디자인 토큰 입문 - 색상 코드가 아니라 결정을 저장하는 법

브랜드 색을 조금 바꾸기로 했다고 해 봅시다. 담당자는 "색 하나 바꾸는 건데 금방 되죠?"라고 묻는데, 개발자의 표정이 어둡습니다. 그 파란색이 코드 여기저기에 #3B82F6 이라는 값으로 마흔 군데쯤 흩어져 있고, 그중 어떤 것은 버튼이고 어떤 것은 링크이고 어떤 것은 무관한 아이콘 색이기 때문입니다. 전부 찾아서, 하나하나 "이건 바꿔야 하는 파랑인가"를 판단해야 합니다.

디자인 토큰은 이 문제를 구조로 해결하는 방법입니다. 개념 자체는 간단한데 효과가 커서, 요즘 디자인 시스템 이야기에서 빠지지 않고 등장합니다.

토큰은 값이 아니라 결정을 저장한다

디자인 토큰의 정의는 한 줄입니다. 디자인 결정에 이름을 붙여 한 곳에 저장한 것.

#3B82F6 은 그냥 값입니다. 반면 색상-강조(brand-accent) = #3B82F6 이라고 적어 두면, 이것은 "우리 서비스의 강조색은 이 파랑이다"라는 결정의 기록이 됩니다. 화면 곳곳에서는 값 대신 이름을 부릅니다. 버튼도 링크도 "강조색을 써라"라고만 말하는 거죠.

이렇게 해 두면 앞의 리브랜딩 문제가 사라집니다. 결정이 저장된 한 곳에서 값을 바꾸면, 그 이름을 부르던 모든 화면이 한 번에 따라옵니다. 마흔 군데 수색 작업이 한 줄 수정으로 줄어드는 것입니다.

층을 나누면 힘이 세진다

실무에서 토큰은 보통 두세 층으로 쌓습니다.

1층은 팔레트입니다. 우리가 쓰는 원료 값들 - 회색 아홉 단계, 파랑 몇 단계 - 에 gray-900, blue-500 같은 이름을 붙여 둡니다. 여기까지만 하는 팀이 많은데, 진짜 효과는 다음 층에서 나옵니다.

2층은 용도입니다. 본문색 = gray-900, 테두리색 = gray-200, 강조색 = blue-500 처럼, 팔레트의 값을 용도에 연결합니다. 화면을 만들 때는 이 용도 이름만 씁니다.

이 분리가 왜 중요한가. 다크 모드를 생각해 보면 됩니다. 용도 층이 있으면 "다크 모드에서는 본문색을 gray-100 에 연결한다"라는 연결 교체만으로 사이트 전체가 전환됩니다. 용도 층이 없이 화면마다 gray-900 을 직접 썼다면, 다크 모드는 전 화면 개조 공사가 됩니다. 브랜드 색 교체, 계열사 테마 적용 같은 일도 전부 같은 원리로 쉬워집니다.

디자이너와 개발자가 같은 사전을 쓰게 된다

토큰의 두 번째 효용은 소통에 있습니다. 디자인 도구(Figma 의 변수 기능)와 코드(CSS 변수)가 같은 이름의 목록을 쓰도록 맞춰 두면, 시안과 구현 사이의 번역 오류가 크게 줄어듭니다. 디자이너가 "여기는 테두리색"이라고 지정하면 개발자도 같은 이름을 가져다 쓰면 끝이라, "시안이랑 회색이 미묘하게 다른데요" 같은 왕복이 사라집니다.

말하자면 토큰 목록은 두 직군이 공유하는 사전입니다. 사전이 없으면 매번 통역이 필요하고, 통역에는 반드시 누락이 생깁니다.

작은 팀일수록 시작이 쉽고 효과가 크다

디자인 토큰이 대기업 디자인 시스템의 전유물처럼 들릴 수 있는데, 실제로는 반대입니다. 결정을 내릴 사람이 적은 팀일수록 "한 번 정해 두고 재사용하는" 구조의 이득이 큽니다. 디자인 시스템을 다룬 글에서 말한 "규칙의 힘"의 가장 작은 단위가 토큰입니다.

시작 순서도 거창할 필요가 없습니다. 지금 운영 중인 사이트에서 실제로 쓰인 색을 전부 추출해 보면 대개 수십 가지가 나옵니다(같은 회색이 네다섯 종류로 미세하게 갈라져 있는 경우가 흔합니다). 이걸 열몇 개로 통합하고, 각각에 용도 이름을 붙이는 것 - 여기까지가 첫걸음이고, 반나절이면 합니다. 글자 크기와 간격도 같은 방식으로 단계를 정해 두면 화면의 인상이 눈에 띄게 정돈됩니다.

이름을 짓는 요령 - 위치나 모양이 아니라 역할로

토큰 도입에서 실제로 가장 헤매는 지점은 기술이 아니라 작명입니다. 요령은 하나입니다. 그 값이 "어디에 있는지"나 "어떻게 생겼는지"가 아니라 "무슨 역할인지"로 이름을 짓는 것.

진한회색은 나쁜 이름입니다. 다크 모드에서 그 자리에 밝은 회색이 들어가는 순간 이름이 거짓말이 됩니다. 푸터-배경색도 위험합니다. 같은 색을 헤더에도 쓰게 되면 푸터 이름을 헤더에 부르는 어색한 코드가 남습니다. 반면 표면-배경, 본문-기본, 테두리-약함 같은 역할 이름은 값이 바뀌어도, 쓰이는 자리가 늘어나도 유효합니다.

판별법도 간단합니다. "이 토큰의 값을 정반대로 바꿔도 이름이 말이 되는가"를 물어보면 됩니다. 말이 되면 역할 이름이고, 안 되면 값을 묘사한 이름입니다.

흔한 실수 세 가지

용도 층을 건너뛰는 것. blue-500 같은 팔레트 이름만 만들어 화면에 직접 쓰면, 값을 정리한 것이지 결정을 저장한 게 아닙니다. 리브랜딩과 다크 모드에서 다시 수색 작업을 하게 됩니다.

처음부터 완벽한 체계를 노리는 것. 토큰 명명법과 계층 설계를 공부하다가 시작을 못 하는 경우가 의외로 많습니다. 색, 글자 크기, 간격 - 이 세 가지의 용도 토큰이면 충분한 출발입니다.

만들어 놓고 안 지키는 것. 급하다고 화면에 값을 직접 박기 시작하면 사전은 몇 달 만에 죽은 문서가 됩니다. "토큰에 없는 값을 쓰려면 토큰을 먼저 추가한다"는 규칙 하나가 체계 전체를 지킵니다.