집중 맞은 도둑력

Next.js 15 변경 사항 [번역] 본문

Nextjs

Next.js 15 변경 사항 [번역]

rainbowjyp 2024. 11. 22. 09:51

[출처] https://nextjs.org/blog/next-15

위 Nextjs 블로그 글을 한국말로 번역한 내용입니다.

 

Next.js 15가 공식적으로 안정화되어 프로덕션 사용이 가능해졌습니다. 이번 릴리스는 RC1과 RC2의 업데이트를 기반으로 합니다. 우리는 안정성에 중점을 두면서도 여러분이 좋아할 만한 흥미로운 업데이트를 추가했습니다. 지금 바로 Next.js 15를 사용해보세요:

# Use the new automated upgrade CLI 새로운 자동 업그레이드 CLI 사용
npx @next/codemod@canary upgrade latest
 
# ...or upgrade manually ...또는 수동으로 업그레이드
npm install next@latest react@rc react-dom@rc

또한 이번 주 목요일(10월 24일)에 열리는 Next.js Conf에서 앞으로의 계획에 대해 더 자세히 공유하게 되어 기쁩니다.

Next.js 15의 새로운 기능:

@next/codemod CLI를 통한 원활한 업그레이드

우리는 모든 주요 Next.js 릴리스와 함께 코드 변환을 자동화하는 codemods를 포함하여, 파괴적인 변경 사항을 업그레이드하는 데 도움을 줍니다.

업그레이드를 더욱 원활하게 하기 위해, 향상된 codemod CLI를 출시했습니다:

터미널

npx @next/codemod@canary upgrade latest

이 도구는 코드베이스를 최신 안정 버전 또는 프리릴리스 버전으로 업그레이드하는 데 도움을 줍니다. CLI는 종속성을 업데이트하고, 사용 가능한 codemods를 보여주며, 이를 적용하는 방법을 안내합니다.

canary 태그는 codemod의 최신 버전을 사용하고, latest는 Next.js 버전을 지정합니다. 우리는 최신 Next.js 버전으로 업그레이드하더라도 codemod의 canary 버전을 사용하는 것을 권장합니다. 이는 여러분의 피드백을 바탕으로 도구에 대한 개선을 계속 추가할 계획이기 때문입니다.

Next.js codemod CLI에 대해 더 알아보세요.

Async Request APIs (Breaking Change)

전통적인 서버 사이드 렌더링에서는 서버가 요청을 기다린 후에야 콘텐츠를 렌더링합니다. 그러나 모든 컴포넌트가 요청 특정 데이터에 의존하는 것은 아니므로, 요청을 기다리지 않고도 렌더링할 수 있습니다. 이상적으로는 서버가 요청이 도착하기 전에 가능한 한 많은 작업을 준비하는 것이 좋습니다. 이를 가능하게 하고 향후 최적화를 위한 기반을 마련하기 위해, 요청을 기다려야 할 시점을 알아야 합니다.

따라서, 헤더, 쿠키, 파라미터 및 searchParams와 같은 요청 특정 데이터에 의존하는 API를 비동기로 전환하고 있습니다.

import { cookies } from 'next/headers';
 
export async function AdminPanel() {
  const cookieStore = await cookies();
  const token = cookieStore.get('token');
 
  // ...
}

이는 획기적인 변경 사항이며, 다음 API에 영향을 미칩니다:

  • cookies
  • headers
  • draftMode
  • layout.js, page.js, route.js, default.js, generateMetadata, generateViewport의 params
  • page.js의 searchParams

더 쉬운 마이그레이션을 위해, 이러한 API는 일시적으로 동기적으로 접근할 수 있지만, 다음 주요 버전까지 개발 및 프로덕션에서 경고가 표시됩니다. 마이그레이션을 자동화하기 위한 codemod가 제공됩니다:

터미널

npx @next/codemod@canary next-async-request-api .

codemod가 코드를 완전히 마이그레이션할 수 없는 경우, 업그레이드 가이드를 읽어보시기 바랍니다. 또한 Next.js 애플리케이션을 새로운 API로 마이그레이션하는 방법에 대한 예제를 제공했습니다.

Caching Semantics

Next.js App Router는 의견이 반영된 캐싱 기본값과 함께 출시되었습니다. 이는 기본적으로 가장 성능이 좋은 옵션을 제공하도록 설계되었으며, 필요할 경우 선택적으로 해제할 수 있습니다.

여러분의 피드백을 바탕으로, 우리는 caching heuristics과 그것이 부분적으로 프리렌더링(Partial Prerendering, PPR) 및 fetch를 사용하는 서드파티 라이브러리와 어떻게 상호작용할지를 재평가했습니다.

Next.js 15에서는 GET 라우트 핸들러와 클라이언트 라우터 캐시의 기본 캐싱을 기본적으로 캐시됨에서 기본적으로 캐시되지 않음으로 변경합니다. 이전 동작을 유지하려면 캐싱을 계속 선택할 수 있습니다.

우리는 앞으로 몇 달 동안 Next.js의 캐싱을 개선할 것이며, 곧 더 많은 세부 정보를 공유할 예정입니다.

GET 라우트 핸들러는 더 이상 기본적으로 캐시되지 않습니다

Next.js 14에서는 GET HTTP 메서드를 사용하는 라우트 핸들러가 동적 함수나 동적 구성 옵션을 사용하지 않는 한 기본적으로 캐시되었습니다. 그러나 Next.js 15에서는 GET 함수가 기본적으로 캐시되지 않습니다.

여전히 export dynamic = 'force-static'와 같은 정적 라우트 구성 옵션을 사용하여 캐싱을 선택할 수 있습니다.

sitemap.ts, opengraph-image.tsx, icon.tsx와 같은 특별한 라우트 핸들러 및 기타 메타데이터 파일은 동적 함수나 동적 구성 옵션을 사용하지 않는 한 기본적으로 정적입니다.

클라이언트 라우터 캐시는 더 이상 페이지 컴포넌트를 기본적으로 캐시하지 않습니다

Next.js 14.2.0에서는 라우터 캐시의 사용자 정의 구성을 허용하기 위해 실험적인 staleTimes 플래그를 도입했습니다.

Next.js 15에서는 이 플래그가 여전히 접근 가능하지만, 기본 동작을 페이지 세그먼트에 대해 staleTime을 0으로 변경합니다. 이는 앱을 탐색할 때 클라이언트가 탐색의 일환으로 활성화된 페이지 컴포넌트에서 항상 최신 데이터를 반영함을 의미합니다. 그러나 여전히 변경되지 않은 중요한 동작이 있습니다:

  • 공유 레이아웃 데이터는 부분 렌더링을 지원하기 위해 서버에서 다시 가져오지 않습니다.
  • 뒤로/앞으로 탐색은 여전히 캐시에서 복원되어 브라우저가 스크롤 위치를 복원할 수 있도록 합니다.
  • loading.js는 5분 동안 캐시됩니다(또는 staleTimes.static 구성의 값).

이전 클라이언트 라우터 캐시 동작을 유지하려면 다음 구성을 설정할 수 있습니다:

// next.config.ts
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 30,
    },
  },
};
 
export default nextConfig;

React 19

Next.js 15 릴리스의 일환으로, 우리는 다가오는 React 19 릴리스와 일치하기로 결정했습니다.

버전 15에서는 App Router가 React 19 RC를 사용하며, 커뮤니티 피드백을 바탕으로 Pages Router에 대한 React 18의 하위 호환성도 도입했습니다. Pages Router를 사용하는 경우, 준비가 되면 React 19로 업그레이드할 수 있습니다.

React 19는 아직 RC 단계에 있지만, 실제 애플리케이션에서의 광범위한 테스트와 React 팀과의 긴밀한 협업을 통해 안정성에 대한 확신을 얻었습니다. 핵심 파괴적 변경 사항은 잘 테스트되었으며 기존 App Router 사용자에게 영향을 미치지 않습니다. 따라서 우리는 Next.js 15를 현재 안정 버전으로 출시하기로 결정했으며, 여러분의 프로젝트가 React 19 GA에 완전히 준비될 수 있도록 했습니다.

전환이 가능한 한 원활하게 이루어질 수 있도록, 우리는 마이그레이션 프로세스를 돕기 위한 codemods와 자동화 도구를 제공했습니다.

Next.js 15 업그레이드 가이드, React 19 업그레이드 가이드, 그리고 React Conf 기조 연설을 시청하여 더 많은 정보를 알아보세요.

React 18의 Pages Router

Next.js 15는 React 18에 대한 Pages Router의 하위 호환성을 유지하여 사용자가 Next.js 15의 개선 사항을 누리면서도 React 18을 계속 사용할 수 있도록 합니다.

첫 번째 릴리스 후보(RC1) 이후, 우리는 커뮤니티 피드백을 바탕으로 React 18에 대한 지원을 포함하는 데 초점을 맞추었습니다. 이러한 유연성 덕분에 React 18을 사용하는 Pages Router와 함께 Next.js 15를 채택할 수 있어 업그레이드 경로에 대한 더 큰 제어권을 제공합니다.

참고: React 18에서 Pages Router를 실행하고 React 19에서 App Router를 실행하는 것은 가능하지만, 이 설정은 권장하지 않습니다. 이렇게 하면 두 버전 간의 기본 API와 렌더링 논리가 완전히 일치하지 않을 수 있어 예측할 수 없는 동작과 타입 불일치가 발생할 수 있습니다.

React 컴파일러 (실험적)

React Compiler는 Meta의 React 팀이 만든 새로운 실험적 컴파일러입니다. 이 컴파일러는 일반 JavaScript 의미론과 React 규칙에 대한 이해를 통해 코드의 깊은 수준을 이해하여 자동 최적화를 추가할 수 있습니다. 컴파일러는 개발자가 useMemo 및 useCallback과 같은 API를 통해 수동으로 메모이제이션을 수행해야 하는 양을 줄여 코드가 더 간단하고 유지 관리가 쉬우며 오류가 발생할 가능성을 줄입니다.

Next.js 15에서는 React 컴파일러에 대한 지원을 추가했습니다. React 컴파일러 및 사용 가능한 Next.js 구성 옵션에 대해 더 알아보세요.

참고: React 컴파일러는 현재 Babel 플러그인으로만 제공되며, 이로 인해 개발 및 빌드 시간이 느려질 수 있습니다.

Hydration errors 개선

Next.js 14.1에서는 오류 메시지와 hydration errors를 개선했습니다. Next.js 15는 개선된 hydration errors view를 추가하여 이러한 개선을 계속 이어갑니다. hydration errors는 이제 오류의 소스 코드를 표시하고 문제를 해결하는 방법에 대한 제안을 제공합니다.

예를 들어, 다음은 Next.js 14.1에서의 hydration error message 메시지였습니다:

 

 

Next.js 15 has improved this to:

Turbopack Dev

우리는 next dev --turbo가 이제 안정화되었으며, 여러분의 개발 경험을 향상시키기 위해 준비되었다고 발표하게 되어 기쁩니다. 우리는 이를 사용하여 http://vercel.com , http://nextjs.org , v0 및 기타 모든 애플리케이션에서 훌륭한 결과를 얻었습니다.

예를 들어, 대규모 Next.js 애플리케이션인 vercel.com에서는 다음과 같은 성과를 보았습니다:

  • 최대 76.7% 더 빠른 로컬 서버 시작.
  • 최대 96.3% 더 빠른 코드 업데이트(빠른 새로 고침 사용).
  • 캐싱 없이 초기 라우트 컴파일이 최대 45.8% 더 빨라짐(현재 Turbopack은 디스크 캐싱을 지원하지 않음).

Turbopack Dev에 대한 자세한 내용은 우리의 새로운 블로그 게시물을 통해 확인할 수 있습니다.

Static Route Indicator

Next.js는 이제 개발 중에 정적 라우트 표시기를 표시하여 어떤 라우트가 정적이고 어떤 라우트가 동적인지를 식별하는 데 도움을 줍니다. 이 시각적 신호는 페이지가 어떻게 렌더링되는지를 이해함으로써 성능을 최적화하는 데 더 쉽게 만들어 줍니다.

또한, next build 출력을 사용하여 모든 라우트의 렌더링 전략을 확인할 수 있습니다.

이 업데이트는 Next.js의 가시성을 향상시키기 위한 지속적인 노력의 일환으로, 개발자가 애플리케이션을 모니터링하고 디버깅하며 최적화하는 데 더 쉽게 만들고자 합니다. 우리는 또한 전용 개발자 도구를 개발 중이며, 더 많은 세부 정보는 곧 공개될 예정입니다.

정적 라우트 표시기에 대해 더 알아보세요. 이 기능은 비활성화할 수 있습니다.

Executing code after a response with unstable_after (Experimental)

사용자 요청을 처리할 때, 서버는 일반적으로 응답을 계산하는 것과 직접 관련된 작업을 수행합니다. 그러나 로깅, 분석 및 기타 외부 시스템 동기화와 같은 작업을 수행해야 할 수도 있습니다.

이러한 작업은 응답과 직접적으로 관련이 없기 때문에 사용자가 이들이 완료될 때까지 기다릴 필요는 없습니다. 응답 후 작업을 연기하는 것은 서버리스 함수가 응답이 종료된 직후에 계산을 중단하기 때문에 도전 과제가 됩니다.

after()는 이러한 문제를 해결하는 새로운 실험적 API로, 응답 스트리밍이 완료된 후 작업을 처리하도록 예약할 수 있게 해주어, 기본 응답을 차단하지 않고 보조 작업을 실행할 수 있습니다.

이를 사용하려면 next.config.js에 experimental.after를 추가하세요:

// next.config.ts
const nextConfig = {
  experimental: {
    after: true,
  },
};
 
export default nextConfig;

그런 다음, 서버 컴포넌트, 서버 액션, 라우트 핸들러 또는 미들웨어에서 함수를 가져옵니다.

import { unstable_after as after } from 'next/server';
import { log } from '@/app/utils';
 
export default function Layout({ children }) {
  // 보조 작업
  after(() => {
    log();
  });
 
  // 기본 작업
  return <>{children}</>;
}

unstable_after에 대해 더 알아보세요.

instrumentation.js (Stable)

register() API가 포함된 instrumentation 파일은 사용자가 Next.js 서버 라이프사이클에 접근하여 성능을 모니터링하고, 오류의 출처를 추적하며, OpenTelemetry와 같은 가시성 라이브러리와 깊이 통합할 수 있도록 합니다.

이 기능은 이제 안정화되었으며, experimental.instrumentationHook 구성 옵션은 제거할 수 있습니다.

또한, 우리는 Sentry와 협력하여 새로운 onRequestError 훅을 설계했습니다. 이 훅은 다음과 같은 용도로 사용할 수 있습니다:

  • 서버에서 발생한 모든 오류에 대한 중요한 컨텍스트 캡처:
    • 라우터: Pages Router 또는 App Router
    • 서버 컨텍스트: 서버 컴포넌트, 서버 액션, 라우트 핸들러 또는 미들웨어
  • 오류를 좋아하는 가시성 제공업체에 보고합니다.
export async function onRequestError(err, request, context) {
  await fetch('https://...', {
    method: 'POST',
    body: JSON.stringify({ message: err.message, request, context }),
    headers: { 'Content-Type': 'application/json' },
  });
}
 
export async function register() {
  // 좋아하는 가시성 제공업체 SDK 초기화
}

onRequestError 함수에 대해 더 알아보세요.

<Form> Component

새로운 <Form> 컴포넌트는 HTML <form> 요소를 확장하여 프리패칭, 클라이언트 사이드 내비게이션 및 점진적 향상을 제공합니다.

이는 검색 결과 페이지로 이어지는 검색 양식과 같이 새로운 페이지로 이동하는 양식에 유용합니다.

// app/page.jsx
import Form from 'next/form';
 
export default function Page() {
  return (
    <Form action="/search">
      <input name="query" />
      <button type="submit">Submit</button>
    </Form>
  );
}

<Form> 컴포넌트는 다음과 같은 기능을 제공합니다:

  • 프리패칭: 양식이 화면에 보일 때 레이아웃과 로딩 UI가 미리 가져와져 내비게이션이 빠릅니다.
  • 클라이언트 사이드 내비게이션: 제출 시 공유 레이아웃과 클라이언트 사이드 상태가 유지됩니다.
  • 점진적 향상: JavaScript가 아직 로드되지 않은 경우에도 양식은 전체 페이지 내비게이션을 통해 작동합니다.

이러한 기능을 달성하기 위해 이전에는 많은 수동 보일러플레이트 코드가 필요했습니다.

// 참고: 이는 시연 목적으로 축약되었습니다.
// 프로덕션 코드에서 사용을 권장하지 않습니다.

'use client'
 
import { useEffect } from 'react'
import { useRouter } from 'next/navigation'
 
export default function Form(props) {
  const action = props.action
  const router = useRouter()
 
  useEffect(() => {
    // 양식 대상이 URL인 경우, 미리 가져오기
    if (typeof action === 'string') {
      router.prefetch(action)
    }
  }, [action, router])
 
  function onSubmit(event) {
    event.preventDefault()
 
    // 모든 양식 필드를 가져와서 데이터 URL 인코딩으로 `router.push`를 트리거합니다.
    const formData = new FormData(event.currentTarget)
    const data = new URLSearchParams()
 
    for (const [name, value] of formData) {
      data.append(name, value as string)
    }
 
    router.push(`${action}?${data.toString()}`)
  }
 
  if (typeof action === 'string') {
    return <form onSubmit={onSubmit} {...props} />
  }
 
  return <form {...props} />
}

Learn more about the <Form> Component.

Support for next.config.ts

Next.js는 이제 TypeScript next.config.ts 파일 형식을 지원하며, 자동 완성과 타입 안전 옵션을 위한 NextConfig 타입을 제공합니다:

// next.config.ts
import type { NextConfig } from 'next';
 
const nextConfig: NextConfig = {
  /* 구성 옵션 여기에 */
};
 
export default nextConfig;

Next.js에서 TypeScript 지원에 대해 더 알아보세요.

Improvements for self-hosting

애플리케이션을 자체 호스팅할 때, Cache-Control 지시어에 대한 더 많은 제어가 필요할 수 있습니다.

일반적인 경우 중 하나는 ISR 페이지에 대해 전송되는 stale-while-revalidate 기간을 제어하는 것입니다. 우리는 두 가지 개선 사항을 구현했습니다:

  • 이제 next.config에서 expireTime 값을 구성할 수 있습니다. 이는 이전의 experimental.swrDelta 옵션이었습니다.
  • 기본 값을 1년으로 업데이트하여 대부분의 CDN이 의도한 대로 stale-while-revalidate 의미론을 완전히 적용할 수 있도록 했습니다.

또한, 기본 값을 사용하여 사용자 정의 Cache-Control 값을 덮어쓰지 않으므로, 완전한 제어가 가능하고 모든 CDN 설정과의 호환성을 보장합니다.

마지막으로, 자체 호스팅 시 이미지 최적화를 개선했습니다. 이전에는 Next.js 서버에서 이미지를 최적화하기 위해 sharp를 설치할 것을 권장했습니다. 이 권장 사항이 가끔 누락되기도 했습니다. Next.js 15부터는 sharp를 수동으로 설치할 필요가 없으며, Next.js는 next start를 사용하거나 standalone output mode로 실행할 때 자동으로 sharp를 사용합니다.

자세한 내용을 알아보려면 Next.js의 자체 호스팅에 대한 새로운 데모 및 튜토리얼 비디오를 확인하세요.

Enhanced Security for Server Actions

서버 액션(Server Actions)은 클라이언트에서 호출할 수 있는 서버 측 함수입니다. 파일의 맨 위에 'use server' 지시어를 추가하고 비동기 함수를 내보내는 방식으로 정의됩니다.

서버 액션이나 유틸리티 함수가 코드의 다른 곳에서 가져오지 않더라도, 여전히 공개적으로 접근 가능한 HTTP 엔드포인트가 됩니다. 이 동작은 기술적으로 올바르지만, 이러한 함수가 의도치 않게 노출될 수 있습니다.

보안을 개선하기 위해 다음과 같은 향상을 도입했습니다:

  • 죽은 코드 제거: 사용되지 않는 서버 액션은 클라이언트 측 JavaScript 번들에 ID가 노출되지 않도록 하여 번들 크기를 줄이고 성능을 향상시킵니다.
  • 안전한 액션 ID: Next.js는 클라이언트가 서버 액션을 참조하고 호출할 수 있도록 예측할 수 없고 비결정적인 ID를 생성합니다. 이러한 ID는 보안을 강화하기 위해 빌드 간에 주기적으로 재계산됩니다.
  • // app/actions.js 'use server';   // 이 액션은 **우리 애플리케이션에서** 사용되므로, Next.js는 // 클라이언트가 서버 액션을 참조하고 호출할 수 있도록 // 안전한 ID를 생성합니다. export async function updateUserAction(formData) {}   // 이 액션은 **우리 애플리케이션에서** 사용되지 않으므로, Next.js는 // `next build` 중에 이 코드를 자동으로 제거하고 // 공개 엔드포인트를 생성하지 않습니다. export async function deleteUserAction(formData) {}

여전히 서버 액션을 공개 HTTP 엔드포인트로 취급해야 합니다. 서버 액션 보안에 대해 더 알아보세요.

Optimizing bundling of external packages (Stable)

외부 패키지를 번들링하면 애플리케이션의 콜드 스타트 성능을 개선할 수 있습니다. App Router에서는 외부 패키지가 기본적으로 번들링되며, 새로운 serverExternalPackages 구성 옵션을 사용하여 특정 패키지를 제외할 수 있습니다.

Pages Router에서는 외부 패키지가 기본적으로 번들링되지 않지만, 기존의 transpilePackages 옵션을 사용하여 번들링할 패키지 목록을 제공할 수 있습니다. 이 구성 옵션을 사용하면 각 패키지를 지정해야 합니다.

App Router와 Pages Router 간의 구성을 통일하기 위해, App Router의 기본 자동 번들링과 일치하도록 새로운 옵션인 bundlePagesRouterDependencies를 도입하고 있습니다. 필요에 따라 serverExternalPackages를 사용하여 특정 패키지를 제외할 수 있습니다.

// next.config.ts
const nextConfig = {
  // Pages Router에서 외부 패키지를 자동으로 번들링합니다:
  bundlePagesRouterDependencies: true,
  // App과 Pages Router 모두에서 특정 패키지를 번들링에서 제외합니다:
  serverExternalPackages: ['package-name'],
};
 
export default nextConfig;

외부 패키지 최적화에 대해 더 알아보세요.

ESLint 9 Support

Next.js 15는 ESLint 8의 지원 종료(2024년 10월 5일)에 따라 ESLint 9에 대한 지원도 도입합니다.

원활한 전환을 보장하기 위해 Next.js는 하위 호환성을 유지하므로 ESLint 8 또는 9를 계속 사용할 수 있습니다.

ESLint 9로 업그레이드할 경우, 새로운 Config 형식을 아직 채택하지 않은 경우 Next.js는 자동으로 ESLINT_USE_FLAT_CONFIG=false 이스케이프 해치를 적용하여 마이그레이션을 용이하게 합니다.

또한, —ext 및 —ignore-path와 같은 더 이상 사용되지 않는 옵션은 next lint를 실행할 때 제거됩니다. ESLint 10에서는 이러한 이전 구성을 허용하지 않을 예정이므로, 가능한 한 빨리 마이그레이션을 시작하는 것을 권장합니다.

이러한 변경 사항에 대한 자세한 내용은 마이그레이션 가이드를 확인하세요.

이번 업데이트의 일환으로, React Hooks 사용에 대한 새로운 규칙을 도입하는 eslint-plugin-react-hooks를 v5.0.0으로 업그레이드했습니다. eslint-plugin-react-hooks@5.0.0의 변경 로그에서 모든 변경 사항을 검토할 수 있습니다.

Development and Build Improvements

서버 컴포넌트 HMR

개발 중에 서버 컴포넌트는 저장할 때마다 다시 실행됩니다. 이는 API 엔드포인트나 서드파티 서비스에 대한 모든 fetch 요청도 호출된다는 것을 의미합니다.

로컬 개발 성능을 개선하고 청구되는 API 호출로 인한 잠재적 비용을 줄이기 위해, 이제 핫 모듈 교체(Hot Module Replacement, HMR)가 이전 렌더링의 fetch 응답을 재사용할 수 있도록 보장합니다.

서버 컴포넌트 HMR 캐시에 대해 더 알아보세요.

앱 라우터를 위한 더 빠른 정적 생성

정적 생성을 최적화하여 빌드 시간을 개선했습니다. 특히 느린 네트워크 요청이 있는 페이지에 대해 더욱 효과적입니다.

이전에는 정적 최적화 프로세스가 페이지를 두 번 렌더링했습니다. 한 번은 클라이언트 사이드 내비게이션을 위한 데이터를 생성하고, 두 번째는 초기 페이지 방문을 위한 HTML을 렌더링하기 위해서였습니다. 이제는 첫 번째 렌더링을 재사용하여 두 번째 패스를 생략하고, 작업량과 빌드 시간을 줄였습니다.

또한, 정적 생성 작업자는 이제 페이지 간에 fetch 캐시를 공유합니다. fetch 호출이 캐싱을 선택 해제하지 않는 경우, 그 결과는 동일한 작업자가 처리하는 다른 페이지에서 재사용됩니다. 이는 동일한 데이터에 대한 요청 수를 줄입니다.

고급 정적 생성 제어 (실험적)

더 큰 제어가 필요한 고급 사용 사례를 위해 정적 생성 프로세스에 대한 더 많은 제어를 위한 실험적 지원을 추가했습니다.

특정 요구 사항이 없는 한 현재 기본값을 유지하는 것이 좋습니다. 이러한 옵션은 리소스 사용량 증가 및 동시성 증가로 인한 잠재적인 메모리 부족 오류를 초래할 수 있습니다.

// next.config.ts
const nextConfig = {
  experimental: {
    // 빌드 실패 전에 Next.js가 실패한 페이지 생성 시도를 몇 번 재시도할지
    staticGenerationRetryCount: 1,
    // 작업자당 처리할 페이지 수
    staticGenerationMaxConcurrency: 8,
    // 새로운 내보내기 작업자를 시작하기 전 최소 페이지 수
    staticGenerationMinPagesPerWorker: 25,
  },
}
 
export default nextConfig;

정적 생성 옵션에 대해 더 알아보세요.

Other Changes