feat: batch wikification of Skybound balance pass and scalable frontend architectures

Processed 80+ files including Skybound playtest feedback, Monorepo strategies, and Modern Component Patterns.

10_Wiki/Topics/Frontend_Mastery/Design Systems.md

@@ -1,27 +1,23 @@
 # [[Design Systems]]
 
 ## 📌 Brief Summary
-디자인 시스템(Design System)은 명확한 표준에 따라 가이드되며 애플리케이션을 구축하기 위해 조립할 수 있는 재사용 가능한 컴포넌트들의 집합입니다 [1]. 이는 브랜드의 시각적 정체성을 프로그래밍 방식으로 구현한 것으로, 플랫폼 전반의 일관성을 보장하고 개발 워크플로우 속도를 높입니다 [2, 3]. 디자인 시스템의 가장 핵심적인 기초 블록은 색상, 간격, 타이포그래피 등의 시각적 디자인 속성을 저장하는 '디자인 토큰(Design Tokens)'입니다 [1, 3].
+디자인 시스템(Design Systems)은 색상, 간격 등의 시각적 디자인 정보를 담은 디자인 토큰(Design Tokens)과 규칙, 재사용 가능한 컴포넌트들의 집합입니다[1]. 이는 엔지니어, 디자이너, 프로덕트 매니저가 일관성 있고 접근성이 뛰어난 애플리케이션을 빠르고 효율적으로 구축할 수 있도록 돕는 공통 언어 역할을 합니다[2]. 디자인 시스템을 도입하면 스타일의 파편화를 막고, 다크 모드나 다중 브랜드 테마와 같은 글로벌 변경 사항을 런타임 또는 빌드 타임에 안전하고 동적으로 확장할 수 있습니다[3-5].
 
-## 📖 Core Content
-**디자인 시스템의 목적과 가치**
-*   **일관성 및 효율성 확보:** 디자인 시스템은 제품 및 플랫폼 전반에 걸친 디자인 일관성을 유지하고, 디자인 및 개발 워크플로우를 단축하며, 디자이너와 엔지니어 간의 공통 언어를 생성합니다 [2].
-*   **반응형 디자인의 내장:** 대규모 조직에서 발생하는 반응형 디자인(Responsive Design)의 불일치를 해결하기 위해, 디자인 시스템은 개별 페이지가 아닌 컴포넌트 자체에 반응형 동작을 속성으로 내장하여 재사용성을 극대화합니다 [4].
-
-**디자인 토큰 (Design Tokens)과 계층 구조**
-디자인 토큰은 디자인 시스템의 시각적 디자인 원자(atoms) 역할을 하며, 플랫폼에 구애받지 않고(platform-agnostic) 시각적 디자인 속성을 저장하는 이름이 부여된 개체(named entities)입니다 [1-3]. 토큰은 주로 3단계의 계층 구조로 체계화됩니다 [5-7]:
-*   **Global Tokens (Primitives):** 컨텍스트 없이 독립적으로 존재하는 원시 값으로 기본 팔레트 역할을 합니다 (예: `--blue-500: #3b82f6`) [5-7].
-*   **Alias Tokens (Semantic):** 특정 의도나 사용 사례를 나타내며 글로벌 토큰을 참조하여 토큰에 의미(context)를 부여합니다 (예: `--color-primary: var(--blue-500)`) [5-7].
-*   **Component Tokens:** 특정 UI 요소에 국한되어 글로벌 또는 별칭 토큰을 참조합니다. 이를 통해 다른 시스템에 영향을 주지 않고 개별 컴포넌트의 스타일을 세밀하게 조정할 수 있습니다 (예: `--button-bg-primary: var(--color-primary)`) [5, 7, 8].
-
-**구현 및 프론트엔드 아키텍처와의 결합**
-*   **단일 진실 공급원(Single Source of Truth) 자동화:** 다중 플랫폼(Web, iOS, Android)을 지원하는 대규모 프로젝트에서 디자인 토큰은 JSON 형식으로 저장되며, Style Dictionary 같은 도구를 통해 CSS 변수, iOS Swift, Android XML 등 플랫폼별 코드로 변환됩니다 [2, 9, 10]. 이는 수작업으로 인한 오류를 없애고 모든 제품 생태계에서 시각적 일관성을 보장합니다 [10].
-*   **CSS 방법론과의 시너지:** Tailwind CSS는 프로젝트 전체의 색상, 타이포그래피 스케일 등을 구성 파일(configuration file)로 정의하여 디자인 시스템을 엄격히 강제함으로써 "300가지 그림자" 같은 일관성 문제를 방지합니다 [11]. 또한, Panda CSS와 같은 최신 Zero-Runtime CSS-in-JS 라이브러리는 디자인 시스템과 테마를 기본적으로 지원하는 토큰 시스템을 내장하고 있습니다 [12]. 
+## 📖 일Core Content
+* **디자인 토큰(Design Tokens)의 계층적 구조**: 확장 가능한 UI 아키텍처의 핵심인 디자인 토큰은 JSON이나 YAML과 같은 기계 판독형 형식으로 저장되어 코드와 디자인 툴을 자동으로 동기화합니다[4, 6]. 유지보수성과 확장성을 높이기 위해 토큰은 3단계 계층 구조를 가집니다. 즉, 순수 값을 나타내는 기본 토큰(Primitive/Base Tokens), 사용 목적과 맥락을 부여한 시맨틱 토큰(Semantic Tokens), 개별 컴포넌트 변형에 쓰이는 컴포넌트 토큰(Component Tokens)으로 구성됩니다[7-12].
+* **리액트(React) 스타일링 패러다임 비교**: 
+  * **Styled-components**: 컴포넌트에 직접 스타일을 캡슐화하여 동적이고 props에 기반한 스타일링을 제공하는 CSS-in-JS 방식입니다[13, 14]. 하지만 브라우저에서 JavaScript를 실행하여 스타일을 주입하므로 런타임 오버헤드가 발생하며, React Context가 없는 React Server Components(RSC) 환경에서는 서버 렌더링에 취약하다는 단점이 있습니다[15-18]. 
+  * **Tailwind CSS**: 유틸리티 퍼스트(Utility-first) 접근법을 취하며, 정적 CSS를 빌드 타임에 생성하여 런타임 오버헤드가 전혀 없습니다[19, 20]. 특히 Tailwind v4는 `@theme` 지시어와 네이티브 CSS 변수를 사용하는 CSS 우선 아키텍처로 전환되어, 빌드 속도 및 초기 렌더링(Core Web Vitals) 성능 면에서 CSS-in-JS보다 대규모 확장에 매우 유리합니다[18, 21-23].
+* **재사용 가능한 컴포넌트 아키텍처 설계 패턴**:
+  * **아토믹 디자인(Atomic Design)**: UI를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages)의 5단계로 세분화하여, 예측 가능하고 조립 가능한 컴포넌트 라이브러리를 구축하는 기초 방법론입니다[24-28].
+  * **컴파운드 컴포넌트(Compound Components)**: 단일 컴포넌트에 너무 많은 속성(Prop)을 주입해 복잡해지는 문제를 해결하기 위해, 여러 하위 컴포넌트가 내부적으로 상태(Context)를 공유하도록 선언적으로 구성하는 패턴입니다(예: `Accordion.Root`, `Accordion.Item`)[29-32].
+  * **오버라이드 패턴(Overrides API) 및 헤드리스(Headless) 컴포넌트**: Uber의 Base Web 등에서 사용하는 오버라이드 패턴은 내부 요소의 기능이나 스타일을 사용자가 쉽게 교체할 수 있도록 합니다[33-36]. 헤드리스 컴포넌트는 스타일링을 제외한 상태 관리와 접근성 로직만을 제공하여 Tailwind 등과 결합 시 유연성을 극대화합니다[37].
+* **대규모 프론트엔드의 구조화(Monorepo 및 FSD)**: 시스템이 커질 경우, 단일 폴더에 공유 컴포넌트를 무분별하게 담지 않고 Monorepo 환경에서 Feature-Sliced Design (FSD) 아키텍처를 도입하는 것이 권장됩니다[38-41]. FSD는 코드를 Shared, Entities, Features, Widgets, Pages 등으로 명확히 분리하여 의존성의 방향을 통제하고 퍼블릭 API 캡슐화를 강제하여 시스템을 견고하게 유지합니다[39, 41].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** [[Design Tokens]], [[Tailwind CSS]], [[CSS Architecture]], [[Responsive Web Design]], [[BEM]]
-- **Projects/Contexts:** [[대규모 프론트엔드 프로젝트의 스타일 확장성 및 유지보수성 (Scalability and Maintainability in Large Frontend Projects)]]
-- **Contradictions/Notes:** 디자인과 개발 간의 완벽한 자동화를 목표로 하지만, Figma와 같은 디자인 앱 자체에는 디자인 토큰을 완벽하게 관리할 수 있는 내장 솔루션이 부족하여 플러그인(Figma Tokens 등)이나 Style Dictionary와 같은 서드파티 도구를 통한 추가적인 수동 구성과 워크플로우 통합이 필수적으로 요구된다는 한계가 지적됩니다 [13]. 
+- **Related Topics:** [[Design Tokens]], [[Atomic Design]], [[Compound Components]], [[Tailwind CSS]], [[Styled-components]], [[Feature-Sliced Design]]
+- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]]
+- **Contradictions/Notes:** 소스 [42]와 [43]는 Tailwind CSS를 사용할 때 여러 유틸리티 클래스로 인해 마크업이 매우 길어지고(Class Soup) 가독성이 떨어질 수 있다고 지적하지만, 소스 [44]와 [45]은 이를 방지하기 위해 유틸리티 클래스를 반복 작성하는 대신 "재사용 가능한 컴포넌트"로 추상화하거나 플러그인 기반 시스템을 구축해야 한다고 조언합니다. 또한 소스 [14], [18]은 Styled-components가 훌륭한 개발자 경험과 동적 스타일링을 제공한다고 설명하지만, 소스 [15], [16], [17]은 대규모 앱이나 RSC가 적용된 Next.js 환경에서는 런타임 성능 및 호환성 이슈를 야기할 수 있으므로 Tailwind나 CSS Modules를 권장하며 서로 다른 최적의 사용 사례를 제시합니다.
 
 ---
 *Last updated: 2026-04-26*