00-foundations — 디자인 시스템의 기초
디자인 시스템은 컴포넌트 라이브러리가 아니라 “디자이너와 개발자 사이에 체결된 계약” 이다. 그 계약을 코드로 직렬화하기 위해 우리는 Foundations → Tokens → Recipes → Theming → Distribution 의 5-레이어로 분해한다. 이 챕터는 그 분해의 정당성과 역사를 깐다.
한 문장 답 (Pyramid Top)
“디자인 시스템”이라는 단어가 가리키는 실체는 컴포넌트의 모음이 아니라 값과 규칙에 관한 약속이다. 이 약속을 깨지 않고 진화시키기 위해 우리는 5개 레이어를 분리한다 — 각 레이어는 변경 빈도와 변경 책임자가 다르기 때문이다. Brad Frost의 Atomic Design(2013)이 컴포넌트 계층을 정리했다면, Salesforce Lightning에서 시작된 Design Tokens(2014~)는 값의 계층을 정리했고, W3C DTCG(2019~)가 그 값의 표준 포맷을 정의했다. Panda CSS와 Tailwind는 Layer 3(Recipes)에서 갈리고 Layer 2(Tokens)에서 다시 만난다 — 이게 두 도구의 공존이 가능한 이유다.
챕터 지도 (Mermaid)
Why — 왜 별도의 챕터인가
상위 챕터(01-tokens 이후)는 모두 “5-레이어 모델” 을 전제한다. 토큰 계층을 primitive/semantic/component로 나누는 것도, theming을 별도 레이어로 빼는 것도, Panda recipe와 Tailwind utility를 동일 토큰 위에서 빌드하는 것도 — 이 5-레이어가 옳다는 합의가 먼저 있어야 의미가 있다.
그런데 이 5-레이어는 자명한 것이 아니다. 2013년 Brad Frost는 Atoms/Molecules/Organisms/Templates/Pages의 수직적 컴포넌트 계층 을 제안했고, 2014년 Jina Anne(Salesforce)는 Design Tokens라는 수평적 값 계층 을 제안했다. 두 사고법은 경쟁했고, 2020년대에 들어 종합되었다 — 그 종합이 바로 우리가 쓰는 5-레이어다.
이 챕터를 건너뛰면 다음 챕터들에서 “왜 토큰 레이어가 따로 있나? Recipe에서 직접 색 hex를 써도 되지 않나?”, “Panda와 Tailwind 중 하나 고르면 끝 아닌가?” 같은 질문이 끊임없이 돌아온다. 모두 이 챕터가 깔리지 않아 생기는 근본 질문이다.
또 하나, 디자인 시스템 프로젝트의 70% 이상이 1~2년 안에 사실상 폐기된다(Sparkbox 2022 Design Systems Survey). 그 실패의 거의 모든 케이스가 “계약이 무엇인지” 와 “성공 지표가 무엇인지” 를 정의하지 않은 채 컴포넌트만 찍어낸 결과다. 04·05 문서는 그 실패를 피하기 위한 조직적 장치를 다룬다.
How — 어떻게 읽나
다음 5개 문서를 순서대로 읽으면 약 60분 걸린다. 1→5로 의존성이 누적된다.
| # | 파일 | 읽는 데 | 핵심 키워드 |
|---|---|---|---|
| 01 | 01-what-is-a-design-system | 15분 | 정의, Material Design vs Material UI, Atomic Design 2013, DTCG 2019 |
| 02 | 02-five-layers | 15분 | Foundations, Tokens, Recipes, Theming, Distribution, Panda·Tailwind 교차점 |
| 03 | 03-atomic-design-vs-tokens-first | 10분 | Brad Frost, Jina Anne, 수직 vs 수평, 종합 모델 |
| 04 | 04-design-system-as-contract | 10분 | SemVer, 토큰 ABI, 브레이킹 체인지, RFC |
| 05 | 05-success-criteria | 10분 | adoption rate, time-to-component, brand consistency, anti-pattern |
의존성: 02는 01의 정의를 가정한다. 03은 02의 5-레이어가 어디서 왔는지를 푼다. 04는 5-레이어를 조직적으로 유지하는 법, 05는 그것을 측정하는 법.
What — 한 페이지 요약
| 문서 | 한 줄 결론 |
|---|---|
| 01 | ”디자인 시스템 = 값과 규칙에 관한 약속.” Material Design은 디자인 시스템이고 Material UI는 그 약속의 한 구현체일 뿐이다. 2013 Atomic Design, 2014 Salesforce Lightning Tokens, 2019 W3C DTCG가 핵심 변곡점. |
| 02 | 5-레이어는 변경 빈도와 변경 책임자가 다르다 — Foundations(수년에 한 번, 디자인 리드), Tokens(분기마다, 디자이너), Recipes(주마다, 개발자), Theming(브랜드 추가 시), Distribution(릴리스마다). Panda·Tailwind는 Layer 3에서 갈라진다. |
| 03 | Atomic Design은 컴포넌트의 분류학, Tokens-first는 값의 정규화. 둘은 경쟁이 아니라 다른 축이다. 현대 디자인 시스템은 둘을 종합하며, Atoms~Pages의 5계층을 Tokens가 관통한다. |
| 04 | 토큰 이름(color.primary.500)은 SemVer의 공개 API다. 이름이 바뀌면 메이저 버전, 값만 바뀌면 마이너. 이 계약 의식이 없으면 디자인 시스템은 “내일 다시 갈아엎을 임시 prefix” 로 전락한다. |
| 05 | 성공의 측정은 컴포넌트 수가 아니라 adoption rate(전체 프로덕트 코드 중 시스템 컴포넌트가 차지하는 비율)다. 부차적으로 time-to-component, brand consistency score, contributor diversity. 측정하지 않으면 폐기된다. |
What-if — 이 챕터의 한계
- 이 챕터는 개념과 역사만 다룬다. 실제 토큰 JSON 스펙, OKLCH 색 공간, Panda recipe API 같은 구체는
01-tokens이후의 챕터. - 조직 사이즈별 디자인 시스템 전략(10인 스타트업 vs 5,000인 엔터프라이즈)은 본격적으로 다루지 않는다. 적용 가능한 범용 원리에 집중한다.
- 디자인 시스템 팀 구성(전담 팀 vs 페더레이션 vs 컨트리뷰션 모델)은
08-pipeline-distribution에서 governance 챕터로 분리. - Figma 측의 디자인 토큰 워크플로(Tokens Studio, Figma Variables)는 토큰 export 지점까지만. UI 사용법 자체는 다루지 않는다.
Insight — 한 단락 이야기
“30년 동안 우리는 같은 함정을 반복해 왔다 — 컴포넌트부터 만들기.”
1996년 Yahoo 디자인 가이드라인, 2003년 IBM eRA Visual Standards, 2014년 Material Design — 매 세대마다 거대 조직은 “디자인 일관성을 위한 표준”을 만들었지만, 그 모두가 동일한 함정을 밟았다. 컴포넌트의 픽업·드롭다운·테이블을 먼저 정의하고, 왜 그 색·간격·폰트가 그 값인지에 대한 layer를 사후에 추가하려 했다. 결과는 매번 같았다 — 6개월 뒤 디자이너가 “이 파란색 좀 살짝 톤다운하자”고 하면 컴포넌트 200개를 다 손봐야 했다. Salesforce가 2014년 처음으로 “값을 먼저, 컴포넌트는 그 다음에” 라는 순서를 뒤집은 이후, 디자인 시스템의 모든 진보는 이 순서를 더 강하게 지키는 방향으로 일어났다. 우리가 5-레이어를 그리는 이유는 이 30년의 교훈을 구조적으로 못 잊게 하기 위함이다.
한 단락 요약
디자인 시스템은 컴포넌트의 모음(
01)이 아니라 값과 규칙의 약속이며, 그 약속은 5-레이어(02)로 분해된다. 이 분해는 Atomic Design과 Tokens-first의 종합(03)이고, 계약(04)으로 유지되며, 측정 가능한 지표(05)로 살아남는다. 이 챕터를 끝내면 다음 챕터부터 등장하는 “왜 토큰 레이어가 따로 있나?” 같은 질문은 더 이상 생기지 않는다 — 그 질문 자체가 이 챕터의 답이기 때문이다. 다음 챕터(01-tokens)는 이 5-레이어의 Layer 2(Tokens) 를 W3C DTCG 표준 위에서 깊게 본다.