개발 일상 | 백엔드 김승원의 실무 노트

들어가며헥사고날 아키텍처(Hexagonal Architecture)는 Alistair Cockburn이 2005년에 제안한 아키텍처 패턴으로, 포트와 어댑터(Ports and Adapters)라고도 불립니다. 핵심 아이디어는 단순합니다: 비즈니스 로직(도메인)을 외부 기술(DB, HTTP, 메시지 큐 등)로부터 완전히 분리하는 것입니다. 이를 통해 도메인 로직은 순수하게 유지되고, 외부 기술이 변경되어도 도메인은 영향을 받지 않습니다.이 글에서는 전통적인 레이어드 아키텍처와의 비교부터, Spring Boot에서의 실제 패키지 구조 설계, 테스트 전략까지 실전적으로 다루겠습니다.왜 헥사고날 아키텍처인가?전통적인 레이어드 아키텍처의 문제// 전형적인 레이어드 아키텍처Controller → Service → ..

들어가며얼마 전 금요일 저녁, 기획자가 "주문 취소 후 환불까지 걸리는 리드타임을 절반으로 줄여달라"고 요청했습니다. 3년 동안 쌓인 OrderService 클래스를 열어보니 1,800줄이 넘었고, 환불 로직이 어느 메서드에 흩어져 있는지 파악하는 데만 20분이 걸렸습니다. 결국 수정은 2시간이었는데, "어디를 고쳐야 할지" 결정하는 데 반나절을 써야 했습니다.익숙한 장면 아닌가요? 서비스 계층은 해가 갈수록 비대해지고, 새 요구사항 하나를 넣으려면 먼저 다른 5개 메서드가 뭘 하는지 해독해야 합니다. 비즈니스 로직이 Service에 있는지 Util에 있는지, 아니면 JPA Entity의 setter 뒤에 숨어 있는지조차 불분명해집니다. 팀에 들어온 지 6개월 된 동료에게 "이 도메인 설명 좀 해달라"고..