데이터 페칭 전략 종류

1. force-static

  • 빌드 시점에 HTML 생성
  • 런타임에서 변경 불가
  • 가장 빠른 성능 제공
  • SEO에 가장 유리
  • 예: 마케팅 페이지, 블로그 포스트, 문서

2. force-dynamic

  • 매 요청마다 새로 렌더링
  • 실시간 데이터가 필요할 때 사용
  • SSR과 유사한 방식
  • 예: 대시보드, 실시간 피드, 채팅

3. unstable_noStore  -> connection 으로 변경

https://nextjs.org/docs/app/api-reference/functions/connection

https://nextjs.org/docs/app/api-reference/functions/unstable_noStore

  • 캐싱을 완전히 비활성화
  • 항상 최신 데이터 제공
  • 실험적 기능
  • 예: 주식 시세, 실시간 경매, 게임 상태

블로그에서의 실제 구현 예시

1. 블로그 메인 페이지

메인 페이지에서는 다양한 종류의 데이터를 표시해야 합니다:

export const dynamic = 'force-static'  // 기본적으로 정적 생성

export default function BlogHome() {
  return (
    <div>
      <FeaturedPosts />        {/* 정적 데이터 (인기 게시물) */}
      <RecentPosts />          {/* 동적 데이터 (최신 게시물) */}
      <PopularTagsSidebar />   {/* 주기적 갱신 (인기 태그) */}
    </div>
  );
}

2. 각 컴포넌트의 데이터 페칭 전략

인기 게시물 (정적 데이터)

// 빌드 시 생성되고 거의 변경되지 않는 데이터
async function FeaturedPosts() {
  const posts = await fetch('/api/featured', {
    cache: 'force-cache'  // 정적으로 캐시
  });

  return <PostGrid posts={posts} />;
}

최신 게시물 (동적 데이터)

// 항상 최신 데이터가 필요한 경우
async function RecentPosts() {
  const posts = await fetch('/api/recent', {
    cache: 'no-store'  // 항상 새로운 데이터
  });

  return <PostList posts={posts} />;
}

인기 태그 (주기적 갱신)

// 일정 주기로 업데이트가 필요한 데이터
async function PopularTags() {
  const tags = await fetch('/api/tags', {
    next: { revalidate: 3600 }  // 1시간마다 갱신
  });

  return <TagCloud tags={tags} />;
}

함수별 상세 설명

force-static 사용 함수

// 정적 생성이 필요한 경우
export const dynamic = 'force-static'
- 빌드 시점에 한 번만 실행
- 서버 리소스 최소화
- CDN 캐싱 최대 활용
- 변경이 거의 없는 콘텐츠에 적합

force-dynamic 사용 함수

// 동적 렌더링이 필요한 경우
export const dynamic = 'force-dynamic'
- 매 요청마다 새로운 데이터 fetch
- 실시간성이 중요한 데이터에 사용
- 서버 부하가 있을 수 있음
- 사용자별 맞춤 콘텐츠에 적합

revalidate 옵션 사용

// ISR(Incremental Static Regeneration) 구현
{
export const revalidate = 5; // 5초마다 재검증
}
- 정적과 동적의 중간 형태
- 지정된 시간마다 데이터 갱신
- 성능과 실시간성의 균형
- 주기적 업데이트가 필요한 데이터에 적합

unstable_noStore 사용

import { unstable_noStore } from "next/cache";
unstable_noStore();
- 캐시를 완전히 비활성화
- 항상 최신 데이터 보장
- 서버 부하가 크므로 신중하게 사용
- 실시간 데이터가 필수인 경우에만 사용

전략 선택 기준

1. 데이터 변경 빈도

  • 거의 변경 없음 → force-static
  • 주기적 변경 → revalidate
  • 실시간 변경 → force-dynamic 또는 unstable_noStore

2. 성능 요구사항

  • 최고 성능 필요 → force-static
  • 적절한 성능 → revalidate
  • 실시간성 중요 → force-dynamic

3. 서버 리소스

  • 최소 부하 → force-static
  • 중간 부하 → revalidate
  • 높은 부하 → force-dynamic/unstable_noStore

주의사항

  1. 적절한 전략 조합이 중요
  2. 사용자 경험 고려
  3. 서버 리소스 관리
  4. 데이터 일관성 유지
  5. 캐싱 전략 최적화

+ Recent posts