CSR · SSG · ISR · SSR 구분
1) 비교표
| 전략 | 렌더 시점 | 신선도 | 초기속도(TTFB) | 서버부하 | SEO | 대표 설정(App Router) |
|---|---|---|---|---|---|---|
| CSR | 브라우저 | 클라 재요청 | 빠름(셸) | 낮음 | 낮음 | use client 컴포넌트 + 클라 패칭 |
| SSG | 빌드 | 낮음(재빌드) | 매우 빠름 | 매우 낮음 | 매우 좋음 | dynamic="force-static", revalidate=false |
| ISR | 빌드+백그라운드 | 중간(TTL) | 빠름 | 낮음 | 좋음 | revalidate=60, revalidateTag() |
| SSR | 요청 시 | 높음(실시간) | 상대적 느림 | 높음 | 좋음 | dynamic="force-dynamic", cache:"no-store" |
1.CSR · SSR · SSG · ISR 개념 정리
1) CSR (Client-Side Rendering)
가) 개념
서버는 HTML 뼈대만 내려주고, 브라우저가 JS 번들을 다운로드해서 화면을 그립니다.
나) 특징
- 장점: 단순한 구조, 배포 편리, 내부 서비스에 적합
- 단점: SEO 취약, 초기 로딩 속도 저하, 번들 크기 부담
2) SSR (Server-Side Rendering)
가) 개념
매 요청마다 서버에서 데이터를 조회하고 HTML을 렌더링해 내려줍니다.
나) 특징
- 장점: 항상 최신 데이터, SEO 최적화, 개인화·권한 처리 용이
- 단점: 서버 부하 증가, TTFB 상대적 지연
3) SSG (Static Site Generation)
가) 개념
빌드 시점에 HTML을 만들어 정적으로 배포합니다.
나) 특징
- 장점: 가장 빠른 응답, 캐시 효율 극대화
- 단점: 데이터 변경 시 재빌드 필요, 대규모 페이지 빌드 시간 증가
4) ISR (Incremental Static Regeneration)
가) 개념
SSG에 TTL을 설정해 일정 시간이 지나면 백그라운드에서 페이지를 재생성합니다.
나) 특징
- 장점: 빠른 응답 + 최신 데이터 유지
- 단점: TTL 동안 구버전 노출 가능
2.작은 프로젝트 vs 큰 프로젝트
1) 작은 프로젝트
- SEO가 필요 없는 경우가 많음 → CSR 하나만으로 충분
- 내부용 대시보드, B2B 툴 등은 오버엔지니어링 방지
2) 큰 프로젝트
- SEO 중요 → SSG/ISR/SSR 필요
- 사용자 수·기능이 많아지면 CSR만으로는 퍼포먼스·확장성에 한계
3.퍼포먼스와 확장성의 의미
1) 퍼포먼스
- CSR은 JS 번들이 커지면 초기 로딩(LCP)이 느려짐
- 저사양 기기·느린 네트워크에서는 체감 속도가 나빠짐
2) 확장성
- 사용자 수가 많아지면 API 호출량 증가 → 서버 부하
- 기능이 복잡해지면 클라이언트에서만 처리하기 힘듦
- 개인화/보안 처리가 필요하면 서버 렌더링이 유리
4.CSR + TanStack Query 조합
1) 가능한 부분
- 중복요청 제거, 캐싱, 배경 리페치
- 로딩 체감 개선(placeholderData, keepPreviousData)
- 데이터 프리패치, 캐시 영속화
2) 커버 불가능한 부분
- 첫 화면 로딩 속도(SSR/SSG만큼 단축 불가)
- SEO 보장
- JS 번들 자체 비용
- 복잡한 권한/개인화 처리
5.실무 의사결정 가이드
1) CSR로 충분한 경우
- SEO 불필요한 B2B/내부 서비스
- 초기 단계 작은 프로젝트
2) SSR/ISR/SSG가 필요한 경우
- 검색 유입이 중요한 경우(블로그, 랜딩 페이지)
- 트래픽 규모가 커지고 초기 로딩 체감이 나빠지는 경우
- 사용자별 맞춤화, 보안 컨텍스트가 중요한 경우
6.최종 결론
- B2B, 작은 프로젝트 → CSR + TanStack Query + codeSplit로도 충분
- 규모 확대/SEO 필요 시 → SSR/ISR/SSG 하이브리드 전환 고려
- Next.js의 강점은 바로 이 “하이브리드 지원”에 있음