Files
2nd/10_Wiki/Topics/Frontend_Mastery/React Server Components (RSC).md
T
Antigravity Agent df275f935b feat: batch wiki-fication of 00_Raw data
Applied double-save rule: Master Archive + Specialized Mapping for Skybound, Datacollector, and Frontend Mastery.
2026-04-25 22:52:01 +09:00

4.9 KiB

React Server Components (RSC)

📌 Brief Summary

React Server Components(RSC)는 컴포넌트가 오직 서버에서만 실행되고 클라이언트로 JavaScript 번들을 전혀 전송하지 않는 혁신적인 렌더링 아키텍처입니다 [1-3]. 기존의 SSR(Server-Side Rendering)과 달리 상호작용이 필요 없는 정적 컴포넌트의 Hydration(수화) 과정을 생략하며, 직렬화된 UI 표현만을 브라우저로 스트리밍합니다 [2, 4, 5]. 결과적으로 클라이언트의 JavaScript 처리 부하를 대폭 줄이고, 초기 로딩 속도와 상호작용 성능 지표인 INP(Interaction to Next Paint)를 향상시키는 렌더링 최적화의 핵심 기술입니다 [1, 2].

📖 Core Content

  • 아키텍처와 작동 원리 (Architecture & Mechanics) RSC는 브라우저가 아닌 서버 환경에서 완전히 실행되므로 데이터베이스, 로컬 파일 시스템, 비공개 환경 변수에 직접 접근할 수 있습니다 [6, 7]. 렌더링 결과물은 단순한 HTML뿐만 아니라, 클라이언트가 UI를 조립하는 데 사용하는 직렬화된 React 지시어(React Flight 프로토콜)와 함께 브라우저에 전달됩니다 [5]. 브라우저는 이 결과물을 받아 즉시 화면에 렌더링하며, 이 과정에서 해당 서버 컴포넌트의 JavaScript 코드는 0바이트로 클라이언트에 전송되지 않습니다 [1, 3, 6].
  • SSR과의 본질적 차이점 및 Hydration 제거 전통적인 SSR은 서버에서 HTML을 미리 생성해 초기 콘텐츠 표시 속도(FCP)를 높이지만, 브라우저가 페이지를 대화형으로 만들기 위해 여전히 전체 JavaScript 번들을 다운로드하고 'Hydration' 과정을 거쳐야만 합니다 [8, 9]. 반면 순수한 RSC는 브라우저에서 실행될 JS 코드가 애초에 존재하지 않으므로 Hydration 단계 자체가 생략되며 클라이언트 메인 스레드의 연산 부담을 극적으로 줄여줍니다 [2, 4, 7].
  • Client Components와의 하이브리드 아키텍처 상태(State) 관리나 이벤트 핸들러(onClick 등), 브라우저 API 접근이 필요한 대화형 요소는 파일 최상단에 "use client" 지시어를 선언하여 클라이언트 컴포넌트로 분리합니다 [6, 10, 11]. 서버 컴포넌트는 클라이언트 컴포넌트를 렌더링할 수 있지만, 클라이언트 컴포넌트는 서버 컴포넌트를 직접 임포트할 수 없다는 엄격한 단방향 의존성 규칙(서버 → 클라이언트)을 따릅니다 [12-14]. 이를 통해 무거운 비상호작용 UI는 서버에 남겨두고 상호작용에 필수적인 부분만 브라우저로 전송하여 번들 크기를 최적화할 수 있습니다 [6, 13].
  • 데이터 페칭(Data Fetching)의 최적화 RSC 환경에서는 컴포넌트 내부에서 별도의 API 중간 계층 없이 데이터베이스에 직접 비동기 요청(async/await)을 수행할 수 있습니다 [15, 16]. 또한 서버 환경의 이점을 살려 렌더링 중 데이터를 병렬로 가져옴으로써, 전통적인 클라이언트 렌더링(CSR)에서 발생하던 데이터 페칭 워터폴(Waterfall) 문제를 효과적으로 제거할 수 있습니다 [17, 18].
  • 제약 사항 및 구현 시 주의점 (Pitfalls) 서버 컴포넌트는 브라우저 API나 상태(State)를 가질 수 없으므로 대화형 인터랙션을 구현할 수 없습니다 [19]. 또한 렌더링 및 데이터 구조를 잘못 설계하여 서버 내에서 순차적으로 데이터를 페칭하게 되면, 기존 클라이언트의 워터폴 문제가 '서버 측 워터폴(Server-Side Waterfalls)'로 그대로 전이되어 응답 지연을 유발할 수 있습니다 [20, 21]. 구조적 문제를 우회하기 위해 "use client"를 무분별하게 남용하면 대규모 JS 번들이 다시 클라이언트로 전송되어 RSC 도입의 최적화 이점이 완전히 사라지게 됩니다 [22].

🔗 Knowledge Connections

  • Related Topics: Server-Side Rendering (SSR), Client-Side Rendering (CSR), Hydration, Component-Based Architecture (CBA), Interaction to Next Paint (INP)
  • Projects/Contexts: Next.js App Router, React 19, React Flight Protocol
  • Contradictions/Notes: 소스는 RSC가 단순히 "향상된 SSR"이 아니라고 명확히 선을 긋습니다. SSR은 여전히 클라이언트에 자바스크립트를 전송하고 하이드레이션을 수행해야 하지만, RSC는 특정 컴포넌트의 클라이언트 측 자바스크립트와 하이드레이션 자체를 완전히 제거한다는 점에서 본질적인 차이가 있습니다 [7, 9]. 또한 서버 컴포넌트를 도입한다고 자동으로 성능이 최적화되는 것은 아니며, 데이터 의존성을 직렬로 잘못 구성하면 서버 상에서 동일한 워터폴 현상(Server-Side Waterfalls)을 일으켜 병목을 초래할 수 있다고 경고합니다 [20, 21, 23].

Last updated: 2026-04-25