CSR & SSR

CSR : Client-Side Rendering

SSR : Server-Side Rendering

렌더링 방식과 애플리케이션 구조는 구분해서 이해해야 한다.

• CSR/SSR은 "어디에서 HTML을 만들어 화면에 그리느냐"에 대한 이야기다.
• SPA/MPA는 "페이지를 어떻게 구성하느냐"에 대한 이야기다.

즉, SPA = CSR로 단정하면 틀릴 수 있다. 요즘 프레임워크는 SPA도 SSR, SSG, 하이브리드 렌더링을 함께 지원한다.

CSR

CSR은 초기 HTML은 최소한으로 보내고, 브라우저에서 JavaScript가 실행되면서 화면을 완성하는 방식이다.

보통 API 서버는 JSON 같은 데이터를 내려주고, 실제 UI 조립은 클라이언트가 담당한다.

장점

• 화면 전환과 상호작용이 빠르다.
• 한 번 앱이 로드되면 부분 갱신이 쉽다.
• 클라이언트 상태 관리와 풍부한 인터랙션에 유리하다.

단점

• 초기 JavaScript 번들이 크면 첫 화면 표시가 늦어질 수 있다.
• 저사양 기기에서는 브라우저가 렌더링 부담을 많이 진다.
• 검색 엔진이 JavaScript를 어느 정도 실행하더라도, 중요한 페이지는 SSR/SSG가 여전히 더 안정적일 때가 많다.

SSR

SSR은 서버가 요청 시점에 HTML을 만들어 먼저 내려주는 방식이다.

브라우저는 우선 완성된 HTML을 보여주고, 이후 JavaScript가 붙으면서 상호작용 가능한 상태가 된다. 이 과정을 hydration이라고 부른다.

장점

• 첫 화면 콘텐츠를 빠르게 보여주기 쉽다.
• 검색 엔진이나 소셜 미리보기에서 유리하다.
• 느린 기기에서도 초기 렌더링 부담을 서버로 넘길 수 있다.

단점

• 서버 부담이 커질 수 있다.
• 데이터 로딩, 캐시, hydration mismatch 같은 복잡도가 늘어난다.
• 모든 페이지를 SSR할 필요는 없는데, 잘못 설계하면 비용만 커질 수 있다.

요즘은 둘 중 하나만 고르지 않는다

현대 웹 프레임워크는 보통 아래를 함께 제공한다.

• CSR
• SSR
• SSG(정적 생성)
• Streaming
• Route 단위 하이브리드 렌더링

예를 들어 마케팅 페이지는 SSG/SSR, 로그인 후 대시보드는 CSR로 구성하는 식이 흔하다.

정리

• CSR은 브라우저 중심 렌더링, SSR은 서버 중심 초기 렌더링이다.
• SPA는 렌더링 방식이 아니라 앱 구조다.
• 검색 엔진이 예전보다 JavaScript를 잘 처리하더라도, 중요한 공개 페이지는 SSR/SSG가 여전히 유리하다.
• 실무에서는 페이지 성격에 따라 렌더링 방식을 섞어 쓰는 경우가 많다.