🚀 Next.js 심화 2장: `use cache`와 부분 캐싱 (Next.js 15+ 최신 트렌드)

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 🧩 use cache 디렉티브: 함수 수준의 영구 동결 🟢
• 🌱 컴포넌트 단위 캐싱 (Cache Components) 🟡
• 🛡️ PPR (Partial Pre-Rendering): 정적 껍데기 + 동적 속살 🔴
• 💥 에러 해결 카탈로그
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 15분 (전체) / 핵심 파트만: 8분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(신입): "Next.js 14에서 15로 버전을 올렸더니, 옛날처럼 무식하게 평생 캐싱을 안 해줘서 사이트는 신선해졌는데 디비 통신 비용이 너무 나와요! 무거운 통계 컴포넌트는 다시 14 시절처럼 서버에 얼려두고 싶은데, fetch 옵션에 덕지덕지 cache: 'force-cache' 붙이는 거 말고 좀 우아한 방법 없을까요?"
• 영호(리드): "영철 님... Vercel 놈들이 15버전부터 던져준 강력한 마법, 'use cache' 디렉티브를 써보세요! 파일 맨 위, 함수 바로 위, 심지어 특정 컴포넌트 블록 위에 선언하는 순간 그 조각 덩어리만 핀셋으로 집어서 영원한 빙하 속(Data Cache)에 화석으로 만들어버린다고요!"

🗺️ 이 문서의 흐름
Next 15의 캐시 선언형 시대 → use cache의 스코프 적용법 → 대망의 PPR (절반만 화석 만들기) 기술

🎯 이 문서를 다 읽으면 할 수 있는 것

• 무거운 써드파티 SDK나 직접 짠 슬로우 쿼리 함수 자체에 'use cache' 지시자를 달아 컴포넌트 레벨의 캐싱 아키텍처를 세밀하게 직조할 수 있다.
• 정적인 껍데기 안에 실시간 데이터를 품은 <Suspense> 구역을 섞어, PPR 아키텍처의 혁명적인 TTFB(0.1초 초기 로딩)를 구현할 수 있다.

🤔 왜 알아야 하는가

심화 1장에서 우리는 끔찍한 캐시 지옥을 봤어. Next.js 13, 14 버전은 기본적으로 모든 fetch를 평생 캐싱해버리는 거대한 폭군이었기 때문이지.
원성이 너무 빗발치자, Next.js 15버전부터는 패러다임을 "기본은 매번 새 데이터를 가져오는 동적(Dynamic) 통신이다! 니가 진정으로 원할 때만 캐시를 선언해라(opt-in)!" 로 아예 180도 뒤집어버렸어.

이 새로운 선언적 캐싱 시대에서 프론트 시니어들에게 가장 핫한 무기가 바로 심화 2장의 주제인 'use cache' 예약어와 PPR(부분 렌더링) 이야.

이걸 모르면 너는 Next 15 세상에서 모든 페이지 컴포넌트를 비싼 CPU 렌더링으로 돌리다가 클라우드 요금 폭탄을 맞고 회사에서 짐을 싸게 될지도 몰라. 화면 전체 단위가 아닌, "내가 원하는 조각"만 얼려버리는 최신 핀셋 기법을 지금부터 마스터하자.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면? (영호의 빙결 마법책)

❌ 과거 14버전 (눈보라 광역 마법)
마을 전체(페이지 통째로)에 눈보라를 내려서 온 동네를 얼려버렸어. 다 꽁꽁 얼어붙어서 장사는 빠른데 눈사람이 안 움직여서 답답했어.

✅ 현재 15버전 (핀셋 빙결 마법 'use cache')
이제 영호 리드가 요술 지팡이 하나를 들고 다녀.
"얍!" 하고 지팡이('use cache')로 치는 특정 상자(함수, 컴포넌트)만 꽁꽁 얼어붙어서 (캐시 서버에 저장), 다음번 부를 땐 연산 0초 만에 완제품이 튀어나와! 마을 사람들(나머지 동적 요소)은 춥지 않고 실시간으로 막 뛰어다닐 수 있지.

🧩 use cache 디렉티브: 함수 수준의 영구 동결 🟢

'use client' 나 'use server' 처럼 파일이나 함수 스코프 최상단에 마법의 부적을 붙이는 방식이야.
주의: 아직 Next.js 공식 실험실(Experimental) 옵션을 켜야 완전히 동작하는 최첨단 스펙이다.

상황: 무거운 통계 분석 함수 (fetch가 아님!)

영철이가 짜놓은 끔찍하게 느린 5초짜리 월간 집계 쿼리가 있어. fetch로 찌르는 외부 API가 아니라, 자기가 직접 Node.js 환경에서 DB 클라이언트 모듈(Prisma 등)과 거대한 for 반복문으로 짠 함수지.

// app/lib/stats.ts
// 💣 이놈은 fetch가 아니라서 기본 Next Data Cache 은총을 받을 수 없어 매번 5초가 걸림!
export async function getHeavyMonthlyStats(year: number, month: number) {
  const rawData = await db.query(...); 
  const result = heavyCPUCalculate(rawData); // 여기서 5초간 끙끙댐...
  return result;
}

✅ 빙결 부적 붙이기 ('use cache')

놀랍게도 코드 단 한 줄 이면 এই 5초짜리 지옥을 0.01초(화석 꺼내기)로 단축할 수 있어!

// app/lib/stats.ts
 
export async function getHeavyMonthlyStats(year: number, month: number) {
  'use cache'; // 🧊 빙결 마법 발동! 이제부터 이 함수의 리턴값은 파라미터를 키값 삼아 Data Cache 레벨로 영원히 얼려짐!!
 
  const rawData = await db.query(...); 
  const result = heavyCPUCalculate(rawData); 
  return result;
}

[마법의 부작용 (부수기)]
이거 심화 1장의 React.cache() (1초 단발성 지우개) 랑 착각하면 안 돼!
'use cache'는 영구 보존되는 3단계 Data Cache 장벽에 화석을 파묻는 행위야!
즉, 누군가가 어드민 페이지에서 백날천날 매출을 갱신해도 유저는 영원히 5초 전의 (얼려진) 통계만 보게 돼.
화석을 부수려면 어떻게? 우리가 배울 강력한 저격총, revalidateTag 를 함수에 명찰로 달아주고 쏴버려야 해. (이건 심화 3장에서 더 깊이 다룰 예정)

🌱 컴포넌트 단위 캐싱 (Cache Components) 🟡

함수 말고, HTML 태그를 뿜어내는 '리액트 컴포넌트(export default function...)' 자체도 통째로 얼려버릴 수 있어!

상황: DB에서 가져온 1만 개 목록 그리기

// app/components/MegaList.tsx
 
// 🧊 이 컴포넌트 덩어리가 뿜어내는 "HTML 구조" 결과물 자체를 통째로 얼려버린다!
export default async function MegaList({ categoryId }: { categoryId: string }) {
  'use cache'; 
  
  // 1만 개 레코드를 가져와서 수만 개의 <li> 태그로 조립하는 거대한 CPU 연산
  const data = await db.getItems(categoryId);
 
  return (
    <ul>
      {data.map(item => <li key={item.id}>{item.name}</li>)}
    </ul>
  )
}

이제 page.tsx 등 아무 곳에서나 저 <MegaList /> 를 수백 번 렌더링하도록 호출해봐도, 서버는 HTML 태그 문자열 조립을 아예 생략하고 디스크 어딘가 캐시 창고에서 꺼낸 완성품 텍스트 덩어리를 0.01초 만에 브라우저에 배달해줘.
프론트 서버 요금을 획기적으로 낮추는 2026 트렌드의 핵심 기법이지.

🛡️ PPR (Partial Pre-Rendering): 정적 껍데기 + 동적 속살 🔴

자, 이제 궁극의 퀘스트. "Next.js 렌더링 최정점의 기술"로 넘어가자.

모순되는 요구사항

기획자가 왔어.
"개발자님! 우리 쇼핑몰 메인의 상단 GNB(메뉴)랑 전체 틀은 아무도 안 건드리니까 빠딱빠딱 광속(Static)으로 뜨게 해주시고요.
대신 한가운데 박혀 있는 [사용자 장바구니 영역]은 방문객 이름이랑 개인 쿠키마다 전부 다르게(Dynamic) 떠야 해요!"

심화 1장에서 배웠지? "단 한 줄의 실시간 쿠키라도 읽으면 그 페이지의 화석(Static)은 영원히 박살 나고 전체가 SSR(Dynamic)로 강등된다" 고!

✅ PPR (부분 사전 렌더링) 이라는 이단아

Vercel 천재들이 이걸 극복해냈어!
우리가 가이드 7장에서 배운 <Suspense> 구멍 뚫기 기술과 결합 된 괴물 사양이야.

// app/page.tsx
// ⚠️ 이 페이지 안에 실시간 정보(쿠키 등)가 있지만 난 절대 속도 강등을 당하지 않을 테다!
 
import { Suspense } from 'react'
import { cookies } from 'next/headers'
import StaticHeader from './StaticHeader'
 
// 1. 여기서 동적 (매 접속마다 달라지는 개인화) 데이터를 사용하는 컴포넌트 덩어리를 분리한다!
async function PersonalCart() {
  const token = (await cookies()).get('token'); // 💣 원래라면 전체 페이지 화석을 깨부수는 폭탄!!
  const cartInfo = await fetchCart(token);
  return <div>내 장바구니: {cartInfo.count}개</div>
}
 
 
// 2. 전체 조합하는 메인 컴포넌트 레이아웃
export default function HomePage() {
  return (
    <main>
      {/* 🌟 여기는 빌드 타임에 평생 보존되는 화석(Static)으로 깡깡 얼어서 0.1초 만에 서빙됨! */}
      <StaticHeader />
      
      {/* 🌟 동적 폭탄 구역을 Suspense 캡슐로 격리해 가둬버렸다! */}
      <Suspense fallback={<div>장바구니 로딩중...</div>}>
        <PersonalCart />
      </Suspense>
      
      {/* 🌟 여기도 Static! */}
      <Footer />
    </main>
  )
}

[마법의 작동 원리 (PPR 캐싱 결합)]

1. 빌드 명령(next build) 시, 넥스트 봇이 트리를 순회하다가 Suspense 캡슐을 만나면 "아하! 이 구멍(Hole) 안쪽은 폭탄 지대니까 내가 건드리면 안 되겠군. 대신 캡슐 바깥의 껍데기 레이아웃들은 모조리 정적 화석 스켈레톤(Static)으로 잔뜩 구워두자!" 하고 부분 화석을 만들어내.
2. 유저가 접속하면? 0.1초 만에 그 가운데에 구멍이 뻥 뚫린 화석 껍데기(GNB + Footer + 장바구니 로딩중 글씨)가 무조건 즉각 서빙(TTFB 폭발)됨!!
3. 그와 동시에 캡슐 안쪽의 살살 녹는 동적 장바구니 컴포넌트가 뒤늦게 쿠키를 까보고 서버 연산을 마친 뒤 그 빈 구멍을 채우러 Stream 전송된다.

이것이 Next.js가 밀어붙이는 궁극의 아키텍처, 껍데기는 화석으로! 속살은 무한한 동적 데이터로! "Partial Pre-Rendering(PPR)" 의 실체야.

💥 에러 해결 카탈로그

에러 메시지가 뜨면 Ctrl+F로 검색해봐.

❌ 'use cache' is an experimental feature...

원인: next.config.ts 계기판에 아직 실험실 옵션을 안 켜고 이 15버전 신묘함을 쓰려고 시도함.
해결책: 계기판 설정 파일에 들어가 experimental: { dynamicIO: true } 설정 등 관련 Next.js 15+ 최신 릴리즈 노트를 참고해 플래그를 수동 점검해야 한다.

❌ Suspense 캡슐을 잘 씌웠는데 빌드해보면 자꾸 속살까지 다 까발려진 채 전체 페이지가 Dynamic으로 강등당해버려요 ㅠㅠ

원인: 아주 흔한 실수.
폭탄 코드(const t = cookies().get())를 캡슐의 바깥(부모)인 page.tsx 내부 스코프에 덩그러니 선언해 두고, 그걸 속살 컴포넌트의 Props로 내려보내는 우를 범했기 때문.
부모가 쿠키 폭탄에 노출된 순간 부모의 껍데기도 함께 오염되어 영원히 화석 기능을 상실한다.
해결책: 무조건 속살 컴포넌트 스코프 내부 안쪽으로 cookies()나 리퀘스트 헤더 읽기 명령문을 통째로 격리/이전시켜야 PPR이 폭탄을 제대로 피해 간다.

🏁 이번에 배운 내용 총정리

💡 시니어의 멘탈 모델
14버전까지는 fetch 에 달린 파라미터 옵션에 목을 맸다면, 15버전부터는 함수 묶음이나 UI 조각 덩어리 자체를 핀셋으로 집어 얼려버리는 우아한 시대에 진입했다. 컴포넌트 안에서 어디 부분까지 정적인지 캡슐 구멍 뚫기(Suspense)만 잘해도 당신은 신의 경지!

📝 마무리 퀴즈

배웠으면 한 번 비틀어서 확인해봐야 해.

Q1. 영철이가 마케팅 부서의 요청을 받아 한 달 내내 똑같은 이달의 상품 목록(무거운 DB 통신) 추천 위젯인 <MonthlyPicks> 컴포넌트를 만들었다. 이놈 안에는 fetch 도 쓰지 않고 Drizzle ORM으로 비싼 쿼리가 날아간다. 그리고 그 컴포넌트 최상단에 당당히 'use cache' 를 박아 넣었다! 그런데 어느 날 마케팅 팀장이 전화를 걸어 "영철 씨, 내가 방금 어드민에서 이달의 상품 1위를 바꿔 놨는데 새로고침해도 어제 상품만 뜨잖아! 빨리 고쳐놔!" 하고 샤우팅을 날렸다. 영철이는 이 낡은 컴포넌트 얼음조각을 어떻게, 어느 타이밍에 박살 내어 갱신해야 할까?

✅ 정답: 다음 장(심화 3장)에서 배울 캐시 폭파 지시자인 revalidateTag 를 활용해야만 한다.

💡 상세 해설: 'use cache'에 명찰(cacheTag: 'monthly')을 붙이되, 마케팅 팀장이 관리자 페이지(어드민)에서 상품 [수정/저장 완료 버튼]을 누르는 액션을 캐치하여 웹훅으로 서버 단에서 revalidateTag('monthly') 지시를 내리게 아키텍처를 세팅해야 한다. 즉, 평소엔 영원히 얼려둔 채 벼룩을 누리다가 이벤트 드리븐 환경(DB 업데이트 찰나)에서만 한 방! 부수는 것이 핀셋 캐싱의 교과서이다.

🐣 영철이의 퇴근 일기

오늘은 정말 넥스트 15의 신기술인 'use cache' 와 PPR 의 매력에 푹 빠진 날이야! 예전엔 페이지 하나를 통째로 정적으로 만들지 말지 고민했는데, 이제는 내가 원하는 조각만 핀셋으로 집어서 얼려버릴 수 있다는 게 얼마나 마법 같은지 몰라.

💡 오늘의 교훈: "복잡한 캐싱 설정에 매달리지 말고, 'use cache' 와 Suspense 를 조합해 '껍데기는 정적(Static), 속살은 동적(Dynamic)' 인 궁극의 성능을 구현하자!"

영호 리드 님이 '껍바속촉(PPR)' 비유를 들어 설명해 주실 때, 사용자에게 0.1초 만에 화면을 보여주는 게 왜 그렇게 중요한지 다시 한번 느꼈어. 오늘 머리를 너무 많이 썼더니 배가 고프네. 집에 가는 길에 겉은 바삭하고 속은 촉촉한 치킨 한 마리 사 들고 가서 셀프 축합 파티를 해야지! 내일은 더 '성능에 진심인' 영철이가 될 거야! 🐣

🔗 더 알아보기

• Next.js Docs: Rendering / PPR (Partial Pre-Rendering)