책임과 트레이드 오프 - Workaway

chaean·2025년 6월 22일

Workaway

목록 보기

8/11

게스트하우스 검색 시스템을 만들면서 "이렇게 짜는 게 맞는 구조인가?"와 같은 고민들이 깊어졌습니다.
주로 QueryDSL을 사용해보며 책임 분리에 대한 내용이 주된 내용입니다.

queryFactory
	.select(Projections.constructor(
		DTO.class,
	    ...
	)
	...

기존에는 위와 같은 방식으로 데이터를 DTO로 변환하여 데이터를 가져오는 방법이 맞다고 생각했습니다.

하지만 코드를 작성하다 보니 다음과 같은 생각이 들었습니다.

"DTO로 변환하는 것이 Repository의 책임인가?"

Join도 많고, 조건도 복잡하고, 추천 계산 식도 들어가고, DTO도 변환도 하다보니
Repository가 너무 커지는 느낌이 강했습니다.

그렇다고 반대로 Entity를 전부 가져와서 Service단에서 DTO로 바꾸는 방식도 고려해봤지만,

이는 다시 다음과 같은 생각이 들었습니다

"필요 없는 데이터도 같이 들어오고, N+1문제가 발생할 수 있지않나?"

결국 트레이드 오프에 대한 고민이었고, 기능에 따라 유연하게 설계해야 된다고 결론을 내렸습니다

상황	선택 방식	비고
단순 조회	`JPA findBy~()` + Service에서 DTO 변환	- 단순 조건, 관계 적을 때 - 구조 명확, 테스트 쉬움
복잡한 Join / 계산 / 필터링 필요	`QueryDSL + DTO 직접 매핑`	- where 조건 복잡 - 성능 최적화 가능
성능 민감 / 페이징 처리 필요	`QueryDSL에서 DTO projection` 사용 권장	- 필요한 필드만 조회 - 페이징 정확도 확보

💡 물론 예시일 뿐이며, 무조건적인 방법보단보단, 도메인, 복잡도, 성능 요구에 따라 유연하게 판단하는 것이 중요할 것입니다.

코드를 작성하며 성능에 관심이 많았던 저는 쿼리를 최소화하는 하는 것이 좋은 아키텍처라고 믿었습니다.

-- 예시 쿼리
SELECT ...
FROM 게스트하우스
LEFT JOIN 게스트하우스 이미지
LEFT JOIN 게스트하우스 리뷰
LEFT JOIN 게스트하우스 리뷰 이미지
LEFT JOIN 게스트하우스 편의시설
.
.
.

위의 예시 쿼리와 같이 약 8개의 테이블이 Join을 해야되는 상황이었습니다.

그런데 구현이 진행될 수록 다음과 같은 문제가 발생했습니다.

Join이 많아질수록 쿼리가 복잡해졌고, 첫번째 고민과 같이 필요한 필드만 추출하기 위해 DTO projection도 점점 지저분해진다
LEFT JOIN 특성상, row 수가 과도하게 증가했다.
또한 이를 해결하기 위해 중복을 제거하는 코드를 작성해야했고, 코드가 또 지저분해진다.
유지보수의 측면으로 봐도 쿼리가 거대해져 구리다는 생각을 했다..

위와 같은 상황들로 저는 아래와 같은 고민을 했습니다

"과연 쿼리 수가 적다고 좋은걸까?"

이전에는 단순 조회성 쿼리를 나누는 것을 비효율이라고 생각했지만,
AI와 여러 블로그 글을 참고하다보니 생각이 바뀌었습니다.

쿼리 수가 적다고 항상 성능이 좋은 것은 아니었습니다.
제가 찾아본 자료로는 이유가 아래와 같습니다