Next.js App Router의 데이터 페칭 및 캐싱 전략 심층 분석

핵심 기술

Next.js app router는 기본적으로 SSR 또는 SSG 방식으로 fetch와 page rendering을 처리하며, 캐시 전략의 선택이 페이지 성능, 사용자 경험, SEO에 결정적인 영향을 미칩니다. 메모리 캐시, no-store, force-cache, revalidateTag 등 다양한 캐시 옵션을 통해 데이터 일관성과 성능을 관리하는 방법을 다룹니다.

기술적 세부사항

• 메모리 캐시 (force-cache): 동일한 fetch 요청은 한 번만 처리하고 결과를 재사용합니다. URL, 쿼리, 헤더가 모두 일치해야 캐싱되며, 서버리스 환경에서는 인스턴스 간 캐시 공유가 되지 않습니다. 과도한 캐시는 메모리 문제를 유발할 수 있습니다.
  • const A = async () => await fetch('/api/workspace');
  • const B = async () => await fetch('/api/workspace'); (같은 요청, 한 번만 요청)
• no-store: 모든 fetch 요청 시 캐시를 사용하지 않고 항상 최신 데이터를 가져옵니다.
  • await fetch('/api/data', { next: { cache: 'no-store' } });
• 정적 캐싱 (force-cache와 유사 동작): next build 시점에 fetch를 실행하고 정적으로 캐싱합니다. 빌드 시 데이터가 고정되며, 실제 배포 환경에서는 auto 캐시 정책이지만 정적 fetch는 force-cache처럼 동작합니다.
  • const todos = await getTodoList(); (ListPage)
• 캐시 무효화:
  • no-store 사용: 항상 최신 데이터 확보
  • revalidateTag: 특정 캐시 무효화 (예: revalidateTag('todos'))
• 페이지 캐시 (Page Cache): 사용자가 방문한 페이지를 캐싱하여 다음 요청 시 빠르게 응답합니다. 요청 시 SSR 결과를 저장하며, ISR 기반으로 작동합니다.
  • 비교:
    • Build-time Cache: 빌드 시점 생성, ISR 또는 재배포로 갱신 (예: 마케팅 페이지)
    • Page Cache: 요청 시점 생성, 조건에 따라 무효화 가능 (예: 로그인 후 대시보드)
• Prefetch: 유저가 아직 클릭하지 않은 링크에 대해 백그라운드에서 미리 데이터를 가져옵니다.
  • <Link>는 정적 경로에 대해 자동 prefetch
  • Intersection Observer로 뷰포트 내에서만 작동
  • 브라우저 캐시 활용

개발 임팩트

정확한 캐시 전략 설정을 통해 불필요한 네트워크 요청을 줄여 애플리케이션 응답 속도를 향상시키고, 사용자 경험을 개선하며, SEO 성능을 최적화할 수 있습니다. 특히 Server Components와 Client Components에서의 데이터 페칭 방식 이해는 복잡한 애플리케이션 구조에서 효율적인 데이터 관리를 가능하게 합니다.

커뮤니티 반응

톤앤매너