🐞 JPA N+1 문제 - Fetch Join & EntityGraph

1. 문제 상황

블로그에서 게시글 목록을 조회하기 위해 JpaRepository의 JPQL을 사용했다.

@Query("""
      SELECT p FROM Post p
      WHERE p.status = :status
      ORDER BY p.createdAt DESC, p.id DESC
      """)
Slice<Post> findPublishedPosts(@Param("status") PostStatus status, Pageable pageable);

실제로 실행된 SQL은 다음과 같다.

-- 1. Post 목록 조회 (1회)
Hibernate:
  select
    p1_0.id,
    p1_0.category_id,
    p1_0.content,
    -- 등등 Post 필드들
  from
    post p1_0
  where
    p1_0.status=?
  order by
    p1_0.created_at desc,
    p1_0.id desc
  fetch
    first ? rows only

-- 2. 각 Post의 Category 조회 (추가 반복)
Hibernate:
  select
    c1_0.id,
    c1_0.created_at,
    -- 등등 Category 필드들
  from
    category c1_0
  where
    c1_0.id=?
Hibernate:
  select
    c1_0.id,
    c1_0.created_at,
    -- 등등 Category 필드들
  from
    category c1_0
  where
    c1_0.id=?
-- 이하 필요한 카테고리 개수만큼 반복

게시글 목록을 조회하는 쿼리가 1회 실행된 후 각 게시글에 대해 연관된 category 데이터를 조회하는 쿼리가 반복 실행되었다. 이러한 현상을 N+1 문제라고 한다.

2. N+1 문제

N+1 문제는 최초의 단일 조회 쿼리(1번) 실행 이후 해당 쿼리 결과로 반환된 데이터와 연관된 엔티티를 조회하기 위해 추가 쿼리가 반복적으로 발생하는 성능 저하 현상을 의미한다.

JPA 환경에서 N+1 문제가 발생하는 주요 원인은 JPQL의 쿼리 변환 방식과 JPA 구현체의 연관 데이터 로딩 전략 간의 차이에 있다.

JPQL은 연관관계 매핑 정보를 기준으로 자동으로 조인을 생성하지 않으며 작성된 쿼리 구조를 기반으로 SQL을 생성한다. 그 결과 연관 데이터를 포함하지 않은 상태로 지정된 대상 테이블만 조회하는 1회의 SQL이 실행된다.

이후 JPA 구현체는 반환된 엔티티를 영속성 컨텍스트에 저장하는 과정에서 엔티티 매핑 정보와 Fetch 전략을 확인한다. 이때 연관 데이터가 아직 로딩되지 않았다면 추가적인 조회 쿼리가 발생할 수 있다.

Fetch 전략이 즉시 로딩(EAGER)으로 설정된 경우에는 연관 데이터를 즉시 조회하기 위해 추가 단건 조회 쿼리가 실행되며 지연 로딩(LAZY)으로 설정된 경우에도 비즈니스 로직에서 연관 엔티티에 실제 접근하는 시점에 개별 조회 쿼리가 발생한다.

이때 발생하는 추가 쿼리의 횟수는 영속성 컨텍스트의 상태에 따라 달라진다. JPA는 연관 엔티티 조회 시 데이터베이스에 쿼리를 전송하기 전 1차 캐시를 먼저 확인하므로 여러 엔티티가 동일한 연관 엔티티를 참조할 경우 캐시된 객체를 반환하여 쿼리 실행을 생략한다.

즉 실제 추가 쿼리는 참조하는 연관 엔티티의 고유한 개수만큼만 실행되고 최악의 경우 N번의 쿼리가 발생한다.

3. 해결 방법

1) JPQL Fetch Join (명시적 조인)

JOIN FETCH를 사용하면 SQL 레벨에서 연관 엔티티를 함께 조회할 수 있어 N+1 문제를 방지할 수 있다.

@Query("""
      SELECT p FROM Post p
      LEFT JOIN FETCH p.category
      WHERE p.status = :status
      ORDER BY p.createdAt DESC, p.id DESC
      """)
Slice<Post> findPublishedPosts(@Param("status") PostStatus status, Pageable pageable);

category가 nullable 관계이기 때문에 LEFT JOIN을 사용하였다.

2) @EntityGraph

@EntityGraph는 JPA에서 제공하는 어노테이션으로 쿼리 자체는 유지하면서 연관 엔티티의 Fetch 전략만 변경할 수 있다.

@EntityGraph(attributePaths = { "category" })
@Query("""
      SELECT p FROM Post p
      WHERE p.status = :status
      ORDER BY p.createdAt DESC, p.id DESC
      """)
Slice<Post> findPublishedPosts(@Param("status") PostStatus status, Pageable pageable);

두 방법 모두 left join이 포함된 단 한 번의 쿼리로 모든 데이터를 조회하게 된다.

Hibernate:
  select
    p1_0.id,
    c1_0.id,
    c1_0.created_at,
    -- 등등 필드들
  from
    post p1_0
  left join
    category c1_0
      on c1_0.id=p1_0.category_id
  where
    p1_0.status=?
  order by
    p1_0.created_at desc,
    p1_0.id desc

Fetch Join을 @Query에 명시적으로 작성하면 조인 타입이나 조건을 명확하게 제어할 수 있다는 장점이 있다.

하지만 현재 글 목록 조회 쿼리는 비교적 단순하기 때문에 가독성이 더 좋은 @EntityGraph를 사용하기로 결정하였다.

추가) DTO Projection

위의 두 가지 방법 외에도 엔티티를 조회하지 않고 필요한 필드만 DTO로 직접 조회하는 DTO Projection 방식을 사용할 수도 있다.

@Query("""
  SELECT new com.example.project.dto.PostResponse(
    p.id,
    p.title,
    c.name
  )
  FROM Post p
  LEFT JOIN p.category c
  WHERE p.status = :status
  """)
Slice<PostResponse> findPublishedPostDtos(
  @Param("status") PostStatus status, Pageable pageable
);

이 방식은 처음부터 필요한 필드만 JOIN하여 조회하기 때문에 N+1 문제가 발생할 여지가 없다. 또한 SELECT * 가 아니라 SELECT p.id, p.title ... 처럼 필요한 컬럼만 조회하므로 DB와 애플리케이션 간의 데이터 전송량을 줄일 수 있다.

다만 JPQL 내부에서 DTO의 전체 패키지 경로를 명시해야 하기 때문에 가독성이 다소 떨어질 수 있다. 또한 조회된 결과는 영속 상태가 아니기 때문에 값을 수정하더라도 JPA의 변경 감지(Dirty Checking)가 적용되지 않는다.