Published on

5단계: 데이터 패칭 — SSR, SSG, CSR 완전 이해

데이터 패칭 — SSR, SSG, CSR 완전 이해

Next.js는 페이지를 렌더링하는 시점과 위치에 따라 다양한 데이터 패칭 전략을 제공합니다.
이 단계에서는 각 방식의 특성과 사용 시점을 구분하고, App Router와 Pages Router의 차이까지 명확히 정리합니다.


5-1. CSR (Client Side Rendering) — 브라우저에서 렌더링

import { useEffect, useState } from 'react';

export default function Page() {
  const [data, setData] = useState(null);

  useEffect(() => {
    fetch('/api/data')
      .then(res => res.json())
      .then(setData);
  }, []);

  if (!data) return <p>로딩 중...</p>;
  return <div>{data.message}</div>;
}
  • 브라우저에서 데이터 fetch
  • 초기 HTML은 비어 있음 → SEO 약함
  • 사용자별 UI에 유리

5-2. SSR (Server Side Rendering) — 매 요청마다 서버에서 렌더링

export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();
  return { props: { data } };
}

export default function Page({ data }) {
  return <div>{data.message}</div>;
}
  • 요청마다 서버에서 HTML 생성
  • 항상 최신 데이터 보장
  • 느릴 수 있으며, 캐싱 필요

5-3. SSG (Static Site Generation) — 빌드 시 정적 HTML 생성

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();
  return { props: { data } };
}
  • 빌드 타임에 HTML 생성
  • CDN 배포, 속도 매우 빠름
  • 변경이 적은 콘텐츠에 적합

5-4. ISR (Incremental Static Regeneration) — 정적 + 갱신 병행

export async function getStaticProps() {
  const res = await fetch('https://api.example.com/data');
  const data = await res.json();
  return {
    props: { data },
    revalidate: 60,
  };
}
  • SSG에 revalidate 추가로 주기적 갱신
  • 성능과 최신성 동시 확보

5-5. 데이터 패칭 방식 비교

방식실행 시점SEO사용 위치
CSR브라우저낮음마이페이지, 관리자 UI
SSR서버 요청 시높음검색결과, 사용자 맞춤
SSG빌드 시점높음블로그, 문서
ISR빌드+갱신높음상품 상세, 리뷰 등

5-6. App Router의 fetch와 Pages Router의 get*Props 비교

구분App RouterPages Router
서버 데이터fetch() (서버 컴포넌트 기본)getServerSideProps
정적 생성generateStaticParams, cache: 'force-cache'getStaticProps
클라이언트useEffect + fetchuseEffect + fetch

요약

  • CSR은 동적인 UI에 유리하지만 SEO가 불리합니다.
  • SSR은 항상 최신 데이터를 보여주지만 서버 부하가 큽니다.
  • SSG는 가장 빠르며, 자주 변경되지 않는 콘텐츠에 적합합니다.
  • ISR은 SSG의 성능과 실시간성을 절충한 방식입니다.
  • App Router는 서버 컴포넌트를 기반으로 fetch 방식, Pages Router는 명시적 get*Props로 구분됩니다.

심화학습

Q1. ISR 방식이 적용된 페이지가 트래픽이 많을 때 어떤 문제를 주의해야 할까?

A: 재생성 타이밍 중 동시에 많은 요청이 들어오면 stale 페이지가 유지될 수 있으며, 캐싱 전략과 fallback 처리 설계가 필요합니다.


Q2. SSR과 CSR을 혼합해서 사용할 수 있을까? 어떻게 분리하는 게 좋을까?

A: 가능하며, 페이지 진입 시 SSR로 초기 데이터만 전달하고 이후 상세 조회, 인터랙션은 CSR 방식으로 처리하는 전략이 이상적입니다.


Q3. App Router에서는 fetch만으로 SSG와 SSR을 어떻게 구분할 수 있을까?

A: fetch 위치에 따라 다릅니다. 서버 컴포넌트에서 fetch하면 SSR이며, cache: 'force-cache'를 사용하면 SSG처럼 정적으로 캐싱됩니다.