feat: batch wikification of Skybound balance pass and scalable frontend architectures
Processed 80+ files including Skybound playtest feedback, Monorepo strategies, and Modern Component Patterns.
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,31 @@
|
||||
# [[Accessibility (A11y)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
접근성(Accessibility, A11y)은 스크린 리더, 키보드 네비게이션 등을 지원하여 모든 사용자가 차별 없이 UI를 이용할 수 있도록 하는 설계 원칙 및 기능입니다 [1, 2]. React 컴포넌트 아키텍처와 디자인 시스템에서 재사용성은 접근성과 뗄 수 없는 관계를 가지며, ARIA 속성 및 시맨틱 HTML 적용을 기본으로 합니다 [3, 4]. 잘 설계된 컴포넌트 라이브러리와 아키텍처 패턴은 개발자가 처음부터 접근성을 구현할 필요 없이, 접근성 테마 모드나 포커스 관리 등과 같은 내장된 접근성 지원을 제공합니다 [1, 5, 6].
|
||||
|
||||
## 📖 Core Content
|
||||
|
||||
* **재사용 가능한 컴포넌트와 접근성 우선(Accessibility First) 원칙**
|
||||
재사용 가능한 컴포넌트를 설계할 때 접근성은 선택 사항이 아니라 필수 사항입니다 [2]. 키보드 탭 순서 관리, 화살표 키 탐색, 올바른 시맨틱 HTML 역할(Roles)과 레이블, 포커스 제어 및 오류 메시지 제공 등은 컴포넌트의 핵심 기능에 내장(Bake into the DNA)되어야 합니다 [2, 6]. 컴포넌트가 진화하더라도 접근성 역할, 레이블, 포커스 상태가 깨지지 않는지 확인하기 위해 지속적인 접근성 검사(Accessibility checks)가 필요합니다 [7].
|
||||
|
||||
* **아키텍처 패턴을 통한 접근성 구현**
|
||||
* **Compound Components:** 부모 컴포넌트(예: Accordion)가 자식 컴포넌트들의 상태를 제어하는 방식은 접근성 구현을 단순하게 만듭니다. 컨텍스트를 통해 내부 상태를 공유하기 때문에, 사용자가 명시적으로 ID를 전달하지 않아도 `aria-controls`와 `aria-labelledby` 같은 속성을 자동으로 연결해 줄 수 있습니다 [8].
|
||||
* **Headless Components:** 이 패턴은 상태 관리, 로직, 그리고 접근성 기능(키보드 네비게이션, ARIA 역할 등)을 내장하여 제공하되, 스타일링은 개발자가 Tailwind CSS 등으로 자유롭게 구성하도록 맡기는 방식으로 현대적이고 접근성이 뛰어난 UI 구축에 활용됩니다 [9].
|
||||
|
||||
* **디자인 시스템 및 테마 기반 접근성**
|
||||
디자인 토큰을 기반으로 한 테마 시스템은 접근성 요구 사항을 유연하게 수용할 수 있습니다 [5, 10]. 예를 들어, 디자인 테마는 다크 모드뿐만 아니라 모든 요소를 더 눈에 띄게 만드는 고대비(High-contrast) 테마나 제한된 움직임(Limited movement)과 같은 사용자 기본 설정에 맞춰 동적으로 조정될 수 있습니다 [5, 10, 11].
|
||||
|
||||
* **주요 라이브러리 및 도구의 접근성 지원의 차이**
|
||||
* Shopify의 Polaris와 Uber의 Base Web과 같은 최신 라이브러리는 키보드 내비게이션, ARIA 역할, 스크린 리더 호환성 및 WCAG 표준 준수를 기본 기능으로 제공합니다 [1, 3, 12, 13].
|
||||
* 반면 Tailwind CSS와 같은 유틸리티 우선 프레임워크는 스타일링에 특화되어 있어 자동으로 `aria-*` 속성이나 시맨틱 HTML 요소로 변경해주지 않습니다 [4]. 따라서 Tailwind CSS를 사용할 때는 개발자가 올바른 ARIA 속성과 시맨틱 마크업을 명시적으로 포함해야 합니다 [4].
|
||||
|
||||
* **대규모 접근성 문서화 및 관리 자동화**
|
||||
Uber와 같은 대규모 환경에서는 VoiceOver, TalkBack, ARIA와 같은 3가지 접근성 API를 커버해야 하며, 각각 수백 개의 속성이 존재하기 때문에 수동으로 스펙을 관리하기 어렵습니다 [14]. 이를 해결하기 위해 AI 에이전트(Figma Console MCP 활용)를 도입하여 컴포넌트 트리를 스크랩하고 다중 플랫폼의 스크린 리더 및 접근성 속성을 단 몇 분 만에 포괄적인 스펙 문서로 자동 렌더링하는 자동화 파이프라인을 구축하여 접근성 기준을 유지합니다 [15-18].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Compound Components]], [[Headless Components]], [[Design Tokens]], [[Tailwind CSS]]
|
||||
- **Projects/Contexts:** [[Uber Base Web]], [[Shopify Polaris]], [[React Component Library Architecture]]
|
||||
- **Contradictions/Notes:** 컴포넌트 레벨에서의 접근성 내장 여부에서 프레임워크 간 차이가 발생합니다. Shopify Polaris나 Uber Base Web 등의 완전한 UI 컴포넌트 라이브러리는 ARIA 및 키보드 조작과 같은 접근성을 기본으로 제공하지만 [1, 3, 12], Tailwind CSS를 단독으로 사용할 경우 자동으로 접근성 태그를 부여하지 않으므로 개발자가 직접 시맨틱 마크업과 ARIA 속성을 챙겨야 한다는 명확한 한계(책임의 전가)를 지적하고 있습니다 [4].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,21 @@
|
||||
# [[Accessibility]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
접근성(Accessibility, A11y)은 장애 여부나 기기 환경에 관계없이 모든 사용자가 인터페이스를 원활하게 이용할 수 있도록 보장하는 핵심 설계 원칙이다 [1]. 확장 가능한 React 컴포넌트 아키텍처에서는 재사용성을 확보하기 위해 ARIA 역할(roles), 키보드 탐색, 포커스 관리, 화면 판독기(Screen-reader) 지원 등을 컴포넌트 단계에서 기본적으로 내장해야 한다 [1-3].
|
||||
|
||||
## 📖 Core Content
|
||||
- **재사용 가능한 컴포넌트의 필수 조건**: 접근성은 디자인 완료 후 나중에 추가하는 것이 아니라 '최우선(First-Class)'으로 컴포넌트의 DNA에 내장되어야 한다 [1, 3]. 접근성을 나중에 덧붙이는 방식(afterthought)으로 처리하면 비용과 수고가 두 배로 든다 [4]. 상호작용 요소에는 적절한 시맨틱 태그, 역할(roles), 라벨, 포커스 관리 및 키보드 탐색(Tab, 화살표 키, Home/End 등) 기능이 필수적으로 포함되어야 한다 [1, 3, 5].
|
||||
- **디자인 토큰과 시스템을 통한 접근성 향상**: 디자인 토큰 기반의 테마 시스템을 적용하면 고대비(high-contrast) 모드나 모션 감소(limited movement)와 같이 다양한 사용자 선호도 및 접근성 요구 사항에 맞춰 인터페이스를 쉽게 조정할 수 있다 [6].
|
||||
- **스타일링 도구 및 아키텍처 패턴의 접근성 처리**:
|
||||
- **Tailwind CSS**: 유틸리티 클래스를 통한 시각적 스타일링은 매우 빠르지만, ARIA 속성이나 시맨틱 HTML을 자동으로 추가해 주지 않는다는 단점이 있다 [7]. 따라서 개발자가 항상 적절한 ARIA 속성과 시맨틱 요소를 직접 추가하는 것이 주요 모범 사례(Best Practice)로 꼽힌다 [8].
|
||||
- **Headless UI 패턴**: Radix UI나 Headless UI와 같은 라이브러리는 복잡한 상태 관리와 접근성 기능을 기본적으로 제공하면서 스타일링 권한만 개발자에게 위임하므로, 브랜드 맞춤형이면서도 완벽한 접근성을 갖춘 UI 시스템을 구축하는 데 매우 유리하다 [9].
|
||||
- **복합 컴포넌트(Compound Components)**: 컴포넌트 내부 컨텍스트(Context)를 공유함으로써 사용자가 직접 ID를 조작하지 않아도 `aria-controls`나 `aria-labelledby`를 자동으로 연결하여 접근성 적용을 단순화할 수 있다 [10].
|
||||
- **대규모 엔터프라이즈의 접근성 관리 (Uber 및 Shopify 사례)**: Shopify의 Polaris 디자인 시스템과 Uber의 Base Web은 키보드 탐색과 화면 판독기 지원을 핵심 기능으로 제공한다 [2, 11, 12]. 특히 Uber는 VoiceOver, TalkBack, ARIA 역할 등 여러 접근성 API의 수백 가지 속성을 정확하게 유지하기 위해, AI 에이전트를 통해 Figma 디자인 파일에서 즉각적으로 스펙(Spec) 문서를 자동 생성하는 시스템을 구축해 규모의 한계를 극복했다 [13-16].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Headless Components]], [[Compound Components]], [[Design Tokens]], [[Tailwind CSS]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]], [[Radix UI]]
|
||||
- **Contradictions/Notes:** 소스는 복합 컴포넌트(Compound Components) 패턴이 ARIA 속성 자동 연결 등을 통해 접근성을 개선해 주지만 [10], 사용자에게 너무 많은 유연성을 부여할 경우 하위 컴포넌트의 순서를 임의로 변경하거나 누락하여 오히려 접근성과 UX를 손상시킬 수 있다고 경고한다 [17].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,28 @@
|
||||
# [[Accessible UI Libraries]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
접근성(Accessibility, A11y)을 기본적으로 갖춘 UI 라이브러리는 스크린 리더 호환성, 키보드 내비게이션, ARIA 속성 등을 내장하여 모든 사용자가 포용적으로 사용할 수 있도록 설계된 컴포넌트 모음입니다 [1-3]. Shopify의 Polaris, Uber의 Base Web, Chakra UI, Headless UI(Radix UI 등) 등이 대표적이며, 이러한 라이브러리들은 확장 가능한 프론트엔드 환경에서 재사용 가능한 UI를 구축할 때 필수적인 역할을 합니다 [2, 4, 5]. 이들을 활용하면 팀이 처음부터 접근성 규칙을 구현하는 시간을 절약하고, 누구나 쉽게 접근 가능한 일관된 사용자 경험(UX)을 제공할 수 있습니다 [6-8].
|
||||
|
||||
## 📖 Core Content
|
||||
* **주요 접근성 내장 UI 라이브러리 및 특징:**
|
||||
* **Chakra UI:** ARIA 호환성을 기본적으로 갖추고 있으며, 키보드 내비게이션과 스크린 리더 사용을 완벽하게 지원하도록 설계되어 포용적인 애플리케이션을 구축하는 데 유리합니다 [2].
|
||||
* **Shopify Polaris:** WCAG 표준을 따르며 적절한 색상 대비, 키보드 내비게이션, 스크린 리더 호환성을 제공합니다 [9]. 또한 ARIA 라벨과 같은 접근성 기능이 사전 구축된 컴포넌트로 제공됩니다 [7].
|
||||
* **Uber Base Web:** 키보드 내비게이션이 안정적으로 작동하고 스크린 리더와 잘 호환되도록 보장하여, 개발자가 모든 방문자에게 적합한 제품을 구축할 수 있게 돕습니다 [1, 4].
|
||||
* **Foundation:** 기본적으로 접근성이 내장되어 있으며, 모든 코드 스니펫에 ARIA 속성이 포함되어 제공되므로 기기나 사용자의 능력에 관계없이 훌륭한 경험을 보장합니다 [3].
|
||||
* **Headless UI (Radix UI 등):** 복잡한 컴포넌트(드롭다운, 다이얼로그 등)에 대해 상태 관리 및 접근성 기능만 제공하고 스타일링은 개발자에게 완전히 일임합니다 [5]. Tailwind CSS와 결합하면 높은 접근성과 브랜드 특화된 UI 라이브러리를 구축하는 데 강력한 힘을 발휘합니다 [5].
|
||||
|
||||
* **재사용 가능한 UI 컴포넌트와 접근성(A11y)의 중요성:**
|
||||
* 재사용 가능한 컴포넌트 설계 시 '접근성 우선(Accessibility First)'은 타협할 수 없는 필수 요소입니다 [10]. 탭(Tab) 순서, 의미 있는 포커스 관리, 올바른 시맨틱 역할(Roles)과 라벨링은 기본적으로 컴포넌트 DNA에 포함되어야 합니다 [10, 11].
|
||||
* 접근성이 확보된 컴포넌트는 팀이 접근성을 처음부터 다시 고민하지 않고도 자신 있게 소프트웨어를 출시할 수 있는 가속기(Accelerator) 역할을 합니다 [6].
|
||||
|
||||
* **규모에 따른 접근성 사양 유지의 과제와 자동화:**
|
||||
* Uber와 같은 대규모 기업에서는 VoiceOver, TalkBack, ARIA 등 플랫폼별로 수백 개의 접근성 속성을 수동으로 유지·관리하는 데 한계가 있습니다 [12].
|
||||
* 이를 해결하기 위해 AI 에이전트와 Figma Console MCP를 연결하여 컴포넌트 구조를 스캔하고, 단 2분 만에 완벽한 스크린 리더 접근성 사양과 문서를 자동 생성하는 시스템(uSpec)을 구축하여 문서화 병목 현상을 해결했습니다 [13-15].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Headless Components]], [[Design Tokens & Theming]]
|
||||
- **Projects/Contexts:** [[Shopify Polaris]], [[Uber Base Web]], [[Chakra UI]], [[Radix UI]]
|
||||
- **Contradictions/Notes:** Tailwind CSS 자체는 강력한 유틸리티 기반 스타일링을 제공하지만, ARIA 속성이나 시맨틱 HTML을 자동으로 추가해주지는 않으므로 접근성을 간과하는 것이 흔한 함정(Pitfall)으로 지적됩니다. 따라서 Tailwind를 사용할 때는 반드시 시맨틱 요소를 직접 추가하거나, 접근성 기능이 내장된 Headless UI 라이브러리를 함께 사용하는 것이 권장됩니다 [5, 16].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -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*
|
||||
@@ -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*
|
||||
Reference in New Issue
Block a user