이 글은 누구를 위한 것인가
- 디자인 시스템을 처음 구축하거나 개선하려는 디자이너·프론트엔드 개발자
- "디자인 토큰"이라는 말을 들었는데 무엇인지 정확히 모르는 분
- iOS, Android, 웹을 동시에 운영하며 디자인 일관성 문제를 겪는 팀
들어가며
"이 버튼 파란색, 저 버튼 파란색인데 왜 색이 달라 보이죠?"
디자인 시스템이 없는 팀에서 자주 나오는 말이다. 디자이너는 Figma에서 특정 파란색을 썼고, 개발자는 코드에서 비슷한 파란색을 눈대중으로 맞췄다. 결과물은 "비슷하지만 다른" 파란색이 여기저기 흩어져 있다.
이 문제를 근본적으로 해결하는 것이 디자인 토큰이다. 그리고 2024년 W3C(웹 표준 기구)가 디자인 토큰 형식의 공식 표준을 발표하면서, 이제 도구나 플랫폼에 관계없이 같은 방식으로 토큰을 정의하고 공유할 수 있게 됐다.
1. 디자인 토큰이란 무엇인가
디자인 토큰은 디자인 결정사항에 붙이는 이름표다.
예를 들어, 브랜드 파란색 #1A73E8이라는 색상값에 color-brand-blue라는 이름을 붙이는 것이다. 이렇게 하면 색상값이 바뀌어도 이름은 그대로고, 이 이름을 참조하는 모든 곳이 자동으로 바뀐다.
[토큰 없는 방식]
버튼 배경색: #1A73E8
링크 색상: #1A73E8
선택 상태 배경: #1A73E8
↑ 색상 변경 시 세 곳을 모두 찾아서 바꿔야 함
[토큰 있는 방식]
color-brand-blue: #1A73E8
버튼 배경색: {color-brand-blue}
링크 색상: {color-brand-blue}
선택 상태 배경: {color-brand-blue}
↑ color-brand-blue 하나만 바꾸면 세 곳 모두 자동으로 업데이트
토큰은 색상만이 아니다. 폰트 크기, 간격, 모서리 둥글기, 그림자, 애니메이션 속도까지 모든 디자인 결정사항이 토큰이 될 수 있다.
2. W3C 표준이 왜 중요한가
기존에도 Figma, Style Dictionary, Theo 같은 도구들이 각자 방식으로 디자인 토큰을 처리했다. 문제는 도구마다 형식이 달라서 호환이 안 됐다는 것이다.
W3C Design Tokens Community Group이 공식 형식을 정의하면서, 이제 Figma의 Variables, Style Dictionary, Tokens Studio 등이 같은 표준 JSON 형식을 사용한다. 도구를 바꿔도 토큰 파일 하나로 모든 곳에서 쓸 수 있다.
W3C 표준 토큰 형식 예시
{
"color": {
"brand": {
"blue": {
"$value": "#1A73E8",
"$type": "color",
"$description": "브랜드 메인 블루 컬러"
}
}
},
"spacing": {
"md": {
"$value": "16px",
"$type": "dimension"
}
}
}
$value, $type, $description — 달러 기호가 붙은 필드가 W3C 표준 키다.
3. 3계층 토큰 시스템: Primitive → Semantic → Component
디자인 토큰을 잘 설계하는 핵심은 3계층 구조다. 각 층이 무엇을 의미하는지 살펴보자.
1층: Primitive 토큰 (원자 토큰)
모든 값의 최소 단위다. "이 파란색의 이름"처럼, 의미 없이 값 자체에 이름을 붙인다.
{
"color-blue-100": "#EBF3FE",
"color-blue-200": "#C3D9FC",
"color-blue-500": "#1A73E8",
"color-blue-700": "#1558B0",
"color-gray-100": "#F5F5F5",
"color-gray-900": "#1A1A1A"
}
Primitive 토큰은 직접 컴포넌트에 사용하지 않는다. 이 값들은 다음 층의 재료가 된다.
2층: Semantic 토큰 (의미 토큰)
Primitive 값에 **맥락(의미)**을 부여한다. "이 색이 어디에 쓰이는 색인가"를 정의한다.
{
"color-action-primary": "{color-blue-500}",
"color-action-primary-hover": "{color-blue-700}",
"color-text-default": "{color-gray-900}",
"color-background-subtle": "{color-gray-100}",
"color-feedback-error": "{color-red-500}"
}
Semantic 토큰의 가장 큰 장점은 테마 전환이다. 다크 모드에서는 같은 color-text-default 토큰이 {color-gray-900} 대신 {color-gray-100}을 가리키도록 바꾸면 된다. 컴포넌트 코드는 하나도 안 바꿔도 된다.
3층: Component 토큰 (컴포넌트 토큰)
특정 컴포넌트에만 사용되는 토큰이다. Semantic 토큰을 참조한다.
{
"button-background-default": "{color-action-primary}",
"button-background-hover": "{color-action-primary-hover}",
"button-text-color": "{color-white}",
"button-border-radius": "{border-radius-md}",
"button-padding-x": "{spacing-lg}",
"button-padding-y": "{spacing-sm}"
}
이렇게 하면 버튼의 배경색을 바꾸고 싶을 때 color-action-primary만 수정하면, 버튼을 쓰는 모든 곳이 일괄로 바뀐다.
4. Style Dictionary로 멀티플랫폼 자동 변환
디자인 토큰의 진짜 힘은 하나의 소스에서 여러 플랫폼의 코드를 자동 생성하는 것이다. Amazon이 만든 오픈소스 도구 Style Dictionary가 이 역할을 한다.
토큰 JSON 파일 하나
│
├── CSS 변수 파일 생성
│ --color-action-primary: #1A73E8;
│
├── iOS Swift 파일 생성
│ static let colorActionPrimary = UIColor(...)
│
├── Android Kotlin 파일 생성
│ val colorActionPrimary = Color(0xFF1A73E8)
│
└── JavaScript 상수 파일 생성
export const colorActionPrimary = '#1A73E8';
토큰 값을 한 번만 수정하면, CI/CD 파이프라인이 자동으로 모든 플랫폼의 코드를 업데이트한다. 디자이너가 색상 하나를 바꾸면 iOS 앱, Android 앱, 웹이 모두 동시에 업데이트된다.
5. Figma Variables와 W3C 토큰 연동
2023년 Figma에 Variables 기능이 추가되면서 디자인 도구 레벨에서도 토큰 관리가 가능해졌다.
Tokens Studio 플러그인을 사용하면 Figma Variables와 W3C 표준 토큰 JSON 파일을 양방향으로 동기화할 수 있다.
워크플로우:
Figma Variables (디자이너 수정)
↕ Tokens Studio 플러그인 동기화
W3C 토큰 JSON (GitHub 저장)
↕ GitHub Actions 자동 빌드
CSS/Swift/Kotlin 코드 (자동 생성)
↕
개발자 코드에 자동 반영
이 파이프라인이 갖춰지면, 디자이너가 Figma에서 색상을 바꾸는 순간 개발자 코드까지 자동으로 업데이트된다. PR 리뷰 → 머지 → 배포 과정도 자동화할 수 있다.
6. 실제 디자인 시스템의 토큰 전략 비교
| 시스템 | 특징 | 참고 포인트 |
|---|---|---|
| GitHub Primer | 시맨틱 토큰 중심, 오픈소스 | 네이밍 컨벤션이 명확함 |
| Shopify Polaris | 상업 목적 특화, 다크모드 완벽 지원 | 컴포넌트 토큰 활용 좋음 |
| Salesforce Lightning | 엔터프라이즈 규모, 멀티 브랜드 | 대규모 조직 운영 모델 참고 |
| Material Design 3 | Google의 동적 컬러 시스템 | 색상 자동 생성 알고리즘 |
오픈소스로 공개된 이 시스템들의 토큰 파일을 직접 열어보면서 네이밍 패턴을 익히는 것이 가장 빠른 학습 방법이다.
7. 자주 하는 토큰 네이밍 실수
실수 1: 색상값으로 이름 짓기
잘못된 예: color-blue, color-red-500
올바른 예: color-action-primary, color-feedback-error
색상값 기반 이름은 색상이 바뀌는 순간 이름이 의미를 잃는다.
실수 2: 컴포넌트별 중복 정의
잘못된 예: button-primary-color, card-primary-color (둘 다 같은 값)
올바른 예: color-action-primary (하나만 정의하고 두 곳에서 참조)
실수 3: 너무 세분화된 컴포넌트 토큰
잘못된 예: button-small-padding-top, button-small-padding-right...
올바른 예: button-small-padding-x, button-small-padding-y
맺으며
디자인 토큰은 처음 셋업이 번거롭지만, 한번 잘 구축해두면 팀 전체의 협업 속도가 확연히 달라진다. 디자이너와 개발자가 "이 색상 정확히 어떤 값이야?"를 물어볼 필요가 없어진다. 변경사항이 자동으로 전파되고, 다크 모드나 새로운 브랜드 테마를 추가하는 것이 코드 대공사 없이 가능해진다.
W3C 표준 덕분에 이제 도구가 달라도 같은 언어로 이야기할 수 있다. 지금이 디자인 토큰 시스템을 시작하기 가장 좋은 시점이다.