“헥사테트라헤드랄” 앱은 비표준 도구 사용으로 유지보수 부담이 크고, 독단적인 규칙들이 코드의 표현력을 저해하며 변경을 복잡하게 만듭니다. 헥사고날 아키텍처의 원래 전제는 건전하지만, 레일즈 내부에서 “프레임워크로부터 분리”하려는 주장은 대부분 설득력이 부족하며, 이는 “결합도를 낮추기 위해 결합도를 낮춘다”는 순환 논리에 불과합니다. 지지자들이 제시하는 이점들(예: 결제 제공업체 전환 용이성)은 현실적인 맥락에서 과장되거나 불필요한 복잡성을 야기합니다. 저자는 헥사고날 아키텍처의 진정한 가치가 비즈니스 도메인 모델링보다는 ActiveRecord와 같은 레일즈의 방대한 API 표면을 “API 축소(API Narrowing)”하려는 시도에 있다고 주장합니다. ActiveRecord의 거대한 API는 대규모 팀 협업 시 혼란을 야기할 수 있습니다. 헥사고날 아키텍처는 이러한 API 위에 얇은 인터페이스를 만들려 했으나, “repository” 패턴과 같은 간접적인 접근 방식은 결국 개발자들이 직접 ActiveRecord를 호출하게 만듭니다. 이러한 아키텍처 유지에 필요한 규율은 매우 높고, 특정 프로젝트에만 국한되는 비표준적인 학습 곡선은 개발자들에게 부담이 됩니다.
헥사테트라헤드랄 레일즈 애플리케이션: 오해와 가치
Hexatetrahedral Rails
작성자
HackerNews
발행일
2025년 07월 26일
핵심 요약
- 1 "헥사고날 레일즈" 아키텍처는 의도치 않은 복잡성을 야기하며, 유지보수 및 진화에 어려움을 초래하는 경우가 많습니다.
- 2 이 아키텍처의 진정한 가치는 비즈니스 도메인 모델링보다는 ActiveRecord와 같은 거대한 API의 표면을 축소하려는 시도에 있습니다.
- 3 오늘날에는 엄격한 육각형 아키텍처를 따르기보다는, 규율을 통해 모듈별로 API를 축소하고 관리하는 방식이 더 실용적입니다.
도입
과거 유행했던 "헥사고날 레일즈(Hexagonal Rails)" 아키텍처는 DDD와 헥사고날 아키텍처 원칙에 기반을 두었으나, 시간이 지나면서 의도치 않은 복잡성을 야기하는 "헥사테트라헤드랄 레일즈"로 인식되고 있습니다. 본 글은 이러한 아키텍처의 문제점과 그 이면에 숨겨진 진정한 가치를 분석합니다.
결론
결론적으로, 저자는 오늘날 "헥사고날 레일즈" 아키텍처 도입을 권장하지 않습니다. 이 아키텍처의 유일한 타당한 이유는 대규모 팀이 협업하는 코드베이스에서 ActiveRecord와 같은 거대한 API의 표면을 줄이는 것입니다. 그러나 이는 비즈니스 유스케이스 모델링 시도로서는 실패했으며, 레일즈 커뮤니티 역시 `Packwerk`과 같은 다른 고립화 시도로 나아가고 있습니다. 헥사고날 아키텍처에서 얻을 수 있는 교훈은 여전히 유효하지만, 특정 도구들을 반드시 사용할 필요는 없습니다. 가장 중요한 것은 "규율"입니다. API 축소의 본질적인 목표를 달성하기 위해서는 각 도메인을 루비 모듈로 정의하고 그 안에 모델 등을 포함시키는 방식과 같이 엄격한 규율을 유지하는 것이 중요합니다. "헥사테트라헤드랄 레일즈"는 과거의 유행이었으며, 그 의도는 좋았지만 실질적인 이점보다는 복잡성을 더 많이 가져왔습니다.