Next.js 15 최신 기능 완전 분석 (2026년) — 실무에서 바로 쓰는 핵심 변경점 총정리

얼마 전 사이드 프로젝트를 진행하던 중, 팀원 한 명이 슬랙에 링크 하나를 던졌어요. “이거 Next.js 15인데, 기존이랑 완전히 다른 것 같아요.” 처음엔 대수롭지 않게 봤는데, 막상 코드를 열어보니 fetch 캐싱 동작부터 시작해서 라우팅 구조까지 손봐야 할 부분이 생각보다 많더라고요. 그때부터 본격적으로 파고들기 시작했습니다. 오늘은 Next.js 15에서 달라진 것들을 같이 살펴보면서, “왜 이런 방향으로 바뀌었는지”까지 함께 고민해 보려 합니다.

1. fetch 기본 캐싱 정책의 역전 — 가장 체감이 큰 변화

Next.js 13~14에서는 fetch가 기본적으로 캐싱(cache: ‘force-cache’)을 적용했어요. 그래서 별도 설정 없이도 정적 데이터처럼 동작했죠. 그런데 Next.js 15부터는 이 기본값이 cache: 'no-store'로 뒤집혔습니다. 즉, 아무 옵션도 안 주면 매 요청마다 서버에서 새로 fetch하는 동적 동작이 기본이 된 거예요.

이게 왜 중요하냐면, 기존 프로젝트를 15로 마이그레이션할 때 조용한 성능 저하가 발생할 수 있거든요. Vercel 내부 벤치마크 기준으로 캐싱 미적용 상태에서 반복 요청 시 응답 시간이 평균 2.3배 증가하는 케이스가 보고된 바 있습니다. 의도치 않은 동적 요청이 폭발적으로 늘어나면 비용 문제로도 이어질 수 있어요. 반드시 기존 코드베이스에서 fetch 호출부를 점검해야 할 것 같습니다.

2. React 19 정식 지원 — Server Actions가 달라졌어요

Next.js 15는 React 19를 정식으로 지원하는 첫 번째 메이저 버전입니다. 그리고 이와 맞물려 Server Actions의 안정성과 타입 추론 능력이 크게 향상됐어요. 이전까지는 Server Actions가 실험적(experimental) 플래그가 필요했거나, 에러 핸들링이 불안정하다는 피드백이 커뮤니티에서 꾸준히 나왔는데, 15에서는 useActionState 훅이 공식 React API로 통합되면서 훨씬 예측 가능한 형태로 쓸 수 있게 됐습니다.

국내 스타트업 씬에서도 반응이 나오고 있어요. 토스나 당근마켓처럼 SSR을 적극 활용하는 팀들은 Server Actions를 폼 처리 및 낙관적 업데이트(optimistic update)에 적용하면서 클라이언트 번들 사이즈를 줄이는 방향을 검토 중이라는 이야기가 개발 컨퍼런스 세션에서 언급된 바 있습니다. 해외에서는 Shopify가 Next.js App Router 기반 커머스 플랫폼의 일부를 Server Actions로 마이그레이션하면서 JS 페이로드를 약 18% 감소시켰다는 사례가 공유됐어요.

3. Turbopack 개발 서버 안정화 — 이제 쓸 만해졌습니다

Turbopack은 사실 꽤 오래전부터 베타 상태였는데, 이번 Next.js 15에서 개발 서버(dev server) 환경에서 안정 버전으로 전환됐습니다. 프로덕션 빌드는 아직 Webpack이 기본이지만, 개발 환경에서는 next dev --turbo 없이 그냥 next dev를 쓰면 자동으로 Turbopack이 동작하도록 바뀌었어요.

Vercel 공식 수치에 따르면, 대형 코드베이스 기준으로 로컬 개발 서버 최초 컴파일 속도가 Webpack 대비 최대 76.7% 빠르고, HMR(Hot Module Replacement) 반응 속도는 96.3% 향상됐다고 합니다. 페이지가 많아질수록 이 차이는 더 극적으로 느껴져요. 직접 써보니 라우트 전환 후 서버 사이드 렌더링이 즉각적으로 반영되는 느낌이 확실히 달랐습니다.

4. 비동기 Request API로의 전환 — 마이그레이션 주의 포인트

Next.js 15에서는 cookies(), headers(), params, searchParams 같은 요청 관련 API들이 이제 비동기(async)로 동작합니다. 기존에는 동기적으로 호출할 수 있었는데, 이제는 반드시 await를 붙여줘야 해요.

이 변화는 처음엔 번거롭게 느껴질 수 있지만, 이유가 있습니다. 동기 방식의 Request API는 렌더링 파이프라인을 블로킹할 수 있어서, Next.js 팀이 서버 컴포넌트의 스트리밍 최적화를 위해 비동기로 전환하는 방향을 선택했다고 봐요. 아래 항목들이 영향을 받으니 점검이 필요합니다.

• cookies() — 이제 await cookies()로 사용해야 함
• headers() — 동일하게 await headers() 필요
• 동적 라우트의 params — Page 컴포넌트의 props에서 await params로 접근
• searchParams — 동일하게 비동기 처리 필요
• 미들웨어에서의 Request 객체 — API 변경 사항 재확인 권장

Next.js 공식 codemod 도구(npx @next/codemod@canary next-async-request-api .)를 실행하면 대부분의 케이스는 자동으로 마이그레이션해 주니, 수동으로 하나하나 고치기보다 이걸 먼저 돌려보는 게 현명한 것 같습니다.

5. Partial Prerendering(PPR) — 정적과 동적의 경계가 무너진다

Partial Prerendering은 Next.js 15에서 실험적 기능(experimental)으로 포함된 개념인데, 앞으로의 방향성을 보여준다는 점에서 주목할 만합니다. 한 페이지 안에서 정적으로 렌더링할 부분과 동적으로 스트리밍할 부분을 혼합할 수 있어요.

예를 들어, 쇼핑몰 상품 상세 페이지에서 상품 이름·이미지·설명은 정적 HTML로 즉시 내려주고, 재고 수량이나 개인화된 추천 상품은 뒤이어 스트리밍으로 채우는 방식이죠. 사용자 입장에서는 페이지가 훨씬 빠르게 뜨는 것처럼 느껴집니다. Core Web Vitals 지표 중 LCP(Largest Contentful Paint) 개선에 직접적인 영향을 줄 수 있는 접근이라고 봐요.

결론 — 지금 바로 올려야 할까요, 아니면 기다려야 할까요?

솔직히 말하면, 신규 프로젝트라면 Next.js 15로 시작하는 게 맞다고 봅니다. Turbopack 개발 경험, React 19의 새로운 훅 생태계, 그리고 PPR 같은 미래 기능을 일찍 익혀두는 게 장기적으로 이득이에요. 반면 운영 중인 서비스를 마이그레이션할 때는 특히 fetch 캐싱 정책 변경과 비동기 Request API 두 가지를 우선 점검 리스트 최상단에 두는 걸 권장합니다. codemod를 먼저 돌리고, 스테이징 환경에서 충분히 검증한 뒤 프로덕션에 반영하는 게 안전한 루트일 것 같아요.

에디터 코멘트 : Next.js의 변화 방향을 보면, Vercel이 단순한 프레임워크를 넘어 “배포 플랫폼과 최적으로 통합되는 풀스택 런타임”을 만들려는 의도가 점점 뚜렷해지는 것 같습니다. 이건 기술적으로 매력적이지만, 동시에 Vercel 생태계 의존도가 높아진다는 트레이드오프이기도 해요. AWS나 자체 서버에 셀프호스팅하는 팀이라면, 각 기능이 플랫폼 독립적으로 동작하는지 반드시 확인하는 습관이 필요할 것 같습니다.