## 📌 Brief Summary
React Server Components(RSC)는 서버에서만 실행되어 클라이언트로 전송되는 자바스크립트 번들 크기를 획기적으로 줄이는 성능 최적화 아키텍처다. 상호작용이 없는 정적 UI는 서버에서 완전히 렌더링하고 필요한 클라이언트 컴포넌트만 브라우저로 전송함으로써, 하이드레이션 비용을 절감하고 초기 로딩 속도를 극대화한다.

## 📖 Core Content
1. **서버 사이드 전용 렌더링**
   - 서버 컴포넌트는 클라이언트 번들에 포함되지 않아 번들 사이즈가 줄어들고 데이터베이스/API에 직접 접근이 가능하다.
2. **번들 및 하이드레이션 최적화**
   - 정적 UI를 서버에서 미리 렌더링하여 클라이언트의 JS 실행 비용(TTI, Total Blocking Time)을 최소화한다.
3. **컴포넌트 조합 패턴**
   - `use client` 지시어를 통해 상호작용이 필요한 영역만 클라이언트 컴포넌트로 선택적으로 정의한다.
   - 서버 컴포넌트를 기본으로 사용하되, 사용자 인터랙션이 필요한 지점에서만 클라이언트 경계를 설정하는 것이 권장된다.
4. **이중 페칭(Double Fetching) 해결**
   - 브라우저에서 데이터를 요청하고 받는 대기 시간을 줄이기 위해 서버 내부에서 데이터를 직접 페칭하여 렌더링에 반영한다.

## ⚖️ Trade-offs & Caveats
- **환경 및 도구 제약**: 현재 주로 Next.js App Router와 같은 특정 프레임워크 환경에서만 안정적으로 작동하며, 기존 Pages Router와는 호환되지 않는다.
- **상태 및 훅의 한계**: 서버 컴포넌트 내에서는 `useState`, `useEffect` 등의 클라이언트 전용 훅과 브라우저 API를 사용할 수 없다.
- **구조적 복잡성**: 서버와 클라이언트 컴포넌트 간의 경계 설계 및 데이터 직렬화(Serialization) 이슈를 관리해야 하는 설계적 부담이 존재한다.

## 🔗 Knowledge Connections
### Related Concepts
- **Next.js App Router**: RSC의 표준 구현체 (관계: 구동 환경)
- **Hydration**: RSC를 통해 비용을 절감하고자 하는 대상 과정 (관계: 최적화 목표)
- **Client Components**: 상호작용을 위한 RSC의 보완재 (관계: 상호 운용 관계)

### Deeper Research Questions
1. RSC와 기존 SSR(Server Side Rendering)은 데이터 전달 방식과 번들링 메커니즘에서 구체적으로 어떤 기술적 차이가 있는가?
2. 서버와 클라이언트 경계에서 데이터를 Props로 넘길 때 발생하는 '직렬화 가능성' 제약 조건을 해결하기 위한 패턴은?
3. RSC를 사용할 때 서버 부하를 제어하고 효율적으로 데이터를 캐싱하기 위한 'Request Memoization' 전략은?
4. 서드파티 라이브러리(예: CSS-in-JS, UI Kits)가 서버 컴포넌트 환경을 지원하지 않을 때의 우회 방법론은?
5. RSC 환경에서 보안 민감 정보(API Key 등)가 클라이언트로 유출되지 않도록 보장하는 'Server-only' 모듈 활용 방안은?

### Practical Application Contexts
- **고성능 웹 서비스 구축**: 대규모 이커머스나 뉴스 미디어 같이 초기 로딩 속도가 비즈니스 지표에 직결되는 사이트 개발.
- **번들 다이어트**: 무거운 서드파티 라이브러리를 서버 측에서만 실행하여 클라이언트 자산 최소화.

### Adjacent Topics
- **Code Splitting & Streaming SSR**
- **Core Web Vitals Optimization**
- **Edge Computing & Serverless Functions**