Next.js 15의 핵심 변경: Turbopack 안정화(개발 서버 속도 대폭 향상), Server Actions 개선, Partial Prerendering(정적+동적 혼합 렌더링), 캐싱 전략 변경(기본 no-cache).
Next.js 15 핵심 변경사항 총정리
한 줄 요약: Next.js 15는 Turbopack 안정화, 캐싱 전략 변경(기본 no-cache), Partial Prerendering(PPR), React 19 통합이 핵심이다. Next.js 14에서 15로 마이그레이션하면 무엇이 달라지는지, 실전 프로젝트에서 주의할 점은 무엇인지 정리한다. 특히 캐싱 동작 변경은 기존 앱의 성능에 직접 영향을 미치므로 반드시 확인해야 한다.
by Lee
한 줄 요약: Next.js 15는 Turbopack 안정화, 캐싱 전략 변경(기본 no-cache), Partial Prerendering(PPR), React 19 통합이 핵심이다.
Next.js 14에서 15로 마이그레이션하면 무엇이 달라지는지, 실전 프로젝트에서 주의할 점은 무엇인지 정리한다. 특히 캐싱 동작 변경은 기존 앱의 성능에 직접 영향을 미치므로 반드시 확인해야 한다.
주요 변경사항
Turbopack 안정화: next dev --turbopack이 안정 버전으로 올라갔다. 대규모 프로젝트에서 Webpack 대비 HMR(Hot Module Reload) 속도가 5~10배 빠르다. next.config.ts에서 experimental.turbo 설정 없이 바로 사용 가능하다.
캐싱 전략 변경: Next.js 14에서 fetch()는 기본적으로 캐시를 사용했지만, 15에서는 기본값이 no-cache로 변경됐다. 기존에 캐시에 의존하던 API 호출이 있다면, 명시적으로 cache: 'force-cache' 또는 next.revalidate를 설정해야 한다. 이 변경으로 인한 성능 저하가 가장 흔한 마이그레이션 이슈다.
캐싱 전략 변경 대응// Next.js 14 (자동 캐시) fetch('https://api.example.com/data') // Next.js 15 (명시적 캐시 필요) fetch('https://api.example.com/data', { next: { revalidate: 3600 } // 1시간 캐시 }) // 또는 route segment config export const revalidate = 3600;
마이그레이션 체크리스트
- 캐싱 동작 변경 확인 (fetch 기본값 변경)
- async Request API 대응 (cookies, headers 등)
- Turbopack으로 개발 서버 전환 테스트
- React 19 호환성 확인
async Request API: cookies(), headers(), params, searchParams가 모두 async로 변경됐다. const cookieStore = await cookies()처럼 await를 추가해야 한다. Codemod npx @next/codemod@canary upgrade latest로 대부분 자동 변환 가능하다.
실전 성능 개선 팁
Next.js 15에서 성능을 극대화하는 방법: PPR(Partial Prerendering) 활용, 이미지 최적화, 서버 컴포넌트 최대한 활용, 클라이언트 번들 최소화.
PPR(Partial Prerendering): 하나의 페이지에서 정적 부분은 빌드 시 생성하고, 동적 부분만 요청 시 스트리밍한다. 예를 들어 상품 페이지에서 제목/설명은 정적, 가격/재고는 동적으로 처리하면 TTFB가 크게 개선된다.
서버 컴포넌트 최적화: 클라이언트 번들에 포함되는 코드를 최소화하라. 'use client'를 가능한 한 리프(leaf) 컴포넌트에만 사용하고, 데이터 페칭은 서버 컴포넌트에서 처리한다. next build 후 .next/analyze로 번들 크기를 확인하라.
마이그레이션 팁:
npx @next/codemod@canary upgrade latest 명령으로 대부분의 breaking change를 자동 수정할 수 있다. 실행 후 수동으로 캐싱 전략만 점검하면 된다.자주 묻는 질문
실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?
fetch 캐싱 동작 변경부터 확인하세요. Next.js 14에서는 fetch가 기본 캐시였지만 15에서는 기본값이 no-cache로 바뀌었기 때문에, 기존에 자동 캐시에 의존하던 호출은 next.revalidate나 cache: force-cache를 명시하지 않으면 매 요청마다 원본을 때려 성능이 떨어집니다. 이게 가장 흔한 마이그레이션 이슈입니다. 그다음으로 cookies()·headers()·params·searchParams가 모두 async로 바뀌었으니 await 누락이 없는지 봐야 하는데, 대부분은 npx @next/codemod@canary upgrade latest 코드모드가 자동 변환해 줍니다. 코드모드 실행 후 캐싱 전략만 수동으로 점검하는 순서를 권장합니다.
가장 자주 발생하는 실수나 함정은 무엇인가요?
단연 캐싱입니다. 코드는 그대로인데 15로 올린 뒤 페이지가 느려졌다면 십중팔구 fetch 기본값이 no-cache로 바뀌어 캐시되던 호출이 매번 원본을 가져오기 때문입니다. 빌드는 통과하니 배포 후에야 알아채는 경우가 많습니다. 두 번째 함정은 async Request API인데, cookies()나 params에 await를 빼먹으면 런타임에서 값이 Promise로 잡혀 엉뚱하게 동작합니다. 코드모드를 돌렸어도 직접 작성한 부분은 놓치기 쉬우니 확인이 필요합니다. 세 번째는 PPR을 무턱대고 켜는 것으로, 정적/동적 경계를 잘못 그으면 오히려 TTFB가 나빠지니 페이지 단위로 효과를 측정하며 적용하시기 바랍니다.
지금 바로 15로 올려야 하나요, 14에 머무는 게 나은 경우도 있나요?
새로 시작하는 프로젝트라면 처음부터 15로 가는 것이 맞습니다. Turbopack 안정화로 개발 서버 HMR이 5~10배 빨라지고, async Request API나 캐싱 기본값도 처음부터 새 동작에 맞춰 짜면 마이그레이션 부담이 없습니다. 운영 중인 14 앱이라면 판단이 갈립니다. fetch 자동 캐시에 깊게 의존하던 앱은 15에서 기본값이 no-cache로 바뀌어 손대지 않으면 성능이 떨어지므로, 트래픽이 몰리는 시즌이나 대형 출시 직전에는 올리지 않는 편이 안전합니다. 반대로 HMR 속도가 답답하거나 PPR로 TTFB를 개선하고 싶다면 올릴 값이 충분합니다. 핵심은 코드모드를 돌린 뒤 캐싱 전략만 수동 점검할 여유가 있을 때 마이그레이션하는 것입니다.
더 깊게 공부하려면 어떤 자료를 보면 좋을까요?
가장 먼저 Next.js 공식 문서의 'Upgrading to Version 15' 가이드를 정독하세요. async Request API, 캐싱 기본값 변경, 코드모드 적용 순서가 항목별로 정리돼 있어 본문 체크리스트를 그대로 확장할 수 있습니다. 캐싱 동작을 제대로 이해하려면 Caching 챕터에서 fetch의 cache·next.revalidate 옵션과 route segment config(export const revalidate)를 함께 보시는 게 좋습니다. PPR은 아직 실험적 기능이므로 공식 문서의 Partial Prerendering 페이지에서 정적/동적 경계를 어떻게 긋는지 예제로 확인하시고, Turbopack은 별도 문서에서 지원되지 않는 webpack 설정·로더 목록을 미리 점검하면 전환 시 막히는 부분을 줄일 수 있습니다.
Next.js 15 핵심 변경사항 총정리, 한 줄로 정리하면 어떻게 되나요?
Next.js 15는 Turbopack 안정화로 개발 서버 HMR이 크게 빨라지고, fetch 캐싱 기본값이 no-cache로 바뀌었으며, cookies·headers·params·searchParams가 모두 async로 전환됐고, PPR로 한 페이지 안에서 정적·동적 렌더링을 섞을 수 있게 된 것이 핵심입니다. 마이그레이션에서 가장 자주 터지는 이슈는 캐싱 기본값 변경이라, 기존에 자동 캐시에 의존하던 fetch에는 next.revalidate나 cache: force-cache를 명시해야 합니다. 실무적으로는 npx @next/codemod로 breaking change 대부분을 자동 수정한 뒤 캐싱 전략만 손으로 점검하면 된다는 것이 결론입니다.
nextjsreact프론트엔드업데이트마이그레이션
