서버 사이드 렌더링
서버 사이드 렌더링(SSR)은 사용자나 검색봇의 요청이 들어올 때마다 서버가 페이지의 완성된 HTML을 미리 만들어 전송하는 방식입니다. 브라우저가 자바스크립트를 실행하기 전에 콘텐츠가 이미 HTML에 들어 있어, 검색엔진이 즉시 내용을 보고 색인하기에 유리합니다.
- 서버 사이드 렌더링(SSR)은 요청 시점에 서버가 완성된 HTML을 생성해 전송하므로, 검색봇이 자바스크립트를 실행하지 않고도 콘텐츠를 곧바로 읽을 수 있습니다.
- 구글 공식 문서는 "서버 사이드 렌더링 또는 사전 렌더링은 여전히 좋은 선택"이라고 명시하며, 모든 봇이 자바스크립트를 실행하지는 못한다는 점을 이유로 듭니다.
- SSR은 FCP(첫 콘텐츠 표시)가 빠르지만 서버 연산 부담으로 TTFB(첫 바이트 도착 시간)가 늦어질 수 있고, 하이드레이션 전까지 상호작용이 막힐 수 있습니다.
- SSR은 모든 방문자에게 동일한 서버 렌더 HTML을 제공하는 방식이며, 봇에게만 다른 버전을 주는 다이내믹 렌더링과는 구분됩니다.
- 콘텐츠 성격에 따라 CSR·SSR·SSG·ISR을 적절히 조합하는 것이 실무 표준이며, 구글은 다이내믹 렌더링을 임시방편으로 보고 권장하지 않습니다.
개요
서버 사이드 렌더링(Server-Side Rendering, SSR)은 페이지 요청이 들어올 때마다 서버가 자바스크립트를 실행해 완성된 HTML을 만들어 응답하는 렌더링 방식입니다. 브라우저는 받은 HTML을 즉시 화면에 그릴 수 있고, 검색봇 역시 자바스크립트를 따로 실행하지 않아도 본문, 메타 정보, 링크를 곧바로 읽을 수 있습니다.
이 점이 SEO에서 중요합니다. 클라이언트 사이드 렌더링(CSR)은 처음에 거의 빈 HTML 껍데기만 보내고 브라우저가 자바스크립트로 콘텐츠를 채우는데, 검색봇이 이 자바스크립트를 실행해 주기를 기다려야 색인이 가능합니다. SSR은 이 단계를 건너뛰므로 색인 신뢰도가 높습니다.
작동 방식
요청이 도착하면 서버가 컴포넌트 트리를 렌더링해 HTML 문자열을 만들고, 이를 응답으로 보냅니다. React를 예로 들면 서버에서 renderToPipeableStream 같은 API로 HTML을 스트리밍하고, 브라우저는 이 정적 HTML을 즉시 표시한 뒤 자바스크립트를 내려받아 hydrateRoot로 이벤트 리스너를 붙여 페이지를 상호작용 가능 상태로 만듭니다. 이 마지막 단계를 하이드레이션(hydration)이라고 부릅니다.
web.dev의 렌더링 전략 문서에 따르면, 하이드레이션 방식에서는 "페이지가 로드되어 상호작용이 가능한 것처럼 보이지만, 해당 컴포넌트의 클라이언트 스크립트가 실행되기 전까지는 실제로는 입력에 반응하지 못한다"는 한계가 있습니다. 즉 화면은 빨리 뜨지만 TTI(상호작용 가능 시점)는 자바스크립트 실행에 좌우됩니다.
렌더링 방식 비교
| 방식 | HTML 생성 시점 | TTFB | SEO 색인 | 적합한 콘텐츠 |
|---|---|---|---|---|
| CSR (클라이언트 렌더) | 브라우저에서 실행 시 | 빠름 | 봇의 JS 실행에 의존(불리) | 로그인 후 대시보드 등 비공개 화면 |
| SSR (서버 렌더) | 요청마다 서버에서 | 서버 연산으로 지연 가능 | 유리(완성 HTML 제공) | 자주 바뀌는 개인화·실시간 페이지 |
| SSG (정적 렌더) | 빌드 시 미리 생성 | 매우 빠름 | 유리(완성 HTML 제공) | 블로그·문서 등 잘 안 바뀌는 페이지 |
| ISR (점진적 재생성) | 빌드 후 일정 주기로 재생성 | 빠름(캐시) | 유리 | 주기적으로 갱신되는 대규모 목록 |
CSR은 첫 바이트는 빠르지만 자바스크립트 번들이 커질수록 TTI가 길어집니다. SSG는 빌드 시점에 HTML을 미리 만들어 두므로 TTFB가 가장 빠르지만, 요청마다 달라지는 동적 콘텐츠에는 맞지 않습니다. SSR은 요청 시점 데이터를 반영하면서도 완성 HTML을 제공한다는 절충점에 있습니다. Next.js 같은 프레임워크는 이들을 한 페이지 안에서 조합하는 부분 사전 렌더링(Partial Prerendering) 같은 방식도 제공합니다.
다이내믹 렌더링과의 구분
SSR과 혼동하기 쉬운 개념이 다이내믹 렌더링(dynamic rendering)입니다. 다이내믹 렌더링은 서버가 요청 주체가 봇인지 사용자인지 감지해 서로 다른 버전을 제공하는 방식으로, 봇에게는 서버 렌더 HTML을, 사용자에게는 자바스크립트 기반 콘텐츠를 줍니다. 반면 SSR은 봇과 사용자를 가리지 않고 모두에게 동일한 서버 렌더 HTML을 제공합니다.
구글은 다이내믹 렌더링에 대해 "자바스크립트 생성 콘텐츠 문제에 대한 우회책이었을 뿐 장기적 해결책이 아니다"라고 명시하고, 대신 서버 사이드 렌더링·정적 렌더링·하이드레이션을 권장합니다. 따라서 새 프로젝트라면 다이내믹 렌더링 대신 SSR/SSG로 가는 것이 바람직합니다.
SEO 이점과 근거
구글 검색 센트럴의 자바스크립트 SEO 기초 문서는 색인 과정을 크롤링 → 렌더링 → 색인의 3단계로 설명합니다. 렌더링 단계에서 Googlebot이 헤드리스 Chromium으로 자바스크립트를 실행하지만, 이 렌더링은 크롤링과 색인 사이에 별도로 대기열을 거치므로 지연이 생길 수 있습니다. SSR은 크롤링 단계에서 이미 완성된 HTML을 제공하므로 이 렌더링 의존을 줄여 줍니다.
- 모든 봇 호환성: 구글 문서는 "모든 봇이 자바스크립트를 실행할 수 있는 것은 아니다"라고 밝히며, 서버/사전 렌더링이 더 넓은 발견 가능성을 보장한다고 설명합니다.
- 색인 신뢰도: 콘텐츠가 처음부터 HTML에 들어 있어 렌더링 대기열에 좌우되지 않고 즉시 색인될 수 있습니다.
- 성능: web.dev에 따르면 SSR은 클라이언트로 보내는 자바스크립트 양을 줄여 FCP를 앞당기고 총 차단 시간(TBT)을 낮춥니다. 사용자 경험과 검색엔진 모두에 이득입니다.
실행 체크리스트
- 공개·색인 대상 페이지(상품·기사·랜딩)는 SSR 또는 SSG로 완성 HTML을 제공하도록 구성하세요.
- title·meta description·canonical·구조화 데이터가 서버 렌더 HTML 안에 포함되는지 페이지 소스 보기로 확인하세요.
- 봇과 사용자에게 다른 콘텐츠를 주는 다이내믹 렌더링·클로킹 형태를 피하고, 동일 HTML을 제공하세요.
- SSR로 인한 TTFB 지연은 캐싱·CDN·ISR 활용으로 완화하세요.
- 하이드레이션 불일치 오류가 SEO·UX를 해치지 않도록 서버와 클라이언트의 렌더 결과를 일치시키세요.