CSR, SSR, SSG

artp·2025년 4월 14일

CSR SSR ssg

cs

목록 보기

6/16

SPA (Single Page Application)란?

SPA (Single Page Application)는 말 그대로 하나의 페이지로 구성된 웹 애플리케이션입니다.

최초 접속 시 HTML, CSS, JS 등 필요한 정적 리소스를 한 번에 모두 다운로드합니다.
이후 사용자가 다른 페이지로 이동하면, 브라우저는 전체 페이지를 다시 로딩(리로딩)하지 않고,
필요한 데이터만 서버에서 받아와 화면의 일부분만 갱신합니다.
이렇게 하면 화면 전환이 빠르고 깜빡임이 없어, 네이티브 앱처럼 부드러운 사용자 경험을 제공할 수 있습니다.

MPA (Multi Page Application)란?

MPA (Multi Page Application)는 전통적인 방식의 웹 애플리케이션입니다.

사용자가 페이지를 이동할 때마다 브라우저는 서버에 새 HTML 페이지를 요청합니다.
서버는 요청에 맞는 페이지를 렌더링해서 HTML, CSS, JS를 다시 보내고,
브라우저는 전체 페이지를 새로 렌더링합니다.
이동 시마다 전체 리소스를 새로 불러오기 때문에 페이지 간 이동시 깜빡임이나 로딩 시간 지연이 발생할 수 있습니다.

SPA, MPA와 CSR, SSR과의 관계

SPA는 일반적으로 CSR을 사용합니다.

SPA는 클라이언트가 페이지 전환을 처리하고, 필요한 데이터를 비동기적으로 받아와 화면을 갱신하는 구조입니다.
이처럼 브라우저가 렌더링을 담당하고, 자바스크립트를 통해 UI를 동적으로 그리는 방식이기 때문에, 일반적으로 CSR(Client Side Rendering) 구조를 사용하게 됩니다.

MPA는 일반적으로 SSR을 사용합니다.

MPA는 페이지 전환 시마다 서버에 새로운 페이지를 요청하고, 서버는 그 요청에 맞는 HTML을 응답합니다.
이때 서버가 요청을 처리하면서 HTML을 동적으로 생성해 응답하는 구조를 SSR(Server Side Rendering)이라고 하며, 전통적인 MPA에서는 이 SSR 방식이 일반적으로 사용됩니다.
다만, MPA 구조에서 정적으로 미리 생성된 HTML을 제공하는 경우도 있기 때문에, MPA = SSR이라고 단정짓기보다는 “일반적으로 SSR이 사용된다”는 표현이 더 적절합니다.

❗️주의
SPA = CSR, MPA = SSR을 의미하는 것이 아닙니다.
SPA에서도 SSR을 사용할 수 있고, MPA에서도 CSR 방식을 사용할 수 있습니다.

웹 렌더링이란?

웹 렌더링은 웹 브라우저가 HTML, CSS, JavaScript 등의 리소스를 해석하여 화면에 웹 페이지를 시각적으로 표현하는 과정을 말합니다.

우리가 어떤 웹사이트를 방문하면, 단순히 "미리 저장된 페이지"를 복사해오는 것이 아니라, 브라우저가 서버로부터 전달받은 코드(HTML, JS 등)를 기반으로 실시간으로 웹 페이지를 구성하게 됩니다.
이 과정을 렌더링(Rendering)이라고 부르며, 웹 개발에서는 이 렌더링 방식이 성능과 사용자 경험에 큰 영향을 미칩니다.

이 렌더링 방식에는 대표적으로 다음 세 가지가 있습니다.

CSR (Client Side Rendering): 브라우저가 렌더링을 담당
SSR (Server Side Rendering): 서버에서 HTML을 만들어 전달
SSG (Static Site Generation): 빌드 시 미리 HTML을 생성해 전달

CSR (Client Side Rendering) - 클라이언트 사이드 렌더링

브라우저(클라이언트)에서 화면을 렌더링하는 방식

CSR(Client Side Rendering)은 클라이언트 사이드 렌더링의 줄임말로,
웹 페이지의 화면을 서버가 아닌 브라우저(클라이언트)에서 자바스크립트를 통해 직접 그리는 방식입니다.

사용자가 웹사이트에 접속했을 때 서버는 HTML 껍데기와 자바스크립트 파일을 전송하고, 브라우저는 이 자바스크립트를 실행해서 실제 컨텐츠를 렌더링합니다.

즉, 브라우저가 HTML을 직접 만들고 DOM을 구성해서 사용자에게 화면을 보여주는 구조입니다.

CSR은 시장에서 재료만 사 와서 집에서 직접 요리를 해 먹는 것과 같습니다.
즉, 데이터, JS(요리 재료)만 전달받고, 브라우저(사용자)가 화면을 직접 조립해서 완성하는 방식입니다.
쉽게 말해, 밀키트를 집에서 조리해 먹는 것와 비슷합니다.

CSR의 작동 과정

1. 최초 접속

사용자가 웹사이트에 처음 접속하면, 서버는 다음과 같은 리소스를 클라이언트에 전달합니다.

HTML 껍데기 파일 (예: <div id="root"></div>)
JavaScript 번들 파일
CSS 파일

<body>
  <div id="root"></div> <!-- 이 부분이 JS에 의해 채워짐 -->
  <script src="/static/js/bundle.js"></script>
</body>

2. JS 실행 및 렌더링

브라우저는 전달받은 JS 번들 파일을 다운로드하고 실행합니다.
실행된 JS는 API 요청을 보내 데이터를 받아옵니다.
받아온 데이터를 기반으로 DOM을 구성하여 실제 화면을 만듭니다.

→ 이 시점부터 브라우저가 모든 화면 렌더링을 주도하게 됩니다.

3. 페이지 전환

사용자가 다른 메뉴를 클릭하거나 페이지를 이동하게 되면,

서버에 전체 HTML을 다시 요청하지 않고,
필요한 데이터만 서버에서 받아와,
브라우저가 그 데이터를 바탕으로 화면의 일부분만 업데이트합니다.

CSR 흐름 요약

사용자가 웹사이트에 접속하면 서버는 빈 HTML(HTML 껍데기)과 JS/CSS 파일을 보냅니다.
브라우저가 자바스크립트를 실행하고 API 요청을 통해 데이터를 받아옵니다.
받아온 데이터를 기반으로 브라우저에서 DOM을 구성하고 화면을 렌더링합니다.
이후 페이지 전환 시에는 전체를 다시 로드하지 않고 필요한 데이터만 받아와 해당 부분만 업데이트합니다.

  서버 → 빈 HTML 껍데기만 전송
  브라우저 → JS 로드 및 실행
  JS → DOM 구성 및 렌더링

CSR 장점

1. 부드럽고 빠른 페이지 전환

전체 HTML을 다시 받지 않고 필요한 부분만 업데이트하므로, 페이지 깜빡임 없이 부드러운 사용자 경험을 제공합니다.

2. 클라이언트 중심의 인터랙션 구현

DOM을 JS로 직접 제어하므로, 모달, 알림창, 애니메이션 등 풍부한 사용자 경험 구현이 용이합니다.

3. API와의 유연한 연동

대부분의 서버 통신이 비동기 API 호출(AJAX, fetch, GraphQL)로 이뤄지므로, 프론트엔드와 백엔드의 완전한 분리가 가능합니다.

4. 정적 리소스 캐싱

JS/CSS 파일은 한 번 로딩하면 브라우저가 캐싱하여 다음 방문 시 빠르게 로딩됩니다.

5. 서버 부하 감소

화면을 브라우저가 렌더링하므로, 서버는 데이터를 응답하기만 하면 되고, 매번 HTML을 생성할 필요가 없어 부하가 줄어듭니다.

CSR 단점

1. 초기 로딩 속도가 느림

최초 접속 시에는 빈 HTML과 큰 JS 번들을 받아야 하고, 이 JS가 실행되기 전까지는 화면이 보이지 않거나 로딩 중 표시만 보여집니다.

사용자 요청 → HTML 받음 → JS 로딩... → JS 실행 → 화면 구성

2. SEO(검색 엔진 최적화)에 불리함

브라우저가 자바스크립트를 실행하여 컨텐츠를 동적으로 만드는데, 이 과정이 실행되기 전에는 빈 HTML이 먼저 화면에 보이게 됩니다.
이 때문에 검색 엔진(웹 크롤러)이 빈 HTML만 보고 콘텐츠가 없는 것으로 인식할 수 있어 검색 노출에 불리하게 작용할 수 있습니다.

검색 엔진 최적화(SEO, Search Engine Optimization)는
구글, 네이버 같은 검색 엔진에서 웹사이트가 더 잘 노출되도록 만드는 작업을 말합니다.

3. 자바스크립트 의존도 높음

CSR은 자바스크립트 실행 없이는 화면 자체를 만들 수 없습니다.
사용자의 브라우저에서 JS 실행이 불가능하거나, 로딩 오류가 발생하면 아무것도 안 보일 수 있습니다.

SSR (Server Side Rendering) - 서버 사이드 렌더링

서버에서 HTML을 렌더링하여 클라이언트에 전달하는 방식

SSR(Server Side Rendering)은 서버 사이드 렌더링의 줄임말로,
브라우저가 요청한 시점에 서버가 HTML을 생성해 클라이언트에 전달하는 방식입니다.

CSR과 달리 브라우저가 자바스크립트를 실행해서 DOM을 생성하는 것이 아니라, 서버에서 이미 완성된 HTML을 만들어 클라이언트에게 전달하고, 브라우저는 전달받은 HTML을 바로 렌더링합니다.

SSR은 레스토랑에서 요리사가 손님의 주문을 받고 그때그때 요리를 만들어 제공하는 것과 같습니다.
요청이 올 때마다 서버가 HTML(요리)을 즉석에서 만들어 브라우저(손님)에게 제공하는 구조입니다.

SSR의 작동 과정

1. 페이지 요청

사용자가 웹사이트에 접속하면, 서버는 다음 순서로 동작합니다.

사용자가 요청한 페이지에 필요한 데이터를 서버가 가져옵니다.
(예: “1번 상품 페이지를 보여줘” → 상품 정보 가져오기)
서버 내부에서 자바스크립트를 실행하여 HTML을 생성합니다.
(HTML 틀 안에 상품 이름, 가격, 이미지 등을 채워 넣음)
완성된 HTML을 클라이언트(브라우저)로 전송합니다.
→ 사용자는 이 HTML을 바로 받아 화면으로 볼 수 있습니다

2. HTML 수신 및 렌더링

사용자의 브라우저는 서버에서 받은 HTML을 그대로 화면에 보여줍니다.
→ JS 실행 없이도 콘텐츠가 즉시 보이기 때문에 화면 전환이 빠르게 느껴집니다.
그 다음, HTML 아래에 연결된 자바스크립트 파일이 로딩됩니다.
이 파일은 페이지에 클릭, 스크롤 같은 인터랙션 기능을 추가해줍니다.
이 과정을 Hydration(하이드레이션)이라고 부릅니다.
→ 이미 화면에 있는 HTML에 동작(이벤트)을 덧붙이는 과정이라고 생각하면 됩니다.

인터랙션(Interaction)은 사용자가 시스템(웹사이트, 애플리케이션 등)과 상호작용하는 과정을 의미합니다.
즉, 사용자가 버튼을 클릭하거나, 입력을 하거나, 스크롤하거나, 마우스를 올리는 등의 행위를 통해
시스템과 정보를 주고받고 반응을 유도하는 모든 행위를 인터랙션이라고 합니다.

하이드레이션(Hydration)이란, 서버 또는 빌드 시점에 미리 생성된 정적 HTML에 브라우저가 자바스크립트를 연결하여, 클릭, 입력 등과 같은 상호작용 기능을 활성화하는 과정을 말합니다.
즉, 브라우저가 이미 렌더링된 HTML을 보여준 뒤, 자바스크립트를 통해 인터랙션을 덧붙여 웹페이지를 완성하는 방식입니다.

SSR 흐름 요약

사용자가 웹사이트에 접속하면, 서버는 필요한 데이터를 조회하고 해당 페이지에 맞는 HTML을 생성합니다.
서버는 완성된 HTML을 클라이언트(브라우저)로 전송합니다.
브라우저는 받은 HTML을 그대로 렌더링하여 화면에 출력합니다.
이후 사용자가 다른 페이지로 이동하면, 서버는 해당 페이지의 HTML을 새로 생성하여 다시 전송합니다.

  서버 → 완성된 HTML 전송
  브라우저 → HTML 파싱 → 바로 DOM 구성
  JS → 하이드레이션으로 동작 연결

SSR 장점

1. 빠른 초기 렌더링

서버에서 완성된 HTML을 제공하므로, 브라우저는 별다른 작업 없이 바로 화면을 렌더링할 수 있습니다.
로딩 시점부터 사용자에게 컨텐츠를 빠르게 제공할 수 있습니다.

2. SEO(검색 엔진 최적화)에 유리

HTML이 서버에서 이미 생성된 상태로 전달되므로, 검색 엔진 크롤러가 콘텐츠를 쉽게 수집할 수 있습니다.
검색 엔진 최적화(SEO, Search Engine Optimization)가 중요한 페이지에서 효과적입니다.

SSR 단점

1. 서버 부하 증가

페이지 요청마다 서버가 HTML을 동적으로 생성해야 하므로, 사용자 수가 많아질수록 서버 부하와 렌더링 시간 증가가 발생할 수 있습니다.

2. 복잡한 개발 구조

하나의 페이지가 서버와 클라이언트 양쪽 모두에서 JavaScript로 처리되기 때문에, 코드 구조가 복잡해지고 관리 비용이 증가할 수 있습니다.

3. 느린 페이지 전환

페이지를 이동할 때마다 서버에 새 HTML을 요청하고 전체 화면을 다시 불러오기 때문에, CSR 방식처럼 빠르고 부드러운 화면 전환이 어렵습니다.
이로 인해 화면이 잠깐 깜빡이거나 전환 속도가 느려지는 현상이 발생할 수 있습니다.

SSG (Static Site Generation) - 정적 사이트 생성

HTML을 빌드 시점에 미리 생성해 서버에 저장해두고, 요청 시 그대로 응답하는 방식

SSG(Static Site Generation)은 정적 사이트 생성 방식으로, 웹 사이트의 HTML을 빌드 시점에 미리 생성해 서버에 저장해 두고, 사용자 요청이 들어오면 서버는 이미 생성된 HTML 파일을 그대로 응답하는 구조입니다.

SSR처럼 요청 시 서버가 HTML을 새로 생성하지 않고, 사전 생성된 정적 파일을 그대로 반환하기 때문에 페이지 로딩 속도가 매우 빠르고 서버 부하도 거의 없습니다.

SSG는 요리사가 도시락처럼 요리를 미리 만들어 두고, 손님이 오면 꺼내주는 방식과 같습니다.
웹사이트를 배포할 때 HTML(도시락)을 미리 생성해두고, 요청(손님)이 오면 서버는 그 파일을 그대로 제공합니다.

SSG의 작동 과정

1. 빌드 시점에 HTML 생성

웹사이트를 배포하기 전에, 프레임워크(예: Next.js 등)는 모든 페이지에 필요한 데이터를 API 등으로 불러옵니다.
이 데이터를 기반으로 각 페이지의 HTML 파일을 정적으로 생성하고, 서버나 CDN에 저장해 둡니다.
이 작업은 배포 과정에서 한 번만 일어나며, 사용자 요청과는 무관하게 빌드 시 미리 수행됩니다.

2. 사용자 요청 시 HTML 응답

사용자가 웹사이트에 접속하면, 서버는 이미 만들어져 있는 HTML 파일을 그대로 응답합니다.
이 응답은 서버가 실시간으로 생성하는 것이 아니므로 매우 빠르게 전달됩니다.

3. 브라우저 렌더링 및 하이드레이션(Hydration)

브라우저는 받은 HTML을 즉시 렌더링하여 사용자에게 보여줍니다.
이후 로딩된 자바스크립트 파일이 작동하면서, 클릭, 스크롤, 폼 입력 같은 인터랙션 기능을 활성화(하이드레이션)합니다.

❗️참고
하이드레이션은 SSR이나 SSG처럼 미리 렌더링된 HTML을 사용할 때 발생하며,
CSR에서는 전체를 자바스크립트로 구성하기 때문에 별도의 하이드레이션 과정이 없습니다.

4. 추가 페이지 요청

사용자가 다른 페이지로 이동하더라도, 서버는 해당 페이지의 HTML을 미리 생성해 두었기 때문에
새로운 요청마다 동일하게 정적 파일을 응답합니다.

SSG 흐름 요약

빌드 시점에 서버는 모든 가능한 요청에 대한 HTML을 미리 생성하고 저장합니다.
사용자가 웹사이트에 접속하면, 서버는 미리 생성해 둔 HTML을 전송합니다.
브라우저는 전송받은 HTML을 렌더링하고, 이후 자바스크립트가 로딩되어 동작을 활성화합니다.
추가 페이지 요청 시에도, 서버는 미리 생성해 둔 해당 페이지의 HTML을 전송합니다.

  배포 시점 → 정적 HTML 생성 
  서버 → 이미 생성된 HTML 전송
  브라우저 → HTML 파싱 → 바로 DOM 구성
  JS → 하이드레이션으로 동작 연결

SSG 장점

1. 매우 빠른 응답 속도

HTML이 미리 만들어져 있기 때문에, 사용자 요청 시 서버는 바로 파일을 응답할 수 있습니다.
서버 처리 없이도 동작하므로 CDN(컨텐츠 전송 네트워크)를 통해 전 세계 어디서나 빠르게 응답할 수 있습니다.
- HTML이 미리 만들어져 있기 때문에, 사용자 요청 시 서버는 즉시 정적 파일을 응답할 수 있습니다.
  또한 이러한 정적 파일은 CDN(Content Delivery Network)을 활용해 전 세계에 분산 저장할 수 있으며,
  이를 통해 사용자와 가까운 위치에서 콘텐츠를 제공함으로써 더 빠르고 안정적인 응답이 가능합니다.

CDN (Content Delivery Network)은 전 세계 여러 지역에 분산된 서버들의 네트워크로,
웹 콘텐츠(HTML, CSS, JS, 이미지, 영상 등)를 사용자에게 더 빠르게 전달하기 위한 시스템입니다.

2. 서버 부하 감소

HTML 생성은 빌드 시 한 번만 수행되고, 그 이후에는 미리 생성된 파일만 제공하므로 서버 자원이 거의 들지 않습니다.

3. SEO(검색 엔진 최적화)에 매우 유리

HTML이 처음부터 완성된 상태로 존재하므로, 검색 엔진이 모든 컨텐츠를 바로 읽을 수 있습니다.

SSG 단점

1. 실시간 데이터 반영 어려움

HTML이 사전에 고정된 형태로 생성되기 때문에, 데이터가 변경되어도 자동으로 반영되지 않습니다.

예를 들어, 블로그 댓글, 상품 재고, 날씨 정보, 인기 글 순위와 같이 실시간으로 자주 변하는 정보는
정적 HTML에 미리 포함시킬 수 없기 때문에, 브라우저(클라이언트)가 별도로 API를 호출해 서버에서 데이터를 받아와야 합니다.

2. 빌드 시간 증가

페이지 수가 많아질수록 빌드 시점의 HTML 생성 작업이 오래 걸릴 수 있습니다.

대규모 컨텐츠를 다룰 때에는 정적 파일 생성이 병목이 될 수 있습니다.

3. 자주 바뀌는 컨텐츠에 부적합

새로운 글이나 데이터를 추가할 때마다 사이트 전체를 다시 빌드해야 반영됩니다.

CSR, SSR, SSG 비교 정리

표: 렌더링 방식 비교

항목	CSR (Client Side Rendering)	SSR (Server Side Rendering)	SSG (Static Site Generation)
렌더링 위치	브라우저(클라이언트)	서버	빌드 시점(정적 생성)
HTML 생성 시점	요청 후 브라우저에서 생성	요청 시 서버에서 생성	빌드 시 미리 생성
초기 로딩 속도	느림	빠름	매우 빠름
페이지 전환 속도	매우 빠름	보통	빠름
SEO	불리함	유리함	매우 유리함
실시간 데이터 처리	매우 유리	유리	별도 API 필요
서버 부하	낮음	높음	거의 없음
개발 복잡도	낮음	중간	낮음
사용자 경험	앱처럼 부드러움	깜빡임 가능	빠르고 안정적

상황별 적합한 렌더링 방식

상황	추천 방식	이유
관리자 페이지, 대시보드, 내부 시스템	CSR	로그인 기반, SEO 필요 없음, SPA 구조
뉴스, 쇼핑몰 메인, 블로그 등	SSR	빠른 초기 렌더링 + SEO 고려
기술 문서, 회사 소개, 포트폴리오	SSG	콘텐츠 고정, 빠른 응답, 캐싱 유리
실시간 대시보드, 알림 시스템	CSR 또는 SSR	빠른 화면 전환 또는 서버 기반 응답
검색엔진 노출이 중요한 페이지	SSR 또는 SSG	HTML이 처음부터 완성돼 있어야 크롤러 인식 가능
정적인 페이지가 수백/수천 개 존재	SSG	한 번만 빌드하면 트래픽과 무관하게 빠른 응답 가능
실시간성 중요, 데이터 자주 변경	❌ SSG 부적합	빌드 후 HTML 고정 → 최신 정보 반영 어려움

SSR vs SSG 구조

항목	SSR	SSG
HTML 생성 시점	요청이 들어올 때마다 서버가 HTML을 동적으로 생성	배포할 때 한 번만 HTML을 미리 생성 (정적 파일로 저장)
HTML 생성 위치	서버 런타임	빌드 타임
클라이언트에 전달되는 구성	✅ 완성된 HTML + 하이드레이션용 JS	✅ 완성된 HTML + 하이드레이션용 JS
하이드레이션 필요 여부	✅ 있음	✅ 있음
실시간성	✅ 최신 데이터 반영 가능	❌ 최신 데이터 반영 어려움 (빌드 후 고정)
속도	느릴 수 있음 (서버 생성 부하 있음)	매우 빠름 (CDN에서 바로 응답 가능)

SSR

SSR에서는 클라이언트 요청이 들어올 때마다 서버에서 실시간으로 HTML을 생성 후 응답합니다.

[요청]
→ 서버가 DB 조회 등 데이터 처리
→ HTML을 서버에서 실시간으로 생성
→ 브라우저는 HTML을 즉시 렌더링
→ JS가 하이드레이션으로 동작 연결

SSG

SSG에서는 사이트 배포 시 .html 파일 형태로 정적 파일로 저장 후, 클라이언트 요청이 들어오면 이미 만들어진 이 정적 파일(HTML 파일)을 그대로 응답합니다.

[배포 시]
→ 모든 HTML 파일을 미리 생성 (예: build 시점)

[요청 시]
→ 서버나 CDN이 완성된 HTML을 그대로 전달
→ 브라우저는 HTML을 즉시 렌더링
→ JS가 하이드레이션으로 동작 연결

artp

donggyun_ee

이전 포스트

웹 브라우저란?

다음 포스트