React Server Components(RSC)를 공부하면서
기존 React의 데이터 페칭 방식과 무엇이 다른지, 그리고 SSR과는 어떤 차이가 있는지 정리한 내용입니다.
1️⃣ 기존 리액트의 문제점: Data Fetching과 Waterfall
기존 리액트에서는 데이터를 가져오는 방식이 주로 두 가지였습니다.
1. 부모에서 모든 데이터를 한 번에 가져오기
- API 요청 수는 감소
- 하지만 컴포넌트 결합도가 높아짐
- over-fetching 발생 가능
부모 컴포넌트가 필요한 모든 데이터를 한 번에 가져와 자식에게 props로 내려주는 방식입니다.
요청 횟수는 줄어들지만 컴포넌트 구조 변경 시 API도 함께 수정해야 하며,
불필요한 데이터까지 함께 요청하는 문제가 발생합니다.
2. 각 컴포넌트에서 개별적으로 데이터 요청
- 필요한 데이터만 요청 가능
- 하지만 클라이언트 ↔ 서버 간 요청이 반복됨
- 👉 Client-Server Waterfall 발생
- 렌더링 지연 → 사용자 경험 저하
특히 useEffect 기반 fetch는 렌더링 이후에 데이터 요청이 시작됩니다.
즉,
- 부모 컴포넌트 렌더링
- 부모 fetch 시작
- 부모 데이터 로딩 완료 후 자식 컴포넌트 렌더링
- 자식 fetch 시작
이처럼 요청이 순차적으로 이어지면서 네트워크 waterfall이 발생합니다.
결과적으로:
- 불필요한 대기 시간 증가
- 연속적인 네트워크 요청
- 성능 저하
문제가 발생합니다.
2️⃣ React Server Components(RSC)란?
React 18에서 도입된 개념으로,
서버에서 렌더링되고 서버에서 실행되는 컴포넌트입니다.
기존처럼 클라이언트에서 데이터를 요청하는 것이 아니라,
서버에서 컴포넌트를 실행하고 데이터를 가져온 뒤
그 결과만 클라이언트에 전달하는 방식입니다.
✅ 핵심 특징
- 클라이언트가 아닌 서버에서 데이터 fetch
- client-server waterfall 제거
- 서버 리소스(DB, 파일시스템 등)에 직접 접근 가능
- 서버 컴포넌트 코드는 클라이언트 번들에 포함되지 않음 (Zero Bundle Size)
즉,
“데이터 fetching은 서버에서, 인터랙션은 클라이언트에서”
라는 역할 분리가 가능해졌습니다.
3️⃣ RSC의 주요 장점
✅ 1. Client-Server Waterfall 제거
- 서버 내부에서 데이터 요청 → 네트워크 latency 감소
- 연속적인 API 호출 제거
그 결과, 클라이언트가 서버에 여러 번 요청하지 않아도 되기 때문에
렌더링 속도가 개선됩니다.
✅ 2. 서버 리소스 직접 접근
서버 컴포넌트에서는 다음과 같은 리소스를 직접 사용할 수 있습니다.
- 데이터베이스
- 파일 시스템
- 내부 서비스 API
이 로직은 브라우저로 전송되지 않기 때문에
보안 측면에서도 이점이 있습니다.
✅ 3. Zero Bundle Size
서버 컴포넌트 코드는 브라우저로 전달되지 않습니다.
- 무거운 라이브러리 사용 가능
- 클라이언트 번들 사이즈에는 영향이 없음
즉, 초기 로딩 속도 개선 측면에서 큰 장점입니다.
✅ 4. 자동 Code Splitting
- 서버 컴포넌트에서 import된 클라이언트 컴포넌트는 자동으로 코드 분할(code splitting)됨
React.lazy를 직접 사용하지 않아도 됨- 더 빠른 초기 번들 다운로드 가능
서버가 어떤 클라이언트 컴포넌트를 사용할지 미리 결정하므로
클라이언트는 필요한 번들만 다운로드합니다.
4️⃣ 컴포넌트 타입 3가지
RSC 도입 이후 컴포넌트는 세 가지로 구분됩니다.
| 타입 | 실행 위치 | 특징 |
|---|---|---|
| 서버 컴포넌트 | 서버 | state, useEffect 사용 불가 / 서버 리소스 접근 가능 |
| 클라이언트 컴포넌트 | 브라우저 | state, 이벤트, 브라우저 API 사용 가능 |
| 공유 컴포넌트 | 서버 + 클라이언트 | 순수 UI 로직만 작성 가능 |
👉 관심사 분리가 명확해졌습니다.
- 데이터 로직 → 서버
- 인터랙션 → 클라이언트
- 순수 UI → 공유 컴포넌트
5️⃣ Server-Side Rendering(SSR)이란?
Server-Side Rendering(SSR)은
클라이언트에서 실행될 React 코드를 서버에서 먼저 HTML로 렌더링하는 방식입니다.
대표적으로 Next.js 같은 프레임워크에서 사용됩니다.
SSR의 동작 방식
- 서버에서 React 컴포넌트를 HTML로 렌더링
- 브라우저는 완성된 HTML을 먼저 받음
- 이후 JavaScript 번들을 다운로드
- hydration 진행 후 인터랙션 활성화
SSR의 목적
- 초기 로딩 속도 개선
- 빈 화면(white screen) 문제 해결
- FCP / LCP 개선
즉, SSR의 핵심 목적은 초기 화면을 빠르게 보여주기 위한 것입니다.
6️⃣ RSC vs SSR 차이
| 구분 | RSC | SSR |
|---|---|---|
| 핵심 목표 | 번들 사이즈 감소 + 데이터 fetching 개선 | 초기 화면 빠르게 표시 |
| 해결 문제 | Client-Server Waterfall | 초기 빈 화면 문제 |
| 클라이언트 전송 코드 | ❌ 서버 컴포넌트 코드는 전송 안 됨 | ✅ 모든 컴포넌트 코드 전송 |
| 실행 구조 | 서버에서 실제로 컴포넌트 실행 | 서버에서 HTML만 먼저 생성 |
| 상태 유지 | 가능 | 새로운 요청 시 전체 HTML 재생성 필요 |
⚡ 가장 중요한 차이
🔹 SSR
- 서버는 HTML을 미리 만들어 줄 뿐
- 모든 JavaScript 코드는 결국 클라이언트로 전달됨
- 브라우저에서 다시 실행 필요
👉 서버는 “미리 보여주는 역할”
🔹 RSC
- 서버에서 실제로 컴포넌트를 실행
- 서버 컴포넌트 코드는 클라이언트에 전달되지 않음
- 번들 사이즈 감소
👉 서버는 “실제로 실행하는 역할”
7️⃣ RSC와 SSR의 관계
✔ 두 기술은 서로 대체 관계라기보다는 보완 관계이므로 함께 사용할 수 있습니다.
- SSR → 초기 HTML을 빠르게 제공
- RSC → 번들 사이즈 감소 + 데이터 fetching 구조 개선
즉,
SSR은 “빠르게 보여주기 위한 전략”
RSC는 “컴포넌트 아키텍처 개선”
8️⃣ 정리
React Server Components는 다음을 가능하게 합니다.
- Client-Server Waterfall 해결
- 번들 사이즈 감소
- 서버 리소스 직접 접근
- 자동 코드 분할
- 컴포넌트 관심사 분리
SSR은 초기 렌더링 성능을 개선하는 전략이며,
RSC는 컴포넌트 아키텍처를 개선하는 모델에 가까운 개념입니다.
🔥 한 줄 요약
React Server Components는
“데이터는 서버에서, 인터랙션은 클라이언트에서”
라는 방향으로 React 컴포넌트 구조를 재정의하는 시도이다.
📌 출처
- React 18: 리액트 서버 컴포넌트 준비하기 — 카카오페이 기술 블로그 (2022.05.20):
https://tech.kakaopay.com/post/react-server-components/
