2026.05.08
Hibernate 설정을 통해서 컬렉션 또는 연관된 엔티티들을 배치로 로딩할 수 있게 해주는 기능 (LAZY 로딩이더라도 미리 설정된 개수만큼 한 번에 불러와줌.)
LAZY 전략을 유지하면서도 IN 절을 활용한 일괄 조회 가능
① 글로벌 설정 (application.yml)
spring:
jpa:
properties:
hibernate:
default_batch_fetch_size: 100
② 개별 설정 (엔티티 또는 컬렉션 필드)
@OneToMany(mappedBy = "user", fetch = FetchType.LAZY) // ← 지연 로딩!
@BatchSize(size = 100)
private List<Post> posts = new ArrayList<>();
| 항목 | 주의할 점 |
|---|---|
BatchSize 크기 | 너무 작으면 효과 미미, 너무 크면 IN 쿼리가 길어져 성능 저하 가능 |
| Fetch Join과 병행 사용 | 컬렉션 Fetch Join과 함께 쓰면 안 됨 (예: 페이징 깨짐) |
LAZY 유지 조건 | 이 설정은 LAZY인 경우에만 유효함 |
Spring Data JPA에서 지원하는 기능, 연관관계를 JPQL 없이 즉시 로딩 하도록 지정 가능
장점 : JPQL 없이 선언적 방식으로 해결 가능 (내부적으로 fetch join 실행)
단점 : 동적 제어 어려움, 복잡한 쿼리는 한계 존재
| 방식 | 특징 | 페이징 가능 | JPQL 필요 | 실무 활용 |
|---|---|---|---|---|
| Fetch Join | 빠르고 직관적 | ✖ (컬렉션 제한) | O | O (조회 성능 빠름) |
| BatchSize | Lazy 유지 + | |||
| IN 조건으로 개선 | ⭕ | ✖ | O (간편 설정) | |
| EntityGraph | 선언적 설정 | ✖ (컬렉션 제한) | ✖ (Spring Data 지원) | △ (단순 관계에 유리) |
DB에서 원하는 컬럼만 선택하여 DTO로 직접 매핑하는 방식
장점 : 필요한 데이터만 조회, 불필요한 연관 로딩 방지
단점 : 엔티티가 아님 → 변경 감지 불가, 복잡한 로직 포함 어려움
버그는 작성 직후 잡을 수록 고치기 쉬움.
테스트는 즉시 실행되므로 문제를 빠르게 확인 가능
QA 단계로 넘어가기 전 대부분의 에러 차단
테스트는 코드 리팩토링의 안전망
기존 코드에 대한 신뢰 확보
“이전 기능이 깨지지 않았다”를 자동으로 증명
테스트는 커뮤니케이션의 언어
코드 리뷰 시 “이 로직이 이런 동작을 해야 한다”를 코드로 보여줄 수 있음.
새 팀원이 들어와도 “테스트 통과”를 기준으로 안정성 보장