클린 아키텍처 vs 헥사고날 아키텍처 비교 — 2026년 기준 실무에서 어떤 걸 골라야 할까?

몇 달 전, 한 스타트업 개발팀에서 이런 고민을 털어놓았어요. “우리 팀이 새 서비스를 설계하면서 클린 아키텍처로 갈지, 헥사고날 아키텍처로 갈지 한 달째 논쟁 중인데 결론이 안 납니다.” 사실 이 두 아키텍처는 겉으로 보면 굉장히 비슷해 보이면서도, 실제 코드베이스에 녹여내는 순간 꽤 다른 느낌을 줍니다. 오늘은 이 두 가지를 같이 뜯어보면서, 어떤 상황에 어떤 선택이 더 맞는지 함께 고민해 보려 해요.

📐 먼저, 두 아키텍처의 핵심 철학부터 짚어봐야 합니다

클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(일명 “엉클 밥”)이 2012년에 정립한 개념으로, 소프트웨어를 동심원(Concentric Circles) 형태의 레이어로 구성합니다. 안쪽부터 Entities → Use Cases → Interface Adapters → Frameworks & Drivers 순으로 쌓이며, 핵심 규칙은 하나예요. 의존성은 항상 안쪽(비즈니스 규칙)을 향해야 한다는 것이죠. 즉, 외부 기술(DB, 프레임워크, UI)이 바뀌어도 비즈니스 로직은 건드리지 않아야 한다는 원칙입니다.

헥사고날 아키텍처(Hexagonal Architecture)는 그보다 앞선 2005년 앨리스테어 콕번(Alistair Cockburn)이 제안했으며, “포트와 어댑터(Ports & Adapters)” 아키텍처라고도 불려요. 애플리케이션의 핵심(도메인)을 육각형 가운데에 두고, 외부 세계와의 통신은 포트(인터페이스)를 통해서만 허용하고, 그 포트에 실제 구현체인 어댑터를 꽂는 방식입니다. REST API든 CLI든 메시지 큐든, 모두 어댑터로 교체 가능한 구조라고 볼 수 있어요.

📊 구체적인 구조 비교 — 숫자와 레이어로 살펴보기

2026년 현재 GitHub에서 ‘clean architecture’ 관련 저장소는 약 6만 2천 개 이상, ‘hexagonal architecture’는 약 1만 8천 개 수준으로 집계됩니다(GitHub Search 기준 추정치). 절대적인 인지도는 클린 아키텍처가 높지만, 헥사고날은 최근 3년간 DDD(도메인 주도 설계) 열풍과 함께 급격히 주목받고 있는 라이크 인 것 같습니다.

두 아키텍처를 레이어 수와 핵심 개념 측면에서 수치로 비교해 보면 아래와 같아요.

• 클린 아키텍처 레이어 수: 공식적으로 4개 (Entities, Use Cases, Interface Adapters, Frameworks & Drivers). 팀에 따라 5~6개로 세분화하는 경우도 흔합니다.
• 헥사고날 아키텍처 레이어 수: 크게 3개 영역 (Application Core, Primary Adapters/Driving Side, Secondary Adapters/Driven Side). 레이어보다는 방향성(인바운드/아웃바운드)으로 구분하는 게 특징이에요.
• 의존성 규칙: 클린 아키텍처는 단방향 안쪽 지향, 헥사고날은 포트 인터페이스를 통한 양방향 격리.
• 테스트 용이성: 두 아키텍처 모두 외부 의존성을 Mock으로 교체하기 쉬운 구조. 다만 헥사고날은 포트 단위로 Mock을 꽂을 수 있어 단위 테스트 설계가 더 직관적이라는 평이 많습니다.
• 러닝 커브: 설문 기반 커뮤니티 조사(2025~2026년 Dev.to, Reddit 기준)에서 클린 아키텍처의 초기 학습 난이도가 약 10~15% 더 높다고 응답한 개발자 비율이 우세했어요. 특히 레이어 이름과 책임 범위 혼동이 원인으로 꼽혔습니다.

🌍 국내외 실제 적용 사례로 보는 차이점

해외 사례 — Netflix와 Amazon: Netflix는 마이크로서비스 전환 과정에서 클린 아키텍처의 계층 분리 개념을 차용한 것으로 알려져 있어요. 특히 Use Case 레이어를 서비스 오케스트레이션 레이어로 활용해 비즈니스 로직과 인프라를 분리하는 방식이 내부 기술 블로그에 공개된 바 있습니다. Amazon의 일부 팀에서는 헥사고날 아키텍처의 포트 개념을 이벤트 드리븐 아키텍처와 결합해, SQS나 SNS 같은 메시지 브로커를 아웃바운드 어댑터로 처리하는 패턴을 활용한다고 봅니다.

국내 사례 — 카카오페이, 토스: 국내 핀테크 진영에서는 DDD와 헥사고날 아키텍처의 조합이 빠르게 확산 중인 것 같아요. 토스(Toss)의 기술 블로그(toss.tech)에서는 도메인 모델 중심의 설계를 강조하며, 외부 결제 게이트웨이나 알림 서비스를 어댑터 패턴으로 교체 가능하게 설계한 사례를 공유했습니다. 카카오페이 역시 클린 아키텍처 기반의 레이어 분리를 내부 서비스에 적용하되, 포트&어댑터 개념을 혼합해 쓰는 하이브리드 접근을 택한 것으로 알려져 있어요.

⚖️ 그래서 실무에서 어떤 기준으로 선택해야 할까요?

두 아키텍처는 사실 상호 배타적이 아닙니다. 클린 아키텍처가 “무엇을 어떤 계층에 둘 것인가”의 관점이라면, 헥사고날 아키텍처는 “외부 세계와 어떻게 통신할 것인가”의 관점에 더 가깝다고 볼 수 있어요. 그래서 많은 팀들이 두 개념을 혼합해서 씁니다.

• 클린 아키텍처가 더 잘 맞는 상황: 팀 규모가 크고 레이어별 책임을 명확히 가이드해야 할 때, 기존 레거시 코드를 점진적으로 리팩터링할 때, 엔터프라이즈 규모의 복잡한 비즈니스 규칙이 있을 때.
• 헥사고날 아키텍처가 더 잘 맞는 상황: 외부 연동이 잦고 교체 가능성이 높을 때 (DB 마이그레이션, 서드파티 API 교체 등), TDD(테스트 주도 개발)를 중심으로 팀이 운영될 때, DDD와 함께 도메인 모델을 명확히 유지하고 싶을 때.
• 둘 다 고려해야 할 때: 마이크로서비스 아키텍처에서 각 서비스가 독립적인 도메인을 갖고, 외부 이벤트나 API와 자주 통신하는 구조라면 두 개념을 함께 적용하는 것이 현실적인 라이크 인 것 같습니다.

🧩 결론 — 정답보다는 맥락이 중요합니다

아키텍처 선택은 “어떤 게 더 좋은가”의 문제가 아니라, “우리 팀의 현재 맥락에 무엇이 더 잘 맞는가”의 문제라고 봅니다. 클린 아키텍처는 계층적 사고로 팀 전체에 명확한 설계 가이드를 제공하고, 헥사고날 아키텍처는 외부 의존성을 포트로 추상화해 비즈니스 로직의 순수성을 지키는 데 탁월해요.

처음 아키텍처를 도입하는 팀이라면, 클린 아키텍처의 레이어 개념으로 팀 컨벤션을 잡고, 외부 연동 포인트에서 포트&어댑터 패턴을 점진적으로 도입하는 하이브리드 전략이 가장 현실적인 대안이라고 생각해요. 완벽한 아키텍처를 처음부터 설계하려다 오버엔지니어링에 빠지는 것보다, 작게 시작해서 필요에 따라 확장하는 접근이 2026년 현재 빠른 제품 개발 환경에 훨씬 적합하다고 봅니다.

에디터 코멘트 : 이 두 아키텍처 논쟁에서 자주 빠지는 함정이 있어요. “어떤 아키텍처를 쓰느냐”보다 “팀이 그 아키텍처의 원칙을 실제로 지키고 있느냐”가 훨씬 더 중요하다는 거예요. 화려한 아키텍처 다이어그램을 그려놓고 실제 코드에서는 레이어를 무시하는 경우가 생각보다 정말 많거든요. 어떤 아키텍처를 선택하든, 팀 내 코드 리뷰와 페어 프로그래밍을 통해 원칙이 실제 코드에 살아있도록 하는 문화가 뒷받침되어야 한다고 생각합니다. 아키텍처는 결국 도구이고, 그걸 제대로 쓰는 건 사람이니까요. 🙂