Hexagonal Architecture, 진짜 하실 건가요? 글을 읽으며..

https://tech.kakaopay.com/post/home-hexagonal-architecture/#%ED%95%B4%EA%B2%B0%EC%B1%85-2-%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98%EB%A5%BC-%ED%86%B5%ED%95%9C-%ED%95%B4%EA%B2%B0-hexagonal-architecture

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

 

좋은 글을 추천받아 한 번 읽고

이해한 걸 정리해보는 글을 작성해보겠습니다

 

 

---

 

 

글의 요약은 서두에 나왔있었습니다.

 

 Hexagonal Architecture를 도입했다가 제거한 경험을 통해

해당 아키텍처의 장단점과 실질적인 문제점을 다루고

완벽해보이는 Hexagonal Architecture도 상황에 따라 약점이 될 수 있음을 강조하며,

이를 적절히 화룡하는 방법의 중요성을 전달합니다.

이 글을 실제 사례를 기반으로 아키텍처 도립을 고민하는 개발자들에게

유용한 교훈과 인사이트를 제공한다고 합니다.

 

 

 

그렇다면 여기서 말하는 Hexagonal Architecture는 무엇인지 찾아보았습니다.

👉 비즈니스 로직을 외부 환경으로부터 완전히 분리하기 위한 아키텍처 패턴

쉽게 말해 핵심 로직은 건드리지 않고, 입출력(웹, DB, API 등)은 언제든 바꿀 수 있게 하자

라는 철학이라고 합니다.

 

 

아마 제가 진행하는 프로젝트를 예로 들면

Service → 핵심 로직

Servlet, JSP → 입출력

DAO → 입출력

 

Service는 일 처리 규칮만 아는 직원이고

Servlet, JSP, DAO는 전화기, 서류,창구 같은 도구입니다

 

직원은

전화기가 뭔지

창구가 웹인지 앱인지

서류가 DB인지 파일인지

전혀 몰라도 일을 처리할 수 있어야 합니다

 

이처럼 핵심 로직(Service)이 입출력 도구를 전혀 모르게 만드는 구조,
그것이 바로 Hexagonal Architecture입니다

 

Service가 Servlet/DAO를 모르게 만들면

이게 바로 Hexagonal Architecture입니다.

 

 

---

 

이제 이 글의 2023년 개편된 카카오페이 새로운 홈 서버의 코드 아키텍처의 변화를 돌아보며

Hexagonal Architecture를 적용했다 다시 제거한 이유에 대한 글을 읽어보겠습니다

 

 

요즘 많은 사람들이 사용하는

카카오페이는 카카오톡과 카카오페이 앱을 통해

접근이 가능하다

 

유저들은 두 가지 앱을 통해 접근하면 카카오페이 홈을 만나게 되는데

개편 이전에는 카카오톡과 카카오페이 앱을 통해 접근했을 때 만나게 되는

UI가 달랐습니다

그리고 유저의 데이터 기반으로 보여주는 정보가 많이 없었다고 합니다

 

 

 

원래 카카오톡에 특화된 기능과 카카오페이앱에 특화된 기능에 조금씩 차이가 있었기 때문에,

채널서버유닛에서는 각 접근 지점별로 마이크로서비스를 구성하여 서버를 관리했습니다

 

 

 

🌸 마이크로서비스란?

하나의 큰 애플리케이션을 여러 개의 작은 서비스로 나누어

개발·운영하는 아키텍처 방식

 

각 기능을 독립적인 서비스로 분리해서

각자 배포·확장·개발할 수 있게 하는 구조

 

---

 

 

 

이후 카카오톡과 카카오페이 앱 모두 통일된 UI를 만날 수 있도록 홈이 개편되었습니다

 

통합된 UI를 보여준다는 점과, 기존 두 가지 서버를 동시에 유지보수하는 것이

효율적이지 않다고 생각해 새로운 카카오페이 홈 마이크로서비스를 구성했습니다

 

 

카카오페이 홈 서버의 핵심 과제

개편된 홈의 핵심 과제는 다음과 같았습니다

 

 

Server Driven UI 적용

개편된 카카오페이 홈은 유저의 앱 버전과 무관하게 최대한

동일한 유지 경험을 제공할 수 있도록 Server Drive UI 기반으로 설계됨

클라이언트 개발자분들과 일관된 JSON 인터페이스를 정의하고, 해당 인터페이스에

맞춰서 응답을 할 경우 정의된 대로 UI가 보이도록 함

 

서버에서 가능한 모든 정보를 제어하도록 설계

텐츠들의 순서나 노출 여부 그리고 각 콘텐츠에 노출되어야 하는 텍스트 등이 모두 서버를 통해 제어됨

당시에는 결제탭에서 활용하고 있는 클라이언트실의 SDU 시스템이 없었기

때문에 홈의 특성에 맞춰 직접 스펙을 정의하고 구현함

 

 

 

 

🌸 SDU 시스템

서버에서 화면(UI)과 콘텐츠 구성을 정의,제어하는 시스템

SDU는 화면을 미리 고정하지 않고 서버가 "이 화면에 이 순서로 이 텍스트를 보여줘"라고 

내려주는 시스템

 

 

---

 

 

실시간 유저 데이터 서빙

개편된 카카오페이 홈은 실시간 데이터를 기반으로 유저에게 이로운 정보를 보여줄 수 있게 설계됨

또한 홈의 전체 콘텐츠를 Server Driven UI로 구현하기 위해 단일 API로 구성함

 

🌸 Server Driven UI

화면을 어떻게 보여줄지 까지 서버가 결정하는 UI 설계 방식

쉽게 말해 클라이언트는 그리기만하고, 서버가 무엇을 어떤 순서로

어떤 문구로 보여줄지 정한다

 

 

따라서 단일 클라이언트 API 호출에 대해 수많은 연동 API 호출을

통해 정보를 조합해야 하는 서버입니다

 

 

---

 

 

 

초기 아키텍처

 

처음 서버를 개발할 때에는 연동을 하기 위해 협의해야 하는 지점도 많았고,

개발해야 하는 양도 많았기 때문에 레이어 단위로 패키징을 한 레이어드 아키텍처 기반으로 개발함

 

또한 종종 연동 서버에서 받아온 응답을 그대로 클라이언트까지 넘겨줘야 하는 경우도 있었는데,

이때에도 서버의 응답 DTO를 그대로 클라이언트로 보내는 DTO에 재활용도 함

같은 객체가 여러 레이어에 걸쳐 사용되어 불편함을 초래할 때가 종종 있었지만,

익숙한 구조 속에서 빠르게 서비스를 개발 가능

 

 

but 문제점

먼저 프록시를 하는 경우 클라이언트의 UI까지 연동 API 응답에 의존하는 문제

앞서 말씀드렸다시피, Server Driven UI 기반으로 설계했기 때문에 클라이언트는

서버에서 응답하는 UI를 그대로 그리는 구조

연동 API 응답의 스펙이나 값이 바뀔 경우,

값을 검증할 기회 없이 클라이언트로 전달되어 UI가 망가지거나 노출되지 않는 문제가 발생

 

또한 첫 서비스 오픈을 위한 개발이다 보니 연동 API 스펙에 있어 변화도 자주 발생

API 스펙이 한번 변할 때마다 해당 연동 API 응답을 다시 Server Driven UI 응답으로

변환하기 위해 많은 공수를 들여야함

 

 

---

 

 

외부 의존성 문제 해결책

◾ 다른 팀과의 협업 '프로세스'를 통한 해결

◾ 우리 코드의 '아키텍처'를 통한 해결

 

 

 

해결책1 : 프로세스를 통한 해결, '연동 API 인터페이스'

첫 번째 접근은 연동 API 인터페이스 라는 이름의 표준 API 스펙을 정의하는 것

보통 서버 간 연동이 필요한 경우는

다른 부서 실시간 정보를 불러와 피드 형태로 변환하는 경우

 

 

개선 이전에는 기존에 존재하던 API의 응답 값을 홈 서버의 로직으로 처리하여 해당 카드 형태로 변환함

이 경우 연동 API 스펙이 변경되면 필연적으로 홈 서버에서도 반영을 위한 작업을 해야함

특히 전사적으로 큰 기술 변경이 있을 때마다 홈 서버는 연동하는 모든 부서의 응답 변경에 대응해야 하는 경우 발생 가능

 

이를 해결하기 위해 연동 부서에서 특정 스펙에 맞춰 홈 서버에 API에 응답하면 약속된 형태로 클라이언트에 반환할 수 있는 API 스펙을 만듦 ▶  홈 서버에서는 어드민에 등록되어 있는 정보와 해당 연동 API 응답을 교차 검증, 활용하여 카드 응답을 생성함

 

 

 

해결책 2 : 아키텍처를 통한 해결, 'Hexagonal Architecture'

 

두 번째 접근은 우리 코드 내부 아키텍처를 통해 해결하는 것이었습니다.

Hexagonal Architecture가 이것에 적합하다고 생각

 

연동 API 인터페이스가 모든 문제를 해결해주진 못할 거라 생각했습니다.

여전히 인터페이스에 맞지 않는 레거시 API들도 존재했고,

앞으로 어떤 새로운 연동이 추가될지 몰랐기 때문

그래서 외부의 변화가 우리 서버의 핵심 로직(도메인)에 침투하지 못하도록 막는 구조적 안전장치가 필요하다고 판단

 

이를 위해 많은 연동 API들을 각기 다른 out Port로 추상화하여 Hexagonal Architecture를 적용했고,

멀티 모듈을 적용하여 의존성 방향을 엄격하게 강제함

 

 

Hexagonal Architecture 적용 이후에는 연동 부서에서 API 응답을 변경하거나 혹은 연동해야 하는

API 자체가 달라지더라도 infrastructure 모듈만 수정하여 in Port 인터페이스에만

맞추면 기존 도메인 로직은 변경할 필요 없이 로직을 지켜낼 수있었다.

도메인 로직의 재사용성을 높이면서도, 외부 세계의 변동에 대해 빠르게 대응할 수 있을 것이라는 기대감

 

 

문제점

가장 근본적인 문제는, 두 개의 해결책이 서로의 존재 이유를 약화시킨다는 점

애초에 연동 부서의 변경으로부터 독립되는 문제를 ‘연동 API 인터페이스’라는 프로세스로 해결하고 있었기 때문에, Hexagonal Architecture를 적용해도 코드 구조를 통해 얻는 효용이 크게 떨어짐

이미 연동 인터페이스가 외부 변화를 막아주는 훌륭한 방파제 역할을 하고 있었기 때문에

헥사고날 아키텍처의 핵심인 ‘도메인 로직 보호’라는 장점이 퇴색됨

보호해야 할 대상이 이미 다른 방식으로 보호받고 있었던 것

 

 

애매한 도메인에 대한 정의

이러한 모순은 ‘도메인’의 정의를 애매하게 만들었습니다.

홈 서버의 핵심 비즈니스 로직은 사실상 ‘외부 데이터를 조합하여 SDUI에 맞게 렌더링하는 것’이었습니다.

즉, 순수한 의미의 독립적인 도메인 모델이라기보다는 외부 데이터를 ‘활용’하고 ‘보여주는’ 로직에 가까웠음

결국 보호해야 할 핵심 도메인이 명확하지 않으니, Hexagonal Architecture의 존재 이유도 점차 희미

 

 

 

모호한 레이어 간 경계

핵심 도메인이 애매하다 보니, 자연스럽게 Port와 Adapter의 경계도 모호해지기 시작

ut Port의 인터페이스는 무엇을 기준으로 만들어야 할까요?

결국 ‘지켜내야 할 도메인’이 없으니, 기존에 연동하던 WebClient의 응답을 기준으로 Port를 작성

이는 외부 세계(infrastructure)의 구현이 내부의 인터페이스(domain)를 정의하는 주객전도 현상을 낳음

 

 

 

신규 기능 개발의 비효율성

신규 기능의 개발은 곧 전체 레이어에 대한 변경을 의미

◾ 도메인 레이어에 로직 추가/변경
◾ 도메인 레이어에서 사용할 수 있는, 사용할 out/in Port 인터페이스 추가/변경
◾ 해당 Port들의 인터페이스에 맞춘 Adapter 개발

 

 

 

단일 in Port

카카오페이 홈 서버는 현재로선 HTTP API를 제공하는 컴포넌트 하나만 구동이 되고 있음

다시 말해 도메인이 있다고 하더라도 해당 모듈을 재사용하는 모듈이 없다는 것

따라서 도메인 모듈의 재사용성이 사실상 크게 떨어지는 것이고,

모듈을 재사용하지 못한다면 Hexagonal Architecture를 적용하는 의미도 크게 떨어진다고 판단

 

 

 

팀 온보딩 및 코드 관리 비용 증가

팀에 새로운 동료가 생길 때마다 홈 서버의 아키텍처를 설명하는 부분도 점점 어려워졌음

 Hexagonal Architecture라는 설명으로는 부족할 정도로 하는 기능에 비해

코드의 사이즈가 비대해진 나머지 하나의 기능이 어떻게 동작하는지 설명하기 위해 많은 비용

 

 

제거 과정 고려 사항

관심사 단위 패키징

단일 모듈 구조로 회귀

Port와 DTO 처리 방식 재설계

Controller와 Infrastructure간 DTO 분리 유지

 

 

 

Hexagonal Architecture, 어떤 프로젝트에 적합할까?

그런 프로젝트의 특징

◾ 도메인 모델을 확실하게 정의할 수 있는 서비스

◾ 외부 의존성이 많지 않은 서비스

◾ 코어 모듈을 사용하는 모듈이 2개 이상인 서비스