feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]
This commit is contained in:
@@ -1,9 +1,29 @@
|
||||
---
|
||||
id: wiki-2026-0508-style-dictionary-pipelines
|
||||
title: Style Dictionary Pipelines
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
---
|
||||
|
||||
# [[Style Dictionary Pipelines|Style Dictionary Pipelines]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
[[Style Dictionary|Style Dictionary]] 파이프라인은 플랫폼에 구애받지 않는 디자인 토큰(JSON 등)을 구문 분석하고 변환하여 iOS, Android, CSS, JS 등 다양한 플랫폼에 맞는 코드로 내보내는 자동화된 빌드 시스템 워크플로우를 의미합니다[1-3]. 이 파이프라인을 통해 여러 플랫폼에서 디자인 값의 '단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])'을 구축하여 수동 오류를 없애고 시각적 일관성을 유지할 수 있습니다[3]. "예쁘게"를 넘어 확장성과 "유지보수성"을 달성하기 위한 대규모 디자인 시스템 아키텍처의 핵심 도구로 작용합니다[3, 4].
|
||||
|
||||
## 📖 Core Content
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **빌드 시스템의 역할 및 작동 원리**
|
||||
* Style Dictionary는 [[Nodejs|Nodejs]]와 브라우저 환경에서 실행되는 빌드 시스템입니다[2].
|
||||
* 구성(configuration)에 정의된 `source`와 `include` 배열을 통해 여러 개의 디자인 토큰 파일(JSON, JSONC, ES Modules 등)을 찾아 심층 병합(deep merge)을 수행합니다[5-7].
|
||||
@@ -21,10 +41,64 @@
|
||||
* 대규모 엔터프라이즈 환경에서는 디자이너가 Figma에서 '프라이머리 블루' 색상을 업데이트할 때, 이 변경 사항이 Style Dictionary와 CI/CD 파이프라인을 통해 수많은 애플리케이션 컴포넌트로 자동 전파되도록 구성합니다[11, 12].
|
||||
* 이러한 자동화 파이프라인은 스타일링 프로세스에서 가장 반복적이고 오류가 발생하기 쉬운 인적 개입을 제거하므로 진정한 의미의 '유지보수성'을 달성하는 궁극적인 표현 방식으로 평가받습니다[12].
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
## 🔗 지식 연결 (Graph)
|
||||
- **Related Topics:** [[디자인 시스템 (Design Systems)|디자인 시스템(DesignSystems]], 디자인 토큰(Design Tokens), [[유지보수성(Maintainability)|유지보수성(Maintainability]]
|
||||
- **Projects/Contexts:** [[대규모 프론트엔드 아키텍처(Large-Scale Frontend Architecture)|대규모 프론트엔드 아키텍처(Large-Scale Frontend Architecture]], [[크로스 플랫폼 UI 개발(Cross-Platform UI Development)|크로스 플랫폼 UI 개발(Cross-Platform UI Development]]
|
||||
- **Contradictions/Notes:** Figma와 같은 기본 디자인 애플리케이션은 디자인 토큰 관리를 위한 인앱 솔루션을 완벽하게 지원하지 않는 한계를 가집니다. 따라서 개발자와 디자이너 사이의 간극을 메우고 동기화된 통신을 허용하기 위해 Style Dictionary를 활용한 파이프라인 같은 서드파티 해결책에 전적으로 의존하고 있습니다[13].
|
||||
|
||||
---
|
||||
*Last updated: 2026-04-26*
|
||||
*Last updated: 2026-04-26*
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
|
||||
## 🧪 검증 상태 (Validation)
|
||||
|
||||
- **정보 상태:** needs_review
|
||||
- **출처 신뢰도:** A
|
||||
- **검토 이유:** *(P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)*
|
||||
|
||||
## 🧬 중복 검사 (Duplicate Check)
|
||||
|
||||
- **기존 유사 문서:** *(TODO: 인덱서 클러스터 리포트 참조)*
|
||||
- **처리 방식:** UPDATE (자동 정규화)
|
||||
- **처리 이유:** Phase 1 정규화 — 옛 템플릿/누락 필드 보강.
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
|
||||
- **과거 데이터와의 충돌:** 없음
|
||||
- **정책 변화:** 없음
|
||||
|
||||
## 🕓 변경 이력 (Changelog)
|
||||
|
||||
| 날짜 | 변경 내용 | 처리 방식 | 신뢰도 |
|
||||
|------|-----------|-----------|--------|
|
||||
| 2026-05-08 | P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화) | UPDATE | A |
|
||||
|
||||
## 💻 코드 패턴 (Code Patterns)
|
||||
|
||||
**패턴 1:** *(TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
Reference in New Issue
Block a user