🚀 Next.js 심화 1장: Caching Deep Dive — 4중 캐시 아키텍처 파헤치기

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 🧩 1단계: Request Memoization (수명 1초의 함수 캐시) 🟢
• 🌱 2단계: Data Cache (DB 쿼리의 영구 보존) 🟡
• 🛡️ 3단계: Full Route Cache (완성된 HTML의 화석화) 🔴
• 🚥 4단계: Router Cache (클라이언트 탭 메모리) 🟣
• 💥 에러 해결 카탈로그
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

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

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

• 영철(신입): "어? 관리자 어드민 페이지에서 공지사항 제목을 뼈 빠지게 '긴급 패치 2.0'으로 수정하고 DB 저장(UPDATE)까지 완벽하게 성공시켰어요! 그런데 메인 화면으로 돌아가서 새로고침(F5)을 아무리 눌러도 예전 제목인 '긴급 패치 1.0'만 계속 떠요! 무려 30분이나 지난 지금도요. 회사 컴퓨터가 미친 건가요?!"
• 영호(리드): "영철 님... Next.js의 악마 같은 'Data Cache'와 'Full Route Cache'라는 이중 자물쇠를 안 풀었잖아요! Next.js 서버는 한 번 긁어온 정적(Static) 데이터를 억지로 때려 부수기 전까지는 지젤처럼 영원히 보존테이프를 틀어준다구요!"

🗺️ 이 문서의 흐름
Next.js 캐시의 악명 → 4가지 캐시 계층 완벽 분해 → 각 캐시의 초기화(Invalidate) 원리

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

• 내 코드가 어느 계층의 캐시에 묶여서 데이터를 갱신하지 못하고 있는지, "범인 레이어"를 정확하게 지목할 수 있다.
• Vercel 빌드 시 화면 옆에 뜨는 ○ (Static) 과 ƒ (Dynamic) 의 진짜 내부 동작 원리를 설명할 수 있다.

🤔 왜 알아야 하는가

Next.js 13+ 버전(App Router)이 처음 등장했을 때 전 세계 프론트엔드 개발자들이 "캐시 괴물"이라고 욕을 퍼부었어.
이전 버전이 "필요할 때 알아서 캐싱해줘" 였다면, App Router는 "기본값이 무조건 영구 캐싱이야! 캐싱하기 싫으면 나를 설득해봐(opt-out)!" 라는 극단적인 캐시 우선주의(Cache by default)로 바뀌었거든.

왜 이렇게까지 독하게 바꿨을까? 서버 렌더링(SSR) 위주의 웹은 구조적으로 매우 비싸고 느리기 때문이야. 사용자가 1만 명 들어올 때마다 서버가 1만 개의 HTML 공장을 돌리고 DB를 찌르면 Vercel 요금이 100배로 폭주할 테니까.

하지만 이걸 완벽하게 이해하지 못하면, 영철이처럼 하루 종일 DB 값이 업데이트 안 되는 지옥에서 헤매게 돼.
Next.js는 단일 캐시가 아니라 4개의 캐시 계층(Layer)이 마치 양파 껍질처럼 서로를 둘러싸고 있어. 이 4중 쉴드의 멘탈 모델을 머릿속에 그리는 것이 시니어의 가장 위대한 여정의 시작이야.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면? (영수네 햄버거 공장의 4중 스피드 시스템)

손님이 "빅맥 하나!" 주문했을 때 공장 내부에서 일어나는 4단계 최적화:

• 1단계 (Router Cache - 내 스마트폰): "어? 나 방금 빅맥 시켰었는데. 배달 안 시키고 내 주머니에서 아까 시킨 빅맥(사진) 꺼내서 봐야징~" (새로고침 전까지 유지)
• 2단계 (Request Memoization - 한 번 배달할 때): "이번엔 진짜 배달 시켰어. 주방장이 고기 굽는데, 내가 고기(fetch) 2번 갖다 달라고 해도 주방장이 무시하고 한 번 구운 고기를 반반 나눠줌!"
• 3단계 (Data Cache - 주방의 영구 냉동고): "어제 들어온 특제 소스(DB 결과)를 영구 냉동고에 보관해뒀어. 내일 손님이 와도, 모레 와도 안 버리고 똑같은 소스를 계속 뿌릴 거야!"
• 4단계 (Full Route Cache - 진열장의 모형 햄버거): "아예 소스, 빵, 야채를 다 조립해둔 완제품 빅맥(HTML 파일 자체)을 가게 앞에 유리장식으로 걸어뒀어! 주문 오면 주방장 안 깨우고 저 모형 바로 던져줌 ㅋㅋㅋ"

🧩 1단계: Request Memoization (수명 1초의 함수 캐시) 🟢

이건 이미 guide 6장에서 마스터한 내용이야. 가볍게 짚고 넘어가자.

특징 요약

• 목적: 깊고 복잡한 컴포넌트 트리 하위에서 데이터를 똑같이 또 호출할 때, 네크워크 부하 방지 (Props Drilling 회피)
• 대상: 오로지 GET 방식의 fetch() 함수. (그리고 수동으로 래핑한 React.cache)
• 수명: 브라우저가 화면을 갱신하는 딱 그 "한 번의 렌더링 턴(Lifecycle)" 동안만 살아있음.
• 초기화(Revalidation) 방법: 없음. 컴포넌트 렌더링이 딱 끝나는 1초 뒤에 메모리에서 연기처럼 사라짐.

🌱 2단계: Data Cache (DB 쿼리의 영구 보존) 🟡

여기서부터가 진짜 골치 아픈 놈들의 시작이야. 영철이가 30분 동안 죽어라 고생한 범인이지.

특징

• 목적: 같은 URL과 파라미터로 들어오는 외부 DB나 API 통신 결과를 디스크(서버) 어딘가에 거미줄처럼 영원히 가둬버림.
• 대상: fetch() 응답값 그 자체.
• 수명: 영구적(Permanent). 개발자가 서버를 내렸다 켜거나 강제로 지우기 전까지 10년이 지나도 그 데이터를 그대로 뱉음!

❌ 영철이의 함정 (기본 캐시 지옥)

// app/notice/page.tsx
export default async function NoticeInfo() {
  // 💣 끔찍한 함정: Next 13, 14 에서는 이걸 적는 순간 "평생 캐시" 로 동작함!
  // (Next 15부터는 다행히 no-store로 정책이 완화되었지만 14 베이스 레거시는 조심해야 함)
  const res = await fetch('https://db.api/api/notice/urgent');
  const data = await res.json();
  return <div>{data.title}</div>
}

✅ 제어권 되찾기 (Opting out)

수천 가지의 "캐시 안 해!" 탈출 방법이 있어.

1) 부분 탈출 (Fetch 레벨)
fetch(url, { cache: 'no-store' }) // Next.js야, 제발 이 쿼리만큼은 매번 실시간으로 가져오렴!

2) 파일 전체 탈출 (Segment Configuration)

export const dynamic = 'force-dynamic' // 이 파일(page) 내의 모든 로직 캐시 거부!
 
export default async function Page() { ... }

3) 시간제 보관 (ISR - Time based Revalidation)
fetch(url, { next: { revalidate: 3600 } }) // Next.js야, 이거 1시간(3600초) 카운트다운하고 캐시 폐기해.

🛡️ 3단계: Full Route Cache (완성된 HTML의 화석화) 🔴

Data Cache가 "DB 쿼리 결과(JSON)"를 조각조각 얼려두는 거라면, Full Route Cache는 더 극강의 병기야.
아예 화면 전체 HTML(JS번들 포함) 덩어리를 통째로 빌드 타임에 구워서 화석으로 만들어버려!

특징

• 목적: 서버 깡통 CPU를 아끼기 위해, 1초의 지연도 없이 번개처럼 화면을 응답하기 위한 완제품 보관.
• 수명: 영구적. 다음 빌드(Build)명령 npm run build를 새로 치기 전까지 죽지 않음.
• 조건: 2단계의 Data Cache가 하나라도 살아있는(Static) 속성의 페이지.

🔄 Static vs Dynamic 루트 판독기

터미널에서 npm run build를 쳤을 때 뜨는 성적표를 잘 봐야 해.

Route (app)                       Size     First Load JS
┌ ○ /                             154 B    86.6 kB
├ ○ /about                        154 B    86.6 kB
└ ƒ /profile/[id]                 154 B    86.6 kB
 
○  (Static)   prerendered as static HTML (uses no initial data)
ƒ  (Dynamic)  server-rendered on demand using Node.js

• ○ (Static) 판정의 비밀: 내 페이지 안에 no-store가 걸린 fetch도 없고, 브라우저 실시간 헤더 cookies(), headers(), searchParams (?id=1) 쪼가리도 단 한 개도 쓰지 않았을 때 획득! 이 축복받은 파일은 Full Route Cache에 화석으로 영구 저장되며 빛의 속도로 서빙된다.
• ƒ (Dynamic) 판정: 로그인 인증을 위해 cookies().get('token')을 한 줄이라도 쓴 순간, 아... 누군지 매번 확인해야 하네? 하면서 화석을 박살 내고 매번 SSR(즉석 렌더링)로 강등당한다.

[영철이 에러의 진상 규명]
영철이의 공지사항 페이지는 완벽한 ○ Static 파일이었어. DB 값 업데이트 로직(Admin)만 만들어 놨지, 유저가 보는 이 라우트의 HTML 덩어리 화석(Full Route Cache)과 JSON(Data Cache)을 망치로 깨부숴서 다시 구우라는 명령어(revalidatePath)를 호출하지 않았던 거야!

🚥 4단계: Router Cache (클라이언트 탭 메모리) 🟣

서버를 관리하는 위 3개의 캐시와 다르게, 마지막 방어선은 사파리/크롬 브라우저 속 사용자 컴퓨터의 메모리(RAM) 안에 살아있어.

브라우저는 똑똑하고 게으르다

Next.js App Router로 네비게이션(Link 태그 클릭)을 하면, 기존 리액트처럼 서버로 안 가고 브라우저 안에 꿍쳐둔 렌더링 조각 모음(RSC Payload)을 꺼내써.

• 수명: 브라우저 탭을 X로 닫거나 새로고침(F5)을 누르기 전까지(또는 30초~5분 내외 메모리 정책 만료 전까지).
• 이 녀석 때문에 "나 방금 글 썼는데 뒤로 가기 눌렀더니 옛날 목록 뜨네?" 같은 버그성 체감이 간헐적으로 발생해.

🔨 부수기 (Invalidation)

이 캐시가 방해가 될 때는 브라우저에게 "네임펜으로 쓴 메모 수첩 찢어버려!"라고 명령해야 해.

'use client'
import { useRouter } from 'next/navigation'
 
export default function ReRouteButton() {
  const router = useRouter()
  return <button onClick={() => router.refresh()}>강제 갱신(브라우저 캐시 부수기)!</button>
}

router.refresh() 는 화면 백지화 없이 오직 백그라운드로 서버의 최신 RSC Payload만 새로 싹 내려받아 치환하는 마법의 고급 훅이야.

💥 에러 해결 카탈로그

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

❌ Dynamic server usage: cookies 에러가 뜨면서 빌드가 폭파돼요!

원인: generateStaticParams 와 같이 '미리 정적으로(Static) 구워두려고 작정'한 파일 공간 내부에서, cookies() 나 URL 쿼리 파라미터 같이 실시간 런타임에만 알 수 있는 객체를 억지로 꺼내 쓰려다 모순이 발생한 것.
해결책: 페이지에 export const dynamic = 'force-dynamic' 을 명시적으로 선언하여 이 파일은 절대 화석(Static)으로 남을 수 없는 운명임을 Next.js에게 자백해라.

🏁 이번에 배운 내용 총정리

이 거대한 4중 장벽의 방어 순서! 브라우저가 화면을 달라고 조르면...

💡 시니어의 멘탈 모델
빌드 시 ○ (Static) 로 굳어버린 라우트는 Data Cache를 부수기 전까지 절대 자기 스스로 갱신되지 않는다.
"데이터가 안 바뀌어요!" 라는 질문에 당황하지 말고, 가장 먼저 Vercel 빌드 터미널 창을 열고 그 페이지가 ○ 인지 ƒ 인지부터 색출하라!

📝 마무리 퀴즈

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

Q1. 영철이가 회원 전용 "내 프로필 페이지(/profile/me)"를 만들었다. 이 페이지 최상단 컴포넌트에서는 const token = cookies().get('session_id') 를 호출해 유저의 쿠키를 뜯어보고 있었다. 영철이는 이 렌더링 연산 비용을 줄이기 위해 이 페이지를 Full Route Cache 화석으로 완벽하게 구워버리고 싶다! 어떻게 해야 할까?

✅ 정답: 불가능하다. 구조적으로 설계가 틀려먹었다.

💡 상세 해설: 내 프로필(me)처럼 유저마다, 접속한 브라우저 쿠키 헤더값에 따라 완전히 화면이 달라지는 고도의 개인화 페이지는 절대로 Static(정적) HTML로 한 번만 구워서 캐싱을 먹일 수 없다. cookies() 등 Dynamic Function이 찍힌 순간 이 페이지는 무조건 매 접속 시마다 새로 조립되는 ƒ (Dynamic) 렌더링으로 강등당해 작동해야 정상이다. 이걸 억지로 정적으로 묻어버리려 한다면 누군가의 개인정보가 전 세계 유저에게 평생 공유되는 대형 참사가 발생한다.

Q2. 영호 리드가 메인 뉴스 홈페이지(/news)를 구축했다. 이건 뉴스니까 정적으로 구워(Full Route Cache - Static) 응답 속도를 광속으로 뽑았는데, 편집팀에서 하루에 특종이 터질 때마다 뉴스 목록 DB가 수시로 바뀌어야 한 단다. 영호는 이 대규모 뉴스 정적 화석을 어떻게, 어느 주기마다 자동으로 쪼개고 다시 굽게 파이프라인을 세팅해야 우아할까?

✅ 정답: 가장 우아한 방법은 두 가지다.

💡 상세 해설: 첫째, 시간 타임아웃 캐싱 (ISR): revalidate: 60 속성을 먹여서, 딱 60초마다 딱 한 번만 낡은 화석을 부수고 새 뉴스 화석 HTML로 교체한다. 편집팀은 1분 정도의 딜레이만 체감하며 환호한다. 둘째, 고오급 수동 저격 무효화 (On-demand Revalidation): Admin CMS 서버에서 [기사 수정] 버튼이 눌리는 그 찰나의 순간에만 Next.js 서버로 API 웹훅 트리거를 날려, 서버 액션의 revalidatePath('/news') 마법 함수를 허공에 쏘게 만든다. 이렇게 되면 평소에는 완벽한 Static 속도로 꿀을 빨다가, 오직 편집자의 조리 도구가 눌린 그 순간에만 화석 장막이 박살 나는 궁극의 아키텍처 완성! (이 마술을 심화 3장에서 더 깊게 팔 것이다.)

🐣 영철이의 퇴근 일기

오늘은 정말 넥스트의 거대한 '캐싱 장벽' 앞에 선 기분이었어. 그동안 단순히 "캐시가 있어서 빨라요"라고만 생각했는데, 그 이면에 Router, Full Route, Request Memoization, Data Cache라는 4중 필터가 있었다니!

💡 오늘의 교훈: "데이터가 안 바뀐다면 빌드 시점에 화석(Static)으로 굽고, 유저마다 다른 정보는 동적(Dynamic)으로 렌더링하여 보안과 성능을 모두 잡자!"

영호 리드 님이 브라우저 RAM부터 서버 디스크까지 단계별로 캐싱이 작동하는 원리를 설명해 주실 때, 파편화되어 있던 지식들이 하나로 합쳐지는 짜릿함을 느꼈어. "화석이 된 HTML은 부수기 전까지 변하지 않는다"는 말씀을 가슴에 새기며... 오늘 머리를 너무 많이 썼더니 당분이 필요해. 집에 가는 길에 달콤한 마카롱이라도 좀 사 가야지. 내일은 더 '효율적인' 캐싱 전략을 짜는 개발자가 되겠어! 🐣

🔗 더 알아보기

• Next.js Docs: Building Your Application - Caching