서버 사이드 렌더링(SSR) vs 클라이언트 사이드 렌더링(CSR)

웹 애플리케이션을 개발할 때 화면을 어디서 렌더링할 것인지는 중요한 설계 요소이다.

 

서버에서 HTML을 생성해 클라이언트로 전달하는 SSR(Server Side Rendering) 방식과,

클라이언트에서 데이터를 받아 화면을 구성하는 CSR(Client Side Rendering) 방식은 서로 다른 특징과 장단점을 가진다.

 

 

 

 

1. 렌더링 방식의 차이

서버 사이드 렌더링(SSR) 은 사용자의 요청이 있을 때, 서버가 HTML 페이지를 완성해서 클라이언트로 전달하는 방식이다. 서버에서 템플릿과 데이터를 조합하여 렌더링이 완료된 HTML을 보내므로, 브라우저는 이를 그대로 표시하면 된다.

 

클라이언트 사이드 렌더링(CSR) 은 서버가 초기 요청에 대해 최소한의 HTML과 JavaScript 파일만 전송하고, 이후 클라이언트가 필요한 데이터를 Ajax 등을 통해 받아와 JavaScript로 화면을 구성하는 방식이다.

 

 

 

2. 처리 흐름 및 예시

SSR의 흐름

• 사용자가 웹 페이지를 요청한다.
• 서버에서 데이터를 조회하고 View 템플릿을 완성하여 HTML을 생성한다.
• HTML이 브라우저에 전송되고 바로 렌더링된다.
• 예시: Spring MVC + JSP, Thymeleaf, PHP, ASP.NET MVC

CSR의 흐름

• 초기 요청 시 HTML 껍데기와 JavaScript만 로딩된다.
• JavaScript가 실행되면서 Ajax를 통해 서버에 데이터를 요청한다.
• 데이터를 받아 화면을 동적으로 구성한다.
• 예시: React, Vue, Angular 등 SPA 프레임워크

 

 

 

3. 초기 로딩, 성능, 서버 부하

SSR의 특징

• 초기 렌더링 속도가 빠르다.
• 브라우저가 도착한 HTML을 바로 표시할 수 있으므로 사용자 경험이 빠르다.
• 서버가 렌더링을 담당하기 때문에 트래픽이 많아지면 서버 부하가 증가할 수 있다.

CSR의 특징

• 초기 로딩은 느릴 수 있으나, 이후 페이지 전환은 빠르다.
• 클라이언트가 렌더링을 담당하므로 서버 부하가 적고 확장성이 좋다.
• JS가 차단된 환경이나 저사양 브라우저에서는 사용자 경험이 저하될 수 있다.

 

 

 

4. SEO(Search Engine Optimization) 및 사용자 경험

SSR은 SEO에 유리하다

• 서버가 완성된 HTML을 제공하므로 검색 엔진이 콘텐츠를 바로 읽을 수 있다.
• 블로그, 커머스, 뉴스 등 검색 엔진 노출이 중요한 서비스에 적합하다.

CSR은 SEO에 불리할 수 있다

• 콘텐츠가 JavaScript 실행 이후 생성되므로 검색 엔진이 모든 콘텐츠를 수집하지 못할 수 있다.
• 최근 구글은 CSR 기반의 웹사이트도 일부 인덱싱 가능하지만, 완전하지 않다.

사용자 경험 관점에서의 차이

• SSR은 페이지 전환마다 서버 요청이 발생하여 새로고침이 일어나는 구조이다.
• CSR은 SPA 구조로 페이지 전환 시 부드럽고 자연스러운 사용자 경험을 제공한다.

 

 

 

 

5. 개발 방식 및 활용 예

SSR 개발 방식

• 서버에서 템플릿 엔진(JSP, Thymeleaf 등)을 사용하여 HTML을 생성한다.
• View 로직과 데이터 처리가 같은 서버에 포함되어 있는 경우가 많다.
• 전통적인 웹 프로젝트에 적합하다.

CSR 개발 방식

• JavaScript 프레임워크를 사용해 프론트엔드와 백엔드를 분리한다.
• API 서버와 프론트엔드 서버를 분리해 독립적인 개발과 배포가 가능하다.
• 대규모 사용자 인터랙션이 필요한 서비스에 적합하다.

 

---

 

결론

SSR과 CSR은 각자의 장단점을 가진 렌더링 방식이다.

초기 속도와 SEO가 중요하고, 서버 중심의 구조를 선호한다면 SSR이 적합하다.

반면, 풍부한 사용자 인터페이스와 SPA 구조가 필요한 경우에는 CSR이 효과적이다.

최근에는 초기 페이지만 SSR로 구성하고, 이후 동작은 CSR로 처리하는 하이브리드 방식도 많이 사용된다.