Update: Wikified 129 files from Datacollector_MAC/out_wiki (P-Reinforce v3.0)
This commit is contained in:
@@ -1,3 +1,46 @@
|
||||
---
|
||||
category: Frontend
|
||||
tags: [auto-wikified, technical-documentation, merged, frontend]
|
||||
title: React Server Components
|
||||
description: "React Server Components(RSC)는 서버에서만 독점적으로 실행되고 클라이언트의 자바스크립트 번들에서 완전히 제외되는 새로운 유형의 컴포넌트 패러다임이다 [1-3]."
|
||||
last_updated: 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는 서버에서 완전히 렌더링하고 필요한 클라이언트 컴포넌트만 브라우저로 전송함으로써, 하이드레이션 비용을 절감하고 초기 로딩 속도를 극대화한다.
|
||||
|
||||
@@ -52,4 +95,4 @@ React Server Components(RSC)는 서버에서만 실행되어 클라이언트로
|
||||
### Adjacent Topics
|
||||
- **Code Splitting & Streaming SSR**
|
||||
- **Core Web Vitals Optimization**
|
||||
- **Edge Computing & Serverless Functions**
|
||||
- **Edge Computing & Serverless Functions**
|
||||
|
||||
Reference in New Issue
Block a user