Antigravity Agent
9.0 KiB
9.0 KiB
category, tags, title, description, last_updated
| category | tags | title | description | last_updated | ||||
|---|---|---|---|---|---|---|---|---|
| Frontend |
|
React Server Components | React Server Components(RSC)는 서버에서만 독점적으로 실행되고 클라이언트의 자바스크립트 번들에서 완전히 제외되는 새로운 유형의 컴포넌트 패러다임이다 [1-3]. | 2026-05-04 |
React Server Components
📌 Brief Summary
React Server Components(RSC)는 서버에서만 독점적으로 실행되고 클라이언트의 자바스크립트 번들에서 완전히 제외되는 새로운 유형의 컴포넌트 패러다임이다 [1-3]. 이들은 데이터베이스나 파일 시스템에 직접 접근할 수 있으며, 전통적인 SSR(서버 사이드 렌더링)과 달리 클라이언트에서의 하이드레이션(Hydration) 과정이 필요하지 않아 초기 로딩 속도와 상호작용성을 크게 향상시킨다 [4, 5]. 클라이언트 컴포넌트와 결합하여 사용할 수 있으며, 'RSC 페이로드(RSC Payload)'라는 직렬화된 UI 트리 설명을 통해 클라이언트와 통신한다 [6-8].
📖 Core Content
- 작동 방식 및 RSC 페이로드
RSC는 서버에서 렌더링되어 HTML이 아닌 JSON 형태와 유사한 'RSC 페이로드'로 직렬화되어 클라이언트로 전송된다 [6-8]. 반면, 기존 방식의 React 컴포넌트는 클라이언트 컴포넌트로 불리며
'use client'지시어를 명시하여 사용하고 서버와 클라이언트 양쪽에서 모두 렌더링될 수 있다 [9, 10]. - 데이터 페칭 및 비동기 스트리밍
서버 컴포넌트는 비동기 함수(
async)로 작성될 수 있어 컴포넌트 내부에서 직접 데이터베이스 요청을await할 수 있다 [11].Suspense와 결합하면 서버 컴포넌트의 데이터가 준비되는 대로 클라이언트에 푸시하는 **순서 없는 스트리밍(out-of-order streaming)**이 가능하여, 느린 쿼리가 전체 페이지의 렌더링을 차단하지 않는다 [12-15]. - 클라이언트 및 서버 컴포넌트의 교차 사용(Interleaving)
클라이언트 컴포넌트는 서버 컴포넌트를 직접 임포트하여 렌더링할 수 없다 [16]. 하지만 서버 컴포넌트를 클라이언트 컴포넌트의
children과 같은 프로퍼티(Prop)로 전달하는 방식으로는 중첩 사용이 가능하다 [17, 18]. 프로퍼티는 직렬화가 가능하므로 번들러가 이를 문제없이 처리할 수 있다 [18]. - 성능 및 번들 크기 최적화 서버 컴포넌트의 코드는 클라이언트 번들에 포함되지 않기 때문에 애플리케이션의 규모가 커지더라도 자바스크립트 번들 크기가 증가하지 않는다 [19]. 이는 무거운 서드파티 라이브러리(예: 구문 강조 라이브러리)를 번들 크기 증가의 부담 없이 서버에서만 자유롭게 활용할 수 있도록 해준다 [20, 21].
⚖️ Trade-offs & Caveats
- 기능적 제약 사항
서버 컴포넌트는 렌더링 후 다시 렌더링(re-render)되지 않으므로
useState,useEffect등의 상태 관리나 생명주기 훅을 사용할 수 없다 [4, 22, 23]. 또한 브라우저 전용 API나 이벤트 핸들러를 가질 수 없으며, 서버에서 클라이언트로 함수(Function)와 같이 직렬화 불가능한 값을 전달할 수 없다 [4, 24]. - 치명적인 보안 위험 (Security Risks)
서버에서 데이터를 수정하는 서버 액션(
"use server")은 본질적으로 퍼블릭 HTTP 엔드포인트로 작동한다 [25]. 클라이언트의 입력값을 일반적인 API처럼 철저히 검증하지 않으면 인가되지 않은 원격 코드 실행(RCE) 등의 치명적인 보안 취약점(예: React2Shell)이 발생할 수 있다 [25-27]. 또한, 서버 컴포넌트에서 클라이언트 컴포넌트로 프로퍼티를 넘길 때 클라이언트가 렌더링에 필요로 하는 데이터 이상을 전달하면 네트워크 탭의 RSC 페이로드에 민감한 정보가 모두 노출된다 [28]. - 복잡성 증가 및 툴링 한계
클라이언트/서버 경계를 나누고 관리해야 하므로 아키텍처의 복잡성과 개발자의 인지적 부하가 크게 증가한다 [29, 30]. 원칙을 이해하지 못하고 모든 곳에
'use client'를 무분별하게 추가하는 방식은 번들 크기 감소의 이점 없이 구조적 복잡성과 보안 표면만 늘리는 안티 패턴이 될 수 있다 [29, 31]. 현재 완벽하게 RSC를 지원하는 프로덕션 프레임워크는 사실상 Next.js에 국한되어 있으며,emotion과 같은 기존의 CSS-in-JS 라이브러리 지원에 문제점들이 존재한다 [32, 33]. - 데이터 캐싱과 직렬 처리 한계
서버 액션(
revalidateTag등)을 통해 데이터를 갱신할 때 해당 변경 사항만 업데이트되는 것이 아니라 전체 RSC 트리가 다시 렌더링되면서 데이터를 재요청하는 비효율이 발생할 수 있다 [34, 35]. 추가로 현재 서버 액션은 직렬로만 실행되므로 느린 네트워크 환경에서는 큰 병목 현상을 유발할 수 있다 [36].
Last updated: 2026-05-03
📚 Legacy Insights & Additional Context
Note
Below is content merged from previous versions of this documentation.
📌 Brief Summary
React Server Components(RSC)는 서버에서만 실행되어 클라이언트로 전송되는 자바스크립트 번들 크기를 획기적으로 줄이는 성능 최적화 아키텍처다. 상호작용이 없는 정적 UI는 서버에서 완전히 렌더링하고 필요한 클라이언트 컴포넌트만 브라우저로 전송함으로써, 하이드레이션 비용을 절감하고 초기 로딩 속도를 극대화한다.
📖 Core Content
- 서버 사이드 전용 렌더링
- 서버 컴포넌트는 클라이언트 번들에 포함되지 않아 번들 사이즈가 줄어들고 데이터베이스/API에 직접 접근이 가능하다.
- 번들 및 하이드레이션 최적화
- 정적 UI를 서버에서 미리 렌더링하여 클라이언트의 JS 실행 비용(TTI, Total Blocking Time)을 최소화한다.
- 컴포넌트 조합 패턴
use client지시어를 통해 상호작용이 필요한 영역만 클라이언트 컴포넌트로 선택적으로 정의한다.- 서버 컴포넌트를 기본으로 사용하되, 사용자 인터랙션이 필요한 지점에서만 클라이언트 경계를 설정하는 것이 권장된다.
- 이중 페칭(Double Fetching) 해결
- 브라우저에서 데이터를 요청하고 받는 대기 시간을 줄이기 위해 서버 내부에서 데이터를 직접 페칭하여 렌더링에 반영한다.
⚖️ Trade-offs & Caveats
- 환경 및 도구 제약: 현재 주로 Next.js App Router와 같은 특정 프레임워크 환경에서만 안정적으로 작동하며, 기존 Pages Router와는 호환되지 않는다.
- 상태 및 훅의 한계: 서버 컴포넌트 내에서는
useState,useEffect등의 클라이언트 전용 훅과 브라우저 API를 사용할 수 없다. - 구조적 복잡성: 서버와 클라이언트 컴포넌트 간의 경계 설계 및 데이터 직렬화(Serialization) 이슈를 관리해야 하는 설계적 부담이 존재한다.
🔗 Knowledge Connections
Related Concepts (Auto-Linked)
- Blocking
- CSS-in-JS
- Client Components
- Code Splitting
- Core_Web_Vitals
- Edge_Computing
- Hydration
- Next.js
- Next.js_App_Router
- Optimization
- React
- Research
- Server Components
Related Concepts
- Next.js App Router: RSC의 표준 구현체 (관계: 구동 환경)
- Hydration: RSC를 통해 비용을 절감하고자 하는 대상 과정 (관계: 최적화 목표)
- Client Components: 상호작용을 위한 RSC의 보완재 (관계: 상호 운용 관계)
Deeper Research Questions
- RSC와 기존 SSR(Server Side Rendering)은 데이터 전달 방식과 번들링 메커니즘에서 구체적으로 어떤 기술적 차이가 있는가?
- 서버와 클라이언트 경계에서 데이터를 Props로 넘길 때 발생하는 '직렬화 가능성' 제약 조건을 해결하기 위한 패턴은?
- RSC를 사용할 때 서버 부하를 제어하고 효율적으로 데이터를 캐싱하기 위한 'Request Memoization' 전략은?
- 서드파티 라이브러리(예: CSS-in-JS, UI Kits)가 서버 컴포넌트 환경을 지원하지 않을 때의 우회 방법론은?
- RSC 환경에서 보안 민감 정보(API Key 등)가 클라이언트로 유출되지 않도록 보장하는 'Server-only' 모듈 활용 방안은?
Practical Application Contexts
- 고성능 웹 서비스 구축: 대규모 이커머스나 뉴스 미디어 같이 초기 로딩 속도가 비즈니스 지표에 직결되는 사이트 개발.
- 번들 다이어트: 무거운 서드파티 라이브러리를 서버 측에서만 실행하여 클라이언트 자산 최소화.
Adjacent Topics
- Code Splitting & Streaming SSR
- Core Web Vitals Optimization
- Edge Computing & Serverless Functions