프론트엔드 개발자 필독서 CSR 렌더링의 모든 것

2025-09-22 23:35

• 클라이언트 사이드 렌더링(CSR)은 브라우저가 자바스크립트를 사용해 직접 페이지를 그리는 현대 웹 개발의 핵심 방식.

• 초기 로딩 속도는 느릴 수 있지만, 이후에는 앱처럼 빠르고 부드러운 사용자 경험을 제공하는 것이 특징.

• SEO와 초기 성능 문제를 해결하기 위해 SSR, SSG 같은 다양한 렌더링 전략과 함께 진화하고 있음.

프론트엔드 개발자 필독서 CSR 렌더링의 모든 것

오늘날 우리가 경험하는 웹은 더 이상 단순한 정보의 나열이 아니다. 마치 잘 만들어진 데스크톱 애플리케이션처럼 부드럽고, 빠르며, 동적으로 반응한다. 이러한 변화의 중심에는 ‘클라이언트 사이드 렌더링(Client-Side Rendering, CSR)‘이라는 기술이 자리 잡고 있다. 이 핸드북은 CSR이 어떻게 웹 개발의 패러다임을 바꾸었는지, 그 내부 동작 원리는 무엇이며, 우리가 이 기술을 어떻게 현명하게 사용해야 하는지에 대한 포괄적인 안내서다.

1. 모든 것은 여기서 시작되었다 CSR의 탄생 배경

CSR을 이해하기 위해서는 먼저 웹의 발전 과정을 되짚어볼 필요가 있다. 기술은 언제나 기존의 불편함을 해결하는 과정에서 탄생하기 때문이다.

정적 웹사이트의 시대

초창기 웹은 서버에 미리 저장된 HTML 파일을 그대로 사용자에게 보여주는 ‘정적(Static)’ 방식이었다. 사용자가 링크를 클릭하면, 서버는 해당 페이지의 완전한 HTML 문서를 보내주고 브라우저는 그것을 처음부터 다시 그렸다. 페이지가 깜빡이며 새로고침되는 것은 당연한 일이었다. 단순한 정보 전달에는 문제가 없었지만, 사용자와의 상호작용이 늘어나면서 한계가 명확해졌다.

서버의 부담을 덜고 싶다 AJAX의 등장

사용자가 작은 행동을 할 때마다 전체 페이지를 새로고침하는 것은 비효율적이었다. 서버는 매번 전체 HTML을 만들어야 했고, 사용자는 불필요한 기다림을 겪어야 했다. 2005년경 등장한 AJAX(Asynchronous JavaScript and XML)는 이 문제를 해결할 실마리를 제공했다.

AJAX는 페이지 전체를 다시 로드하지 않고, 자바스크립트를 이용해 백그라운드에서 서버와 데이터를 교환하는 기술이다. 사용자가 모르게 필요한 데이터만 살짝 가져와 페이지의 일부만 업데이트할 수 있게 된 것이다. 이로써 웹은 비로소 ‘동적’이라는 수식어를 당당하게 붙일 수 있게 되었다.

웹을 ‘애플리케이션’으로 SPA의 대두와 CSR

AJAX의 성공은 개발자들에게 새로운 영감을 주었다. “페이지의 일부만 바꿀 수 있다면, 아예 최초에 한 번만 뼈대를 불러오고 그 안에서 모든 것을 처리하면 어떨까?” 이 아이디어가 바로 **단일 페이지 애플리케이션(Single Page Application, SPA)**의 시작이었다.

SPA는 말 그대로 단 하나의 HTML 페이지로 구성된 애플리케이션이다. 최초 요청 시 서버는 거의 비어있는 HTML 파일과 방대한 양의 자바스크립트 코드를 보낸다. 그러면 클라이언트, 즉 사용자의 브라우저가 이 자바스크립트를 실행하여 UI를 만들고, 이후의 모든 상호작용(페이지 이동, 데이터 요청 등)을 자바스크립트가 도맡아 처리한다.

이 과정에서 렌더링의 주체가 서버에서 클라이언트로 완전히 넘어오게 되는데, 이것이 바로 **클라이언트 사이드 렌더링(CSR)**의 핵심이다. 서버는 더 이상 UI를 그리는 데 관여하지 않고, 데이터만 제공하는 API 역할에 집중하게 된다.

2. CSR은 어떻게 동작하는가 건축 과정 엿보기

CSR의 동작 방식을 ‘조립식 주택 키트’에 비유하면 쉽게 이해할 수 있다.

1. 건축 부지(빈 HTML) 확보: 사용자가 웹사이트에 접속하면, 서버는 집을 지을 수 있는 텅 빈 땅과 같은 최소한의 HTML 파일을 보낸다. 이 파일 안에는 보통 <div id="root"></div>와 같은 뼈대만 덩그러니 놓여 있다.

2. 설계도와 자재(JS 번들) 배송: HTML 파일 안에는 <script src="app.js"></script>와 같은 태그가 포함되어 있다. 브라우저는 이 태그를 보고 집을 지을 설계도와 모든 자재가 담긴 거대한 ‘자바스크립트 번들’ 파일을 서버에 요청하여 다운로드한다.

3. 현장 건축(JS 실행 및 DOM 생성): 브라우저는 다운로드한 자바스크립트 코드를 실행한다. React, Vue, Angular와 같은 프레임워크가 이 설계도를 해석하여 어떤 구조의 집을 지을지 결정하고, 가상 DOM(Virtual DOM)과 같은 기술을 사용해 효율적으로 UI 컴포넌트들을 조립하기 시작한다.

4. 인테리어(데이터 API 호출): 집의 골격이 만들어지면 내부를 채울 가구와 가전제품이 필요하다. 자바스크립트는 API 서버에 필요한 데이터를 요청한다. 예를 들어, 사용자 정보, 게시글 목록 등을 비동기적으로 가져온다.

5. 입주(최종 렌더링): 데이터를 모두 받아오면, 자바스크립트는 비어있던 집 내부에 가구를 배치하듯 데이터를 채워 넣어 최종적으로 사용자 눈에 보이는 완전한 화면을 그려낸다. 이제 사용자는 비로소 콘텐츠를 보고 상호작용할 수 있다.

이 모든 과정이 클라이언트(브라우저)에서 일어나기 때문에 CSR이라 부른다. 한번 ‘입주’가 완료되면, 이후 다른 방으로 이동(페이지 전환)할 때는 집 전체를 부수고 새로 짓는 것이 아니라, 필요한 가구만 빠르게 교체하므로 매우 빠른 속도를 자랑한다.

3. CSR 사용 설명서 장점과 단점

모든 기술에는 명과 암이 있듯, CSR도 장점과 단점이 뚜렷하다.

장점 (CSR이 빛을 발하는 순간)

• 서버 부하 감소: 서버는 UI 렌더링에 대한 부담 없이 데이터 제공(API)에만 집중할 수 있다. 이는 서버 자원을 효율적으로 사용하고 비용을 절감하는 효과로 이어진다.

• 탁월한 사용자 경험(UX): 최초 로딩 후에는 페이지 전체를 새로고침할 필요가 없으므로 화면 전환이 매우 부드럽고 빠르다. 이는 사용자가 웹사이트가 아닌 네이티브 앱을 사용하는 듯한 착각을 불러일으킨다.

• 풍부한 생태계와 개발 생산성: React, Vue, Angular 등 강력한 프론트엔드 프레임워크(라이브러리)를 기반으로 한다. 수많은 개발 도구와 커뮤니티 지원 덕분에 복잡한 애플리케이션도 효율적으로 구축할 수 있다.

단점 (CSR을 사용하기 전 고려할 점)

• 느린 초기 로딩 속도: 사용자가 첫 화면을 보기까지의 과정이 길다. 거대한 자바스크립트 번들을 다운로드하고, 실행하고, 다시 데이터를 요청해서 화면을 그리기까지 상당한 시간이 소요될 수 있다. 이는 특히 인터넷 속도가 느리거나 디바이스 성능이 낮은 환경에서 치명적이다. 이를 나타내는 지표로 **TTI(Time to Interactive, 상호작용 가능 시간)**가 길어진다는 표현을 쓴다.

• 검색 엔진 최적화(SEO)의 어려움: 검색 엔진의 웹 크롤러(로봇)는 웹 페이지의 HTML을 분석하여 콘텐츠를 수집한다. 하지만 CSR 방식의 웹사이트는 초기 HTML이 거의 비어있기 때문에, 크롤러가 자바스크립트를 제대로 실행하지 못하면 아무런 콘텐츠도 수집하지 못하는 문제가 발생할 수 있다. (물론, 최근 구글봇은 자바스크립트 실행 능력이 크게 향상되었지만 여전히 완벽하지는 않다.)

• 사용자 디바이스 의존성: 모든 렌더링 연산을 사용자의 브라우저, 즉 사용자의 컴퓨터나 스마트폰에 떠넘기는 방식이다. 따라서 저사양 기기에서는 웹사이트가 버벅이거나 느려지는 현상이 발생할 수 있다.

CSR vs SSR 한눈에 비교하기

CSR의 특징을 명확히 이해하기 위해 전통적인 **서버 사이드 렌더링(Server-Side Rendering, SSR)**과 비교해 보자.

특징	클라이언트 사이드 렌더링 (CSR)	서버 사이드 렌더링 (SSR)
초기 로딩 속도	느림 (JS 번들 다운로드 및 실행 필요)	빠름 (완성된 HTML을 바로 받음)
페이지 전환 속도	빠름 (필요한 데이터만 비동기 교체)	느림 (매번 새로운 페이지 요청)
서버 부하	낮음 (주로 API 역할만 수행)	높음 (페이지 렌더링 책임)
사용자 경험 (UX)	우수 (앱과 유사한 부드러운 경험)	전통적인 웹 페이지 경험
검색 엔진 최적화 (SEO)	불리 (초기 HTML이 비어 있음)	유리 (콘텐츠가 채워진 HTML 제공)
개발 복잡도	초기 설정은 복잡, 이후 개발은 용이	상대적으로 단순할 수 있으나 상태 관리 복잡
적합한 애플리케이션	복잡한 상호작용이 많은 웹 앱, 대시보드	콘텐츠 중심의 웹사이트, 블로그, 뉴스

4. CSR 심화 학습 더 나은 웹을 위한 고민들

개발자들은 CSR의 단점을 극복하고 장점을 극대화하기 위해 다양한 기법들을 발전시켜 왔다.

코드 스플리팅 (Code Splitting)

거대한 자바스크립트 번들이 초기 로딩 속도를 저해하는 주범이라는 점에서 착안한 기법이다. 하나의 큰 번들 파일을 여러 개의 작은 파일로 나누는 것을 말한다. 사용자가 현재 보고 있는 페이지에 필요한 코드만 먼저 로드하고, 다른 페이지의 코드는 해당 페이지로 이동할 때 로드하는 방식이다. 이를 통해 초기 로딩 시간을 획기적으로 단축할 수 있다.

SEO 문제 해결을 위한 노력

• 프리렌더링(Prerendering): 빌드 시점에 특정 페이지들을 미리 HTML 파일로 만들어두는 방식이다. 크롤러에게는 이 미리 만들어진 HTML을 보여주고, 실제 사용자에게는 일반적인 CSR 앱처럼 동작하게 한다.

• 동적 렌더링(Dynamic Rendering): 서버에서 접속한 주체가 사람인지 크롤러인지 판단하여, 크롤러에게는 서버에서 렌더링한 HTML을, 사람에게는 기존 CSR 앱을 보내주는 방식이다.

CSR의 진화 SSR과 SSG와의 공존

최근 웹 개발 트렌드는 CSR과 SSR의 장점만을 취하려는 방향으로 나아가고 있다. Next.js(React 기반), Nuxt.js(Vue 기반)와 같은 프레임워크들이 대표적이다. 이들은 개발자가 페이지별로 렌더링 방식을 유연하게 선택할 수 있도록 지원한다.

• SSR (Server-Side Rendering): 첫 페이지는 서버에서 렌더링하여 SEO와 초기 로딩 속도를 확보하고, 이후의 상호작용은 CSR 방식으로 처리하여 부드러운 UX를 제공한다.

• SSG (Static Site Generation): 블로그나 문서 사이트처럼 내용이 자주 바뀌지 않는 페이지들은 빌드 시점에 아예 완전한 HTML 파일로 미리 생성해둔다. 이는 가장 빠른 로딩 속도를 보장한다.

이처럼 현대 웹 개발에서는 하나의 렌더링 방식만을 고집하기보다, 서비스의 특성에 맞게 다양한 전략을 조합하는 ‘하이브리드’ 방식이 각광받고 있다.

5. 결론 CSR, 여전히 강력하지만 만능은 아니다

클라이언트 사이드 렌더링(CSR)은 웹을 정적인 문서에서 동적인 애플리케이션으로 끌어올린 혁신적인 기술이다. 풍부한 상호작용과 뛰어난 사용자 경험을 제공하며, 오늘날 수많은 웹 서비스의 근간을 이루고 있다.

하지만 초기 로딩 속도와 SEO라는 명확한 단점 또한 존재한다. 따라서 모든 프로젝트에 CSR이 정답은 아니다. 우리가 만들어야 할 서비스가 무엇인지 명확히 이해하는 것이 중요하다. 관리자 대시보드나 복잡한 상호작용이 필요한 웹 앱이라면 CSR은 훌륭한 선택이다. 반면, 콘텐츠 노출이 중요한 블로그, 뉴스 사이트, 이커머스라면 SSR이나 SSG를 우선적으로 고려해야 한다.

결국 중요한 것은 기술 그 자체가 아니라, 기술을 통해 해결하고자 하는 문제다. CSR의 원리를 깊이 이해하고 그 장단점을 명확히 파악할 때, 비로소 우리는 사용자와 비즈니스 모두를 만족시키는 최적의 렌더링 전략을 선택할 수 있는 현명한 개발자가 될 수 있을 것이다.