SSR vs SSG vs ISR 운영 차이¶
SSR / SSG / ISR 렌더링 방식의 차이를 운영 기준으로 정리한다.
렌더링 전략에 따라 캐시 주체, 배포 방식, 장애 시 영향 범위가 크게 달라진다.
1. SSR (Server-Side Rendering)¶
동작¶
- 요청마다 서버에서 HTML을 생성
- 렌더링 성능이 서버 상태에 직접 의존
운영 특징¶
- 서버 리소스(CPU/메모리) 사용량 높음
- SSR 경로 장애 시 해당 페이지 즉시 영향
- 캐시 전략은 주로 Nginx/프록시 계층에 의존
운영 리스크¶
- 트래픽 급증 시 서버 부하로 응답 지연 발생
- 캐시 미설정 시 모든 요청이 서버를 직접 타격
적합한 경우¶
- 로그인 기반 개인화 페이지
- 실시간 데이터 반영이 반드시 필요한 화면
2. SSG (Static Site Generation)¶
동작¶
- 빌드 시 HTML을 미리 생성
- 런타임에서는 정적 파일만 제공
운영 특징¶
- 런타임 서버 부하 거의 없음
- CDN 캐싱에 매우 유리
- 변경 사항 반영 시 재빌드 필요
운영 리스크¶
- 빌드 시간 증가
- 빌드 실패 시 전체 배포 차질 가능
- 실시간 데이터 반영 불가
적합한 경우¶
- 문서, 블로그, 마케팅 페이지
- 트래픽이 많고 안정성이 최우선인 경우
3. ISR (Incremental Static Regeneration)¶
동작¶
- 기본 동작은 SSG와 동일
revalidate주기에 따라 백그라운드 재생성
운영 특징¶
- 정적 안정성과 최신성의 절충
- 캐시 정책(
revalidate) 설정이 핵심 - 재생성 실패 시 이전 정적 페이지 유지
운영 리스크¶
- 실시간 데이터 요구에는 부적합
- 잘못된
revalidate값은- 과도한 재생성
- 데이터 최신성 문제
로 이어질 수 있음
적합한 경우¶
- 주기적으로 변경되는 콘텐츠
- 대규모 서비스의 목록/상세 페이지
4. 운영 관점 비교 요약¶
| 항목 | SSR | SSG | ISR |
|---|---|---|---|
| 렌더링 시점 | 요청 시 | 빌드 시 | 빌드 + 주기 재생성 |
| 서버 부하 | 높음 | 매우 낮음 | 낮음 |
| 캐시 주체 | 프록시/서버 | CDN | CDN + 프레임워크 |
| 장애 영향 | SSR 경로 즉시 영향 | 영향 적음 | 중간 |
| 변경 반영 | 즉시 | 재빌드 필요 | 지연 반영 |
5. 선택 기준 요약¶
- SSR
- 실시간성·개인화가 최우선
- 서버 리소스 감당 가능할 때
- SSG
- 변경 빈도 낮음
- 안정성과 트래픽 대응이 핵심일 때
- ISR
- 최신성이 필요하지만 실시간까지는 불필요
- 대규모 페이지를 안정적으로 운영해야 할 때