레이어드 아키텍처와 클린 아키텍처 비교
처음 스프링 프로젝트를 진행할때, 당연한듯이 레이어드 아키텍처(Layered Architecture)로 개발을 진행했다. JPA 객체와 연동하여 Repository를 구성하고 서비스 아이디어에 걸맞는 Service 로직을 구성하고 로직에 대한 반환을 유연하게 전달하도록 DTO를 구성하였으며, 요청에 대한 응답을 Controller로 처리하였다. 아무래도 지금까지 진행해보았던 프로젝트들은 서로 간의 의존성을 많이 나눌정도로 기능이 복잡하지 않았고, 기능 클래스들이 서로 엮이지도 않았다. 더 극명하게 관리하고자하는 일도 없었으며 크게 레이어드 구조상에서 내가 개선해야할 부분이나 유지보수성을 올릴 이유가 없었다. 그러던중, F-lab 세미나 도중 클린 아키텍처를 접하게 되었고, 작년 과제테스트에서도 Hexagonal Architecture 구조를 유지하여 개발하라는 요청을 받은적이 있다. 그래서 나는 클린 아키텍처를 찾아보았고, 만들면서 배우는 클린 아키텍처라고 하는 좋은 서적을 발견해 실습을 진행해보았다. 그리고 클린아키텍처를 적용한 프로젝트 레포지토리들을 깃허브에서 뒤적여보기도 했다..(정말 최저의 결합도를 유지하게 된다는 느낌을 받았다.)
결론적으로, 로버트 마틴은 레이어드 아키텍처와 육각형 아키텍처 적절한 사용을 어떻게 생각할까? 궁금했고, 블로그 글을 찾아 정리해보았다.
로버트 마틴이 말하는 육각형 아키텍처는 어떤 상황에서 사용하는게 적절할까? 레이어드 아키텍처와의 장단점 및 차이점은 무엇인가?
로버트 마틴은 클린 아키텍처에서 육각형 아키텍처(Hexagonal Architecture, 포트와 어댑터 패턴)의 원칙을 강조하며, 비즈니스 로직이 외부 기술(데이터베이스, 웹, 외부 API 등)에 의존하지 않도록 설계하는 것을 권장한다.
어떤 상황에서 육각형 아키텍처를 사용하는 것이 적절한가?
비즈니스 로직이 외부 기술에 의존하지 않게 하고 싶을때, 여러 종류의 입력(웹, 메시지 큐, CLI등) 또는 출력(DB, 외부서비스, 파일 등)이 존재하거나, 앞으로 추가될 가능성이 있을때, 테스트 용이성, 유지보수성, 확장성을 높이고 싶을 때, 외부 컴포넌트 (데이터베이스, API 클라이언트 등 )를 쉽게 교체하거나 확장하고 싶을 때, 마이크로서비스, 이벤트 기반 시스템 등에서 유연한 아키텍처가 필요할 때
육각형 아키텍처와 레이어드 아키텍처의 차이점
| 구분 | 레이어드 아키텍처(Layered Architecture) | 육각형 아키텍처(Hexagonal Architecture) |
|---|---|---|
| 구조 | 계층(레이어) 기반(프레젠테이션, 비즈니스, 데이터) | 도메인 중심, 포트와 어댑터로 외부와 연결 |
| 의존성 방향 | 상위 계층 → 하위 계층(단방향) | 도메인(핵심) ← 어댑터(외부) 의존성 역전 |
| 외부 기술 의존성 | 비즈니스 로직이 데이터베이스 등에 의존 | 비즈니스 로직이 외부 기술에 의존하지 않음 |
| 유연성/확장성 | 낮음(계층 간 결합도 높음) | 높음(포트와 어댑터로 외부 컴포넌트 교체 용이) |
| 테스트 용이성 | 낮음(외부 의존성 때문에 테스트 어려움) | 높음(외부 기술을 목(Mock)으로 대체 가능) |
| 적합한 상황 | 단순한 모놀리식, 빠른 개발, 익숙한 구조 | 복잡한 시스템, 마이크로서비스, 유지보수성 중시 |
| 구현 난이도 | 쉬움 | 복잡함(포트와 어댑터 설계 필요) |
장단점
육각형 아키텍처은 비즈니스 로직이 외부 기술에 의존하지 않아서 순수하게 유지된다. 외부 컴포넌트(DB, API등)를 쉽게 교체할 수 있다. 테스트가 쉬워진다.(외부 의존성을 목(Mock)으로 대체 가능하다) 확장성, 유지보수성이 높다. 반면, 구현이 더 복잡하고 설계에 신경 써야 한다. 작은 시스템에서는 오버엔지니어링이 될 수 있다.
레이어드 아키텍처는 구조가 단순하고 익숙하다. 빠른 개발이 가능하다. 많은 개발자들이 알고 있다. 반면, 비즈니스 로직이 외부 기술에 의존하게 되어 유지보수와 테스트가 어렵다. 계층 간 결합도가 높아 외부 컴포넌트 교체가 어렵다.
따라서, 육각형 아키텍처는 비즈니스 로직을 외부 기술로부터 보호하고, 유연성과 테스트 용이성을 높이고 싶을 때 적합하다. 레이어드 아키텍처는 구조가 단순하고 빠른 개발이 필요할 때 적합하다. 로버트 마틴은 비즈니스 로직이 외부 기술에 의존하지 않도록 설계하는 것이 중요하다고 강조하며, 육각형 아키텍처(포트와 어댑터)를 권장한다.
그렇다면
로버트 마틴은 포트와 어댑터 아키텍처를 단순한 외부 API 연동과 CRUD 기능만 있는 애플리케이션에 대해 마틴이 이 아키텍처르 반드시 사용하라고 명시적으로 권장하는지 찾아보니, 명확하지는 않다. 실제로 여러 커뮤니티에서는 그러할때 오버엔지니어링이 될 수 있다고 지적하기도 한다. 마틴 역시 클린 아키텍처에서 강조했지만, 실제로는 프로젝트의 복잡성, 변화 가능성, 유지보수성 요구에 따라 적절한 아키텍처를 선택해야 한다는 점을 암시하고 있다.
이러한 경우에는 오히려 레이어드 아키텍처가 더 적합할 수 있다.