GraphQL에서 N+1 문제란 무엇이며 DataLoader는 어떻게 이를 해결하나요?

Question

IT Interview Practice · Accepted Answer

**N+1 문제**는 필드 resolver가 parent 항목마다 한 번씩 실행되고 매 실행이 각자의 데이터베이스 쿼리를 날릴 때 발생합니다. N개의 post 목록을 가져온 뒤 각 post의 author를 가져오면 **post에 대한 1개의 쿼리 + author에 대한 N개의 쿼리** — 부하가 걸리면 성능을 무너뜨리는 N+1번의 round trip이 발생합니다.

## 왜 발생하는가

resolver는 필드마다, 항목마다 실행됩니다. `Post.author`는 목록의 모든 post에 대해 개별적으로 실행되고, 각 실행은 서로를 알지 못하므로 각자 자신의 `findById`를 수행합니다.

```js
// BAD: one DB call per post -> N+1
const resolvers = {
  Post: {
    author: (post, _a, ctx) => ctx.db.users.findById(post.authorId),
  },
};
```

## DataLoader: batch + cache

**DataLoader**는 같은 tick에 이루어진 개별 `.load(id)` 호출을 미뤄 두었다가, 모은 key들을 하나의 **batch 함수**에 넘겨 단일 쿼리로 전부 가져옵니다. 또한 요청 내에서 key별로 **캐시**하므로 반복되는 id는 비용이 없습니다.

```js
import DataLoader from "dataloader";

// create ONE loader per request (put it on context so caching is request-scoped)
const userLoader = new DataLoader(async (ids) => {
  // ids arrives as [1, 2, 3, ...] -> a single batched query
  const users = await db.users.findByIds(ids);
  // MUST return values in the SAME ORDER as ids
  return ids.map((id) => users.find((u) => u.id === id));
});

const resolvers = {
  Post: {
    author: (post, _a, ctx) => ctx.userLoader.load(post.authorId), // batched
  },
};
// Now N author resolvers collapse into 1 query: total 2 queries, not N+1.
```

두 가지 규칙: loader는 **요청 단위로** 생성하고(전역이 아니라 — 그러면 사용자 간에 오래된 데이터가 새어 나갑니다), batch 함수는 결과를 **정확히 key 순서대로** 반환해야 합니다.

## 왜 중요한가

N+1은 가장 흔한 GraphQL 성능 함정이자 거의 확실히 나오는 면접 질문입니다. DataLoader를 꺼내 든다는 것 — 그리고 그것이 *왜* 요청 범위(request-scoped)여야 하고 순서를 보존해야 하는지 안다는 것 — 은 실제 프로덕션 경험의 신호입니다.

왜 발생하는가

DataLoader: batch + cache

왜 중요한가

관련 질문