- 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 Router | Pages Router |
---|---|---|
서버 데이터 | fetch() (서버 컴포넌트 기본) | getServerSideProps |
정적 생성 | generateStaticParams , cache: 'force-cache' | getStaticProps |
클라이언트 | useEffect + fetch | useEffect + 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처럼 정적으로 캐싱됩니다.