디자인 문서(Design Document) vs 디자인 체인(Design Chain)
요약
Google Labs가 공개한 DESIGN.md 오픈 소스 프로젝트를 분석하며, 디자인 토큰 포맷의 한계와 이를 보완하기 위한 '디자인 체인' 개념을 제안합니다. 단순한 포맷을 넘어 디자인 의도를 구체적인 값으로 변환하는 단계적 접근법의 중요성을 강조합니다.
핵심 포인트
- DESIGN.md는 AI 에이전트가 디자인 토큰을 읽고 쓸 수 있는 표준화된 포맷을 제공함
- 기존 포맷은 이미 결정된 디자인 의도를 기록할 뿐, 의도를 결정하는 과정은 다루지 못함
- 0에서 1을 만드는 단계에서는 포맷보다 모호한 아이디어를 값으로 바꾸는 '체인'이 필요함
- 디자인 방향성을 설정하는 '방향성 문서'부터 구체적 토큰까지의 단계적 접근이 핵심임
Google이 DESIGN.md를 오픈 소스로 공개했습니다 — YAML 토큰, CLI 린터(linter), 원클릭 Tailwind 내보내기 기능까지. 훌륭합니다. 하지만 포맷(format)은 이미 자신이 무엇을 원하는지 알고 있는 사람들에게만 도움이 됩니다. 0에서 1을 만드는 제품에 필요한 것은 포맷이 아니라 — 체인(chain)입니다.
Google Labs가 흥미로운 것을 오픈 소스로 공개했습니다: AI 코딩 에이전트가 디자인 토큰(design tokens)을 읽고 쓸 수 있도록 하는 표준화된 포맷입니다.
colors:
background: "#ffffff"
ink: "#08060d"
...
해당 YAML의 각 명명된 값 — #ffffff, 18px, 4px — 은 **디자인 토큰 (design token)**입니다. 이는 디자인 시스템에서 가장 작은 원자적 값(atomic value)으로, 이름과 숫자를 포함하고 있어 에이전트가 UI를 구축할 때 추측하지 않도록 돕습니다.
여기에 CLI도 포함되어 있습니다: designmd lint, designmd export --format css-tailwind, designmd diff.
완전해 보입니다. 에이전트는 토큰을 읽고 UI를 작성합니다. 디자인 변경 사항은 diff(차이점)로 확인됩니다. 테마는 내보내기(export)됩니다.
하지만 AI 코딩 어시스턴트와 함께 처음부터 무언가를 시작해 본 적이 있다면, 여러분은 어색한 진실에 부딪혔을 것입니다:
DESIGN.md는 _무엇을 쓸지(what to write)_를 알려줄 뿐, _무엇을 결정할지(what to decide)_를 알려주지 않습니다.
강조 색상이 #aa3bff인지 #2563eb인지에 대한 결정은 DESIGN.md가 작성되기 _전_에 이루어집니다. 그리고 고통스러운 부분은 바로 그 "전" 단계입니다.
1. 포맷은 목적지이지, 경로가 아니다
Google의 PHILOSOPHY.md에는 제가 강력히 동의하는 문장이 있습니다: "산문(prose)은 어조를 설정하고, 토큰은 그 산문의 맥락(context)이다." 모호한 형용사를 쓰지 마세요. 대신 구체적인 참조를 작성하세요 — "레트로 스타일"이 아니라 "1970년대 강의 유인물 같은" 식으로 말이죠.
하지만 그 산문은 어디에서 오는 걸까요? 누가 참조를 선택할까요? 제품 아이디어가 여전히 모호할 때, 누가 "1970년대 강의 유인물 같은" 스타일로 결정할 수 있을까요?
DESIGN.md는 여러분이 이미 디자인 의도(design intent)를 가지고 있다고 가정합니다. 그것을 발견하도록 도와주지는 않습니다.
여기에 간극이 있습니다:
┌─────────────────────────────────┐
│ 의도가 있음 → 토큰 작성 │ ← 포맷이 다루는 영역
└─────────────────────────────────┘
...
디자이너, 디자인 시스템(Design System), 그리고 성숙한 제품을 갖춘 팀에게는 전반부(first half)가 문제가 되지 않습니다. 하지만 0→1 팀이나 1인 개발자에게는 그것이 문제의 전부입니다.
2. 체인(Chain)의 해답: 네 개의 링 (Four Rings)
이 포맷은 후반부만을 다룹니다. 전반부를 다루기 위해서는 모호한 아이디어에서 구체적인 값(values)으로 단계별로 나아가는 **체인(chain)**이 필요하며, 각 링(ring)은 하나의 특정 문제를 해결합니다.
링 1: 방향성 문서 (Direction Document) — 구체적인 값 없음
첫 번째 결과물은 방향성 문서입니다. 시각적 톤(visual tone)은 어떠한가? 어떤 제품을 참고(reference)하고 있는가? 어떤 스타일은 피해야 하는가?
이 단계에서는 의도적으로 색상 값(color values)을 전혀 작성하지 않습니다. 이는 태만이 아니라 절제입니다. 만약 첫 번째 라운드에서 #aa3bff라고 적는다면, 그 헥스(hex) 값은 아마도 참조 분석의 결과가 아니라 당신의 "직감"일 가능성이 높습니다. 이는 "왜 저 보라색이 아니라 이 보라색인가?"라는 질문을 견뎌낼 수 없습니다.
방향성 문서의 출력물은 톤(tone), 참조 제품, 시각적 분위기(visual mood), 클리셰 방지 체크(anti-cliché checks)입니다. 모두 산문(prose) 형태이며, 구체적인 값은 전혀 없습니다.
(저는 이 단계를 ReqForge 프레임워크에서 "디자인 브리프(Design Brief)" 스킬로 구현했습니다. 이는 사용자가 의도를 명확히 할 수 있도록 돕는 설문 조사와 참조 분석의 결합입니다. 출력물은 산문으로만 구성되며, 헥스 값은 포함되지 않습니다.)
링 2: 목업 (Mockup) — 픽셀 수준의 검증
디자인 도구(Pencil, Figma 또는 적합한 도구)를 사용하여 검토 가능한 시각적 목업을 제작합니다. 여기서의 가치는 "예쁘게 만드는 것"이 아니라, 추상적인 설명을 구체적으로 반박할 수 있는 무언가로 바꾸는 것에 있습니다:
- "이 간격(spacing)은 너무 넓어요" → 목업을 가리키며 말할 수 있습니다.
- "이 색상은 틀렸어요" → 색상을 변경할 수 있습니다.
- "이 폰트는 너무 답답해 보여요" → 눈으로 확인할 수 있습니다.
사람들이 말하는 "깔끔하고 현대적인 팔레트(clean modern palette)"의 의미와, 실제 특정 픽셀을 보았을 때 승인하는 것 사이의 간극은 생각보다 훨씬 넓습니다. 열 배는 더 넓습니다.
링 3: 승인 후 (Post-Approval) — 값 고정 (Freeze the Values)
목업이 사람의 검토를 통과한 후에야 비로소 값 고정(value-freeze) 단계로 진입합니다.
"Freeze"의 의미는 다음과 같습니다: 이 색상 값은 최소 세 차례의 검증 단계(방향성(direction) → 픽셀(pixels) → 사람의 승인(human sign-off))를 통과했다는 뜻입니다. 이는 더 이상 한 개인의 직관적인 결정이 아닙니다.
고정된 명세(spec) 파일은 **단일 진실 공급원 (single source of truth)**이 됩니다. UI를 작성하는 구현자(implementer)와 이를 감사하는 검토자(reviewer) 모두 이 파일을 가장 먼저 참조하여 값을 읽습니다. 디자인 도구의 목업(mockup)은 계속 진화할 수 있지만, 표준이 되는 값(canonical values)은 이 하나의 파일에 존재합니다.
Ring 4: 검증 (Verification) — 린트(Lint), 디프(Diff), 내보내기(Export)
이 단계에서 표준 형식이 빛을 발합니다. 고정된 명세는 자동화될 수 있습니다:
npx -p @google/design.md designmd lint DESIGN.md # 준수 여부 확인 (conformance check)
npx -p @google/design.md designmd diff DESIGN.md v2 # 변경 사항 추적 (change tracking)
npx -p @google/design.md designmd export --format css-tailwind # 테마 내보내기 (theme export)
하지만 체인(chain)의 관점에서 볼 때, 이것은 입구가 아니라 **선택적인 출구 (optional exit)**입니다. 린트(lint)가 실패했을 때 올바른 대응은 "배포를 차단하는 것"이 아니라, "값이 세 차례의 검증 단계를 거쳤는지 먼저 확인하는 것"입니다. 왜냐하면 많은 프로젝트는 UI조차 없으며, 이 계층이 전혀 필요하지 않을 수도 있기 때문입니다.
3. 형식(Format)과 체인(Chain)은 상호 보완적입니다
이 둘은 경쟁 관계가 아닙니다. 서로 다른 문제를 해결하며, 서로를 필요로 합니다.
| 차원 (Dimension) | 형식 (Format, DESIGN.md) | 체인 (Chain, 4개의 링) |
|---|---|---|
| 핵심 질문 | 값을 어떻게 작성할 것인가 | 값을 어떻게 결정할 것인가 |
| ... | ... | ... |
Google의 DESIGN.md 철학은 다음과 같이 말합니다: "구체적인 참조(specific reference) > 형용사(adjectives)." "레트로 스타일"이라고 쓰지 말고, "1970년대 강의 유인물 같은" 스타일이라고 쓰십시오.
체인 역시 같은 말을 하고 있습니다. 다만 그 단계를 한 단계 더 앞당길 뿐입니다. 만약 아직 그 "구체적인 참조"가 없다면, 토큰(token)을 작성하기 전에 그것을 먼저 찾아내라는 것입니다.
두 경로 모두 동일한 진리를 발견했습니다: 구체적인 것이 추상적인 것을 이깁니다 (concrete beats abstract). 형식은 당신에게 구체적인 토큰을 작성할 것을 요구합니다. 체인은 또한 그 토큰들의 출처(source) 역시 구체적으로 만들 것을 요구합니다.
4. 형식만으로 충분한 때는 언제인가?
타당한 질문입니다. 모든 프로젝트에 전체 체인이 필요한 것은 아닙니다.
✅ 형식(Format)만으로도 충분한 경우
- 디자이너가 있거나 기존의 디자인 시스템 (Design System)이 있는 경우
- 기존 제품을 재설계 (Redesigning) 하는 경우 — 방향성이 이미 알려져 있음
- 팀원들이 산문 (Prose)만으로도 의도를 조율할 수 있는 경우
- 디자인 결과물을 위해 다른 도구를 사용 중이며, 후속 단계 (Downstream) 소비를 위한 명세서 (Spec) 파일만 필요한 경우
❌ 전체 체인 (Full Chain) 실행을 고려해야 하는 경우
- 참조할 제품이 없는 0→1 단계의 구축인 경우
- 검증되지 않은 디자인 직관을 가진 1인 PM + 개발자인 경우
- 여러 명이 참여하며, 각자가 생각하는 "깔끔함 (Clean)"의 기준이 서로 다른 경우
- 지난 릴리스가 디자인 재작업 (Rework)으로 인해 지연된 경우
이것은 품질의 임계값 (Quality threshold)이 아니라, **리스크 임계값 (Risk threshold)**입니다. 방향 설정 (Direction) 단계를 건너뛰고 값을 직접 작성하는 것은 당신의 직관이 충분히 정확하다는 데 거는 도박입니다. 어떤 팀과 제품에게는 그 도박이 성공할 수도 있습니다. 하지만 대부분의 0→1 시나리오에서는 그렇지 않습니다.
5. 결론 (Closing)
Google의 DESIGN.md는 훌륭한 형식 (Format) 제안입니다. 이는 실제 문제를 해결합니다. 안정적인 값의 소스 (Source of values)가 없으면, AI 에이전트들은 색상을 추측하게 되고, 충분히 많은 색상이 추측되면 당신의 UI는 무지개처럼 변해버립니다.
하지만 형식은 목적지이지, 경로가 아닙니다.
값을 신뢰할 수 있게 만드는 것은 잘 정의된 YAML 스키마 (Schema)나 통과된 린트 체크 (Lint check)가 아닙니다. 그것은 "정말 확실합니까?"라는 질문을 세 번 받는 것입니다. 한 번은 방향 문서 (Direction document)에서, 한 번은 목업 (Mockup) 전에, 그리고 한 번은 목업 승인 시점에 말입니다.
만약 세 번 모두 답변이 같다면, 그 색상은 아마도 맞을 것입니다.
만약 당신이 첫 번째 단계에서 바로 명세서 (Spec) 파일에 작성했다면, 그것이 세 번째 질문까지 살아남았을지 당신은 결코 알 수 없을 것입니다.
2026년 6월. 형식은 당신이 올바르게 작성하도록 돕습니다. 체인은 당신이 작성하기 전에 올바른 상태가 되도록 돕습니다. 당신은 둘 다 필요하지만, 순서가 중요합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기