2025-09-13 패턴과 아키텍처에 대해

백엔드 개발자 기술면접관

헥사고날 아키텍처 매력적이다. 평소에 결합도, 응집도와 변경 용이성을 주요하게 살펴보고 특정 ‘패턴’이나 ‘아키텍처’라는 틀에 가두는걸 지양하려고 했었는데 이번에 클린스프링을 수강하면서 생각이 조금 달라졌다.

프로덕트 코드의 일관된 구조와 방향성을 위해서는 ‘아키텍처’가 필요하다는걸 느꼈다.

이전에는 도메인에서의 어떤 ‘개념’이 발견되면 이 개념에 대한 ‘경계’와 ‘기준’을 세우는걸 기본으로 삼고, 객체 단위의 ‘책임’을 중심으로 설계에만 집중했었다. 나름대로 고민을 많이 하는 터라, 분명 응집도 높고 깔끔한 코드이긴 했다만 어느순간 처음 생각했던 객체의 ‘경계’가 조금 모호해지거나 ‘도메인 관심사’와 ‘기술 관심사’가 명백히 구분되지 않는 상황들에 대해 어떻게 구조를 가져가야 할지 판단이 서질 않았다.

즉, 어떤 경우에는 ‘도메인 관심사’에 가깝다고 판단하고 도메인 레이어에 두고, 어떤 경우에는 ‘기술 관심사’라고 판단하고 인프라 레이어에 두는 등 일관된 기준이 없었다.

그런데 이를 ‘헥사고날 아키텍처 컴포넌트들의 역할/책임’에 따라 판단할 수 있을 것 같다.

도메인 서비스로 바라봐야 하는지 혹은 어플리케이션 서비스로 바라봐야 하는지 라던가, 비즈니스 정책/규칙을 담고있으니 도메인 서비스로 바라보되, 이 정책/규칙을 구현하는 건 기술적인 요소에 해당하니 어댑터로써 구현한다던지.

클린스프링을 수강하면서 헥사고날 아키텍처의 기본적인 감을 잡고 딱 들어맞지 않는 상황(위의 예시)에는 어떻게 바라볼 수 있을지에 대한 유연한 관점도 함께 배웠다.