서버 사이드 렌더링(SSR, Server-Side Rendering)은 웹페이지의 HTML을 브라우저가 아니라 서버에서 완성해 보내는 방식으로, 검색엔진과 AI 크롤러가 자바스크립트를 실행하지 않아도 본문을 읽을 수 있게 한다.
구글 web.dev는 SSR을 “앱을 서버에서 렌더링해 클라이언트에 자바스크립트 대신 HTML을 보내는 것”으로 정의한다 (Google web.dev, Rendering on the Web). MDN은 같은 개념을 “서버에서 HTML 콘텐츠를 생성해 클라이언트로 보내는 관행”이라 부르고, 클라이언트가 자바스크립트로 HTML을 만드는 클라이언트 사이드 렌더링(CSR)의 반대편에 둔다 (MDN, Server-side rendering).
원래 PHP나 JSP 시절의 웹은 전부 서버가 HTML을 만들어 보냈다. 리액트, 뷰 같은 프런트엔드 프레임워크가 브라우저에서 화면을 그리는 CSR을 퍼뜨린 뒤, 첫 화면 속도와 검색 노출 문제 때문에 Next.js와 Nuxt가 다시 서버 렌더링을 되살린 것이 지금의 SSR이다.
CSR은 서버가 거의 빈 HTML과 자바스크립트 번들을 보내고 브라우저가 실행해서 화면을 만든다. SSR은 서버가 완성된 HTML을 보내고 브라우저는 받은 그대로 먼저 그린다.
web.dev는 CSR을 “브라우저에서 자바스크립트로 DOM을 수정해 앱을 렌더링하는 것”으로, 정적 렌더링(SSG)을 빌드 시점에 URL마다 HTML 파일을 미리 만드는 것으로 구분한다 (Google web.dev, Rendering on the Web, 위 인용). 검색어 자동완성에 “ssr csr ssg isr”이 같이 뜨는 만큼 네 방식을 한 표로 비교하면 아래와 같다.
| 방식 | HTML이 만들어지는 시점 | 만드는 주체 | 어울리는 페이지 |
|---|---|---|---|
| SSR (서버 사이드 렌더링) | 요청이 올 때마다 | 서버 | 로그인 후 화면, 실시간 재고, 개인화 콘텐츠 |
| CSR (클라이언트 사이드 렌더링) | 브라우저가 JS를 실행한 뒤 | 브라우저 | 대시보드, 관리 도구, 색인이 필요 없는 앱 |
| SSG (정적 사이트 생성) | 빌드할 때 한 번 | 빌드 도구 | 블로그, 문서, 위키, 마케팅 페이지 |
| ISR (증분 정적 재생성) | 빌드 때 한 번, 이후 정해진 주기로 갱신 | 빌드 도구와 서버 | 자주 바뀌지만 요청마다 새로 만들 필요는 없는 목록 |
MDN은 SSR과 CSR의 구분이 “실시간 갱신이나 사용자별 콘텐츠처럼 동적인 사이트에서 더 의미가 있다”고 설명한다 (MDN, Server-side rendering, 위 인용). 모든 페이지를 미리 만들어 둘 수 없을 때 요청마다 서버가 HTML을 만드는 것이 SSR이고, 미리 만들 수 있으면 SSG가 더 싸고 빠르다.
두 방식은 배타적이지 않다. 같은 앱에서 페이지별로 섞어 쓰는 것을 Nuxt는 하이브리드 렌더링이라 부르고, 라우트 규칙으로 페이지마다 정적 생성, SSR, SWR 캐시, ISR을 지정하게 한다 (Nuxt, Rendering Modes).
브라우저가 URL을 요청하면 서버가 데이터를 가져와 HTML을 완성해 응답하고, 브라우저는 그 HTML을 그린 뒤 자바스크립트를 내려받아 상호작용을 붙인다. 순서는 다음과 같다.
5번 단계가 하이드레이션(hydration)이다. web.dev는 이를 “서버에서 렌더링된 HTML에 애플리케이션 상태와 상호작용을 더하기 위해 클라이언트 스크립트를 실행하는 것”으로 정의한다 (Google web.dev, Rendering on the Web, 위 인용).
리액트에서는 react-dom/server가 HTML을 만들고, 브라우저에서 hydrateRoot가 “이전에 서버가 생성한 HTML이 있는 DOM 노드”에 리액트를 붙여 관리를 넘겨받는다 (React, hydrateRoot). Nuxt는 “서버에서 한 번 실행된 것과 같은 자바스크립트 코드가 브라우저에서 백그라운드로 다시 실행돼 상호작용이 켜진다”고 같은 과정을 설명한다 (Nuxt, Rendering Modes, 위 인용).
구글은 자바스크립트를 실행할 수 있지만 렌더링 대기열을 거치고, 주요 AI 크롤러는 2024년 12월 기준 자바스크립트를 아예 실행하지 않는다. 본문이 서버 HTML에 들어 있어야 어느 크롤러든 바로 읽는다.
구글봇은 자바스크립트 웹 앱을 크롤링, 렌더링, 색인 생성의 세 단계로 처리하고, 페이지는 렌더링 대기열에 “몇 초 동안 머무를 수 있지만 그보다 오래 있을 수도 있다” (Google 검색 센터, 자바스크립트 SEO 기본사항). 같은 문서는 “모든 크롤러가 자바스크립트를 실행할 수 있는 것은 아니므로” 서버 측 렌더링이나 사전 렌더링이 여전히 좋은 방법이라고 못 박는다.
네이버는 더 직접적이다. 자바스크립트 해석에 “전통적인 HTML 페이지의 해석보다 몇 배 이상의 리소스”가 들기 때문에, SPA 사이트라도 HTML의 주요 영역은 서버에서 렌더링하라고 권장한다 (네이버 서치어드바이저, 자바스크립트 검색 최적화).
AI 크롤러는 아직 렌더링 단계 자체가 없다. Vercel이 자사 네트워크 트래픽을 분석한 결과 “주요 AI 크롤러 중 자바스크립트를 렌더링하는 것은 하나도 없다”고 밝혔고, 구글 제미나이만 구글봇 인프라를 써서 렌더링한다 (Vercel, The rise of the AI crawler).
| 크롤러 | 월간 요청 수 (Vercel 네트워크, 2024년 12월) | 자바스크립트 실행 |
|---|---|---|
| Googlebot (검색과 제미나이) | 45억 회 | 실행함 |
| GPTBot (ChatGPT) | 5억 6,900만 회 | 실행 안 함 |
| ClaudeBot (Claude) | 3억 7,000만 회 | 실행 안 함 |
| AppleBot | 3억 1,400만 회 | 실행 안 함 |
| PerplexityBot | 2,440만 회 | 실행 안 함 |
같은 보고서는 “ChatGPT와 Claude는 자바스크립트를 실행하지 않으므로 중요한 콘텐츠는 서버에서 렌더링하라”고 권고한다 (Vercel, The rise of the AI crawler, 위 인용). CSR로만 만든 페이지는 AI 검색 답변에 인용될 본문 자체가 크롤러에게 보이지 않는다.
크롤러에게만 렌더링된 HTML을 따로 주는 동적 렌더링은 우회책일 뿐이다. 구글은 이를 “임시방편이며 장기적인 솔루션이 아니다”라고 하면서 서버 측 렌더링, 정적 렌더링, 하이드레이션을 대신 권한다 (Google 검색 센터, 동적 렌더링).
SSR은 첫 화면과 크롤러 가독성에서 이기고, 서버 비용과 첫 바이트 응답 시간에서 진다. 어느 쪽이 큰지는 페이지 성격이 정한다.
| 항목 | 장점 | 단점 |
|---|---|---|
| 첫 화면 속도 | 빈 화면 대신 완성된 HTML이 먼저 그려져 FCP가 빠르다 | 서버가 HTML을 만드는 시간만큼 TTFB가 늘어난다 |
| 상호작용 | 본문은 JS 실행 전에도 보인다 | 하이드레이션이 끝나야 클릭이 동작하고, 무거우면 TBT와 INP가 나빠진다 |
| 검색 노출 | 검색엔진과 AI 크롤러가 HTML을 바로 읽는다 | 없음 |
| 인프라 | 없음 | 요청마다 서버 연산이 필요해 정적 호스팅보다 비용이 든다 |
| 개발 | 서버와 브라우저에서 같은 코드를 쓴다 | window 같은 브라우저 전용 API를 서버에서 쓰면 오류가 난다 |
web.dev는 “서버 사이드 렌더링은 일반적으로 빠른 FCP를 만든다”고 하면서, 동시에 “서버에서 페이지를 생성하는 데 시간이 걸려 TTFB가 늘어날 수 있다”와 “하이드레이션을 동반한 SSR은 TBT와 INP에 상당한 악영향을 줄 수 있다”를 같이 적는다 (Google web.dev, Rendering on the Web, 위 인용). TTFB의 권장 기준은 75번째 백분위 기준 0.8초 이하다 (Google web.dev, Time to First Byte).
CSR이 LCP에 불리한 이유도 구체적이다. HTML을 브라우저에서 만들면 그 안에 참조된 이미지와 폰트를 브라우저의 프리로드 스캐너가 미리 발견하지 못해 로딩이 뒤로 밀린다 (Google web.dev, Client-side rendering of HTML and interactivity).
비용 쪽은 Nuxt가 솔직하게 적는다. 유니버설 렌더링의 단점으로 “서버와 브라우저 API가 달라 코드에 주의가 필요하다”와 “서버를 돌리는 비용이 계속 든다”를 들고, CSR의 장점으로 정적 서버 어디에나 올릴 수 있는 점을 든다 (Nuxt, Rendering Modes, 위 인용).
리액트는 Next.js, 뷰는 Nuxt, 콘텐츠 사이트는 Astro가 대표적이고, 세 도구 모두 페이지 단위로 SSR과 정적 생성을 섞을 수 있다.
| 프레임워크 | 기반 | SSR을 켜는 방법 | 기본값 |
|---|---|---|---|
| Next.js | React | Pages Router에서 getServerSideProps를 내보내면 요청마다 HTML 생성 | 정적 생성 |
| Nuxt | Vue | 유니버설 렌더링이 기본, 라우트 규칙으로 페이지별 변경 | SSR |
| Astro | 프레임워크 무관 | 어댑터 설치 후 prerender = false 또는 output: 'server' | 정적 생성 |
Next.js 문서는 페이지가 SSR을 쓰면 “HTML이 요청마다 생성된다”고 하고, 빌드 때 실행되는 getStaticProps와 달리 getServerSideProps는 모든 요청에서 실행된다고 구분한다 (Next.js, Server-side Rendering). Astro는 반대로 “기본적으로 사이트 전체가 사전 렌더링돼 정적 HTML이 전송된다”고 하면서, 대부분의 페이지를 요청 시점에 만들어야 한다는 확신이 들기 전까지는 정적 모드로 시작하라고 권한다 (Astro, On-demand rendering).
선택 기준은 단순하다. 방문자마다 내용이 달라지거나 초 단위로 바뀌면 SSR, 누가 봐도 같은 내용이면 SSG, 그 사이면 ISR이나 SWR 캐시다.
자바스크립트 없이 HTML만 받아서 본문이 들어 있는지 보면 된다. 브라우저 “페이지 소스 보기”나 curl이 그 방법이다.
curl -s https://예시.com/페이지/를 실행하거나 브라우저에서 페이지 소스 보기를 연다.<div id="root"></div>만 있고 본문이 없으면 CSR이다.서치폴라리스 위키는 Astro 정적 생성으로 발행한다. 2026년 9월 30일 curl로 받은 이 사이트의 위키 문서 한 편은 HTML 26.7KB 안에 H2 9개와 정의 문단이 전부 들어 있었고, TTFB는 0.149초로 web.dev 기준 0.8초의 5분의 1 수준이었다 (서치폴라리스 자체 실측, 2026-09-30).
같은 날 구글 키워드 플래너 기준 “서버 사이드 렌더링”의 월 평균 검색량은 260회, “ssr csr”은 170회, “클라이언트 사이드 렌더링”은 50회였다 (서치폴라리스 자체 실측, 구글 키워드 플래너 2026-09-30). 구글 1페이지 9건 중 6건이 SSR과 CSR 비교 글이었고, 테크니컬 SEO 관점에서 쓴 글은 1건뿐이었다.
첫 화면이 빨리 뜨고 검색엔진과 AI 크롤러가 본문을 바로 읽는다. web.dev가 “일반적으로 빠른 FCP”를, 구글 검색 센터가 “모든 크롤러가 자바스크립트를 실행할 수 있는 것은 아니다”를 근거로 든다 (위 인용).
내용이 방문자나 시점에 따라 달라지면 SSR, 모두에게 같으면 SSG, 자주 바뀌지만 요청마다 새로 만들 필요가 없으면 ISR이다. CSR은 검색 노출이 필요 없는 로그인 후 앱에 어울린다.
직접 구성하려면 서버에서 react-dom/server로 HTML을 만들고 브라우저에서 hydrateRoot로 붙인다. 실무에서는 이 과정을 프레임워크가 처리하는 Next.js를 쓰는 경우가 대부분이다.
데이터를 가져오는 코드가 서버에서 실행되므로 API 키나 내부 주소가 브라우저 번들에 노출되지 않는다. 다만 HTML 자체는 누구나 볼 수 있으니 비공개 정보를 서버가 HTML에 넣어 보내면 의미가 없다.
FCP와 LCP는 대체로 좋아지지만 자동은 아니다. 서버 응답이 느리면 TTFB가 늘고, 하이드레이션이 무거우면 INP가 나빠지므로 세 지표를 따로 측정해야 한다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.