헥사고날 아키텍처를 선택하기 전에 물어야 할 것

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

헥사고날 아키텍처를 적용했는데 설계는 나아지지 않고 시스템만 더 복잡해질 수 있다. 팀이 해결할 문제보다 아키텍처의 이름에서 출발해 포트와 어댑터를 기계적으로 늘리면 이런 일이 생긴다. 겉으로는 아키텍처가 있어 보이지만 다음 유지보수자는 얻는 이점 없이 더 많은 간접 계층을 따라가야 한다.

문제는 헥사고날 아키텍처 자체가 아니다. 그것을 개발 역량의 표식이나 기본 정답처럼 선택하는 태도가 문제다. 아키텍처를 고르려면 지금 만드는 시스템의 인터페이스, 성장 가능성, 필요한 격리 수준, 유지보수 부담에서 나온 근거가 있어야 한다.

아키텍처가 설계 역량을 대신하지 않는다

결합도를 낮추고 의존성을 통제하며 의존성 역전을 활용하는 일은 중요하다. 헥사고날 아키텍처도 이를 달성하는 한 가지 방법이다. 그러나 포트와 어댑터를 추가한다고 구현과 설계가 저절로 좋아지지는 않는다. 책임을 나누거나 흐름을 설계하는 데 어려움을 겪던 개발자라면 같은 문제를 더 많은 파일과 인터페이스에 흩어 놓을 수도 있다.

반대로 잘 설계한 레이어드 구조에서도 책임과 의존성을 충분히 통제할 수 있다. 요구사항을 더 알게 됐을 때 확장할 수도 있다. 아키텍처를 조금만 바꾸려 해도 지나치게 어렵다면 특정 아키텍처를 처음부터 쓰지 않은 탓으로 돌리기 전에 구현과 설계 자체를 살펴볼 필요가 있다.

회사에서는 이 문제가 더 중요하다. 개발한 코드는 장기간 다른 사람이 유지보수해야 하는 회사의 자산이다. 필요 없는 추상화의 비용은 리뷰어, 새로 합류한 동료, 처음 만든 사람이 떠난 뒤 시스템을 변경할 사람이 지불한다. 유행하는 이름이 그 비용을 상쇄해 주지는 않는다.

모든 경계에는 구체적인 이유가 필요하다

이 접근법을 충분히 경험하지 못했을 가능성도 있으므로 다음 내용은 보편적인 규칙이 아니라 선택 기준으로 봐야 한다. 헥사고날 아키텍처를 선택할 만한 한 가지 상황은 여러 프로토콜을 받아야 하는 시스템이다. 같은 비즈니스 기능으로 gRPC, HTTP, TCP나 또 다른 인터페이스가 들어올 수 있다. 이런 경우에는 포트와 어댑터를 명시해 각 프로토콜의 차이를 핵심 흐름에서 격리하는 방식이 효과를 낼 수 있다.

더 강한 격리 자체가 실질적인 이점이 될 때도 있다. 서비스가 여러 인터페이스를 향해 성장할 근거가 있거나, 교체 가능한 경계가 구조를 유지하는 데 충분히 중요할 수 있다. 핵심은 그 예상을 설명할 수 있느냐다. “이 프로토콜들이 달라지기 때문에 경계가 필요하다”거나 “곧 이 인터페이스들이 추가될 가능성이 있고, 이 구조로 변화 지점을 통제하겠다”는 것은 근거가 된다.

평범한 경로 하나로 통신하는 작은 서비스의 판단은 달라야 한다. 단순한 HTTP 진입점과 데이터베이스로 동작한다면 포트와 어댑터 전체를 갖추는 일이 탐색할 코드만 늘릴 수 있다. 작은 쿠폰 서비스도 헥사고날로 만들 수는 있다. 다만 그 규모에서 추가 격리가 어떤 가치를 주는지는 답할 수 있어야 한다. 유명한 책에 나오거나 다른 팀이 많이 쓴다는 이유만으로는 부족하다.

바꿀 수 있는 구조에서 시작한다

구현과 도메인을 충분히 이해하기 전에 최종 아키텍처를 모두 예측할 필요는 없다. 현재의 흐름을 명확히 표현한다면 단순한 레이어드 설계도 책임 있는 출발점이 된다. 직접 실험해 본 범위에서는 잘 만든 레이어드 구조를 헥사고날 구조로 옮기는 일이 가능했다. 이것이 모든 전환이 쉽다는 증거는 아니다. 다만 처음부터 가장 복잡한 목표 구조를 설치해야만 한다는 생각에는 반례가 된다.

더 중요한 조건은 나중에도 바꿀 수 있는가이다. 책임을 명확히 두고, 의존성이 무심코 번지는 것을 막고, 근거 없이 비즈니스 결정을 전송 방식에 묶지 않아야 한다. 이런 성질을 지키면 실제 변화가 나타날 때 더 강한 경계를 도입할 여지가 남는다. 팀이 나중에 어떤 아키텍처 이름을 선택하든 필요한 기반이기도 하다.

학습과 업무의 목적도 구분해야 한다. 호기심으로 아키텍처를 적용해 보는 개인 실험은 자연스럽다. 운영할 코드는 기준이 다르다. 그 구조가 제품에 왜 도움이 되는지, 팀이 앞으로 치를 유지보수 비용을 왜 감수할 만한지 설명해야 한다.

만들 대상의 크기에 구조를 맞춘다

작은 빌라와 아주 높은 건물을 같은 방식으로 짓지는 않는다. 소프트웨어도 마찬가지다. 작은 문제에 큰 시스템을 위한 구조를 선택한다고 문제가 더 중요해지는 것은 아니다. 결과에 필요한 것보다 많은 노력만 들 수 있다.

엔지니어링은 목적을 달성하는 데 필요한 만큼의 구조, 용량, 안전성을 선택하는 일이다. 크지 않은 부하에 과도한 인프라를 투입하면 몇 가지 어려운 판단은 피할 수 있겠지만 세심한 엔지니어링이라고 하기는 어렵다. 아키텍처도 비용을 치르는 자원이며, 그 자리를 차지할 만한 이점을 보여줘야 한다.

헥사고날 아키텍처를 고르기 전에 네 가지를 바로 물어보자.

1. 구체적으로 어떤 프로토콜이나 인터페이스가 달라져야 하는가?
2. 이 서비스에 어떤 격리가 필요하며, 그 이유는 무엇인가?
3. 예상 규모나 성장 가능성이 지금 복잡성을 감수할 만큼 분명한가?
4. 팀이 추가한 모든 경계를 유지보수하고 설명할 수 있는가?

답이 구체적이라면 헥사고날 아키텍처는 합리적인 선택이 될 수 있다. 답이 모호하다면 비즈니스 흐름을 명확히 표현하면서 나중에 바꿀 수 있는 가장 작은 설계로 시작하면 된다. 아키텍처를 피하자는 뜻이 아니다. 모든 아키텍처 선택에 그 선택만의 이유를 요구하자는 뜻이다.