[Java] ORM의 N+1 문제

📝 N+1 구현 자료 GitHub

GitHub - castle-bird/castle-bird-lab: 마주한 이슈들을 해결하고 기록하는 곳

 

---

1. N+1이란?

• JPA와 같은 ORM(객체 관계 매핑) 기술에서 발생하는 성능 문제
• 하나의 쿼리(1)를 실행했을 때 연관된 객체를 불러오기 위해 N개의 추가 쿼리가 반복적으로 실행
  • 데이터베이스 부하와 성능 저하를 야기 ⭐
• @ManyToOne(fetch = FetchType.LAZY)의 게으른 로딩시 문제가 발생.

---

2. N+1의 원인 및 코드

연관된 엔티티를 불러올 때 지연 로딩(Lazy Loading) 전략으로 인해, 첫 쿼리 이후 각 데이터마다 추가 쿼리가 발생.

📝발생 코드 (상단 GitHub에서 자세히 확인 가능 ⭐)

@Entity
@Table(name = "tbl_food")
public class Food {
    // ... 필드

    // 부모 엔티티 참조 중. (Foreign Key)
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id")
    private Category category;
}

@Entity
@Table(name = "tbl_category")
public class Category {
    // ... 필드

    // 자식 엔티티에 참조 되는 중.
    @OneToMany(mappedBy = "category")
    private List<Food> foods;
}

@RequiredArgsConstructor
@Service
public class MenuService {

    private final FoodRepository foodRepository;

    // ========== 서비스 로직 ==========
    public List<FoodDTO> findAll() {
        // 1. 이때 까진 카테고리 내용이 없는 순수 Food의 내용만 담겨있음
        List<Food> foods = foodRepository.findAll();

        // 2. 그러나 DTO변환시 convertToDTO내부 코드로인해 N + 1 발생 중!
        return foods.stream()
                .map(this::convertToDTO)
                .toList();
    }

    // ========== 엔티티 -> DTO ==========
    public FoodDTO convertToDTO(Food food) {

        // 3. CategoryId, CategoryName에 접근 안한채 DTO 변환 시 N+1 발생 안함
        FoodDTO foodDTO = FoodDTO.builder()
                .id(food.getId())
                .foodName(food.getFoodName())
                .price(food.getPrice())
                .build();

        // 4. 이때 문제 발생.
        //  findAll()의 1번에서 확인했듯이 최초에는 Category를 조회하지 않았음.
        //  그러나 현재 getCategory()에 접급하는 순간 없던 Category를 조회하기 위해 추가 쿼리가 발생
        if (food.getCategory() != null) {
            foodDTO.setCategoryId(food.getCategory().getId());
            foodDTO.setCategoryName(food.getCategory().getCategoryName());
        }

        return foodDTO;
    }
}

 

위 코드 처럼 N+1이 발생 했을때 아래 이미지와 같이 최초 조회 이후에도 여러번의 쿼리가 발생하는 것을 알 수 있음.

N+1 발생

---

3. N+1의 해결법

3-1. Fetch Join

• "모든 데이터를 한 방에 가져오기"
• JPQL을 사용하여 조회 시점에 연관된 데이터를 강제로 조인(Join) 하여 단 한 번의 쿼리로 가져온다.
• INNER JOIN 기준으로 가져옴 ⭐

// JPQL 
@Query("SELECT f FROM Food f JOIN FETCH f.category")
List<Food> findAllJPQL();

JPQL로 N + 1 해결

 

3-2. EntityGraph

• "가져올 목록을 미리 체크리스트로 전달하기"
• JPQL을 직접 작성하는 것이 번거로울 때 사용하는, JPA 표준 스펙인 어노테이션 기반 기능.
• LEFT JOIN 기준으로 가져옴 ⭐

// @EntityGraph
@Override
@EntityGraph(attributePaths = {"category"})
List<Food> findAll();

@EntityGraph로 N+1해결

 

3-3. Batch Size

• "데이터를 묶음 배송으로 가져오기"
• 위의 두 방법이 쿼리를 '1번'으로 줄이는 방법이라면, Batch Size는 N번의 쿼리를 매우 많이 줄이는 방식.
• 연관된 데이터를 조회할 때 IN 쿼리를 사용하여 설정한 개수만큼 모아서 조회.
• 만약 Batch Size를 100으로 설정한다면 연관된 데이터 조회 쿼리시(N번 조회), 100개씩 묶음으로 조회.

// application.yml
spring:
  jpa:
    properties:
      hibernate:
        default_batch_fetch_size: 100

Batch Size로 N+1해결

---

4. N+1은 무조건 없애야 하는 과제일까?

N+1 문제를 유발할 수 있는 @ManyToOne(fetch = FetchType.LAZY) 설정이 무조건 나쁜 것은 아니다.
핵심은 기능의 구현과 성능의 최적화 사이에서 적절한 합의점을 찾는 것이다.

1) 왜 지연 로딩(LAZY)을 기본으로 쓰는가?

• 불필요한 리소스 낭비 방지: 사용자가 확인하지도 않을 데이터까지 한꺼번에 조회하는 것은 DB와 메모리에 큰 부담.
• 예측 가능성: 즉시 로딩(EAGER)은 어디서 어떤 쿼리가 나갈지 파악하기 어렵게 만들어 예상치 못한 성능 저하 발생.

2) 기술보다 중요한 것은 '사용자 분석'

결국 어떤 로딩 방식을 선택할지는 사용자의 서비스 이용 패턴이 중요

• 상세 보기 진입률이 높다면? 처음부터 데이터를 함께 가져오는 것이 효율적.
• 목록만 훑어보는 유저가 많다면? 필요할 때만 가져오는 지연 로딩이 유리.

3) 결론: 무조건적인 제거보다는 '선별적 최적화'

실제 사용자 분석을 통해 성능 병목이 발생하는 특정 지점에서만 Fetch Join 등을 활용해 N+1을 해결하는 전략을 취하는 것이 가장 바람직합니다.

 

📝
N+1 해결은 기술적인 '정답'을 맞히는 문제가 아니라, 
비즈니스 상황에 맞춰 트레이드오프(Trade-off)를 조절하는 과정.

---