# [[React [[Server Components]](RSC) 환경의 스타일링 최적화]]

## 📌[[ brief]] Summary
[[React Server Components]](RSC)는 서버에서 HTML을 스트리밍하는 방식으로 동작하므로, 브라우저의 [[React Context]]에 의존하는 기존의 런타임 기반 [[CSS-in-JS]](예: [[styled-components]], Emotion) 라이브러리와는 근본적으로 호환되지 않습니다 [1, 2]. 따라서 RSC 환경(예: [[Next.js App Router]])에서는 런타임 오버헤드가 전혀 없는 [[Tailwind CSS]], [[CSS Modules]]를 사용하거나, 빌드 타임에 정적 CSS를 생성하는 [[Zero-Runtime CSS-in-JS]](예: [[vanilla-extract]])를 선택하는 것이 필수적입니다 [2-4].

## 📖 Core Content
* **RSC와 기존 런타임 CSS-in-JS의 비호환성 문제**
  * RSC는 브라우저가 아닌 서버에서 실행되므로, React Context를 사용하여 런타임에 동적으로 CSS를 생성하는 styled-components나 Emotion 같은 라이브러리는 제대로 기능할 수 없습니다 [2].
  * 이러한 기존 CSS-in-JS 방식은 RSC 환경에서 부분적인 호환성만 지원하거나 서버 사이드 렌더링(SSR) 설정이 매우 복잡해지며 런타임 성능 저하([[JavaScript]] 번들 증가, 렌더링 비용)를 유발하는 치명적인 단점이 있습니다 [1, 3, 5].

* **RSC 환경을 위한 최적의 스타일링 대안**
  이러한 RSC와의 호환성 문제로 인해, 실무에서는 런타임 비용이 없는 다음과 같은 스타일링 방식들로 전환하고 있습니다 [2].
  * **Tailwind CSS**: 런타임 실행 비용이 전혀 없으며 RSC와 완벽하게 호환됩니다 [2, 3].
  * **CSS Modules**: 런타임 오버헤드 없이 빌드 타임에 정적 CSS로 변환되어 고유한 클래스명을 제공하므로 RSC 환경에 이상적입니다 [2, 3, 6].
  * **Zero-runtime CSS-in-JS (예: vanilla-extract)**: TypeScript를 활용한 타입 안전성과 CSS-in-JS의 개발 경험을 유지하면서도, 빌드 시점에 정적 CSS를 생성하여 런타임 오버헤드를 없애고 RSC와 완벽히 호환됩니다 [2, 3].

* **2025년 기준 실무 적용 전략**
  * [[Next.js]] App Router 기반의 새로운 프로젝트를 시작할 때는 런타임 CSS-in-JS의 사용을 피하고 Tailwind CSS나 CSS Modules를 채택하는 것이 강력히 권장됩니다 [4].
  * 중소규모의 애플리케이션에서는 Tailwind CSS가 유리하며, 복잡한 애니메이션이나 상세한 CSS 제어가 필요한 프로젝트에는 CSS Modules가 권장됩니다 [4].
  * 여러 테마를 다루어야 하는 대규모 디자인 시스템을 구축할 경우 Zero-runtime 기반의 vanilla-extract를 도입하는 것이 최적의 선택입니다 [4].

## 🔗 Knowledge Connections
- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[CSS Modules]]
- **Projects/Contexts:** [[Next.js App Router]], [[디자인 시스템]]
- **Contradictions/Notes:** styled-components 등 기존 런타임 CSS-in-JS는 props 기반의 동적 스타일링과 컴포넌트 캡슐화에 큰 강점이 있어 널리 쓰여왔으나 [7, 8], RSC 기술이 주류로 자리 잡으면서 그 근본적인 Context 의존성 및 성능 오버헤드 문제로 인해 2024~2025년 기준으로는 사용이 지양되고 빌드 타임 추출 방식이 선호되는 추세입니다 [1, 2, 4].

---
*Last updated: 2026-04-26*