Next.js/렌더링/Lesson 05
데이터 페칭 — fetch 캐시 정책 4가지 + revalidate
35분·theory
이 챕터
2/5
TypeScript
데이터 페칭 — fetch 캐시 정책 4가지 + revalidate
💡 왜 배워야 할까요? — '캐시 정책' 이 페이지 속도를 결정한다
🎯
Pages Router 의 `getStaticProps`(SSG) · `getServerSideProps`(SSR) · ISR 옵션이 전부 **fetch 의 옵션 하나**로 통합됐습니다.
💼
fetch 가 자동으로 dedupe + 캐시되므로, '같은 데이터를 여러 컴포넌트에서 부르면 비효율' 이라는 옛 걱정이 사라집니다.
⚡
`revalidate` (시간 기반) + `tags` (수동 무효화) 조합으로 페이지마다 신선도 정책을 정확히 정할 수 있습니다.
🔗
이걸 모르면 모든 페이지가 기본 SSG 로 캐시돼 '새 글 썼는데 안 보임' 문제가 생기거나, 반대로 `no-store` 남발로 서버 부하가 늘어납니다.
🏢 실무에서는
codemaster40 의 학습 콘텐츠는 거의 안 바뀌므로 SSG (force-cache) 가 적합합니다. 반면 사용자 진도·북마크는 사용자별로 다르고 자주 바뀌니 `no-store`. 게시판·댓글 같은 콘텐츠는 1~5분 `revalidate` 가 균형점. 이 결정을 매 fetch 호출 단위로 내릴 수 있는 게 App Router 의 강점입니다.
fetch 캐시 정책 4가지 + revalidate 방법
1. 기본 — force-cache (SSG)
빠르지만 데이터가 바뀌면 반영 안 됨. 불변에 가까운 데이터에 적합.
2. no-store (SSR)
항상 최신. 사용자별 데이터·시세·재고처럼 매 요청 신선도가 중요한 데이터.
3. revalidate (ISR — Incremental Static Regeneration)
캐시의 빠름 + 신선도. 블로그·문서·자주 안 바뀌지만 가끔 갱신.
4. tags + revalidateTag (수동 무효화)
돌발 갱신 (글 작성 직후 등) 에 적합. ISR + tags 가 실무 표준 조합.
5. 경로 단위 무효화 — revalidatePath
6. 정리 — 언제 무엇을?
💡 💡 Next.js 데이터 페칭 실전 5
1. 기본은 force-cache — 모르면 캐시된다
빌드 시 fetch 하고 영구 캐시. 데이터가 바뀌어도 안 보이는 이유 1위.
2. revalidate 시간 정하기 휴리스틱
- ▸콘텐츠가 분당 1회 미만 바뀜 → 60
- ▸시간당 몇 번 → 300
- ▸거의 안 바뀜 → 3600 이상 또는 무한 (force-cache + tags)
3. tags 와 revalidateTag 조합이 가장 강력
글 작성·수정·삭제 액션에서 revalidateTag('posts') 한 줄이면 관련 캐시 전부 무효화.
4. 같은 URL 은 자동 dedup — 호출 횟수 걱정 X
같은 렌더링 안에서 fetch('/api/me') 를 여러 컴포넌트에서 호출해도 실제 네트워크 요청은 1번.
5. cookies()·headers() 를 호출하면 자동 dynamic
fetch 캐시 모드와 무관하게 페이지가 dynamic 으로 전환됨.
⚡ 직접 실행해보기 — 캐시 정책 시뮬레이터
각 fetch 호출의 캐시 정책이 페이지 신선도에 어떤 영향을 주는지 시뮬레이션합니다.
✏️ JS 코드
📟 콘솔 출력
▶ 실행 버튼을 눌러보세요
⚠️ 브라우저 샌드박스에서 실행 — console.log()만 지원, alert/fetch 불가
확인 퀴즈
Next.js App Router 의 `fetch(url)` (옵션 없음) 의 기본 캐시 동작은?
먼저 읽으면 좋은 개념: Server Component — DB 직접 접근, 0KB 번들