Hexagonal Architecture 리뷰를 보고 느낀 점

내가 읽은 블로그 포스팅
https://tech.kakaopay.com/post/home-hexagonal-architecture/

Hexagonal Architecture, 진짜 하실 건가요? | 카카오페이 기술 블로그

---

Hexagonal Architecture는 언제나 정답일까

– 카카오페이 홈 개편 사례를 통해 느낀 점

 

1. 카카오페이 홈 개편의 배경

카카오페이 홈 서버는 마이크로 서비스 구조로 개편되었고,
Server Driven UI(SDUI)를 적용하여

UI를 서버 응답(JSON)으로 제어하는 방식을 사용하고 있다.

 

이 구조의 핵심은 다음과 같다.

• 서버가 JSON 응답으로 화면 구조와 콘텐츠를 내려준다
• 클라이언트는 이 JSON을 그대로 렌더링한다

이를 위해 일관된 JSON 인터페이스와

표준 API 스펙을 정의하였다.

---

2. 표준 API 스펙의 역할

카카오페이 홈 서버는 하나의 강력한

비즈니스 도메인을 중심으로 동작하기보다는

 

다수의 외부 연동 API를 조합하고

정리하는 역할을 수행한다.

 

이때 표준 API 스펙이 가지는 의미는 크다.

• 연동되는 외부 API에서 새로운 콘텐츠가 추가되더라도
• 사전에 정의된 인터페이스 규칙만 지켜진다면
• 홈 서버는 별도의 코드 수정 없이도
  새로운 콘텐츠를 반영할 수 있다

---

3. Hexagonal Architecture 도입 배경

외부 API 연동이 많고 변경이 잦은 구조에서
내부 핵심 로직을 보호하고 의존성을 줄이기 위해
Hexagonal Architecture(Ports & Adapters)를 내부에 도입하였다.

 

Hexagonal Architecture의 목적은 다음과 같다.

• 비즈니스 로직을 중심에 두고
• 외부 변화가 우리 핵심 로직에 침투하지 못하게 방어

이론적으로는 카카오페이

홈 서버의 상황과 잘 맞아 보였다.

---

4. 실제 적용 후 드러난 문제점

하지만 실제로 운영해 보니 문제가 발생했는데

 

4-1. 보호할 “핵심 도메인”이 명확하지 않았다

카카오페이 홈 서버의 핵심 로직은
외부 API 흐름에 의해 결정되고 조합되는 구조였다.

 

즉,

• 내부 비즈니스 규칙이 외부와 독립적으로 존재하지 않았고
• 외부 API 연동 결과 자체가 곧 도메인이었다

이러한 구조에서는 Hexagonal Architecture가 전제로 하는
“외부로부터 보호해야 할 핵심 도메인”이 존재하지 않았다.

 

4-2. 포트와 어댑터만 계속 늘어나는 구조

외부 연동 서비스가 추가되거나 변경될 때마다 다음 작업이 필요했다.

• 새로운 Port 정의
• Adapter 구현
• 매핑 코드 추가
• 테스트 코드 추가

기능 자체는 단순하지만
관리해야 할 코드와 구조만 계속 증가하는 상황이 되었다.

 

결과적으로 변경에 강해지기 위해 도입한 구조가
오히려 변경 비용을 높이는 구조가 되었다.

 

4-3. 팀 온보딩과 유지보수 비용 증가

구조가 복잡해지면서 신규 인원이 코드를

이해하는 데 더 많은 시간이 필요했다.

• 왜 이 Port가 필요한지
• 왜 Adapter를 거쳐야 하는지
• 실제 비즈니스 로직은 어디에 있는지

이런 설명 비용이 계속 발생했고,
실질적인 비즈니스 로직에 비해 구조가 과도하게 무거워졌다.

---

5. 결국 Hexagonal Architecture 제거

카카오페이 홈 서버에서는
Hexagonal Architecture를 유지하는 것보다

관심사 기반 패키징의 단일 모듈로 회귀하게 되었다.

 

그래서 결국 Hexagonal Architecture를 제거하고
시스템 성격에 맞도록 관심사별로 구분되어 있는

레이어드 아키텍처의 패키지 구조를 따라가고 있다.

---

6. 느낀 점

어떤 아키텍처도 만능은 아니다.

Hexagonal Architecture는 핵심 도메인을

보호해야 하는 시스템에서는 매우 강력한 도구이지만

모든 시스템에 적용해야 할 정답은 아니다.

 

중요한 것은

• 내가 만들고 있는 시스템이 어떤 역할을 하는지
• 핵심 로직이 어디에 있는지
• 보호해야 할 도메인이 실제로 존재하는지

이를 먼저 파악한 뒤,
그에 맞는 구조와 해결 방안을 선택하는 것이다.

---

마무리

아직 초보자다 보니 원문에 기재되어 있는

다양한 기술들을 이해하진 못했지만 (포트, 어댑터, SDU시스템 등)

최대한 큰 주제와 흐름을 이해하려 했다.

 

크게 와닿았던 점은 아키텍처는 목적이 아니라 도구이며
도구는 상황에 맞게 선택되어야 한다는 점이었다.

 

내가 사용하는 코드가 어떤 상황과

어떤 로직을 담고 있는지를 이해하는 것,
그것이 가장 중요한 설계의 출발점이다.

 

내가 앞으로 설계를 진행할 일이 있다면

내가 담당하는 프로젝트가 어떤 관계를 띄고 있고

어떤 로직을 핵심으로 돌아가는지 꼭 파악하고

설계 작업에 들어가려 한다.