N+1 쿼리 문제란?

N+1 쿼리 문제는 N개의 레코드를 가져올 때 레코드마다 쿼리가 하나씩 더 실행되어, 한두 번이면 될 왕복이 N+1번으로 늘어나는 패턴입니다. 데이터 기반 애플리케이션에서 가장 흔한 심각한 성능 버그이자, 가장 잘 위장된 버그입니다. 개별 쿼리는 모두 빠르고, 코드는 완벽하게 읽히며, 페이지도 잘 동작합니다. 실제 규모의 데이터가 들어오기 전까지는 말입니다.

핵심 요약

코드로 보는 버그

// 쿼리 1개: 게시물 100개 조회
const posts = await postRepo.findRecent(100);

for (const post of posts) {
  // 게시물마다 +1 쿼리 — post.author는 속성처럼 보이지만
  // 실제로는 지연 로딩: SELECT * FROM users WHERE id = ?
  render(post.title, (await post.author).name);
}
// 쿼리 로그: 페이지 렌더링 한 번에 1 + 100 = 101번 왕복

SDK로 표현한 해결책은 이렇습니다. 관계를 미리 선언하면 플랫폼이 같은 요청에서 함께 가져옵니다:

// JavaScript / Node.js — Back4app JS SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
const query = new Parse.Query('Comment');
query.equalTo('post', post);
query.include('author');                    // eager-load the pointer
const comments = await query.find();        // one round trip, total

comments.forEach((c) =>
  render(c.get('text'), c.get('author').get('username')) // already loaded
);

// Flutter / Dart — Back4app Flutter SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
final query = QueryBuilder<ParseObject>(ParseObject('Comment'))
  ..whereEqualTo('post', post.toPointer())
  ..includeObject(['author']);              // eager-load the pointer
final response = await query.query();       // one round trip, total

// iOS / Swift — Back4app Swift SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
let query = Comment.query("post" == post)
  .include("author")                        // eager-load the pointer
query.find { result in
  if case .success(let comments) = result { // one round trip, total
    comments.forEach { render($0.text, $0.author?.username) }
  }
}

// Android / Kotlin — Back4app Android SDK
// The fix: fetch the relation in the same request — 1 query, not N+1
val query = ParseQuery.getQuery<ParseObject>("Comment")
query.whereEqualTo("post", post)
query.include("author")                     // eager-load the pointer
query.findInBackground { comments, e ->     // one round trip, total
  if (e == null) comments.forEach {
    render(it.getString("text"), it.getParseObject("author")?.getString("username"))
  }
}

곱해 보는 비용

설명 글들이 건너뛰는 계산입니다. 총 시간 ≈ 목록 쿼리 + (N × 왕복 지연 시간):

공개된 수정 사례도 이 계산과 일치합니다. 페이지가 1.4 s에서 0.16 s로 줄고, 엔드포인트가 30배 이상 빨라졌습니다. 기억해 둘 만한 따름정리가 두 가지 있습니다. 페이지네이션은 N에 상한을 둡니다. 제한된 페이지 크기는 진짜 해결책을 적용하기 전에도 영향 범위를 제한합니다. 그리고 네트워크 버전은 더 나쁩니다. N번의 호출 하나하나가 로컬 쿼리가 아니라 HTTP 요청이라면, 한 자릿수 밀리초가 아니라 수십 밀리초를 곱해야 합니다.

네 가지 탈출구

마지막 행은 GraphQL의 유명한 사례입니다. 리졸버는 부모 객체마다 실행되어 서버 측에서 루프를 재현하며, 로더 패턴(한 틱 동안 키를 모으고, 한 번에 가져오고, 요청 단위로 메모이제이션)이 업계 표준 해법입니다. 여기에는 미묘한 규칙이 하나 따라붙습니다. 로더는 요청 범위여야 합니다. 전역 로더는 인가 버그를 품은 낡은 캐시가 됩니다.

탐지: 빠른 쿼리 찾기

N+1의 특징은 일반적인 성능 작업과 정반대입니다. 느린 쿼리 하나가 아니라 빠르고 동일한 쿼리 여러 개를 찾아야 합니다. 그래서 흔히 쓰는 도구인 슬로 쿼리 로그는 이를 결코 보지 못합니다. 효과가 있는 방법은 다음과 같습니다. ORM 디버그 로그(렌더링 한 번에 같은 문장이 N개의 다른 매개변수로 반복됨), 동일하고 짧은 스팬이 폭포수처럼 이어지는 모습이 뚜렷이 보이는 APM 스팬 뷰, 그리고 가장 저렴한 방법인 개발 환경에서 페이지 로드 한 번의 쿼리 수를 세는 것입니다. 이때 머릿속에 기준선을 두어야 합니다. 목록 페이지의 쿼리 수는 행 수의 배수가 아니라 한 자릿수여야 합니다. 쓰기 쪽의 쌍둥이도 점검할 가치가 있습니다. 항목마다 insert를 실행하는 루프는 쓰기의 N+1이며, 벌크 작업으로 해결합니다.

일반적인 사용 사례

• 작성자, 소유자, 상태를 함께 보여 주는 목록 화면 – 본래의 서식지입니다. 사람과 항목을 연결하는 모든 피드, 받은편지함, 테이블이 여기에 해당합니다.
• GraphQL API – 중첩된 목록 필드는 로더가 생기기 전까지 구조적으로 N+1입니다.
• 문서 데이터베이스 – 참조된 문서마다 find를 한 번씩 실행합니다. 모델링 규칙에 따라 include, 배칭된 IN, 임베딩으로 해결합니다.
• 마이크로서비스 팬아웃 – 서비스 A에서 목록을 받고, 항목마다 서비스 B에 HTTP 호출을 한 번씩 보냅니다. 복합 엔드포인트와 BFF는 이를 끝내기 위해 존재합니다.
• 백그라운드 작업 – 10,000개 레코드를 레코드당 쿼리 두 개씩으로 처리하는 루프가 조용히 몇 시간을 잡아먹습니다.

지연 로딩 vs. 즉시 로딩: 결정 매트릭스

그리고 어떤 매트릭스보다 오래 남는 상시 점검 규칙이 있습니다. 루프 안에서 건드리는 모든 관계는 쿼리 로그가 무죄를 증명하기 전까지 유죄입니다.

한계와 트레이드오프

• 즉시 로딩은 과잉 교정이 될 수 있습니다. 무거운 관계를 어디서나 포함하면 N+1을 비대한 페이로드와 넓은 조인으로 맞바꾸게 됩니다. 그래프 전체가 아니라 화면이 렌더링하는 것만 포함해야 합니다.
• 조인에도 나름의 절벽이 있습니다. 일대다 조인은 자식마다 부모 행을 중복시킵니다. 팬아웃이 크면 쿼리 두 번으로 배칭하는 조회가 단일 조인보다 낫습니다.
• 로더는 구현 복잡도를 더합니다. 요청 범위 지정, 요청 내 캐시 무효화, 배칭 윈도는 실제로 작성해야 하는 코드이며, 자동 배칭의 대가입니다.
• 프레임워크는 조용히 문제를 다시 들여옵니다. 직렬화기, 템플릿 헬퍼, “필드 하나만 더” 식의 리뷰가 고쳐 둔 페이지를 퇴행시킵니다. 쿼리 수 점검은 기억이 아니라 CI에 있어야 합니다.
• 해결은 전역이 아니라 경로 단위입니다. N+1은 접근 패턴의 버그이며, 새 화면이 생길 때마다 같은 질문을 다시 던져야 합니다.

Back4app에서의 N+1

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. Back4app의 SDK는 해결책을 사후 조치가 아니라 기본 관용구로 만듭니다. 관계는 타입이 지정된 Pointer이고, include()(위의 코드 탭)는 관계를 같은 요청에서 서버 측 배칭으로 가져옵니다. GraphQL API는 필드별 팬아웃 없이 중첩 쿼리를 해석하고, 페이지네이션 기본값이 N이 커지기 전에 상한을 둡니다. N+1을 일으키는 루프는 자연스럽게 작성될 여지가 없습니다. 이것이 가장 좋은 종류의 해결책, 즉 아무도 기억할 필요가 없는 해결책입니다.