[Next.js] App Router - 풀 라우트 캐시 (Full Route Cache)

개념 설명

• 풀 라우트 캐시는 Next.js 서버가 빌드 타임(Build Time) 또는 재검증(Revalidation) 시점에 렌더링된 결과물(HTML 및 Payload)을 서버 메모리나 디스크에 저장하는 기능
• 사용자가 페이지를 요청할 때마다 서버에서 매번 리액트 컴포넌트를 실행하고 HTML을 생성하는 비용을 절감하여 응답 속도를 극적으로 높이는 것이 핵심 목적

---

사용 상황 예시

• 블로그 포스트 및 뉴스 기사: 내용이 자주 바뀌지 않고 모든 사용자에게 동일한 내용을 보여줘야 하는 페이지에 최적.
• 회사 소개 및 랜딩 페이지: 정적인 정보 위주로 구성되어 빠른 초기 로딩 속도가 필수적인 페이지에 적합.
• 상품 상세 페이지: 데이터 캐싱과 결합하여 수만 개의 상품 페이지를 미리 생성해두고 즉각적으로 응답할 때 사용.

---

기본 문법 및 설정 방식

Next.js 13+ (App Router)에서는 별도의 설정 없이도 기본적으로 Static Rendering을 지향함.

동적 함수 사용	데이터 캐시 사용	페이지 분류	Full Route Cache 적용
Yes	No	Dynamic Page	미사용 (매 요청 시 렌더링)
Yes	Yes	Dynamic Page	미사용 (매 요청 시 렌더링)
No	No	Dynamic Page	미사용 (캐시되지 않은 데이터 포함)
No	Yes	Static Page	사용 (최초 렌더링 후 저장)

// 1. 기본 Static Page (Full Route Cache 대상)
export default async function Page() {
  const res = await fetch('https://api.example.com/data'); // 기본값: cache: 'force-cache'
  const data = await res.json();
  
  return <div>{data.title}</div>;
}

// 2. Dynamic Page로 강제 전환 (Cache 미적용)
export const dynamic = 'force-dynamic'; 
// 또는 쿠키, 헤더, searchParams 사용 시 자동 전환

---

자주 하는 실수

• 데이터 캐시와 혼동: Data Cache(데이터 fetch 결과 저장)와 Full Route Cache(렌더링 결과 저장)를 동일하게 생각하는 경우 발생. 데이터는 캐싱되어도 페이지 자체가 Dynamic이면 렌더링 과정은 매번 수행됨.
• 동적 함수 사용 인지 부족: cookies()나 headers()를 컴포넌트 내에서 호출하면 해당 페이지가 자동으로 Dynamic Page가 되어 풀 라우트 캐시 혜택을 받지 못함을 간과함.
• 개발 모드에서의 오해: 개발 환경(next dev)에서는 매번 최신 코드를 반영하기 위해 풀 라우트 캐시가 작동하지 않음. 반드시 next build 후 next start를 통해 성능 확인 필요.

핵심 요약

1. 빌드 시점의 HTML/Payload 서버 저장 기술
2. 정적 페이지(Static Page) 판정 시 자동 적용
3. 동적 함수 미사용 및 데이터 캐싱 활성화 필수

출처: 한 입 크기로 잘라먹는 Next.js(v15)