SSR vs CSR vs SSG — 완성된 HTML은 누가, 언제 만드는가

SSR, CSR, SSG. 셋 다 “웹 페이지를 만드는 방식”이라는 건 알겠는데, 매번 헷갈린다면 질문을 하나로 좁혀보자. 완성된 HTML은 누가, 언제 만드는가? 세 용어는 이 한 질문에 대한 서로 다른 대답이다.

CSR(Client-Side Rendering): 브라우저가, 접속한 뒤에 만든다.
SSR(Server-Side Rendering): 서버가, 요청이 올 때마다 만든다.
SSG(Static Site Generation): 빌드 도구가, 배포 전에 미리 만들어 둔다.

브라우저에 도착하는 것부터 다르다

CSR에서 서버가 보내는 HTML은 사실상 빈 껍데기다.

<!-- CSR: 서버 응답. 내용이 없다 -->
<body>
  <div id="root"></div>
  <script src="bundle.js"></script>
</body>

화면은 브라우저가 bundle.js를 내려받아 실행한 뒤에야 그려진다. React SPA의 기본형이 이 모양이다. 반면 SSR과 SSG의 응답에는 제목·본문이 전부 채워진 완성 HTML이 들어 있다. 두 방식의 차이는 그 HTML을 요청 순간에 조립했느냐(SSR), 빌드 때 미리 찍어뒀느냐(SSG) 뿐이다.

트레이드오프 한눈에 보기

	CSR	SSR	SSG
HTML 생성 시점	접속 후, 브라우저	요청마다, 서버	빌드 때, 한 번
첫 화면 표시	느림 (JS 실행 후)	빠름	가장 빠름
요청마다 다른 내용	가능	가능	불가 (재빌드 필요)
서버 부담	거의 없음	요청마다 렌더링	파일 서빙뿐
페이지 전환	매끄러움 (SPA)	매번 새 문서	매번 새 문서

CSR의 약점은 첫 화면이다. JS를 다 받아 실행하기 전까지 사용자는 빈 화면을 본다. 검색 엔진 크롤러도 마찬가지로 빈 HTML을 먼저 만나기 때문에, 콘텐츠가 검색에 노출되어야 하는 페이지에서는 SEO가 불리해질 수 있다. 대신 한 번 로드된 뒤에는 페이지 전환이 서버를 거치지 않아 앱처럼 매끄럽다.

SSR은 첫 화면과 SEO 문제를 풀지만, 요청마다 서버가 렌더링을 수행하므로 서버 비용과 응답 지연이 생긴다. SSG는 그 비용마저 빌드 시점으로 옮겨버린 극단이고, 그 대가로 “내용이 바뀌면 다시 빌드”라는 제약을 진다.

경계는 생각보다 흐리다 — 하이드레이션

“SSR·SSG는 JS가 필요 없다”는 건 오해다. 완성 HTML을 받아도 버튼 클릭 같은 상호작용을 붙이려면 결국 브라우저에서 JS가 실행되어야 한다. 서버가 그린 HTML 위에 이벤트 핸들러를 다시 연결하는 이 과정을 하이드레이션(hydration)이라 부른다. Next.js의 SSR 페이지는 “서버가 먼저 그리고, 브라우저가 이어받는” 구조라서 CSR과 SSR의 혼합에 가깝고, Astro는 하이드레이션을 페이지 전체가 아니라 필요한 조각(아일랜드)에만 적용한다.

그래서 현대 프레임워크에서 셋은 배타적인 진영이 아니다. Next.js는 페이지 단위로 정적 생성과 서버 렌더링을 골라 쓰게 하고, 정적 페이지를 주기적으로 다시 굽는 ISR(Incremental Static Regeneration) 같은 중간 지대도 있다.

무엇을 고르나

결정 기준은 페이지의 성격이다.

누가 봐도 같은 내용 (블로그, 문서, 랜딩) → SSG. 매 요청마다 다시 만들 이유가 없다.
요청마다 달라지는 내용 (검색 결과, 재고·가격, 개인화 피드) → SSR. 최신 데이터와 SEO를 같이 잡는다.
로그인 뒤에만 쓰는 앱 (대시보드, 에디터) → CSR. 검색 노출이 필요 없고 상호작용이 전부인 화면이다.

한 서비스 안에서도 랜딩은 SSG, 검색 결과는 SSR, 관리자 화면은 CSR로 섞는 게 자연스럽다. 셋 중 하나를 “채택”하는 게 아니라, 페이지마다 HTML을 만들 가장 싼 시점을 고르는 것 — 그게 이 세 용어를 관통하는 관점이다.