2nd/10_Wiki/Topics/Frontend_Mastery/Scalable Design Systems.md

# [[Scalable Design[[ system]]s]]

## 📌[[ brief]] Summary
확장 가능한 디자인 시스템(Scalable Design System)은 시각적 일관성, 유연성 및 유지보수성을 보장하기 위해 재사용 가능한 UI 컴포넌트, 디자인 토큰 및 가이드라인을 체계화한 프레임워크입니다 [1, 2]. 디자인 토큰과 컴포넌트 기반 아키텍처를 통해 디자인의 의도(intent)와 코드의 구현(impact)을 분리함으로써, 대대적인 리팩토링 없이도 새로운 테마, 브랜드 또는 플랫폼에 쉽게 적응할 수 있도록 합니다 [3, 4]. 현대 프론트엔드 엔지니어링에서는 개발자 경험(DX)과 런타임 성능 간의 균형을 맞추기 위해 필수적인 요소로 자리 잡고 있습니다 [5].

## 📖 Core Content
*   **디자인 토큰([[Design Tokens]])과 테밍(Theming):**
    디자인 토큰은 색상, 타이포그래피, 여백 등의 시각적 디자인 정보를 하드코딩된 값이 아닌 JSON이나 YAML 같은 기계 판독 가능 형식의 데이터로 저장하여 '단일 진실 공급원([[Single Source of Truth]])' 역할을 합니다 [1, 6]. 확장 가능한 시스템은 토큰을 Base/Primitive(원시 값), Semantic(목적 지향적), Component(특정 변형)의 세 가지 계층으로 구성하여 토큰의 무분별한 확장을 막고 안전한 리팩토링을 보장합니다 [7-9]. 이러한 계층 구조를 통해 CSS 변수나 [[Style Dictionary]] 같은 도구를 활용한 동적 테밍(라이트/다크 모드 등)이 가능해집니다 [10, 11].

*   **확장 가능한 컴포넌트 아키텍처 패턴:**
    *   **아토믹 디자인([[Atomic Design]]):** UI 요소를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿, 페이지 단위로 계층화하여 개발자가 개별 요소와 전체 UI를 동시에 파악하고 일관되게 재사용할 수 있도록 돕습니다 [12-14].
    *   **합성 컴포넌트([[Compound Components]]):** 탭(Tabs)이나 아코디언(Accordion) 같은 복잡한 UI에서, [[React Context]]를 통해 암시적으로 상태를 공유하는 여러 하위 컴포넌트로 책임을 분산시킵니다. 이는 불필요한 Props 전달([[Prop Drilling]])과 비대한 Props(Prop soup)를 방지하고 높은 유연성을 제공합니다 [15-18].
    *   **오버라이드 패턴([[Overrides Pattern]]):** Uber의 Base Web 등에서 사용되는 패턴으로, 최상위 Props를 과도하게 늘리지 않고도 컴포넌트 내부의 특정 요소에 식별자를 부여해 추가 스타일이나 속성을 주입하거나 하위 컴포넌트 자체를 교체할 수 있게 합니다 [19-21].

*   **스타일링 패러다임 비교 ([[Tailwind CSS]] vs [[styled-components]]):**
    *   **Tailwind CSS:** 유틸리티 우선(Utility-first) 접근 방식으로 빌드 타임에 정적 CSS를 생성합니다. 특히 v4에서는 `@theme` 지시어와 네이티브 CSS 변수를 활용하는 'CSS-first' 아키텍처를 채택했습니다. 런타임 오버헤드가 없고, 번들 크기가 작으며, [[React Server Components]](RSC) 환경과 높은 호환성을 가져 성능 최적화에 유리합니다 [22-25].
    *   **Styled-Components ([[CSS-in-JS]]):** Props 기반의 동적 스타일링과 컴포넌트 단위의 캡슐화를 통해 뛰어난 개발자 경험을 제공합니다. 하지만 브라우저에서 [[JavaScript]]를 실행해 스타일 태그를 주입해야 하므로 CPU 런타임 오버헤드가 발생하며, React Context에 의존하기 때문에 [[Next.js App Router]]의 RSC 환경에서는 본질적으로 비호환성 문제를 가집니다([[Style Registry]] 등을 통한 우회 필요) [24, 26-29].

*   **프론트엔드 모노레포와 아키텍처 구성:**
    시스템이 커질수록 다수의 앱과 공유 라이브러리를 관리하기 위해 [[Turborepo]], Nx 등의 모노레포([[Monorepo]]) 아키텍처가 사용됩니다 [30, 31]. 이와 함께 기능 분할 설계([[Feature-Sliced Design]], FSD) 방법론을 적용해 코드를 Shared, Entities, Features, Widgets, Pages, App 계층으로 나누어 엄격한 의존성 경계를 설정하고 스파게티 코드를 방지합니다 [32, 33].

*   **자동화와 시스템 관측성(Observability):**
    대규모 엔터프라이즈 환경에서는 디자인 시스템의 유지보수를 위해 자동화가 필수적입니다. Uber는 [[Figma]] Console MCP와 AI 에이전트를 결합해 몇 분 만에 멀티 플랫폼용 컴포넌트 스펙 문서를 자동 생성합니다 [34-36]. 또한 'Design System Observability' 시스템을 통해 뷰 트리를 탐색하여 수천 개의 화면에서 표준 컴포넌트의 실제 채택률을 정량적으로 측정하고 코드 품질을 제어합니다 [37-39].

## 🔗 Knowledge Connections
- **Related Topics:** [[Design Tokens]], [[Atomic Design]], [[Compound Components]], [[React [[Server Components]] (RSC)]], [[Tailwind CSS]], [[Styled-Components]], [[Feature-Sliced Design (FSD)]]
- **Projects/Contexts:** [[Next.js App Router]], [[Uber Base Web]], [[Shopify Polaris]]
- **Contradictions/Notes:** 소스 [40, 41]는 Tailwind CSS가 JSX 마크업을 장황하게(Verbose) 만들고 컴포넌트 수준의 캡슐화가 부족하다고 지적하지만, 소스 [25, 42, 43]는 [[Headless UI]] 컴포넌트, CVA(Class Variance Authority), 그리고 Tailwind v4의 `@theme` 지시어를 결합하면 이러한 단점을 극복하고 재사용 가능한 컴포넌트를 효과적으로 추상화할 수 있다고 주장합니다. 또한, CSS-in-JS(Styled-Components)는 동적 스타일링의 편리함을 제공하지만 대규모 트래픽이나 성능([[Core Web Vitals]])이 중요한 프로젝트 및 최신 RSC 기반 애플리케이션에서는 제로 런타임인 Tailwind나 [[CSS Modules]]의 사용이 적극 권장됩니다 [44-46].

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