$value/$type라는 예약어로 토큰의 값과 종류를 표시하고, {group.token} 문법으로 서로 참조하게 하는" 규칙 그 자체다. 코드를 실행하는 프로그램이 아니라, 마치 "이 서류 양식을 이렇게 채우세요"라는 규정집을 읽는 것과 비슷하다. 2025년 10월 첫 정식 안정 버전(2025.10)이 나왔고, 지금 Figma·Adobe·Style Dictionary·Tokens Studio 등 수십 개 도구가 이 형식을 따라가는 중이다.
design-tokens/community-group · 시작 2019-09-02(W3C 커뮤니티 그룹 헌장) · 최신 안정 명세 2025.10(2025-10-28 발행) · 라이선스 W3C Software and Document License + 기고는 W3C CLA 필요 · pnpm 모노레포(technical-reports · schemas · www) · 명세 문서 자체는 ReSpec으로 빌드 · 최신 커밋 2026-06-17)
디자인 토큰(Design Token)이란 색상·간격·글꼴 크기처럼 디자인 시스템을 이루는 더 이상 쪼갤 수 없는 최소 단위를 말한다. "Button background는 #0066cc"처럼, 이름 붙은 값 하나하나가 토큰이다. 이 개념 자체는 세일즈포스 디자인 시스템 팀(Jon과 Jina)이 만들었는데, 문제는 회사마다 도구마다 이걸 저장하는 파일 형식이 제각각이었다는 점이다.
DTCG(Design Tokens Community Group)는 이 문제를 풀기 위해 2019년 W3C 안에 만들어진 커뮤니티 그룹이고, 이 저장소(design-tokens/community-group)는 그 그룹이 만드는 명세(specification) 문서와 부속 도구를 담고 있다. 실행 가능한 라이브러리가 아니라 "이런 JSON 구조를 쓰면 모두가 이해할 수 있다"는 규칙 문서이며, 곁들여 그 규칙을 검증할 JSON 스키마, 명세 사이트(designtokens.org)를 만드는 빌드 코드가 함께 들어있다.
여행할 때 나라마다 콘센트 모양이 달라 어댑터가 필요했던 경험이 있을 것이다. 디자인 도구 세계도 마찬가지였다. Figma는 Figma대로, Tokens Studio는 Tokens Studio대로, 사내 시스템은 또 자기들만의 방식으로 "색상 토큰"을 저장했다.
DTCG는 새로운 콘센트를 발명하는 게 아니라, "이 모양·이 핀 배치를 표준으로 하자"
이 저장소 자체는 2019년부터 있었지만, 2025년 10월 28일 "2025.10"이라는 이름으로 첫 안정(Stable) 버전이 발행되면서 실무자들의 관심이 크게 늘었다. 2021년 첫 에디터 초안 이후 4년 넘게 걸린 결과물이다. 지금 주목받는 이유를 세 가지로 정리하면:
디자인 시스템이 커질수록 색상표 하나를 Figma·Sketch·Style Dictionary·사내 문서에 네 번씩 다른 형식으로 옮겨 적어야 했다. 변환기를 직접 짜거나, 도구가 바뀔 때마다 마이그레이션 스크립트를 새로 짜는 일이 반복됐다. DTCG 형식 하나로 맞추면 이 변환 지옥이 줄어든다는 기대가 크다.
Figma가 자체 "Variables" 기능을 키우면서, 디자인 도구 안에서 만든 값을 코드로 어떻게 안전하게 내보낼지가 실무 이슈가 됐다. DTCG 형식은 이 내보내기·불러오기의 공통 표적이 되어준다. README에도 Figma가 CG에 참여 중인 회사로 이름을 올리고 있다.
DTCG는 W3C 정식 표준 트랙(Standards Track)이 아니다. 그런데도 실무에서는 이미 "쓸만한 표준처럼" 취급되고 있다. 공식 FAQ조차 "핵심 포맷은 프로덕션에 써도 안전하다"면서도 "스펙은 여전히 진화 중"이라고 솔직히 밝힌다. 이 "공식 표준은 아니지만 사실상 표준(de facto standard)"이라는 애매한 위치 자체가 논의거리가 되고 있다.
Style Dictionary·Tokens Studio는 각자 훌륭한 도구지만 결국 한 회사·한 프로젝트가 정한 포맷이었다. DTCG는 Adobe·Amazon·Figma·Google·Microsoft·Salesforce 등 수십 개 회사가 한 테이블에 앉아 합의하는 절차를 거친다는 점이 다르다. 느리지만, 어느 한 벤더에 종속되지 않는다는 장점이 있다.
DTCG가 실제로 풀려는 문제는 크게 세 갈래다.
같은 색상 토큰이라도 어떤 도구는 value, 어떤 도구는 val, 어떤 도구는 color라는 키를 썼다. DTCG는 모든 예약 속성 앞에 $를 붙이는 규칙($value, $type, $description 등)으로 이를 통일했다. $가 붙었으니 토큰 이름이 우연히 value여도 충돌하지 않는다.
"Button background는 Primary Blue와 같은 색"처럼 참조(alias) 관계는 디자인 시스템의 핵심이다. 도구마다 $primary, @primary, var(primary) 등 자기 방식으로 표현했는데, DTCG는 {group.token}이라는 중괄호 문법 하나로 통일했다. 값이 바뀌면 참조하는 모든 곳에 자동으로 전파된다는 개념까지 규칙으로 못박았다.
테마(라이트·다크)와 브랜드(A·B)와 화면 크기(모바일·데스크톱)를 조합하면 토큰 파일 수가 기하급수적으로 불어난다. 이걸 풀기 위해 이 저장소는 Resolver(리졸버)라는 별도 명세를 두어, "기초 토큰 + 테마별 차이"를 따로 저장했다가 필요한 조합만 조립하는 방법을 정의한다(자세한 내용은 5장).
번역 이전에 "맞춤법"부터 통일하는 일이라고 보면 된다. 여러 나라 말(도구별 포맷)을 자동 번역하는 도구(Style Dictionary 같은 변환기)는 이미 있었다. 하지만 그 번역기들이 입력으로 받는 원문 자체가 나라마다 맞춤법이 달랐다면 번역 품질이 들쭉날쭉해진다. DTCG는 "원문을 쓸 때 이 맞춤법을 따르자"는 합의이지, 번역기 그 자체는 아니다.
design-tokens/community-group은 pnpm 워크스페이스 모노레포다. 소프트웨어 앱이 아니라 "문서를 만드는 문서용 프로젝트"이므로, 폴더 구조도 코드가 아니라 명세 챕터별 마크다운 파일 위주로 짜여 있다.
구조가 말해주는 것: 이 레포는 "규칙을 적은 문서(technical-reports) + 그 규칙을 기계로 검증할 스키마(schemas) + 규칙을 사람이 읽을 웹사이트(www)" 세 덩어리로 나뉜 문서 프로젝트다. 명세는 챕터별 마크다운 파일을 data-include로 index.html에 끼워 넣고, W3C의 ReSpec 도구가 이를 정식 명세 문서 HTML로 빌드해 GitHub Pages(gh-pages 브랜치)로 배포한다.
technical-reports·schemas·www 세 패키지를 함께 관리한다.이 저장소 어디에도 ".tokens.json 파일을 실제로 파싱해 CSS로 바꿔주는 코드"는 없다. schemas/도 파일을 검증하는 JSON 스키마일 뿐, 변환기가 아니다.
실제로 토큰 파일을 읽고 쓰고 변환하는 일은 Style Dictionary·Tokens Studio·Terrazzo 같은 제3자 도구가 한다(7장 참고). 이 레포에서 "실행 파일"을 찾으려 하면 시간을 버린다.
$value부터 타입까지$value
$value 속성을 가진 객체가 곧 토큰이다. 이름(키)과 $value는 필수이고, 나머지는 전부 선택이다.
{
"token name": {
"$type": "color",
"$value": {
"colorSpace": "srgb",
"components": [1, 0, 0]
}
}
}
토큰 이름은 대소문자를 구분하고, 자유로운 문자열을 쓸 수 있지만 $extends가 쓰는 { } . 세 글자는 이름에 넣을 수 없다(참조 문법과 충돌하기 때문).
$description · $type · $extensions · $deprecated$description — 사람이 읽을 설명 문자열. 툴팁·주석으로 쓰인다.$type — 토큰의 타입. 직접 안 써도 ① 참조 대상의 타입 → ② 가장 가까운 부모 그룹의 $type 순서로 상속되며, 그래도 못 정하면 그 토큰은 무효(invalid)다. 도구는 값만 보고 타입을 "추측"하면 안 된다.$extensions — 벤더별 부가 데이터를 넣는 자리. 다른 도구가 이해 못 하는 확장 데이터라도 보존해야 한다(MUST preserve)는 규칙이 핵심이다.$deprecated — true/문자열(사유)/false 세 가지 값을 가진다.{
"Button background": {
"$type": "color",
"$value": { "colorSpace": "srgb", "components": [0.467, 0.467, 0.467] },
"$extensions": { "org.example.tool-a": 42 },
"$deprecated": "Please use {button.activeBorder} instead."
}
}$root
$value가 없는 객체는 자동으로 "그룹"이 된다. 그룹은 토큰을 폴더처럼 묶는 장치일 뿐, 이름 자체에 의미를 부여하지 않는다. 그룹에도 자기 자신을 나타내는 "대표값"이 필요할 때는 예약된 이름 $root를 쓴다.
{
"color": {
"accent": {
"$root": { "$type": "color", "$value": { "colorSpace": "srgb", "components": [0.867, 0, 0] } },
"light": { "$type": "color", "$value": { "colorSpace": "srgb", "components": [1, 0.133, 0.133] } }
}
}
}
// {color.accent.$root} → 대표(root) 색상값
// {color.accent} → 무효 (그룹은 참조 대상이 될 수 없음)
또한 그룹은 $extends로 다른 그룹을 상속(딥 머지)할 수 있다. JSON Schema의 $ref와 의미상 동일하게 동작하도록 설계됐다.
| 구분 | 중괄호 {group.token} | JSON Pointer $ref: "#/..." |
|---|---|---|
| 가리키는 대상 | 토큰 전체($value)만 | 문서 안 어디든 (속성 하나까지) |
| 용도 | 토큰 ↔ 토큰 참조 | 세부 속성 단위 참조(예: 색상의 R값 하나만) |
| 지원 의무 | 필수 | 필수 (RFC 6901 JSON Pointer) |
{
"colors": { "blue": { "$type": "color",
"$value": { "colorSpace": "srgb", "components": [0, 0.4, 0.8] } } },
"semantic": {
"primary": { "$value": "{colors.blue}" }, // 토큰 전체 참조
"primaryHue": { "$type": "number",
"$value": { "$ref": "#/colors/blue/$value/components/0" } } // 속성 1개만 참조
}
}참조는 연쇄(chain)될 수 있지만(A→B→C), 순환(A→B→A)은 금지되며 도구는 이를 감지해 오류로 보고해야 한다.
| 타입 | 값 구조 |
|---|---|
color | {colorSpace, components[], alpha?, hex?} — 12개 색공간 지원(아래 표) |
dimension | {value, unit} — unit은 "px" 또는 "rem"만 허용 |
fontFamily | 문자열 하나 또는 문자열 배열(우선순위 순) |
fontWeight | 1~1000 숫자 또는 "bold"·"thin" 같은 사전 정의 별칭 |
duration | {value, unit} — unit은 "ms" 또는 "s" |
cubicBezier | [P1x, P1y, P2x, P2y] 숫자 4개 배열 |
number | JSON 숫자 그대로(음수·소수 가능) |
{
"spacing-stack-1": { "$type": "dimension", "$value": { "value": 0.5, "unit": "rem" } },
"font-weight-thick": { "$type": "fontWeight", "$value": "extra-bold" },
"Duration-Quick": { "$type": "duration", "$value": { "value": 100, "unit": "ms" } }
}
color 값은 colorSpace(색공간)와 components(성분 배열)가 필수다. sRGB처럼 익숙한 것부터 OKLCH·Display P3처럼 넓은 색영역(wide gamut) 공간까지 12개를 표준으로 지원한다.
| colorSpace 값 | 성분(components) |
|---|---|
srgb / srgb-linear | [R, G, B] 각 0~1 |
hsl | [색상 0~360), 채도 0~100, 명도 0~100] |
hwb | [색상, 흰색량, 검정량] |
lab / oklab | [L(명도), A(초록-빨강), B(파랑-노랑)] |
lch / oklch | [L(명도), C(채도/채도폭), H(색상각)] |
display-p3 · a98-rgb · prophoto-rgb · rec2020 | [R, G, B] — 더 넓은 색영역용 |
xyz-d65 / xyz-d50 | [X, Y, Z] — 색 변환의 기준 공간 |
{
"Hot pink": {
"$type": "color",
"$value": {
"colorSpace": "srgb",
"components": [1, 0, 1],
"alpha": 1,
"hex": "#ff00ff"
}
},
"White (hue 미지정)": {
"$type": "color",
"$value": { "colorSpace": "hsl", "components": ["none", 0, 100] }
}
}
components의 각 원소는 숫자 대신 "none" 키워드도 쓸 수 있다. "값이 0"과 "이 성분은 해당 없음"을 구분하기 위해서인데, 색상 보간(그라디언트 등)에서 결과가 달라질 수 있다. hex는 선택적 대체(fallback) 값이다.
그림자·테두리·타이포그래피처럼 여러 하위값이 고정된 구조로 묶인 타입이다. 각 하위값은 실제 값이거나 {token} 참조일 수 있다.
| 타입 | 구조 |
|---|---|
strokeStyle | 문자열(solid·dashed…) 또는 {dashArray[], lineCap} |
border | {color, width, style} |
transition | {duration, delay, timingFunction} |
shadow | {color, offsetX, offsetY, blur, spread, inset?} — 배열이면 레이어드 섀도 |
gradient | [{color, position}, ...] — position은 0~1로 클램프 |
typography | {fontFamily, fontSize, fontWeight, letterSpacing, lineHeight} |
{
"shadow": {
"medium": {
"$type": "shadow",
"$value": {
"color": "{color.shadow-050}",
"offsetX": "{space.small}",
"offsetY": "{space.small}",
"blur": { "value": 1.5, "unit": "rem" },
"spread": { "value": 0, "unit": "rem" }
}
}
},
"type styles": {
"heading-level-1": {
"$type": "typography",
"$value": {
"fontFamily": "Roboto",
"fontSize": { "value": 42, "unit": "px" },
"fontWeight": 700,
"letterSpacing": { "value": 0.1, "unit": "px" },
"lineHeight": 1.2
}
}
}
}그룹과 컴포지트 토큰을 헷갈리기 쉬운데, 그룹은 그저 담는 폴더(참조 불가)이고 컴포지트 토큰은 그 자체가 하나의 토큰(참조 가능, 하위값 이름·타입이 정해져 있음)이라는 차이가 있다.
토큰 파일은 JSON이며, 확장자는 .tokens 또는 .tokens.json을 권장한다. HTTP로 서빙할 때 MIME 타입은 application/design-tokens+json(대체로 application/json도 허용)을 쓴다.
라이트/다크 테마, 브랜드별 변형, 화면 크기별 값처럼 "맥락에 따라 달라지는 토큰"은 포맷 명세가 아니라 별도의 Resolver(리졸버) 명세가 다룬다. 기초 토큰 묶음을 sets(세트)로, 맥락별 대안값을 modifiers(수정자)로 나눠 저장해두고, resolutionOrder 배열 순서대로 겹쳐 쌓아 최종 결과를 조립한다.
{
"$schema": "https://www.designtokens.org/schemas/2025.10/resolver.json",
"sets": {
"foundation": { "sources": [{ "$ref": "foundation.json" }] }
},
"modifiers": {
"theme": {
"context": {
"light": [{ "$ref": "themes/light.json" }],
"dark": [{ "$ref": "themes/dark.json" }]
}
}
},
"resolutionOrder": [
{ "$ref": "#/sets/foundation" },
{ "$ref": "#/modifiers/theme" }
]
}
// 입력 { "theme": "dark" } 이면 themes/dark.json 값만 골라 foundation과 합침
// themes/light.json은 이 입력에서는 아예 쓰이지 않는다즉 "라이트용 파일, 다크용 파일을 각각 통째로 만드는" 대신, 겹치는 부분은 한 번만 쓰고 다른 부분만 갈아 끼우는 방식으로 조합 폭발을 줄인다.
#/a/b/0 같은 슬래시 경로로 가리키는 표준 문법. DTCG는 $ref 속성에 이 문법을 써서 토큰 값 속의 개별 항목(배열 원소 하나 등)까지 참조할 수 있게 한다.$type이 없고 상속받을 부모 그룹도 없으면, 그 토큰은 값이 멀쩡해 보여도 무효다. 스펙은 명시적으로 "도구는 값을 보고 타입을 추측하려 해서는 안 된다(MUST NOT)"고 못박는다. "그냥 숫자 배열이니 색상이겠지" 식의 눈치 파싱은 스펙 위반이다.
DTCG는 2019년 9월 2일 헌장(CHARTER.md)으로 출범한 W3C 커뮤니티 그룹이다. 헌장이 정한 작업 범위(Deliverables)는 포맷/문법/구문, 색상, 간격, 지속시간, 타이포그래피, 기타 토큰 관련 명세로 한정된다.
기본은 합의(consensus)다. 이견이 남으면 커미터(Committer, 꾸준한 기여로 지위를 얻은 참여자)들이 표결하며, 반대하는 사람은 "포크를 떠서 자기 대안을 구현하는" 것도 명시적으로 허용된다 — 구현 경험이 쌓인 뒤 그걸 보고 그룹이 최종 채택 여부를 정하자는 취지다.
| 버전 | 날짜 | 상태 |
|---|---|---|
| preview | — | Experimental |
| first-editors-draft | 2021-09-23 | Draft |
| second-editors-draft | 2022-06-14 | Draft |
| third-editors-draft | 2025-07-21 | Draft |
| 2025.10 | 2025-10-28 | Stable |
헌장(2019) → 첫 초안(2021) → 첫 안정판(2025)까지 6년이 걸린 셈이다. 그런데도 이 저장소의 main 브랜치, 즉 지금 여러분이 보는 technical-reports/의 실제 HTML 설정은 여전히 specStatus: 'CG-DRAFT'다. 다시 말해 2025.10은 "그 시점 스냅샷"이고, 저장소 본체는 그 이후로도 계속 수정되고 있다.
명세 편집을 이끄는 에디터는 Louis Chenais, Mike Kamminga, Kathleen McMahon, Drew Powers, Matthew Ström-Awn, Donna Vitan 등이며, README에는 Adobe·Amazon·Atlassian·Figma·Google·Microsoft·Salesforce·Shopify·Zendesk 등 40개 가까운 회사·오픈소스 프로젝트가 대표를 파견해 참여 중이라고 명시돼 있다.
공식 FAQ가 스스로 밝히듯 "DTCG 스펙은 W3C 표준 트랙에 있지 않다(not on the W3C Standards Track)." 2025.10에 붙은 "Stable"은 이 커뮤니티 그룹 안에서의 성숙도 표시이지, ISO나 W3C Recommendation 같은 공식 국제 표준 인증이 아니다.
이 저장소 자체는 실행할 게 없지만, "어떤 도구를 어떤 순서로 연결하면 되는가"는 명확한 그림이 있다.
Figma Variables(네이티브 변수) 또는 Tokens Studio(Figma 플러그인, DTCG 태동에 큰 영향을 준 도구) · Penpot(오픈소스 디자인 툴)에서 색상·간격 등을 정의하고 .tokens.json으로 내보낸다.
이 레포의 schemas/ 패키지(@dtcg/schemas)가 만드는 format.json·resolver.json(JSON Schema draft-07)을 ajv 같은 표준 JSON Schema 검증기에 물려 내가 만든 토큰 파일이 규격에 맞는지 CI에서 자동 확인할 수 있다. 파일 안의 "$schema": "https://www.designtokens.org/schemas/2025.10/format.json" 한 줄이 그 표식이다.
Style Dictionary(가장 널리 쓰이는 변환 엔진, Amazon 출신) 또는 Terrazzo(DTCG 네이티브를 표방하는 신흥 변환기)가 .tokens.json을 읽어 CSS 커스텀 속성·Sass 변수·iOS Swift·Android XML·Compose 등으로 뽑아낸다.
라이트/다크나 브랜드 변형이 있다면, Resolver 명세대로 sets/modifiers/resolutionOrder를 쓴 리졸버 파일을 만들어 "입력값(예: {"theme":"dark"})에 따라 최종 토큰 트리를 조립"하게 한다. 다만 이 부분 툴 생태계는 아직 포맷보다 훨씬 얇다(9장 참고).
메모장에 이 문서 5장의 최소 예제({"token name": {"$type":"color","$value":{...}}})를 my.tokens.json으로 저장하고, $schema 줄을 추가한 뒤 온라인 JSON Schema 검증기에 format.json과 함께 넣어보라. "규칙 문서를 읽는 것"과 "그 규칙이 실제로 강제되는 것"의 차이를 체감할 수 있다.
README와 공식 FAQ가 밝히는 참여·채택 현황을 정리하면 다음과 같다.
| 영역 | 도구/회사 |
|---|---|
| 커뮤니티 그룹 참여사 | Adobe · Amazon · Atlassian · Figma · Google · Microsoft · Salesforce · Shopify · Sketch · Zendesk 등 약 40곳 |
| 디자인 도구 | Figma(Variables) · Penpot · Sketch · Framer · Adobe |
| 토큰 관리 플러그인 | Tokens Studio · TokensBrücke(Figma 플러그인) |
| 변환/빌드 도구 | Style Dictionary · Terrazzo · Universal Design Tokens(UDT) |
| 검증·린팅 | Design Token Validator(Anima) · Project Wallace · Design Tokens Language Server(VS Code) |
| 문서화 도구 | zeroheight · Supernova · Knapsack · Storybook 생태계 |
실무에서 흔히 보는 흐름은 다음과 같다: 디자이너가 Figma에서 변수를 정의 → Tokens Studio 같은 플러그인으로 .tokens.json 내보내기 → Git 저장소에 커밋 → CI에서 Style Dictionary/Terrazzo 실행 → CSS 변수·모바일 네이티브 코드로 변환 → 제품 코드가 그 결과물을 가져다 씀. 테마가 있다면 이 파이프라인 중간에 Resolver 단계가 끼어든다.
이건 마치 "통역이 필요 없는 국제 회의"를 만드는 일과 비슷하다. 예전에는 디자이너(Figma어)가 말한 걸 개발자(코드어)가 알아듣도록 매번 통역사(맞춤 스크립트)를 불러야 했다. 이제는 모두가 DTCG라는 공용어로 적어두면, 여러 통역사(Style Dictionary, Terrazzo…) 중 아무나 불러도 같은 뜻으로 옮겨진다.
커뮤니티 그룹 리포트는 W3C 표준 트랙 밖에 있다. 법적 구속력이나 국제 표준 인증 같은 무게감을 기대하고 접근하면 실망한다. 대신 "다수 벤더가 합의해가는, 빠르게 움직이는 사실상 표준"으로 이해하는 편이 정확하다.
composite-types.md 안에는 <div class="issue"> 형태로 아직 확정 안 된 논쟁이 그대로 박혀 있다. 예: strokeStyle에 SVG의 stroke-linejoin 같은 하위값이 더 필요한지(#98), border가 다중 테두리·테두리 이미지를 지원해야 하는지(#99), shadow가 다중 그림자를 지원해야 하는지(#100), gradient에 linear/radial/conical 종류 구분이 필요한지(#101), typography의 lineHeight가 숫자여야 하는지 별도 타입이어야 하는지(#102).
또한 types.md는 Font style(이탤릭 등)·백분율/비율·파일(에셋) 타입이 "아직 다뤄지지 않았다"고 스스로 명시한다.
Resolver 명세는 2025-07-23에 v2.1.0이 나왔는데, 그 CHANGELOG에 스스로 "용어(process/inputs/dimensions vs contexts) 정리 필요", "수정자(modifier)를 배열로 할지 객체로 할지 미정", "병합 로직·우선순위 규칙을 더 상세히 정해야 함" 등을 미해결 과제로 나열해 둔다. 프로덕션 테마 파이프라인 전체를 이 명세 하나에 맡기기엔 아직 이르다.
Button, Card 같은 컴포넌트 단위 토큰은 composite-types.md 예제에 관행적으로 등장하지만(예: component.card.box-shadow), 이를 위한 별도 규칙이나 예약 구조는 정의돼 있지 않다. "기초 토큰 → 시맨틱 토큰 → 컴포넌트 토큰"이라는 계층화는 커뮤니티 관행이지 이 스펙이 강제하는 문법이 아니다.
공식 FAQ는 "핵심 포맷($value/$type/그룹/참조/기본 타입들)은 프로덕션에 써도 안전하다"고 명시한다. 위험한 건 주변부(아직 논의 중인 타입 세부 규칙, 테마 리졸버)이지, 중심부(토큰의 기본 뼈대)가 아니다. 날짜가 박힌 버전(예: 2025.10)에 고정해 쓰는 것을 권장한다.
| 대안 | 특징 | DTCG와 차이 |
|---|---|---|
| Theo(Salesforce) | "디자인 토큰"이라는 이름·개념을 처음 세상에 내놓은 원조 도구. 자체 YAML/JSON 포맷을 씀 | 사실상 유지보수가 멎었고, 한 회사 전용 포맷이라 벤더 간 호환이 안 됨. README에도 "ex-contributors to Theo"가 DTCG 참여자로 명시돼 있어, 사실상 Theo의 후계자 격으로 읽힌다 |
| Style Dictionary 레거시 포맷 | $ 없이 value/type 키를 쓰던 기존 방식. 여전히 실무에 많이 남아있음 | 도구 하나에 종속된 포맷. DTCG는 벤더 중립이고 참조·타입 상속 규칙이 더 명시적 |
| Tokens Studio 자체 포맷 | Figma 플러그인 생태계에서 독자적으로 발전한 JSON 구조 | DTCG 초기 논의에 큰 영향을 줬지만, 세부 문법(참조 표기 등)이 조금씩 다름. 현재 DTCG 포맷과 수렴 중 |
| Figma Variables(원시) | Figma 안의 네이티브 변수 — 색상/숫자/문자열/불리언 + 모드(mode) | 파일 포맷이 아니라 도구 내부 데이터 모델이다. 외부로 내보내려면 결국 플러그인이 DTCG 같은 교환 포맷으로 변환해야 함 |
| 사내 수기 JSON | 회사마다 손으로 짠 {"primary-blue": "#0066cc"} 식 평면 구조 | 빠르지만 타입·참조·확장 규칙이 없어 도구가 늘어날수록 유지비가 커짐 |
Theo가 "최초로 손목시계를 만든 장인"이라면, DTCG는 "모든 시계 제조사가 같은 나사 규격을 쓰도록 정한 국제 표준 위원회"에 가깝다. 장인 개인의 시계는 정교했지만 다른 회사 부품과 안 맞았다. 표준 나사 규격이 생기면 부품 교환·수리·조립이 회사를 넘나들며 가능해진다 — 다만 표준을 정하는 회의는 시계 장인 한 명이 만드는 것보다 훨씬 오래 걸린다.
여러 도구(디자인 툴 + 변환기 + 문서화 도구)를 동시에 쓰거나 앞으로 바꿀 가능성이 있다면 DTCG 형식이 유리하다. 반대로 도구 하나에 계속 고정될 확실한 소규모 팀이라면, 지금 당장 마이그레이션 비용을 들일 만큼 급하지 않을 수 있다 — 다만 업계 도구들이 이쪽으로 수렴하고 있으니 신규 프로젝트라면 처음부터 DTCG로 시작하는 편이 안전하다.
design-tokens/community-group은 실행되는 프로그램이 아니라 W3C 커뮤니티 그룹이 합의해가는 명세 문서 저장소다. 읽는 방식도 소스코드를 읽듯이 "함수가 뭘 하나"를 쫓기보다, "이 JSON 키는 무슨 규칙을 강제하는가"를 규정집 읽듯 따라가야 한다.
Figma·Style Dictionary·Tokens Studio를 넘나들며 토큰을 옮기는 일을 한다면, 이 명세를 한 번 읽어두는 것만으로 "왜 $value 앞에 $가 붙는지", "왜 {group.token} 문법을 쓰는지"에 대한 근본적인 이해가 생긴다.
토큰 임포트·익스포트 기능을 만드는 플러그인·SaaS 개발자라면, schemas/의 JSON 스키마와 technical-reports/format/의 각 타입 규칙을 직접 대조하며 구현 정합성을 확인해야 한다.
".tokens.json을 바로 파싱해주는 코드"가 필요하다면 이 레포가 아니라 Style Dictionary·Terrazzo 같은 구현체 저장소로 가야 한다. 여기는 그 구현체들이 참고하는 "규칙" 저장소다.
마지막으로 기억할 한 문장: DTCG는 아직 진행형인 표준이다. 핵심 뼈대($value/$type/그룹/참조/기본 타입)는 실무에 써도 안전하다고 공식적으로 밝히고 있지만, 색상 보간·테마 리졸버·컴포넌트 토큰 같은 주변부는 아직 스펙 본문에 "미해결"이라고 적힌 채로 계속 논의되고 있다.