Antigravity Agent
47 lines
4.5 KiB
Markdown
47 lines
4.5 KiB
Markdown
---
|
|
category: DevOps_and_Security
|
|
tags: [auto-wikified, technical-documentation, merged, devops_and_security]
|
|
title: Design System
|
|
description: "디자인 시스템은 애플리케이션 전반의 일관성을 유지하기 위해 추출된 재사용 가능한 컴포넌트와 패턴의 공유 라이브러리이다 [1, 2]."
|
|
last_updated: 2026-05-04
|
|
---
|
|
|
|
# Design System
|
|
|
|
|
|
## 📌 Brief Summary
|
|
디자인 시스템은 애플리케이션 전반의 일관성을 유지하기 위해 추출된 재사용 가능한 컴포넌트와 패턴의 공유 라이브러리이다 [1, 2]. 주로 모달(Modal), 탭(Tabs), 아코디언(Accordion), 선택 상자(Select)와 같은 UI 원시(primitives) 요소들로 구성되며, 개발자와 디자이너 간의 협업 및 확장성을 돕는다 [2, 3]. React 등 현대 프레임워크에서는 복합 컴포넌트(Compound Components)와 같은 고급 아키텍처 패턴을 활용하여 유연하고 견고한 디자인 시스템을 구축한다 [4, 5].
|
|
|
|
## 📖 Core Content
|
|
* **React 기반 디자인 시스템의 핵심 패턴**: 디자인 시스템이나 공유 컴포넌트 라이브러리를 구축할 때 가장 필수적으로 사용되는 아키텍처 패턴은 복합 컴포넌트(Compound Components)와 렌더 프롭스(Render Props), 그리고 커스텀 훅(Custom Hooks)이다 [2, 4, 6]. Radix UI, Headless UI, React Aria, ShadCN, Material UI와 같은 유명 오픈소스 라이브러리들은 이러한 패턴을 활용한 디자인 시스템 설계의 훌륭한 모범 사례를 제공한다 [2, 5].
|
|
* **복합 컴포넌트(Compound Components)를 통한 유연성 확보**: 디자인 시스템에서 컴포넌트는 다수의 프로퍼티(Props)를 전달받는 거대한 단일 컴포넌트가 되어서는 안 된다 [7]. 대신, 하위 컴포넌트들이 React Context를 통해 암시적 상태를 공유하도록 설계하여, 디자인 시스템을 사용하는 개발자(소비자)가 UI의 구조를 자유롭게 제어할 수 있게 해야 한다 [7, 8].
|
|
* **헤드리스(Headless) 컴포넌트 라이브러리**: 렌더 프롭스나 커스텀 훅 패턴은 상태 관리나 드래그 앤 드롭, 폼 상태와 같은 '동작 로직(Behavioral Logic)'만을 공유하고 시각적 표현(UI)은 전적으로 소비자에게 맡기는 형태의 디자인 시스템(헤드리스 컴포넌트)을 구축하는 데 이상적이다 [9, 10].
|
|
* **코드 기반 프로토타이핑과의 동기화**: UXPin Merge와 같은 도구를 활용하여, 디자인 시스템 팀이 구축한 실제 React 또는 Vue 3 코드 컴포넌트를 디자이너가 프로토타이핑 환경에서 직접 사용하게 할 수 있다 [11, 12]. 이를 통해 디자인과 개발 간의 상호작용 패턴 및 시각적 일관성을 최종 제품까지 완벽하게 동기화할 수 있다 [12].
|
|
|
|
## ⚖️ Trade-offs & Caveats
|
|
* **오버엔지니어링(Over-Engineering)의 위험**: 디자인 시스템 구축 시 모든 컴포넌트에 복잡한 패턴을 적용할 필요는 없다 [5]. 몇 개의 프로퍼티만 받는 단순한 `<Button>` 요소 등에 굳이 복합 컴포넌트 패턴을 적용하는 것은 불필요한 복잡성만 가중시킬 뿐이다 [5]. 진정한 복잡성(자식들 간의 상태 공유나 UI 유연성 등)이 요구될 때만 이러한 패턴을 도입해야 한다 [5].
|
|
* **구조적 복잡성 및 래퍼 지옥(Wrapper Hell)**: 로직 분리를 위해 렌더 프롭스 패턴 등을 남용할 경우, JSX 코드가 깊게 중첩되어 코드를 읽고 디버깅하기 매우 어려워지는 단점이 존재한다 [10, 13].
|
|
* **엄격한 유지보수 및 표준화 요구**: 디자인 시스템의 프로토타입이나 컴포넌트가 커질수록 파편화를 방지하기 위해 명확한 코딩 표준 확립, 일관된 명명 규칙, 그리고 컴포넌트 API 및 생성 패턴에 대한 철저한 문서화가 반드시 뒷받침되어야 한다 [14].
|
|
|
|
---
|
|
*Last updated: 2026-05-03*
|
|
|
|
## 📚 Legacy Insights & Additional Context
|
|
> [!NOTE]
|
|
> Below is content merged from previous versions of this documentation.
|
|
|
|
## 📌 한 줄 통찰 (The Karpathy Summary)
|
|
> 지식 요약 정보 추출 중...
|
|
|
|
## 📖 구조화된 지식 (Synthesized Content)
|
|
본문 구조화 작업 중...
|
|
|
|
## ⚠️ 모순 및 업데이트 (Contradictions & RL Update)
|
|
- **과거 데이터와의 충돌:** 자동화 엔진에 의해 매핑된 지식으로, 추후 정밀 검증 필요.
|
|
- **정책 변화:** Design & Experience 분야의 자동 자산화 수행.
|
|
|
|
## 🔗 지식 연결 (Graph)
|
|
|
|
- Raw Source: 00_Raw/2026-04-20/Material Design System.md
|
|
---
|