클라이언트 사이드 렌더링(Client-Side Rendering, CSR)은 웹 애플리케이션의 렌더링을 클라이언트 측에서 처리하는 방식입니다. CSR은 React와 같은 JavaScript 프론트엔드 프레임워크와 함께 주로 사용되며, 동적인 사용자 경험과 인터랙티브한 UI를 구현하는 데 유용합니다. 이 포스팅에서는 CSR의 개념과 작동 방식, 그리고 CSR을 사용하는 것의 장단점에 대해 알아보겠습니다.
개념
클라이언트 사이드 렌더링(Client-Side Rendering, CSR)은 웹 애플리케이션의 렌더링을 클라이언트 측에서 처리하는 방식입니다. CSR은 서버로부터 초기 HTML 페이지를 받아오고, 그 이후에 JavaScript를 사용하여 동적으로 컨텐츠를 렌더링하고 업데이트합니다. 이를 통해 빠른 사용자 경험과 인터랙티브한 UI를 제공할 수 있습니다.
동작 과정
초기 로딩
-
클라이언트는 서버에 초기 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의 장점
좋은 사용자 경험 - CSR은 초기 페이지 로딩 후에 동적으로 컨텐츠를 업데이트할 수 있어 사용자에게 빠른 반응성과 부드러운 인터랙션을 제공합니다. 이는 사용자의 만족도를 높일 수 있습니다.
서버 부담 감소 - 서버는 초기 HTML 파일을 제공하고 이후의 데이터 요청에 응답하는 역할을 수행합니다. 정적 파일 서비스와 API 엔드포인트로 분리될 수 있으므로 서버의 부담이 상대적으로 줄어듭니다.
즉, 서버의 부담을 최소화하고 빠른 인터랙션과 트래픽 감소를 보장합니다.
CSR의 단점
초기 로딩 시간 - CSR은 초기 HTML 파일을 받은 후에 JavaScript를 로드하고 렌더링을 수행해야 합니다. 이로 인해 초기 로딩 시간이 길어질 수 있으며, 페이지의 초기 표시 속도가 느려질 수 있습니다. 사용자는 초기 로딩 시간 동안 빈 화면을 보게 될 수도 있습니다. 파일의 크기가 커질수록, 속도는 더 느려질 것입니다.
SEO - 어떤 웹이나 앱이든 SEO의 중요성을 간과할수는 없습니다. 하지만 CSR은 초기 HTML에 기반하여 동적으로 컨텐츠를 생성하므로, 검색 엔진이 페이지 내용을 색인화하기 어려울 수 있습니다. 이로 인해 SEO에 악영향을 줄 수 있습니다. 검색 엔진 최적화가 필요한 경우 이러한 점을 보완할 추가적인 작업이 필요할 수 있습니다.
보안 문제 - CSR은 클라이언트 측에서 데이터를 가져와서 렌더링하기 때문에, 보안 상의 주의가 필요합니다. 애플리케이션에서 사용자 입력을 적절하게 검증하고 이스케이프하는 등의 보안 조치가 필요합니다.
초기 로딩 시간과, SEO, 보안 등의 측면은 웹/앱에서 가장 중요한 특징 중 하나이기 때문에 상황 별 적절한 조치가 필수적입니다.
애플리케이션의 요구사항과 특성, CSR의 장/단점을 고려해 CSR을 선택할지, SSR(Server-Side Rendering)을 선택할지 결정해야합니다.
그렇다면 CSR의 적절한 사용사례는 어떤 것들이 있을까요?
대화 및 동적 애플리케이션
CSR은 대화형 앱이나 동적인 사용자 경험을 제공하는데 적합합니다. 사용자의 상호작용에 따라 즉시 변경되는 UI 요소가 다수 필요한 경우 SSR보다는 CSR이 더 선호될 수 있습니다. 예를 들면, 싱글 페이지 애플리케이션(SPA)에서 사용자가 메뉴를 클릭하거나 데이터를 필터링하는 등의 동작이 엄청 많이 필요하거나, 대화형 챗봇 서비스를 제공해야 하는 앱에서 효과적입니다.
작은 규모의 애플리케이션
초기 로딩 속도와 검색 엔진 최적화(SEO)가 크게 중요하지 않은 경우에는 CSR을 선택할 수 있습니다. 작은 규모의 애플리케이션에서 CSR은 개발 생산성이 높고, SPA를 구축하는데 용이하기 때문에 구조를 단순하게 작성할 수 있습니다. 따라서 CSR이 간단하고 빠른 개발을 가능하게 하며, 사용자 경험을 향상시킬 수 있습니다.
대규모 애플리케이션
대규모 애플리케이션에서는 초기 로딩 속도, SEO, 복잡한 상태 관리가 중요한 요소입니다. CSR은 복잡한 상태 관리와 동적인 UI 요구사항을 처리하는데 적합하며, 단점이라고 할 수 있는 초기 로딩 속도나 SEO는 코드 스플리팅과 서버 사이드 렌더링(SSR)과 결합하여 개선할 수 있습니다.
또한, 복잡한 상태 관리가 필요한 대규모 애플리케이션에서 Redux, MobX, Zustand 등과 같은 상태 관리 라이브러리를 함께 사용해 보다 쉬운 상태 관리가 가능합니다.
하지만 특정 사례를 예시로 드는것 보다는, 개발하고자 하는 애플리케이션의 규모와 요구사항을 적절히 고려하여 SSR 또는 CSR을 선택하는 것이 중요합니다.
다음 포스팅에서는 SSR(Sever-side Rendering)에 대해서 알아보겠습니다.
https://dev.to/novu/building-a-chat-app-with-socketio-and-react-2edj - image 2
