[SSR / CSR] 서버 사이드 / 클라이언트 사이드 렌더링

SSR(서버 사이드 렌더링)과 CSR(클라이언트 사이드 렌더링)은 웹 애플리케이션에서 페이지를 렌더링하는 방식의 두 가지 주요 방법입니다. 이 두 가지 방식은 웹 애플리케이션이 어떻게 화면을 그리는지, 그리고 이 과정에서 서버와 클라이언트가 각각 어떤 역할을 맡는지에 따라 다릅니다.

1. SSR (서버 사이드 렌더링, Server

-Side Rendering)

SSR은 웹 페이지의 HTML을 서버에서 생성한 후 클라이언트에 전달하는 방식입니다. 클라이언트가 요청을 보내면 서버는 해당 페이지에 필요한 데이터를 가져와 HTML을 생성하고, 완성된 HTML을 클라이언트에 전달합니다. 클라이언트는 받은 HTML을 그대로 표시합니다.

동작 방식

• 요청 → 서버: 클라이언트(브라우저)가 페이지를 요청하면 서버가 해당 페이지의 HTML을 렌더링하여 응답합니다.
• 클라이언트: 클라이언트는 렌더링된 HTML을 받으며, 그 후 자바스크립트가 실행되면 추가적인 동작이 가능해집니다.

장점

• 빠른 초기 렌더링: 서버에서 미리 렌더링된 HTML을 전달하므로 페이지가 빨리 로드됩니다. 특히 검색 엔진 최적화(SEO)가 중요한 경우 유리합니다.
• SEO 최적화: 검색 엔진 크롤러가 서버에서 렌더링된 HTML을 그대로 가져오므로 SEO에 유리합니다.

단점

• 서버 부하: 각 페이지 요청마다 서버에서 HTML을 생성하므로 서버에 부담이 큽니다.
• 느린 상호작용: HTML이 준비된 후 자바스크립트가 실행되기 전까지는 상호작용이 제한적일 수 있습니다.

사용 예시

• Next.js(React 기반의 SSR 프레임워크)
• Nuxt.js(Vue.js 기반의 SSR 프레임워크)

---

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

CSR은 웹 페이지를 클라이언트(브라우저)에서 생성하는 방식입니다. 클라이언트가 처음 페이지를 요청하면 빈 HTML 파일만 반환되고, 그 후에 자바스크립트가 실행되어 데이터를 요청하고 화면을 구성합니다. 클라이언트에서 모든 렌더링과 로직을 처리합니다.

동작 방식

• 요청 → 서버: 클라이언트는 HTML 파일을 요청하고, 서버는 빈 HTML 파일을 반환합니다.
• 클라이언트: 자바스크립트가 실행되어 API나 서버에서 데이터를 가져오고, 이 데이터를 바탕으로 화면을 렌더링합니다.

장점

• 서버 부하 감소: 페이지 렌더링이 서버가 아닌 클라이언트에서 이루어지므로 서버에 부담이 적습니다.
• 동적인 웹 애플리케이션: 클라이언트에서 페이지 전환이나 상태 관리를 유연하게 할 수 있어 SPA(Single Page Application)에 적합합니다.
• 빠른 상호작용: 페이지를 한 번 로드한 후, 서버와의 통신 없이 빠르게 상호작용할 수 있습니다.

단점

• 초기 로딩 시간: 자바스크립트가 다운로드되고 실행된 후에야 페이지가 렌더링되므로 초기 로딩 시간이 길어질 수 있습니다.
• SEO 최적화 문제: 검색 엔진 크롤러가 자바스크립트로 동적으로 렌더링된 내용을 제대로 인식하지 못할 수 있습니다.

사용 예시

• React (CSR 방식으로 많이 사용)
• Vue.js
• Angular

---

SSR vs CSR 비교

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

렌더링 위치	서버에서 HTML을 렌더링	클라이언트(브라우저)에서 자바스크립트를 이용해 렌더링
SEO	SEO에 유리 (검색 엔진이 HTML을 그대로 읽을 수 있음)	SEO에 불리 (자바스크립트로 렌더링된 콘텐츠는 크롤링이 어려움)
초기 로딩 속도	빠른 초기 로딩 (HTML이 서버에서 렌더링되어 빠르게 로드)	느릴 수 있음 (자바스크립트가 로드되어야 페이지가 렌더링됨)
서버 부하	서버 부하가 큼 (매번 페이지 요청 시 서버에서 렌더링)	서버 부하가 적음 (클라이언트에서 렌더링)
상호작용	초기 렌더링 후 동적 상호작용을 추가로 처리해야 함	빠른 동적 상호작용 (SPA에 적합)
사용 예시	Thymeleaf, Next.js, Nuxt.js	React, Vue.js, Angular