기존 JPA로만 작업하던 프로젝트에서 QueryDSL을 추가로 적용하면서
'어떤 걸 두고, 어떤 걸 QueryDSL로 옮겨야 할까?'에 대해서 찾아봤다.
✅ QueryDSL로 옮기는 기준
- 동적 조건이 있는 조회
➡️ QueryDSL 필수!! JPQL @Query는 조건 조합이 늘어날수록 문자열 이어 붙이기 지옥이 됨. - exists, 서브쿼리, 복잡한 OR 조건
➡️ QueryDSL이 안전!! 문자열 JPQL은 실수나 리팩토링에 취약 - 페이징 + 정렬 + count 분리 필요
➡️ Page / Slice 구현: QueryDSL이 구조적으로 유리 - 다중 테이블 조인 DTO 프로젝션
➡️ QueryDSL이 컴파일 타임 타입 체크: JPQL 문자열은 필드명 오타가 런타임 에러 - 검색 조건이 계속 늘어날 가능성 있음
➡️ 초기에 단순해 보여도 앞으로 필터 추가 요청 예상되면 QueryDSL
❌ 굳이 안 옮겨도 되는 경우
- 단순 CRUD (ex. `findById`, `deleteById`, `existsById`...)
➡️ Spring Data 기본 메서드로 충분 - 단순 벌크 수정/삭제 (ex. `@Modifying @Query("delete ... where id = :id")`)
➡️ 그대로 둬도 됨 (오히려 QueryDSL 벌크는 flush/clear 직접 관리 필요) - DB 전용 기능 (CTE / window function)
➡️ QueryDSL-JPA는 표현 못함. JDBC / native SQL 유지가 더 낫다. - 절대 안 변할 정적 쿼리 (ex. “활성 Y 데이터 전부 조회”)
➡️ `@Query` 하나로 끝나고 끝까지 안 변하면 유지
찾아본 결과 이렇게 정리했다.
이대로 팀 개발 가이드 문서나, 개인 프로젝트 시 참고하면 좋을 것 같다!
'Backend > Spring' 카테고리의 다른 글
| [Gradle] implementation, api 선언 (0) | 2026.01.22 |
|---|---|
| [Spring Data JPA] Stream Filter 후 Page로 변환하기 (0) | 2025.05.23 |
| [Spring Data JPA] 페이징(Pageable)과 정렬(Sort) 한 번에 처리하기 (0) | 2025.04.30 |