# [[React Design Systems|React DesignSystems]]

## 📌 Brief Summary
React [[Design Systems|Design Systems]](리액트 디자인 시스템)은 재사용 가능한 UI 컴포넌트, 디자인 토큰(Design Tokens), 그리고 체계적인 스타일링 방법론을 결합하여 일관되고 확장 가능한 사용자 인터페이스를 구축하기 위한 프레임워크입니다 [1, 2]. 이 시스템은 아토믹 디자인(Atomic Design)이나 컴파운드 컴포넌트([[Compound Components|Compound Components]]) 같은 아키텍처 패턴을 통해 UI 로직과 비즈니스 로직을 분리합니다 [3-5]. 특히 현대의 React 환경에서는 성능 및 React Server Components(RSC)와의 호환성을 위해 런타임 오버헤드가 있는 [[CSS-in-JS|CSS-in-JS]] 방식(Styled Components)과 빌드 타임 최적화를 제공하는 유틸리티 퍼스트 방식([[Tailwind CSS|Tailwind CSS]]) 사이에서 기술적 균형을 맞추는 것이 핵심 과제입니다 [6-8].

## 📖 Core Content
*   **스타일링 패러다임: Styled Components vs. Tailwind CSS**
    *   **Styled Components (CSS-in-JS):** 컴포넌트의 상태(props)에 따른 동적 스타일링과 런타임 테마 적용에 매우 유용하며, 스타일이 컴포넌트 라이프사이클과 강력하게 결합됩니다 [9, 10]. 하지만 브라우저에서 [[JavaScript|JavaScript]]를 실행해 CSS를 생성하고 주입하기 때문에 CPU 실행 비용(런타임 오버헤드)이 발생하며, 이는 대규모 애플리케이션에서 렌더링 지연(FID, INP 저하)을 유발할 수 있습니다 [9, 11-13]. 또한 React Context에 의존하기 때문에 기본적으로 React Server Components(RSC) 환경과 호환되지 않는 문제가 있어, [[Next.js 15|Next.js 15]] 환경에서는 별도의 [[Style Registry|Style Registry]]를 구축하거나 v6.3.0부터 지원되는 RSC 전용 기능을 사용해야 합니다 [14-17].
    *   **Tailwind CSS:** 미리 정의된 유틸리티 클래스를 조합하여 UI를 구축하는 방식으로, JIT(Just-In-Time) 컴파일러를 통해 사용된 클래스만 빌드 타임에 정적 CSS로 생성합니다 [18, 19]. 이로 인해 런타임 오버헤드가 0에 수렴하며 번들 크기가 매우 작고 RSC와 완벽히 호환됩니다 [19-22]. 최신 Tailwind v4는 JavaScript 설정 파일 대신 `@theme` 디렉티브를 이용한 'CSS-first' 아키텍처를 도입하여 네이티브 CSS 변수 기반의 디자인 토큰 관리를 지원합니다 [23-26].
*   **디자인 토큰(Design Tokens)과 동적 테마(Theming)**
    *   디자인 토큰은 색상, 타이포그래피, 여백 등의 시각적 디자인 결정을 코드화된 데이터(JSON, YAML)로 중앙 집중화하는 개념입니다 [27, 28]. 확장 가능한 시스템을 위해 토큰은 원시 값인 **Base Tokens**(예: `#3366FF`), 사용 목적을 나타내는 **Semantic Tokens**(예: `color.primary`), 컴포넌트에 종속적인 **Component Tokens**(예: `button.background`)의 3계층으로 구성됩니다 [29-32].
    *   [[Style Dictionary|Style Dictionary]] 등의 도구를 사용하면 토큰을 CSS 변수(Custom Properties)로 자동 변환할 수 있습니다 [33-35]. 이를 통해 React 애플리케이션에서 컴포넌트 수정 없이 특정 CSS 클래스 변경만으로 다크 모드 등 동적 테마를 원활하게 전환할 수 있습니다 [36-38].
*   **재사용 가능한 컴포넌트 설계 아키텍처**
    *   **아토믹 디자인(Atomic Design):** UI를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages) 단계로 분해하여 조립하는 상향식 방법론으로, 컴포넌트의 일관성과 재사용성을 보장합니다 [3, 39, 40].
    *   **컴파운드 컴포넌트(Compound Components):** `Accordion.Header`, `Accordion.Body`처럼 여러 하위 컴포넌트가 React Context를 통해 암묵적으로 상태를 공유하는 패턴입니다 [4, 5, 41]. 이 패턴은 상위 컴포넌트에 수많은 props가 몰리는 현상(prop soup)을 방지하고 유연한 레이아웃 구성을 가능하게 합니다 [41-43].
    *   **[[Headless UI|Headless UI]]:** 컴포넌트의 상태 관리, 키보드 내비게이션, ARIA 속성(접근성) 등 비즈니스 및 상호작용 로직만 제공하고 시각적 스타일링은 완전히 개발자에게 위임하는 패턴입니다 [44-46]. Tailwind CSS와 결합하여 고도의 맞춤형 디자인 시스템을 구축할 때 널리 쓰입니다 [44].
    *   **오버라이드 패턴(Overrides API):** Uber의 Base Web 등에서 채택한 방식으로, 컴포넌트 내부의 깊은 DOM 요소까지 식별자를 통해 스타일이나 속성, 심지어 내부 컴포넌트 자체를 통째로 교체할 수 있게 허용하여 컴포넌트의 확장성을 극대화합니다 [47-49].
*   **확장 가능한 프론트엔드 구조와 [[Monorepo|Monorepo]]**
    *   조직 규모가 커질수록 pnpm workspaces, [[Turborepo|Turborepo]], Nx를 활용한 모노레포(Monorepo) 아키텍처가 필수적입니다 [50-52].
    *   FSD([[Feature-Sliced Design|Feature-Sliced Design]]) 방법론을 모노레포와 결합하여, `shared`(재사용 UI 및 토큰), `entities`(도메인 구조), `features`(비즈니스 로직) 등의 계층으로 나누고 각 패키지 간의 명시적인 공개 API(Public API)만을 통한 통신을 강제함으로써 의존성 엉킴과 스파게티 코드를 방지합니다 [53-56].

## 🔗 Knowledge Connections
- **Related Topics:** [[CSS-in-JS|CSS-in-JS]], Tailwind CSS, Design Tokens, [[Atomic Design|Atomic Design]], Compound Components, [[Headless UI|Headless UI]], React Server Components, [[Feature-Sliced Design|Feature-Sliced Design]]
- **Projects/Contexts:** [[Shopify Polaris|Shopify Polaris]], [[Uber Base Web|Uber Base Web]]
- **Contradictions/Notes:** 소스에 따르면 Styled Components 등 CSS-in-JS는 동적 스타일링과 런타임 테마 적용에 매우 강력하지만, CSS 생성에 따른 런타임 성능 오버헤드와 [[Next.js|Next.js]]의 React Server Components(RSC) 환경에서의 제약(직접적인 Context 사용 불가)이라는 단점이 존재합니다 [7-9, 14]. 반면 Tailwind CSS와 같은 유틸리티 퍼스트 접근법은 빌드 타임에 정적 CSS를 생성해 런타임 부하가 없으며 RSC와 완벽히 호환되므로 성능이 중요한 대규모 및 프로덕션 환경에서 더욱 유리하다고 대조하여 설명합니다 [18, 19, 21, 57].

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