사용자 목록을 불러오는 API가 로컬에서는 빠른데 운영에서 0.5초가 걸립니다. 로그를 보면 쿼리가 수백 개 찍혀 있습니다. ORM 코드는 단 두 줄인데 실제로는 사용자 수만큼 쿼리가 나가는 N+1 문제입니다. 이 패턴을 모르면 ORM을 쓸수록 성능이 나빠지는 이유를 찾지 못합니다.

N+1 문제란?

N+1 문제는 1번의 목록 조회 후 각 항목에 대해 N번의 추가 쿼리가 발생하는 패턴입니다. ORM 코드에서는 단순한 속성 접근처럼 보이지만 실제로는 루프마다 DB 쿼리가 실행됩니다.

게시글 100개를 조회하고 각 게시글에서 post.author.name을 읽으면 1번(게시글 목록) + 100번(작성자 정보) = 총 101번의 쿼리가 실행됩니다. 게시글이 1,000개라면 1,001번입니다. 개발 환경에서는 데이터가 적어 눈에 띄지 않다가, 운영 환경에서 데이터가 쌓이면 급격히 느려집니다.

아래는 N+1이 발생하는 Python/SQLAlchemy 예시와 실제로 실행되는 쿼리입니다.

posts = session.query(Post).limit(100).all()

for post in posts:
    print(f"{post.title} by {post.author.name}")

SELECT * FROM posts LIMIT 100;

SELECT * FROM users WHERE id = 1;
SELECT * FROM users WHERE id = 2;
SELECT * FROM users WHERE id = 3;

실행 완료 또는 조회 결과가 표시됩니다.

JOIN으로 한 번에 해결

N+1의 근본 해결책은 처음부터 JOIN을 사용해 필요한 데이터를 한 번의 쿼리로 가져오는 것입니다. 아래 쿼리는 위 101번 쿼리와 동일한 결과를 단 1번에 반환합니다.

SELECT
    p.id,
    p.title,
    p.created_at,
    u.name AS author_name,
    u.avatar_url
FROM posts p
JOIN users u ON p.author_id = u.id
ORDER BY p.created_at DESC
LIMIT 100;

ORM별 Eager Loading 해결법

각 ORM 프레임워크는 N+1을 방지하는 Eager Loading 기능을 제공합니다. Django의 select_related는 FK 관계에 SQL JOIN을 사용하고, prefetch_related는 M:N이나 역방향 FK에 별도 쿼리 1번을 실행합니다.

posts = Post.objects.select_related('author').all()[:100]

posts = Post.objects.prefetch_related('tags', 'comments').all()[:100]

posts = Post.objects.select_related('author').prefetch_related('tags')[:100]

SQLAlchemy에서는 joinedload가 JOIN 방식이고, selectinload는 별도 IN 쿼리 방식으로 M:N 관계에 적합합니다.

from sqlalchemy.orm import joinedload, selectinload

posts = session.query(Post).options(joinedload(Post.author)).limit(100).all()

posts = session.query(Post).options(selectinload(Post.tags)).limit(100).all()

Hibernate/JPA에서는 JPQL의 JOIN FETCH 또는 @EntityGraph를 사용합니다.

List<Post> posts = em.createQuery(
    "SELECT p FROM Post p JOIN FETCH p.author WHERE p.deleted = false",
    Post.class
).setMaxResults(100).getResultList();

N+1 탐지 방법

개발 환경에서 쿼리 로그를 활성화해두면 N+1을 조기에 발견할 수 있습니다. Django Debug Toolbar, Hibernate Statistics 같은 도구도 활용합니다. Django에서 직접 쿼리 수를 확인하려면 아래 코드를 사용합니다.

from django.db import connection

with connection.execute_wrapper(lambda execute, *a, **kw: execute(*a, **kw)):
    posts = list(Post.objects.all()[:100])
    print(f"쿼리 실행 횟수: {len(connection.queries)}")

배치 처리 스크립트에서도 N+1이 발생합니다. 루프 안에서 단건 조회 대신 bulk 조회를 사용합니다.

orders = Order.objects.filter(id__in=order_ids).select_related('customer')
for order in orders:
    process(order)

인덱스를 걸었는데도 EXPLAIN이 Full Table Scan을 보여줍니다. 쿼리가 뭔가 잘못됐다는 건 알겠는데 왜 인덱스가 안 타는지 이해가 안 됩니다. 인덱스 컬럼을 함수로 감싸거나, LIKE 앞에 %를 쓰거나, 타입 불일치가 있으면 옵티마이저가 인덱스를 무시합니다. 이 패턴들을 알면 느린 쿼리의 절반 이상을 설명할 수 있습니다.

패턴 1: 함수로 인덱스 컬럼 감싸기

B-Tree 인덱스는 컬럼의 원래 값으로 만들어집니다. WHERE 절에서 인덱스가 걸린 컬럼을 함수로 감싸면 인덱스 키와 비교 대상이 달라져 인덱스를 전혀 사용할 수 없고 Full Table Scan이 발생합니다.

해결 방법은 함수를 적용하지 않고 범위 조건으로 변환하는 것입니다. 날짜 연산의 경우 YEAR(created_at) = 2024 대신 created_at >= '2024-01-01' AND created_at < '2025-01-01'로 바꾸면 인덱스를 그대로 활용할 수 있습니다.

어쩔 수 없이 함수를 사용해야 한다면 PostgreSQL의 표현식 인덱스(Function-Based Index)를 생성하면 됩니다. 표현식 인덱스는 동일한 함수 표현식을 인덱스 키로 저장하므로 같은 함수를 적용한 WHERE 조건이 인덱스를 사용할 수 있습니다.

-- 인덱스 무력화 (Seq Scan 발생)
EXPLAIN SELECT * FROM orders WHERE YEAR(created_at) = 2024;

-- 인덱스 활용 (Index Range Scan)
EXPLAIN SELECT * FROM orders
WHERE created_at >= '2024-03-01'
  AND created_at <  '2024-04-01';

SELECT * FROM users WHERE phone_number = '01012345678';

-- 표현식 인덱스로 함수 그대로 사용
CREATE INDEX idx_name_upper ON users (UPPER(name));

SELECT * FROM users WHERE UPPER(name) = 'HONG';

패턴 2: LIKE 앞에 % 와일드카드

B-Tree 인덱스는 전화번호부처럼 앞에서부터 정렬됩니다. LIKE '삼성%'처럼 앞이 고정된 접두사 매칭은 인덱스 범위 검색을 할 수 있지만, LIKE '%노트북%'처럼 앞에 와일드카드가 오면 어디서 시작할지 알 수 없어 전체 테이블을 스캔해야 합니다.

중간 포함 검색이 필요하다면 Full-Text Search를 사용합니다. PostgreSQL은 tsvector와 to_tsquery로 전문 검색을 지원하며, 대용량 검색에는 Elasticsearch 도입을 검토합니다.

SELECT * FROM products WHERE name LIKE '삼성%';

SELECT * FROM products
WHERE to_tsvector('korean', name) @@ to_tsquery('korean', '노트북');

패턴 3: 암묵적 형변환

컬럼 타입과 비교 값의 타입이 다르면 DB가 자동으로 형변환을 시도합니다. 이 과정에서 인덱스가 걸린 컬럼에 변환 함수가 내부적으로 적용되어 인덱스가 무력화됩니다.

VARCHAR 컬럼을 숫자 리터럴과 비교하거나, INTEGER 컬럼을 문자열 리터럴과 비교할 때 발생합니다. 항상 컬럼 타입과 동일한 타입의 리터럴을 사용합니다.

SELECT * FROM users WHERE phone_number = '01012345678';

SELECT * FROM users WHERE user_id = 42;

패턴 4: OR 조건의 인덱스 문제

각 컬럼에 인덱스가 있더라도 OR 조건은 플래너가 두 인덱스를 결합하기 어려워 Seq Scan을 선택할 수 있습니다. UNION ALL로 분리하면 각 브랜치에서 독립적으로 인덱스를 활용합니다. UNION ALL은 UNION과 달리 중복 제거를 하지 않으므로 중복이 없는 경우 더 빠릅니다.

SELECT * FROM users WHERE status = 'active' AND region = 'seoul'
UNION ALL
SELECT * FROM users WHERE status = 'vip'
  AND NOT (status = 'active' AND region = 'seoul');

패턴 5: SELECT * 의 숨은 비용

SELECT *는 테이블의 모든 컬럼을 읽어 네트워크로 전송합니다. TEXT, BLOB 같은 대용량 컬럼이 포함된 테이블에서는 불필요한 데이터가 대량으로 전송됩니다. 또한 필요한 컬럼만 인덱스에 포함하는 커버링 인덱스(Index Only Scan) 활용이 불가능해집니다.

스키마에 컬럼이 추가될 때 예상치 못한 동작이 발생하거나 ORM 매핑 오류가 생길 위험도 있습니다.

SELECT order_id, status, total_amount, created_at
FROM orders
WHERE customer_id = 42;

패턴 6: OFFSET 페이지네이션

OFFSET N은 DB가 처음 N개 행을 읽고 버린 뒤 다음 결과를 반환하는 방식입니다. OFFSET 10000이면 10,020개를 읽고 앞의 10,000개를 버립니다. 페이지가 뒤로 갈수록 읽어야 할 행이 선형적으로 늘어납니다.

Keyset Pagination(커서 기반)은 마지막으로 본 항목의 값을 기준으로 다음 페이지를 조회합니다. 복합 인덱스가 있으면 항상 빠른 Index Range Scan으로 처리됩니다. 단, 임의 페이지로 바로 이동(예: 페이지 번호 클릭)은 불가능합니다.

SELECT * FROM articles
WHERE created_at < '2024-03-15 12:00:00'
   OR (created_at = '2024-03-15 12:00:00' AND id < 12345)
ORDER BY created_at DESC, id DESC
LIMIT 20;

안티패턴 요약 체크리스트