디자인 토큰은 오래전부터 있던 개념이지만, 최근에는 문서가 아니라 실행 가능한 컨텍스트로 취급되기 시작했습니다. DTCG Design Tokens Format Module 2025.10은 그 흐름을 표준 쪽에서 정리한 첫 안정 버전이고, DESIGN.md는 그 아이디어를 에이전트가 직접 읽는 파일로 옮긴 사례입니다.
먼저 결론부터 말하면, DTCG 2025.10은 디자인 토큰을 서로 다른 도구가 주고받을 수 있는 공통 언어로 다듬었고, DESIGN.md는 그 언어를 AI 코딩 에이전트가 바로 읽을 수 있는 휴대용 컨텍스트로 확장합니다. 다만 둘은 경쟁 관계가 아니라 역할이 다릅니다. 하나는 토큰의 형식이고, 다른 하나는 그 형식을 모델이 이해할 수 있게 설명하는 레이어입니다.
2026-07-23 · DTCG Design Tokens Format Module 2025.10, DTCG 공식 홈페이지, Atlassian 공식 글, Atlassian DESIGN.md 스냅숏 기준입니다.
이 글에서 다루는 내용:
- DTCG 2025.10이 왜 중요한지
- 토큰 형식이
DESIGN.md와 어떻게 연결되는지 - 에이전트 시대에 디자인 시스템이 왜 “읽히는 문서”가 되어야 하는지
DTCG 2025.10은 무엇을 표준화했나
DTCG는 디자인 토큰을 서로 다른 도구 사이에서 교환하기 위한 공통 형식을 정의하는 커뮤니티 그룹입니다. 공식 홈페이지는 이 포맷을 “tools between design tokens”의 상호운용성과 theming을 여는 JSON 형식으로 설명하고, 2025년 10월 28일에는 first stable version 2025.10 ↗이 공개됐다고 알립니다.
이 버전의 핵심은 토큰을 단순한 키-값 쌍으로 보지 않고, 타입과 그룹, alias, composite token 같은 개념으로 정리했다는 점입니다. 즉, 색상이나 간격뿐 아니라 그림자, border, gradient, typography처럼 복합적인 값도 같은 언어로 표현하려고 합니다.
flowchart LR
A[디자인 툴] --> B[DTCG 토큰 파일]
B --> C[번역 도구]
C --> D[코드베이스]
C --> E[문서/프리뷰]
D --> F[실제 UI]
E --> F이 구조가 중요한 이유는, 토큰이 이제 특정 툴의 내보내기 포맷이 아니라는 점입니다. DTCG 문서는 design tool, translation tool, documentation tool을 각각 구분하며, 도구마다 다른 방식으로 토큰을 읽고 변환할 수 있어야 한다고 전제합니다.
DESIGN.md는 토큰을 “에이전트용 문맥”으로 바꿉니다
Atlassian의 실험은 여기서 한 발 더 나갑니다. DESIGN.md는 DTCG 같은 토큰 체계를 직접 대체하려는 파일이 아니라, AI 코딩 에이전트가 디자인 언어를 빠르게 읽게 하려는 portable context입니다.
Atlassian이 공개한 DESIGN.md는 색상, 간격, 타이포그래피 같은 토큰과 함께, 어떤 밀도와 분위기를 유지해야 하는지에 대한 설명을 담습니다. 중요한 건 값 그 자체보다 “왜 이렇게 생겼는가”를 함께 전달한다는 점입니다. DTCG가 토큰의 형식을 다듬는다면, DESIGN.md는 그 형식을 모델 친화적인 설명으로 묶어 줍니다.
이 관점은 DTCG 스펙이 말하는 역할과도 맞닿아 있습니다. 스펙은 design tool, translation tool, documentation tool이 토큰을 읽고 해석하는 방식을 정리하지만, 실제 에이전트는 추가 설명 없이는 문맥을 놓치기 쉽습니다. 그래서 DESIGN.md 같은 파일이 의미를 갖습니다.
왜 둘을 같이 봐야 하나
DTCG 2025.10만 보면 표준 이야기처럼 보이고, DESIGN.md만 보면 실험적인 편의 기능처럼 보입니다. 하지만 둘을 같이 보면 그림이 선명해집니다. 디자인 시스템은 이제 사람만 보는 문서가 아니라, 도구와 에이전트가 함께 읽는 인터페이스가 되고 있습니다.
Atlassian은 이미 MCP와 스킬로 더 정교한 컨텍스트 전달을 하고 있었지만, 그래도 DESIGN.md를 실험했습니다. 이유는 단순합니다. 모든 환경이 같은 수준의 통합을 제공하지 않기 때문입니다. 파일 하나만 붙여 넣을 수 있는 환경, 빠르게 프로토타입을 만들어야 하는 상황, 브랜드 톤을 먼저 맞춰야 하는 화면에서는 DESIGN.md가 훨씬 가볍습니다.
반대로 프로덕션 코드에서는 토큰 파일만으로는 부족합니다. 컴포넌트 import, 접근성 규칙, lint, 금지 패턴, 테스트는 별도로 강제되어야 합니다. 즉, DTCG는 공통 언어를 만들고, DESIGN.md는 그 언어를 에이전트가 작업 전에 읽을 수 있도록 압축합니다.
실무적으로 어떻게 나누면 좋나
가장 현실적인 조합은 세 겹입니다.
- DTCG 토큰: 색상, 간격, 타이포그래피 같은 디자인 결정을 구조화합니다.
DESIGN.md: 에이전트가 그 결정을 읽는 방식과 디자인 의도를 설명합니다.- MCP 또는 문서 검색: 필요한 컴포넌트, 사용법, 제약을 작업 중에 가져옵니다.
이렇게 나누면 토큰 파일은 얇고 정확하게 유지할 수 있고, DESIGN.md는 사람이 읽어도 이해되는 수준의 문맥만 담을 수 있습니다. 에이전트가 필요한 순간에는 MCP로 더 깊은 정보를 가져오고, 초반 방향성은 DESIGN.md로 정하는 식입니다.
| 레이어 | 역할 | 잘 맞는 상황 |
|---|---|---|
| DTCG 토큰 | 공통 형식의 디자인 값 정의 | 테마, 브랜드 시스템, 다중 툴 동기화 |
DESIGN.md | 디자인 의도와 사용 맥락 전달 | 프로토타입, 외부 협업, 빠른 초기 세팅 |
| MCP / 문서 | 필요한 규칙과 컴포넌트 조회 | 프로덕션 코드, 세밀한 구현 제어 |
주의할 점
첫째, DESIGN.md는 all-at-once 방식이라 길어지면 오히려 무거워집니다. 둘째, 설명이 추상적이면 모델은 익숙한 SaaS 기본값으로 돌아가기 쉽습니다. 셋째, 구현 규칙이 빠지면 화면은 그럴듯해도 실제 코드 품질은 흔들릴 수 있습니다.
그래서 가장 좋은 사용법은 “토큰은 표준으로, 의도는 문서로, 제약은 도구로” 나누는 것입니다. DTCG와 DESIGN.md는 서로를 대체하는 게 아니라, 서로의 빈칸을 채웁니다.
마무리
DTCG Design Tokens Format Module 2025.10은 디자인 토큰을 도구 간 공통 언어로 굳히는 첫 안정 버전이고, DESIGN.md는 그 언어를 AI 코딩 에이전트가 읽을 수 있는 형태로 옮긴 실험입니다. 하나는 표준이고, 다른 하나는 그 표준이 실제 작업 흐름에서 어떻게 살아나는지 보여주는 예시입니다.
결국 중요한 질문은 “디자인 토큰을 만들 수 있나”가 아닙니다. “그 토큰과 디자인 의도가 에이전트에게도 같은 의미로 읽히는가”가 더 중요합니다.
이미 비슷한 흐름은 Atlassian DESIGN.md 공개: AI에게 디자인 시스템을 읽히는 법과 Google Stitch: AI 네이티브 ‘바이브 디자인’ 플랫폼이 바꿀 UI 디자인의 미래에서도 이어집니다. 이 글은 그 사이에서 표준화된 토큰 언어와 휴대용 디자인 문맥이 어떻게 만나는지를 더 좁게 본 버전입니다.
참고 링크
- DTCG 공식 홈페이지 ↗ - first stable version 공지
- Design Tokens Format Module 2025.10 ↗ - 포맷 스펙
- Atlassian 공식 글 ↗ - DESIGN.md 실험 배경
- Atlassian DESIGN.md ↗ - 공개 스냅숏