2nd/10_Wiki/Topics/Design System Architecture.md

Design System Architecture

📌 Brief Summary

디자인 시스템 아키텍처는 재사용 가능한 UI 컴포넌트, 디자인 토큰(색상, 타이포그래피, 간격 등), 그리고 이들을 조합하는 규칙들의 집합으로, 일관되고 접근성 높은 애플리케이션을 신속하게 구축할 수 있게 해주는 프레임워크입니다 [1, 2]. 이는 엔지니어, 디자이너, 제품 관리자 간의 공통 언어로 기능하며 팀의 생산성을 높입니다 [3, 4]. 현대 프론트엔드 환경에서는 런타임 성능 최적화, 다계층 디자인 토큰 시스템, 그리고 모듈화된 컴포넌트 아키텍처의 융합을 통해 확장 가능하고 유지보수가 쉬운 대규모 UI 시스템을 구현하는 것이 핵심입니다 [5].

📖 Core Content

• 디자인 토큰 시스템 (Design Token Systems) 디자인 시스템의 근간을 이루는 디자인 토큰은 확장성과 일관성을 위해 3단계 계층 구조로 관리됩니다 [2, 6].

  • 원시/기본 토큰 (Primitive/Base Tokens): 헥스 코드나 픽셀 단위와 같은 시스템의 근본적인 원시 값입니다 (예: color.blue.500) [7-9].
  • 시맨틱 토큰 (Semantic Tokens): 목적과 의도를 나타내며 기본 토큰을 참조합니다. 런타임 환경에서 다크 모드 등 테마 스위칭을 안전하게 지원하는 핵심 역할을 합니다 (예: color.primary) [7-9].
  • 컴포넌트 토큰 (Component Tokens): 특정 UI 컴포넌트나 변형에 종속되는 토큰으로, 시맨틱 토큰을 참조하여 복잡한 UI 상태를 관리합니다 [7, 9].

• 컴포넌트 라이브러리 아키텍처 패턴 (Component Architecture Patterns)

  • 아토믹 디자인 (Atomic Design): UI를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages) 단위로 분해하여 재사용성을 극대화하는 멘탈 모델입니다 [10, 11].
  • 복합 컴포넌트 (Compound Components): 탭(Tabs)이나 아코디언(Accordion) 등에서 컴포넌트 간 Context를 통해 상태를 암시적으로 공유하여, 과도한 Prop Drilling(Prop Soup)을 방지하고 유연한 레이아웃을 제공합니다 [12-14].
  • 헤드리스 UI (Headless Components): 상태 관리, 접근성(A11y) 등 비즈니스 로직만 제공하고 렌더링 형태(UI)는 개발자에게 맡기는 방식으로, Tailwind CSS와 결합하여 고도로 커스터마이징 가능한 시스템을 구축할 때 적합합니다 [15].
  • 오버라이드 패턴 (Overrides Pattern): Uber의 Base Web 등에서 사용되며, 컴포넌트를 구성하는 세부 하위 요소에 새로운 속성이나 스타일을 주입하거나 컴포넌트 전체를 교체할 수 있는 구조를 제공합니다 [16-18].

• 스타일링 패러다임 비교 (styled-components vs Tailwind CSS)

  • Styled-Components (CSS-in-JS): 컴포넌트 단위의 강한 응집력과 동적 스타일링을 제공하지만, JavaScript 실행에 따른 런타임 오버헤드가 발생합니다 [19, 20]. 특히 React Server Components (RSC 환경에서는 Context 접근이 불가하므로 Style Registry 등 부가적인 설정이 필요하며 하이드레이션 불일치 위험이 따릅니다 [21-23].
  • Tailwind CSS: 유틸리티 퍼스트 접근법으로, 최신 v4 버전에서는 @theme 디렉티브 기반의 CSS-first 아키텍처를 도입해 디자인 토큰을 기본 CSS 변수로 직접 노출합니다 [24-26]. 런타임 오버헤드가 0에 수렴하는 정적 CSS를 생성하여 TTI(Time to Interactive), INP(Interaction to Next Paint) 등 Core Web Vitals 성능 개선에 압도적으로 유리합니다 [20, 27-29].

• 대규모 프론트엔드 시스템 확장 및 거버넌스 (Scalability & Governance)

  • Monorepo & FSD: Turborepo나 Nx 같은 모노레포 환경과 결합하여 Feature-Sliced Design (FSD) 계층 구조를 채택하면, 제네릭 컴포넌트(Shared)와 비즈니스 피처(Features) 간의 의존성을 한 방향으로 엄격하게 통제할 수 있습니다 [30-32].
  • 자동화 및 관측성 (Observability): Uber의 uSpec처럼 AI를 활용해 Figma에서 컴포넌트 스펙을 추출해 다중 플랫폼 문서를 자동화하거나, 앱 내 Base 컴포넌트 채택률을 결정론적 방식(Deterministic Counter)으로 측정하여 스타일 편차(Style drift)를 방지하는 모니터링 시스템을 구축하는 것이 엔터프라이즈급 관리의 핵심입니다 [33-38].

🔗 Knowledge Connections

• Related Topics: Design Tokens, Atomic Design, Compound Components, Tailwind CSS, Styled-Components, Feature-Sliced Design (FSD)
• Projects/Contexts: React Server Components (RSC), Uber Base Web, Shopify Polaris
• Contradictions/Notes: 컴포넌트의 스타일링 방식에 있어, Styled-Components와 같은 CSS-in-JS는 뛰어난 컴포넌트 개발 경험(DX)과 동적인 테마 적용의 이점을 제공한다고 주장되지만, 대규모 서비스 성능 관점에서는 런타임 처리 비용과 [React Server Components|React Server Components] 환경에서의 제약 때문에 Tailwind CSS와 같은 빌드 타임(Static) 유틸리티 모델이 더 우수하다는 강력한 성능적 반론이 존재합니다 [19-21, 29, 39, 40].

---

Last updated: 2026-04-26