웹 페이지는 HTML을 어디에서, 언제 생성하느냐에 따라 렌더링 전략을 구분할 수 있습니다. 대표적인 방식이 SSR, CSR, SSG입니다.
SSR: 요청 시 서버에서 생성
Server-side rendering은 요청을 받은 서버가 HTML을 생성해 응답하는 방식입니다. 사용자별로 달라지는 내용이나 요청 시점의 데이터가 필요한 페이지에 활용합니다.
- 장점: 응답 HTML에 콘텐츠가 포함되어 초기 내용 표시와 검색엔진의 콘텐츠 해석에 유리합니다.
- 비용: 데이터 조회와 렌더링 시간이 응답 시간에 포함되며, 요청마다 서버 자원이 필요할 수 있습니다.
HTML이 보인다고 모든 상호작용이 준비된 것은 아닙니다. React 같은 도구의 이벤트와 상태를 연결하려면 JavaScript 다운로드와 하이드레이션(hydration)이 필요할 수 있습니다.
CSR: 브라우저에서 생성
Client-side rendering은 브라우저가 JavaScript를 실행해 주요 화면을 구성하는 방식입니다. 서버에서 받은 기본 HTML에 코드를 실행하고 데이터를 가져와 UI를 표시합니다.
- 장점: 로드된 코드와 상태를 활용해 풍부한 상호작용과 화면 전환을 구현하기 좋습니다.
- 비용: 초기 콘텐츠가 JavaScript 다운로드·실행·데이터 요청을 기다릴 수 있습니다.
검색엔진마다 JavaScript 처리 능력이 다르고, 링크 미리보기 봇은 실행하지 않을 수 있습니다. 따라서 CSR의 검색 노출이 불가능하다고 단정할 수는 없지만 별도의 검토가 필요합니다.
SSG: 빌드 시 미리 생성
Static site generation은 배포 전 빌드 과정에서 HTML을 생성합니다. 요청 시 준비된 파일을 전달하므로 블로그나 문서처럼 변경 빈도가 낮은 콘텐츠에 잘 맞습니다.
- 장점: CDN 캐싱과 정적 호스팅에 적합하며 요청 시 렌더링 비용이 작습니다.
- 비용: 콘텐츠 변경을 반영하려면 재생성이 필요하고, 페이지가 많으면 빌드 비용이 커집니다.
SSG 페이지에도 JavaScript를 추가할 수 있으므로 “정적 생성”이 “상호작용 불가능”을 뜻하지는 않습니다.
선택 기준
| 방식 | 주요 HTML 생성 시점 | 대표 고려사항 |
|---|---|---|
| SSR | 요청 시 | 최신 데이터, 응답 시간, 서버 비용 |
| CSR | 브라우저 실행 시 | 번들 크기, 상호작용, 검색 노출 |
| SSG | 빌드 시 | 갱신 주기, 페이지 수, 캐시 |
실제 서비스에서는 경로나 화면 영역에 따라 혼합할 수 있습니다. 어느 방식이 항상 빠른지보다 첫 콘텐츠 표시, 상호작용 준비, 서버 부하를 나누어 측정해야 합니다.
참고