Hexagonal Architecture의 정의
Hexagonal Architecture는 앨리스터 코오번(Alistair Cockburn)이 제안한 소프트웨어 설계 패턴으로, ‘포트와 어댑터(Ports and Adapters)’ 패턴이라고도 불립니다. 핵심 아이디어는 애플리케이션의 핵심 로직(도메인, 비즈니스 규칙)을 외부 기술 요소인 DB, 웹 프레임워크, 메시지 큐 등으로부터 완전히 분리하는 것입니다. 육각형 모양은 실제 의미보다는 상징적인 표현으로, 중심에 비즈니스 로직을 두고 여러 방향에서 외부 시스템이 연결될 수 있음을 시각화한 것입니다.
포트와 어댑터는 어떻게 동작하는가
핵심 개념은 ‘포트’와 ‘어댑터’ 두 가지입니다. 포트는 애플리케이션 내부와 외부가 소통하는 인터페이스이고, 어댑터는 그 인터페이스를 실제 기술로 구현한 구현체입니다.
예를 들어 콘센트(포트)는 규격만 정해져 있고, 실제로 꽂히는 것은 냉장고 플러그일 수도 있고 노트북 충전기 플러그(어댑터)일 수도 있습니다. 콘센트 규격 자체는 바뀌지 않지만, 어떤 기기를 꽂느냐에 따라 다른 어댑터가 사용되는 것과 같은 원리입니다.
코드로 보면 비즈니스 로직은 이렇게 인터페이스에만 의존합니다.
interface UserRepository { save(user: User): void }
실제 구현은 어댑터에서 담당합니다.
class MySqlUserRepository implements UserRepository { save(user) { /* DB 저장 로직 */ } }
도메인 로직은 ‘MySqlUserRepository’라는 구체적인 구현을 알 필요가 없고, 오직 ‘UserRepository’ 인터페이스만 알면 됩니다. DB를 MySQL에서 MongoDB로 바꾸더라도 어댑터만 교체하면 되고, 핵심 로직은 전혀 변경할 필요가 없습니다.
실무에서 왜 이 구조를 쓰는가
실무에서 Hexagonal Architecture를 채택하는 이유는 다음과 같습니다.
- 테스트 용이성: 실제 DB나 외부 API 없이도 가짜(Mock) 어댑터로 비즈니스 로직을 독립적으로 테스트할 수 있습니다.
- 기술 교체 유연성: 프레임워크나 DB를 변경해도 핵심 로직은 그대로 유지됩니다.
- 관심사 분리: 비즈니스 규칙과 기술적 세부사항이 섞이지 않아 코드 가독성과 유지보수성이 높아집니다.
다만 이 구조는 작은 프로젝트에서는 오히려 불필요한 추상화로 복잡도를 높일 수 있습니다. 따라서 도메인 로직이 복잡하고 장기간 유지보수가 필요한 서비스에서 특히 효과적입니다.