DTO와 의존성, 계층의 분리에 대한 고민

정재익 2025. 8. 15. 14:00

모놀리식아키텍처는 컨트롤러 비즈니스 레포지터리의 계층을 나누고 계층간의 이동은 DTO로 변환해서 관리한다.

이것은 엔티티는 영속성에 종속되어있고 이것을 계층간에 전달하게 되면 강한결합을 유발하기 때문이다. 순수한 비즈니스로직을 영속성에 오염시킬 수 있고 보안 문제의 예방도 있다. 종합하자면 단일원칙책임을 준수하기위해서 DTO를 활용한다고 볼 수 있다.

하지만 헥사고날아키텍처에서는 외부세계 (어댑터)밖으로 나가기 직전에 DTO로 변환시키고 그 이전엔 엔티티를 활용한다.

이것은 도메인 모델과 영속성 분리의 완벽한 분리를 추구하기 때문이다. 엔티티는 JPA나 외부기술의 영향을 받지않는 가장 순수한 계층이다. 헥사고날에서의 DTO는 도메인과 외부 세계를 연결하는 계약의 역할을 한다.

이때! 엔티티는 가장 순수하다고 했지만 엔티티 자체가 JPA의 영향을받아 만드는순간 영속성 컨텍스트에 들어가지않나? 즉 영속성의 영향을 받는것이다

JPA를 외부세계로 구분하였지만 결국 기술상 엔티티를 구현하는순간 외부세계와 이어진다. 그렇다면 포트간의 엔티티를 교환하는 행위는 각 도메인의 로직들을 영속성에 종속시키는 즉 오염시키는 행위아닌가? 이미 오염됐는데 외부세계(클라이언트) 로 반환값을 보내기 직전에 DTO를 사용한들 무슨 소용인걸까? 헥사고날도 각 포트간에 DTO로 교환해야 순수한 단일책임을 유지할 수 있는게 아닐까?

해결

나의 고민은 JPA엔티티와 도메인의 엔티티를 동일시한 착오에서 시작되었다.

이상적인 헥사고날에서는 어떠한 기술에도 종속되지않은 엔티티 클래스를 하나 더 만들고 이것을 주고받으며 소통한다.

그럼 앞선 오염문제들이 전부 해결된다. 다만 기존의 나의 방식도 잘못된것은 아니다. 두개의 클래스를 만드는건 모든 로직에대한 오염을 완전히 해소시켜주지만 구현이 복잡해지고 작업량이 상승한다. 크지않은 프로젝트에는 굳이 이렇게 하지않고 절충안을 택할때도 있다.

절충안이란 JPA엔티티를 도메인 모델로 활용하되 외부로나갈때만 DTO로 변환시키는것이다. 지금까지 완벽을 최대한 지키려하면서 아키텍처 변환작업을 하였고 완벽을 추구하기위한 트레이드오프를 몸소체감했다.

당장 도메인을 분리시켜 새로운 서버로 띄워야하는 상황이아니라면 절충안이 나을 수 있다. 테스트코드는 이미 헥사고날 변환으로 인해 상당히 가벼워졌으며 엔티티 클래스를 굳이 더 안만들어도 충분하다고 생각한다.

완벽을 추구하기보다 현 상황에 맞는 트레이드오프를 잘 계산해야한다고 생각한다. 이론은 이론이고 완벽은 이상이다. 현실에서는 수 많은 경우가있고. 좋은 개발자란 애플리케이션을 만들고 그것이 매끄럽게 작동하도록 만들어주는 사람이다. 개발이 이론과 기술을 선택하는것이지 이론과 기술 그리고 이상에 개발이 종속되어서는 안된다.