Hexagonal Rails 아키텍처를 적용한 애플리케이션들은 종종 비표준 도구와 방대한 양의 비기본 종속성을 도입하여 업데이트 및 이해에 상당한 부담을 가중시킵니다. 이는 기존 Rails 내장 기능(ActiveRecord, ERB, 컨트롤러 등)에 익숙한 개발자들에게 새로운 학습 곡선을 요구하며, 특정 개발자에 의해 도입된 도구들이 방치되거나 재작성되는 경우도 발생합니다. 또한, ‘UsersRepository.find_all_with_email(…)’과 같은 간접 계층은 코드의 표현력을 향상시키기보다 변경을 더욱 복잡하게 만들고, 개발자가 ‘정석적인 경로’를 따를지 아니면 ActiveRecord를 직접 사용할지 매번 결정해야 하는 딜레마를 야기합니다.
‘Rails로부터의 분리(Decouple from Rails)’라는 주장은 웹을 주된 전달 수단으로 하는 Rails 애플리케이션의 본질을 간과하는 경우가 많습니다. 결제 공급자 전환, 데이터베이스 없이 비즈니스 로직 테스트, GraphQL 도입과 같은 Hexagonal 아키텍처의 이점으로 제시되는 사항들은 대부분 해당 아키텍처 없이도 충분히 달성 가능하거나, 문제의 본질과는 거리가 있습니다. 예를 들어, 결제 공급자 전환은 아키텍처의 문제가 아닌 외부 API 연동의 문제이며, GraphQL 도입 시 ActiveRecord 사용이 문제가 되는 것이 아니라 뷰 레이어 자체가 재작성되어야 합니다.
Hexagonal Rails와 연관된 DataMapper, rom_rb, dry-rb, Trailblazer, ROAR, RSpec의 과도한 모킹, ‘null database’ 등 많은 도구들은 시간이 지나면서 예상과 다르게 발전하거나 유지보수 문제를 겪었습니다. SSD와 SQLite의 발전으로 ‘null database’와 ‘mock database’의 필요성은 크게 줄었으며, FactoryBot은 테스트 속도 저하의 주범으로 지목되기도 합니다. 이러한 도구들은 추가적인 개념과 종속성을 부과하여 애플리케이션을 ‘프랑켄슈타인의 괴물’처럼 만들 수 있습니다.
그러나 저자는 Hexagonal 아키텍처의 진정한 가치가 ActiveRecord와 같이 방대한 API를 가진 프레임워크의 API 표면을 줄이는 ‘API 축소(API narrowing)’에 있다고 주장합니다. Ruby의 IO 객체 예시를 통해, 필요한 메서드만 노출하는 ‘좁은 인터페이스’가 어떻게 코드의 제어와 안정성을 높이는지 설명합니다. ActiveRecord는 600개 이상의 클래스 메서드와 270개 이상의 인스턴스 메서드를 제공하는 방대한 API를 가지고 있으며, 이는 대규모 협업 환경에서 ‘통행료 징수소’를 설치하기 매우 어렵게 만듭니다. 즉, Hexagonal 아키텍처의 핵심 동기는 비즈니스 유스케이스 모델링보다는 이처럼 거대한 API로부터 발생하는 혼란을 줄이고자 하는 열망에 있었다고 분석합니다.