JPA N+1 문제의 발생 원인과 해결 방법
한 줄 답변
N+1 문제는 연관 관계가 설정된 엔티티 조회 시 조회된 데이터 개수(N)만큼 추가 쿼리가 발생하는 성능 문제입니다. JPQL의 동작 방식 때문에 발생하며, Fetch Join이나 Batch Size 설정을 통해 쿼리를 최적화하여 해결할 수 있습니다.
핵심 개념 정리
JPA N+1 문제는 1:N 또는 N:1 관계에서 부모 엔티티를 조회한 후, 연관된 자식 엔티티에 접근할 때마다 추가적인 SELECT 쿼리가 발생하는 현상을 말합니다. 예를 들어 10명의 회원을 조회했는데, 각 회원의 주문 내역을 확인하기 위해 10번의 추가 쿼리가 실행되어 총 11번(1+10)의 쿼리가 나가는 상황이 대표적입니다.
이 문제가 발생하는 근본적인 이유는 JPQL이 엔티티 객체를 대상으로 쿼리를 생성하기 때문입니다. JPQL은 우선 해당 엔티티만을 조회하는 SQL을 생성하여 실행합니다. 이후 영속성 컨텍스트에서 연관된 객체를 찾는데, 만약 데이터가 로딩되어 있지 않다면(지연 로딩) 객체에 접근하는 시점에 개별적으로 쿼리를 날리게 됩니다. 즉, 즉시 로딩(Eager)이나 지연 로딩(Lazy) 설정과 관계없이 로직에 따라 발생할 수 있습니다.
실무에서 이 문제를 방치하면 데이터 양이 늘어남에 따라 데이터베이스에 가해지는 부하가 기하급수적으로 증가하며, 결국 서비스 전체의 응답 속도가 저하됩니다. 따라서 단순히 FetchType을 변경하는 수준이 아니라, 비즈니스 로직에 맞춰 쿼리 한 번으로 데이터를 가져오는 최적화 전략을 설계하는 것이 백엔드 개발자의 핵심 역량 중 하나입니다.
비교 정리
| 항목 | Fetch Join (페치 조인) | Batch Size (배치 사이즈) |
|---|---|---|
| 쿼리 효율성 | 한 번의 조인 쿼리로 모든 데이터 로딩 (최적) | N번의 쿼리를 IN 절을 사용하여 1번으로 병합 |
| 페이징 처리 | 1:N 관계에서 사용 시 페이징 불가능 (위험) | 페이징 쿼리와 완벽하게 호환되어 안전함 |
| 중복 데이터 | 조인 결과에 따라 데이터 중복 발생 가능 (Distinct 필요) | 필요한 데이터만 로딩하므로 중복 문제 없음 |
| 복합 관계 | 둘 이상의 컬렉션 페치 조인 시 예외 발생 위험 | 여러 컬렉션이 있어도 각각 설정 수만큼 최적화 가능 |
면접에서 이렇게 답하세요
면접에서는 단순히 '페치 조인을 씁니다'라고 답하기보다, 'JPQL이 DB SQL로 번역되는 과정에서 발생하는 한계'를 먼저 언급하세요. 그 다음, 조회 성능을 위해 기본적으로는 페치 조인을 사용하되, 1:N 관계의 페이징 문제나 둘 이상의 컬렉션을 로딩해야 하는 상황에서는 Batch Size 설정을 통해 성능과 안정성을 모두 챙긴다는 실무적 관점을 덧붙이면 매우 좋은 인상을 남길 수 있습니다.
자주 묻는 추가 질문
Q. FetchType.LAZY로 설정하면 N+1 문제가 안 생기나요?
아니오. 지연 로딩은 쿼리 시점을 늦출 뿐, 결국 루프 등을 통해 자식 객체를 사용하는 시점에 N번의 추가 쿼리가 나가는 것은 동일합니다.
Q. EntityGraph와 Fetch Join의 차이는 무엇인가요?
Fetch Join은 JPQL에 직접 작성하며 Inner Join을 주로 사용하고, EntityGraph는 어노테이션 기반으로 설정하며 기본적으로 Left Outer Join을 수행합니다.
Q. Batch Size의 적절한 크기는 어느 정도인가요?
보통 100~1000 사이를 권장합니다. 1000 이상은 DB에 따라 지원하지 않거나 CPU 부하가 커질 수 있으므로 환경에 맞는 벤치마킹이 필요합니다.
커뮤니티 하이라이트
“페이징 할 때 Fetch Join 쓰다가 OutOfMemory 경험해보신 분들은 Batch Size의 소중함을 잘 알죠. 꼭 같이 언급하세요.”
“Querydsl을 사용한다면 fetchJoin() 메서드로 훨씬 가독성 있게 작성할 수 있다는 점도 실무 팁으로 좋습니다.”
42명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.