B컷전문 | 개발과 인생의 이야기

헥사고날 아키텍처는 ‘깔끔한 구조’를 위한 트렌드가 아닙니다. 외부로부터 자유로운 도메인 설계를 위한 철학입니다. 이 글에서는 헥사고날 아키텍처의 본질과 구조, 도입 배경을 현실적인 시각에서 풀어봅니다.

 

솔직히 말하면, 헥사고날 아키텍처라는 이름을 처음 들었을 때,
“왜 하필 육각형이지? 도형은 왜 중요한데?”
이런 생각, 한 번쯤은 해보셨을 겁니다.

하지만 핵심은 형태가 아니라 방향입니다. 헥사고날 아키텍처는 결국 “의존성은 안으로만 향해야 한다”는 단순한 원칙에서 시작합니다.

---

헥사고날 아키텍처, 왜 나왔을까?

이 구조를 처음 제안한 사람은 Alistair Cockburn입니다.
그는 객체지향 설계를 오랫동안 고민하면서 한 가지 문제에 도달합니다:

“왜 항상 비즈니스 로직이 외부 기술에 끌려다니지?”

DB를 바꾸면 도메인 코드가 바뀌고, 웹 프레임워크가 바뀌면 유스케이스 구현도 바뀝니다.
이건 무언가 잘못된 것입니다. 왜냐하면, 핵심 비즈니스 로직은 외부 기술과 독립적이어야 오래 유지되고 안정됩니다.

이 문제를 해결하기 위해, 도메인 로직을 외부 환경으로부터 단절시키는 아키텍처로 등장한 것이 바로 헥사고날입니다.

---

구조를 한눈에 정리하면

헥사고날 아키텍처는 다음과 같은 구조를 갖습니다:

[Infrastructure Adapter] → [Port] → [Application] → [Domain] ← [Port] ← [UI Adapter]

• Domain: 가장 안쪽. 순수한 비즈니스 규칙
• Application: 유즈케이스 흐름 (서비스 계층)
• Port: 외부와 도메인을 연결하는 추상화 계층 (인터페이스)
• Adapter: 외부 시스템(DB, 웹, 메시징, CLI 등)과 실제 연동 구현

육각형은 사실 “어디서든 포트를 연결할 수 있다”는 의미에서 나온 비유적인 도형일 뿐, 필수는 아닙니다. 원으로 그려도 문제없습니다.

---

중요한 원칙 – 의존성은 안쪽으로만

이 아키텍처의 가장 중요한 원칙은 의존성 방향이 항상 도메인을 향한다는 것입니다.
즉, 도메인은 외부 기술을 알지 못합니다.
반대로 DB나 Web, Kafka 같은 어댑터들은 도메인의 인터페이스(Port)를 구현해서 연결됩니다.

이로써 우리는 다음을 얻습니다:

• DB를 바꿔도 도메인은 건드릴 필요 없음
• Web UI가 아니라 CLI로 바뀌어도 유즈케이스는 동일하게 작동
• 테스트에서 어댑터를 전부 Mock으로 대체 가능

---

실무에서의 예시

예를 들어, 전자상거래 시스템에서 ‘주문 생성’이라는 유스케이스가 있다고 해보죠.

• Domain: 주문, 상품, 가격 정책 같은 핵심 로직만 포함
• Application: ‘주문하기’라는 유스케이스의 흐름을 담당 (입력 검증, 주문 생성, 결제 요청)
• Inbound Adapter: REST API Controller, GraphQL, 혹은 CLI 명령어
• Outbound Adapter: JPA 기반 OrderRepository, RedisCache, KafkaProducer

결국 핵심 비즈니스는 외부에 끌려다니지 않고, 필요할 때 다양한 외부 환경을 '연결'할 수 있는 구조가 됩니다.

---

‘실제로 쓸 수 있는 구조인가요?’

이 질문, 정말 자주 받습니다.
정답부터 말하면: 그렇습니다. 하지만 반드시 필요한 건 아닙니다.

헥사고날 아키텍처는 특히 다음과 같은 경우에 유용합니다:

• 테스트 자동화를 많이 하는 팀
• 외부 연동이 많고 기술 변경이 잦은 프로젝트
• 도메인 로직이 복잡하고 장기 운영을 염두에 둔 시스템

반대로 단순 CRUD 위주의 프로젝트에서는 적용 부담이 과도할 수도 있습니다. 의존성 역전을 위해 인터페이스, 어댑터, 포트를 다 구현하려면 손이 많이 가거든요.
그래서 많은 팀들이 핵심 유스케이스나 핵심 도메인에만 제한적으로 적용하는 경우가 많습니다.

---

헥사고날 vs 클린 아키텍처 vs Onion?

헥사고날, 클린 아키텍처, Onion 아키텍처는 철학적으로 거의 유사합니다.

아키텍처 핵심 개념

헥사고날	포트-어댑터 기반의 입력/출력 추상화
클린 아키텍처	유스케이스 중심 + 의존성 규칙 명확화
Onion 아키텍처	도메인을 중심으로 동심원 구조 설계

이름과 표현이 다를 뿐, 의존성은 항상 안쪽으로 향하고, 도메인은 외부에 의존하지 않는다는 철학은 공통입니다.

---

아키텍처는 ‘경계’를 세우는 일

헥사고날 아키텍처가 특별한 이유는, 단지 새로운 구조이기 때문이 아니라,
무엇을 안에 두고 무엇을 밖에 둘지 ‘선’(경계)을 명확히 긋기 때문입니다.

경계가 명확해지면 팀 간 협업도, 코드 유지보수도, 테스트도 쉬워집니다.

무엇보다 중요한 건, 이 아키텍처가 우리에게 주는 자유입니다.
기술 변화에도 흔들리지 않는 핵심 로직. 그것이 바로 헥사고날 아키텍처가 말하는 핵심입니다.