기존 JPA로만 작업하던 프로젝트에서 QueryDSL을 추가로 적용하면서

'어떤 걸 두고, 어떤 걸 QueryDSL로 옮겨야 할까?'에 대해서 찾아봤다.

 

✅ QueryDSL로 옮기는 기준

  1. 동적 조건이 있는 조회
    ➡️ QueryDSL 필수!! JPQL @Query는 조건 조합이 늘어날수록 문자열 이어 붙이기 지옥이 됨.
  2. exists, 서브쿼리, 복잡한 OR 조건
    ➡️ QueryDSL이 안전!! 문자열 JPQL은 실수나 리팩토링에 취약
  3. 페이징 + 정렬 + count 분리 필요
    ➡️ Page / Slice 구현: QueryDSL이 구조적으로 유리
  4. 다중 테이블 조인 DTO 프로젝션
    ➡️ QueryDSL이 컴파일 타임 타입 체크: JPQL 문자열은 필드명 오타가 런타임 에러
  5. 검색 조건이 계속 늘어날 가능성 있음
    ➡️ 초기에 단순해 보여도 앞으로 필터 추가 요청 예상되면 QueryDSL

 

❌ 굳이 안 옮겨도 되는 경우

  1. 단순 CRUD (ex. `findById`, `deleteById`, `existsById`...)
    ➡️ Spring Data 기본 메서드로 충분
  2. 단순 벌크 수정/삭제 (ex. `@Modifying @Query("delete ... where id = :id")`)
    ➡️ 그대로 둬도 됨 (오히려 QueryDSL 벌크는 flush/clear 직접 관리 필요)
  3. DB 전용 기능 (CTE / window function)
    ➡️ QueryDSL-JPA는 표현 못함. JDBC / native SQL 유지가 더 낫다.
  4. 절대 안 변할 정적 쿼리 (ex. “활성 Y 데이터 전부 조회”)
    ➡️ `@Query` 하나로 끝나고 끝까지 안 변하면 유지

 

찾아본 결과 이렇게 정리했다.

이대로 팀 개발 가이드 문서나, 개인 프로젝트 시 참고하면 좋을 것 같다!

+ Recent posts