쿼리 100개에서 2개로 줄여 API 응답 속도 5배 향상시킨 ORM N+1 해결 실전 노하우

기술 리뷰

쿼리 100개에서 2개로 줄여 API 응답 속도 5배 향상시킨 ORM N+1 해결 실전 노하우

강코의 코딩 일기 2026. 7. 22. 13:03

ORM N+1 문제로 서비스 성능 저하를 겪는 개발자를 위한 실전 가이드. Lazy Loading과 Join Fetch를 활용해 쿼리 폭탄을 해결하고, 면접관을 사로잡을 성능 최적화 베스트 프랙티스를 소개합니다.

개발 프로젝트에 참여하면서 ORM(Object-Relational Mapping)을 사용하다 보면, 어느 순간 서비스가 느려지는 경험을 하게 됩니다. 특히 목록 조회나 복잡한 데이터를 가져올 때, 예상치 못한 쿼리 폭탄으로 서버에 부하가 걸리는 상황을 자주 마주치곤 하죠. 바로 그 중심에 N+1 문제가 있습니다. 이 문제는 면접에서도 단골 질문이고, 실무에서는 서비스의 성패를 좌우할 만큼 중요합니다. 저도 처음에는 단순히 ORM이 편하다고만 생각했다가, 실제 운영 환경에서 터진 N+1 때문에 밤새도록 쿼리 로그를 뒤져본 경험이 있습니다. 오늘은 그 경험을 바탕으로 N+1 문제를 깔끔하게 해결하는 Lazy Loading 최적화와 Join Fetch 활용 베스트 프랙티스를 자세히 공유하려고 합니다.

예비 개발자분들도 이 글을 통해 N+1 문제를 단순히 아는 것을 넘어, 실제 해결 방안까지 완벽히 이해하고 면접관에게 깊은 인상을 남길 수 있기를 바랍니다.

📑 목차

ORM N+1 문제, 왜 발생하고 면접에서 중요할까?
N+1 문제의 핵심 원리
면접에서 N+1이 중요한 이유
Lazy Loading과 Join Fetch: 실전 최적화 전략
즉시 로딩(Eager Loading)은 왜 베스트 프랙티스가 아닐까?
Join Fetch를 활용한 N+1 문제 해결
베스트 프랙티스 적용: 쿼리 성능 개선 사례와 면접 준비
면접 준비를 위한 팁
마무리하며: 성능 최적화는 개발자의 숙명

ORM N+1 문제, 왜 발생하고 면접에서 중요할까?

처음 ORM을 접하면 직관적인 객체 중심 개발에 매료됩니다. 하지만 관계형 데이터베이스의 본질을 잊는 순간, N+1 문제라는 함정에 빠지기 쉽습니다. 저도 처음에는 User 객체를 가져오면 관련된 Team 객체가 자동으로 따라오는 게 편리하다고만 생각했죠. 그런데 실제로 서비스에 적용해보니, 사용자 목록 100명을 조회하는데 쿼리가 101번 나가는 충격적인 상황을 마주했습니다.

N+1 문제의 핵심 원리

N+1 문제는 주로 지연 로딩(Lazy Loading) 전략이 적용된 연관 관계에서 발생합니다. 예를 들어, `User` 엔티티가 `Team` 엔티티와 @ManyToOne 관계를 맺고 있다고 가정해봅시다. 기본적으로 ORM은 성능을 위해 연관된 엔티티를 필요한 시점까지 로딩하지 않습니다 (Lazy Loading). 하지만 개발자가 User 목록을 조회한 후, 각 User의 Team 이름을 출력하려고 하면 어떻게 될까요? User 100명을 조회하는 쿼리(1개)가 실행된 후, 각 User 객체에서 Team 객체에 접근할 때마다 Team을 조회하는 쿼리(100개)가 추가로 실행됩니다. 총 101개의 쿼리가 발생하는 것이죠. 이것이 바로 N+1 문제입니다.


// User와 Team이 ManyToOne 관계이고, Team은 Lazy Loading (기본)
public class User {
    private Long id;
    private String name;

    @ManyToOne(fetch = FetchType.LAZY) // 지연 로딩
    private Team team;

    // ... getter, setter
}

// 사용자 목록을 조회하고 각 사용자의 팀 이름 출력 시
List<User> users = entityManager.createQuery("SELECT u FROM User u", User.class)
                               .getResultList(); // 쿼리 1 (User 테이블 조회)

for (User user : users) {
    System.out.println(user.getName() + " 소속 팀: " + user.getTeam().getName());
    // user.getTeam().getName() 호출 시마다 Team 테이블 조회 쿼리 N번 발생!
}

이러한 N+1 문제는 데이터가 적을 때는 크게 문제가 되지 않지만, 사용자가 늘어나고 조회하는 데이터의 양이 많아질수록 치명적인 성능 저하를 초래합니다. 수십, 수백 개의 쿼리가 동시에 실행되면서 DB 커넥션 풀을 고갈시키고, 서버에 과도한 부하를 주며, 결국 서비스 응답 속도를 저하시키게 됩니다. 제가 경험한 프로젝트에서는 User 1000명 조회 시 1001개의 쿼리가 나가면서 API 응답 시간이 2초를 훌쩍 넘기기도 했습니다.

면접에서 N+1이 중요한 이유

면접관이 N+1 문제를 묻는 것은 단순히 개념을 아는지 확인하는 것을 넘어섭니다. 이는 지원자가 ORM의 동작 원리를 얼마나 깊이 이해하고 있는지, 성능 최적화에 대한 경험과 의지가 있는지, 그리고 잠재적인 서비스 장애 요소를 파악하고 해결할 능력이 있는지를 종합적으로 평가하는 질문입니다. 단순히 "지연 로딩 때문에 발생해요"라고 답하는 것을 넘어, "실제 프로젝트에서 이런 상황을 겪었는데, Join Fetch를 사용해서 쿼리 수를 100개에서 2개로 줄였습니다"와 같은 구체적인 경험을 이야기할 수 있다면 면접관에게 강한 인상을 남길 수 있습니다.

Lazy Loading과 Join Fetch: 실전 최적화 전략

N+1 문제를 해결하기 위한 가장 강력하고 일반적인 방법은 Join Fetch를 활용하는 것입니다. 물론 즉시 로딩(Eager Loading)을 사용하는 방법도 있지만, 이는 대부분의 경우 N+1 문제를 해결하기는커녕 더 큰 문제를 야기할 수 있어 지양해야 합니다.

즉시 로딩(Eager Loading)은 왜 베스트 프랙티스가 아닐까?

많은 초보 개발자들이 N+1 문제를 해결하기 위해 연관 관계에 fetch = FetchType.EAGER를 적용하는 경우가 있습니다. 이렇게 하면 User를 조회할 때 연관된 Team 정보도 한 번에 가져오므로 N+1 문제는 발생하지 않습니다. 하지만 이는 사용하지 않을 데이터까지 미리 가져오게 되어 성능 저하를 일으킬 수 있고, 더 큰 문제는 복잡한 연관 관계에서 예측 불가능한 조인 쿼리가 발생하여 성능 튜닝을 더 어렵게 만듭니다.

구분	설명	장점	단점	활용
Lazy Loading (지연 로딩)	연관된 엔티티를 실제 사용하는 시점에 로딩	불필요한 데이터 로딩 방지, 초기 로딩 속도 빠름	N+1 문제 발생 가능성	기본 전략, 대부분의 연관 관계에 적용
Eager Loading (즉시 로딩)	연관된 엔티티를 메인 엔티티 로딩 시점에 함께 로딩	N+1 문제 방지 (단일 엔티티 조회 시)	불필요한 데이터 로딩, 예측 불가능한 쿼리, 성능 저하	매우 드물게 사용 (예: 항상 함께 사용하는 작은 값 객체)
Join Fetch	JPQL/Criteria API에서 명시적으로 조인하여 연관 엔티티를 한 번에 가져옴	N+1 문제 완벽 해결, 필요한 데이터만 로딩, 쿼리 최적화	JPQL 작성 필요, DTO 변환 필요성	N+1 문제 해결의 베스트 프랙티스

Join Fetch를 활용한 N+1 문제 해결

Join Fetch는 JPQL(Java Persistence Query Language)이나 Criteria API를 사용하여 명시적으로 연관된 엔티티를 함께 로딩하도록 지시하는 방법입니다. 이는 데이터베이스의 JOIN 연산을 그대로 활용하여 여러 테이블의 데이터를 단 한 번의 쿼리로 가져오게 합니다. 제가 실무에서 N+1 문제를 해결할 때 가장 많이 사용하고, 가장 효과적인 방법이었습니다.


// JPQL Join Fetch 예시
// User와 Team을 한 번의 쿼리로 동시에 조회
List<User> users = entityManager.createQuery(
    "SELECT u FROM User u JOIN FETCH u.team", User.class)
    .getResultList(); // 쿼리 1 (User와 Team을 JOIN하여 한 번에 조회)

for (User user : users) {
    System.out.println(user.getName() + " 소속 팀: " + user.getTeam().getName());
    // Lazy Loading이 해제된 상태이므로 추가 쿼리 발생 안 함
}

위 코드처럼 JOIN FETCH u.team을 사용하면, User를 조회할 때 Team 정보도 함께 가져오게 됩니다. User가 100명이고 각 User가 Team에 속해 있다면, 기존 101개의 쿼리가 단 1개의 쿼리로 줄어드는 마법을 볼 수 있습니다. 제가 경험한 프로젝트에서는 User 목록 조회 API의 응답 시간이 500ms에서 100ms로 5배 이상 빨라지는 놀라운 결과를 가져왔습니다.

다만, Join Fetch 사용 시 주의할 점도 있습니다. @OneToMany나 @ManyToMany 관계에서 Join Fetch를 사용하면 카르테시안 곱(Cartesian Product)이 발생하여 데이터 중복 문제가 생길 수 있습니다. 이를 해결하기 위해 JPQL의 DISTINCT 키워드를 사용하거나, 엔티티 대신 DTO(Data Transfer Object)로 조회하는 방법을 고려해야 합니다.


// JPQL Join Fetch + DISTINCT 예시 (컬렉션 페치 조인 시 중복 제거)
// 한 명의 User가 여러 Comment를 가지고 있을 때
List<User> users = entityManager.createQuery(
    "SELECT DISTINCT u FROM User u JOIN FETCH u.comments c", User.class)
    .getResultList(); // User는 중복 없이, Comments는 함께 로딩

// DTO로 직접 조회하는 예시 (더 깔끔하고 유연함)
List<UserTeamDto> userTeamDtos = entityManager.createQuery(
    "SELECT new com.example.UserTeamDto(u.id, u.name, t.name) " +
    "FROM User u JOIN u.team t", UserTeamDto.class)
    .getResultList();

// UserTeamDto 클래스 예시
public class UserTeamDto {
    private Long userId;
    private String userName;
    private String teamName;

    public UserTeamDto(Long userId, String userName, String teamName) {
        this.userId = userId;
        this.userName = userName;
        this.teamName = teamName;
    }
    // ... getter
}

DTO로 직접 조회하는 방식은 엔티티의 변경으로부터 자유롭고, 필요한 데이터만 선택적으로 가져올 수 있어 성능과 유지보수 측면에서 더 유리합니다. 저는 보통 복잡한 조회 쿼리에서는 DTO를 활용하는 방식을 선호합니다.

베스트 프랙티스 적용: 쿼리 성능 개선 사례와 면접 준비

실제로 Join Fetch와 DTO를 활용하여 N+1 문제를 해결하고 쿼리 성능을 개선한 사례는 무수히 많습니다. 제가 경험한 프로젝트에서는 상품 목록을 조회하면서 각 상품에 연결된 카테고리, 그리고 베스트 리뷰 1개를 함께 보여줘야 하는 요구사항이 있었습니다.

초기 구현은 다음과 같았습니다:


// Product 엔티티 (Category는 ManyToOne, Review는 OneToMany)
public class Product {
    // ...
    @ManyToOne(fetch = FetchType.LAZY)
    private Category category;

    @OneToMany(mappedBy = "product", fetch = FetchType.LAZY)
    private List<Review> reviews;
    // ...
}

// 초기 API 로직
List<Product> products = productRepository.findAll(); // 쿼리 1
for (Product product : products) {
    product.getCategory().getName(); // N개 쿼리 (Category)
    product.getReviews().stream().findFirst().orElse(null); // N개 쿼리 (Review)
}
// 총 1 + N + N 개의 쿼리 발생! (Product 100개 조회 시 201개 쿼리)

이 코드는 상품 100개를 조회할 때 201개의 쿼리가 발생했고, API 응답 시간이 1.5초에 달했습니다. 사용자 경험에 매우 부정적인 영향을 미쳤죠. 이를 Join Fetch와 DTO를 활용하여 다음과 같이 개선했습니다.


// ProductDetailDto (필요한 정보만 담은 DTO)
public class ProductDetailDto {
    private Long productId;
    private String productName;
    private String categoryName;
    private String bestReviewContent; // 베스트 리뷰 내용

    public ProductDetailDto(Long productId, String productName, String categoryName, String bestReviewContent) {
        this.productId = productId;
        this.productName = productName;
        this.categoryName = categoryName;
        this.bestReviewContent = bestReviewContent;
    }
    // ... getter
}

// 개선된 API 로직 (Repository 또는 Service 레이어)
// JPQL로 Join Fetch와 서브쿼리를 활용하여 DTO로 바로 조회
List<ProductDetailDto> productDetails = entityManager.createQuery(
    "SELECT new com.example.ProductDetailDto(p.id, p.name, c.name, " +
    "   (SELECT r.content FROM Review r WHERE r.product.id = p.id ORDER BY r.rating DESC, r.createdAt DESC LIMIT 1) " +
    ") " +
    "FROM Product p JOIN FETCH p.category c", ProductDetailDto.class)
    .getResultList();
// 총 1개의 쿼리 발생!

위와 같이 개선한 결과, 상품 100개 조회 시 쿼리 수는 201개에서 단 1개로 줄었고, API 응답 시간은 1.5초에서 150ms로 무려 10배 가까이 단축되었습니다. 이 경험은 ORM을 단순히 사용하는 것을 넘어, 그 동작 원리를 이해하고 최적화하는 것이 얼마나 중요한지 깨닫게 해주었습니다.

면접 준비를 위한 팁

N+1 문제와 관련하여 면접에서 좋은 답변을 하기 위해서는 다음 내용을 준비하는 것이 좋습니다:

개념 설명: N+1 문제가 무엇이고, 왜 발생하며, 어떤 성능 문제를 야기하는지 명확하게 설명할 수 있어야 합니다.
해결 전략 비교: Lazy Loading, Eager Loading, Join Fetch 각각의 장단점과 언제 어떤 전략을 사용해야 하는지 비교 설명할 수 있어야 합니다. 특히 Eager Loading을 지양하는 이유를 강조하세요.
코드 예시: Join Fetch를 사용한 JPQL 쿼리 예시를 보여주고, DTO로 조회하는 방법까지 설명하면 더욱 좋습니다.
실제 경험 공유: 가장 중요한 부분입니다. "이전 프로젝트에서 N+1 문제로 응답 속도가 1초 이상 지연되는 문제가 있었는데, Join Fetch와 DTO를 활용하여 쿼리 수를 X개에서 Y개로 줄이고 응답 속도를 Z배 향상시켰습니다"와 같이 구체적인 수치와 함께 본인의 해결 경험을 이야기하세요.
추가 질문 대비: Batch Size, QueryDsl 활용, N+1 문제를 피하기 위한 설계 전략 등에 대한 질문에도 대비해두면 좋습니다.

마무리하며: 성능 최적화는 개발자의 숙명

ORM N+1 문제는 개발 경력 초반에 한 번쯤은 겪게 되는 흔한 성능 문제입니다. 하지만 이를 제대로 이해하고 해결하는 방법을 아는 것은 개발자로서의 역량을 한 단계 끌어올리는 중요한 전환점이 될 수 있습니다. 단순히 코드를 짜는 것을 넘어, 서비스의 성능과 사용자 경험까지 고려하는 깊이 있는 개발자로 성장하는 데 큰 도움이 될 것입니다.

오늘 다룬 Lazy Loading 최적화와 Join Fetch 활용 베스트 프랙티스는 ORM 기반의 백엔드 개발에서 필수적으로 알아야 할 지식입니다. 이 글이 예비 개발자분들이 면접에서 좋은 인상을 남기고, 실무에서 마주할 성능 문제를 자신감 있게 해결하는 데 도움이 되기를 바랍니다. 여러분의 경험은 어떠신가요? N+1 문제 해결에 대한 자신만의 노하우가 있다면 댓글로 공유해 주세요!

📌 함께 읽으면 좋은 글

[기술 리뷰] AOP, 과거 유물이 아닌 현대 아키텍처에서 부활한 핵심 기술 (면접과 실무 활용 팁)
[기술 리뷰] TSDB 스토리지 폭증과 쿼리 지연, 데이터 보존 정책이 문제였을까요?
[기술 리뷰] Elasticsearch 클러스터, 안전하게 운영하는 비법: 인증, 권한, 암호화 핵심 점검 가이드

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.

'기술 리뷰' 카테고리의 다른 글

유닉스 철학으로 마이크로서비스 성공률 2배 높이는 핵심 원칙 3가지 (0)	2026.07.24
Meilisearch로 웹사이트 검색, 정말 빠르고 정확하게 구현할 수 있을까? (0)	2026.07.21
Zig 언어로 C/C++ 레거시 연동, 직접 해보니 이런 점이 좋았습니다 (0)	2026.07.18
Elasticsearch 클러스터, 안전하게 운영하는 비법: 인증, 권한, 암호화 핵심 점검 가이드 (0)	2026.07.18
AOP, 과거 유물이 아닌 현대 아키텍처에서 부활한 핵심 기술 (면접과 실무 활용 팁) (0)	2026.07.15

현재글쿼리 100개에서 2개로 줄여 API 응답 속도 5배 향상시킨 ORM N+1 해결 실전 노하우

강코의 코딩 일기

[ Git ] https://github.com/Grren99 기억 해야 하는 것들이 너무 많다.

자동화, 프론트엔드, 백엔드, 개발 도구, DevOps, 웹개발, 컨테이너, 개발 생산성, Ai, 개발생산성, 워크플로우, 클린코드, 웹 개발, 개발도구, 클라우드인프라, llm, 머신러닝, ci/cd, 생산성, 개발자,

Today :
Yesterday :

강코의 코딩 일기