디자인 토큰(Design Tokens)은 색상, 간격, 글꼴 크기, 그림자 같은 디자인 결정을 이름 붙은 값으로 정리해 두는 방식이다. "파란색 #2563EB" 대신 "primary 색"이라 부르고, 그 이름 하나만 바꾸면 디자인 도구부터 웹·iOS·안드로이드까지 일관되게 반영되도록 하는 것이 핵심이다. 최근에는 이 토큰을 담는 파일 형식을 표준화하려는 W3C 차원의 작업이 진행되면서, 흩어져 있던 디자인 시스템 생태계가 하나의 공통 언어로 모이는 중이다.
왜 지금인가. 서비스가 웹·앱·워치·TV로 늘어나고, 라이트/다크 테마에 브랜드별 변형까지 겹치면서 디자인 값을 손으로 관리하는 한계가 명확해졌기 때문이다.
토큰은 디자인을 '데이터'로 바꾼다.
그러면 사람 대신 도구가 일관성을 지킨다.
색 하나를 바꾸려고 코드 수백 곳을 뒤지는 대신, 토큰 한 값만 고치면 된다. 디자인과 개발이 같은 원본을 바라보게 만드는 것이 토큰의 목적이다.
1원본 단일 진실의 출처(SSOT) |
3계층 원시·의미 ·컴포넌트 |
JSON표준 도구 중립 공통 포맷 |
다중플랫폼 웹·iOS·안드 한 번에 반영 |
토큰은 계층으로 쌓인다
잘 만든 토큰 체계는 대개 세 겹으로 이뤄진다. 이 구조를 이해하면 왜 토큰이 유지보수를 극적으로 줄이는지 보인다.
- 원시 토큰(primitive) — 순수한 값 그 자체다. blue-500 = 특정 파랑, space-4 = 16px처럼. 여기엔 '의미'가 없다.
- 의미 토큰(semantic) — 값에 역할을 입힌다. color-primary가 blue-500을 가리키고, color-danger가 red-600을 가리키는 식이다. 화면은 원시 값이 아니라 이 의미 토큰을 참조한다.
- 컴포넌트 토큰 — 버튼·카드 같은 부품 단위로 한 번 더 좁힌다. button-bg가 color-primary를 참조하는 식이다.
핵심은 참조의 사슬이다. 브랜드 색을 바꾸고 싶으면 원시 blue-500 하나만 바꾸면 그걸 가리키던 모든 의미·컴포넌트 토큰이 연쇄적으로 따라온다. 다크 테마도 마찬가지다. 의미 토큰이 테마에 따라 다른 원시 값을 가리키게만 하면, 화면 코드는 손대지 않아도 된다.
표준 포맷이 왜 중요한가
그동안 디자인 도구, 프론트엔드 프레임워크, 모바일 각각이 토큰을 제 나름의 형식으로 저장했다. 그래서 디자인 도구에서 만든 토큰을 코드로 옮기려면 매번 변환기를 붙여야 했고, 도구를 바꾸면 다 갈아엎어야 했다. 표준 JSON 포맷은 이 벽을 허문다. 하나의 파일을 도구도, 코드도, 빌드 파이프라인도 똑같이 읽을 수 있게 되면 변환 지옥이 사라진다.
실무 흐름은 이렇게 정리된다. 디자이너가 도구에서 토큰을 정하면 표준 JSON으로 내보내고, 빌드 단계에서 이 파일을 CSS 변수·iOS 리소스·안드로이드 리소스로 각각 자동 변환한다. 원본은 하나, 산출물은 여럿이다. 이 파이프라인이 돌기 시작하면 "디자인과 코드가 어긋난다"는 고질병이 구조적으로 줄어든다.
| 항목 | 디자인 토큰 | 직접 값 지정 |
|---|---|---|
| 색 변경 | 원본 1곳 수정 | 전 코드 검색·치환 |
| 다크 테마 | 참조만 교체 | 화면마다 분기 |
| 멀티플랫폼 | 자동 변환·동기화 | 플랫폼별 수작업 |
| 디자인-코드 일치 | 구조적으로 유지 | 쉽게 어긋남 |
도입할 때의 함정
토큰이 만능은 아니다. 흔한 실수는 원시 토큰을 화면에서 직접 쓰는 것이다. color-blue-500을 버튼에 바로 박아 두면, 나중에 브랜드가 초록으로 바뀔 때 다시 전부 뒤져야 한다. 반드시 의미 토큰을 거쳐야 한다. 또 하나, 토큰 이름을 너무 잘게 쪼개면 관리할 대상만 늘어난다. 처음부터 완벽한 체계를 노리기보다, 자주 바뀌는 색·간격부터 토큰화하고 점진적으로 넓히는 편이 현실적이다. 표준화된 포맷은 이 여정을 훨씬 매끄럽게 만들어 줄 뿐, 좋은 이름 설계라는 숙제까지 대신 풀어 주지는 않는다.
자주 묻는 질문
디자인 토큰과 CSS 변수는 같은 건가요?
비슷하지만 다르다. CSS 변수는 웹에서 토큰을 구현하는 하나의 결과물이다. 디자인 토큰은 도구·플랫폼에 얽매이지 않는 원본 개념이고, 이 원본을 웹에서는 CSS 변수로, iOS·안드로이드에서는 각 리소스 형식으로 변환해 쓴다.
작은 프로젝트에도 토큰이 필요한가요?
규모가 아주 작다면 과할 수 있다. 다만 색과 간격을 이름으로 정리해 두는 최소한의 토큰만 있어도 테마 변경과 일관성 관리가 쉬워진다. 플랫폼이 여럿이거나 팀이 커지는 순간부터는 사실상 필수에 가깝다.
표준 JSON 포맷을 지금 꼭 따라야 하나요?
강제는 아니지만, 표준을 따르면 도구를 갈아타거나 변환 파이프라인을 붙일 때 이식성이 크게 좋아진다. 특정 도구에 종속된 형식으로 쌓아 두면 나중에 옮기기 어려우므로, 새로 시작한다면 표준 지향으로 설계하는 편이 안전하다.
토큰은 디자이너와 개발자 중 누가 관리하나요?
양쪽의 접점에서 함께 관리하는 것이 이상적이다. 디자이너가 값을 정하고 개발자가 변환·적용 파이프라인을 책임지는 분담이 흔하다. 토큰의 진짜 가치는 두 직군이 같은 원본을 바라보게 만드는 데 있으므로, 어느 한쪽만의 자산으로 두면 효과가 반감된다.
댓글 0