세 가지 렌더링 방식의 정의
| 용어 | 설명 |
| CSR (Client Side Rendering) | HTML, JS, CSS를 받아 브라우저에서 실행하고 화면을 렌더링하는 방식 |
| SSR (Server Side Rendering) | 서버가 HTML을 만들어 클라이언트에 보내고, 클라이언트는 그걸 바로 보여주는 방식 |
| SSG (Static Site Generation) | 빌드 시 HTML을 미리 생성해 서버에 저장하고, 요청 시 정적 파일을 전달하는 방식 |
동작 원리 비교
CSR (Client Side Rendering)
- 초기 요청 시 index.html만 서버에서 받아옴
- 이후 JavaScript가 실행되며 전체 화면 구성
- 데이터는 클라이언트에서 비동기 호출로 가져옴
브라우저 요청 → index.html + JS → 브라우저가 JS 실행 → 화면 렌더링SSR (Server Side Rendering)
- 서버에서 HTML을 구성하고 브라우저에 전달
- 클라이언트는 받아온 HTML을 즉시 표시 가능
- 이후 JavaScript가 실행되어 상호작용 가능해짐 (Hydration)
브라우저 요청 → 서버가 HTML 생성 → HTML 응답 → 브라우저 표시 + JS 실행SSG (Static Site Generation)
- 빌드 시점에 모든 HTML 파일을 미리 생성
- 사용자의 요청이 있을 때 서버는 이 파일을 전달
빌드 시 HTML 생성 → 서버에 저장 → 사용자 요청 → 정적 HTML 전달
장단점 비교
| 항목 | CSR | SSR | SSG |
| 초기 로딩 속도 | 느림 (JS 실행 후 렌더링) | 빠름 (HTML 즉시 표시) | 매우 빠름 (정적 파일 바로 전달) |
| SEO | 불리함 (JS 기반 콘텐츠) | 유리함 | 매우 유리 |
| 서버 부하 | 낮음 (렌더링 없음) | 높음 (요청마다 렌더링) | 매우 낮음 (정적 파일) |
| 실시간 데이터 | 매우 적합 | 적합 | 부적합 (빌드시 고정됨) |
| 유지보수 | 단순 | 복잡 (서버 코드 필요) | 중간 (빌드 자동화 필요) |
| 유연성 | 높음 | 높음 | 낮음 (자주 바뀌는 콘텐츠엔 부적합) |
| 예시 프레임워크 | React, Vue SPA | Next.js (SSR 모드), Nuxt SSR | Next.js (Static 모드), Gatsby, Hugo |
사용 사례 및 선택 기준
CSR이 적합한 경우
- 대시보드, 관리자 패널 등 로그인이 필수인 앱
- SEO가 크게 중요하지 않은 웹앱
- 자주 변하는 데이터 기반 SPA
SSR이 적합한 경우
- 뉴스, 커머스 등 SEO가 중요한 페이지
- 콘텐츠가 자주 변경되며 빠르게 반영되어야 함
- 로그인 여부에 따라 다른 콘텐츠를 보여줘야 함
SSG가 적합한 경우
- 블로그, 문서 사이트, 마케팅 랜딩 페이지
- 콘텐츠가 자주 바뀌지 않음
- 빌드 시간이 길어도 괜찮고, 빠른 응답이 중요한 경우
정리
| 기준 | CSR | SSR | SSG |
| SEO | 불리 | 유리 | 매우 유리 |
| 초기 속도 | 느림 | 보통 | 빠름 |
| 실시간 반영 | 쉬움 | 쉬움 | 어려움 |
| 서버 부하 | 낮음 | 높음 | 매우 낮음 |
| 기술 복잡도 | 낮음 | 높음 | 중간 |
결론
CSR, SSR, SSG는 각각의 장단점이 분명하며, 프로젝트의 목적과 특성에 따라 선택해야 합니다.
- SPA 기반 대시보드: CSR
- SEO가 필요한 서비스형 웹사이트: SSR
- 정적 콘텐츠 기반 블로그/문서: SSG
그리고 요즘은 이 세 가지를 혼합해서 사용하는 하이브리드 접근이 일반화되고 있습니다.
예: Next.js의 getStaticProps, getServerSideProps처럼 페이지별로 다르게 설정
728x90