“좋은 아키텍처는 비즈니스 로직을 외부 세계로부터 보호하고, 외부 세계가 비즈니스 로직에 의존하도록 만든다.” - 로버트 C. 마틴
모든 프로젝트는 살아있는 유기체처럼 성장하고 변화합니다. 처음에는 단순했던 기능도 시간이 지나면서 복잡해지고, 새로운 요구사항이 끊임없이 추가됩니다. 이때, 우리가 채택한 아키텍처가 변화의 발목을 잡는 기술 부채가 될 것인가, 아니면 지속 가능한 성장을 뒷받침하는 든든한 발판이 될 것인가가 결정됩니다.
이번 글에서는 THIP의 이전 버전인 ‘책산책(BookJourney)’ 프로젝트에서 경험했던 레이어드 아키텍처의 한계를 구체적인 사례를 통해 돌아보고, 왜 헥사고날 아키텍처(Hexagonal Architecture) 로의 전환이 단순한 기술적 선택이 아닌, 제품의 장기적인 성장과 유지보수 효율성, 그리고 팀의 개발 경험을 위한 최선의 결정이었는지 그 여정을 공유하고자 합니다.
‘책산책’ 프로젝트의 초기 목표는 명확했습니다. 빠르게 프로토타입을 만들고 동아리 데모데이를 무사히 마치는 것.
시간이 한정된 상황에서, 팀이 가장 익숙하게 속도를 낼 수 있는 구조가 필요했고, 그래서 전형적인 **레이어드 아키텍처(Layered Architecture)**를 선택했습니다.
bookjourney-backend/
└── domain/
├── user/
│ ├── controller/
│ ├── service/
│ ├── domain/ # 실제로는 JPA Entity
│ └── dto/
└── room/
├── controller/
├── service/
├── domain/ # 실제로는 JPA Entity
└── dto/
이 구조는 계층이 명확하고 직관적이어서 초기 개발 속도를 높이는 데 큰 도움이 되었습니다. 컨트롤러는 요청을 받고, 서비스는 비즈니스 로직을 처리하며, 엔티티는 데이터베이스 테이블과 1:1로 매핑되는 방식으로 빠르게 기능을 만들어낼 수 있었습니다.
문제는, 이 속도가 ‘프로토타입을 완성하는 데’ 최적화되어 있었다는 점입니다.
데모데이까지는 “보여줄 수 있는 형태”만 갖추면 됐기 때문에, 구조의 단점이 쉽게 드러나지 않았습니다. 오히려 레이어드 아키텍처는 개발을 단순하게 만들어 줬고, 그 단순함이 빠른 성과로 이어졌습니다.
하지만 데모데이를 끝내고 나니 이야기가 달라졌습니다.
실제 서비스 운영을 위해서는 “동작하는 기능”이 아니라, 사용자가 실제로 원하는 기능을 지속적으로 다듬고 바꿔나가는 과정이 필요하기 때문입니다.
그리고 그 순간, 초기에 당연하게 받아들였던 레이어드 구조가 변화에 취약한 구조였다는 사실이 체감하기 시작했습니다.