React Server Components (RSC)

📌 Brief Summary

[React Server Components|React Server Components]는 브라우저가 아닌 서버에서 배타적으로 실행되며(빌드 타임 또는 요청 시) 클라이언트로 JavaScript를 전송하지 않고 HTML을 스트리밍하는 컴포넌트입니다 [1, 2]. 브라우저 API 및 React Context에 대한 접근이 불가능하기 때문에, 기존 런타임 CSS-in-JS 라이브러리의 호환성 문제를 발생시키며 프론트엔드 스타일링 및 컴포넌트 아키텍처에 근본적인 변화를 가져왔습니다 [1-4].

[React Server Components|React Server Components]는 서버에서 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는 서버에서 실행되므로 클라이언트로 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].

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].

⚖️ Trade-offs & Caveats

No trade-offs available.

🔗 Knowledge Connections

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

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].