# [[Scalable Design Systems|Scalable DesignSystems]]

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

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

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

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

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

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

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

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