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_Art/UI_UX_Assets/Atomic Design.md

@@ -0,0 +1,30 @@
+# [[Atomic Design]]
+
+## 📌 Brief Summary
+Atomic Design(아토믹 디자인)은 브래드 프로스트(Brad Frost)가 고안한 디자인 방법론으로, 사용자 인터페이스(UI)를 응집력 있는 전체이자 부분의 집합으로 동시에 생각할 수 있게 해주는 멘탈 모델입니다 [1-3]. 이 방법론은 인터페이스를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages)라는 5개의 계층적 단계로 나누어 효과적이고 의도적인 디자인 시스템을 구축하도록 돕습니다 [4, 5]. React와 같은 모던 컴포넌트 아키텍처와 결합하여 일관성을 강제하고, 디자인 시스템의 재사용성을 높이며, 확장 가능한 폴더 구조를 구축하는 데 널리 활용됩니다 [6-8].
+
+## 📖 Core Content
+*   **5단계의 컴포넌트 계층 구조**:
+    *   **원자 (Atoms)**: 더 이상 쪼갤 수 없는 UI의 기본 구성 요소입니다 [1, 5]. HTML 태그(예: input, label, button)나 React의 기본 함수형 컴포넌트에 해당하며, 각기 고유한 속성을 가집니다 [9, 10].
+    *   **분자 (Molecules)**: 원자들의 결합으로 이루어진 비교적 단순한 UI 컴포넌트 그룹입니다(예: 라벨 + 입력창 + 버튼 = 검색 폼) [5, 10, 11]. 단일 책임 원칙(Single Responsibility Principle)을 장려하여 "한 가지 일을 잘 수행하도록" 함으로써 테스트와 재사용성을 용이하게 합니다 [12].
+    *   **유기체 (Organisms)**: 분자, 원자, 혹은 다른 유기체들로 구성된 복잡한 컴포넌트로, 인터페이스의 뚜렷한 독립적 섹션을 형성합니다(예: 웹사이트 헤더, 제품 그리드) [5, 10, 13, 14].
+    *   **템플릿 (Templates)**: 컴포넌트들을 레이아웃에 배치하고 디자인의 근본적인 콘텐츠 구조(뼈대)를 명확히 하는 페이지 레벨의 객체입니다 [5, 10, 15, 16]. 최종 콘텐츠보다는 기본 골격에 집중합니다 [16].
+    *   **페이지 (Pages)**: 템플릿에 실제 대표 콘텐츠를 주입한 구체적 인스턴스입니다. 최종 UI를 보여주고 기초 디자인 시스템의 효과와 복원력을 테스트하며 콘텐츠의 동적 변형(예: 데이터 길이에 따른 변화)을 명확히 합니다 [5, 10, 17-19].
+
+*   **Atomic Design의 핵심 이점 및 특징**:
+    *   **맥락의 전환**: 추상적인 요소(원자)를 조작하는 동시에 그것들이 모여 구체적인 최종 결과물(페이지)에 미치는 영향을 빠르게 파악하고 테스트할 수 있도록 돕습니다 [20, 21].
+    *   **구조와 콘텐츠의 분리**: UI의 콘텐츠 구조 스켈레톤(템플릿)과 최종 콘텐츠(페이지) 사이의 깔끔한 분리를 제공하면서도 둘의 상호작용을 고려하게 합니다 [22, 23].
+    *   **보편적 적용성**: 웹 전용 기술(CSS, JavaScript 구조 등)에 국한되지 않으며, Instagram과 같은 네이티브 모바일 앱을 포함한 모든 소프트웨어 인터페이스 설계에 적용할 수 있습니다 [24-26].
+    *   **비선형적 접근**: 단순히 1단계에서 5단계로 순차적으로 진행하는 선형 프로세스가 아니라, 전체와 부분을 동시에 설계하기 위한 멘탈 모델로 접근해야 합니다 [1, 2].
+
+*   **React 확장성 및 아키텍처에서의 활용**:
+    *   React의 컴포넌트 트리와 완벽하게 대칭을 이루어 디자인 시스템을 구축하는 근본적인 모델이 됩니다 [6].
+    *   성공적인 엔터프라이즈 팀들은 원자 단위의 순수함과 재사용성을 유지하기 위해 UI 라이브러리 계층에는 Atomic Design을 활용하고, 비즈니스 로직이 들어가는 애플리케이션 코드에는 기능 분할 설계(Feature-Sliced Design, FSD) 등 기능 기반 구조를 혼합하여 설계합니다 [10, 27].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Component-Based Design]], [[Feature-Sliced Design (FSD)]], [[Compound Components]], [[Design Systems]]
+- **Projects/Contexts:** [[React Frontend Architecture]], [[Reusable UI Component Libraries]]
+- **Contradictions/Notes:** 소스에 따르면 Atomic Design은 시각적 일관성과 재사용성을 달성하는 데는 매우 강력하지만, 복잡한 비즈니스 로직을 가진 컴포넌트를 이 5가지의 엄격한 범주에 억지로 끼워 맞추려다 보면 어려움에 직면할 수 있다는 한계도 지적됩니다 [10]. 이에 대한 보완책으로 Headless UI나 Compound Components 패턴이 현대 프론트엔드 환경에서 함께 권장됩니다 [28, 29].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Building Reusable UI Components.md

@@ -0,0 +1,33 @@
+# [[Building Reusable UI Components]]
+
+## 📌 Brief Summary
+재사용 가능한 UI 컴포넌트는 여러 프로젝트와 위치에서 코드를 크게 수정하지 않고도 사용할 수 있는 독립적이고 이식성(Portable)과 예측 가능성(Predictable)이 뛰어난 UI 구성 요소입니다 [1]. 이는 단일 책임을 가지며 명확한 API(Props)와 접근성(Accessibility)을 갖추어 확장 가능하고 일관성 있는 디자인 시스템을 구축하는 핵심 역할을 합니다 [2, 3]. 최신 React 생태계에서는 복잡성을 줄이기 위해 단순한 Prop 전달을 넘어서, 컴파운드 컴포넌트나 헤드리스 컴포넌트와 같은 고급 합성 패턴을 활용하여 재사용성을 극대화합니다 [4, 5].
+
+## 📖 Core Content
+* **재사용 가능한 컴포넌트의 4가지 핵심 원칙 (Four Golden Rules)**:
+  * **단일 책임 (Single Responsibility):** 각 컴포넌트는 한 가지 기능만 잘 수행하도록 만들어 버그를 줄이고 재사용성을 높여야 합니다 [3].
+  * **상속보다 합성 (Composition Over Inheritance):** 의견이 배제된(unopinionated) 기본 컴포넌트들을 블록처럼 조립하여 더 큰 컴포넌트를 구성해야 합니다 [3].
+  * **명확한 계약 (Explicit Contracts):** 컴포넌트가 받는 값(Props)과 반환하는 이벤트(Callbacks)의 API를 명확히 정의하여 부작용을 방지해야 합니다 [3, 6].
+  * **접근성 우선 (Accessibility First):** 키보드 내비게이션, ARIA 역할(Roles), 포커스 관리 등 스크린 리더 및 모든 사용자를 위한 접근성을 기본적으로 내장해야 합니다 [3, 7].
+
+* **상태 관리 및 API 설계 (State Boundaries & API Design)**:
+  * Prop 기반의 API는 요구사항이 늘어날수록 수많은 상태 변수(Prop Soup)를 발생시켜 확장을 어렵게 만듭니다 [6, 8]. 의도에 맞는 Prop 이름을 사용하고 안전한 기본값(Defaults)을 설정해야 합니다 [6].
+  * 툴팁 토글과 같은 로컬 UI 상태는 컴포넌트 내부에 유지하되, 필터링이나 데이터 호출과 같은 비즈니스 로직은 상위 부모 컴포넌트로 올려야(Push up) 재사용성이 높아집니다 [9].
+
+* **재사용성을 극대화하는 고급 React 패턴 (Scalable Component Patterns)**:
+  * **컴파운드 컴포넌트 (Compound Components):** 아코디언(Accordion)이나 탭(Tabs)처럼 여러 하위 컴포넌트가 Context를 통해 암시적으로 상태를 공유하도록 구성하여, 소비자가 레이아웃을 유연하게 제어할 수 있게 합니다 [10-12].
+  * **헤드리스 컴포넌트 (Headless Components):** 시각적인 마크업(UI) 없이 상태와 동작 로직만 제공하여, 디자인 시스템과 무관하게 접근성 높고 재사용 가능한 컴포넌트를 만들 수 있습니다 [13-15].
+  * **렌더 프롭스 (Render Props):** 함수를 자식 요소로 전달하여 로직을 공유하고 렌더링에 대한 완전한 제어권을 사용자에게 부여합니다 [15, 16].
+  * **슬롯 및 영역 (Slots / Regions):** 소비자가 직접 콘텐츠를 끼워 넣을 수 있는 의도적인 빈 공간(예: 헤더, 푸터)을 제공하여 Prop의 과부하를 막습니다 [14].
+
+* **스타일링과 테마 적용 (Styling & Theming)**:
+  * 재사용 가능한 컴포넌트는 하드코딩된 스타일을 피하고, 색상이나 간격 등의 디자인 토큰(Design Tokens)을 기반으로 브랜드의 룩을 상속받아야 합니다 [17].
+  * 구조를 캡슐화하면서도 클래스 이름이나 스타일 Prop을 주입할 수 있는 훅을 노출하여, 코드를 포크(Fork)하지 않고도 여러 제품 스킨이나 다크 모드 테마에 유연하게 대응하도록 설계해야 합니다 [17, 18].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Compound Components]], [[Headless Components]], [[Atomic Design]], [[Design Tokens]]
+- **Projects/Contexts:** [[Shopify Polaris]] (재사용 가능한 컴포넌트와 접근성을 제공하여 일관된 앱 UI를 구축하는 쇼피파이의 디자인 시스템 [19, 20]), [[Uber Base Web]] (다양한 요구사항에 대응하기 위해 모든 하위 요소의 스타일과 기능을 제어할 수 있는 'Overrides' 패턴을 구현한 React 컴포넌트 라이브러리 사례 [21, 22])
+- **Contradictions/Notes:** 컴파운드 컴포넌트는 뛰어난 레이아웃 구성의 자유도를 제공하지만 [10], 지나친 자유도는 UX 일관성을 해칠 수 있으며, 단순하고 구조가 고정된 컴포넌트(예: 버튼, 아이콘)에 사용할 경우 불필요한 추상화와 유지보수 비용만 증가시키게 되므로 상황에 맞게 적용해야 합니다 [23-25].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Client Components.md

@@ -0,0 +1,22 @@
+# [[Client Components]]
+
+## 📌 Brief Summary
+클라이언트 컴포넌트(Client Components)는 모던 React 아키텍처(예: Next.js 15 App Router)에서 `'use client'` 지시어로 정의되며 전통적인 React 컴포넌트처럼 동작하는 UI 요소이다 [1]. 서버 컴포넌트와 달리 클라이언트 측 자바스크립트를 실행하므로 상태(state) 관리, 이벤트 핸들러 등 상호작용이 필요하거나 브라우저 API를 사용해야 할 때 필수적으로 적용된다 [1, 2]. 확장 가능한 프론트엔드 환경에서는 자바스크립트 번들 크기를 최소화하고 성능을 극대화하기 위해 클라이언트 컴포넌트를 작고 기능적으로 집중된 형태로 유지하는 것이 핵심 원칙이다 [2, 3].
+
+## 📖 Core Content
+* **경계 설정 및 하이드레이션(Hydration):** 클라이언트 컴포넌트는 최상단에 `'use client'` 지시어를 선언하여 클라이언트 측 자바스크립트가 시작되는 경계를 명확히 표시한다 [1]. 서버가 렌더링한 정적 HTML에 React가 이벤트 리스너와 상태를 연결하여 상호작용을 가능하게 만드는 과정인 하이드레이션(Hydration)은 Next.js 15 기준으로 오직 클라이언트 컴포넌트에서만 발생한다 [4].
+* **컴포넌트 합성 패턴(Composition Patterns):** 재사용 가능하고 확장성 있는 UI를 구축하기 위해 다양한 합성 패턴이 사용된다. 서버 컴포넌트가 클라이언트 컴포넌트를 하위 요소로 렌더링하거나, 반대로 서버 컴포넌트를 클라이언트 컴포넌트의 자식(children)이나 props로 전달하여 자식 요소가 서버 컴포넌트로서의 특성을 유지하게 할 수 있다 [1, 4]. 또한 클라이언트 측 상태를 앱 전반에 공유하기 위해 Context Provider 패턴을 사용하기도 한다 [4].
+* **확장 가능한 프론트엔드를 위한 모범 사례:** 
+  * 기본적으로 서버 컴포넌트를 사용하고 상호작용이 필요한 구역만 클라이언트 컴포넌트로 분리하여 작게 유지해야 한다 [2, 3].
+  * 레이아웃 등 최상단 요소에 불필요하게 `'use client'`를 남용하면 하위의 모든 라우트가 클라이언트 측 컴포넌트로 강제 전환되므로 주의해야 한다 [3].
+  * 데이터 패칭은 가급적 서버 측에서 수행하여 클라이언트 번들 크기를 줄이고 보안을 유지해야 한다 [3].
+  * 함수, 날짜, 클래스 인스턴스 등 직렬화할 수 없는(non-serializable) props를 서버 컴포넌트에서 클라이언트 컴포넌트로 넘겨서는 안 된다 [5].
+* **스타일링 파라다임 및 테마 적용(CSS-in-JS):** Next.js App Router 아키텍처에서 styled-components와 같은 런타임 CSS-in-JS 라이브러리를 사용하려면, 렌더링 중 CSS 규칙을 수집하기 위한 '스타일 레지스트리(Style Registry)'를 구성하고 이를 클라이언트 컴포넌트로 래핑해야 한다 [6]. 더 나아가, React Context 없이도 클라이언트 컴포넌트와 서버 컴포넌트 모두에서 테마가 작동하도록 CSS 사용자 지정 속성(CSS custom properties)을 기반으로 한 `createTheme` 등의 기능이 도입되어 렌더링 컨텍스트의 한계를 극복하고 있다 [7].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Server Components]], [[Hydration]], [[CSS-in-JS]], [[React Context]]
+- **Projects/Contexts:** [[Next.js App Router]], [[styled-components]]
+- **Contradictions/Notes:** 전통적인 런타임 CSS-in-JS 라이브러리(styled-components, Emotion)는 내부적으로 React Context에 의존하기 때문에 서버 컴포넌트에서는 작동하지 않고 클라이언트 컴포넌트 래핑이 필요하지만, 대규모 프로젝트의 성능(Core Web Vitals) 향상과 Next.js App Router와의 완벽한 호환을 위해서는 런타임 비용이 없는 [[Tailwind CSS]], CSS Modules 또는 vanilla-extract 등의 정적 CSS 생성 도구로의 전환이 2025년 기준 더욱 강력히 권장되고 있다 [6, 8-11].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Component API Design.md

@@ -0,0 +1,22 @@
+# [[Component API Design]]
+
+## 📌 Brief 소목 Summary
+컴포넌트 API 디자인(Component API Design)은 개발자가 UI 컴포넌트를 사용하고 구성하는 방식에 대한 구조적 설계와 인터페이스 정의를 의미합니다[1-3]. 잘 설계된 컴포넌트 API는 과도한 Prop 설정에 의존하는 대신 합성(Composition)을 활용하여 소비자가 유연하게 UI를 조립할 수 있도록 돕습니다[2, 4]. 이는 확장 가능하고 유지보수가 쉬운 재사용 가능한 React 컴포넌트 라이브러리를 구축하는 데 핵심적인 역할을 합니다[1, 5, 6].
+
+## 📖 Core Content
+* **Prop-Driven API의 한계**: 컴포넌트의 레이아웃과 동작을 오직 수많은 Prop(예: 다수의 불리언 플래그)으로만 제어하려 하면, 각 Prop이 결합되어 내부 로직이 복잡해지는 '블랙박스'가 형성됩니다[4, 7, 8]. 이는 예기치 않은 동작을 유발하고, 사소한 변경에도 시스템이 쉽게 깨지는 원인이 됩니다[4, 7].
+* **명확한 계약(Explicit Contracts) 및 Prop 설계**: 좋은 컴포넌트 API는 직관적이고 오용하기 어려워야 합니다[3]. 구현 방식이 아닌 사용 목적(intent)에 따라 Prop 이름을 짓고, Prop의 수를 최소화하여 지나치게 복잡한 설정(Prop Soup)을 피해야 합니다[3, 9]. 또한 초기 사용을 위해 합리적인 기본값(Sensible Defaults)을 제공해야 합니다[3, 10].
+* **합성 기반(Composition-Driven) 사고의 전환**: "컴포넌트가 어떻게 보여야 하는지"를 지시하는 대신, 상태와 규칙만 제공하고 "레이아웃은 소비자가 조립"하도록 구성하는 멘탈 모델로의 전환이 필요합니다[2]. 
+* **확장 가능한 주요 API 패턴**:
+  * **복합 컴포넌트 (Compound Components)**: `Accordion`, `Accordion.Item` 등과 같이 여러 하위 컴포넌트가 React Context를 통해 암시적으로 상태를 공유하는 패턴입니다[5, 11, 12]. 이 패턴은 Prop 드릴링을 방지하고 선언적이며 읽기 쉬운 구조를 제공합니다[5, 11].
+  * **Render Props**: 사용자에게 특정 UI 렌더링에 대한 완전한 제어권을 넘겨주는 '탈출구(escape hatch)' 역할을 하며, 기존 API를 해치지 않으면서 고급 사용자에게 유연성을 제공합니다[13, 14].
+  * **오버라이드 패턴 (Overrides Pattern)**: Uber의 Base Web 등에서 활용되는 방식으로, `overrides` prop을 통해 컴포넌트 내부의 특정 하위 요소에 접근하여 속성, 스타일, 또는 렌더링 방식 전체를 대체할 수 있게 해줍니다[9, 15-17]. 이를 통해 모든 엣지 케이스를 위한 새로운 Prop을 추가할 필요가 없어집니다[17].
+  * **헤드리스 컴포넌트 (Headless Components) 및 슬롯 (Slots)**: UI 스타일링 없이 상태와 동작 로직만 제공하거나(Headless), 소비자가 자체 콘텐츠를 삽입할 수 있는 의도된 영역(Slots)을 제공하여 API의 복잡성을 낮추는 패턴입니다[8, 18].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Compound Components]], [[Headless Components]], [[Overrides Pattern]], [[Prop Drilling]], [[Atomic Design]]
+- **Projects/Contexts:** [[Uber Base Web]], [[Radix UI]], [[Shopify Polaris]]
+- **Contradictions/Notes:** 복합 컴포넌트(Compound Components) 패턴은 강력한 구성의 자유도를 제공하지만, 지나친 자유로움으로 인해 사용자가 하위 컴포넌트의 순서를 임의로 변경하여 UX나 접근성의 일관성을 해칠 위험이 있습니다[19, 20]. 따라서 버튼이나 아이콘같이 단순하고 구조가 고정된 컴포넌트에서는 불필요한 추상화가 되므로 일반적인 Prop-Driven 방식이 더 안전하고 적합합니다[20, 21].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Component Library Architecture.md

@@ -0,0 +1,20 @@
+# [[Component Library Architecture]]
+
+## 📌 Brief Summary
+컴포넌트 라이브러리 아키텍처는 확장 가능하고 유지보수가 용이한 프론트엔드 애플리케이션을 구축하기 위해 재사용 가능한 UI 컴포넌트를 설계하고 조직화하는 구조적 접근 방식입니다 [1, 2]. 이는 단순한 시각적 요소를 넘어, 컴포넌트 간의 상태 공유, 로직 분리, 아키텍처 패턴을 활용하여 일관성 있는 시스템을 구현하는 것을 목표로 합니다 [3-5]. 잘 설계된 아키텍처는 과도한 상태 전달(prop drilling)을 방지하고 높은 유연성을 제공하여 끊임없이 변화하는 제품 요구사항에 안전하게 대처할 수 있게 합니다 [1, 6-8].
+
+## 📖 Core Content
+* **아토믹 디자인(Atomic Design) 방법론:** UI를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages) 등 5단계의 계층으로 나누어 구조화하는 멘탈 모델입니다 [2, 9, 10]. 이는 디자인 시스템의 일관성을 촉진하지만, 복잡한 비즈니스 로직과 결합될 때는 UI 라이브러리에만 아토믹 구조를 적용하고 애플리케이션 코드는 기능(Feature) 기반으로 분리하여 비즈니스 로직을 캡슐화하는 하이브리드 방식이 주로 권장됩니다 [11, 12].
+* **복합 컴포넌트(Compound Components) 패턴:** 탭(Tabs)이나 아코디언(Accordion)과 같이 밀접하게 연관된 하위 컴포넌트들이 React Context를 통해 암시적으로 상태를 공유하는 패턴입니다 [13-15]. 무수히 많은 Prop을 하위로 계속 넘겨주는 대신, 컴포넌트 소비자가 직접 하위 요소를 조합할 수 있게 하여 레이아웃의 유연성을 극대화하고 API를 깔끔하게 유지합니다 [3, 6, 16, 17].
+* **헤드리스 컴포넌트(Headless Components):** 접근성, 상태 관리, 비즈니스 로직 등 핵심 기능만 제공하고 시각적인 마크업과 스타일링은 전적으로 개발자에게 위임하는 방식입니다 [18, 19]. 주로 Tailwind CSS와 결합하여 특정 프레임워크나 디자인 시스템에 종속되지 않는 고도로 맞춤화된 UI 라이브러리를 구축하는 데 사용됩니다 [18, 20].
+* **오버라이드 패턴(Overrides Pattern):** Uber의 Base Web 시스템 등에서 활용하는 아키텍처로, 컴포넌트 내부의 모든 하위 요소에 접근할 수 있는 식별자를 제공하여 스타일, 속성, 혹은 렌더링되는 컴포넌트 자체를 통째로 교체할 수 있게 합니다 [21-24]. 이를 통해 모든 엣지 케이스마다 새로운 Prop을 추가하여 발생하는 복잡성(Prop soup)을 방지하고 심층적인 커스터마이징을 지원합니다 [23, 24].
+* **기능 분할 설계(Feature-Sliced Design, FSD) 및 모노레포:** 거대한 컴포넌트 라이브러리와 다수의 애플리케이션이 공존할 때, 단방향 의존성 흐름을 강제하는 구조입니다 [25-28]. Shared(공유 UI 기본 요소, 디자인 토큰 등), Entities, Features, Widgets, Pages 등의 계층으로 명확히 나누어 모노레포(Turborepo, Nx 등) 내에서 안정적이고 격리된 아키텍처를 유지할 수 있게 합니다 [27, 29-31].
+* **디자인 토큰(Design Tokens) 계층화:** 색상, 타이포그래피, 간격 등의 원시 값을 추상화하여 기본 토큰(Primitives), 시맨틱 토큰(Semantic), 컴포넌트 토큰(Component Tokens)의 3단계 계층 구조로 관리합니다 [32-35]. 이는 테마(예: 다크 모드)의 동적 전환을 용이하게 하고 라이브러리 전반의 시각적 일관성과 안전한 리팩토링을 보장합니다 [5, 36-38].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Atomic Design]], [[Compound Components]], [[Headless Components]], [[Design Tokens]], [[Feature-Sliced Design]]
+- **Projects/Contexts:** [[Uber Base Web]], [[Shopify Polaris]], [[React Server Components (RSC)]], [[Tailwind CSS vs Styled Components]]
+- **Contradictions/Notes:** 복합 컴포넌트 패턴은 높은 유연성을 주지만 과용하면 소비자에게 너무 많은 통제권을 주어 UX나 접근성 등 구조적 일관성이 깨질 위험이 있습니다. 따라서 레이아웃이 고정되어 있는 단순한 버튼이나 배지 같은 컴포넌트에는 일반적인 Prop 기반 방식이 훨씬 적합합니다 [39-41]. 또한, 컴포넌트 스타일링 구현 시 Styled Components처럼 런타임에 스타일을 주입하는 방식은 동적 스타일링에 강력하나 Next.js 15의 App Router 및 RSC 환경에서는 Context 부재로 인한 구조적 제약과 번들 사이즈 등 성능 비용이 따릅니다 [42-45]. 이 때문에 최신 프론트엔드 아키텍처는 정적 CSS 생성이 가능한 Tailwind CSS 또는 Zero-runtime 방식(vanilla-extract 등)을 컴포넌트 라이브러리 구축에 더 권장하는 추세입니다 [46-49].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Component-Based Design.md

@@ -0,0 +1,23 @@
+# [[Component-Based Design]]
+
+## 📌 Brief Summary
+컴포넌트 기반 디자인(Component-Based Design)은 사용자 인터페이스를 재사용 가능하고 이식성이 뛰어나며 예측 가능한 모듈식 구성 요소로 구축하는 아키텍처 접근 방식입니다 [1, 2]. 이는 거대한 단일 컴포넌트를 구성하는 방식에서 벗어나, 조합(Composition)을 통해 레이아웃과 동작을 조립함으로써 '프롭 드릴링(prop drilling)'과 숨겨진 결합도를 줄입니다 [3-5]. 단일 책임 원칙과 명시적인 API 계약을 준수함으로써, 변화하는 요구사항에 유연하게 적응하고 확장할 수 있는 확장성 높은 UI 시스템을 구축하는 데 핵심적인 역할을 합니다 [6-8].
+
+## 📖 Core Content
+- **원자적 설계(Atomic Design) 계층 구조**: 사용자 인터페이스는 더 이상 분해할 수 없는 기본 요소인 원자(Atoms), 이들이 모인 분자(Molecules), 더 복잡한 유기체(Organisms), 구조를 정의하는 템플릿(Templates), 그리고 실제 콘텐츠가 채워지는 페이지(Pages)의 5단계로 체계화하여 설계할 수 있습니다 [9-12].
+- **재사용성을 위한 핵심 원칙**: 훌륭한 재사용 가능 컴포넌트는 단일 책임(Single Responsibility) 원칙을 따르고, 상속보다는 조합(Composition)을 우선하며, 명확한 API 계약을 가져야 합니다 [8]. 내부 상태를 최소화하여 예측 가능성을 높이고, 접근성(Accessibility)을 기본적으로 내장해야 합니다 [8, 13].
+- **프롭(Prop) 기반에서 조합(Composition) 기반 API로의 전환**: 모든 구성 옵션을 프롭으로 전달하는 방식은 컴포넌트를 변경하기 어려운 '블랙 박스'로 만들며 기하급수적인 복잡성을 초래합니다 [14-16]. 대신, 책임을 분산시켜 사용자가 필요에 따라 하위 요소를 조립하게 하는 조합 기반 접근 방식이 대규모 UI 확장에 유리합니다 [3, 5].
+- **확장 가능한 컴포넌트 패턴**:
+  - **복합 컴포넌트(Compound Components)**: React 컨텍스트를 활용하여 탭(Tabs)이나 아코디언(Accordion)과 같은 여러 컴포넌트가 암시적으로 상태를 공유하는 패턴으로, 프롭 비대화 없이 높은 레이아웃 조립 유연성을 제공합니다 [4, 16-18].
+  - **헤드리스 컴포넌트(Headless Components)**: 복잡한 상태 관리와 논리만 캡슐화하고 UI 마크업과 스타일링은 온전히 소비자에게 위임하여, 특정 디자인 시스템에 구애받지 않는 유연성을 제공합니다 [16, 19, 20].
+  - **렌더 프롭(Render Props)**: 렌더링 함수를 자식이나 프롭으로 전달하여 논리를 공유하는 기법으로, 사용자에게 렌더링 결과에 대한 완전한 제어권을 줍니다 [16, 20, 21].
+  - **오버라이드 패턴(Overrides Pattern)**: 컴포넌트 내부의 하위 요소에 대한 식별자를 노출하여, 매번 새로운 프롭을 추가할 필요 없이 특정 내부 요소의 스타일이나 하위 컴포넌트를 깊게 커스터마이징할 수 있게 합니다 [16, 22, 23].
+- **디자인 토큰(Design Tokens) 바인딩**: 컴포넌트는 하드코딩된 리터럴 값(예: `#dc2222`)을 피하고 디자인 토큰(예: `color.error`)을 참조하여 바인딩해야 합니다 [24, 25]. 이를 통해 간격, 색상, 타이포그래피 등의 디자인 요소가 변경될 때 시스템 전체에 일관된 업데이트가 자동으로 반영됩니다 [24].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Atomic Design]], [[Compound Components]], [[Headless Components]], [[Design Tokens]], [[Feature-Sliced Design]]
+- **Projects/Contexts:** [[Uber Base Web]], [[Shopify Polaris]], [[Radix UI]]
+- **Contradictions/Notes:** 원자적 설계(Atomic Design)는 시각적 일관성을 유지하는 데 효과적이지만, 복잡한 비즈니스 로직을 포함하는 컴포넌트를 엄격한 범주에 억지로 맞출 때 구조적 한계에 부딪힐 수 있으므로 실무에서는 기능(Feature) 기반 구조와 결합하여 사용하는 것이 권장됩니다 [26, 27]. 또한, 복합 컴포넌트 패턴은 소비자에게 막강한 유연성을 제공하지만, 너무 많은 자유를 허용하면 일관된 UI나 접근성이 훼손될 수 있으므로 디자인 시스템 차원에서 안전한 구성 경계(composition boundaries)를 문서화하는 것이 필수적입니다 [28, 29].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Compound Components Pattern.md

@@ -0,0 +1,23 @@
+# [[Compound Components Pattern]]
+
+## 📌 Brief Summary
+Compound Components 패턴은 암시적으로 상태를 공유하고 특정 부모 내에서만 작동하는 일련의 관련 컴포넌트들을 노출하여 선언적이고 가독성 높은 API를 구성하는 React 컴포넌트 설계 방식이다 [1]. 모든 기능을 수십 개의 prop으로 단일 컴포넌트에 쑤셔넣는 대신, 여러 협력 컴포넌트에 책임을 분산시켜 복잡한 요구사항을 처리한다 [2]. 이는 HTML의 `<select>`와 `<option>` 요소처럼 개별적인 책임을 유지하면서도 응집력 있는 단위로 함께 작동하여, 재사용 가능하고 유연한 UI를 구축하는 데 핵심적인 역할을 한다 [1, 3].
+
+## 📖 Core Content
+* **작동 원리 및 상태 관리:** 이 패턴은 React Context를 내부 계약(Internal Contract)으로 사용하여 prop drilling 없이 컴포넌트 간에 상태를 공유한다 [1, 4, 5]. 최상위(Root) 컴포넌트인 Provider는 전역 상태를 소유 및 관리하며, 하위 컴포넌트(Header, Body 등)는 전체 상태를 알 필요 없이 자신에게 필요한 좁은 범위의 상태만 소비하도록 설계된다 [6-8].
+* **주요 장점:** 
+  * 컴포넌트의 레이아웃과 구성을 소비자가 자유롭게 결정할 수 있는 높은 유연성을 제공한다 [3, 9].
+  * 복잡한 기능을 구현할 때 수많은 설정 prop으로 인해 발생하는 'Prop Soup(프롭 수프)' 문제와 내부 로직이 숨겨지는 '블랙 박스' 문제를 해결하여 명확한 API를 유지할 수 있다 [10-12].
+  * 디자인 시스템 구축 시 확장성이 뛰어나며, `aria-controls`와 같은 접근성(A11y) 속성을 수동으로 전달할 필요 없이 내부적으로 자동 연결하여 관리를 단순화할 수 있다 [13].
+* **단점 및 주의사항:** 
+  * 초기 작성해야 하는 보일러플레이트 코드량이 많고, 로직이 Context나 Hook에 분산되어 있어 단순 prop 기반 컴포넌트보다 버그 추적 및 디버깅이 어려울 수 있다 [13, 14].
+  * 컴포넌트의 순서를 바꾸거나 생략할 수 있는 등 소비자에게 주어지는 자유도가 너무 높으면 오히려 UX나 접근성 일관성이 깨질 위험이 있어 명확한 문서화가 필수적이다 [14, 15].
+* **적용 시기:** 레이아웃이 다양하게 변하거나, 소비자가 구성을 자유롭게 조합해야 할 때, 혹은 확장 가능한 공유 UI 라이브러리를 구축할 때 매우 적합하다 [15]. 하지만 Button, Icon, Badge처럼 단일하고 고정된 레이아웃을 가진 단순한 컴포넌트에는 불필요한 추상화를 초래하므로 피해야 한다 [16].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[React Context API]], [[Headless Components]], [[Render Props]], [[Atomic Design]]
+- **Projects/Contexts:** [[Radix UI]], [[Headless UI]], [[React Design Systems]]
+- **Contradictions/Notes:** Compound Components는 구성의 유연성을 제공하여 재사용성을 높이지만, 너무 많은 자유도를 제공하면 일관성을 해치고 접근성을 손상시킬 수 있으므로 디자인 시스템 차원에서 "안전한 구성 경계(safe composition boundaries)"를 명확히 정의하고 문서화해야 한다 [14, 15]. 또한 모든 컴포넌트에 이 패턴을 남용하는 것은 가장 흔한 실수이며, 레이아웃이 고정된 단순 컴포넌트는 일반적인 Prop 기반 접근이 더 안전하고 단순하다고 조언한다 [16].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Compound Components.md

@@ -0,0 +1,34 @@
+# [[Compound Components]]
+
+## 📌 Brief 단기 요약
+합성 컴포넌트(Compound Components)는 여러 개의 연관된 하위 컴포넌트들이 암시적으로 상태를 공유하며 하나의 응집력 있는 단위로 동작하도록 설계하는 React 컴포넌트 패턴입니다 [1, 2]. 단일 컴포넌트에 수십 개의 Prop을 밀어 넣어 비대해지는 것을 방지하고, 기능과 책임을 여러 컴포넌트에 분산시킵니다 [3, 4]. 이는 HTML의 `<select>`와 `<option>` 태그처럼 직관적이고 선언적인 API를 형성하여 뛰어난 유연성과 재사용성을 제공합니다 [1, 4].
+
+## 📖 Core Content
+
+*   **설계 철학 및 멘탈 모델의 전환**
+    *   기존의 Prop 기반(Prop-Driven) API는 요구사항(레이아웃 변경, 조건부 동작 등)이 추가될 때마다 Prop이 폭발적으로 증가하여 유지보수가 어렵고 컴포넌트 내부가 파악하기 힘든 '블랙박스'가 되는 문제가 있습니다 [5-7].
+    *   합성 컴포넌트는 이를 '구성 중심(Composition-Driven)' 모델로 전환하여, 컴포넌트는 상태와 규칙만 관리하고 레이아웃과 구조의 결정권은 이를 사용하는 소비자(Consumer)에게 일임합니다 [7, 8].
+
+*   **React Context를 활용한 암시적 상태 공유**
+    *   이 패턴의 핵심 기술은 React Context를 내부 상태 관리의 '계약(Contract)'으로 사용하는 것입니다 [9]. 부모(Root) 컴포넌트가 Context를 통해 상태를 제공하고, 하위 컴포넌트들은 Prop Drilling 없이 필요한 상태만 구독하여 동작합니다 [1, 10].
+    *   내부 구현이 추상화되어 있으므로, 소비자는 내부가 어떻게 작동하는지 몰라도 하위 컴포넌트들을 자유롭게 조립할 수 있습니다 [9].
+
+*   **주요 장점**
+    *   **뛰어난 유연성과 가독성:** 특정 기능을 쉽게 포함하거나 제외할 수 있으며, 개발자는 하위 요소의 렌더링 순서와 구조를 자유롭게 재배치할 수 있습니다 [4, 7, 8].
+    *   **접근성(A11y) 자동화:** 컴포넌트 내부 Context에서 상태와 ID를 제어하므로, `aria-controls`나 `aria-labelledby` 같은 접근성 속성을 소비자가 수동으로 연결할 필요 없이 자동으로 처리할 수 있습니다 [11].
+
+*   **성능 최적화 기법**
+    *   복잡한 시스템이나 대규모 렌더링이 필요한 경우, 불필요한 리렌더링을 방지하기 위해 빈번하게 변경되는 상태와 정적인 구성을 각각 다른 Context로 분리(Split Contexts)하여 최적화할 수 있습니다 [12, 13].
+    *   필요한 곳에만 하위 컴포넌트를 전략적으로 메모이제이션(Memoization)하여 성능을 유지합니다 [14].
+
+*   **사용 시 주의사항 및 한계**
+    *   패턴을 구현하기 위해 초기에 작성해야 할 코드가 많아지고, Context 기반 렌더링 비용이 발생하며, 디버깅이 다소 까다로워질 수 있습니다 [11].
+    *   버튼, 배지, 아바타, 아이콘처럼 구조가 단일하고 레이아웃이 고정된 컴포넌트에는 불필요한 추상화(Overusing)가 될 수 있으므로 피해야 합니다 [15, 16]. 탭, 아코디언, 모달, 드롭다운과 같이 레이아웃과 조립 방식이 다양한 복잡한 UI에 가장 적합합니다 [17-19].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Render Props]], [[Headless Components]], [[Context API]], [[Atomic Design]]
+- **Projects/Contexts:** [[Radix UI]], [[Headless UI]], [[MUI]]
+- **Contradictions/Notes:** 합성 컴포넌트는 매우 유연하고 강력한 패턴이지만, 하위 컴포넌트의 구성을 소비자가 자유롭게 바꿀 수 있기 때문에 의도치 않게 접근성이나 일관된 UX를 해칠 수 있습니다. 따라서 디자인 시스템에서는 안전한 조합의 경계(Safe composition boundaries)를 정의하고 문서화하는 것이 필수적입니다 [15, 17]. 또한 단순하고 고정된 레이아웃을 가진 컴포넌트에서는 일반적인 Prop 기반 접근법이 훨씬 간단하고 안전합니다 [16].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Design System Architecture.md

@@ -0,0 +1,33 @@
+# [[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(RSC) 환경에서의 제약 때문에 Tailwind CSS와 같은 빌드 타임(Static) 유틸리티 모델이 더 우수하다는 강력한 성능적 반론이 존재합니다 [19-21, 29, 39, 40].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/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*

10_Wiki/Topics_Art/UI_UX_Assets/Design Tokens.md

@@ -1,31 +1,21 @@
 # [[Design Tokens]]
 
 ## 📌 Brief Summary
-디자인 토큰(Design Tokens)은 색상, 간격, 타이포그래피, 모션 등과 같은 시각적 디자인 속성을 저장하는 플랫폼 독립적인 명명된 식별자입니다 [1-3]. 이는 확장 가능한 디자인 시스템을 구축하기 위한 원자 단위(Atoms)의 핵심 구성 요소로 작용하여 여러 플랫폼과 환경에서 일관된 시각적 언어를 유지하게 합니다 [1, 4]. 하드코딩된 값을 대체함으로써 전역적인 테마 변경을 용이하게 하며, 디자인과 개발 팀 간의 원활한 협업을 지원하는 '단일 진실 공급원(Single Source of Truth)' 역할을 수행합니다 [3-5].
+디자인 토큰(Design Tokens)은 색상, 서체, 간격, 그림자, 모션 등 사용자 인터페이스의 시각적 DNA를 구성하는 원자 단위의 데이터 포인트입니다 [1-3]. 이 데이터는 JSON이나 YAML과 같은 기계 판독 가능한 형식으로 저장되어 디자인 도구와 코드를 자동으로 연결하는 단일 진실 공급원(Single source of truth) 역할을 합니다 [1, 4, 5]. 디자인 토큰은 하드코딩된 값을 대체함으로써 UI 구성 요소의 일관성을 유지하고, 다크 모드와 같은 동적 테마를 효율적으로 전환하며, React 프로젝트에서 확장 가능한 디자인 시스템을 구축하는 데 핵심적인 역할을 수행합니다 [6-8].
 
 ## 📖 Core Content
-* **디자인 토큰의 3단계 계층 구조 (Token Hierarchy)**:
-  효과적이고 확장성 있는 토큰 관리를 위해 유연성과 일관성의 균형을 맞추는 3단계 계층 구조가 사용됩니다.
-  * **글로벌 토큰 (Global Tokens / Primitives)**: 컨텍스트나 사용 의도가 포함되지 않은 원시 값(예: `--blue-500: #3b82f6`)으로, 디자인 시스템의 기본 팔레트 역할을 합니다 [6-8].
-  * **별칭 토큰 (Alias / Semantic Tokens)**: 글로벌 토큰을 참조하며 특정 의도나 사용 사례를 부여하는 토큰입니다(예: `--color-primary: var(--blue-500)`). 테마 시스템 구현에 핵심적이며, 이 값을 변경함으로써 애플리케이션 전체의 스타일을 쉽게 바꿀 수 있습니다 [6-8].
-  * **컴포넌트 토큰 (Component-specific Tokens)**: 특정 UI 요소에 맞춰 범위를 지정한 토큰(예: `--button-bg-primary: var(--color-primary)`)으로, 전체 시스템에 영향을 주지 않고 해당 구성 요소의 스타일만을 세밀하게 조정할 수 있게 합니다 [6, 8, 9].
-
-* **카테고리 및 명명 규칙 (Categories and Naming Conventions)**:
-  * 토큰은 기능에 따라 색상, 간격(여백, 패딩), 타이포그래피(글꼴 크기, 두께 등), 크기(너비, 아이콘 크기), 테두리(Border), 그림자, 모션(지속 시간, 이징), Z-index 등의 카테고리로 분류됩니다 [3, 10].
-  * CSS 환경에서는 주로 케밥 케이스(kebab-case)를 사용하며, 플랫폼 구현 세부 사항이 아니라 역할과 의미론(Semantic)에 기반한 명명 규칙을 적용하여 코드의 가독성과 예측 가능성을 높입니다 [11].
-
-* **다중 플랫폼 지원과 자동화 파이프라인 (Multi-Platform Automation)**:
-  * 대규모 프로젝트에서는 디자인 토큰을 JSON과 같은 플랫폼 중립적인 데이터 형식으로 저장합니다 [5, 12].
-  * Style Dictionary, Theo 등의 도구를 활용해 JSON 파일 하나를 웹의 CSS 변수, iOS용 Swift 코드, Android용 XML 코드 등으로 자동 변환하여 배포할 수 있습니다 [4, 5, 13]. 이 과정을 통해 사람의 수동 오류를 방지하고 제품 생태계 전반에 걸친 완벽한 시각적 동기화를 보장합니다 [4, 5].
-
-* **도구 및 실무 적용 (Tools & Implementation)**:
-  * 실무 워크플로우에서는 Design Tokens Generator 같은 수동 도구나, Figma 등 디자인 툴과 연동되는 반자동 플러그인(Toolabs Design System Manager 등)을 사용해 토큰을 추출 및 관리합니다 [14-17].
-  * 관리된 디자인 토큰은 CSS 변수나 SCSS 변수뿐만 아니라 Tailwind CSS의 `tailwind.config.js` 설정과 결합되어 강력한 유틸리티 클래스와 테마 시스템을 구축하는 데 활용됩니다 [12, 18].
+*   **디자인 토큰의 3계층 구조:** 확장 가능하고 안전한 시스템을 구축하기 위해 디자인 토큰은 3단계 계층으로 구성됩니다 [9-11].
+    *   **원시/기본 토큰 (Primitive/Base Tokens):** `#3366FF`나 `16px`과 같은 구체적이고 원시적인 값으로, 시맨틱(의미론적)인 목적을 갖지 않는 디자인 시스템의 기본 구성 요소입니다 [10, 12-14].
+    *   **시맨틱/앨리어스 토큰 (Semantic/Alias Tokens):** 원시 토큰을 참조하여 디자인의 '의도'와 역할을 명시합니다 (예: `color.primary = color.blue.500`) [10, 12-14]. 안전한 리팩토링과 테마 전환을 가능하게 하는 가장 중요한 계층입니다 [10, 12].
+    *   **컴포넌트 토큰 (Component Tokens):** 특정 컴포넌트와 그 변형에 직접적으로 연결된 토큰입니다 (예: `button.background = color.primary`) [10-14].
+*   **동적 테마 및 도구 통합:** 디자인 토큰을 활용하면 별도의 테마 토큰 세트(예: Light/Dark 모드)를 정의하여 **동적 테마(Dynamic Theming)**를 쉽게 구현할 수 있습니다 [15, 16]. Style Dictionary와 같은 도구를 사용하면 JSON에 정의된 토큰을 CSS Custom Properties(CSS 변수)나 iOS, Android, React용 포맷으로 자동 변환하여 코드 베이스에 즉시 주입할 수 있습니다 [17-20].
+*   **Tailwind CSS v4와의 시너지:** Tailwind CSS v4는 구성 방식에 있어 JavaScript 파일 대신 CSS 우선(CSS-first) 구조를 도입하여 토큰 관리에 패러다임 전환을 가져왔습니다 [21-23]. `@theme` 디렉티브 내에서 디자인 토큰을 기본 CSS 변수로 정의하면, Tailwind가 이에 대응하는 유틸리티 클래스를 자동으로 생성합니다(예: `--color-primary-500` 선언 시 `bg-primary-500` 사용 가능) [21-24]. 이를 통해 CSS 변수를 네이티브하게 활용할 수 있고, JS 오버헤드 없이 강력한 런타임 테마 기능을 제공합니다 [23, 25, 26].
+*   **협업 효율성 및 확장성:** 디자인 토큰은 디자이너와 프론트엔드 개발자 간에 공통된 언어를 형성하여 중복된 스타일링을 방지하고 코드의 유지보수 비용을 낮춥니다 [8, 27-29]. 중앙 집중식 토큰 관리를 통해 CI/CD 파이프라인에서 토큰의 배포를 자동화하면 대규모 React 애플리케이션에서도 시각적 일관성을 깨뜨리지 않고 스타일을 안정적으로 진화시킬 수 있습니다 [30-33].
 
 ## 🔗 Knowledge Connections
-- **Related Topics:** `[[Design Systems]]`, `[[CSS Variables]]`, `[[Tailwind CSS]]`
-- **Projects/Contexts:** `[[디자인 시스템 개념]]`, `[[실무에서 CSS 관리하는 방법]]`
-- **Contradictions/Notes:** 소스에 따르면 Figma Tokens와 같은 일부 반자동 플러그인 도구는 피그마의 기존 스타일과 완벽히 동기화되지 않거나, 테마 전환 시 디자인 속성이 오염되는 등 치명적인 버그를 가지고 있어 주의가 필요합니다 [19]. 반면 Amazon의 Style Dictionary와 같은 JSON 기반 변환 시스템은 훨씬 신뢰할 수 있는 업계 표준으로 소개됩니다 [5, 13].
+- **Related Topics:** `[[CSS Variables]]`, `[[Tailwind CSS v4]]`, `[[Style Dictionary]]`, `[[Dynamic Theming]]`
+- **Projects/Contexts:** `[[Figma Tokens Studio]]`, `[[React Component Architecture]]`, `[[Uber Base Web Design System]]`
+- **Contradictions/Notes:** 소스의 권장 사항에 따르면, 개발 시 컴포넌트에 원시 토큰(Primitive Tokens)이나 임의의 값을 직접 하드코딩하는 것은 시스템의 확장성을 파괴하는 주된 원인이 됩니다 [34, 35]. 따라서 스타일의 일관성을 유지하고 유연한 테마를 지원하기 위해서는 반드시 시맨틱 토큰(Semantic Tokens)을 거쳐 컴포넌트에 적용해야 합니다 [10, 34, 36].
 
 ---
 *Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Domain-Driven Design (DDD).md

@@ -0,0 +1,19 @@
+# [[Domain-Driven Design (DDD)]]
+
+## 📌 Brief Summary
+Domain-Driven Design (DDD)은 제한된 컨텍스트(bounded contexts)와 보편적 언어(ubiquitous language)와 같은 유용한 개념을 도입하는 소프트웨어 설계 방법론입니다 [1]. 프론트엔드 개발 팀은 종종 이러한 추상적인 개념을 실용적이고 유지보수 가능한 파일 시스템으로 변환하는 데 어려움을 겪습니다 [1]. 그러나 Feature-Sliced Design(FSD)과 같은 아키텍처 방법론을 활용하면 DDD의 개념을 도메인에 맞게 구체적인 프로젝트 구조로 구현하여 확장성 있는 프론트엔드를 구축할 수 있습니다 [1].
+
+## 📖 Core Content
+* **프론트엔드에서의 DDD 적용 한계:** DDD는 제한된 컨텍스트와 보편적 언어 등 훌륭한 아이디어를 제공하지만, 프론트엔드 팀들은 종종 이러한 추상적인 개념을 실용적인 디렉토리나 파일 시스템으로 해석하고 구현하는 데 어려움을 겪습니다 [1].
+* **FSD를 통한 DDD 보완:** Feature-Sliced Design (FSD) 아키텍처는 DDD의 추상적인 개념을 구체적인 프로젝트 구조로 매핑하여 이러한 문제를 해결합니다 [1]. 
+* **도메인 개념의 구조화 (Entities & Features):** FSD 구조에서 `entities/` 계층은 "User", "Product", "Order"와 같은 핵심 비즈니스 도메인 개념과 그에 따른 UI 및 상태(state) 표현을 담당합니다 [1, 2]. `features/` 계층은 사용자에게 가치를 제공하는 기능(예: 장바구니 담기, 결제 처리)을 포함하며, `shared/`는 재사용 가능한 UI 원형들을 보관합니다 [1, 2].
+* **가시적인 도메인 경계:** 이러한 디렉토리 구조화를 통해 도메인의 경계가 단순히 문서상에만 존재하는 것이 아니라, 코드의 import 경로와 디렉토리에서 명확하게 시각화됩니다 [1].
+* **모듈러 모놀리스(Modular Monolith)와의 연계:** 프론트엔드에서 수직적 슬라이스(Vertical Slice)나 모듈러 모놀리스 아키텍처를 채택할 때, 라우트, API, 테이블 등을 아우르는 엔드투엔드(end-to-end) 도메인 인터페이스를 정의할 수 있습니다 [3]. 도메인 간 워크플로우가 교차하는 경우 도메인 이벤트(domain events)를 활용하는 내부 이벤트 버스를 구성하여 결합도를 낮출 수 있습니다 [4].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Feature-Sliced Design (FSD)]], [[Modular Monolith]]
+- **Projects/Contexts:** [[Scalable Frontend Architecture]]
+- **Contradictions/Notes:** 소스에서는 프론트엔드 환경에서 DDD를 단독으로 적용하면 개념이 너무 추상적이어서 실패하기 쉬우며, 이를 실질적인 파일 시스템으로 변환해주는 FSD와 같은 구체적인 아키텍처 패턴의 도움이 필수적이라고 강조합니다 [1].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Feature-Sliced Design (FSD).md

@@ -0,0 +1,18 @@
+# [[Feature-Sliced Design (FSD)]]
+
+## 📌 Brief Summary
+**Feature-Sliced Design (FSD)**는 프런트엔드 시스템 내 앱과 패키지의 코드를 체계적으로 조직화하여 조직 전체의 일관성을 보장하도록 돕는 아키텍처 방법론입니다 [1]. 명확한 책임과 의존성 규칙을 가진 계층(Layer)으로 코드베이스를 나누어, 개발자가 코드가 어디에 위치해야 하고 어떻게 임포트되어야 하는지 예측할 수 있게 합니다 [1, 2]. 결과적으로 '전역 공유 폴더'가 무분별한 스파게티 코드의 쓰레기장으로 변하는 것을 방지하고, 리팩토링의 안전성을 확보하며 새로운 팀원의 온보딩 시간을 단축합니다 [1-3].
+
+## 📖 Core Content
+- **명확한 계층적 구조 (Layered Structure):** FSD는 코드베이스를 엄격한 책임에 따라 여러 계층으로 나눕니다. 일반적인 UI 컴포넌트나 헬퍼 함수, 디자인 토큰을 담는 가장 낮은 계층인 `Shared`부터 시작하여, 비즈니스 도메인을 나타내는 `Entities`, 사용자를 위한 비즈니스 로직(예: 결제 처리)을 담은 `Features`, 이러한 기능과 엔티티를 결합하는 `Widgets`, 전체 화면을 구성하는 `Pages`, 그리고 스타일 및 라우팅이 초기화되는 진입점인 `App`으로 구성됩니다 [1].
+- **의존성 방향 및 공개 API (Dependencies & Public APIs):** FSD는 상위 계층이 하위 계층을 향해서만 의존성을 가지도록 방향성을 통제하며, 슬라이스(slice) 경계에서 명시적인 공개 API(Public APIs)를 노출할 것을 권장합니다 [4, 5]. 예를 들어, 앱은 패키지의 깊은 내부 파일을 직접 임포트해서는 안 되며(`index.ts` 등을 통해서만 접근), 기능(`Features`)은 의도된 공유 슬라이스가 없는 한 다른 기능을 직접 임포트하지 않아야 합니다 [4, 5].
+- **도메인 주도 설계(DDD)의 구체화:** 프런트엔드 환경에서 도메인 주도 설계를 실용적인 파일 시스템으로 변환하는 것은 까다롭지만, FSD는 이를 구체적인 프로젝트 구조로 맵핑해 줍니다 [6]. 핵심 도메인 개념은 `entities/`에, 사용자 대면 기능은 `features/`에, 재사용 가능한 원시 요소는 `shared/`에 배치함으로써 도메인 경계를 디렉토리 및 임포트 수준에서 시각적으로 명확하게 드러냅니다 [6].
+- **모노레포 아키텍처와의 시너지:** 모노레포(Monorepo) 환경에서 FSD를 적용하면 UI 키트나 API 클라이언트 등은 공유 패키지로 분리하고, 각 앱과 도메인 패키지 내부는 FSD 계층에 따라 구조화하는 "두 세계의 장점(best of both worlds)"을 취할 수 있습니다 [7]. 이는 대규모 시스템에서 우발적인 결합(accidental coupling)을 크게 줄여줍니다 [4].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Monorepo Architecture]], [[Atomic Design]], [[Domain-Driven Design (DDD)]], [[Public APIs]]
+- **Projects/Contexts:** [[대규모 확장성과 유지보수성이 요구되는 프런트엔드 모노레포 프로젝트]], [[Turborepo 및 Nx와 같은 빌드 오케스트레이션 도구를 활용하는 대규모 조직의 React 시스템]]
+- **Contradictions/Notes:** 소스에 따르면 [[Atomic Design]]은 UI 컴포넌트와 디자인 시스템을 구성하는 데는 강력한 언어지만 도메인 로직의 위치를 일관되게 지정하기 어렵게 만드는 반면, FSD는 명확한 기능(Feature) 경계와 의존성 방향을 제공하여 대규모 애플리케이션의 아키텍처적 일관성을 유지하는 데 더 적합하다고 비교됩니다 [4].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Feature-Sliced Design.md

@@ -0,0 +1,28 @@
+# [[Feature-Sliced Design]]
+
+## 📌 Brief Summary
+Feature-Sliced Design(FSD)은 조직 전반의 일관성을 보장하기 위해 애플리케이션 및 패키지 내의 코드를 구성하는 커뮤니티 주도의 프론트엔드 아키텍처 방법론입니다 [1, 2]. 이 방법론은 명확한 책임과 의존성 방향을 가진 여러 계층(layer)으로 코드베이스를 나누어, 예측 가능한 슬라이스(slice) 경계와 명시적인 공개 API(Public API)를 제공합니다 [1-3]. 이를 통해 '글로벌 공유 폴더(global shared folder)'가 무분별한 코드의 쓰레기장으로 변하는 것을 방지하고, 유지보수가 용이한 확장 가능한 프론트엔드 시스템을 구축할 수 있습니다 [4, 5].
+
+## 📖 Core Content
+* **계층화된 아키텍처 (Layered Architecture):** FSD는 명확한 책임을 가진 여러 계층으로 코드를 분리합니다 [1].
+  * *Shared:* 가장 하위 계층으로 일반적인 UI 컴포넌트(원자), 헬퍼 함수, 디자인 토큰을 포함하며, 다른 어떤 계층에서도 가져올(import) 수 없습니다 [1, 6].
+  * *Entities:* 핵심 비즈니스 도메인(예: 사용자, 제품, 주문)을 나타내며 데이터 구조와 도메인별 로직 및 UI/상태 표현을 포함합니다 [1, 6].
+  * *Features:* 사용자에게 가치를 제공하는 비즈니스 로직(예: 장바구니 추가, 결제 진행)을 포함합니다 [1, 6].
+  * *Widgets:* 기능(features)과 엔티티(entities)를 결합한 상위 수준의 UI 블록(예: 제품 카드, 네비게이션 헤더)입니다 [1].
+  * *Pages:* 위젯과 기능을 기반으로 구축된 전체 페이지 구성입니다 [1].
+  * *App:* 글로벌 프로바이더, 스타일, 라우팅이 초기화되는 최상위 진입점입니다 [1].
+
+* **엄격한 의존성 방향 및 경계 규칙:** 우발적인 결합(coupling)을 줄이기 위해 강력한 제약 조건을 강제합니다 [3].
+  * 앱(App)은 패키지의 깊은 내부 파일이 아닌 오직 공개 API에서만 임포트해야 합니다 [3, 7].
+  * 의도적으로 공유된 슬라이스가 없는 한, 특정 기능(Feature)은 다른 기능(Feature)을 직접 가져올(import) 수 없습니다 [7].
+  * Shared 패키지는 비즈니스 흐름을 포함하지 않고 오직 재사용 가능한 기본 요소로만 작게 유지되어야 합니다 [7].
+
+* **도메인 주도 설계(DDD)와의 조화:** 기존 DDD의 추상적인 개념을 실용적인 파일 시스템 구조로 구체화하여, 임포트(import) 경로와 디렉토리 구조만으로도 도메인 경계를 명확히 식별할 수 있게 돕습니다 [6].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Monorepo Architecture]], [[Atomic Design]], [[Domain-Driven Design (DDD)]], [[Component Library Architecture]], [[Public API]]
+- **Projects/Contexts:** 대규모 프론트엔드 애플리케이션 및 디자인 시스템 구축, [[Turborepo]] 또는 [[Nx]]를 활용한 확장 가능한 프론트엔드 모노레포 관리 환경 [5, 8, 9].
+- **Contradictions/Notes:** 소스에 따르면 FSD는 [[Atomic Design]]과 경쟁하기보다는 상호 보완적으로 사용될 수 있습니다. UI 라이브러리에는 Atomic Design을 사용하여 "원자(Atoms)"를 순수하게 유지하고, 애플리케이션의 비즈니스 로직은 FSD의 Feature 기반 구조를 따르도록 결합하는 방식이 성공적인 아키텍처 패턴으로 제시됩니다 [10].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Figma Design System Integration.md

@@ -0,0 +1,17 @@
+# [[Figma Design System Integration]]
+
+## 📌 Brief Summary
+Figma Design System Integration(Figma 디자인 시스템 통합)은 Figma에서 결정된 디자인 요소(색상, 글꼴, 간격 등)를 애플리케이션의 실제 코드베이스와 원활하게 동기화하는 프로세스를 의미합니다 [1]. 주로 Tokens Studio for Figma와 같은 플러그인을 통해 디자인 결정을 JSON 형태의 디자인 토큰으로 구조화한 후, Style Dictionary 등의 도구로 React용 CSS 변수나 코드로 자동 변환합니다 [2], [3]. 최근에는 AI 에이전트나 코드 기반 UI 도구를 활용해 컴포넌트 스펙 생성과 디자이너-개발자 간 핸드오프를 자동화하여, 대규모 프론트엔드 아키텍처 내에서 디자인 시스템을 일관되고 확장 가능하게 유지하는 핵심 기술로 자리 잡고 있습니다 [4], [5], [6].
+
+## 📖 Core Content
+- **디자인 토큰 기반의 자동화 파이프라인:** 디자인 시스템 구축 시 Figma를 단일 진실 공급원(Single source of truth)으로 설정하여 스타일링 결정을 중앙화합니다 [1], [7]. Figma에서 내보낸 다크/라이트 모드 등의 JSON 토큰 데이터를 Style Dictionary를 사용해 처리하면, 플랫폼에 종속되지 않은 토큰이 React 애플리케이션에서 즉시 사용할 수 있는 JavaScript/TypeScript 객체 또는 CSS 변수 형태로 생성됩니다 [3], [8]. 이 자동화 파이프라인은 수동으로 스타일을 복제할 때 발생하는 오류를 방지하고, 일관성 있는 동적 테마(Dynamic Theming) 적용을 가능하게 합니다 [3], [7].
+- **코드 기반 컴포넌트 직접 연동:** 디자인 도구와 실제 코드 간의 불일치를 해결하기 위해 UXPin 등은 사용자 지정 Git React 컴포넌트 저장소를 디자인 워크플로우에 직접 통합하는 방식을 제공합니다 [5], [6]. 이를 통해 디자이너는 코드로 렌더링된 실제 컴포넌트를 이용해 프로토타입을 제작하게 되며, 코드베이스와 디자인 토큰이 자동으로 동기화됩니다 [6]. 반면, 이러한 코드 기반 통합이 불가능한 기존 디자인 툴 환경에서는 수동 JSON 내보내기와 빌드 파이프라인을 거쳐야 하므로 디자인과 개발 환경의 괴리(Drift)를 막기 위한 엄격한 관리 프로세스가 필요합니다 [9].
+- **AI 에이전트 및 MCP를 활용한 컴포넌트 스펙 자동화:** 대규모 UI 시스템에서 문서화의 병목을 해결하기 위해 Uber는 Figma Console MCP(Model Context Protocol)와 Cursor 내 AI 에이전트를 활용한 'uSpec' 시스템을 구축했습니다 [10], [4]. 이 AI 에이전트는 로컬 웹소켓을 통해 Figma 파일에 직접 연결한 후, 컴포넌트 트리, 토큰 값, 변형(Variants) 구조를 크롤링합니다 [11], [12]. 분석된 데이터를 기반으로 접근성 규칙(VoiceOver, ARIA 등)과 구조 스펙이 담긴 문서를 단 몇 분 만에 Figma 파일 내에 직접 렌더링하여 엔터프라이즈급 확장성을 입증했습니다 [13], [14], [15], [16].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Design Tokens]], [[Dynamic Theming]], [[Component-Based Design]], [[Automated Token Distribution]]
+- **Projects/Contexts:** [[Uber's Base Design System / uSpec]], [[Tokens Studio for Figma]], [[Style Dictionary]], [[UXPin Merge]]
+- **Contradictions/Notes:** Figma에서 토큰을 수동으로 내보내고 동기화하는 방식은 유용하지만 설계와 개발 코드 간의 드리프트(Drift)를 유발할 수 있습니다 [9]. 따라서 대규모 조직에서는 CI/CD 파이프라인을 통해 토큰 릴리스를 자동화하고 코드 리뷰와 동일한 수준의 엄격한 거버넌스를 갖추는 것이 필수적입니다 [17], [18], [19].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Headless Components.md

@@ -0,0 +1,25 @@
+# [[Headless Components]]
+
+## 📌 Brief Summary
+Headless Components(헤드리스 컴포넌트)는 마크업이나 스타일링 없이 상태 관리(State management)와 동작 로직(Behavioral logic)만을 제공하는 훅(Hooks) 또는 컴포넌트 패턴입니다 [1, 2]. 시각적인 렌더링 요소는 전적으로 이를 사용하는 개발자에게 위임하여 로직과 마크업을 완벽하게 분리합니다 [3]. 고도로 커스텀된 브랜드 UI를 구축하거나 접근성(Accessibility)을 잃지 않으면서도 특정 디자인 시스템에 종속되지 않는 유연한 재사용 가능 컴포넌트를 설계할 때 이상적으로 사용됩니다 [2-4].
+
+## 📖 Core Content
+* **로직과 마크업의 완벽한 분리 (Separation of Logic and Markup):**
+  Headless Components는 UI(시각적 형태) 없이 로직만을 노출하므로 개발자가 완전히 자유롭게 UI를 정의할 수 있습니다 [3]. 이러한 분리를 통해 컴포넌트의 구성 가능성(Composability)을 극대화할 수 있으며, 프레임워크나 특정 디자인 시스템에 구애받지 않고 작동합니다 [3]. 또한 'Headless Hook'의 형태로 추출될 경우, UI가 없는 상태에서도 독립적인 테스트가 가능해져 관심사의 분리(Separation of concerns)를 깔끔하게 유지할 수 있습니다 [5].
+
+* **완전한 스타일링 제어 (Complete Style Control):**
+  디자인적 의견(opinions)을 내포하여 배포되는 일반적인 Styled Components와는 다르게, Headless Components는 시각적 구현을 전적으로 소비자인 개발자에게 맡깁니다 [6]. 이 특성 덕분에 자체적인 브랜드 가이드라인을 엄격하게 반영해야 하는 고도의 브랜딩 애플리케이션(highly branded apps)을 개발하는 데 매우 적합합니다 [2]. 
+
+* **복잡한 상태 관리와 접근성 보장 (State Management & Accessibility):**
+  드롭다운, 다이얼로그, 콤보박스(예: Downshift의 `useCombobox()`) 등 상호작용이 복잡한 컴포넌트의 경우, Headless 라이브러리가 내부 상태뿐만 아니라 키보드 탐색, 스크린 리더 지원과 같은 필수적인 접근성(Accessibility) 기능을 모두 제공합니다 [3, 4]. 따라서 개발자는 브라우저별 호환성 이슈나 복잡한 상태 관리의 부담 없이 시각적 디자인에만 집중할 수 있습니다 [4].
+
+* **Tailwind CSS와의 시너지 (Synergy with Tailwind CSS):**
+  2025년 확장 가능한 프론트엔드 아키텍처의 핵심 트렌드 중 하나는 Radix UI나 Headless UI 같은 Headless 라이브러리의 적극적인 채택입니다 [4]. 특히 이 패턴은 Tailwind CSS와 결합할 때 그 진가를 발휘하는데, 복잡한 로직과 접근성은 Headless 컴포넌트가 책임지고, 시각적 스타일링은 Tailwind의 유틸리티 클래스로 빠르게 처리함으로써 접근성과 유지보수성이 뛰어난 브랜드 전용 UI 라이브러리를 쉽게 구축할 수 있습니다 [4].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Compound Components]], [[Tailwind CSS]], [[Accessibility (A11y)]], [[Design Systems]]
+- **Projects/Contexts:** [[Radix UI]], [[Headless UI]], [[Downshift]], [[shadcn/ui]]
+- **Contradictions/Notes:** 일반적인 스타일링 라이브러리(예: Styled Components)는 컴포넌트에 특정한 디자인적 '의견(opinions)'이 결합된 채로 제공되지만, Headless Components는 디자인을 배제하고 오직 로직과 상태만을 제공하여 시각적 자유도를 극대화한다는 점에서 명확한 대비를 이룹니다 [6].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Layout Thrashing.md

@@ -0,0 +1,24 @@
+# [[Layout Thrashing]]
+
+## 📌 Brief Summary
+레이아웃 스래싱(Layout Thrashing)은 브라우저가 페이지의 구조를 다시 계산해야 하는 리플로우(Reflow)와 리페인트(Repaint)를 과도하게 반복할 때 발생하는 성능 병목 현상입니다 [1, 2]. 주로 자바스크립트가 DOM을 읽고 쓰는 작업을 좁은 루프 안에서 번갈아 수행하거나 레이아웃에 큰 영향을 미치는 CSS 속성을 애니메이션화할 때 유발됩니다 [1, 2]. 이 현상은 프레임 속도를 심각하게 저하시키고 애니메이션을 끊기게 만들어 전반적인 사용자 경험을 훼손합니다 [1, 2].
+
+## 📖 Core Content
+**발생 원인**
+* **DOM 읽기/쓰기의 반복**: 자바스크립트 스크립트가 좁은 루프 내에서 DOM 속성에 대한 읽기와 쓰기를 번갈아 수행할 때 흔히 발생합니다 [2, 3]. 예를 들어 `offsetWidth`나 `offsetHeight` 같은 크기 관련 속성을 읽을 때, 브라우저는 정확한 치수를 제공하기 위해 내부 레이아웃 큐(Queue)를 강제로 비우고 동기적 리플로우(Synchronous reflow)를 수행해야 하므로 프레임 속도에 악영향을 미칩니다 [2].
+* **무거운 레이아웃 속성 변경**: `width`, `height`, `margin`, `padding`, `left/top/right/bottom`과 같이 기하학적 형태나 레이아웃에 직접적인 영향을 주는 속성을 애니메이션 처리하면 브라우저가 레이아웃을 지속적으로 재계산하게 되어 레이아웃 스래싱을 유발합니다 [1, 4, 5].
+
+**최적화 및 해결 방법**
+* **DOM 읽기와 쓰기 분리**: 레이아웃 스래싱을 방지하기 위해서는 DOM 값을 읽는 작업(Read)과 쓰는 작업(Write)을 엄격히 분리하여 수행해야 합니다 [3].
+* **DOM 변경 일괄 처리(Batching)**: 다수의 DOM 변경을 한 번에 묶어 처리하면 리플로우와 리페인트를 줄일 수 있습니다 [2, 6]. `classList.add()`나 `cssText`를 사용하여 단 한 번의 렌더링 주기만 유발하거나 `innerHTML`을 사용하여 여러 요소를 동시에 업데이트할 수 있습니다 [2, 6].
+* **가상 DOM 활용**: 새로운 요소를 라이브 DOM에 직접 추가하기 전에 `DocumentFragment`를 활용하여 추가하거나, 노드를 복제하여 변경한 후 원본과 교체하는 방식을 쓰면 요소당 한 번씩 일어날 리플로우를 단 한 번으로 줄일 수 있습니다 [2, 6, 7].
+* **애니메이션 속성 대체**: 애니메이션을 구현할 때는 레이아웃을 변경하는 속성 대신 GPU 가속의 이점을 얻을 수 있는 `transform`과 `opacity` 속성을 사용하여 리플로우 발생을 피해야 합니다 [5, 8, 9]. 또한 자바스크립트 기반 애니메이션에서는 `requestAnimationFrame`을 사용하여 브라우저의 네이티브 리페인트 주기와 동기화시킴으로써 끊김 없는 모션을 구현해야 합니다 [2, 3, 6].
+* **스타일 적용 방식 최적화**: 자바스크립트로 직접 인라인 스타일을 조작하기보다는 CSS 클래스를 추가/제거하는 방식을 사용해야 합니다 [6]. 렌더링 속도를 늦추는 깊고 복잡한 CSS 선택자의 사용을 피하고, 자주 변경될 요소에는 `will-change` 속성을 통해 브라우저가 미리 렌더링을 최적화할 수 있는 힌트를 제공하는 것도 방법입니다 [3, 6, 10]. 
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Reflow]], [[Repaint]], [[CSS Animations]], [[Performance Optimization]]
+- **Projects/Contexts:** [[Frontend Architecture]], [[실무에서 CSS 관리하는 방법]]
+- **Contradictions/Notes:** `will-change` 속성은 브라우저가 변경 사항에 미리 대비하게 해주어 성능을 향상할 수 있지만, 너무 많은 요소에 불필요하게 적용할 경우 오히려 브라우저 자원을 낭비하여 성능 문제를 일으킬 수 있으므로 신중하게 사용해야 합니다 [10].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/React Component Architecture.md

@@ -0,0 +1,32 @@
+# [[React Component Architecture]]
+
+## 📌 Brief Summary
+React Component Architecture(리액트 컴포넌트 아키텍처)는 확장 가능하고 유지보수가 용이하며 재사용 가능한 사용자 인터페이스(UI)를 구축하기 위한 구조적 방법론 및 설계 패턴을 의미합니다. 이 아키텍처는 아토믹 디자인(Atomic Design)과 같은 세분화 기준을 통해 컴포넌트를 계층적으로 구성하고, 컴파운드 컴포넌트(Compound Components)나 헤드리스 컴포넌트(Headless Components)와 같은 고급 합성 패턴을 사용하여 비즈니스 로직과 스타일링의 결합도를 낮춥니다. 잘 설계된 컴포넌트 아키텍처는 디자인 토큰(Design Tokens)의 적용을 용이하게 하며, 거대한 단일 컴포넌트에 발생하는 'Prop 드릴링' 문제를 최소화하여 대규모 프론트엔드 환경에서의 일관성과 유연성을 보장합니다.
+
+## 📖 Core Content
+
+*   **재사용성을 위한 핵심 설계 원칙 (Foundational Rules):**
+    효과적인 컴포넌트 아키텍처는 네 가지 핵심 원칙을 따릅니다 [1]. 첫째, 각 컴포넌트는 하나의 일만 잘 수행해야 하는 '단일 책임 원칙(Single Responsibility)'입니다. 둘째, '상속보다 합성(Composition Over Inheritance)'을 통해 작은 블록을 결합하여 큰 컴포넌트를 구성해야 합니다. 셋째, 명시적인 계약(Explicit Contracts)을 통해 컴포넌트의 API(prop)를 예측 가능하게 설계해야 합니다. 넷째, 접근성(Accessibility)을 최우선으로 고려하여 키보드 내비게이션이나 스크린 리더 지원을 내재화해야 합니다 [1, 2]. 
+
+*   **아토믹 디자인 방법론 (Atomic Design):**
+    UI를 구성하는 컴포넌트를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages)의 다섯 단계로 분류하는 아키텍처 접근법입니다 [3, 4]. 가장 기본적인 HTML 요소(버튼, 인풋 등)인 원자에서 시작하여, 이들을 조합한 분자(예: 검색 폼), 더 복잡한 유기체(예: 헤더)로 확장해 나갑니다 [5-7]. 이 방법론은 디자인 시스템의 일관성을 강제하고, 대규모 팀 환경에서 컴포넌트의 계층구조를 체계적으로 관리하는 데 매우 유용합니다 [8-10].
+
+*   **컴파운드 컴포넌트 패턴 (Compound Components):**
+    단일 컴포넌트에 수십 개의 Prop을 주입하는 대신(Prop-driven API), 여러 하위 컴포넌트들이 React Context를 통해 암묵적으로 상태를 공유하며 협력하는 합성 패턴입니다 [11-14]. 예를 들어 `Accordion.Root`, `Accordion.Item`, `Accordion.Header`, `Accordion.Body`와 같이 컴포넌트를 분리하여 소비자가 자유롭게 레이아웃과 순서를 결정할 수 있게 합니다 [15, 16]. 이를 통해 렌더링 유연성이 극대화되고 API가 훨씬 선언적이며 깔끔해집니다 [13, 17].
+
+*   **헤드리스 컴포넌트 (Headless Components):**
+    상태 관리(State)나 접근성(Accessibility) 같은 복잡한 비즈니스 로직 및 동작만을 캡슐화하여 제공하되, 시각적 마크업과 스타일링은 개발자가 완전히 자유롭게 정의할 수 있도록 하는 패턴입니다 [18, 19]. 복잡한 커스텀 UI 라이브러리를 구축할 때 필수적이며, 특히 Tailwind CSS와 같은 유틸리티 우선(Utility-first) 스타일링과 결합할 때 강력한 시너지를 발휘합니다 [18].
+
+*   **오버라이드 패턴 (Overrides Pattern):**
+    Uber의 Base Web과 같은 엔터프라이즈 디자인 시스템에서 활용되는 패턴으로, 하위 컴포넌트의 렌더링 동작, 추가 Prop, 그리고 스타일을 통째로 덮어쓰거나(Override) 교체할 수 있는 통합된 API를 제공합니다 [20-23]. 이를 통해 라이브러리 제작자가 모든 엣지 케이스(Edge Case)에 대비하여 개별 Prop을 만들 필요 없이('prop soup' 방지), 개발자에게 깊은 수준의 커스터마이징 권한을 부여할 수 있습니다 [21, 23].
+
+*   **모노레포 및 Feature-Sliced Design (FSD) 기반 아키텍처:**
+    앱이 확장됨에 따라 단일 컴포넌트를 넘어 앱 간의 의존성을 관리하는 것이 중요해집니다 [24]. 모노레포(Turborepo, Nx 등) 내에서 Feature-Sliced Design 방법론을 적용하여 코드를 Shared(UI 원자, 토큰), Entities, Features, Widgets, Pages, App 레이어로 나누어 계층 간 엄격한 의존성 방향을 설정할 수 있습니다 [25]. 이는 '무분별한 공유 폴더' 문제를 방지하고, 기능 단위의 독립성과 확장 가능한 UI 아키텍처를 제공합니다 [9].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Atomic Design]], [[Compound Components]], [[Headless Components]], [[Design Tokens]], [[Feature-Sliced Design (FSD)]]
+- **Projects/Contexts:** [[Uber Base Web]], [[Shopify Polaris]], [[Tailwind CSS]], [[Styled Components]]
+- **Contradictions/Notes:** 컴파운드 컴포넌트 패턴은 뛰어난 유연성을 제공하지만, 지나친 자유도(Too much freedom)로 인해 개발자가 서브 컴포넌트를 임의로 생략하거나 순서를 바꿔 UX와 접근성을 훼손할 위험이 존재합니다 [26]. 따라서 버튼, 아이콘, 배지 등 고정된 레이아웃을 가진 단순한 컴포넌트에는 적용을 피하고(단순한 Prop 방식이 더 안전함), 레이아웃 변형이 잦은 복잡한 UI(탭, 모달, 아코디언 등)에만 선택적으로 사용해야 합니다 [27, 28].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/React Component Library Architecture.md

@@ -0,0 +1,30 @@
+# [[React Component Library Architecture]]
+
+## 📌 Brief Summary
+React 컴포넌트 라이브러리 아키텍처는 확장 가능하고 유지보수가 용이한 프론트엔드 환경을 구축하기 위해 재사용 가능한 UI 컴포넌트를 설계하고 조직화하는 구조적 접근 방식입니다 [1, 2]. 이 아키텍처는 단일 책임 원칙과 합성을 강조하며, Prop의 과도한 사용으로 인한 결합도 증가를 피하고 유연성을 높이는 것을 목표로 합니다 [3-6]. 아토믹 디자인(Atomic Design), 컴파운드 컴포넌트(Compound Components), 헤드리스(Headless) UI 등 다양한 고급 디자인 패턴과 디자인 토큰을 결합하여 다양한 플랫폼 및 테마 요구사항에 대응할 수 있는 일관된 시스템을 제공합니다 [7-10].
+
+## 📖 Core Content
+*   **구조적 계층화 방법론 (Structural Methodologies)**
+    *   **아토믹 디자인 (Atomic Design):** UI를 원자(Atoms: 버튼, 입력창 등), 분자(Molecules: 라벨이 있는 입력창 등), 유기체(Organisms: 헤더 등), 템플릿(Templates), 페이지(Pages)의 5단계로 세분화하는 방법론입니다 [2, 7, 11]. 이를 통해 일관성을 강제하고 추상적인 요소부터 구체적인 최종 UI까지 유기적인 설계가 가능합니다 [12-14].
+    *   **Feature-Sliced Design (FSD)와의 결합:** 대규모 애플리케이션이나 모노레포(Monorepo) 환경에서는 범용적인 UI 원자(Atoms)를 'Shared' 계층의 별도 패키지로 분리하고, 비즈니스 로직은 'Features' 계층에 캡슐화하여 의존성 방향을 통제합니다 [15-17].
+
+*   **확장성을 위한 컴포넌트 패턴 (Scalable Component Patterns)**
+    *   **컴파운드 컴포넌트 (Compound Components):** `Select`와 `Option`의 관계처럼 여러 하위 컴포넌트들이 React Context를 통해 암시적으로 상태를 공유하며 하나의 단위로 작동하는 패턴입니다 [8, 18]. 소비자가 직접 레이아웃과 구성을 결정할 수 있게 하여 유연성을 극대화하며, 수많은 Prop으로 인한 'Prop 지옥(prop soup)'을 방지합니다 [3, 5, 8, 19].
+    *   **헤드리스 컴포넌트 (Headless Components):** 복잡한 상태 관리와 접근성(A11y), 비즈니스 로직만을 캡슐화하여 제공하고 시각적인 마크업과 스타일링은 전적으로 개발자에게 위임하는 패턴입니다 [10, 20]. Tailwind CSS와 같은 유틸리티 퍼스트 프레임워크와 함께 사용할 때 브랜딩에 맞춘 UI 라이브러리를 구축하는 데 매우 효과적입니다 [10].
+    *   **오버라이드 패턴 (Overrides Pattern):** Uber의 Base Web 등에서 사용되는 아키텍처로, 컴포넌트 내부의 각 하위 요소에 식별자를 부여하여 `overrides` Prop을 통해 개별 스타일, 속성, 심지어 렌더링되는 컴포넌트 자체를 교체할 수 있도록 합니다 [21-23].
+
+*   **디자인 토큰과 테마 아키텍처 (Design Tokens & Theming)**
+    *   성공적인 컴포넌트 아키텍처는 컴포넌트 내부에 고정된 스타일 값을 사용하지 않고, 3계층의 디자인 토큰 시스템(원시 토큰, 시맨틱 토큰, 컴포넌트 토큰)을 활용하여 디자인 의도와 컴포넌트를 분리합니다 [24-27].
+    *   이러한 토큰들은 CSS 변수(Custom Properties)로 변환되어 React 컴포넌트에 주입되며, 이를 통해 자바스크립트 컴파일 없이도 다크 모드 등 동적 런타임 테마 전환이 가능해집니다 [28-30]. 
+
+*   **API 설계 및 접근성 (API Design & Accessibility)**
+    *   **명시적 계약:** 컴포넌트 API는 직관적이고 최소한의 Prop을 유지해야 하며, 부모 상태를 임의로 변이하지 않는 명시적인 계약을 가져야 합니다 [6, 31]. 
+    *   **접근성(A11y) 내장:** 재사용 가능한 컴포넌트 아키텍처는 키보드 탐색, 올바른 ARIA 속성 및 역할 부여, 포커스 관리 등 화면 판독기 지원을 기본적으로 내장해야 합니다 [6, 32-34].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Atomic Design]], [[Compound Components]], [[Headless UI]], [[Design Tokens]], [[Tailwind CSS]], [[Styled Components]], [[Monorepo]], [[Feature-Sliced Design]]
+- **Projects/Contexts:** [[Radix UI]], [[Shopify Polaris]], [[Uber Base Web]], [[Next.js App Router]]
+- **Contradictions/Notes:** 컴파운드 컴포넌트 패턴은 높은 구성 자유도를 제공하지만 과도한 추상화를 유발할 수 있습니다. 레이아웃이 고정되어 있거나 구조가 단순한 컴포넌트(예: 버튼, 아이콘, 배지 등)에는 컴파운드 패턴을 피하고 단순한 Prop 기반 컴포넌트를 사용하는 것이 더 안전하고 유지보수에 유리합니다 [35, 36].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/React Component Patterns.md

@@ -0,0 +1,34 @@
+# [[React Component Patterns]]
+
+## 📌 Brief Summary
+React Component Patterns(리액트 컴포넌트 패턴)은 확장 가능하고 유지보수가 용이한 프론트엔드 애플리케이션을 구축하기 위해 컴포넌트를 구성하고 설계하는 구조적 방법론입니다 [1, 2]. 단순한 속성(Prop) 기반의 경직된 설정에서 벗어나 조합(Composition) 중심의 API로 전환함으로써 Prop Drilling을 줄이고, 높은 재사용성과 유연한 UI를 구현하는 데 목적이 있습니다 [1, 3, 4]. 대표적인 패턴으로는 아토믹 디자인, 컴파운드 컴포넌트, 헤드리스 컴포넌트 등이 있습니다 [2, 5, 6].
+
+## 📖 Core Content
+* **속성 기반(Prop-Driven)에서 조합 중심(Composition-Driven)으로의 전환**
+  초기 컴포넌트는 모든 레이아웃과 동작의 변수를 속성(Prop)으로 전달받지만, 요구사항이 늘어날수록 Prop이 기하급수적으로 증가하며 내부 로직이 강하게 결합되는 '블랙박스' 형태가 되기 쉽습니다 [7-9]. 이를 해결하기 위해, 상태와 동작 규칙만을 컴포넌트가 제공하고 실제 레이아웃과 구조 결정권은 사용자(Consumer)에게 넘기는 조합 중심 패턴이 권장됩니다 [4].
+
+* **아토믹 디자인 (Atomic Design)**
+  UI를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages) 등 5단계의 입자성으로 나누어 구성하는 방법론입니다 [2, 10-12]. 베이스 스타일을 한눈에 파악할 수 있어 디자인 시스템의 일관성을 유지하고 확장에 유리합니다 [5, 13].
+
+* **컴파운드 컴포넌트 (Compound Components)**
+  부모 컴포넌트가 전역 상태를 소유하고, 자식 컴포넌트들이 React Context를 통해 암시적으로 상태를 공유하며 하나의 단위로 협력하는 패턴입니다 [5, 14-16]. HTML의 `<select>`와 `<option>` 태그처럼 동작하며, Prop Drilling 없이 선언적이고 가독성 높은 API를 제공하여 Radix UI 등에서 널리 쓰입니다 [5, 14, 17].
+
+* **헤드리스 컴포넌트 (Headless Components)**
+  상태 관리와 동작 로직만 제공하고 UI(마크업)의 렌더링은 전적으로 사용자에게 위임하는 패턴입니다 [6, 18]. 로직과 시각적 요소가 분리되므로 디자인 시스템이나 프레임워크에 구애받지 않는 높은 재사용성과 접근성을 보장합니다 [6, 19].
+
+* **렌더 프롭스 (Render Props)**
+  함수를 자식(child)으로 전달하여 컴포넌트 간에 로직을 공유하는 기법으로, 렌더링의 세밀한 제어 권한을 소비자에게 부여할 때 유용합니다 [6, 20].
+
+* **오버라이드 패턴 (Overrides Pattern)**
+  Uber의 Base Web 디자인 시스템 등에서 활용되는 방식으로, 컴포넌트 내부의 각 하위 요소들에 식별자를 부여하고 사용자가 `overrides` 속성을 통해 추가적인 prop, 스타일을 전달하거나 컴포넌트 자체를 완전히 교체할 수 있게 합니다 [21-24]. 이를 통해 불필요한 prop 확장을 막고 극단적인 맞춤형 UI 요구사항(Edge cases)을 수용할 수 있습니다 [21, 24].
+
+* **슬롯 / 영역 (Slots / Regions) 및 컨테이너 패턴**
+  헤더, 푸터, 액션 등 의도된 영역을 미리 비워두어 사용자가 자신의 콘텐츠를 끼워 넣을 수 있게 함으로써 Prop 과부하를 피하는 방식입니다 [19]. 또한, 상태 및 데이터를 다루는 로직(Container)과 UI 렌더링(Presentational)을 분리하는 패턴도 Storybook과 같은 환경에서 컴포넌트를 독립적으로 테스트하기 좋게 만듭니다 [25].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Compound Components]], [[Headless Components]], [[Atomic Design]], [[Overrides Pattern]], [[Render Props]], [[Feature-Sliced Design (FSD)]]
+- **Projects/Contexts:** [[Uber Base Web]], [[Radix UI]]
+- **Contradictions/Notes:** 컴파운드 컴포넌트 패턴은 뛰어난 유연성을 제공하지만 사용자가 하위 컴포넌트를 임의로 누락하거나 순서를 변경할 수 있어 UX나 접근성 일관성이 깨질 위험(Too much freedom)이 있습니다. 따라서 명확한 조합 경계와 문서화가 필수적입니다 [26, 27]. 아울러 아토믹 디자인은 시각적 구조화에는 유리하지만 복잡한 비즈니스 로직이나 상태가 엮인 컴포넌트를 분류할 때 한계가 있어, 종종 기능 분할 설계(Feature-Sliced Design, FSD)와 함께 결합되어 사용됩니다 [28].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/React Design Systems.md

@@ -0,0 +1,28 @@
+# [[React Design Systems]]
+
+## 📌 Brief Summary
+React Design Systems(리액트 디자인 시스템)은 재사용 가능한 UI 컴포넌트, 디자인 토큰(Design Tokens), 그리고 체계적인 스타일링 방법론을 결합하여 일관되고 확장 가능한 사용자 인터페이스를 구축하기 위한 프레임워크입니다 [1, 2]. 이 시스템은 아토믹 디자인(Atomic Design)이나 컴파운드 컴포넌트(Compound Components) 같은 아키텍처 패턴을 통해 UI 로직과 비즈니스 로직을 분리합니다 [3-5]. 특히 현대의 React 환경에서는 성능 및 React Server Components(RSC)와의 호환성을 위해 런타임 오버헤드가 있는 CSS-in-JS 방식(Styled Components)과 빌드 타임 최적화를 제공하는 유틸리티 퍼스트 방식(Tailwind CSS) 사이에서 기술적 균형을 맞추는 것이 핵심 과제입니다 [6-8].
+
+## 📖 Core Content
+*   **스타일링 패러다임: Styled Components vs. Tailwind CSS**
+    *   **Styled Components (CSS-in-JS):** 컴포넌트의 상태(props)에 따른 동적 스타일링과 런타임 테마 적용에 매우 유용하며, 스타일이 컴포넌트 라이프사이클과 강력하게 결합됩니다 [9, 10]. 하지만 브라우저에서 JavaScript를 실행해 CSS를 생성하고 주입하기 때문에 CPU 실행 비용(런타임 오버헤드)이 발생하며, 이는 대규모 애플리케이션에서 렌더링 지연(FID, INP 저하)을 유발할 수 있습니다 [9, 11-13]. 또한 React Context에 의존하기 때문에 기본적으로 React Server Components(RSC) 환경과 호환되지 않는 문제가 있어, Next.js 15 환경에서는 별도의 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 등의 도구를 사용하면 토큰을 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:** 컴포넌트의 상태 관리, 키보드 내비게이션, ARIA 속성(접근성) 등 비즈니스 및 상호작용 로직만 제공하고 시각적 스타일링은 완전히 개발자에게 위임하는 패턴입니다 [44-46]. Tailwind CSS와 결합하여 고도의 맞춤형 디자인 시스템을 구축할 때 널리 쓰입니다 [44].
+    *   **오버라이드 패턴(Overrides API):** Uber의 Base Web 등에서 채택한 방식으로, 컴포넌트 내부의 깊은 DOM 요소까지 식별자를 통해 스타일이나 속성, 심지어 내부 컴포넌트 자체를 통째로 교체할 수 있게 허용하여 컴포넌트의 확장성을 극대화합니다 [47-49].
+*   **확장 가능한 프론트엔드 구조와 Monorepo**
+    *   조직 규모가 커질수록 pnpm workspaces, Turborepo, Nx를 활용한 모노레포(Monorepo) 아키텍처가 필수적입니다 [50-52].
+    *   FSD(Feature-Sliced Design) 방법론을 모노레포와 결합하여, `shared`(재사용 UI 및 토큰), `entities`(도메인 구조), `features`(비즈니스 로직) 등의 계층으로 나누고 각 패키지 간의 명시적인 공개 API(Public API)만을 통한 통신을 강제함으로써 의존성 엉킴과 스파게티 코드를 방지합니다 [53-56].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[Design Tokens]], [[Atomic Design]], [[Compound Components]], [[Headless UI]], [[React Server Components]], [[Feature-Sliced Design]]
+- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]]
+- **Contradictions/Notes:** 소스에 따르면 Styled Components 등 CSS-in-JS는 동적 스타일링과 런타임 테마 적용에 매우 강력하지만, CSS 생성에 따른 런타임 성능 오버헤드와 Next.js의 React Server Components(RSC) 환경에서의 제약(직접적인 Context 사용 불가)이라는 단점이 존재합니다 [7-9, 14]. 반면 Tailwind CSS와 같은 유틸리티 퍼스트 접근법은 빌드 타임에 정적 CSS를 생성해 런타임 부하가 없으며 RSC와 완벽히 호환되므로 성능이 중요한 대규모 및 프로덕션 환경에서 더욱 유리하다고 대조하여 설명합니다 [18, 19, 21, 57].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/React Design Tokens.md

@@ -0,0 +1,32 @@
+# [[React Design Tokens]]
+
+## 📌 Brief Summary
+React 프로젝트에서 디자인 토큰(Design Tokens)은 색상, 타이포그래피, 간격, 그림자 등 인터페이스의 핵심 시각적 속성을 중앙 집중화하여 관리하는 원천 데이터(Single Source of Truth)입니다. 하드코딩된 값을 배제하고 JSON이나 YAML과 같은 기계 판독 가능한 형식으로 저장되며, Style Dictionary 등의 도구를 통해 CSS 변수나 테마 객체로 변환되어 React 컴포넌트에 적용됩니다. 이를 통해 디자인의 일관성을 유지하고, 라이트/다크 모드와 같은 동적 테마(Dynamic Theming) 구현 및 확장 가능한 프론트엔드 UI 시스템 구축을 가능하게 합니다.
+
+## 📖 Core Content
+*   **디자인 토큰의 정의와 목적**
+    *   디자인 토큰은 애플리케이션의 시각적 DNA를 구성하는 원자적 데이터 포인트입니다. 
+    *   개발자는 고정된 값(예: `#4A00FF`)을 직접 하드코딩하는 대신 `primary`와 같은 재사용 가능한 토큰을 정의하여 사용합니다. 값이 변경될 때 모든 컴포넌트가 자동으로 업데이트되므로 유지보수성이 크게 향상되며 디자이너와 개발자 간의 공통 언어 역할을 합니다 [1-3].
+
+*   **토큰의 3단계 계층 구조 (Token Hierarchy)**
+    *   확장 가능한 시스템을 구축하기 위해 토큰은 3가지 계층으로 나뉘어 관리됩니다 [4-10].
+    *   **기본 토큰 (Primitive/Reference Tokens):** `#3366FF` 또는 `16px`과 같은 원시적이고 맥락이 없는 기본 값을 의미합니다.
+    *   **시맨틱 토큰 (Semantic/Alias Tokens):** 기본 토큰을 참조하며, `color.primary`나 `button.background`처럼 토큰의 목적과 의도를 나타냅니다. 테마(라이트/다크 모드) 전환 시 컴포넌트 코드를 수정할 필요 없이 시맨틱 토큰이 가리키는 기본 값만 교체하여 테마를 구현합니다.
+    *   **컴포넌트 토큰 (Component Tokens):** `button.background.primary`와 같이 특정 컴포넌트나 변형(variant)에 국한된 토큰으로, 시맨틱 토큰을 참조해야 합니다.
+
+*   **React 애플리케이션에서의 구현 (Implementation Pipeline)**
+    *   **디자인 도구 통합:** Figma의 Tokens Studio와 같은 플러그인을 사용하여 디자이너가 설정한 시각적 결정들을 JSON 데이터 구조로 추출합니다 [11-14].
+    *   **토큰 변환:** Style Dictionary 또는 Knapsack과 같은 변환 도구를 사용하여 JSON/YAML 형태의 토큰을 React에서 사용할 수 있는 CSS 변수(Custom Properties) 또는 JS 객체 포맷으로 자동 변환합니다 [15-17].
+    *   **React 통합:** 생성된 CSS 변수를 `index.css`와 같은 최상위 스타일에 정의한 뒤, React 컴포넌트 내부에서 인라인 스타일, CSS Modules, styled-components, 또는 Tailwind CSS와 결합하여 사용합니다 [15, 18, 19].
+
+*   **최신 트렌드: Tailwind CSS v4의 CSS-First 접근**
+    *   2025/2026년 기준, Tailwind CSS v4는 자바스크립트 설정 파일(`tailwind.config.js`) 대신 CSS `@theme` 디렉티브를 사용하여 디자인 토큰을 선언합니다 [20-22].
+    *   이 접근법은 디자인 토큰을 네이티브 CSS 변수로 직접 노출시키며, Tailwind는 이 변수들을 바탕으로 유틸리티 클래스(예: `--color-primary-500` 선언 시 `bg-primary-500` 자동 생성)를 생성하여 런타임 오버헤드 없이 빠른 성능을 제공합니다 [21, 23].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Tailwind CSS]], [[styled-components]], [[Dynamic Theming]], [[Atomic Design]], [[CSS-in-JS]]
+- **Projects/Contexts:** [[Style Dictionary]], [[Figma Tokens Studio]], [[React Server Components]]
+- **Contradictions/Notes:** 소스 [15]와 [19]은 디자인 토큰을 기반으로 생성된 CSS 변수를 styled-components와 같은 런타임 CSS-in-JS 라이브러리에 묶어서 사용하는 방식을 설명하지만, 소스 [24-27]와 [28-30]은 React Server Components(RSC) 환경에서는 런타임 CSS-in-JS의 성능 및 호환성 문제로 인해 Tailwind CSS나 CSS Modules처럼 빌드 타임에 정적 CSS를 생성하는 방식(Zero-runtime)으로 전환하는 것을 강력히 권장합니다.
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/React Server Components (RSC).md

@@ -0,0 +1,18 @@
+# [[React Server Components (RSC)]]
+
+## 📌 Brief Summary
+React Server Components(RSC)는 브라우저가 아닌 서버에서 배타적으로 실행되며(빌드 타임 또는 요청 시) 클라이언트로 JavaScript를 전송하지 않고 HTML을 스트리밍하는 컴포넌트입니다 [1, 2]. 브라우저 API 및 React Context에 대한 접근이 불가능하기 때문에, 기존 런타임 CSS-in-JS 라이브러리의 호환성 문제를 발생시키며 프론트엔드 스타일링 및 컴포넌트 아키텍처에 근본적인 변화를 가져왔습니다 [1-4].
+
+## 📖 Core Content
+- **서버 전용 실행 및 성능 최적화:** RSC는 서버에서 실행되므로 클라이언트로 JavaScript 번들을 보내지 않습니다 [2]. 데이터베이스 쿼리와 같은 비즈니스 로직을 브라우저에 노출하지 않고 직접 처리하여 보안을 유지하며, 클라이언트의 자원 부담을 최소화합니다 [2].
+- **스타일링 아키텍처에 미치는 영향:** RSC 환경에서는 React Context를 사용할 수 없기 때문에, `ThemeProvider`와 같이 Context에 의존하는 기존의 런타임 CSS-in-JS(예: styled-components, Emotion)는 서버 컴포넌트 환경에서 기본적으로 호환되지 않습니다 [1, 3-5]. 이로 인해 런타임 오버헤드가 없는 Tailwind CSS나 빌드 타임에 정적 CSS를 생성하는 vanilla-extract 같은 접근 방식이 현대 프론트엔드 아키텍처에서 선호되는 추세입니다 [1].
+- **styled-components의 RSC 지원 및 Style Registry:** 이러한 한계를 극복하기 위해 Next.js 15에서는 렌더링 중 CSS 규칙을 수집하여 주입하는 'Style Registry' 패턴을 도입했습니다 [6]. 또한 `styled-components`는 v6.3.0부터 RSC 환경을 자동 감지하여 `'use client'` 지시어 없이도 인라인 `<style>` 태그를 방출하도록 업데이트되었으며 [7], RSC에서 작동하지 않는 `ThemeProvider` 대신 CSS 커스텀 속성(CSS custom properties)을 활용하는 `createTheme` 헬퍼 함수를 통한 테마 적용을 권장합니다 [5, 7, 8].
+- **컴포넌트 합성(Composition) 및 설계 패턴:** 보편적인 설계 패턴은 서버 컴포넌트가 데이터를 패칭하고, 상호작용이 필요한 부분만을 `'use client'` 지시어가 선언된 클라이언트 컴포넌트(Client Component)로 분리하는 방식입니다 [9, 10]. 또한 서버 컴포넌트를 클라이언트 컴포넌트의 하위(`children`)나 `props`로 전달하여 서버 측 데이터 패칭 이점을 유지하는 합성 패턴이 효과적입니다 [11]. RSC에서 동적 스타일링이 필요한 경우, 직렬화(serialization) 오버헤드를 피하기 위해 동적 보간(interpolation)보다는 데이터 속성(data attributes, 예: `data-size='lg'`)과 정적 스타일을 사용하는 것이 모범 사례로 꼽힙니다 [7, 12].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[Client Components]]
+- **Projects/Contexts:** [[Next.js 15 App Router]], [[styled-components v6.3+]]
+- **Contradictions/Notes:** 런타임 CSS-in-JS 라이브러리는 기본적으로 RSC 환경(Context 부재)과 호환되지 않는다는 근본적인 한계가 제기되나 [3, 4], 최근의 `styled-components` 업데이트(v6.3.0 이상)에서는 인라인 스타일 주입 및 CSS 변수를 활용한 테마 적용 방식으로 이를 우회하여 RSC를 지원하고 있습니다 [7, 8].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/React Server Components.md

@@ -0,0 +1,18 @@
+# [[React Server Components]]
+
+## 📌 Brief Summary
+React Server Components(RSC)는 브라우저가 아닌 서버에서만 독점적으로 렌더링되어 클라이언트로 JavaScript 번들을 전송하지 않는 React의 혁신적인 렌더링 아키텍처입니다 [1]. 이 환경에서는 React Context에 대한 접근이 불가능하기 때문에 기존의 런타임 기반 스타일링 도구와의 호환성 문제를 야기했으며, 프론트엔드의 스타일링 패러다임에 큰 변화를 가져왔습니다 [2, 3]. 결과적으로 확장 가능한 프론트엔드 아키텍처를 구축하려면 서버와 클라이언트 컴포넌트의 역할을 명확히 분리하고 RSC 환경에 최적화된 스타일링 전략을 채택하는 것이 필수적입니다 [4, 5].
+
+## 📖 Core Content
+* **RSC의 동작 원리와 컴포넌트 구성**: 서버 컴포넌트는 완전히 서버에서 실행되어 데이터베이스에 직접 접근할 수 있으며, 렌더링된 정적 HTML만을 클라이언트에 전달하므로 성능 최적화와 보안 유지에 탁월합니다 [1]. 반면, 컴포넌트에 상태(state)나 이벤트 핸들러 같은 브라우저 상호작용이 필요한 경우에 한해 `'use client'` 지시어를 명시하여 클라이언트 컴포넌트로 분리해야 합니다 [6]. 모범적인 아키텍처 구성을 위해서는 데이터 패칭을 서버 컴포넌트에서 처리하고 상호작용이 필요한 최소한의 영역만 클라이언트 컴포넌트로 유지해야 합니다 [5, 7].
+* **기존 CSS-in-JS 아키텍처와의 마찰**: RSC의 서버 전용 렌더링 환경은 기존 프론트엔드 생태계에 큰 영향을 미쳤습니다. 특히 `styled-components`나 `Emotion`과 같은 런타임 CSS-in-JS 라이브러리는 테마 주입을 위해 내부적으로 React Context에 크게 의존하는데, RSC 환경에는 React Context가 존재하지 않으므로 구조적인 비호환성(incompatibility)이 발생합니다 [2, 3, 8].
+* **현대적인 스타일링 및 렌더링 전략**: 위와 같은 호환성 문제로 인해 현재 Next.js App Router를 비롯한 RSC 환경에서는 런타임 오버헤드가 없는 빌드 타임 스타일링 방식이 강력히 권장됩니다 [2, 9]. 정적 CSS를 생성하는 `Tailwind CSS`, `CSS Modules` 또는 Zero-runtime CSS-in-JS인 `vanilla-extract`를 도입하는 것이 성능을 향상시키고 복잡성을 줄이는 핵심 전략입니다 [3, 4, 9]. RSC 환경에서는 수많은 고유 클래스를 런타임에 동적으로 생성하기보다, 정적인 스타일을 유지하되 데이터 속성(`data-*` attributes)을 변경하여 상태 변형을 제어하는 방식이 성능 최적화에 유리합니다 [10].
+* **Styled-components의 RSC 지원 및 우회 방식**: 완전한 대안으로 전환하지 못하는 프로젝트를 위해 `styled-components`는 v6.3.0부터 RSC 환경을 자동 감지하는 패치를 적용했습니다 [11]. RSC 환경에서는 `ThemeProvider`가 아무 동작도 하지 않는 패스스루(no-op)로 변하기 때문에, 이를 대체할 수 있도록 CSS Custom Properties(변수) 기반의 테마를 생성하는 `createTheme` 헬퍼 함수를 사용할 것을 권장합니다 [12, 13]. 또한 SSR 시 스타일이 유실되지 않도록 서버에서 렌더링 중 CSS를 수집하여 삽입하는 `Style Registry` 패턴을 구성해야 하며, 인라인 스타일 태그 삽입으로 인해 깨질 수 있는 자식 인덱스 선택자 문제(`:first-child` 등)를 방지하기 위한 `stylisPluginRSC` 플러그인도 함께 제공됩니다 [14, 15].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Tailwind CSS]], [[Styled-components]], [[CSS-in-JS]], [[Zero-runtime CSS]]
+- **Projects/Contexts:** [[Next.js App Router]]
+- **Contradictions/Notes:** 소스 [2, 3, 8]에서는 `styled-components` 등 런타임 CSS-in-JS가 React Context 부재로 인해 RSC와 근본적으로 호환되지 않으므로 Next.js App Router 환경에서 피해야 한다고 설명합니다. 하지만 소스 [11-14]에 따르면, `styled-components`는 최신 업데이트를 통해 RSC 환경을 스스로 감지하고 Context 의존을 탈피하여 CSS Custom Properties를 사용하는 새로운 API 및 자동 스타일 인라인 주입 기능으로 RSC 환경에서의 사용을 계속해서 지원하고 있습니다.
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Reusable UI Component Libraries.md

@@ -0,0 +1,41 @@
+# [[Reusable UI Component Libraries]]
+
+## 📌 Brief Summary
+재사용 가능한 UI 컴포넌트(Reusable UI Component) 라이브러리는 현대 React 애플리케이션의 뼈대 역할을 하는 '레고 블록'과 같은 요소로, 이식성(Portable)과 예측 가능성(Predictable), 그리고 목적성(Purposeful)을 갖추도록 설계됩니다 [1, 2]. 잘 설계된 컴포넌트 시스템은 일관된 사용자 경험을 제공하고 개발 시간을 단축하며, 단일 책임 원칙과 디자인 토큰 기반의 유연한 스타일링을 통해 확장 가능하고 유지보수가 용이한 프론트엔드 아키텍처를 구축하는 데 핵심적인 역할을 합니다 [1, 3-6].
+
+## 📖 Core Content
+
+**1. 재사용 가능한 컴포넌트의 4가지 핵심 원칙**
+* **단일 책임 원칙 (Single Responsibility):** 각 컴포넌트는 한 가지 목적만 잘 수행해야 하며, 관련 없는 복잡한 로직(예: 복잡한 데이터 페칭 등)을 짊어져서는 안 됩니다 [4, 7].
+* **상속보다 합성 (Composition Over Inheritance):** 의견이 배제된(unopinionated) 작은 기본 컴포넌트들을 합성하여 더 큰 구조를 만들어야 합니다 [4].
+* **명시적 계약 (Explicit Contracts):** 입력(props)과 출력(callbacks/events)을 명확하게 정의하고, 설정 범위를 최소화하여 잘못 사용할 여지를 줄여야 합니다(prop soup 지양) [4, 8].
+* **접근성 우선 (Accessibility First):** 키보드 탐색, 탭 순서, 올바른 ARIA 역할 및 스크린 리더 지원이 기본적으로 내장되어야 합니다 [4, 9].
+
+**2. 상태 관리 및 API 설계**
+* 컴포넌트의 API는 사용 목적을 명확히 드러내는 이름으로 구성되어야 하며, 합리적인 기본값(Sensible Defaults)을 제공해야 합니다 [8].
+* 내부 상태(Internal State)는 툴팁 표시와 같은 국소적인 UI 상태로 제한해야 합니다. 비즈니스 로직이나 여러 컴포넌트를 조절해야 하는 상태는 부모 컴포넌트로 끌어올리고(State Hoisting), 콜백을 통해 변경 사항을 알려야 합니다 [10]. 
+
+**3. 확장 가능한 아키텍처 패턴**
+* **복합 컴포넌트 (Compound Components):** `Accordion.Item`, `Accordion.Header`와 같이 여러 하위 컴포넌트가 React Context를 통해 암시적으로 상태를 공유하는 패턴입니다. 부모 컴포넌트에서 과도하게 Prop을 내려보내는(Prop drilling) 문제를 해결하고 매우 유연한 구성을 가능하게 합니다 [11-13].
+* **헤드리스 컴포넌트 (Headless Components):** UI 마크업이나 스타일링을 배제하고 상태 및 동작 로직만 제공하는 패턴으로, 높은 커스터마이징이 필요할 때 이상적입니다 [14, 15].
+* **오버라이드 패턴 (Overrides Pattern):** 특정 컴포넌트 내부의 하위 요소들을 식별자를 통해 노출하여, 사용자가 쉽게 추가적인 속성이나 스타일을 주입하거나 요소를 통째로 교체할 수 있게 하는 API 설계 방식입니다(예: Uber의 Base Web) [16-18].
+* **아토믹 디자인 (Atomic Design):** UI를 원자(Atoms), 분자(Molecules), 유기체(Organisms), 템플릿(Templates), 페이지(Pages) 단위로 점진적으로 결합하여 구성하는 방법론으로 시각적 일관성을 높입니다 [19-21].
+
+**4. 스타일링 및 디자인 토큰 통합**
+* 브랜드의 룩앤필을 하드코딩하지 않기 위해 **디자인 토큰(Design Tokens)**(색상, 간격, 타이포그래피)을 사용하여 스타일을 구성해야 합니다 [5]. 
+* 3단계의 토큰 계층(Base/Primitive, Semantic, Component-specific)을 활용하고 이를 CSS 변수로 변환하면, 애플리케이션의 테마(라이트/다크 모드 등)를 컴포넌트 수정 없이 동적으로 전환할 수 있습니다 [22-25]. 
+* 기술적으로는 런타임 비용이 없는 Tailwind CSS 기반의 유틸리티 방식이 높은 성능을 내며 [26, 27], Styled-Components와 같은 CSS-in-JS는 컴포넌트 레벨의 동적 스타일링에 강력하지만 서버 사이드 렌더링 환경에서는 복잡성이 추가될 수 있습니다 [28, 29].
+
+**5. 확장 가능한 프론트엔드 인프라 (모노레포)**
+* 컴포넌트 라이브러리가 여러 애플리케이션에서 공유될 때, **모노레포(Monorepo)**(예: pnpm workspaces, Turborepo, Nx) 아키텍처를 도입하는 것이 권장됩니다 [30-32]. 
+* FSD(Feature-Sliced Design) 아키텍처 방법론을 함께 도입하여 기능(Feature)이나 공유 원시 컴포넌트(Shared) 사이에 딥 임포트(deep imports)를 금지하고 명확한 Public API 인터페이스 규칙을 강제해야 모듈의 응집도를 유지할 수 있습니다 [33, 34].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Compound Components]], [[Atomic Design]], [[Design Tokens]], [[Tailwind CSS]], [[Styled Components]], [[React Server Components (RSC)]], [[Feature-Sliced Design (FSD)]]
+- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]], [[Radix UI]]
+- **Contradictions/Notes:** 
+  - 복합 컴포넌트(Compound Components) 패턴은 조립의 자유도를 극대화하지만 로직이 여러 컨텍스트 및 Render Props에 분산되어 디버깅이 어려울 수 있습니다. 따라서 레이아웃이 고정되어 있거나 버튼, 배지처럼 단순한 요소에 도입하는 것은 과도한 추상화(Over-engineering)가 되므로 피해야 합니다 [35-37]. 
+  - Tailwind CSS(유틸리티 퍼스트)와 Styled-Components(CSS-in-JS)는 스타일링 패러다임 측면에서 충돌합니다. Tailwind는 빌드 시점에 정적 CSS를 생성해 React Server Components(RSC) 환경 및 성능 최적화에 뛰어나지만 JSX 마크업이 지저분해질 수 있습니다 [38-40]. 반면 Styled-Components는 훌륭한 캡슐화와 동적 Prop 스타일링을 제공하지만 런타임 시 자바스크립트 실행으로 인한 오버헤드가 발생하며, RSC 환경을 온전히 지원하기 위해 별도의 스타일 레지스트리 패턴 설정이 강제됩니다 [40-43].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Scalable Design Systems.md

@@ -0,0 +1,31 @@
+# [[Scalable Design Systems]]
+
+## 📌 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*

10_Wiki/Topics_Art/UI_UX_Assets/Scalable Frontend Design Systems.md

@@ -0,0 +1,29 @@
+# [[Scalable Frontend Design Systems]]
+
+## 📌 Brief Summary
+확장 가능한 프론트엔드 디자인 시스템(Scalable Frontend Design Systems)은 다수의 프로젝트와 플랫폼 전반에서 일관되고 유지보수가 용이한 사용자 인터페이스를 구축하기 위한 아키텍처 및 방법론의 집합입니다. 디자인 토큰(Design Tokens)을 기반으로 시각적 속성을 중앙 집중화하고, Tailwind CSS나 Styled-Components와 같은 스타일링 패러다임을 적용하여 재사용성을 극대화합니다 [1, 2]. 또한, 아토믹 디자인(Atomic Design), 복합 컴포넌트(Compound Components), 그리고 모노레포(Monorepo) 아키텍처를 결합하여 컴포넌트의 독립성을 유지하면서 대규모 확장성을 지원하는 것이 핵심입니다 [3-5].
+
+## 📖 Core Content
+- **디자인 토큰과 테마 확장성 (Design Tokens & Theming)**
+  시스템의 일관성을 보장하는 핵심은 **디자인 토큰**입니다. 토큰은 원시 값(Primitive Tokens, 예: `#3366FF`), 의미 기반 토큰(Semantic Tokens, 예: `color.primary`), 그리고 컴포넌트 특화 토큰으로 계층화되어 관리됩니다 [1, 6-8]. 이 계층 구조는 다크 모드와 같은 동적 테마 전환을 수월하게 만들며, Style Dictionary 등의 도구를 사용하면 Figma의 디자인 데이터를 React의 CSS 변수나 테마 객체로 자동 동기화할 수 있어 개발과 디자인 간의 간극을 좁힙니다 [9-11].
+
+- **스타일링 패러다임: Tailwind CSS vs Styled-Components**
+  React 생태계의 스타일링 접근법은 런타임 성능과 개발자 경험의 균형을 맞추는 방향으로 발전하고 있습니다.
+  - **Tailwind CSS:** 유틸리티 퍼스트(Utility-first) 방식으로 런타임 오버헤드가 없으며, 5-20kb 수준의 작은 번들 크기를 유지할 수 있습니다 [12, 13]. 특히 v4 버전부터는 `@theme` 디렉티브를 사용하는 CSS-first 아키텍처를 도입하여 빌드 속도가 10배 향상되었으며, 네이티브 CSS 변수를 활용하여 더욱 강력한 테마 기능을 제공합니다 [14, 15]. 런타임 컨텍스트가 없는 **React Server Components(RSC) 및 Next.js App Router에 매우 적합**하지만, 클래스명이 길어지는 '클래스 스프(class soup)' 문제를 피하기 위해 컴포넌트 추출 규율이 필요합니다 [16, 17].
+  - **Styled-Components:** JavaScript 파일 내에서 컴포넌트와 스타일을 함께 관리하는 CSS-in-JS 라이브러리로, Prop에 기반한 동적 스타일링에 강력합니다 [18]. 하지만 실행 시점에 CSS를 생성하고 주입하는 과정에서 **CPU 및 런타임 성능 오버헤드**가 발생하며, React Context를 사용하기 때문에 RSC 환경과 근본적인 호환성 문제(Next.js 15에서는 Style Registry 패턴으로 우회 지원)를 겪습니다 [13, 19, 20].
+
+- **재사용 가능한 컴포넌트 아키텍처 (Component Architecture)**
+  - **아토믹 디자인 (Atomic Design):** UI를 가장 작은 단위인 원자(Atoms)에서 시작해 분자(Molecules), 유기체(Organisms), 템플릿, 페이지로 결합하는 방식입니다 [3, 21, 22]. 이는 UI의 일관성을 높이지만, 복잡한 비즈니스 로직을 다룰 때는 유연성이 떨어질 수 있습니다 [23].
+  - **복합 컴포넌트 (Compound Components):** `Accordion.Item`, `Accordion.Header`처럼 여러 하위 컴포넌트가 하나의 상태를 Context를 통해 공유하는 패턴입니다 [24, 25]. 이 패턴은 소비자가 UI 레이아웃을 자유롭게 구성할 수 있도록 높은 유연성을 제공하며 불필요한 Prop Drilling을 방지합니다 [4, 26, 27].
+  - **Headless UI 및 Overrides 패턴:** 상태 관리 및 접근성 로직만 제공하고 시각적 스타일링은 완전히 분리하는 Headless 컴포넌트 패턴과, 내부 하위 요소의 속성이나 스타일을 주입 및 교체할 수 있게 하는 Uber Base Web의 Overrides API 패턴이 복잡하고 확장 가능한 UI 라이브러리 구축에 활용됩니다 [28-30].
+
+- **대규모 확장을 위한 모노레포 및 폴더 구조 (Monorepo & Organization)**
+  다수의 앱과 공유 라이브러리를 단일 저장소에서 관리할 때 **모노레포(Monorepo)**가 사용됩니다 [5]. pnpm workspaces나 Turborepo, Nx 등의 도구를 사용해 종속성을 관리하고 CI/CD 빌드 캐싱을 최적화합니다 [31-33]. 모노레포 내부의 스파게티 코드를 막기 위해, Shared, Entities, Features 등으로 계층을 나누어 하위 계층이 상위 계층을 참조하지 못하게 하는 **Feature-Sliced Design (FSD)** 방법론을 적용하는 것이 권장됩니다 [34, 35].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Design Tokens]], [[Tailwind CSS]], [[Styled-Components]], [[React Server Components (RSC)]], [[Atomic Design]], [[Compound Components]], [[Monorepo Architecture]], [[Feature-Sliced Design]]
+- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]], [[Style Dictionary]], [[Next.js App Router]]
+- **Contradictions/Notes:** 스타일링 접근 방식에 있어 명확한 트레이드오프가 존재합니다. Styled-Components는 캡슐화와 Prop 기반의 동적 스타일링 측면에서 뛰어난 개발자 경험을 제공하지만 런타임 성능 오버헤드 및 RSC 비호환 문제를 가집니다. 반면, Tailwind CSS는 제로 런타임 오버헤드와 RSC 환경에 최적화된 높은 성능을 자랑하지만, 마크업에 유틸리티 클래스가 누적되어 코드 가독성이 떨어질 수 있습니다. 성능 최적화가 필수적인 대규모 엔터프라이즈 환경에서는 CSS-in-JS에서 Tailwind CSS와 같은 정적/유틸리티 퍼스트 방식으로 마이그레이션하는 추세가 확인됩니다.
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Server Components.md

@@ -0,0 +1,29 @@
+# [[Server Components]]
+
+## 📌 Brief Summary
+React Server Components(RSC)는 빌드 타임 또는 요청 시에 서버에서만 독점적으로 실행되고 클라이언트로 JavaScript를 전송하지 않는 React의 렌더링 아키텍처입니다 [1]. Next.js App Router와 함께 본격적으로 도입되어 프론트엔드 생태계에 큰 변화를 가져왔으며, 특히 React Context에 의존하는 기존 CSS-in-JS 라이브러리들과의 호환성 문제를 발생시켜 Tailwind CSS와 같은 제로 런타임(zero-runtime) 또는 유틸리티 우선(utility-first) 스타일링 패러다임으로의 전환을 가속화하는 핵심 요인이 되었습니다 [2-4].
+
+## 📖 Core Content
+* **RSC의 동작 방식과 특징:**
+  Server Components는 브라우저로 JavaScript를 보내지 않고 정적으로 렌더링된 HTML만을 전송합니다 [1]. 데이터베이스에서 직접 데이터를 가져오는 등의 서버 로직을 안전하게 처리할 수 있으며, 상호작용(상태 관리, 이벤트 핸들러 등)이나 브라우저 API가 필요한 경우에만 명시적으로 `'use client'` 지시어를 사용하여 클라이언트 컴포넌트(Client Components)를 렌더링하는 컴포지션 패턴을 사용합니다 [1, 5]. 이로 인해 클라이언트 측 번들 크기가 대폭 줄어들고 성능이 향상됩니다 [6].
+
+* **CSS-in-JS 스타일링 라이브러리와의 호환성 한계:**
+  RSC 환경에서는 브라우저 환경과 React Context가 존재하지 않습니다 [3, 7]. 따라서 테마 관리를 위해 React Context에 강하게 의존하던 Styled Components나 Emotion과 같은 런타임 기반 CSS-in-JS 라이브러리들은 RSC와 근본적으로 호환되지 않는 문제를 겪습니다 [2, 3, 7]. Next.js App Router와 같은 환경에서 기존의 런타임 CSS-in-JS를 사용하는 것은 하이드레이션(hydration) 불일치 및 성능 병목 현상을 유발할 수 있습니다 [2, 8].
+
+* **RSC 환경에서의 스타일링 모범 사례:**
+  * **제로 런타임 스타일링 권장:** 런타임 오버헤드가 없고 서버 컨텍스트를 요구하지 않는 Tailwind CSS나 CSS Modules, vanilla-extract 같은 정적 CSS 생성 방식이 RSC와 완벽하게 호환되므로 새로운 프로젝트에서 강력히 권장됩니다 [3, 9, 10]. 
+  * **정적 스타일과 데이터 속성(Data attributes) 활용:** 프로퍼티 변화에 따라 매번 새로운 클래스를 동적으로 생성하는 대신, 정적 스타일을 선언하고 이산적인 변형(variants)에 대해서는 `&[data-size='lg']`와 같은 데이터 속성(data attributes)을 활용하여 상태를 토글하는 것이 RSC 환경의 최적화 모범 사례입니다 [8, 11].
+
+* **Styled Components의 RSC 지원 대응:**
+  Styled Components는 v6.3.0 이상부터 별도의 `'use client'` 지시어 없이도 RSC 환경을 자동 감지하고 호환성을 제공하도록 업데이트되었습니다 [11]. 
+  * RSC 환경에서는 `ThemeProvider`와 `StyleSheetManager`가 컨텍스트가 없기 때문에 아무 동작도 하지 않는(no-op) 통과 컴포넌트가 됩니다 [11, 12].
+  * 테마를 위해서는 React Context 대신 CSS 커스텀 속성(CSS custom properties/variables)으로 변환해 주는 `createTheme` 헬퍼 함수를 사용하는 것이 권장됩니다 [11, 13].
+  * Next.js App Router 환경에서는 렌더링 중 CSS 규칙을 수집하여 HTML 헤드에 주입하는 'Style Registry 패턴'(`useServerInsertedHTML` 활용)을 통해 SSR 하이드레이션 문제를 해결합니다 [14].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[Styled Components]]
+- **Projects/Contexts:** [[Next.js App Router]]
+- **Contradictions/Notes:** 소스에 따르면 기존 CSS-in-JS의 테마 제공 방식(`ThemeProvider`)은 React Context를 필수적으로 요구하기 때문에 서버 컴포넌트 환경에서는 동작하지 않습니다. 따라서 RSC 환경에서 테마를 구현하려면 Context 기반이 아닌 순수 CSS 변수(CSS Variables) 기반의 테마 구현 방식으로 접근법을 바꿔야 합니다 [11-13].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Styled Components v6.md

@@ -0,0 +1,18 @@
+# [[Styled Components v6]]
+
+## 📌 Brief Summary
+Styled Components v6는 React 프로젝트에서 널리 사용되는 CSS-in-JS 라이브러리의 주요 메이저 업데이트 버전입니다 [1, 2]. 이 버전은 TypeScript로 완전히 재작성되고 내부 CSS 파서로 Stylis v4를 채택하여 구조적인 혁신을 이루었습니다 [3, 4]. 또한 자동 Prop 필터링을 제거하고 Transient Props(`$`)를 도입했으며 [3, 5], 최신 업데이트(v6.3.0 이상)를 통해 React Server Components(RSC) 환경을 기본적으로 지원하여 런타임 테마의 한계를 극복하는 데 중점을 두었습니다 [6, 7].
+
+## 📖 Core Content
+* **TypeScript 기반 재작성 및 내장 타입 지원:** v6는 TypeScript로 완전히 재작성되어 라이브러리 자체에서 타입 정의를 제공합니다 [2, 4]. 따라서 기존 버전에서 필요했던 `@types/styled-components` 패키지를 더 이상 설치할 필요가 없으며 [3, 8], `CSSProp`과 CSS 사용자 지정 속성(CSS Variables)에 대한 TypeScript 지원이 강화되었습니다 [9, 10].
+* **스타일링 및 Prop 전달 메커니즘 변경:** 과거 버전에서 제공되던 자동 Prop 필터링 기능이 제거되었습니다 [3]. 대신 하위 React 노드나 DOM 요소로 전달되지 않기를 원하는 스타일링 전용 Prop에는 달러 기호(`$`)를 접두사로 사용하는 'Transient props'를 사용해야 합니다 [3, 5, 11]. 또한 `shouldForwardProp` API를 통해 어떤 Prop이 하위 컴포넌트로 전달될지 세밀하게 제어할 수 있습니다 [12, 13].
+* **React Server Components (RSC) 통합:** v6.3.0 버전부터는 `'use client'` 지시어 없이도 React Server Components 환경에서 작동하도록 기본 지원이 추가되었습니다 [7]. RSC 환경에서는 React Context를 사용할 수 없기 때문에 `ThemeProvider`와 `StyleSheetManager`는 아무런 동작을 하지 않는 패스스루(no-op) 컴포넌트로 작동합니다 [7, 14, 15]. 이를 해결하기 위해 v6.4.0에서는 `createTheme` 헬퍼 함수를 도입하여 React Context 대신 CSS 사용자 지정 속성(CSS Variables)을 활용해 클라이언트와 서버 환경 모두에서 안정적으로 작동하는 테마 기능을 제공합니다 [16]. 또한 RSC 모드에서는 인라인 `<style>` 태그를 자동으로 삽입하여 스타일을 전달합니다 [6, 7].
+* **API 정리 및 엔진 변경:** 구버전의 `$as` 및 `$forwardedAs` prop은 제거되었고, `as` 및 `forwardedAs` prop으로 완전히 대체되었습니다 [3, 8]. 또한 `disableVendorPrefixes` 속성이 `enableVendorPrefixes`로 교체되어, 이전 브라우저 지원을 위한 자동 벤더 프리픽스(vendor prefixing) 기능이 기본적으로 비활성화되었습니다 [3]. 내부 CSS 파서 엔진은 stylis v4로 업그레이드되었습니다 [3, 4].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[CSS-in-JS]], [[React Server Components]], [[Transient Props]], [[Tailwind CSS]]
+- **Projects/Contexts:** [[Next.js App Router]], [[Scalable Frontend Architecture]]
+- **Contradictions/Notes:** 소스에 포함된 일부 아티클은 Styled Components가 React Context에 의존하기 때문에 React Server Components(RSC) 환경과 근본적으로 호환되지 않아 Next.js App Router 프로젝트에 부적합하다고 주장합니다 [17-19]. 그러나 Styled Components의 공식 릴리스 노트에 따르면 v6.3.0부터 RSC 환경을 공식 지원하며 [7], v6.4.0의 `createTheme`을 통한 CSS 변수 접근 방식을 사용하여 Context 부재로 인한 런타임 한계를 구조적으로 극복하고 있습니다 [6, 7, 16].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Styled Components.md

@@ -0,0 +1,20 @@
+# [[Styled Components]]
+
+## 📌 Brief Summary
+Styled Components는 React 및 Next.js 환경에서 사용되는 대표적인 CSS-in-JS 라이브러리로, 자바스크립트 파일 내에서 태그된 템플릿 리터럴(tagged template literals)을 사용하여 CSS를 직접 작성할 수 있게 해줍니다 [1, 2]. 이 방식은 컴포넌트와 스타일 코드를 같은 곳에 위치(co-location)시키고 자동으로 고유한 클래스명을 생성하여 스타일의 전역 충돌을 방지합니다 [3, 4]. 프롭스(props)와 상태(state)를 기반으로 한 동적 스타일링에 매우 강력하지만, 런타임 CSS 생성으로 인한 성능 오버헤드와 최근의 React Server Components(RSC) 환경에서의 호환성 처리라는 과제를 안고 있습니다 [4-6].
+
+## 📖 Core Content
+* **동적 스타일링 및 테마 시스템**: Styled Components는 프롭스와 상태, 그리고 테마를 활용해 자연스러운 동적 스타일링을 가능하게 합니다 [4, 6]. 라이브러리에 내장된 `ThemeProvider`는 Context API를 통해 앱 하위의 모든 컴포넌트에 테마를 주입할 수 있어 다크 모드나 다중 브랜드 테마를 구축하는 데 유용합니다 [4, 7].
+* **주요 컴포넌트 API**: 
+  * **`as` 프롭스**: 컴포넌트에 적용된 스타일은 그대로 유지하면서, 런타임에 렌더링되는 실제 HTML 태그나 React 컴포넌트를 변경할 수 있는 다형성(polymorphism)을 제공합니다 [8].
+  * **트랜지언트 프롭스 (Transient props)**: 스타일링 컴포넌트 전용으로 사용되며 실제 DOM 노드에는 전달되지 않기를 원하는 프롭스의 경우, 이름 앞에 달러 기호(`$`)를 붙여 필터링할 수 있습니다 [9, 10].
+* **성능 및 번들 사이즈의 한계**: 런타임에 CSS 문자열을 생성하고 브라우저에 주입해야 하기 때문에 CPU 및 JavaScript 실행 비용(런타임 텍스)이 발생합니다 [4, 6]. 라이브러리 추가로 인해 번들 사이즈가 약 30kb(gzipped) 증가하며, 대규모 렌더링(예: 10,000개 리스트 아이템) 시 빌드 타임 기반의 Tailwind CSS(85ms)보다 렌더링 시간(148ms)이 더 오래 걸리는 등 성능 최적화 면에서 한계를 보입니다 [5, 6, 11].
+* **React Server Components (RSC) 호환성과 Next.js 통합**: Styled Components의 테마 기능은 React Context에 의존하므로, Context가 없는 서버 컴포넌트(RSC) 환경에서는 기본적으로 작동하지 않습니다 [12, 13]. Next.js 15의 App Router에서 사용하기 위해서는 렌더링 중 CSS 규칙을 수집하여 `<head>`에 주입하는 '스타일 레지스트리(Style Registry) 패턴'을 적용해야 합니다 [14]. 또한 서버와 클라이언트 간의 하이드레이션(Hydration) 불일치를 막기 위해 컴파일러 설정(`styledComponents`)을 활성화해야 합니다 [15]. 최신 버전(v6.3.0 이상)에서는 RSC 환경에서 자동으로 인라인 `<style>` 태그를 방출하여 React 19의 호이스팅 및 중복 제거 기능을 지원하도록 업데이트되었습니다 [16].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[CSS-in-JS]], [[Tailwind CSS]], [[React Server Components]], [[Dynamic Theming]]
+- **Projects/Contexts:** [[Next.js App Router]], [[Component Library Architecture]]
+- **Contradictions/Notes:** 소스 [6, 17, 18] 및 [19]는 런타임 비용이 없는 Tailwind CSS가 대규모 프로덕션이나 Core Web Vitals(FID, INP 등) 최적화에 훨씬 뛰어나며, App Router 환경에서는 Tailwind나 CSS Modules를 사용하는 것을 권장한다고 주장합니다. 반면, 소스 [20]는 테마가 사용자 데이터나 복잡한 런타임 상태와 깊게 결합된 '고도로 동적인 대시보드 형태의 애플리케이션'에서는 Styled Components가 여전히 매우 강력한 도구라고 강조하며 상반되면서도 보완적인 시각을 제공합니다.
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Tailwind CSS v4 CSS-first Architecture.md

@@ -0,0 +1,28 @@
+# [[Tailwind CSS v4 CSS-first Architecture]]
+
+## 📌 Brief Summary
+Tailwind CSS v4의 CSS-first 아키텍처는 기존의 자바스크립트 설정 파일(`tailwind.config.js`)에 의존하던 방식을 탈피하여 CSS 기반의 설정으로 전환한 근본적인 패러다임의 변화입니다 [1, 2]. `@theme` 디렉티브를 사용하여 디자인 토큰을 네이티브 CSS 변수로 정의하면 프레임워크가 해당하는 유틸리티 클래스를 자동으로 생성합니다 [2-5]. 이를 통해 자바스크립트 런타임 오버헤드 없이 동적인 테밍이 가능해지며, Rust 기반의 Oxide 엔진과 결합하여 빌드 성능이 비약적으로 향상되었습니다 [3, 6].
+
+## 📖 Core Content
+* **자바스크립트 설정에서 CSS 중심으로의 전환:** 
+  Tailwind CSS v4는 기존 `tailwind.config.js`를 통한 자바스크립트 구성 대신 `@theme` 및 `@source` 디렉티브를 활용하는 CSS-first 아키텍처를 채택했습니다 [1, 3]. 과거에는 컴파일 타임에만 토큰이 적용되고 자바스크립트 객체로 테마를 확장해야 했지만, v4부터는 네이티브 CSS 변수를 통해 런타임에서도 접근 가능한 형태로 변경되었습니다 [2].
+
+* **`@theme` 디렉티브와 유틸리티 클래스 자동 생성:** 
+  `@theme` 블록 내에 디자인 토큰(예: `--color-primary-500`)을 네이티브 CSS 변수로 정의하면, Tailwind는 이를 바탕으로 `bg-primary-500`, `text-primary-500`, `border-primary-500`과 같은 유틸리티 클래스를 자동으로 생성합니다 [2, 3, 5]. 일반적인 `:root` 선택자와 달리, `@theme`는 단순 변수 정의를 넘어 유틸리티 클래스와의 매핑을 지시하는 역할을 합니다 [7]. 정의되는 변수들은 `--spacing-*`, `--font-*`, `--radius-*` 등 지정된 네임스페이스 규칙을 따릅니다 [8, 9].
+
+* **`@source` 디렉티브를 통한 경로 관리:** 
+  자바스크립트로 스캔할 콘텐츠 경로를 설정하던 기존 방식 대신, CSS 파일 내에서 직접 `@source` 디렉티브를 사용하여 경로를 선언합니다 [10]. 이는 CSS 임포트와 자연스럽게 연동되며, 복잡한 모노레포(Monorepo) 환경에서 관리를 더욱 용이하게 만듭니다 [10].
+
+* **웹 플랫폼 정렬 및 성능 최적화:** 
+  이러한 CSS-first 아키텍처는 네이티브 CSS 변수와의 직접적인 통합을 통해 현대 웹 플랫폼의 방향성과 완벽하게 부합합니다 [3, 11]. 또한 Rust로 작성된 Oxide 엔진의 도입으로 이전의 자바스크립트 기반 컴파일러보다 전체 빌드는 5~10배, 증분 빌드(Incremental build)는 100배 이상 빨라졌습니다 [3, 6, 12].
+
+* **Zero-Config 및 향상된 런타임 테밍:** 
+  React 프로젝트에서 기존 CSS-in-JS 라이브러리(Styled Components 등)가 React Context에 의존하며 서버 컴포넌트(RSC) 환경이나 런타임 성능에서 한계를 보였던 반면, Tailwind v4는 자바스크립트 구성이 필요 없는 Zero-config 환경을 제공합니다 [3, 6, 13]. 또한 컴포넌트의 로직 수정 없이 CSS 변수의 값만 스왑하는 방식으로 다크 모드나 다중 브랜드 테밍을 매우 직관적이고 효율적으로 구현할 수 있습니다 [3, 14].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Design Tokens]], [[Utility-first CSS]], [[React Server Components (RSC)]], [[CSS-in-JS]]
+- **Projects/Contexts:** [[Modern Scalable Frontend Architecture]], [[Next.js App Router Migration]]
+- **Contradictions/Notes:** 기존 Tailwind CSS v3까지는 자바스크립트를 이용해 설정 파일을 다루고 컴파일 타임에만 디자인 시스템이 생성되었다면, v4는 CSS 변수를 바탕으로 런타임과 브라우저의 기본 기능을 적극 활용하는 방향으로 설계 사상이 완전히 반전되었습니다 [2].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Tailwind CSS v4.md

@@ -0,0 +1,26 @@
+# [[Tailwind CSS v4]]
+
+## 📌 Brief Summary
+Tailwind CSS v4는 JavaScript 설정 파일 대신 CSS 우선(CSS-first) 아키텍처를 도입하여 프론트엔드 스타일링의 패러다임을 전환한 프레임워크입니다 [1-3]. Rust 기반의 Oxide 엔진을 탑재하여 기존 대비 빌드 속도를 비약적으로 향상시켰으며, 네이티브 CSS 변수를 통해 디자인 토큰을 직접 제어할 수 있도록 지원합니다 [3, 4]. 이를 통해 제로 컨피그(Zero Config) 환경을 제공하고 런타임 자바스크립트의 오버헤드 없이 확장 가능한 디자인 시스템과 테마 기능을 효율적으로 구현할 수 있습니다 [3, 4].
+
+## 📖 Core Content
+
+* **CSS 우선 아키텍처(CSS-First Architecture):** 
+  Tailwind CSS v4의 가장 큰 구조적 변화는 기존의 `tailwind.config.js`를 통한 JavaScript 기반 설정에서 벗어나 CSS 파일 내에서 직접 설정을 관리한다는 점입니다 [1-3]. 개발자는 `@source` 지시어(directive)를 통해 유틸리티 클래스를 스캔할 콘텐츠 경로를 선언하고, `@theme` 지시어를 사용해 테마와 디자인 토큰을 정의합니다 [5, 6].
+
+* **테마 변수(Theme variables) 및 네이티브 CSS 변수:** 
+  `@theme` 블록 내에 디자인 토큰(예: `--color-mint-500`)을 정의하면, 이는 네이티브 CSS 변수로 노출될 뿐만 아니라 `bg-mint-500`, `text-mint-500`과 같은 유틸리티 클래스들을 자동으로 생성합니다 [2, 7-9]. 이러한 네이티브 CSS 변수 접근 방식은 다크 모드나 브랜드 테마와 같은 런타임 테마 전환을 JavaScript 문맥(Context) 업데이트 없이도 손쉽게 구현할 수 있게 해줍니다 [3, 10]. 또한 `var()`를 사용하여 임의의 값이나 인라인 스타일에서 디자인 토큰을 직접 참조하는 것도 가능해졌습니다 [9, 11].
+
+* **압도적인 성능 향상 (Oxide 엔진):** 
+  Tailwind v4는 Rust로 작성된 새로운 Oxide 엔진을 도입하여 기존 버전에 비해 성능이 크게 향상되었습니다 [3, 4, 12]. 전체 빌드 속도는 최대 10배, 증분 빌드(incremental builds)는 100배 이상 빨라졌으며, 거의 즉각적인 HMR(Hot Module Replacement)을 제공합니다 [3, 4, 13]. 자바스크립트 실행 없이 빌드 타임에 정적 CSS를 생성하기 때문에, 브라우저가 스타일을 네이티브하게 구문 분석할 수 있어 서버 CPU 지연 시간과 Time to First Byte(TTFB)를 크게 줄입니다 [14, 15].
+
+* **확장 가능한 디자인 시스템 설계:** 
+  Tailwind v4는 인간의 인지 수준에 맞춰 균일한 밝기 단계를 제공하는 OKLCH 색상 시스템을 채택하여 일관성 있는 색상 스케일을 쉽게 구축할 수 있습니다 [10]. 또한, CVA(Class Variance Authority)와 같은 도구를 함께 사용하면 컴파운드 컴포넌트(Compound Components) 패턴으로 복잡한 UI 컴포넌트 변형(variant)을 직관적이고 확장성 있게 관리할 수 있습니다 [6, 16]. 
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Design Tokens]], [[CSS-in-JS]], [[React Server Components]], [[Compound Components]]
+- **Projects/Contexts:** [[Next.js App Router]], [[Scalable Design Systems]]
+- **Contradictions/Notes:** 소스에 따르면 Tailwind CSS v4는 JS 오버헤드가 없는 정적 CSS 생성으로 인해 Core Web Vitals 최적화와 SSR 환경에 유리한 반면, Styled Components와 같은 런타임 기반 CSS-in-JS 라이브러리는 동적 스타일링에 강점이 있지만 스타일 생성 및 주입 과정에서 JavaScript 성능 오버헤드가 발생하며 React Server Components(RSC)와의 기본 호환성이 부족하다는 차이점을 가집니다 [14, 17-19].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Tailwind CSS.md

@@ -0,0 +1,34 @@
+# [[Tailwind CSS]]
+
+## 📌 Brief Summary
+Tailwind CSS는 개발자가 마크업(HTML/JSX) 내에서 미리 정의된 저수준 유틸리티 클래스(예: `flex`, `pt-4`, `bg-blue-500`)를 조합하여 사용자 인터페이스를 직접 구축할 수 있게 해주는 유틸리티 퍼스트(Utility-first) CSS 프레임워크입니다 [1, 2]. 컴포넌트 단위로 분리된 기존 CSS 파일 작성 방식과 달리 컨텍스트 전환 없이 빠른 UI 개발을 지원하며, 사용하지 않는 CSS를 빌드 타임에 제거하여 매우 작고 최적화된 프로덕션 번들을 생성하는 것이 특징입니다 [1, 3, 4]. 최근 React Server Components(RSC) 환경과 같이 고성능이 요구되는 현대 프론트엔드 아키텍처에서 런타임 오버헤드가 없는 최적의 스타일링 방식으로 널리 채택되고 있습니다 [5-7].
+
+## 📖 Core Content
+
+**작동 방식 및 주요 특징**
+*   **유틸리티 퍼스트(Utility-First) 접근:** 복잡한 CSS 클래스를 작성하는 대신 단일 CSS 속성에 대응하는 작고 명확한 유틸리티 클래스를 조합하여 UI를 구성합니다 [1, 8]. 
+*   **디자인 시스템 내장:** 간격(spacing), 타이포그래피, 색상 등 일관된 디자인 토큰을 내장하여 여러 명의 개발자가 작업해도 디자인이 어긋나는 현상(예: 수백 가지의 다른 회색 음영)을 방지합니다 [3, 9].
+*   **Tailwind v4의 아키텍처 혁신:** 최신 Tailwind v4에서는 JavaScript 설정 파일(`tailwind.config.js`) 대신 `@theme`, `@source` 디렉티브를 사용하는 'CSS-first' 아키텍처를 채택했습니다 [10, 11]. 이는 네이티브 CSS 변수에 직접 접근하게 해 주며, Rust 기반의 Oxide 엔진을 활용하여 기존 대비 빌드 속도를 최대 10배 향상시켰습니다 [10, 12, 13].
+
+**Tailwind CSS의 주요 장점 (Pros)**
+*   **성능 및 번들 최적화:** 런타임에 스타일을 구문 분석하고 주입하는 CSS-in-JS와 달리, JIT(Just-In-Time) 컴파일러와 PurgeCSS를 사용하여 사용된 클래스만 추출한 정적 CSS를 생성합니다 [3, 4, 7]. 이로 인해 런타임 오버헤드가 'Zero'이며, 프로덕션 CSS 번들 크기를 5~20kb 수준으로 억제할 수 있습니다 [3, 6, 7].
+*   **React Server Components (RSC) 완벽 호환:** 런타임 단계에서 React Context에 의존하는 Styled Components나 Emotion과 달리, Tailwind는 정적 CSS를 기반으로 하므로 Next.js 15의 App Router와 같은 서버 컴포넌트 환경에서 제약 없이 완벽히 동작합니다 [5, 6, 14, 15].
+*   **코드 유지보수 및 개발 속도:** 컴포넌트를 삭제할 때 해당 스타일도 함께 안전하게 제거되므로 사용되지 않는 '고아 CSS(Orphaned CSS)'가 쌓이지 않으며, 마크업과 스타일링을 한 곳에서 처리하여 개발 속도를 높여줍니다 [3, 8].
+
+**Tailwind CSS의 단점 및 한계 (Cons)**
+*   **가독성 저하 (Class Soup):** 복잡한 컴포넌트의 경우 `className`에 수십 개의 유틸리티 클래스가 나열되어 마크업의 가독성이 떨어지고 코드가 지저분해지는 문제가 발생합니다 [3, 16, 17].
+*   **임의의 값(Arbitrary Values) 남용 문제:** 디자인 토큰에 정의되지 않은 임의의 값(예: `w-[347px]`)을 프로젝트 내에 무분별하게 사용하면 디자인 시스템의 확장성과 일관성이 훼손될 위험이 있습니다 [16, 18].
+*   **러닝 커브:** 새로운 유틸리티 클래스 이름의 규칙을 익혀야 하므로 초기 진입 장벽과 학습 시간이 필요합니다 [17, 18].
+
+**재사용 가능한 컴포넌트 아키텍처 및 모범 사례 (Best Practices)**
+*   **컴포넌트 추상화:** 긴 유틸리티 클래스 문자열의 중복과 가독성 저하를 피하기 위해, `@apply` 지시어를 무분별하게 사용하기보다는 반복되는 패턴을 별도의 React 컴포넌트로 추출하여 캡슐화하는 것이 가장 좋은 방법입니다 [16, 19].
+*   **도구 생태계 활용:** Tailwind와 함께 Radix UI 등 스타일이 없는 'Headless UI'를 결합하거나, CVA(Class Variance Authority) 및 `clsx`, `tailwind-merge` 라이브러리를 활용하여 동적 변형(Variants)과 클래스 충돌을 효율적으로 관리해야 합니다 [3, 20-22].
+*   **디자인 토큰 중앙 집중화:** 산발적인 색상이나 간격 값을 사용하지 않고 설정 파일이나 `@theme` 블록을 통해 테마 변수(CSS 변수)를 중앙 집중화하면 다크 모드 및 멀티 브랜딩 시스템을 견고하게 구축할 수 있습니다 [9, 23-25].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Styled Components]], [[CSS-in-JS]], [[Design Tokens]], [[React Server Components (RSC)]], [[Headless UI]]
+- **Projects/Contexts:** [[Next.js App Router]], [[Component Library Architecture]], [[Scalable Frontend Systems]]
+- **Contradictions/Notes:** 소스 전반에 걸쳐 Styled Components는 동적 스타일링과 props를 통한 캡슐화 등 뛰어난 개발자 경험(DX)을 제공한다고 언급되지만 [26, 27], 현대 프론트엔드 환경(특히 Next.js App Router/RSC)에서는 Tailwind CSS가 런타임 오버헤드가 없고 번들 크기가 작기 때문에 아키텍처 상의 성능 우위를 가지며 확장 가능한 대규모 설계에 훨씬 적합하다고 대조적으로 평가합니다 [6, 7, 14, 15, 28, 29].
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/Uber Base Web Design System.md

@@ -0,0 +1,19 @@
+# [[Uber Base Web Design System]]
+
+## 📌 Brief Summary
+Uber Base Web Design System은 Uber에서 수백 개의 내부 웹 애플리케이션 간의 일관성을 유지하고 개발 오버헤드를 줄이기 위해 구축한 React 컴포넌트 라이브러리이다 [1, 2]. 2018년에 오픈 소스로 공개되었으며, 기기에 구애받지 않고 빠르고 쉽게 웹 애플리케이션을 만들 수 있는 탄탄한 기반을 제공한다 [2]. 특히 접근성과 성능을 중시하며, 독자적인 'Overrides API 패턴'을 통해 유연하고 확장 가능한 컴포넌트 커스터마이징을 지원하는 것이 핵심적인 특징이다 [3-5].
+
+## 📖 Core Content
+- **탄생 배경 및 목적:** Uber의 수많은 내부 웹 애플리케이션들이 각기 다르게 작동하여 발생하는 학습 오버헤드와 중복 개발(바퀴의 재발명) 문제를 해결하기 위해 도입되었다 [1]. Base 디자인 언어를 코드로 구현하여 디자이너, 엔지니어, 프로덕트 매니저 간의 공통 언어 역할을 수행한다 [2, 6].
+- **신뢰성 (Reliability):** 각 커밋마다 시각적 회귀(visual regression) 서비스 테스트와 Puppeteer를 활용한 엔드투엔드(End-to-End) 테스트를 거쳐 픽셀 단위의 완벽한 레이아웃을 보장하고 버그 발생을 방지한다 [7].
+- **접근성 및 성능 (Accessibility & Performance):** 키보드 내비게이션 및 스크린 리더와 원활하게 작동하도록 설계되어 엄격한 접근성 기준(ARIA 등)을 충족한다 [3, 8]. 또한, 모바일 기기 및 열악한 네트워크 환경에서의 최적화를 위해 Styletron을 활용하여 원자적(atomic) 스타일링을 생성, 다운로드되는 콘텐츠 페이로드를 최소화한다 [3].
+- **Overrides API 패턴:** Base Web이 채택한 가장 핵심적인 확장 아키텍처 패턴이다 [9]. 개발자가 컴포넌트 내부의 하위 요소(sub-element)에 식별자를 통해 접근하여 스타일과 속성을 덮어쓰거나, 컴포넌트 자체를 완전히 교체할 수 있도록 `overrides` 속성을 제공한다 [5, 9-11].
+- **확장성 및 유지보수 이점:** Overrides 패턴을 통해 최상위 컴포넌트에 무수히 많은 속성(prop)을 추가해야 하는 'prop soup' 문제를 방지한다 [9, 10]. 라이브러리 개발자가 모든 사용 사례를 예측해 속성을 노출하지 않아도, 소비자가 직접 엣지 케이스에 맞춰 UI를 재정의할 수 있어 거대한 스케일에서도 라이브러리가 비대해지지 않고 유연함을 유지한다 [9].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Overrides Pattern]], [[React Component Architecture]], [[Styletron]], [[Design Tokens]], [[Accessibility (A11y)]]
+- **Projects/Contexts:** [[Building Reusable UI Components]], [[Scalable Frontend Design Systems]]
+- **Contradictions/Notes:** 소스에 상충하는 내용에 대한 관련 정보가 부족합니다.
+
+---
+*Last updated: 2026-04-26*

10_Wiki/Topics_Art/UI_UX_Assets/shadcn-ui.md

@@ -0,0 +1,19 @@
+# [[shadcn/ui]]
+
+## 📌 Brief Summary
+shadcn/ui는 Tailwind CSS를 위해 설계된 React UI 컴포넌트 라이브러리 및 프리미티브 모음입니다 [1, 2]. 주로 Radix와 같은 Headless UI와 함께 사용되며, 복잡한 상호작용과 상태 관리를 지원하는 정교하고 재사용 가능한 컴포넌트를 구축하는 데 사용됩니다 [3, 4]. 특히 Next.js App Router를 사용하는 중소규모의 애플리케이션에서 Tailwind CSS와 결합하여 사용할 때 가장 권장되는 접근 방식 중 하나입니다 [2].
+
+## 📖 Core Content
+- **Tailwind CSS 기반 생태계:** shadcn/ui는 Tailwind CSS 환경에 완벽하게 맞춰 설계되었으며, 주로 Radix UI 및 Headless UI와 결합하여 사용됩니다 [1, 3]. 이는 CSS-in-JS의 런타임 오버헤드를 피하고 유틸리티 클래스 기반의 빠른 렌더링 성능을 활용하는 현대적인 스타일링 접근 방식과 맞닿아 있습니다 [2, 5].
+- **컴포넌트 프리미티브 제공:** 새로운 프로젝트(특히 Next.js App Router 기반의 중소규모 앱)를 구축할 때, 처음부터 UI를 작성하는 대신 프리미티브(Component primitives) 역할을 하여 빠른 개발을 돕습니다 [2].
+- **고급 컴포넌트 패턴 지원:** 유연하고 확장 가능한 API를 설계하기 위해 컴파운드 컴포넌트(Compound component) 아키텍처 패턴을 적극적으로 활용합니다 [4]. 이를 통해 하나의 거대한 컴포넌트에 수많은 prop을 전달하는 대신, 논리적으로 협력하는 여러 하위 컴포넌트로 책임을 분산시켜 복잡한 요구사항을 해결합니다 [3, 6].
+- **확장 가능한 스타일링 및 성능 최적화:** 변형(variant) 시스템, 반응형 디자인, 테마 통합과 같은 고급 스타일링 기법을 마스터할 수 있는 구조를 갖추고 있습니다 [4]. 효율적인 렌더링과 상태 관리를 위한 성능 최적화 기술도 내장하고 있습니다 [4].
+- **타입 안정성 보장:** TypeScript를 기반으로 구축되어 있어, 오류를 방지하고 완벽한 타입 안정성을 제공하는 컴포넌트 개발 및 API 설계가 가능합니다 [4].
+
+## 🔗 Knowledge Connections
+- **Related Topics:** [[Tailwind CSS]], [[Compound Components]], [[Headless UI]], [[Radix]]
+- **Projects/Contexts:** [[Next.js App Router 프로젝트]], [[재사용 가능한 React 컴포넌트 라이브러리 설계]]
+- **Contradictions/Notes:** 소스 상에서 shadcn/ui는 전통적인 의미의 무거운 UI 프레임워크라기보다는, Tailwind CSS와 결합하여 개발자에게 강력한 통제권과 유연성을 제공하는 프리미티브 모음으로 묘사되고 있습니다 [1, 2].
+
+---
+*Last updated: 2026-04-26*