CSR vs SSR vs SSG vs 스트리밍: 성능 트레이드오프는?

Question

IT Interview Practice · Accepted Answer

렌더링 전략은 HTML이 *어디서 언제* 만들어지는지를 결정하며, 이것이 로딩 지표를 좌우합니다. 보편적 최선은 없습니다 — 콘텐츠가 얼마나 동적이고 개인화되었는지에 맞추세요.

## 전략들

```text
CSR      서버가 거의 빈 HTML + JS 전송 ──▶ 브라우저가 데이터 페치 ──▶ 렌더   (느린 첫 페인트)
SSR      서버가 요청마다 완전한 HTML 렌더 ──▶ 브라우저가 표시 ──▶ 하이드레이트   (최신, TTFB 비용)
SSG      배포 시 HTML을 한 번 빌드 ──▶ CDN에서 제공 ──▶ 하이드레이트               (가장 빠름, 정적)
Stream   서버가 준비되는 대로 HTML을 청크로 flush ──▶ 셸 먼저, 데이터 채움    (빠른 TTFB + 최신)
```

- **CSR(클라이언트 사이드)** — 빈 셸 + JS를 보내고, 브라우저가 데이터를 페치해 렌더합니다. 호스팅은 저렴하지만 콘텐츠가 JS를 기다리므로 LCP와 SEO가 나쁩니다.
- **SSR(서버 사이드)** — 요청마다 완전한 HTML을 렌더합니다. 빠르고 SEO 친화적인 첫 페인트에 항상 최신이지만, TTFB(요청당 서버 작업)를 더하고 여전히 하이드레이션이 필요합니다.
- **SSG(정적)** — 빌드 시점에 렌더하여 CDN에서 제공합니다. 최고의 TTFB/LCP지만 콘텐츠는 마지막 빌드만큼만 최신입니다. **ISR**은 주기적/온디맨드 재빌드를 더합니다.
- **스트리밍 SSR** — HTML 셸을 즉시 flush하고 느린 부분을 스트리밍(React Suspense / `renderToPipeableStream`)하여 데이터가 로드되는 동안 사용자가 콘텐츠를 보게 합니다.

## 선택

| 콘텐츠 | 최적 |
|---------|----------|
| 마케팅, 문서, 블로그 | SSG (+ ISR) |
| 개인화, 요청별 | SSR / 스트리밍 |
| 인증 뒤의 고도로 인터랙티브한 앱 | CSR 또는 SSR + 아일랜드 |

## 하이드레이션 비용 (공통 함정)

SSR/SSG는 빠르게 페인트하지만 JS가 **하이드레이트**하기 전까지 페이지는 인터랙티브하지 않습니다 — INP가 나빠지는 구간입니다. 부분/점진적 하이드레이션과 React Server Components는 클라이언트 JS를 덜 보내 그 간극을 줄이기 위해 존재합니다.

## 왜 중요한가

시니어는 하나를 독단적으로 고르는 것이 아니라 표면(surface)별로 이 트레이드오프를 추론할 수 있어야 합니다. 핵심 통찰: 빠른 페인트(SSR/SSG)가 빠른 인터랙티브를 의미하지 않는다 — 하이드레이션이 숨은 세금이며, 스트리밍 + 서버 컴포넌트가 둘 다 얻기 위한 현대적 해답입니다.

콘텐츠	최적
마케팅, 문서, 블로그	SSG (+ ISR)
개인화, 요청별	SSR / 스트리밍
인증 뒤의 고도로 인터랙티브한 앱	CSR 또는 SSR + 아일랜드

전략들

선택

하이드레이션 비용 (공통 함정)

왜 중요한가

관련 질문