JPA N+1 문제 완전 정복 — 재현부터 Fetch Join, Batch Size까지

JPA N+1 문제. 잘 돌아가던 API가 데이터가 쌓이자 갑자기 느려졌다면, 십중팔구 N+1이다. 왜 생기는지, 어떻게 찾는지, 그리고 Fetch Join·EntityGraph·Batch Size로 어떻게 잡는지를 쿼리 로그와 함께 정리한다.

---

들어가며

JPA를 쓰다 보면 코드는 깔끔한데 성능이 이상하게 안 나오는 순간이 온다.
분명 회원 목록을 한 번 조회했을 뿐인데, 로그를 보면 쿼리가 수십, 수백 개가 나간다. 이게 바로 N+1 문제다.

N+1은 조용하다. 개발 DB에 데이터가 몇 건 없을 땐 멀쩡하다가, 운영에서 데이터가 쌓이면 그제야 터진다.
DB 인덱스 글에서 "개발 DB의 작은 데이터로 판단하지 말라"고 했는데, N+1이 딱 그런 경우다.

N+1은 버그가 아니라 "의도대로 동작하는데 느린" 문제다. 그래서 더 놓치기 쉽다.

이 글에서는 N+1을 직접 재현하고, 탐지하고, 세 가지 방법으로 해결한다. 예시는 Spring Data JPA / Hibernate 기준이다.

---

N+1 문제란

연관관계가 있는 엔티티를 조회할 때, 연관 데이터를 가져오려고 추가 쿼리가 N번 더 나가는 현상이다.
처음 1번(목록 조회) + 연관 데이터 N번 = "N+1".

회원(Member)과 팀(Team)이 있다고 하자. 회원은 하나의 팀에 속한다.

@Entity
public class Member {
    @Id @GeneratedValue
    private Long id;
    private String username;

    @ManyToOne(fetch = FetchType.LAZY)   // 지연 로딩
    @JoinColumn(name = "team_id")
    private Team team;
}

@Entity
public class Team {
    @Id @GeneratedValue
    private Long id;
    private String name;

    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();
}

---

1. N+1 재현하기

회원 전체를 조회하고, 각 회원의 팀 이름을 출력하는 평범한 코드다.

List<Member> members = memberRepository.findAll();   // 쿼리 1번

for (Member member : members) {
    // member.team은 LAZY → 실제 접근하는 순간 쿼리 발생
    System.out.println(member.getTeam().getName());   // 회원 수만큼 쿼리
}

실행되는 SQL을 보면 문제가 드러난다.

-- 1. 회원 전체 조회 (1번)
SELECT * FROM member;

-- 2. 각 회원의 팀을 조회 (회원이 100명이면 100번!)
SELECT * FROM team WHERE team_id = 1;
SELECT * FROM team WHERE team_id = 2;
SELECT * FROM team WHERE team_id = 3;
-- ... 100번 반복

회원이 100명이면 쿼리가 1 + 100 = 101번 나간다. 데이터가 늘수록 쿼리도 선형으로 늘어 성능이 무너진다.
지연 로딩(LAZY)된 연관 객체에 루프 안에서 접근하는 게 전형적인 패턴이다.

---

2. N+1 탐지하기

해결보다 먼저, 지금 쿼리가 몇 번 나가는지 눈으로 봐야 한다. 가장 간단한 방법은 SQL 로그를 켜는 것이다.

# application.yml
spring:
  jpa:
    show-sql: true              # 실행 SQL 출력
    properties:
      hibernate:
        format_sql: true        # 보기 좋게 정렬
logging:
  level:
    org.hibernate.SQL: debug

더 정확하게 보려면 p6spy 라이브러리를 쓰면 실제 바인딩된 값까지, 쿼리 실행 횟수까지 한눈에 보인다.

// build.gradle.kts
implementation("com.github.gavlyukovskiy:p6spy-spring-boot-starter:1.9.1")

테스트 코드로 쿼리 수를 검증해두면, 나중에 누가 N+1을 다시 만들었을 때 바로 잡힌다.

@Test
void N플러스1_검증() {
    List<Member> members = memberRepository.findAll();
    members.forEach(m -> m.getTeam().getName());
    // 쿼리 로그를 보고 1번만 나가는지 확인
}

---

3. 해결법 1: Fetch Join

가장 직접적인 해법. JPQL에서 JOIN FETCH를 쓰면 연관 엔티티를 한 번의 쿼리로 함께 가져온다.

public interface MemberRepository extends JpaRepository<Member, Long> {

    @Query("SELECT m FROM Member m JOIN FETCH m.team")
    List<Member> findAllWithTeam();
}

실행되는 SQL은 단 한 번이다.

-- JOIN으로 회원과 팀을 한 번에 조회
SELECT m.*, t.*
FROM member m
JOIN team t ON m.team_id = t.id;

101번이 1번으로 줄었다. ToOne 관계(@ManyToOne, @OneToOne)에서는 fetch join이 가장 깔끔한 해법이다.

---

4. 해결법 2: @EntityGraph

Fetch Join을 JPQL 없이 어노테이션으로 선언하는 방법이다. 메서드 이름 기반 쿼리에도 붙일 수 있어 편하다.

public interface MemberRepository extends JpaRepository<Member, Long> {

    @EntityGraph(attributePaths = {"team"})   // team을 함께 로딩
    List<Member> findAll();

    @EntityGraph(attributePaths = {"team"})
    List<Member> findByUsername(String username);
}

동작은 fetch join과 같다(내부적으로 left outer join). JPQL을 따로 쓰기 싫고 연관관계만 즉시 로딩하고 싶을 때 간편하다.
복잡한 조건이 붙으면 fetch join이 더 유연하다.

---

5. 해결법 3: Batch Size

컬렉션(@OneToMany)을 다룰 때나, fetch join을 쓰기 어려운 상황에서 강력한 해법이다.
IN 절로 묶어서 N번 쿼리를 몇 번으로 줄인다.

# application.yml — 전역 설정 (권장)
spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100

이 설정 하나로, 연관 데이터를 개별 조회하는 대신 IN 절로 묶는다.

-- Batch Size 적용 전: team_id마다 따로 (N번)
SELECT * FROM member WHERE team_id = 1;
SELECT * FROM member WHERE team_id = 2;
-- ...

-- Batch Size 적용 후: IN 절로 한 번에 (N/100번)
SELECT * FROM member WHERE team_id IN (1, 2, 3, ..., 100);

팀 100개의 회원을 가져올 때, batch size가 100이면 쿼리가 100번 → 1번으로 줄어든다.
특정 엔티티에만 적용하려면 @BatchSize(size = 100)를 필드나 클래스에 붙이면 된다.

---

6. 함정: 컬렉션 Fetch Join + 페이징

여기서 많이 당한다. 컬렉션을 fetch join하면서 페이징하면 심각한 문제가 생긴다.

// 위험: 컬렉션 fetch join + 페이징
@Query("SELECT t FROM Team t JOIN FETCH t.members")
Page<Team> findAllWithMembers(Pageable pageable);

이렇게 하면 Hibernate가 경고를 띄운다.

HHH000104: firstResult/maxResults specified with collection fetch;
            applying in memory!

DB에서 페이징하지 못하고 전체 데이터를 메모리에 다 올린 뒤 잘라낸다.
데이터가 많으면 그대로 OOM(메모리 부족)으로 죽는다.
컬렉션을 fetch join하면 결과 행이 뻥튀기(카테시안 곱)되기 때문에 페이징 자체가 불가능한 것이다.

해결: 페이징이 필요한 컬렉션은 fetch join 대신 Batch Size로 푼다.

// ToOne은 fetch join, 컬렉션은 batch size에 맡긴다
@Query("SELECT t FROM Team t")   // 컬렉션은 fetch join 안 함
Page<Team> findAllTeams(Pageable pageable);
// default_batch_fetch_size 설정으로 members는 IN 절로 로딩됨

또 하나, 컬렉션을 두 개 이상 fetch join하면 MultipleBagFetchException이 터진다.
이것도 batch size로 풀어야 한다.

---

7. 언제 무엇을 쓸까

상황	권장 해법	이유
ToOne 관계 (@ManyToOne)	Fetch Join 또는 @EntityGraph	한 방 쿼리로 깔끔
컬렉션 + 페이징 없음	Fetch Join (단, 1개만)	카테시안 곱 주의
컬렉션 + 페이징 있음	Batch Size	메모리 페이징 회피
컬렉션 2개 이상	Batch Size	MultipleBagFetchException 회피
전역 기본 방어	default_batch_fetch_size	깔아두면 안전망 역할

실무에서 가장 무난한 조합은 "ToOne은 fetch join, 컬렉션은 default_batch_fetch_size" 다.
이 둘만 챙겨도 대부분의 N+1이 사라진다.

---

마치며

N+1은 JPA의 버그가 아니라, 지연 로딩이라는 편리한 기능의 그림자다.
코드는 자연스러운데 뒤에서 쿼리가 폭발한다.
그래서 핵심은 "내가 짠 코드가 실제로 쿼리를 몇 번 날리는지 보는 습관" 이다.

추천하는 순서는 이렇다.
먼저 show-sql이나 p6spy로 쿼리 로그를 켜서 N+1이 있는지 확인하고, ToOne은 fetch join, 컬렉션은 batch size로 해결한다.
그리고 default_batch_fetch_size를 전역에 깔아 안전망을 둔다.

그리고 가장 중요한 건, 운영과 비슷한 양의 데이터로 테스트하는 것이다.
N+1은 데이터가 적으면 절대 안 보인다.
DB 인덱스와 마찬가지로, 작은 개발 데이터는 거짓 안심을 준다.

---

참고 출처

• Hibernate ORM Documentation: Fetching — https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#fetching
• Spring Data JPA: Entity Graphs — https://docs.spring.io/spring-data/jpa/reference/jpa/entity-graph.html
• Vlad Mihalcea: N+1 query problem — https://vladmihalcea.com/n-plus-1-query-problem/