🔃

[TroubleShooting] N+1 쿼리

Date

2025/10/30

문제 상황

프로젝트 전반에서 JPA의 지연 로딩(Lazy Loading) 이 기본으로 설정되어 있었기 때문에, 상품, 주문, 결제, 환불 등 주요 도메인 조회 시 N+1 쿼리 문제가 빈번하게 발생했습니다.

예를 들어, 주문(Order)을 조회할 때 연관된 주문 상세(OrderDetail), 배송지(DeliveryAddress), 결제(Payment), 환불(Refund) 정보를 함께 불러오는 과정에서 각 연관 관계마다 Lazy 로딩이 발생하며, 결과적으로 한 API 호출에 수십~수백 개의 쿼리가 실행되었습니다.

-- 주문 목록 조회 (1회)
SELECT * FROM p_order;

-- 주문별 상세 조회 (N회)
SELECT * FROM p_order_detail WHERE order_id = ?;

-- 주문별 환불 조회 (N회)
SELECT * FROM p_refund WHERE order_id = ?;

-- 주문별 배송지 조회 (N회)
SELECT * FROM p_delivery_address WHERE delivery_address_id = ?;
SQL
복사

이로 인해 데이터베이스 조회 횟수가 급격히 늘어나며 응답 지연과 트랜잭션 처리 시간이 증가했습니다.

원인 분석

1. Lazy Loading의 기본 동작 방식

•

JPA의 @ManyToOne, @OneToMany 관계는 기본적으로 지연 로딩(LAZY) 을 사용

•

즉, 조회 시점에는 연관 객체가 프록시로 남아 있다가 실제 접근 시점(.getXXX())에 추가 쿼리가 실행됨

→ 엔티티 그래프를 단순히 순회하는 것만으로도 여러 개의 SELECT가 실행되는 구조

2. DTO 설계 문제

•

기존 DTO 구조는 엔티티 자체를 필드로 보유하고 있어, 
DTO 생성 시 연관 객체 접근 → Lazy 쿼리 연쇄 실행

•

결과적으로 DTO 변환 과정에서도 N+1 쿼리가 추가로 발생

public record RefundDetailResponse(
    UUID orderId,
    String orderNum,
    List<ProductInfoDto> productList,
    RecipientAddressDto recipientAddress,
    UUID refundId,
    LocalDateTime cancelDate,
    RefundStatus refundStatus,
    int refundPrice,
    RefundReason refundReason
) {
    public static RefundDetailResponse of(Order order, List<OrderDetail> orderDetails, Refund refund) {
        List<ProductInfoDto> productList =
                orderDetails.stream().map(ProductInfoDto::fromEntity).toList();

        RecipientAddressDto recipientAddress =
                RecipientAddressDto.fromEntity(order.getDeliveryAddress()); // Lazy 접근

        return new RefundDetailResponse(
                order.getOrderId(),
                order.getOrderNum(),
                productList,
                recipientAddress,
                refund.getRefundId(),
                refund.getCreatedAt(),
                refund.getRefundStatus(),
                refund.getPrice(),
                refund.getReason());
    }
}
Java
복사

해결 과정

1. Fetch Join 적용

•

JPQL + Fetch Join을 통해 필요한 연관 엔티티를 한 번의 쿼리로 함께 조회

@Query("""
SELECT o FROM Order o
JOIN FETCH o.deliveryAddress
JOIN FETCH o.orderDetails
LEFT JOIN FETCH o.refund
WHERE o.orderId = :orderId
""")
Optional<Order> findByIdWithRelations(@Param("orderId") UUID orderId);
Java
복사

결과:

Order, OrderDetail, DeliveryAddress, Refund를 단일 SQL로 조회

→ Lazy 로딩 제거, DB 왕복 횟수 대폭 감소

2. Batch Fetch Size 설정

•

일괄 로딩(Batch Fetch)을 통해 N+1 문제를 완화

•

Hibernate 설정으로 한 번의 SELECT에 여러 엔티티를 묶어서 가져오도록 지정

spring:
  jpa:
    properties:
      hibernate.default_batch_fetch_size: 100
YAML
복사

효과: 여러 연관 엔티티를 묶어서 한 번에 SELECT
→ 대량 목록 조회에서도 100회 이하의 최소 쿼리로 데이터 로딩 가능

3. DTO 구조 개선

•

DTO에서 엔티티를 직접 참조하지 않고, 내부 static record 구조를 활용해 필요한 데이터만 노출하도록 개선

public record RefundDetailResponse(
        UUID orderId,
        String orderNum,
        List<ProductInfoDto> productList,
        RecipientAddressDto recipientAddress,
        UUID refundId,
        LocalDateTime cancelDate,
        RefundStatus refundStatus,
        int refundPrice,
        RefundReason refundReason) {

    public record ProductInfoDto(
            UUID orderDetailId, int productPrice, String productName, String optionTitle, int quantity) {
        public static ProductInfoDto fromEntity(OrderDetail orderDetail) {
            return new ProductInfoDto(
                    orderDetail.getOrderDetailId(),
                    orderDetail.getPrice(),
                    orderDetail.getProductName(),
                    orderDetail.getOptionName(),
                    orderDetail.getQuantity());
        }
    }

    public record RecipientAddressDto(
            String postalCode, String city, String sigungu, String roadName, String addressDetail,
            String recipientName, String recipientContact) {
        public static RecipientAddressDto fromEntity(DeliveryAddress deliveryAddress) {
            return new RecipientAddressDto(
                    deliveryAddress.getAddress().getPostalCode(),
                    deliveryAddress.getAddress().getCity(),
                    deliveryAddress.getAddress().getSigungu(),
                    deliveryAddress.getAddress().getRoadName(),
                    deliveryAddress.getAddress().getAddressDetail(),
                    deliveryAddress.getRecipientName(),
                    deliveryAddress.getRecipientContact());
        }
    }
}
Java
복사

목적:

•

Lazy 객체 접근 방지

•

DTO는 “읽기 전용 뷰 모델”로 사용 → 불변성 보장

•

조회 시점에 필요한 데이터만 Select하여 전송량 및 처리 속도 개선

개선 효과

구분	개선 전	개선 후
쿼리 수	최대 3N+1	1 ~ 2회
DB 왕복 횟수	엔티티 수만큼 반복	일괄 조회로 최소화
조회 성능	느림 (Lazy 로딩 중첩)	빠름 (Fetch Join + Batch Fetch)
DTO 구조	엔티티 직접 포함	필요한 필드만 내부 DTO로 매핑

인사이트

Lazy Loading은 필연적으로 N+1 문제를 동반하므로, 조회 전용 API에는 반드시 제어가 필요하다.

전역 BatchSize 설정은 간편하지만, 도메인별 최적 크기를 조정해야 한다.

DTO는 엔티티를 직접 담지 말고, 데이터 전송 목적에 맞는 형태로 변환해야 조회 성능과 불변성을 확보할 수 있다.

최적의 설계는 “조회용 쿼리(읽기)”와 “명령용 로직(쓰기)”을 분리하는 것이다. (CQRS 접근)

참고자료

Beware of hibernate batch fetching

Last week, I was exploring how to avoid N+1 selects problem when loading associations or collections for an entity in hibernate. I went down a lot of interesting paths and came up with so many fasc…

https://prasanthmathialagan.wordpress.com/2017/04/20/beware-of-hibernate-batch-fetching/

Mastering Data Fetching in Hibernate JPA: Lazy, Eager, Subselect, and Batch Size

Hibernate JPA, a powerful ORM framework, offers various strategies for fetching related data from your database. Understanding these…

https://medium.com/%40kashishpl2000/mastering-data-fetching-in-hibernate-jpa-lazy-eager-subselect-and-batch-size-89e57a5307b7