아키텍처 관점에서 Repository 계층의 접근 범위에 대한 고민 (2025년 6월 15일)

2025년 6월 15일의 고민 노션에서 옮겨오고 있습니다.

 

고민

 

최근 데이터엑세스 코드를 수정하면서 레포지토리 계층에서 DTO나 인터페이스에 접근하는 것이 아키텍처에 어긋나는지 고민에 빠졌다. 일반적으론 Repository에서 바로 비즈니스 로직을 거치지않고 바로 DTO에 접근하는 것은 맞지 않다고 느껴진다. 하지만 그건 JPA의 관점이 아닌가? 마이바티스는 일반적으로 바로 DTO에 접근하는데? JPA의 더티체킹에 익숙해져서 서비스 -> 엔티티 -> 레포지토리 구조에 빠져버린건가?

 

특히 QueryDSL의 프로젝션 기능을 사용하면 복잡한 조회 쿼리도 깔끔하게 DTO로 매핑할 수 있는데, 이런 경우에도 아키텍처 원칙 때문에 포기해야 하나 하는 고민이 들었다. 같은 애플리케이션에서 기술에 따라 다른 패턴을 사용하는게 맞는것인가? 결과적으로는 같은 데이터를 반환하는데 이렇게 고민할 필요가 있는건지 아키텍처를 지키기위해 JDBC Template으로 바꿀까라는 생각도 했는데 생각해보니 기술을 바꿔도 결국 레포지토리에서 DTO를 반환하는 건 똑같다. 기술을 바꾸는 것보다는 아키텍처 접근 방식을 다시금 생각해 보아야하나..?

---

해결

 

아키텍처는 목적이 아니라 수단이다. 완벽한 아키텍처를 위해 개발 생산성을 희생할 필요는 없다.

CQRS 패턴을 이용하면 아키텍처 원칙을 지키면서 실용성도 가질 수 있다. 명령과 조회의 책임을 분리함으로서 조회 전용은 DTO 반환을 허용하고 도메인 로직용은 엔티티를 반환하는 것이다.

 

그럼 기술별 일관성을 유지할 수 있게 된다. 기술에 반환값을 의존하게 되지 않고 비즈니스 요구사항이 반환 타입을 결정하기 때문이다. JPA로 프로젝션을 활용해서 DTO 반환도 좋고 마이바티스로 DTO반환도 좋다 JDBC Template또한 동일하다.

 

아키텍처를 지키는 것도 중요하지만, 생산성과 실용성 사이에서 저울질을 해야한다는 것을 깨달았다.