CSR과 SSR

CSR(Client Side Rendering)은 브라우저가 자바스크립트로 화면을 직접 그리는 방식이고, SSR(Server Side Rendering)은 서버가 화면(HTML)을 다 만들어서 보내 주는 방식입니다. 둘의 차이는 "완성된 HTML을 누가 만드느냐"입니다.

한눈에 보기

• 렌더링을 어디서 하느냐에 따라 이름이 갈립니다.
  • SSR: 서버에서 HTML을 완성해서 보냅니다.
  • CSR: 서버는 빈 HTML과 자바스크립트 파일을 보내고, 브라우저가 데이터를 받아 와서 HTML을 직접 만듭니다.
• 비유: 가구 구매와 비슷합니다.
  • SSR은 완제품 가구 배송입니다. 받자마자 바로 쓸 수 있지만, 공장(서버)이 주문마다 조립해야 해서 공장이 바쁩니다.
  • CSR은 조립식 가구(이케아) 입니다. 처음에 설명서와 부품(JS 파일)이 오고, 내가(브라우저가) 조립해야 쓸 수 있습니다. 대신 한 번 조립 방법을 익히면, 이후에는 부품(데이터)만 받아서 빠르게 바꿔 끼울 수 있습니다.

렌더링 방식의 변화

전통적인 SSR (멀티 페이지 애플리케이션)

예전 웹사이트는 링크를 누를 때마다 서버가 새 HTML 페이지 전체를 만들어서 보냈습니다. 이렇게 페이지마다 HTML 문서가 따로 있는 방식을 MPA(Multi Page Application) 라고 합니다.

• 페이지를 옮길 때마다 화면이 하얗게 깜빡이며 새로 고침이 일어납니다.
• 메뉴, 머리글처럼 바뀌지 않은 부분까지 매번 다시 받아서 다시 그립니다.
• 렌더링을 서버가 모두 맡으므로, 사용자가 많고 화면이 자주 바뀌는 서비스일수록 서버 자원과 트래픽이 많이 듭니다.

웹에서 다루는 정보와 사용자 동작(클릭, 입력, 필터링)이 많아지면서, 작은 변화에도 페이지 전체를 다시 받는 이 방식은 비효율적이 되었습니다.

SPA의 등장과 CSR

이 문제를 해결하려고, 모바일 시대에 들어서 SPA(Single Page Application) 가 널리 쓰이게 되었습니다.

SPA: 처음 한 번 페이지 전체를 불러온 뒤, 이후에는 필요한 데이터만 바꿔 가며 화면을 갱신하는 애플리케이션

• 서버는 HTML을 그리는 대신 JSON 같은 데이터만 보내 줍니다.
• 화면을 그리는 일은 브라우저에서 자바스크립트가 맡습니다. 이것이 CSR입니다.
• 페이지를 옮겨도 새로 고침이 일어나지 않습니다. 자바스크립트가 화면 내용을 바꾸고, HTML5 History API(history.pushState)로 주소창의 URL만 바꿔 줍니다. 그래서 뒤로 가기 버튼과 주소 공유도 평소처럼 동작합니다.
• React, Vue 같은 라이브러리가 이런 SPA를 쉽게 만들도록 도와줍니다. 두 라이브러리의 차이는 Vue와 React에서 다룹니다.

CSR은 사용자 행동에 따라 필요한 부분만 다시 불러오므로, 페이지 전체를 다시 읽는 것보다 빠르게 반응합니다.

동작 순서 비교

[SSR]
 브라우저 ──요청──▶ 서버: 데이터 조회 + HTML 완성
 브라우저 ◀─완성된 HTML── 서버
   → 바로 내용이 보임
   → JS를 받아 실행하면 버튼 등이 동작하기 시작

[CSR]
 브라우저 ──요청──▶ 서버
 브라우저 ◀─빈 HTML + JS 파일── 서버
   → JS 다운로드, 실행 (이 동안 빈 화면 또는 로딩 표시)
 브라우저 ──API 요청──▶ 서버
 브라우저 ◀─JSON 데이터── 서버
   → JS가 HTML을 만들어서 화면에 그림

같은 흐름을 시간축 위에 그리면 차이가 더 잘 보입니다. 그림의 FCP(First Contentful Paint)는 화면에 내용이 처음 보이는 시점, TTI(Time to Interactive)는 버튼을 눌러도 반응하기 시작하는 시점입니다. net줄은 네트워크 요청, JS줄은 자바스크립트 실행입니다.

SSR은 서버가 그려 둔 HTML이 도착하자마자 내용이 보이고(FCP), 작은 JS만 실행하면 바로 눌러볼 수 있습니다(TTI).

CSR은 빈 HTML을 받은 뒤 bundle.js를 내려받고 render(app)을 실행해야 화면이 완성됩니다. 그동안 사용자는 빈 화면이나 로딩 표시만 보게 됩니다.

그림 출처: web.dev - Rendering on the Web (CC BY 4.0)

CSR의 장단점

장점

• 트래픽 감소: 처음 이후에는 필요한 데이터만 받습니다.
• 사용자 경험: 새로 고침 없이 화면이 바뀌어서, 네이티브 앱처럼 매끄럽게 느껴집니다.
• 서버 부담 감소: 화면 그리기를 사용자 브라우저가 나눠 맡으므로 서버는 데이터만 처리하면 됩니다.

단점

• 초기 로딩이 느림: 첫 화면을 보려면 앱 전체 JS 파일을 받아 실행해야 해서, 그동안 빈 화면이 보일 수 있습니다.
• 검색 엔진 최적화(SEO) 불리: React로 만든 웹앱의 페이지 소스를 열어 보면 <div id="root"></div>만 있고 내용이 비어 있습니다.
  • 구글 검색 로봇은 자바스크립트를 실행해서 내용을 읽을 수 있지만, 실행을 뒤로 미뤄 두기 때문에 반영이 늦을 수 있습니다.
  • 자바스크립트를 제대로 실행하지 못하는 검색 로봇이나, 카카오톡·슬랙 링크 미리보기를 만드는 로봇은 빈 페이지만 보게 됩니다.
  • 그래서 검색 노출이 중요한 페이지는 SSR을 따로 붙이는 수고가 생깁니다.
• 사용자 기기 성능에 영향을 받음: 오래된 휴대폰에서는 JS 실행이 느려 화면이 늦게 뜹니다.

SSR의 장단점

장점

• 검색 엔진 최적화(SEO): 첫 응답 HTML에 내용이 다 들어 있어서 어떤 검색 로봇이든 읽을 수 있습니다.
• 첫 화면이 빠름: 서버가 이미 그려 둔 HTML을 보내 주므로, JS를 다 받기 전에도 내용이 먼저 보입니다.

단점

• 서버 부하: 요청마다 서버가 HTML을 만들어야 하므로 사용자가 많으면 서버 자원이 많이 듭니다.
• 페이지 이동 시 깜빡임: 전통적인 SSR은 페이지를 옮길 때마다 전체를 새로 받습니다.
• 보이지만 누를 수 없는 시간: 화면은 먼저 보이지만 JS가 아직 연결되지 않아 버튼을 눌러도 반응하지 않는 순간이 생길 수 있습니다. (아래 하이드레이션 참고)
• 프로젝트 복잡도: 같은 코드가 서버와 브라우저 양쪽에서 돌아야 해서, window처럼 브라우저에만 있는 기능을 쓸 때 주의해야 하고 설정이 복잡해집니다.

SSG와 하이드레이션

요즘은 CSR과 SSR 중 하나만 고르기보다, 둘의 장점을 섞어서 씁니다.

SSG (Static Site Generation)

SSG는 HTML을 요청이 올 때 만드는 것이 아니라, 배포하기 전에(빌드할 때) 미리 전부 만들어 두는 방식입니다.

• 서버는 미리 만들어 둔 파일을 그대로 주기만 하면 되므로 아주 빠르고, 정적 파일 서버나 CDN만으로 운영할 수 있습니다.
• 대신 내용이 바뀌면 다시 빌드해야 하므로, 블로그나 문서처럼 자주 바뀌지 않는 내용에 잘 맞습니다.
• 정해진 시간마다 일부 페이지만 다시 만드는 ISR(Incremental Static Regeneration) 이라는 절충안도 있습니다(Next.js).

실제 예: 지금 보고 계신 이 사이트(1mo.dev)가 바로 SSG입니다. VitePress가 빌드할 때 모든 글을 HTML 파일로 만들어 두고, GitHub Pages는 그 파일을 그대로 전달합니다. 그래서 서버 프로그램(WAS) 없이도 운영됩니다. 웹 서버와 WAS의 차이는 웹 서버와 WAS에서 다룹니다.

하이드레이션 (Hydration)

하이드레이션은 서버(또는 빌드)에서 만든 정적인 HTML에 자바스크립트를 연결해 살아 움직이게 만드는 과정입니다.

• 비유: 하이드레이션(hydration)은 "물을 준다"는 뜻입니다. 바싹 마른 건조 식품(정적 HTML)에 물(JS)을 부어 먹을 수 있는 상태로 되살리는 것과 같습니다.
• 첫 화면은 HTML로 빠르게 보여 주고, JS가 도착하면 버튼 클릭 같은 이벤트를 연결합니다.
• 하이드레이션이 끝난 뒤에는 CSR처럼 동작합니다. 이 사이트도 첫 페이지는 HTML로 뜨지만, 이후 왼쪽 메뉴로 다른 글을 누르면 새로 고침 없이 SPA처럼 이동합니다.

아래 그림처럼 서버가 만든 HTML 덕분에 내용은 일찍 보이지만(FCP), JS를 받아 render(app, DATA)로 이벤트를 연결하기 전까지는 눌러도 반응하지 않습니다(TTI). 앞에서 말한 "보이지만 누를 수 없는 시간"이 바로 FCP와 TTI 사이입니다.

그림 출처: web.dev - Rendering on the Web (CC BY 4.0)

방식	HTML을 만드는 때	만드는 곳	어울리는 서비스
CSR	페이지를 연 뒤	브라우저	관리자 화면, 로그인 후 쓰는 대시보드
SSR	요청이 올 때마다	서버	쇼핑몰 상품 페이지, 뉴스처럼 자주 바뀌고 검색이 중요한 곳
SSG	빌드할 때 한 번	빌드 서버	블로그, 문서 사이트, 회사 소개 페이지

대표 도구로는 React 기반의 Next.js, Vue 기반의 Nuxt가 SSR과 SSG를 모두 지원하고, VitePress와 Astro는 SSG에 강합니다.

코드로 감 잡기: 첫 응답에 무엇이 들어 있나

서버가 처음 보내 주는 HTML에 실제 내용이 들어 있는지 비교해 봅니다. 자바스크립트를 실행하지 않는 검색 로봇은 이 첫 응답만 보고 판단합니다.

import json

posts = [{"title": "브라우저 동작 원리"}, {"title": "CSR과 SSR"}]

# SSR: 서버가 데이터를 넣어 완성된 HTML을 보냄
def ssr_response():
    items = "".join(f"<li>{p['title']}</li>" for p in posts)
    return f"<html><body><ul>{items}</ul></body></html>"

# CSR: 서버는 빈 껍데기 HTML과 JS 파일을 먼저 보내고,
#      데이터는 나중에 JSON으로 따로 보냄
def csr_shell():
    return '<html><body><div id="app"></div><script src="app.js"></script></body></html>'

def csr_api():
    return json.dumps(posts, ensure_ascii=False)

print("[SSR] 첫 응답 =", ssr_response())
print("[CSR] 첫 응답 =", csr_shell())
print("[CSR] 이후 API 응답 =", csr_api())

# 검색 로봇이 JS를 실행하지 않고 첫 응답만 본다면?
for name, html in [("SSR", ssr_response()), ("CSR", csr_shell())]:
    print(name, "첫 응답에 글 제목이 있나:", "CSR과 SSR" in html)

실행 결과:

[SSR] 첫 응답 = <html><body><ul><li>브라우저 동작 원리</li><li>CSR과 SSR</li></ul></body></html>
[CSR] 첫 응답 = <html><body><div id="app"></div><script src="app.js"></script></body></html>
[CSR] 이후 API 응답 = [{"title": "브라우저 동작 원리"}, {"title": "CSR과 SSR"}]
SSR 첫 응답에 글 제목이 있나: True
CSR 첫 응답에 글 제목이 있나: False

CSR의 첫 응답에는 빈 div만 있고, 글 제목은 JS가 API를 호출한 뒤에야 화면에 생깁니다.

면접에서 자주 나오는 질문

Q. CSR과 SSR의 차이는 무엇인가요? CSR은 서버가 빈 HTML과 JS를 보내고 브라우저가 데이터를 받아 화면을 그리는 방식이고, SSR은 서버가 데이터를 넣어 완성된 HTML을 보내는 방식입니다. CSR은 페이지 이동이 빠르고 서버 부담이 적지만 첫 로딩과 SEO가 불리하고, SSR은 첫 화면과 SEO에 유리하지만 서버 부하가 큽니다.

Q. SPA가 무엇이고, 새로 고침 없이 주소는 어떻게 바뀌나요? 처음 한 번 페이지를 불러온 뒤 데이터만 바꿔 가며 화면을 갱신하는 애플리케이션입니다. 화면은 자바스크립트가 바꾸고, 주소는 History API(pushState)로 새로 고침 없이 바꿉니다.

Q. CSR에서 SEO 문제를 어떻게 해결하나요? 검색이 중요한 페이지에 SSR이나 SSG를 적용하는 것이 가장 확실합니다. Next.js, Nuxt 같은 프레임워크를 쓰거나, 검색 로봇에게만 미리 그려 둔 HTML을 주는 프리렌더링을 쓰기도 합니다.

Q. 하이드레이션이 무엇인가요? 서버나 빌드 단계에서 만든 정적 HTML에 자바스크립트를 연결해 이벤트가 동작하도록 만드는 과정입니다. 첫 화면은 HTML로 빠르게 보여 주고, 이후에는 CSR처럼 동작하게 합니다.

Q. SSG는 언제 쓰나요? 블로그, 문서 사이트처럼 내용이 자주 바뀌지 않는 곳에 씁니다. 빌드할 때 HTML을 미리 다 만들어 두므로 빠르고 서버 비용이 적지만, 내용이 바뀌면 다시 빌드해야 합니다.

정리

구분	CSR	SSR	SSG
HTML 만드는 곳	브라우저	서버 (요청마다)	빌드 서버 (배포 전 한 번)
첫 화면	느림 (JS 실행 후)	빠름	가장 빠름
페이지 이동	빠름 (새로 고침 없음)	전통 방식은 새로 고침	하이드레이션 뒤에는 빠름
SEO	불리	유리	유리
서버 부담	적음 (데이터만)	큼	거의 없음 (파일 전달만)
대표 예	React, Vue 기본 SPA	Next.js, Nuxt	VitePress, Astro, Next.js