Next.js 16의 'use cache'

요청이 아니라 함수와 컴포넌트를 캐시해

Next.js 16은 'use cache' 지시어를 도입했어. fetch() 응답 하나뿐 아니라 함수나 컴포넌트의 전체 결과를 캐시할 수 있는 기본 요소야. 실험적이던 unstable_cache보다 선언 위치와 의도가 또렷해.

API	맡는 일
`'use cache'`	함수나 컴포넌트 결과를 캐시 대상으로 선언해.
`cacheLife(profile)`	캐시가 오래됨·재검증·만료되는 시간을 정해.
`cacheTag(...tags)`	나중에 요청형 무효화할 이름을 결과에 붙여.

수명은 프로필로 표현해

'seconds', 'minutes', 'hours', 'days', 'weeks', 'max' 같은 내장 cacheLife 프로필을 쓸 수 있어. 요구가 더 정확하면 stale, revalidate, expire를 각각 정한 사용자 프로필을 만들어.

부분 사전 렌더링과 조합돼

캐시한 컴포넌트는 Partial Prerendering에서 빌드 시점의 정적 셸 일부가 될 수 있고, 같은 라우트의 캐시하지 않은 부분은 동적으로 남아. 페이지 전체를 정적 또는 동적으로만 나누지 않고 데이터 수명별로 경계를 세우는 도구야.

use cache를 붙이기 전에 함수의 입력과 숨은 의존성을 적어. 사용자 세션이나 현재 시각처럼 결과를 바꾸는 값이 캐시 키에 드러나지 않으면 다른 요청의 결과를 재사용할 수 있어. cacheLife는 신선도, cacheTag는 변경 경로와 짝지어 함께 설계해. 캐시 단위를 정한 뒤에는 같은 입력의 재사용과 다른 입력의 분리를 로그로 증명해. 태그 하나가 너무 넓으면 작은 변경도 많은 결과를 버리고, 너무 좁으면 오래된 값이 남아. 컴포넌트 단위 캐시가 있다고 fetch 캐시를 전부 대체할 필요는 없어. 외부 응답 자체를 여러 소비자가 공유하면 fetch 캐시가 맞고, DB query와 렌더 결과를 한 단위로 재사용하면 use cache가 자연스러워. 가장 작은 재사용 단위가 아니라 의미가 안정된 단위를 골라. 느린 DB 함수를 use cache로 감싸 호출 횟수를 로그로 세고, 내장·사용자 cacheLife 프로필의 stale·revalidate·expire 시점을 확인해. 변경 액션에서 세밀한 tag만 갱신해 같은 라우트의 다른 캐시 영역이 유지되는지도 봐.

Code

컴포넌트 전체 캐시하기·tsx

'use cache';
import { cacheLife } from 'next/cache';

export default async function ProductList() {
  cacheLife('hours');
  const products = await db.product.findMany();
  return (
    <ul>
      {products.map(p => <li key={p.id}>{p.name} — ${p.price}</li>)}
    </ul>
  );
}

함수 캐시에 무효화 태그 붙이기·ts

'use cache';
import { cacheTag } from 'next/cache';

export async function getProduct(id: string) {
  cacheTag('products', `product-${id}`);
  return db.product.findUnique({ where: { id } });
}

// 서버 액션 안:
import { updateTag } from 'next/cache';

export async function updateProduct(id: string, data: FormData) {
  'use server';
  await db.product.update({ where: { id }, data: { /* … */ } });
  updateTag(`product-${id}`); // 이 상품의 캐시만 무효화
}

요청이 아니라 함수와 컴포넌트를 캐시해

수명은 프로필로 표현해

부분 사전 렌더링과 조합돼

Code

External links

Exercise

Progress

댓글 0