2nd/01_Archive/2026-05-03/Server Components (RSC).md

# [[Server Components (RSC)]]

## 📌 Brief Summary
서버 컴포넌트(React Server Components, RSC)는 React 컴포넌트가 오직 서버에서만 실행되도록 설계된 새로운 렌더링 패러다임이다 [1, 2]. 기존의 서버 사이드 렌더링(SSR)이 가진 하이드레이션(Hydration) 지연과 불필요한 자바스크립트 번들 비대화 문제를 해결하기 위해 도입되었다 [3, 4]. 데이터베이스 등 서버 리소스에 직접 접근하여 처리한 뒤, 직렬화된 UI 표현(RSC Payload)만을 클라이언트에 스트리밍 방식으로 전송함으로써 초기 로딩 속도와 성능을 대폭 향상시킨다 [5, 6].

## 📖 Core Content
- **작동 원리 및 직렬화 (Mechanism & Serialization):** 
  서버 컴포넌트는 서버에서 미리 실행되어 자바스크립트 번들에 코드가 포함되지 않는다 [1, 7]. 대신 JSON과 유사한 형태의 직렬화된 UI 설명인 'RSC 페이로드'를 생성하여 클라이언트로 스트리밍한다 [5]. 클라이언트의 React는 이 페이로드를 읽어 화면 전체를 새로 고치지 않고 기존 Fiber 트리에 병합하여 화면을 업데이트한다 [5, 8, 9]. 이를 통해 무거운 서드파티 라이브러리(예: 구문 강조 도구)를 클라이언트 번들에 추가하지 않고도 사용할 수 있는 강력한 성능 이점을 제공한다 [10, 11].

- **클라이언트 컴포넌트와의 경계 설정 (Boundary Definition):** 
  RSC 패러다임 내에서 모든 컴포넌트는 기본적으로 서버 컴포넌트로 간주된다 [12]. 상호작용(Event Handlers), 상태(State), 생명주기(Effect) 또는 브라우저 API가 필요한 경우에만 파일 최상단에 `'use client'` 지시어를 명시하여 클라이언트 컴포넌트로 전환한다 [1, 6, 13, 14]. 클라이언트 컴포넌트 내부에서 임포트된 모든 컴포넌트는 암시적으로 클라이언트 컴포넌트가 되는 제약이 있으나, 부모 서버 컴포넌트가 자식 서버 컴포넌트를 `children` 프로프(prop)로 전달하여 이 경계를 우회하는 합성 패턴을 실무에서 적극 활용한다 [15-17].

- **데이터 페칭 및 Suspense와의 통합:** 
  서버 컴포넌트는 비동기(async) 함수로 정의될 수 있어, 컴포넌트 내부에서 직접 데이터베이스 쿼리나 파일 시스템 읽기를 수행할 수 있다 [1, 18]. 이렇게 처리된 데이터는 React Suspense와 결합되어, 응답이 느린 쿼리를 기다리는 동안 빈 화면 대신 로딩 상태를 보여주고 데이터가 준비되는 대로 아웃오브오더(out-of-order) 방식으로 스트리밍한다 [19, 20].

- **서버 액션을 통한 데이터 뮤테이션 (Server Actions):** 
  서버의 데이터를 변경할 때는 `'use server'` 지시어를 사용하는 서버 액션을 활용한다 [21, 22]. 클라이언트 컴포넌트에서 호출된 서버 액션은 내부적으로 서버로 향하는 단일 왕복(Round trip) HTTP 요청으로 변환되어 실행된다 [23]. 이는 폼(Form) 처리 등에서 탁월한 효율을 제공한다 [24].

## ⚖️ Trade-offs & Caveats
- **상태 및 생명주기 사용의 한계:** 서버 컴포넌트는 렌더링된 이후 상태가 유지되지 않고 재렌더링되지 않으므로, `useState`, `useEffect` 등의 훅을 절대 사용할 수 없다 [13, 25].
- **직렬화 제약 조건:** 서버 컴포넌트에서 클라이언트 컴포넌트로 함수(Function)를 프로프로 전달할 수 없다. 오직 문자열, 숫자, 객체 등 직렬화가 가능한 순수 값만 경계를 넘을 수 있다 [26].
- **데이터 과다 노출로 인한 보안 위험:** 클라이언트 컴포넌트로 불필요하게 많은 데이터(예: 전체 데이터베이스 레코드)를 프로프로 전달하면, 브라우저의 네트워크 탭(RSC 페이로드)에 해당 데이터가 전부 노출되는 심각한 보안 취약점이 발생할 수 있다 [27].
- **서버 액션 보안 (RCE 취약점):** 서버 액션은 프론트엔드의 로컬 함수처럼 보이지만 실제로는 인터넷에 공개된 퍼블릭 HTTP 엔드포인트이다 [27]. 입력값에 대한 철저한 유효성 검사(Validation)를 하지 않으면, 조작된 요청을 통해 원격 코드 실행(RCE) 등 시스템을 장악당하는 취약점(예: React2Shell)이 발생할 위험이 높다 [28-30].
- **성능적 트레이드오프 및 복잡성:** 서버 액션은 직렬화되어 실행되므로 한 번에 하나의 액션만 실행(In flight)될 수 있다 [31]. 데이터를 업데이트한 후 `revalidateTag` 등을 호출하면 변경된 부분만 캐시가 비워지는 것이 아니라 해당 페이지의 전체 RSC 트리가 다시 렌더링되는 제약이 있다 [32, 33]. 또한 상호작용이 주를 이루는 애플리케이션(예: 그리기 도구 등)의 경우 억지로 RSC 구조를 도입하면 아키텍처적 복잡성만 커지고 실질적인 이점이 없을 수 있다 [34].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (아키텍처/기반 기술)]
- `[[Server Side Rendering (SSR)]]`
  - 연결 이유: RSC는 기존 SSR의 대체재가 아니라, 서로 완벽하게 결합하여 초기 렌더링 속도와 JS 번들 최적화를 이루는 상호 보완적인 렌더링 전략이다 [35].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 초기 페이지 로딩 시 서버에서 HTML의 '골격(Shell)'을 생성하여 보여주고, 클라이언트가 하이드레이션하는 전반적인 웹 렌더링 매커니즘을 이해할 수 있다 [36, 37].

- `[[React Suspense]]`
  - 연결 이유: RSC 페이로드를 생성하고 클라이언트로 전송할 때 데이터를 비동기 스트리밍(Streaming) 방식으로 처리할 수 있게 하는 핵심 UI 처리 기술이다 [20, 38].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 렌더링 차단 현상(Waterfalls)을 피하면서 데이터가 준비된 순서대로 점진적 UI 렌더링이 이루어지는 스트리밍 구조를 배울 수 있다 [19, 20].

#### [관계 유형 B (구현/활용 도구)]
- `[[Next.js App Router]]`
  - 연결 이유: RSC를 완전하게 지원하는 대표적인 프로덕션 프레임워크로, 디렉토리 구조 자체가 서버 컴포넌트 기반으로 작동하도록 설계되었다 [6, 39, 40].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 실제 실무 환경에서 라우팅 시스템이 RSC 페이로드를 어떻게 호출하고, Next.js의 캐싱 메커니즘과 서버 액션이 어떻게 연동되는지 확인할 수 있다 [23, 33, 39].

- `[[Client Components]]`
  - 연결 이유: 서버 컴포넌트 패러다임 속에서 사용자 상호작용과 브라우저 전용 기능을 담당하는 대척점이며, `'use client'`를 통해 의도적으로 분리된다 [6, 41, 42].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 서버와 클라이언트 컴포넌트 간의 임포트(Import) 경계, 직렬화 가능한 프로프(prop) 전달 원칙 등 효율적인 컴포넌트 트리 설계법을 배울 수 있다 [5, 15].

### Deeper Research Questions
- React 서버 컴포넌트(RSC) 페이로드의 직렬화 포맷은 정확히 어떻게 구성되며, 클라이언트의 Fiber 트리와 어떠한 과정을 거쳐 병합(Merge)되는가?
- 서버 액션(`'use server'`)을 안전하게 사용하기 위해, 실무에서는 어떤 라이브러리와 유효성 검사/인가(Authorization) 패턴을 구축하여 HTTP 엔드포인트로서의 취약점을 방어하는가?
- 부모가 클라이언트 컴포넌트일 때 자식인 서버 컴포넌트를 `children`으로 전달하여 렌더링 제약을 우회하는 '합성(Composition) 패턴'의 정확한 작동 원리는 무엇인가?
- Next.js 외에 Waku, Vite, RedwoodJS 등 다른 메타 프레임워크나 번들러에서 RSC를 구현할 때 겪는 기술적 한계와 아키텍처적 차이점은 무엇인가?
- 상태 관리가 중요한 복합적인 UI를 만들 때, `react-query`와 서버 컴포넌트를 혼용하면 두 번의 네트워크 왕복이 발생하는 현상은 어떻게 최적화할 수 있는가?

### Practical Application Contexts
- **Implementation:** React 기반 프로젝트 작성 시 습관적으로 `'use client'`를 붙이는 대신, 모든 컴포넌트를 기본 서버 컴포넌트로 취급하고 순수 UI 렌더링 로직을 서버에 배치하여 초기 로드되는 자바스크립트 크기를 최소화한다 [14, 43].
- **System Design:** 대규모 마크다운 파싱이나 무거운 코드 구문 강조(Syntax Highlighting) 라이브러리를 사용해야 할 경우, 클라이언트가 아닌 서버 컴포넌트 단에 배치하여 사용자 단말기의 성능 부담을 제거하는 시스템 구조를 설계한다 [10, 11].
- **Operation / Maintenance:** 서버 액션 함수를 작성할 때 외부로부터 직접 POST 요청이 들어올 수 있음을 전제로, 철저한 권한 부여 및 입력 데이터 살균(Sanitize) 검증 프로세스를 운영 표준에 포함시켜야 한다 [27, 29].
- **Learning Path:** 클라이언트 사이드 렌더링(CSR)과 하이드레이션 지연 문제에 대한 기초를 이해한 뒤, React 19의 RSC 모델과 Suspense, 메타 프레임워크(Next.js) 구조로 학습을 확장하여 프론트엔드 최적화 역량을 키운다 [3, 35, 44].
- **My Project Relevance:** 프레임워크별 실전 아키텍처 전략에 맞춰, 데이터 종속성이 깊고 초기 렌더링이 중요한 화면 요소는 서버 컴포넌트로 격리하고, 상호작용이 잦은 부분은 클라이언트 컴포넌트로 분리하는 아키텍처 설계 지침 수립에 직접 활용할 수 있다.

### Adjacent Topics
- `[[Hydration & Progressive Rendering]]`
  - 확장 방향: 서버 컴포넌트가 만들어낸 초기 마크업이 브라우저에서 상호작용을 갖추게 되는 '하이드레이션' 과정과, 이를 점진적으로 처리하여 체감 성능을 향상하는 기법으로 깊이 확장하여 조사.

---
*Last updated: 2026-05-03*