이 글을 시작하며
디자인 시스템을 한 번이라도 다뤄보셨다면 ‘디자인 토큰(Design Token)’이라는 말을 한번 쯤은 들어보셨을 것 같은데요. 그런데 막상 “토큰이 정확히 뭐냐”고 물으면, 의외로 설명이 애매해지지 않으시던가요? 변수 같기도 하고, 미리 지정해둔 색상 팔레트 같기도 하고 말이죠.
그래서 이 글에서는 그 애매함을 한번 걷어내 보려 합니다. 1편인 이 글에서는 토큰이 무엇이고, 왜 필요하며, 어떻게 구조화되는지를 정리하고, 2편에서는 토큰을 Figma에서 정의한 후 → DESIGN.md를 거쳐 → Tailwind 코드가 되고 → AI로 자동화하는 것 까지 이어지는 구조로 이야기를 풀어나가 보겠습니다.
디자인 토큰이란 무엇인가
제 모든 글에서 항상 그래왔듯 이번 글에서도 단어의 의미에 대해 알아보고 토큰의 개념에 대해 설명해 보도록 하겠습니다. ‘token’이라는 영어 단어는 ‘표시, 징표’라는 뜻을 가지고 있습니다. 즉 토큰이란 어떤 값을 대신 가리키는 ‘표식’인 셈이죠. 디자인 토큰도 같은 역할을 하게됩니다.
한마디로 디자인 토큰은 정의된 디자인 결정값에 붙인 ‘이름표’라는 뜻입니다. 이런 토큰이 실제 디자인에서는 어떤 식으로 활용되는지 한번 살펴보겠습니다🧐
예를 들어 #B2FF00이라는 색상 코드를 화면마다 그대로 적어 넣는 대신, lime-500라는 이름을 붙이고 그 이름에 의미를 붙여서 color-primary라는 이름으로 디자인하는 것입니다. 개발하시는 분들에게는 익숙한 ‘변수(variable)’의 개념을, 디자인(색·간격·폰트·그림자 등)에도 동일하게 들여온 것이라고 보시면 됩니다.
왜 디자인 토큰이 필요할까
그냥 색상 코드로도 작업할 수 있는데, 굳이 이름까지 붙여 토큰으로 만들어 쓰는 건 무엇때문일까요? 저는 토큰에 대한 가치를 [일관성, 확장성, 디자인-개발 언어의 통합을 통한 협업] 이렇게 세가지로 정리해서 설명해 보고자 합니다.
일관성 (Consistency) : 같은 의미에는 항상 같은 값이 적용됩니다. 비슷하지만 미묘하게 다른 색을 실수로 쓰는 일이, 구조적으로 차단되는 거죠.
확장성 (Scalability) : 다크 모드, 브랜드 리뉴얼, 멀티 테마. 토큰의 값만 바꾸면 전체 시스템이 따라옵니다. 화면이 100개든 1,000개든 수정 비용은 거의 같습니다.
협업 (Collaboration) : 저는 이게 가장 중요하다고 봅니다. 디자이너의 color-primary와 개발자의 –color-primary가 같은 것을 가리킬 때, 둘 사이의 커뮤니케이션 비용이 사라지거든요. 토큰은 디자인과 코드가 함께 쓰는 ‘공통 언어’인 셈입니다. 그리고 2편에서 자세히 설명드리겠지만, 이 가이드는 이제 AI를 활용해서 디자인 작업을 진행할 때도 커뮤니케이션 비용을 줄여주게 됩니다.
토큰의 3계층 구조
디자인 토큰을 쓰기 시작하면서 우리는 계층 구조라는 개념을 만나게 됩니다. 잘 설계된 토큰 시스템은 보통 3단계로 나뉩니다. 조직마다 토큰의 구조 및 약속은 달라서 이 글 에서는 무엇이 일반적이라고 규정 하지는 않겠습니다.
1단계 Primitive
순수한 값 그 자체로 원본 데이터를 담고 있습니다. 이 데이터는 색상 팔레트, 폰트 사이즈 스케일 같은 ‘재료’에 해당합니다. 이 단계의 토큰은 화면에 직접 쓰지 않습니다.
2단계 Semantic
원시 토큰에 ‘역할’을 부여한 것입니다. 디자인의 실제 의도가 담기는 단계죠. lime-500이 아니라 color-primary로 사고하기 시작하는 순간, 디자인은 단순한 색이 아니라 의미로 움직이기 시작합니다.
3단계 Component
특정 컴포넌트에만 한정된 토큰입니다. 가장 구체적인 단계입니다.
이 3단계가 사슬처럼 연결되어 있기 때문에, 가장 위(Primitive)의 값 하나를 바꾸면 그 아래 모든 것이 자동으로 따라 바뀝니다. 저는 이 구조를 처음 이해했을 때, 디자인이 ‘그림’이 아니라 ‘시스템’으로 보이기 시작했던 기억이 납니다.
| 계층 | 역할 | 예시 | 직접 사용 |
|---|---|---|---|
| Primitive | 순수한 값 | lime-500: #B2FF00 |
✕ |
| Semantic | 의미·역할 부여 | color-primary |
○ |
| Component | 컴포넌트 한정 | button-bg-primary |
○ |
네이밍이 곧 토큰의 품질입니다
계층만큼 중요한 게 이름이라고 생각합니다. 모두가 보고 해당 토큰의 역할과 의미를 파악하고 개발 및 디자인을 할 수 있어야 하니까요. 네이밍은 보통 [카테고리]-[속성]-[변형]-[상태] 같은 일관된 패턴을 따릅니다.
여기서 핵심은 ‘읽었을 때 의미가 바로 떠오르는가’입니다. space-md는 누가 봐도 중간 크기 간격임을 알 수 있죠. 반면 space-2는 한 번 더 해석이 필요합니다. 이 네이밍의 일관성은 AI를 활용한 자동화 단계에서 특히 빛을 발하는데요, 이름이 명확할수록 AI가 덜 헤매기 때문입니다. 이 내용은 2편에서 더 자세하게 다뤄보도록 하겠습니다.
글을 마치며
여기까지 디자인 토큰에 대한 전반적인 내용을 훑어봤는데요. 토큰이 무엇이고, 왜 필요하며(일관성·확장성·협업), 어떻게 구조화되는지(Primitive → Semantic → Component)까지 짚어봤습니다.
이제 이 토큰들이 실제로 화면에 어떻게 적용되고 어떻게 활용할 수 있는지를 봐야겠죠? 다음 편에서는 Figma에 정의된 토큰을 → DESIGN.md로 제작해 하나의 규칙으로 만들고 → Tailwind 코드에 맵핑시킨 뒤 → AI 자동화의 연료가 되는 하나의 흐름을 설명드려 보려 합니다.
