서버 사이드 렌더링을 검색하면 프론트엔드 개발 학습 자료가 대부분 나옵니다. 이 글은 프레임워크 구현 코드가 아니라, 검색엔진과 AI 크롤러가 페이지를 읽는 방식만 검색 노출 관점에서 다룹니다.
서버 사이드 렌더링(SSR)은 사용자가 페이지를 요청할 때마다 서버가 데이터를 채워 완성된 HTML을 만들어 응답하는 렌더링 방식입니다. 브라우저가 화면을 그리기 전에 제목, 본문, 링크가 이미 담긴 문서를 받는다는 뜻입니다.
이 글은 web.dev의 렌더링 전략 가이드와 Google 검색 센터의 공식 문서를 기준으로 작성했습니다. Vercel과 MERJ의 AI 크롤러 조사도 참고했습니다.
요청마다 서버가 완성하는 HTML
React나 Vue 같은 프레임워크로 클라이언트 사이드 렌더링(CSR)만 쓰면, 서버는 빈 틀에 가까운 HTML만 먼저 보내고 나머지는 브라우저가 JavaScript를 실행해 채웁니다. SSR은 이 순서를 바꿉니다. 요청이 들어오는 순간 서버에서 데이터베이스나 API를 조회하고, 그 결과를 넣어 완성된 HTML 문서를 만든 뒤 브라우저로 보냅니다.
그래서 SSR 페이지에서 페이지 소스 보기를 열면 빈 <div id="root">가 아니라 실제 제목과 본문, 링크 태그가 그대로 보입니다. 브라우저는 이 HTML을 받아 바로 화면에 그리고, 이후 클릭이나 입력 같은 상호작용 기능은 JavaScript가 뒤이어 연결합니다.
클라이언트 사이드 렌더링과 다른 점
SSR과 CSR은 같은 화면을 만들어도 누가 언제 그리는지가 다릅니다.
| 구분 | CSR | SSR |
|---|---|---|
| 처음 받는 응답 | 빈 틀에 가까운 HTML | 데이터가 채워진 완성 HTML |
| 화면을 완성하는 주체 | 브라우저의 JavaScript | 서버 |
| 로직, 데이터 조회, 라우팅 처리 위치 | 브라우저 | 서버 |
| 첫 콘텐츠 표시(FCP) | 느린 편 | 빠른 편 |
| 서버 응답 시간(TTFB) | 짧은 편 | 페이지를 만드는 시간만큼 늘어날 수 있음 |
CSR은 브라우저가 로직과 데이터 조회, 템플릿 렌더링, 라우팅을 모두 처리해야 하므로 첫 화면이 늦게 완성될 수 있습니다. 반대로 SSR은 그 작업을 서버가 미리 끝내고 텍스트와 링크 위주의 완성된 응답만 보내므로 첫 콘텐츠가 빠르게 나타납니다. 다만 서버가 매 요청마다 페이지를 새로 만들어야 해서, 서버 응답을 기다리는 시간(TTFB)이 늘어날 수 있습니다.
SSR과 정적 생성, 하이드레이션의 관계
SSR과 자주 묶여 등장하는 정적 생성(SSG), 하이드레이션은 요청 시점과 처리 순서가 다릅니다.
- 정적 생성(SSG): 빌드 시점에 페이지별 HTML을 미리 만들어 둡니다. SSR은 사용자가 요청하는 순간 그때그때 HTML을 만들지만, SSG는 배포 전에 만든 파일을 그대로 서빙합니다. 자주 바뀌지 않는 페이지는 SSG가 서버 부하 없이 같은 효과를 냅니다.
- 하이드레이션: 별도의 렌더링 방식이 아니라, SSR이나 SSG로 받은 HTML에 브라우저가 JavaScript를 실행해 클릭과 입력 같은 상호작용 기능을 연결하는 후속 과정입니다. 화면은 이미 완성돼 있으니 사용자는 SSR처럼 빠른 첫 화면을 보고, 이어서 JavaScript가 그 화면을 다시 한번 처리해 완전한 앱으로 만듭니다.
SSR, SSG, 하이드레이션을 한 문장으로 정리하면, SSG는 언제 HTML을 만드는지, SSR은 누가 만드는지, 하이드레이션은 그 HTML에 무엇을 이어 붙이는지에 대한 답입니다.
검색엔진과 AI 크롤러가 SSR을 선호하는 이유
Google은 자바스크립트 SEO 기본 문서에서 서버 측 또는 사전 렌더링을 여전히 좋은 방법이라고 설명합니다. 사용자와 크롤러 모두에게 더 빠른 로딩을 제공하고, 모든 크롤러가 JavaScript를 실행할 수 있는 것은 아니기 때문입니다. Google 자체는 JavaScript를 실행해 CSR 페이지도 처리할 수 있지만, 그 처리가 모든 크롤러에 똑같이 적용된다고 볼 수는 없습니다.
같은 이유로 Google은 다이내믹 렌더링(크롤러에게만 서버 렌더링 버전을 보여주는 임시 대응)을 장기 해법으로 권장하지 않습니다. 대신 서버 측 렌더링과 정적 렌더링, 하이드레이션으로 문제를 해결하라고 안내합니다. 다이내믹 렌더링과 클로킹의 경계는 클로킹 글에서 다룹니다. 네이버도 자바스크립트 검색 최적화 문서에서 주요 본문을 서버에서 렌더링해 제공하도록 권장합니다.
AI 크롤러 쪽은 상황이 더 뚜렷합니다. Vercel과 MERJ가 2024년 12월 발표한 조사는 nextjs.org와 Vercel 네트워크의 실제 트래픽을 몇 달간 관찰하고, 서로 다른 기술 스택을 쓰는 두 사이트로 교차 검증했습니다. 이 조사에서 GPTBot, ClaudeBot, PerplexityBot을 포함한 주요 AI 크롤러는 JavaScript를 렌더링(실행)하지 않는 것으로 확인됐습니다. ChatGPT와 Claude의 크롤러가 JavaScript 파일 자체를 내려받는 비율은 각각 11.5%, 23.84%로 나타났지만, 가져오는 것과 실행하는 것은 다릅니다. 파일을 받아도 실행하지 않으면 그 안에서 만들어지는 콘텐츠는 크롤러에 보이지 않습니다.
다만 이 사실은 OpenAI나 Anthropic의 공식 크롤러 문서가 직접 밝힌 내용은 아닙니다. 두 회사의 공식 문서는 크롤러 이름과 IP 대역, robots.txt 처리 방침만 공개할 뿐 JavaScript 실행 여부는 언급하지 않습니다. 이 글에서 AI 크롤러의 JS 실행 여부는 공식 발표가 아니라 Vercel과 MERJ의 조사 결과로 표시하며, 조사 시점 이후 크롤러 동작이 바뀌었을 가능성도 있습니다. AVCD는 검색엔진과 AI 크롤러 모두를 고려해야 하는 사이트라면, 핵심 제목과 본문, 링크를 초기 HTML에서부터 제공하는 SSR이나 정적 생성 쪽을 우선 검토하도록 권합니다.
실무에서 확인하는 방법
SSR을 실제로 쓰고 있는지, 잘 작동하는지는 다음 두 가지로 나눠 확인합니다.
- 초기 HTML에 콘텐츠가 있는지 확인: 브라우저에서 페이지 소스 보기(JavaScript 실행 전 원본 HTML)를 열어 제목과 본문, 링크가 보이는지 봅니다. 빈
<div>만 있고 텍스트가 없다면 그 페이지는 CSR로 응답하고 있는 것입니다. - 서버 응답 속도 확인: TTFB(서버가 첫 응답 바이트를 보내기까지 걸리는 시간)를 잽니다. SSR은 요청마다 서버가 HTML을 새로 만들기 때문에, 데이터 조회나 서버 자원이 부족하면 TTFB가 길어질 수 있습니다.
Googlebot이 실제로 어떻게 렌더링하는지, 초기 HTML과 실행 후 HTML이 어디서 갈리는지처럼 더 깊은 진단은 JavaScript SEO 글에서 단계별로 다룹니다. 이 글은 SSR 자체의 정의와 선택 이유에 집중합니다.
자주 묻는 질문
워드프레스처럼 원래 서버에서 HTML을 만드는 사이트도 SSR인가요?
넓은 의미로는 같은 원리입니다. 요청이 올 때마다 서버가 완성된 HTML을 만들어 보낸다는 점에서 전통적인 서버 렌더링 웹사이트도 SSR의 한 형태로 볼 수 있습니다. 다만 SSR이라는 용어는 보통 React나 Vue처럼 원래 브라우저에서 그리도록 설계된 JavaScript 프레임워크를, 서버에서도 같은 방식으로 미리 렌더링하게 만든 경우를 가리킬 때 더 자주 쓰입니다.
SSR을 쓰면 검색 순위가 오르나요?
그렇게 단정할 근거는 없습니다. Google 공식 문서는 서버 측 렌더링이 크롤러 호환성과 로딩 속도에 도움이 된다고 설명할 뿐, 순위 상승을 보장한다고 말하지 않습니다. 콘텐츠의 관련성과 품질은 렌더링 방식과 별개로 계속 중요합니다.
CSR 사이트를 전부 SSR로 바꿔야 하나요?
무조건 그렇지는 않습니다. Google은 JavaScript를 실행해 CSR 페이지도 처리할 수 있다고 밝히고 있어, SSR이 모든 사이트의 절대 요건은 아닙니다. 다만 여러 크롤러의 처리 범위가 다르고 AI 크롤러 다수가 JavaScript를 실행하지 않는 현재 상황에서는, 검색과 AI 노출이 중요한 페이지일수록 SSR이나 정적 생성으로 핵심 콘텐츠를 초기 HTML에 담아 두는 편이 안전합니다.
함께 알아두면 좋은 용어
- JavaScript SEO: 렌더링을 포함해 JavaScript 페이지 전반의 검색 노출을 점검하고 고치는 작업
- 크롤링: 검색로봇이 URL과 자원을 가져오는 과정
- AI 크롤러: AI 모델 학습과 검색, 실시간 응답을 위해 웹페이지에 접근하는 봇
- 페이지 속도: 서버 응답과 렌더링을 포함해 페이지가 보이고 반응하기까지의 전반적인 성능
- 클로킹: 검색엔진과 사용자에게 다른 콘텐츠를 보여주는 스팸 기법
- CDN: 사용자와 가까운 서버에서 콘텐츠를 전달해 응답 속도를 줄이는 네트워크