feat: batch wikification of Skybound balance pass and scalable frontend architectures

Processed 80+ files including Skybound playtest feedback, Monorepo strategies, and Modern Component Patterns.

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

@@ -1,17 +1,18 @@
 # [[React Server Components (RSC)]]
 
 ## 📌 Brief Summary
-React Server Components(RSC)는 브라우저가 아닌 서버에서 실행되며 HTML을 스트리밍하는 방식으로 동작하는 컴포넌트입니다 [1]. 서버 컴포넌트 내에는 React context가 존재하지 않기 때문에, 이에 의존하는 기존의 런타임 CSS-in-JS 라이브러리들과 근본적인 호환성 문제를 겪고 있습니다 [1, 2]. 이로 인해 RSC 환경에서는 런타임 오버헤드가 없는 Tailwind CSS나 CSS Modules, 또는 빌드 타임에 정적 CSS를 생성하는 방식이 주요 CSS 실전 설계 전략으로 부상하고 있습니다 [1, 3].
+React Server Components(RSC)는 브라우저가 아닌 서버에서 배타적으로 실행되며(빌드 타임 또는 요청 시) 클라이언트로 JavaScript를 전송하지 않고 HTML을 스트리밍하는 컴포넌트입니다 [1, 2]. 브라우저 API 및 React Context에 대한 접근이 불가능하기 때문에, 기존 런타임 CSS-in-JS 라이브러리의 호환성 문제를 발생시키며 프론트엔드 스타일링 및 컴포넌트 아키텍처에 근본적인 변화를 가져왔습니다 [1-4].
 
 ## 📖 Core Content
-- **실행 환경과 컨텍스트의 부재**: 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].
+- **서버 전용 실행 및 성능 최적화:** RSC는 서버에서 실행되므로 클라이언트로 JavaScript 번들을 보내지 않습니다 [2]. 데이터베이스 쿼리와 같은 비즈니스 로직을 브라우저에 노출하지 않고 직접 처리하여 보안을 유지하며, 클라이언트의 자원 부담을 최소화합니다 [2].
+- **스타일링 아키텍처에 미치는 영향:** RSC 환경에서는 React Context를 사용할 수 없기 때문에, `ThemeProvider`와 같이 Context에 의존하는 기존의 런타임 CSS-in-JS(예: styled-components, Emotion)는 서버 컴포넌트 환경에서 기본적으로 호환되지 않습니다 [1, 3-5]. 이로 인해 런타임 오버헤드가 없는 Tailwind CSS나 빌드 타임에 정적 CSS를 생성하는 vanilla-extract 같은 접근 방식이 현대 프론트엔드 아키텍처에서 선호되는 추세입니다 [1].
+- **styled-components의 RSC 지원 및 Style Registry:** 이러한 한계를 극복하기 위해 Next.js 15에서는 렌더링 중 CSS 규칙을 수집하여 주입하는 'Style Registry' 패턴을 도입했습니다 [6]. 또한 `styled-components`는 v6.3.0부터 RSC 환경을 자동 감지하여 `'use client'` 지시어 없이도 인라인 `<style>` 태그를 방출하도록 업데이트되었으며 [7], RSC에서 작동하지 않는 `ThemeProvider` 대신 CSS 커스텀 속성(CSS custom properties)을 활용하는 `createTheme` 헬퍼 함수를 통한 테마 적용을 권장합니다 [5, 7, 8].
+- **컴포넌트 합성(Composition) 및 설계 패턴:** 보편적인 설계 패턴은 서버 컴포넌트가 데이터를 패칭하고, 상호작용이 필요한 부분만을 `'use client'` 지시어가 선언된 클라이언트 컴포넌트(Client Component)로 분리하는 방식입니다 [9, 10]. 또한 서버 컴포넌트를 클라이언트 컴포넌트의 하위(`children`)나 `props`로 전달하여 서버 측 데이터 패칭 이점을 유지하는 합성 패턴이 효과적입니다 [11]. RSC에서 동적 스타일링이 필요한 경우, 직렬화(serialization) 오버헤드를 피하기 위해 동적 보간(interpolation)보다는 데이터 속성(data attributes, 예: `data-size='lg'`)과 정적 스타일을 사용하는 것이 모범 사례로 꼽힙니다 [7, 12].
 
 ## 🔗 Knowledge Connections
-- **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].
+- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[Client Components]]
+- **Projects/Contexts:** [[Next.js 15 App Router]], [[styled-components v6.3+]]
+- **Contradictions/Notes:** 런타임 CSS-in-JS 라이브러리는 기본적으로 RSC 환경(Context 부재)과 호환되지 않는다는 근본적인 한계가 제기되나 [3, 4], 최근의 `styled-components` 업데이트(v6.3.0 이상)에서는 인라인 스타일 주입 및 CSS 변수를 활용한 테마 적용 방식으로 이를 우회하여 RSC를 지원하고 있습니다 [7, 8].
 
 ---
 *Last updated: 2026-04-26*