# [[디자인 시스템|디자인 시스템]]

## 📌 Brief Summary
디자인 시스템은 명확한 표준에 따라 애플리케이션을 구축하기 위해 조립할 수 있는 재사용 가능한 컴포넌트의 집합입니다 [1]. 이는 브랜드의 시각적 정체성을 프로그래밍 방식으로 구현한 것이며, 디자인과 엔지니어링 사이의 간극을 연결하는 소통 프로토콜의 역할을 수행합니다 [2, 3]. 궁극적으로 제품과 플랫폼 전반에서 일관성을 유지하고, 개발 및 유지보수 워크플로우의 속도를 높이며, 대규모 프론트엔드 환경에서 확장 가능하고 유지보수 가능한 아키텍처를 세우는 것을 목적으로 합니다 [4, 5].

## 📖 Core Content
* **핵심 역할 및 아키텍처적 가치**
  디자인 시스템은 디자인과 엔지니어링 간의 공용 언어를 생성하여 의사소통 오류를 줄이고 제품 업데이트나 리브랜딩을 용이하게 합니다 [4, 6]. 특히 규모가 큰 엔터프라이즈 프로젝트에서 디자인 시스템은 단순히 예쁜 UI를 만드는 것을 넘어, 팀 간의 협업을 지원하고 기술 부채의 누적을 방지하는 유지보수 가능한 아키텍처 구축의 핵심 뼈대가 됩니다 [5].

* **디자인 토큰([[Design Tokens|Design Tokens]])을 통한 확장성 확보**
  디자인 시스템의 근간은 '디자인 토큰'입니다. 이는 색상, 여백, 타이포그래피 등 시각적 디자인 원자들을 정의하는 플랫폼 독립적인 변수입니다 [1, 2]. 효과적인 관리를 위해 토큰은 3단계 계층으로 구성됩니다.
  1. 전역 토큰(Global Tokens): 맥락 없는 원시 값(예: `#3b82f6`) [7-9]
  2. 별칭/시맨틱 토큰(Alias Tokens): 특정 의도나 맥락을 설명하는 토큰(예: `primary-color`) [7-9]
  3. 컴포넌트 토큰(Component Tokens): 특정 UI 요소에 국한되어 세밀한 조정을 허용하는 토큰 [7, 9, 10]
  이러한 계층 구조는 대규모 프로젝트에서 개발자가 임의의 색상을 무분별하게 도입하여 발생하는 "300가지 그림자(300 shades of gray)"와 같은 일관성 문제를 효과적으로 방지합니다 [11].

* **컴포넌트 중심의 반응형 설계 적용**
  최신 디자인 시스템 및 프론트엔드 설계에서는 반응형 동작을 개별 페이지의 레이아웃 문제가 아닌 '컴포넌트의 속성'으로 취급합니다 [12, 13]. 디자인 시스템 내의 컴포넌트(버튼, 모달, 데이터 테이블 등) 자체가 컨테이너 크기([[Container Queries|Container Queries]] 등 활용)나 맥락을 인지하여 반응하도록 설계되면, 이를 가져다 쓰는 모든 팀은 자동으로 일관된 반응형 동작을 얻게 되어 레이아웃 불일치를 근본적으로 해결할 수 있습니다 [13, 14].

* **단일 진실 공급원([[Single_Source_of_Truth|Single Source of Truth]])과 자동화**
  웹, iOS, Android 등 다중 플랫폼을 지원하기 위해 디자인 시스템의 토큰들은 주로 JSON과 같은 중립적 형식으로 저장됩니다 [15, 16]. 그런 다음 [[Style Dictionary|Style Dictionary]]와 같은 도구를 사용하여 CSS 변수, Android용 XML, iOS용 Swift 등 각 플랫폼에 맞는 코드로 자동 변환(Transformation)합니다 [3, 15, 16]. 이 자동화 파이프라인은 수작업으로 인한 오류를 제거하고 모든 제품 생태계에서 완벽한 시각적 일관성을 유지할 수 있게 해줍니다 [3, 16].

## 🔗 Knowledge Connections
- **Related Topics:** [[디자인 토큰 (Design Tokens)|디자인 토큰 (Design Tokens]], CSS 아키텍처 (CSS Architecture), 컴포넌트 기반 아키텍처 (Component-Based Architecture), 반응형 디자인 (Responsive Design), [[Tailwind CSS|Tailwind CSS]], [[BEM|BEM]]
- **Projects/Contexts:** 엔터프라이즈 프론트엔드 설계 (Enterprise [[Frontend|Frontend]] [[Architecture|Architecture]]), 다중 플랫폼 배포 워크플로우 (Multi-Platform Workflows), 디자인-코드 핸드오프 (Design-to-Code)
- **Contradictions/Notes:** 대규모 CSS 시스템을 구축할 때 [[SCSS|SCSS]]나 BEM 방법론은 높은 수준의 제어력과 깔끔한 마크업을 제공하지만 개발자의 수동적인 규칙 준수에 의존해야 하는 위험성이 있습니다. 반면, [[Tailwind CSS|Tailwind CSS]]는 설정 파일 기반으로 디자인 시스템(테마)을 강제하여 개발 속도와 일관성을 보장하고 CSS 파일 크기를 억제하지만, HTML 마크업이 매우 길어지고(verbose) 복잡해진다는 트레이드오프를 가집니다 [11, 17, 18].

---
*Last updated: 2026-04-26*