[Common] SSR vs CSR 비교

들어가며

웹 개발에서 “렌더링”이란 브라우저에 웹 페이지를 그리는 과정입니다.
이 렌더링이 어디에서 발생하느냐에 따라 크게 두 가지 방식으로 나뉘는데,
바로 서버 사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)입니다. 이번 글에서는 SSR과 CSR의 개념, 특징, 그리고 각각의 장단점과 사용 예시까지 비교해보겠습니다.

목차

1. SSR이란?
2. CSR이란?
3. SSR vs CSR: 핵심 비교
4. 실제 예시로 이해하기
5. 어떤 상황에 무엇을 선택할까?
6. 정리 및 결론

1. SSR이란? (Server Side Rendering)

서버 사이드 렌더링(SSR)은 브라우저가 요청하면, 서버에서 HTML을 모두 구성해 응답하는 방식입니다. 즉, 서버가 데이터를 가져와 페이지를 구성한 후, 완성된 HTML을 브라우저에 전달합니다.
브라우저는 받은 HTML을 바로 렌더링하고, 이후 필요한 JS를 로딩합니다.

✅ 장점

• SEO에 유리함: HTML에 콘텐츠가 모두 들어 있으므로 검색 엔진이 잘 읽을 수 있음
• 초기 렌더링 속도가 빠름: JS를 실행하기 전에도 사용자에게 콘텐츠가 보임
• 공유 링크에 미리보기(meta tag) 제공 가능

❌ 단점

• 사용자와의 상호작용에는 여전히 JS 실행이 필요
• 매 요청마다 HTML을 새로 생성하므로 서버 부담이 큼

2. CSR이란? (Client Side Rendering)

클라이언트 사이드 렌더링(CSR)은 브라우저가 먼저 JS 파일을 다운로드 받은 뒤, 데이터를 요청하고 페이지를 렌더링하는 방식입니다. 서버는 최소한의 HTML(거의 빈 상태)과 JS 파일만 응답하고, 나머지는 브라우저가 알아서 처리합니다.

✅ 장점

• 초기 로딩 이후 빠른 페이지 전환: JS로 필요한 데이터만 요청하여 동적으로 렌더링
• 서버 부하가 적음
• SPA(Single Page Application)에 최적화

❌ 단점

• 초기 로딩 속도가 느림: JS 다운로드 + 실행 + 데이터 요청 → 렌더링
• SEO에 불리함: 초기 HTML에 콘텐츠가 없기 때문에 검색엔진이 인식하지 못할 수 있음

3. SSR vs CSR: 핵심 비교

항목	SSR (서버 사이드 렌더링)	CSR (클라이언트 사이드 렌더링)
렌더링 위치	서버	브라우저(클라이언트)
초기 로딩 속도	빠름	느릴 수 있음
SEO	유리함	불리함
서버 부하	높음	낮음
사용자 경험	새로고침 시 전체 로딩	초기 느림, 이후 빠름
활용 예	뉴스, 블로그, 포털	대시보드, SPA, 앱 스타일 웹

4. 실제 예시로 이해하기

🟦 SSR 예시 (Next.js)

// pages/index.tsx
export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/posts');
  const posts = await res.json();
  return { props: { posts } };
}

서버에서 데이터를 먼저 가져와 HTML을 구성 브라우저는 받아서 바로 렌더링

🟨 CSR 예시 (React)

// App.jsx
useEffect(() => {
  fetch('https://api.example.com/posts')
    .then(res => res.json())
    .then(setPosts);
}, []);

초기 HTML은 빈 div만 포함 JS 실행 후 fetch로 데이터를 받아 페이지 구성

5. 어떤 상황에 무엇을 선택할까?

상황	추천 렌더링 방식
SEO가 중요한 콘텐츠 (블로그, 쇼핑몰, 뉴스 등)	SSR
로그인 후 대시보드, 관리자 페이지	CSR
구형 브라우저 지원 필요	SSR
빠른 상호작용과 UX가 중요한 앱	CSR
콘텐츠 공유 및 미리보기(meta tag) 필요	SSR or Static Generation

6. 정리 및 결론

SSR과 CSR 모두 각각의 목적과 장단점이 명확합니다. 중요한 건 “사용자에게 어떤 경험을 줄 것인가?”와 “서비스의 목적이 무엇인가?”를 기준으로 적절히 선택하는 것입니다.