01 — What is a Design System
디자인 시스템은 “제품 전반에 걸쳐 일관된 결정을 내리기 위한, 공유되는 값·규칙·도구의 집합” 이다. 컴포넌트 라이브러리는 그 집합의 한 출력물이지 집합 자체가 아니다. Material Design은 디자인 시스템이고, Material UI는 그것의 React 구현체다 — 이 둘을 동의어로 쓰는 순간 모든 의사결정이 어그러진다.
Why — 왜 정의부터 시작하나
디자인 시스템 프로젝트가 1~2년 안에 폐기되는 가장 흔한 이유는 기술적 실패가 아니라 정의의 실패 다. 팀마다 “디자인 시스템”이 가리키는 대상이 다르면, 같은 회의에서 다른 이야기를 한다.
| 팀 | ”디자인 시스템”이 의미하는 것 | 결과 |
|---|---|---|
| 디자이너 | Figma 라이브러리·스타일 가이드 | ”왜 코드가 Figma와 안 맞나?” |
| 프론트엔드 | @company/ui npm 패키지 | ”왜 디자이너가 라이브러리에 없는 색을 쓰나?” |
| PM | ”브랜드 일관성 프로젝트" | "왜 6개월째 컴포넌트 카탈로그만 만드나?” |
| 디자인 리드 | 원칙·가이드라인·voice & tone | ”왜 개발자는 가이드라인을 안 읽나?” |
이들 중 어느 하나만 “디자인 시스템”이라 부르면 나머지 90%가 빠진다.
올바른 정의는 위 4가지가 모두 한 약속의 다른 표현이라는 인식에서 출발한다. 그 약속의 이름이 디자인 시스템이며, Figma 라이브러리·npm 패키지·가이드 문서는 그 약속을 다른 청중에게 전달하는 매체다.
How — 정의의 3가지 핵심
1) 디자인 시스템 = 약속 (Promise)
Nathan Curtis(EightShapes, 2016)의 고전적 정의:
“A design system offers a library of visual style, components, and other concerns documented and released by an individual, team, or community as code and design tools so that adopting products can be more efficient and cohesive.”
핵심은 “adopting products” 다. 디자인 시스템은 자기 자신이 제품이 아니라 다른 제품에게 약속을 제공하는 메타-제품이다.
2) 디자인 시스템 ≠ 컴포넌트 라이브러리
이 둘의 차이는 물건 vs 약속의 차이와 같다.
| 측면 | 컴포넌트 라이브러리 | 디자인 시스템 |
|---|---|---|
| 핵심 산출물 | Button, Modal 등 코드 | 토큰·원칙·규칙·문서·코드의 전체 집합 |
| 책임자 | 개발 팀 | 디자인+개발+제품의 공동 책임 |
| 변경 비용 | 한 라이브러리 버전 올림 | SemVer·RFC·마이그레이션 가이드 |
| 성공 기준 | 컴포넌트 수, GitHub stars | adoption rate, brand consistency |
| 폐기 가능성 | 다른 라이브러리로 swap | 다른 디자인 시스템으로 마이그레이션 — 거의 회사 재창업 수준 |
대표 예시:
- Material Design = 디자인 시스템 (Google이 발행하는 문서 + 토큰 + 원칙)
- Material UI / MUI = 그 시스템의 React 구현 컴포넌트 라이브러리
- Material You = Material Design의 다음 세대 약속
Material UI를 다른 라이브러리(예: Mantine)로 교체하더라도 Material Design의 디자인 시스템 약속은 그대로 살아남는다 — 토큰·spacing·typography는 코드가 아니라 약속이기 때문이다.
3) 디자인 시스템의 구성요소 — Brad Frost의 5요소
이 5요소가 모두 있어야 디자인 시스템이라 부를 자격이 있다. 하나가 빠지면 다른 이름이다 — 가령 ③④⑤만 있고 ①②가 없으면 그건 컴포넌트 라이브러리다.
What — 역사·표준·사실상 표준
디자인 시스템의 4번의 변곡점
| 연도 | 사건 | 의미 |
|---|---|---|
| 1996 | Yahoo Pattern Library | 최초의 공개 패턴 라이브러리. 정적 HTML 페이지. |
| 2013 | Brad Frost, Atomic Design | 컴포넌트의 수직적 분류학 제안(Atoms → Pages). |
| 2014 | Salesforce Lightning Design System (Jina Anne) | Design Tokens 개념 도입. “값을 먼저, 컴포넌트는 그 다음.” |
| 2016 | Material Design 1.0 (Google) | 거대 조직의 공개 디자인 시스템 — 문서·코드·Figma의 3축 통합. |
| 2019 | W3C Design Tokens Community Group (DTCG) 결성 | 토큰의 표준 JSON 포맷 정의 시작. |
| 2022 | Style Dictionary 4.0 + DTCG 호환 | 다중 플랫폼(웹·iOS·Android)으로 동일 토큰을 빌드. |
| 2024 | Tailwind v4 @theme + Panda CSS 안정화 | CSS-first 토큰 시대 — DTCG와 직접 매핑. |
사실상 표준 사례 (Industry-leading Systems)
| 시스템 | 운영사 | 특징 |
|---|---|---|
| Material Design | 공개·다중 플랫폼·tonal palette 자동 생성. 디자인 시스템 = 제품 그 자체 의 극단. | |
| Primer | GitHub | 매우 보수적인 토큰 변경. 25년 GitHub UI를 지탱. |
| Carbon | IBM | 엔터프라이즈 SaaS의 표준. 그리드 시스템·data viz까지 정의. |
| Atlassian Design System | Atlassian | RFC 프로세스가 공개되어 있어 거버넌스의 모범. |
| Spectrum | Adobe | 다국어·다플랫폼·접근성의 극한 케이스. |
| Polaris | Shopify | 수만 개 상점 어드민의 일관성. 콘텐츠 가이드라인까지 깊다. |
| Lightning Design System | Salesforce | 디자인 토큰의 발상지. 모든 현대 시스템의 조상. |
형식상 표준 (Formal Standards)
| 표준 | 발행 | 다루는 것 |
|---|---|---|
| W3C DTCG Format | 2023 Editor’s Draft | 토큰 JSON의 $value, $type, $description, $extensions |
| WCAG 2.2 | W3C 2023 | 접근성 — 디자인 시스템의 의무 사항 |
| APCA | W3C Draft | 색 대비의 차세대 알고리즘 (현행 WCAG 4.5:1 대체 후보) |
DTCG 토큰 JSON의 최소 예시:
{
"color": {
"primary": {
"500": {
"$value": "#3370b8",
"$type": "color",
"$description": "Brand primary, used for CTA buttons"
}
}
}
}$value/$type prefix가 W3C DTCG의 표지. 이 포맷이 표준이 되면 Figma/Tokens Studio/Style Dictionary/Tailwind/Panda 모두 같은 JSON을 읽는다.
What-if — 정의를 흐리면 어떻게 깨지나
1) “Material UI를 깔았으니 디자인 시스템이 생겼다”
- 증상: 컴포넌트는 깔렸는데 디자이너의 Figma와 색이 안 맞음.
- 원인: 디자인 시스템의 ②Guidelines·①Principles·③Tokens가 없음. 컴포넌트만 있음.
- 대응: 토큰 레이어를 별도로 도입. MUI의
theme객체를 DTCG 토큰에서 생성하도록 빌드.
2) “디자인 시스템 팀에 디자이너가 없다”
- 증상: 6개월 후 새 화면 디자인에서 디자이너가 시스템 외 색·간격을 임의 사용.
- 원인: 디자인 시스템이 개발 부서 내부 프로젝트로 운영됨. ①Principles의 주인이 없음.
- 대응: 디자인 시스템 팀에 디자이너 1명 이상 전임. 디자인 리뷰 게이트를 워크플로에 박음.
3) “Figma 라이브러리만 있고 코드 토큰이 없다”
- 증상: 디자이너의 Figma 변경이 6개월 뒤에야 코드에 반영됨.
- 원인: 디자인과 코드 사이에 번역기가 사람뿐임 (디자이너 → PM → 개발자 구두 전달).
- 대응: Tokens Studio / Figma Variables → JSON export → Style Dictionary → CSS variables의 자동 파이프라인. DTCG 포맷이 공통어.
4) “디자인 시스템 = 컴포넌트 카탈로그”의 끝없는 컴포넌트 만들기
- 증상: 12개월 동안 컴포넌트 50개 추가, 그러나 실제 제품에선 절반만 채택.
- 원인: ⑤Documentation·④Components만 보고 ①Principles·③Tokens를 안 짠 결과. 왜 이 컴포넌트가 필요한가의 답이 없으니 PM이 swap 라이브러리로 회피.
- 대응: 새 컴포넌트의 RFC에 “이 컴포넌트가 풀려는 사용자 문제” 를 필수 항목으로. 채택률 30% 미만 컴포넌트는 deprecation.
5) “오픈소스 시스템을 fork했는데 우리 브랜드가 사라진다”
- 증상: Mantine/Chakra를 fork했는데, 1년 뒤에는 원본 색·간격이 살짝씩 우리 디자인을 잠식.
- 원인: 외부 라이브러리의 기본값이 ③Tokens를 ②Guidelines보다 먼저 결정해버림.
- 대응: 외부 라이브러리는 컴포넌트 골격만 빌리고, 토큰은 반드시 자체 정의.
theme.extend로 덧칠하지 말고 토큰 자체를 교체.
Insight — “Design System”이라는 말의 짧고 강렬한 역사
“디자인 시스템(design system)이라는 말은 사실 1960년대 Dieter Rams가 Braun에서 쓰던 용어다.”
Dieter Rams의 Braun design system은 라디오·스피커·전자레인지가 시각적 가족 유사성을 갖도록 한 가이드라인이었다. 흥미롭게도 그의 10가지 디자인 원칙(Good design is innovative, useful, aesthetic, unobtrusive…)은 현대 디지털 디자인 시스템의 ①Principles 레이어와 거의 동일한 위계를 차지한다. 우리가 2025년 Figma에서 토큰을 export하면서 사용하는 어휘가 60년 전 산업 디자인의 어휘와 같다는 것이 흥미롭다.
디지털 디자인 시스템의 진정한 변곡점은 2014년이다. Jina Anne(당시 Salesforce)이 Design Tokens라는 용어를 처음 공개적으로 쓴 SXSW 발표는 이렇게 시작한다:
“We have thousands of hex codes. None of us know which one is ‘the brand blue’. So we’re going to give them names.”
이 한 문장이 모든 것을 바꿨다. 색·간격·폰트에 이름을 주는 것 — 그게 디자인 시스템의 출발점이며, 이후 모든 진보(DTCG, Style Dictionary, Panda CSS의 tokens.color.primary.500)는 이 한 아이디어의 정제다.
그리고 잘 알려지지 않은 사실 — Salesforce는 이 작업을 Atlassian과 거의 동시에 하고 있었다. Atlassian의 ADG (Atlassian Design Guidelines) 도 2014년 무렵 토큰 개념을 도입했고, 두 팀이 같은 결론에 다른 경로로 도달했다는 사실이 이후 W3C DTCG의 결성을 자연스럽게 만들었다 — 모두가 같은 패턴을 발견했으니, 이제 표준화하자는 합의가 빠르게 모였다.
또 하나 — “왜 React 컴포넌트 라이브러리는 5년 안에 폐기되지만, Material Design은 10년이 지나도 살아남는가”. 답은 추상화 레벨이다. 컴포넌트 라이브러리는 프레임워크에 종속된다(React 19 마이그레이션, Server Components 이슈 등). 디자인 시스템은 프레임워크 위에 있다. 토큰은 React·Vue·Swift·Kotlin 어디로든 컴파일된다. 추상의 높이가 수명을 결정한다 — 이게 디자인 시스템을 컴포넌트 라이브러리가 아닌 토큰 중심으로 운영해야 하는 가장 강력한 이유다.
요약 + Mermaid
- 디자인 시스템 = 원칙 + 가이드라인 + 토큰 + 컴포넌트 + 문서 의 5요소 약속.
- 컴포넌트 라이브러리는 그 약속의 한 출력물이지 약속 자체가 아니다.
- 변곡점: 2013 Atomic Design, 2014 Salesforce Tokens, 2019 W3C DTCG, 2024 CSS-first 시대.
- 프레임워크에 종속되지 않는 토큰이 수명의 비결.
- 정의가 흐려지면 디자인 시스템은 1~2년 안에 컴포넌트 폐기물이 된다.