헥사고날 아키텍처, MSA, 그리고 AI 시대의 변화
개발자 면접이나 실무 기술 미팅에서 단골로 등장하는 질문이 있다.
“프로젝트를 진행할 때 어떤 패키지 구조를 선호하시나요?”
이 질문을 받으면 많은 이들이 최근 유행하는 아키텍처나 자신이 감명 깊게 읽은 책의 구조를 정답처럼 이야기하곤 한다. 하지만 시니어 개발자들이나 아키텍트들이 이 질문을 던지는 본질적인 이유는 따로 있다.
결론부터 말하자면, 패키지 구조에 정답은 없다. 모든 것은 환경에 따라, 비즈니스의 복잡도에 따라 매번 달라지기 때문이다.
이 질문이 왜 끊임없이 나오는지, 그리고 그 속에서 언급되는 핵심 개념인 헥사고날 아키텍처와 MSA가 어떤 관계를 맺고 있는지 정리해 보고자 한다.
헥사고날 아키텍처: 비즈니스 로직의 철저한 독립
헥사고날 아키텍처(Hexagonal Architecture)를 한 마디로 정의하자면 “핵심 비즈니스 로직(도메인)을 외부 기술(DB, 웹 프레임워크, 외부 API 등)로부터 철저하게 독립시키자”는 인터페이스 기반의 설계 방식이다.
흔히 ‘포트 앤 어댑터(Ports and Adapters)’ 구조라고도 부른다.
- 장점: 데이터베이스를 MySQL에서 MongoDB로 바꾸거나, 웹 프레임워크를 완전히 변경하더라도 핵심 비즈니스 로직은 전혀 손댈 필요가 없다. 코드가 기술에 종속되지 않으니 테스트 코드를 작성하기에도 매우 유용하다.
- 단점: 외부와 연결되는 인터페이스(포트)와 이를 구현하는 클래스(어댑터)를 일일이 다 만들어야 하므로, 클래스 파일이 엄청나게 많이 쏟아진다. 소규모 프로젝트나 단순한 CRUD 중심의 시스템에 적용하면 배보다 배꼽이 더 커지는 상황이 발생한다.
AI 시대가 가져온 단점의 상쇄
과거에는 이 수많은 보일러플레이트(반복적인 기초 코드) 클래스들을 일일이 타이핑하는 것이 개발자에게 큰 고역이었다. “굳이 이렇게까지 클래스를 쪼개야 하나?”라는 회의감이 들 만했다.
하지만 지금은 AI 시대다. LLM에게 개발 환경과 도메인 모델을 제시하고 “이 도메인을 기반으로 헥사고날 구조의 포트와 어댑터 코드를 짜줘”라고 요청하면, 순식간에 수십 개의 클래스 구조를 깔끔하게 만들어준다.
즉, “클래스가 너무 많이 생성되어 생산성이 떨어진다”는 헥사고날의 전통적인 단점이 AI 툴의 발전으로 인해 더 이상 절대적인 약점이 아니게 된 것이다.
MSA(마이크로서비스 아키텍처)와 도메인의 크기
그렇다면 요즘 대세인 MSA 환경에서는 패키지 구조를 어떻게 가져가야 할까? 이 역시 “그때그때 다르다”가 답이다. MSA로 서비스를 어디까지 쪼갰느냐에 따라 최적의 구조가 달라지기 때문이다.
- 도메인을 극단적으로 쪼갠 경우 (Micro): 하나의 마이크로서비스가 정말 단 하나의 핵심 도메인만 담당할 만큼 작다면, 복잡한 헥사고날 아키텍처는 사치일 수 있다. 이럴 때는 스프링의 가장 기본적이고 직관적인 레이어드 구조(Controller – Service – Repository)만으로도 충분히 깔끔하고 유지보수하기 쉬운 코드가 나온다.
- 큰 서브도메인을 안고 있는 경우 (Macro): MSA를 지향하지만 현실적인 한계나 비즈니스 복잡도로 인해 특정 서비스 내에 여러 서브도메인이 얽혀 있는 경우도 많다. 이럴 때는 마이크로서비스 내부에서 다시 도메인별로 경계를 나누고, 그 아래에서 헥사고날 아키텍처를 도입해 비즈니스 로직을 보호하는 전략이 유효하다.
결국 시스템을 MSA로 쪼갤 만큼 쪼갰다면 기본 구조로도 충분하고, 그렇지 않고 내부 복잡도가 높다면 헥사고날이나 더 고도화된 레이어 구조가 필요하다는 뜻이다.
질문의 본질
다시 처음으로 돌아가서, 면접관들은 왜 우리에게 선호하는 패키지 구조를 물어볼까?
그들은 특정 아키텍처 명칭을 듣고 싶어 하는 게 아니다.
기술을 선택할 때 ‘트레이드 오프(Trade-off)’를 고려할 줄 아는 개발자인지 확인하고 싶은 것이다.
- 맹목적인 유행 추종 걸러내기: “요즘 트렌드니까 무조건 헥사고날로 짜야 합니다”라고 말하는 개발자보다, “우리 서비스의 규모와 팀의 리소스, 그리고 AI 툴 활용 여부까지 고려했을 때 지금은 이 구조가 최선입니다”라고 말할 수 있는 개발자를 찾기 위함이다.
- 상황(Context) 중심의 사고방식: 아키텍처는 고정된 진리가 아니라 생물처럼 변하는 환경에 맞추어 가는 도구다. 프로젝트의 시작 단계, 성장 단계, 그리고 MSA 전환 단계 등 각 환경에 맞는 유연한 사고를 할 수 있는지 평가하는 아주 좋은 척도가 된다.
결국 본질은 ‘상황’이다
기술의 세계에서 Silver Bullet은 없다.
헥사고날 아키텍처가 아무리 훌륭한 독립성을 보장하더라도 가벼운 토이 프로젝트에 도입하는 건 낭비이며, 반대로 거대하고 복잡한 금융 시스템을 단순 레이어드 구조로만 방치하는 건 재앙이다.
내가 처한 환경, 우리 팀의 역량, 비즈니스의 목표, 그리고 AI와 같은 도구의 지원 여부까지.
이 모든 상황을 종합적으로 판단하여 ‘지금 이 순간 우리에게 가장 알맞은 무게의 구조’를 선택하는 것.
그것이 진정한 아키텍처의 시작이자 이 질문이 개발자들에게 던지는 주관식 정답일 것이다.
0 글이 마음에 드시면 하트를 눌러주세요! 행복한 고민이 됩니다!