🔎 왜 RSC가 필요한가?
📍 React의 클라이언트 중심 렌더링(CSR)의 한계
React 애플리케이션은 기본적으로 Client Side Rendring(CSR) 구조를 기반으로 동작한다. 즉, 브라우저가 모든 렌더링을 담당하고 필요한 데이터를 API를 통해 가져와 화면을 구성한다.
이 방식은 UI를 동적으로 생성하여 초기 로딩 후 빠른 페이지 전환과 부드러운 사용자 경험을 제공하는 이점이 있다. 하지만 프로젝트 규모가 커질수록 다음과 같은 문제가 발생한다.
1️⃣ 초기 로딩 속도 저하
앱에 첫 요청을 앱에 첫 요청을 보낼 때, 서버에서 오는 HTML은 사실상 빈 껍데기에 가깝다. 브라우저는 이 HTML을 받은 후, 거대한 자바스크립트 번들을 다운로드하고 실행해야만 비로소 UI를 렌더링할 수 있다. 데이터 요청은 그 후에 이루어지기 때문에, 사용자가 화면을 볼 때까지 걸리는 시간이 길어지게 된다. TTI(Time to Interact) 지연은 사용자 경험을 해치는 주범이다.
2️⃣ 자바스크립트 번들 크기 증가
앱 기능이 늘어날수록 필연적으로 클라이언트로 전송해야 할 자바스크립트 번들의 크기가 증가한다. 이 무거운 번들을 다운로드하고 파싱하고 실행하는 과정 자체가 브라우저에 큰 부하를 주고, 결국 전체적인 앱 성능 저하를 유발한다.
3️⃣ SEO(검색 엔진 최적화) 문제
검색 엔진 크롤러가 빈 HTML을 마주할 때가 많다. 클라이언트 측에서 JS가 실행되기 전에는 실질적인 콘텐츠가 없기 때문에, 검색 엔진이 페이지 내용을 제대로 색인하지 못하는 문제가 발생한다. 특히 검색 노출이 중요한 페이지에서는 치명적이다.
📍 React에서 서버 사이드 렌더링(SSR) 구조의 문제점
이러한 한계를 보완하기 위해 등장한 방식이 Server Side Rendering(SSR)이다.
SSR은 서버에서 HTML을 미리 생성해 전달하기 때문에, 사용자는 비교적 빠르게 완성된 화면을 볼 수 있다. 하지만 이 또한 다음과 같은 문제점이 있다.
1️⃣ 하이드레이션(Hydration) 비용
기존 SSR은 서버에서 완성된 HTML을 생성해서 보낸다. 하지만 이 HTML을 상호작용 가능한 상태로 만들기 위해 클라이언트에서는 다시 모든 컴포넌트의 JS 코드를 다운로드하고 실행하여 하이드레이션 과정을 거쳐야 한다.
결국 JS 번들 크기 문제는 해결되지 않고, 하이드레이션 과정 자체가 메인 스레드를 막아 초기 상호작용을 지연시키는 또 다른 성능 병목이 된다.
2️⃣ 데이터 패칭의 워터폴 문제
기존 SSR은 서버에서 데이터를 가져온 후 HTML을 생성하지만, 데이터 로딩이 느리면 전체 페이지 렌더링이 지연된다.
클라이언트 측에서는 컴포넌트 렌더링 이후에 다시 데이터를 요청하는 네트워크 워터폴(순차적인 데이터 요청)이 발생하기 쉽다.
3️⃣ 서버 리소스 낭비와 확장성 한계
기존 SSR은 사용자가 실제로 보지 않는 부분까지 모든 컴포넌트를 서버에서 HTML로 렌더링해야 하므로, 서버의 연산 리소스를 비효율적으로 사용한다.
트래픽이 많을수록 서버 부하가 크게 증가하고, 규모가 커질수록 유지 비용이 늘어나고 확장성도 떨어진다.
💡 RSC란?
React는 이러한 한계를 개선하기 위해 RSC를 도입했다.
RSC(React Server Components)는 이름 그대로 서버에서만 렌더링되는 컴포넌트이다.
기존의 CSR이나 SSR처럼 브라우저에서 모든 자바스크립트를 실행하는 방식이 아니라, 서버가 미리 컴포넌트를 렌더링하고 그 결과를 클라이언트로 전송한다.
즉, 서버는 데이터 패칭과 렌더링 같은 무거운 연산을 맡고, 클라이언트는 상호작용과 이벤트 처리에 집중한다.
✍🏻 RSC의 주요 특징
-
번들 크기 최소화
서버에서 렌더링된 결과만 클라이언트로 전달되므로,
전송되는 자바스크립트 양이 획기적으로 줄어든다. -
빠른 초기 렌더링
브라우저는 필요한 JS만 다운로드하기 때문에
Time To Interactive(TTI) 가 크게 단축된다. -
보안성 향상
데이터 패칭 로직이 서버에서 수행되므로,
API 키나 민감한 로직이 클라이언트에 노출되지 않는다. -
코드 구조 단순화
데이터 로직과 UI 로직이 명확히 분리되어,
유지보수성과 가독성이 개선된다.
🧩 RSC 동작 원리
RSC의 동작 방식은 기존과는 완전히 다르다. 핵심은 서버가 클라이언트에게 HTML이 아닌 RSC Payload라는 특별한 데이터 구조를 보낸다는 점이다.
-
요청 및 서버 컴포넌트 실행 : 클라이언트가 페이지를 요청하면, 서버는 해당 페이지의 서버 컴포넌트(RSC)를 실행하고 필요한 데이터를 미리 패칭한다.
async/await를 컴포넌트 내부에서 자유롭게 사용할 수 있다. -
RSC Payload 생성 : 서버는 실행 결과를 RSC Payload라는 직렬화된 데이터 포맷으로 변환한다. 이 페이로드는 렌더링된 UI 구조, 클라이언트 컴포넌트가 들어갈 자리와 JS 파일 경로 등을 담고 있다.
-
스트리밍 전송 : 이 Payload는 클라이언트에게 스트리밍 방식으로 전송된다. 데이터 로딩이 완료된 부분부터 끊김 없이 UI를 구성할 수 있게 한다.
-
클라이언트 재구성 및 최소 하이드레이션 : 클라이언트는 Payload를 받아서 React 컴포넌트 트리를 재구성한다. 이 과정에서 상호작용이 필요한 클라이언트 컴포넌트 영역에 대해서만 해당 JS 파일을 다운로드하고 최소한의 하이드레이션을 수행한다.
-
RSC 영역은 이미 완성된 결과만 보여주므로 하이드레이션이 필요 없다. 이 분업 방식 덕분에 클라이언트가 다운로드할 JS 양이 줄어들어 초기 로딩 속도(TTI)가 획기적으로 개선된다.
🧐 SSR vs RSC
RSC는 SSR(Server-Side Rendering)의 단점을 보완하며 등장했지만, 둘은 근본적으로 지향하는 목표와 작동 방식이 다르다. 아래 표를 보면 차이가 명확하게 드러난다.
| 구분 | SSR (기존 방식) | RSC (React Server Components) |
|---|---|---|
| 서버 렌더링 결과물 | HTML 문서 (전체 페이지) | RSC Payload (직렬화된 컴포넌트 트리) |
| 클라이언트 JS 번들 | 모든 컴포넌트의 JS 코드 포함 (하이드레이션 필수) | Client Component에 필요한 JS 코드만 포함 |
| 하이드레이션 | HTML을 상호작용 가능하게 만들기 위해 전체 페이지에서 필요하다. (비용이 크다) | 오직 Client Component 영역에서만 필요하다. (비용 최소화) |
| 데이터 패칭 | 서버에서 전체 데이터를 기다린 후 HTML 생성 (블로킹) | 서버에서 컴포넌트 단위로 패칭 후 스트리밍으로 전달 (비블로킹) |
| 핵심 목표 | SEO 개선 및 초기 콘텐츠의 빠른 노출 | JS 번들 사이즈 최소화 및 TTI 개선 |
결론적으로, SSR은 "HTML 껍데기를 먼저 보여주자"였다면, RSC는 "상호작용이 없는 코드는 클라이언트에게 아예 보내지 않겠다"는 근본적인 성능 최적화 철학을 갖고 있다. RSC는 SSR의 문제점인 무거운 하이드레이션 비용까지 해결하는 새로운 아키텍처이다.
