Next.js를 사용한다면 WebP 이미지를 서빙하는 두 가지 경로가 있습니다: next/image가 런타임에 자동으로 변환하게 두거나, 배포 전에 미리 WebP로 변환하여 변환된 파일을 바로 서빙하는 방법입니다. 둘 다 브라우저에서 WebP를 제공하지만, 성능 특성은 매우 다릅니다. 이 글에서 각 방식에서 정확히 무슨 일이 일어나는지, 언제 어떤 방법을 선택해야 하는지 분석합니다.
next/image의 온디맨드 변환 방식
브라우저가 Next.js 이미지 최적화 파이프라인을 통해 이미지를 요청하면, 서버는 첫 번째 요청에서 다음을 수행합니다:
- 디스크에서 소스 이미지를 읽거나 원격 URL에서 가져옴
- 이미지를 원시 픽셀 버퍼로 디코딩
- 요청된 품질과 크기로 WebP로 재인코딩
- 결과를 디스크 캐시에 기록 (보통
.next/cache/images/) - WebP 응답을 브라우저로 스트리밍
이후 요청(동일 URL, 동일 너비, 동일 품질)에서는 Next.js가 캐시된 WebP를 디스크에서 읽어 재인코딩을 건너뜁니다. 캐시는 URL + 너비 + 품질 + 포맷으로 키가 지정되므로, 같은 이미지의 400px와 800px 렌더는 별도로 캐시됩니다.
콜드 스타트 페널티
각 이미지 변형의 첫 번째 요청은 느립니다. 중급 클라우드 VM(vCPU 2개)에서의 일반적인 인코딩 시간:
| 소스 이미지 | 치수 | 첫 요청 지연 | 캐시 히트 지연 |
|---|---|---|---|
| 2 MB JPEG | 3000×2000 → 800px | ~340 ms | ~4 ms |
| 5 MB PNG | 4000×3000 → 1200px | ~820 ms | ~6 ms |
| 500 KB JPEG | 1200×900 → 400px | ~90 ms | ~3 ms |
서버리스 배포(Vercel, AWS Lambda)에서는 인스턴스가 새로 시작될 때마다 콜드 스타트가 발생합니다. 트래픽이 많은 페이지는 캐시가 빨리 따뜻해지지만, 트래픽이 적거나 롱테일 페이지는 서버가 차갑게 식었을 때 방문하는 모든 새 사용자에게 느린 첫 렌더를 제공합니다.
사전 변환 WebP: 정적 접근 방식
대안은 빌드 타임 변환 단계를 실행하는 것입니다 — sharp, cwebp나 Picovert의 PNG to WebP 변환 도구를 사용하여 — 결과.webp 파일을 리포지토리에 커밋하거나 CDN에 업로드합니다. 그런 다음 마크업에서 .webp를 직접 참조합니다:
<img src="/images/hero.webp" width={1200} height={630} alt="Hero" />
또는 Next.js의 반응형 리사이징은 원하지만 포맷 변환은 원하지 않는 경우, next/image에 .webp 파일을 전달하면 됩니다 — 옵티마이저가 WebP 입력을 감지하고 재인코딩을 건너뛰어 필요한 경우 크기 조정만 합니다.
비교 정리
| 요소 | next/image 온디맨드 | 사전 변환 WebP |
|---|---|---|
| 첫 요청 지연 | 느림 (인코딩 오버헤드) | 빠름 (정적 파일) |
| 이후 요청 | 빠름 (디스크 캐시) | 빠름 (CDN/정적) |
| 반응형 리사이징 | 자동 (srcset) | 수동 또는 커스텀 |
| 포맷 협상 | 자동 (AVIF/WebP/JPEG) | 포맷별 수동 |
| 배포 복잡도 | 추가 단계 없음 | 빌드 단계 필요 |
| 서버리스 콜드 스타트 | 영향받음 | 영향 없음 |
| 스토리지 비용 | 변형마다 캐시 증가 | 빌드 시 고정 |
next/image 온디맨드 변환을 쓸 때
- 사용자 생성 콘텐츠 — 이미지가 런타임에 업로드되며 빌드 타임에 알 수 없어 사전 변환이 불가능합니다.
- 대형 이미지 라이브러리 — 수백~수천 개의 상품 이미지를 모두 사전 변환하면 CI에 수분이 더 걸립니다.
- 인기 페이지에 트래픽이 집중 — 따뜻한 캐시가 실제로 콜드 스타트를 드물게 만듭니다.
- AVIF 지원이 필요 —
next/image는 브라우저별 최적 포맷을 협상합니다. 빌드 타임 AVIF 변환은 느리고, 지원 브라우저에 AVIF를 서빙하고 폴백으로 WebP를 제공하는 것은 옵티마이저 없이 구현하기 복잡합니다.
사전 변환 WebP를 쓸 때
- 마케팅/랜딩 페이지 — 이미지 수가 적고 트래픽이 많아 TTFB의 모든 밀리초가 중요합니다.
- CDN을 사용한 SSG(정적 사이트 생성) — 빌드 후 WebP 파일이 서버 처리 없이 엣지 노드에서 직접 서빙됩니다.
- 예측 불가능한 콜드 스타트가 있는 서버리스 배포 — 인코딩 지연을 없애면 일관된 첫 바이트 시간이 보장됩니다.
- 자주 변경되지 않는 이미지 — 로고, 히어로 이미지, OG 썸네일 등 빌드 단계 비용이 무시할 수 있는 수준입니다.
하이브리드 접근 방식
대부분의 프로덕션 Next.js 앱은 두 전략을 조합하면 좋습니다: 중요한 above-the-fold 이미지 (히어로, LCP 후보)의 소규모 집합은 WebP로 사전 변환하고, next/image가 동적이거나 덜 중요한 이미지의 롱테일을 처리하게 합니다. 이렇게 하면 중요한 이미지에서 LCP 지연이 거의 없어지고, 전체 이미지 카탈로그에 대한 대규모 빌드 오버헤드도 피할 수 있습니다.
결론
next/image의 온디맨드 변환은 대부분의 앱에서 올바른 기본값입니다. 하지만 크리티컬 렌더 경로에 있는 이미지 — 히어로 이미지, above-the-fold 썸네일, OG 이미지 — 는 WebP로 사전 변환하면 콜드 스타트 페널티를 완전히 없애고 서버 상태에 관계없이 일관되게 빠른 첫 렌더를 제공합니다. 두 전략은 서로를 보완합니다.