chore: Delete processed raw file (Design Systems)
This commit is contained in:
Antigravity Agent
@@ -1,17 +0,0 @@
|
||||
# [[Design Systems]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
디자인 시스템은 애플리케이션의 일관성 있는 UI를 구축하고 컴포넌트의 재사용성을 촉진하기 위해 활용되는 체계입니다 [1, 2]. 주로 아토믹 디자인(Atomic Design) 모델과 결합하여 디자이너와 개발자 간의 공유된 어휘를 확립하는 데 탁월한 역할을 합니다 [1]. 그러나 디자인 시스템 자체는 비즈니스 로직이나 애플리케이션 상태(state)를 관리하는 방법을 규정하지 않기 때문에, 대규모 프로젝트에서는 이를 보완할 별도의 프론트엔드 아키텍처 방법론이 함께 요구됩니다 [1, 2].
|
||||
|
||||
## 📖 Core Content
|
||||
* **아토믹 디자인(Atomic Design)과의 결합:** 디자인 시스템을 일관성 있게 구축하기 위한 유용한 멘탈 모델로 아토믹 디자인이 주로 사용됩니다 [1]. 이는 인터페이스를 가장 작은 원자(atoms) 요소부터 분자, 유기체, 템플릿, 페이지 등 복잡한 구조로 상향식으로 구축하여 재사용 가능한 UI 라이브러리를 만드는데 강력한 성능을 발휘합니다 [2].
|
||||
* **Storybook을 통한 문서화 및 테스트:** 디자인 시스템의 컴포넌트들은 주로 Storybook과 같은 도구를 사용하여 문서화되고 개발됩니다 [3]. 또한 Happo 또는 Chromatic과 같은 도구를 연동하여 시각적 회귀 테스트(Visual regression testing)를 수행함으로써, 레이아웃, 색상, 타이포그래피, 반응형 동작 등의 의도치 않은 UI 변경이나 버그를 사전에 방지할 수 있습니다 [3-5].
|
||||
* **아키텍처적 한계 및 다른 방법론과의 공존:** 디자인 시스템(아토믹 디자인 기반)은 UI의 일관성과 재사용성에 초점을 맞추기 때문에, 기능 간의 관계나 비즈니스 로직을 구성하는 방법은 의도적으로 배제합니다 [1, 2]. 결과적으로 훌륭한 UI 컴포넌트 위에 혼란스러운 로직 계층이 얹히는 문제를 막기 위해, 도메인 복잡성과 애플리케이션 흐름을 다루는 Feature-Sliced Design (FSD)과 같은 아키텍처와 한 프로젝트 내에서 공존하며 상호 보완적으로 사용되어야 합니다 [1, 2].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
- **Related Topics:** [[Atomic Design]], [[Storybook]], [[Feature-Sliced Design (FSD)]], [[Visual Regression Testing]]
|
||||
- **Projects/Contexts:** [[UI Component Library Development]], [[Scalable React Architecture]]
|
||||
- **Contradictions/Notes:** 아토믹 디자인을 기반으로 한 디자인 시스템은 UI 재사용성에는 이상적이지만 비즈니스 로직이나 상태 관리에는 부족함이 있습니다. 따라서 구조와 흐름에 중점을 두는 Feature-Sliced Design과 초점이 다르며, 대규모 앱에서는 두 가지를 명확히 구분하고 결합하여 사용해야 합니다 [1, 2].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: DS-GOVERNANCE-001
|
||||
category: "[[10_Wiki/💡 Topics/AI]]"
|
||||
confidence_score: 1.0
|
||||
tags: [design-system, governance, scalability, theme-system, design-tokens, tokens, ui-kit]
|
||||
last_reinforced: 2026-04-26
|
||||
---
|
||||
|
||||
# [[Scalable Design System Governance (확장 가능한 디자인 시스템 거버넌스)]]
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
> "디자인 시스템은 고정된 라이브러리가 아니라 끊임없이 변화하는 살아있는 제품(Product)이며, 명확한 의사결정 체계(Governance)와 기술적 유연성(Tokens)이 뒷받침될 때 비로소 전사적 일관성을 지키는 방패가 된다" — 대규모 조직의 디자인-엔지니어링 협업 시스템의 정수.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
- **추출된 패턴:** "Token-based Theming and Democratic Evolution" — 스타일 속성을 추상화한 디자인 토큰(Design Tokens)을 통해 기술 스택에 상관없는 일관성을 유지하고, 새로운 컴포넌트의 추가/수정 프로세스를 시스템화하는 패턴.
|
||||
- **핵심 거버넌스 요소:**
|
||||
- **Design Tokens:** 색상, 타이포그래피, 간격 등을 JSON 형태의 변수로 관리하여 Web, iOS, Android 전반에 동기화.
|
||||
- **Contribution Model:** 새로운 UI 패턴이 발견되었을 때 이를 검토하고 시스템에 편입시키는 명확한 워크플로우 정의.
|
||||
- **Documentation (Storybook):** 컴포넌트의 사용법, 상태(State), 도메인별 제약 사항을 실시간 문서화.
|
||||
- **Accessibility Audit:** 시스템 수준에서 WCAG 기준을 준수하도록 강제하여 모든 제품의 포용성 확보.
|
||||
- **의의:** 중복 작업을 제거하여 생산성을 높이고, 브랜드 정체성을 모든 디지털 터치포인트에서 견고하게 유지함.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
||||
- **과거 데이터와의 충돌:** 과거에는 디자인 가이드라인을 단순 문서(PDF)로 공유했으나, 현대 정책은 '코드 기반의 진실 정책(Source of Truth in Code)'을 통해 디자인과 실제 구현을 1:1로 일치시킴.
|
||||
- **정책 변화:** Antigravity 프로젝트는 모든 디자인 시스템 변경 사항에 대해 엔지니어링 리드와 디자인 리드의 공동 승인 정책을 시행하며, 토큰 업데이트 시 자동화된 빌드 배포 정책을 준수함.
|
||||
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- [[Atomic-Design-System-Architecture]], [[Uber-Base-Web-Design-System]], [[Inclusive-Design-and-UX]], [[Modern-Web-Design-Best-Practices-2025]]
|
||||
- **Raw Source:** [[00_Raw/Design Systems.md]]
|
||||
Reference in New Issue
Block a user