서버 사이드 렌더링(SSR)
Server Side Rendering · SSR
서버 사이드 렌더링(SSR)은 페이지 요청이 들어올 때 서버가 화면에 필요한 HTML을 생성해 브라우저에 보내는 렌더링 방식입니다. 빌드 시 파일을 만드는 정적 생성, 브라우저 JavaScript가 DOM을 만드는 클라이언트 렌더링과 다릅니다.
AI 보조 조사·작성 후 원문과 대조한 설명입니다. 사례·계산은 별도 출처 표기가 없는 한 이해를 위한 가상 예시이며 실제 고객 성과가 아닙니다.
SSR 여부는 실제 응답에서 확인합니다
web.dev 렌더링 문서는 SSR을 서버가 요청에 응답해 HTML을 생성하는 방식으로 정의하고 정적 렌더링·CSR·하이드레이션과 구분합니다. Google JavaScript SEO 문서는 검색 처리에서 크롤링·렌더링·색인을 나눕니다. 프레임워크 설정 이름보다 URL을 새로 요청했을 때 받은 HTML에 제목·본문·링크가 있는지 확인합니다.
가상 기사 페이지는 어떻게 검사하나요?
가상 기사 /news/42를 요청했을 때 응답 본문에 <main><h1>신제품 발표</h1><p>발표 내용입니다.</p></main>이 있다면 주요 내용이 서버 HTML에 포함된 상태입니다. 이후 JavaScript가 댓글이나 저장 버튼을 활성화할 수 있습니다. 빈 root 요소와 큰 스크립트만 내려온다면 주요 화면은 CSR에 더 의존할 수 있습니다.
검수 항목
- 로그아웃 상태의 응답 HTML에 핵심 내용이 있는가?
- 서버와 클라이언트 렌더 결과가 달라지지 않는가?
- 하이드레이션 전 버튼을 눌렀을 때 오동작하지 않는가?
- 캐시와 개인화가 다른 사용자 내용을 섞지 않는가?
SSR과 정적 생성 중 무엇이 항상 더 좋은가요?
항상 우월한 방식은 없습니다. SSR은 요청 시 최신 데이터와 개인화를 반영할 수 있지만 서버 생성 시간이 TTFB에 영향을 줄 수 있습니다. 정적 생성은 미리 만든 HTML을 빠르게 제공하기 좋지만 URL 수와 갱신 방식의 제약이 있습니다. CSR도 구현과 테스트가 적절하면 검색 접근이 가능하지만 클라이언트 처리 비용을 관리해야 합니다.
SSR로 바꾸면 속도와 색인이 개선되나요?
개선을 보장할 수 없습니다. 서버 HTML이 빨리 보여도 무거운 하이드레이션이 INP를 늦출 수 있고 느린 데이터 요청은 TTFB를 키울 수 있으며 내용이 중복·noindex라면 색인되지 않을 수 있습니다. 변경 전후에는 응답 HTML, TTFB, LCP, INP와 색인 상태를 각각 측정해 렌더링 방식 변경을 단일 성과로 설명하지 않습니다.
자주 묻는 질문
- SSR이면 JavaScript가 필요 없나요?
- 아닙니다. 서버 HTML 뒤에 상호작용을 위한 JavaScript와 하이드레이션을 사용할 수 있습니다.
- 페이지 소스에 본문이 보이면 SSR인가요?
- 요청 시 생성된 SSR일 수도 있고 빌드 시 만든 정적 HTML일 수도 있습니다. 빌드·배포 방식과 응답을 함께 확인합니다.
출처와 확인 범위
- Rendering on the Web · web.dev · 확인 2026-10-27
SSR은 요청에 응답해 서버에서 HTML을 만들고 CSR은 브라우저 JavaScript가 DOM을 만들며 정적 렌더링과 하이드레이션은 별도 방식입니다.
확인 범위: 표시한 절의 정의·프로토콜·측정 조건·한계만 사용했습니다. 크롤링·렌더링·색인·검색 노출·속도·순위·처리 기간 보장은 근거로 사용하지 않았습니다.
- Understand the JavaScript SEO basics · Google Search Central · 확인 2026-10-27
Google은 JavaScript 페이지를 크롤링, 렌더링, 색인의 세 단계로 처리하며 각 단계의 실패 원인과 확인 방법이 다릅니다.
확인 범위: 표시한 절의 정의·프로토콜·측정 조건·한계만 사용했습니다. 크롤링·렌더링·색인·검색 노출·속도·순위·처리 기간 보장은 근거로 사용하지 않았습니다.