feat: massive wikification of styling systems and SaaS architecture

Processed 100+ files including Design Systems, CSS Architectures, and Enterprise Frontend strategies.

10_Wiki/Topics/Frontend_Mastery/React Server Components (RSC).md

@@ -1,25 +1,17 @@
 # [[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].
+React Server Components(RSC)는 브라우저가 아닌 서버에서 실행되며 HTML을 스트리밍하는 방식으로 동작하는 컴포넌트입니다 [1]. 서버 컴포넌트 내에는 React context가 존재하지 않기 때문에, 이에 의존하는 기존의 런타임 CSS-in-JS 라이브러리들과 근본적인 호환성 문제를 겪고 있습니다 [1, 2]. 이로 인해 RSC 환경에서는 런타임 오버헤드가 없는 Tailwind CSS나 CSS Modules, 또는 빌드 타임에 정적 CSS를 생성하는 방식이 주요 CSS 실전 설계 전략으로 부상하고 있습니다 [1, 3].
 
 ## 📖 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].
+- **실행 환경과 컨텍스트의 부재**: React Server Components는 브라우저 환경이 아닌 서버 환경에서 실행되어 HTML을 스트리밍합니다 [1]. 이러한 구조적 특성으로 인해 서버 컴포넌트에는 React context가 존재하지 않습니다 [1].
+- **런타임 CSS-in-JS 라이브러리와의 비호환성 문제**: 현대 프론트엔드 생태계에서 RSC와 관련된 주요 문제점은 `styled-components`나 `Emotion`과 같이 React context에 의존하는 런타임 CSS-in-JS 라이브러리들이 정상적으로 기능할 수 없다는 것입니다 [1, 2]. Next.js의 App Router 환경 등에서 RSC를 사용할 때 런타임 기반의 CSS-in-JS는 작동에 문제가 발생하거나 부분적인 호환성만 가집니다 [2, 4].
+- **유지보수 가능한 새로운 CSS 아키텍처로의 이동**: RSC의 등장은 유지보수성 및 호환성 측면에서 개발 팀들이 런타임 실행이 전혀 필요 없는 [[Tailwind CSS]]나 [[CSS Modules]]와 같은 구조 설계 방식을 채택하도록 만들었습니다 [1]. 더불어 기존 CSS-in-JS의 타입 안정성과 개발 경험을 유지하면서도 RSC와 호환되는 해결책으로, 빌드 타임에 정적 CSS를 생성하는 제로 런타임(Zero-runtime) CSS-in-JS(예: `vanilla-extract`) 방식이 중요한 전략으로 활용되고 있습니다 [1, 3].
 
 ## 🔗 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].
+- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[CSS Modules]]
+- **Projects/Contexts:** [[Next.js App Router]]
+- **Contradictions/Notes:** 소스는 런타임에 의존하는 기존 CSS-in-JS 라이브러리(styled-components 등)는 RSC와 구조적으로 호환되지 않는다고 지적하지만, 반대로 빌드 시점에 정적 CSS를 추출하는 제로 런타임 CSS-in-JS(vanilla-extract 등)는 RSC와 문제없이 호환된다고 명확히 구분하고 있습니다 [1-3].
 
 ---
-*Last updated: 2026-04-25*
+*Last updated: 2026-04-26*