[Next] 16. 데이터 캐싱

Next.js를 쓰다 보면 "데이터 캐싱"이라는 개념을 한 번쯤 마주하게 된다. 이건 단순히 속도만 빠르게 하자는 게 아니라, 사용자 경험과 서버 비용까지 챙기는 핵심 전략이다.

이번 글에서는 Next.js에서의 데이터 캐싱이 어떻게 동작하는지, 그리고 SSR, SSG, ISR, fetch API와의 관계에서 어떤 식으로 작동하는지를 정리해보자.

---

1️⃣ 왜 캐싱이 중요한가?

• 사용자가 동일한 데이터를 여러 번 요청할 때 서버를 매번 호출하면 리소스 낭비다.
• 데이터를 캐싱하면:
  • 응답 속도가 빨라지고 (성능 향상),
  • API 서버 트래픽이 줄어들고 (비용 절감),
  • 서버 과부하도 방지된다.

---

2️⃣ Next.js의 캐싱 전략 요약

Next.js에서의 캐싱은 요청 유형에 따라 달라진다:

렌더링 방식캐싱 기본값비고

Static Generation (SSG)	HTML + 데이터 캐싱됨	최초 빌드 시 생성
Incremental Static Regeneration (ISR)	TTL에 따라 재생성	revalidate 설정
Server Side Rendering (SSR)	기본적으로 캐싱 없음	매 요청마다 렌더링
Client-side fetching	브라우저/클라이언트에 따라 다름	직접 캐싱 제어해야 함

---

3️⃣ fetch()의 캐싱 제어

app/ 디렉토리 기반에서 fetch()를 쓰면, Next.js는 내부적으로 자동 캐싱을 해준다. 하지만 캐시 제어는 명시적으로 해줘야 한다.

예시: 기본 fetch() → 정적 캐싱됨

const res = await fetch("https://api.example.com/posts");

캐싱 끄기: cache: 'no-store'

const res = await fetch("https://api.example.com/posts", {
  cache: "no-store",
});

조건부 재생성: next: { revalidate: 60 }

const res = await fetch("https://api.example.com/posts", {
  next: { revalidate: 60 }, // 60초마다 재생성
});

4️⃣ 캐싱 위치 정리

Next.js의 캐시는 3단계로 나뉜다

1. 빌드 시 정적 캐싱 – SSG 결과물
2. 서버 내부 캐시 (Next.js 자체) – revalidate, fetch() 캐시 제어
3. 브라우저 캐시 – 응답 헤더 기반 (ex: Cache-Control)

---