Update: 2026-04-30 22:59
This commit is contained in:
Antigravity Agent
@@ -1,18 +1,40 @@
|
||||
# [[React Server Components]]
|
||||
|
||||
## 📌[[ brief]] Summary
|
||||
React [[Server Components]](RSC)는 브라우저가 아닌 서버에서만 독점적으로 렌더링되어 클라이언트로 [[JavaScript]] 번들을 전송하지 않는 React의 혁신적인 렌더링 아키텍처입니다 [1]. 이 환경에서는 [[React Context]]에 대한 접근이 불가능하기 때문에 기존의 런타임 기반 스타일링 도구와의 호환성 문제를 야기했으며, 프론트엔드의 스타일링 패러다임에 큰 변화를 가져왔습니다 [2, 3]. 결과적으로 확장 가능한 프론트엔드 아키텍처를 구축하려면 서버와 클라이언트 컴포넌트의 역할을 명확히 분리하고 RSC 환경에 최적화된 스타일링 전략을 채택하는 것이 필수적입니다 [4, 5].
|
||||
## 📌 Brief Summary
|
||||
React Server Components(RSC)는 서버에서만 실행되어 클라이언트로 전송되는 자바스크립트 번들 크기를 획기적으로 줄이는 성능 최적화 아키텍처다. 상호작용이 없는 정적 UI는 서버에서 완전히 렌더링하고 필요한 클라이언트 컴포넌트만 브라우저로 전송함으로써, 하이드레이션 비용을 절감하고 초기 로딩 속도를 극대화한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **RSC의 동작 원리와 컴포넌트 구성**: 서버 컴포넌트는 완전히 서버에서 실행되어 데이터베이스에 직접 접근할 수 있으며, 렌더링된 정적 HTML만을 클라이언트에 전달하므로 성능 최적화와 보안 유지에 탁월합니다 [1]. 반면, 컴포넌트에 상태([[State]])나 이벤트 핸들러 같은 브라우저 상호작용이 필요한 경우에 한해 `'use client'` 지시어를 명시하여 클라이언트 컴포넌트로 분리해야 합니다 [6]. 모범적인 아키텍처 구성을 위해서는 데이터 패칭을 서버 컴포넌트에서 처리하고 상호작용이 필요한 최소한의 영역만 클라이언트 컴포넌트로 유지해야 합니다 [5, 7].
|
||||
* **기존 [[CSS-in-JS]] 아키텍처와의 마찰**: RSC의 서버 전용 렌더링 환경은 기존 프론트엔드 생태계에 큰 영향을 미쳤습니다. 특히 `[[styled-components]]`나 `Emotion`과 같은 런타임 CSS-in-JS 라이브러리는 테마 주입을 위해 내부적으로 React Context에 크게 의존하는데, RSC 환경에는 React Context가 존재하지 않으므로 구조적인 비호환성(incompatibility)이 발생합니다 [2, 3, 8].
|
||||
* **현대적인 스타일링 및 렌더링 전략**: 위와 같은 호환성 문제로 인해 현재 [[Next.js App Router]]를 비롯한 RSC 환경에서는 런타임 오버헤드가 없는 빌드 타임 스타일링 방식이 강력히 권장됩니다 [2, 9]. 정적 CSS를 생성하는 `[[Tailwind CSS]]`, `[[CSS Modules]]` 또는 [[Zero-Runtime CSS-in-JS]]인 `[[vanilla-extract]]`를 도입하는 것이 성능을 향상시키고 복잡성을 줄이는 핵심 전략입니다 [3, 4, 9]. RSC 환경에서는 수많은 고유 클래스를 런타임에 동적으로 생성하기보다, 정적인 스타일을 유지하되 데이터 속성(`data-*` attributes)을 변경하여 상태 변형을 제어하는 방식이 성능 최적화에 유리합니다 [10].
|
||||
* **Styled-components의 RSC 지원 및 우회 방식**: 완전한 대안으로 전환하지 못하는 프로젝트를 위해 `styled-components`는 v6.3.0부터 RSC 환경을 자동 감지하는 패치를 적용했습니다 [11]. RSC 환경에서는 `ThemeProvider`가 아무 동작도 하지 않는 패스스루(no-op)로 변하기 때문에, 이를 대체할 수 있도록 CSS Custom Properties(변수) 기반의 테마를 생성하는 `createTheme` 헬퍼 함수를 사용할 것을 권장합니다 [12, 13]. 또한 SSR 시 스타일이 유실되지 않도록 서버에서 렌더링 중 CSS를 수집하여 삽입하는 `[[Style Registry]]` 패턴을 구성해야 하며, 인라인 스타일 태그 삽입으로 인해 깨질 수 있는 자식 인덱스 선택자 문제(`:first-child` 등)를 방지하기 위한 `stylisPluginRSC` 플러그인도 함께 제공됩니다 [14, 15].
|
||||
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 Topics:** [[Tailwind CSS]], [[Styled-components]], [[CSS-in-JS]], Zero-runtime CSS
|
||||
- **Projects/Contexts:** [[Next.js App Router]]
|
||||
- **Contradictions/Notes:** 소스 [2, 3, 8]에서는 `styled-components` 등 런타임 CSS-in-JS가 React Context 부재로 인해 RSC와 근본적으로 호환되지 않으므로 [[Next.js]] App Router 환경에서 피해야 한다고 설명합니다. 하지만 소스 [11-14]에 따르면, `styled-components`는 최신 업데이트를 통해 RSC 환경을 스스로 감지하고 Context 의존을 탈피하여 CSS Custom Properties를 사용하는 새로운 API 및 자동 스타일 인라인 주입 기능으로 RSC 환경에서의 사용을 계속해서 지원하고 있습니다.
|
||||
### Related Concepts
|
||||
- **Next.js App Router**: RSC의 표준 구현체 (관계: 구동 환경)
|
||||
- **Hydration**: RSC를 통해 비용을 절감하고자 하는 대상 과정 (관계: 최적화 목표)
|
||||
- **Client Components**: 상호작용을 위한 RSC의 보완재 (관계: 상호 운용 관계)
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
### 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**
|
||||
Reference in New Issue
Block a user