N+1 쿼리를 어떻게 고치고 Eloquent를 최적화하나요?

Question

Accepted Answer

**N+1 쿼리 문제** — 루프에서 관계에 접근하면 레코드당 별도의 쿼리가 트리거되는 것 — 는 가장 흔한 Eloquent 성능 문제입니다. `with()`를 이용한 **즉시 로딩(eager loading)**이 주요 해결책이며, 다른 최적화(컬럼 선택, 청킹, 인덱싱)와 함께 사용됩니다.

## N+1 문제와 그 해결책

```php
// ❌ N+1: post를 위한 쿼리 1개 + 각 author를 로딩하는 post당 쿼리 1개
$posts = Post::all();                         // 쿼리 1개
foreach ($posts as $post) {
    echo $post->author->name;                  // 각각 +1 쿼리 → post 100개 = 쿼리 101개!
}

// ✅ with()로 즉시 로딩 → 총 2개 쿼리 (post + 모든 author)
$posts = Post::with('author')->get();
foreach ($posts as $post) {
    echo $post->author->name;                  // 추가 쿼리 없음 — author 미리 가져옴
}
```

**`with()`**는 관계를 미리 즉시 로딩하여(레코드당 하나가 아닌 관계당 하나의 추가 쿼리) 101개 쿼리를 2개로 바꿉니다 — 극적인 개선입니다. 이것이 필수적인 Eloquent 최적화입니다.

## 즉시 로딩 변형

```php
Post::with(['author', 'comments'])->get();        // 여러 관계
Post::with('comments.user')->get();                // 중첩
Post::with(['comments' => fn($q) => $q->latest()])->get();   // 제약된
User::withCount('posts')->get();                   // 로딩 없이 카운트 (post_count)
```

## N+1 자동 탐지

```php
// 개발 중, 지연 로딩이 예외를 던지게 하여 N+1 문제를 일찍 잡음
Model::preventLazyLoading();    // service provider에서 (개발용)
// 또는 Laravel Debugbar / Telescope로 요청당 쿼리 수 확인
```

**Debugbar/Telescope** 같은 도구는 페이지당 쿼리 수를 보여주고(N+1을 시각적으로 발견), `preventLazyLoading()`은 개발 중 우발적인 지연 로딩을 에러로 바꿉니다.

## 기타 Eloquent 최적화

```php
User::select('id', 'name')->get();             // 필요한 컬럼만 가져오기
User::chunk(1000, fn($users) => ...);           // 거대한 세트를 배치로 처리 (메모리)
User::cursor();                                  // 지연 반복 — 일정한 메모리
// + 필터링/조인되는 컬럼에 데이터베이스 인덱스 추가 (가장 큰 DB 수준의 이득)
// + 컬렉션에 대한 PHP 루프 대신 쿼리 빌더/데이터베이스 집계 사용
```

## 왜 중요한가

N+1 쿼리를 고치고 Eloquent를 최적화하는 것은 Laravel 애플리케이션에 중요한 성능 지식입니다 — **N+1 쿼리 문제는 Laravel에서 가장 흔하고 영향력 있는 단일 성능 문제**이며, 그것을 방지하는 방법을 이해하는 것은 필수적입니다.

이 문제는 Eloquent의 편리한 관계 접근(`$post->author`)이 매번 조용히 데이터베이스 쿼리를 트리거하기 때문에 음흉합니다. 따라서 적은 데이터로 잘 동작하는 코드가 데이터가 증가하면서 치명적으로 저하(레코드 100개가 쿼리 101개가 됨)되며, 흔히 부하가 걸린 운영 환경에서야 발견됩니다. **`with()`를 이용한 즉시 로딩**이 필수적인 해결책이며 — 레코드당 하나가 아닌 몇 개의 쿼리로 관계를 미리 로딩 — 그 변형(여러 개, 중첩, 제약된 즉시 로딩, `withCount`)을 아는 것은 일반적인 요구를 충족합니다.

마찬가지로 가치 있는 것은 **N+1 문제를 잡는** 방법(쿼리 수를 보기 위한 Debugbar/Telescope, 개발 중 우발적인 지연 로딩을 에러로 바꾸는 `preventLazyLoading()`)을 아는 것이므로, 운영 전에 그것들을 발견합니다.

N+1 외에도 다른 최적화 — 필요한 컬럼만 선택, 메모리를 소진하지 않고 대규모 데이터셋을 처리하기 위한 **청킹/커서**, PHP 측 컬렉션 처리보다 데이터베이스 집계, 그리고 결정적으로 필터링/조인되는 컬럼에 **인덱싱**(흔히 가장 큰 데이터베이스 수준의 이득) — 이 도구 세트를 완성합니다.

이것들 — 특히 즉시 로딩으로 N+1을 인식하고 고치는 것 — 을 이해하는 것은 성능이 뛰어난 Laravel 애플리케이션을 작성하는 개발자를, 데이터가 증가하면서 앱이 기어가게 만드는 개발자와 구별하는 중요한 시니어 수준의 지식이며, 확장되는 애플리케이션을 구축하는 데 자주 관련되는 높은 가치의 주제입니다.