사용자 목록을 불러오는 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;

안티패턴 요약 체크리스트

지금까지 안티패턴을 하나씩(N+1·SELECT *·함수 씌운 WHERE·암묵 형변환·OFFSET) 봤습니다. 새로운 안티패턴을 만났을 때 목록을 외워 대조하는 대신, 쿼리가 실행되는 파이프라인의 어느 단계에서 비용이 생기는지로 위치를 잡으면 처방이 바로 나옵니다. SQL 한 문장은 파싱 → 계획 수립(옵티마이저) → 실행을 지나고, 애플리케이션은 이 과정을 여러 번 반복합니다. 각 안티패턴은 이 중 특정 단계에 비용을 심습니다.

하나의 SQL이 실행되는 경로와, 안티패턴이 비용을 심는 지점
   │
   ① 파싱·바인딩 — 구문 검사, 컬럼·타입 확인
   │     암묵적 형변환의 씨앗: 컬럼 타입 ≠ 리터럴 타입
   │
   ② 계획 수립(옵티마이저) — 인덱스·조인·스캔 방식 결정
   │     함수로 감싼 컬럼·앞% LIKE·형변환 → "인덱스 못 씀"으로 판정
   │     OR 조건 → 두 인덱스 결합을 포기하고 Seq Scan 선택
   │
   ③ 실행·접근 — 계획대로 행을 읽고 가공
   │     Seq Scan이면 전체 행 I/O · SELECT *는 넓은 행·큰 컬럼까지 전송
   │     OFFSET 10000은 버릴 앞 1만 행까지 읽음
   │
   ④ 반복 — 애플리케이션이 ①~③을 N번 되풀이
   ▼     N+1: 목록 1번 + 항목마다 쿼리 N번 = 왕복 폭증
  응답 (작은 데이터에선 안 보이다가 운영 규모에서 터진다)

어떤 안티패턴이 어느 단계에서 비용을 만드나:

즉 인덱스를 죽이는 안티패턴은 대부분 ② 계획에서(옵티마이저가 인덱스를 포기), SELECT *·OFFSET은 ③ 실행에서(과도한 I/O·전송), N+1은 ④ 반복에서(왕복 횟수) 비용을 만듭니다. 그래서 진단 도구도 단계별로 갈립니다 — ②는 EXPLAIN의 type=ALL·Seq Scan·key=NULL로, ③은 실제로 읽은 행 수·전송량(EXPLAIN (ANALYZE, BUFFERS))으로, ④는 요청당 쿼리 카운트(slow query log·ORM 로그)로 잡습니다. 비용이 어느 단계에서 생기는지를 먼저 짚으면, 처방이 '인덱스 추가/조건 재작성'(②)인지 '컬럼 명시/Keyset'(③)인지 'JOIN·Eager Loading'(④)인지 바로 정해집니다.

지금까지의 안티패턴은 대부분 SELECT — 어떻게 읽느냐의 문제였습니다. 그런데 운영에서 가장 크게 터지는 안티패턴은 오히려 쓰기 쪽, 그것도 "한 문장으로 너무 많은 행을 건드리는" 경우입니다. DELETE FROM logs WHERE created_at < now() - interval '90 days'로 2천만 행을 지우거나, UPDATE users SET flag = true로 전체 테이블을 한 번에 바꾸는 것이 대표적입니다. 문법은 완벽하고 개발 DB에선 잘 돌지만, 운영에서는 다음이 동시에 일어납니다.

• 락과 긴 트랜잭션: 문장이 끝날 때까지 트랜잭션이 열려 있어 그 행들에 대한 동시 쓰기를 막고, 대기 큐와 데드락 위험을 키웁니다. 게다가 열려 있는 긴 트랜잭션은 VACUUM이 회수할 수 있는 경계(xmin horizon)를 붙잡아, 그동안 시스템 전체의 죽은 튜플 회수를 지연시킵니다.
• MVCC 팽창: PostgreSQL의 DELETE/UPDATE는 행을 즉시 없애지 않고 죽은 튜플로 표시만 합니다. 2천만 행을 지우면 2천만 개의 죽은 튜플이 남아 테이블과 인덱스가 부풀고, VACUUM 전까지 디스크가 줄지 않습니다(일반 VACUUM은 공간을 재사용만 하고 OS에 반환하지 않습니다 — 반환은 VACUUM FULL/pg_repack 필요).
• WAL과 복제: 한 트랜잭션이 대량 WAL을 몰아서 만들어 복제 지연이 치솟고, WAL 디스크가 가득 찰 수도 있습니다.
• 올-오어-낫싱: 몇 시간짜리 삭제가 막판에 실패하면 통째로 롤백돼 시간을 통으로 날립니다.

해결의 핵심은 "큰 트랜잭션을 작은 트랜잭션 여러 개로" 바꾸는 배치 처리입니다. 수천 행씩 잘라 지우고 배치마다 커밋하면, 락이 곧바로 풀려 동시 쓰기가 진행되고, WAL이 조금씩 빠져 복제가 따라잡으며, autovacuum이 죽은 튜플을 회수해 팽창이 억제됩니다. 그리고 반복되는 기간 기반 삭제라면 애초에 파티셔닝으로 설계해, 오래된 파티션을 DROP/DETACH하면 삭제가 즉시 끝나고 죽은 튜플도 남지 않습니다.