[Frontend] CSR(Client-Side Rendering) vs SSR(Server-Side Rendering)

CSR(Client-Side Rendering)

개념

• 클라이언트 사이드 렌더링(Client-Side Rendering, CSR)은 웹 애플리케이션의 렌더링을 클라이언트 측에서 처리하는 방식
• CSR은 서버로부터 초기 HTML 페이지를 받아오고, 그 이후에 JavaScript를 사용하여 동적으로 콘텐츠를 렌더링하고 업데이트함. 이를 통해 빠른 사용자 경험과 인터렉티브한 UI를 제공할 수 있음
• CSR은 React와 같은 JavaScript 프론트엔드 프레임워크와 함께 주로 사용

동작 과정

초기 로딩

• 클라이언트는 서버에 초기 HTML 파일을 요청함
• 서버는 해당 HTML 파일을 응답하여 클라이언트에게 전달함

HTML 파일 로드

• 클라이언트는 서버로부터 받은 HTML 파일을 로드함
• HTML 파일에는 애플리케이션의 기본적인 구조와 초기 데이터가 포함되어 있음

JavaScript 실행

• 클라이언트는 HTML 파일의 JavaScript 코드를 실행함
• JavaScript 코드는 주로 프레임워크 또는 라이브러리를 통해 작성된 애플리케이션 로직이 포함되어 있음

가상 DOM(Virtual DOM) 생성

• JavaScript 코드가 실행되면 가상 DOM이 생성됨
• 가상 DOM은 실제 DOM의 작은 복사본으로, 변경 사항을 추적하고 업데이트할 수 있는 구조

실제 DOM 조작

• 가상 DOM을 기반으로 실제 DOM을 조작함
• 변경된 부분만 업데이트하여 화면에 반영

컴포넌트 렌더링

• 컴포넌트는 애플리케이션의 UI 단위
• 클라이언트는 컴포넌트를 가상 DOM과 매칭하여 렌더링함
• 변경된 데이터가 있을 경우, 해당 컴포넌트만 다시 렌더링

이벤트 처리

• 사용자의 입력에 따라 이벤트가 발생함
• 이벤트 처리기는 JavaScript 코드에서 정의되어 있으며, 컴포넌트를 업데이트하거나 다른 작업을 수행할 수 있음

CSR에서 서버의 역할은 초기 HTML 파일을 제공하는 것. 이후의 렌더링 및 데이터 업데이트는 클라이언트에서 JavaScript를 사용하여 처리함. 클라이언트와 서버는 필요한 경우 Ajax 요청을 통해 데이터를 주고 받을 수도 있음

CSR의 장점

• 좋은 사용자 경험
  CSR은 초기 페이지 로딩 후에 동적으로 콘텐츠를 업데이트할 수 있어 사용자에게 빠른 반응성과 부드러운 인터랙션을 제공함. 이는 사용자의 만족도를 높일 수 있음
• 서버 부담 감소
  서버는 초기 HTML 파일을 제공하고 이후의 데이터 요청에 응답하는 역할을 수행함. 정적 파일 서비스와 API 엔드포인트로 분리될 수 있으므로 서버의 부담이 상대적으로 줄어듬

CSR의 단점

• 초기 로딩 시간
  CSR은 초기 HTML 파일을 받은 후에 JavaScript를 로드하고 렌더링을 수행해야 함. 이로 인해 초기 로딩 시간이 길어질 수 있으며, 페이지의 초기 표시 속도가 느려질 수 있음. 사용자는 초기 로딩 시간 동안 빈 화면을 보게 될 수도 있음. 파일의 크기가 커질수록 속도는 더 느려짐
• SEO
  어떤 웹이나 앱이든 SEO의 중요성을 간과할 수는 없음. 하지만 CSR은 초기 HTML에 기반하여 동적으로 콘텐츠를 생성하므로, 검색 엔진이 페이지 내용을 색인화하기 어려울 수 있음. 이로 인해 SEO에 악영향을 줄 수 있음. 검색 엔진 최적화가 필요한 경우 이러한 점을 보완할 추가적인 작업이 필요할 수 있음
• 보안 문제
  CSR은 클라이언트 측에서 데이터를 가져와서 렌더링하기 때문에 보안 상의 주의가 필요함. 애플리케이션에서 사용자 입력을 적절하게 검증하고 이스케이프하는 등의 보안 조치가 필요함

사용 사례

• 대화 및 동적 애플리케이션
  CSR은 대화형 앱이나 동적인 사용자 경험을 제공하는데 적합함. 사용자의 상호작용에 따라 즉시 변경되는 UI 요소가 다수 필요한 경우 SSR보다는 CSR이 더 선호될 수 있음. 예를 들면, 싱글 페이지 애플리케이션(SPA)에서 사용자가 메뉴를 클릭하거나 데이터를 필터링하는 등의 동작이 엄청 많은 필요하거나, 대화형 챗봇 서비스를 제공해야 하는 앱에서 효과적임
• 작은 규모의 애플리케이션
  초기 로딩 속도와 검색 엔진 최적화(SEO)가 크게 중요하지 않은 경우에는 CSR을 선택할 수 있음. 작은 규모의 애플리케이션에서 CSR은 개발 생산성이 높고, SPA를 구축하는데 용이하기 때문에 구조를 단순하게 작성할 수 있음. 따라서 CSR이 간단하고 빠른 개발을 가능하게 하며, 사용자 경험을 향상시킬 수 있음
• 대규모 애플리케이션
  대규모 애플리케이션에서는 초기 로딩 속도, SEO, 복잡한 상태 관리가 중요한 요소. CSR은 복잡한 상태 관리와 동적인 UI 요구사항을 처리하는데 적합하며, 단점이라고 할 수 있는 초기 로딩 속도나 SEO는 코드 스플리팅과 서버 사이드 렌더링(SSR)과 결합하여 개선할 수 있음 또한, 복잡한 상태 관리가 필요한 대규모 애플리케이션에서 Redux, MobX, Zustand 등과 같은 상태 관리 라이브러리를 함께 사용해 보다 쉬운 상태 관리가 가능함

SSR(Server-Side Rendering)

개념

• 서버 사이드 렌더링(Server-Side Rendering, SSR)은 클라이언트와 서버 간의 협력으로 이루어지는 프로세스
• 웹 애플리케이션에서 클라이언트 측에서만 렌더링되던 부분을 서버에서도 렌더링하여 완전한 HTML 문서를 클라이언트에게 제공하는 기술
• 서버에서 초기 렌더링을 처리하고 클라이언트에게 완성된 HTML을 제공함으로써 초기 로딩 속도를 개선 할 수 있음
• 이후에는 클라이언트 측 JavaScript 코드가 실행되어 동적인 상호작용을 제공

동작 과정

클라이언트 요청

• 사용자가 웹 애플리케이션에 접속하면 클라이언트는 서버에 요청을 전송함

서버에서 데이터 로드

• 서버는 해당 요청에 필요한 데이터를 로드함. 데이터는 API 호출, 데이터베이스 쿼리 등을 통해 가져올 수 있음

컴포넌트 렌더링

• 서버는 로드한 데이터와 함께 React 컴포넌트를 렌더링함. 이 때, 컴포넌트는 사용자에게 보여질 최종 HTML을 생성하는데 사용됨

완성된 HTML 반환

• 서버는 완성된 HTML을 클라이언트에게 반환함. 이 HTML에는 컴포넌트가 렌더링된 상태와 필요한 데이터가 포함됨

클라이언트 렌더링

• 클라이언트는 받은 HTML을 브라우저에 렌더링함. 이후에는 클라이언트 측 JavaScript 코드가 실행되어 해당 페이지의 상호작용이 가능해짐
• 페이지가 로드된 이후에는 사용자의 상호작용에 따라 클라이언트 측에서 추가적인 데이터 요청이 발생하고, 필요한 부분만 업데이트됨
• 이는 일반적인 클라이언트 사이드 렌더링(CSR)과 유사함

SSR의 장점

다양한 측면에서 애플리케이션의 성능과 사용자 경험을 향상시킬 수 있음

• 초기 로딩 속도 개선
  SSR은 서버에서 렌더링된 완전한 HTML 문서를 클라이언트에게 제공하므로, 사용자는 초기에 전체 페이지를 볼 수 있음. 이는 CSR(Client-Side Rendering)과 비교했을 때 초기 로딩 속도가 빠르다는 장점을 가지고 있음. 사용자들은 빠른 페이지 로딩을 경험하며, 애플리케이션에 대한 전반적인 성능이 향상됨
• 검색 엔진 최적화(SEO)
  SSR은 서버에서 완전한 HTML 문서를 제공하기 때문에 검색 엔진 크롤러가 콘텐츠를 인덱싱하는데 용이함. 검색 엔진은 CSR에서는 자바스크립트 파일의 로딩을 기다리지 않고 HTML을 크롤링함. 따라서 SSR을 사용하면 검색 엔진이 애플리케이션의 콘텐츠를 쉽게 찾고 인덱싱할 수 있음. 이로써 검색 결과에는 노출되는 가능성이 높아지며, 애플리케이션의 가시성과 유입 경로가 향상됨
• 소셜 미리보기
  소셜 미디어 플랫폼은 URL을 스크랩하여 해당 페이지의 미리보기를 생성함. SSR을 사용하면 서버에서 렌더링된 HTML 문서를 제공하므로, 미리보기가 정확하고 풍부한 정보를 포함할 수 있음. 이는 사용자가 앱을 공유할 때 미리보기가 정확히 표시되어 사용자들에게 더욱 매력적인 링크를 제공할 수 있음
• 보안 강화
  SSR은 클라이언트 측 자바스크립트 코드를 외부로 노출시키지 않기 때문에 애플리케이션의 보안을 강화하는 데 도움을 줌. CSR에서는 클라이언트에게 자바스크립트 파일을 제공하여 실행되기 때문에 악의적인 사용자가 코드를 분석하거나 수정할 수 있는 위험이 존재함. SSR은 클라이언트 측에서 실행되는 코드 양을 최소화하여 보안 취약점을 줄여주
• 개발 유연성
  SSR은 서버 측에서 렌더링되기 때문에 서버 측의 다양한 기능과 환경을 활용할 수 있음. 서버 사이드의 언어나 프레임워크, 미들웨어 등 다양한 기술을 자유롭게 사용하여 애플리케이션을 개발할 수 있음. 또한 SSR은 클라이언트와 독립적으로 구현되므로 클라이언트 측 기술 변화에 영향을 받지 않고 개발을 진행할 수 있는 장점도 있음

SSR의 단점

• 서버 부하
  SSR은 서버에서 렌더링을 처리하기 때문에 서버의 부하가 증가할 수 있음. 많은 요청이 동시에 발생하거나 복잡한 컴포넌트를 렌더링해야 하는 경우 서버의 응답 시간이 증가할 수 있음. 적절한 서버 인프라와 캐싱 전략을 사용하여 서버 부하를 완화할 수 있음
• 초기 구성 복잡성
  SSR은 클라이언트와 서버 간의 상호작용이 필요하기 때문에 초기 구성이 상대적으로 복잡할 수 있음. 서버 측 라우팅, 데이터 로딩 및 상태 관리 등을 처리해야 하므로 개발자가 더 많은 작업과 공부를 해야 함. 이에 대한 복잡성을 줄이기 위해서 프레임워크나 라이브러리를 사용하는 것이 도움이 될 수 있음
• 클라이언트 자원 사용
  SSR은 초기 로딩 시에 완전한 HTML 문서를 클라이언트에게 전송함. 따라서 초기 로딩에 필요한 자원(HTML, CSS, JavaScript)의 크기가 증가할 수 있음. 이는 네트워크 대역폭을 차지하고 초기 로딩 시간을 늘릴 수 있으며, 모바일 사용자들에게는 추가적인 데이터 사용량을 초래할 수 있음
• 클라이언트 측 로딩 이중화
  SSR은 초기 렌더링을 서버에서 처리하기 때문에 클라이언트 측의 자바스크립트 로직과 중복될 수 있음. 예를 들어, 페이지 내의 동적 상호작용이나 데이터 변경이 발생하는 경우 서버와 클라이언트 간의 동기화 문제가 발생할 수 있음. 이를 해결하기 위해 초기 상태 전달 및 서버와의 데이터 통신을 조율하는 추가 작업이 필요할 수 있음
• 제한된 클라이언트 기능 사용
  SSR은 서버에서 렌더링하기 때문에 클라이언트 측 기능에 제한이 있을 수 있음. 일부 브라우저 API나 서드파티 라이브러리(개인 개발자나 프로젝트 팀, 혹은 업체 등에서 개발하는 라이브러리)는 클라이언트 환경에서만 사용 가능한 경우가 많으므로 서버 사이드에서는 이러한 기능을 사용할 수 없을 수도 있음. 이 경우, 클라이언트 측에서 추가적인 로직을 처리해야 할 수 있음

사용 사례

• 콘텐츠 사이트
  뉴스, 블로그, 포럼 등과 같은 콘텐츠 중심의 웹 사이트는 SSR을 활요하여 초기 로딩 속도를 개선하고 SEO를 향상시킴. 사용자들은 빠른 페이지 로딩과 검색 엔진에서의 노출을 기대할 수 있음
• 전자상거래 플랫폼
  전자상거래 애플리케이션은 SSR을 사용하여 초기 카탈로그 페이지, 제품 목록, 제품 상세 페이지 등을 렌더링하여 사용자들에게 빠른 로딩 속도와 검색 가능성을 제공함
• 소셜 미디어 앱
  소셜 미디어 플랫폼은 링크 공유 시 미리보기를 제공하는 데 SSR을 사용할 수 있음. 링크 클릭 시 빠른 로딩과 풍부한 미리보기 정보를 제공하여 사용자들에게 적절한 링크를 제공

💡 참고

서버사이드렌더링 vs 클라이언트 사이드렌더링 (SSR과 CSR)
클라이언트 사이드 렌더링(Client-Side Rendering, CSR)
서버 사이드 렌더링(Server-Side Rendering, SSR)