주제 소개

서비스가 커질수록 화면 수보다 빠르게 늘어나는 것이 있습니다. 바로 “거의 같은데 조금 다른” 값들입니다. 비슷한 회색이 여러 개 생기고, 여백은 화면마다 4px씩 어긋나고, 다크 모드를 붙이려는 순간 어디부터 손대야 할지 막막해집니다.

우리는 이 문제를 도구보다 언어의 문제로 봅니다. 값이 흩어지는 이유는 대부분 팀이 같은 대상을 서로 다른 이름으로 부르기 때문입니다. 디자인 토큰은 색, 글자 크기, 간격, 둥근 모서리, 그림자 같은 디자인 결정을 이름이 붙은 값으로 정리한 것입니다. 이 글에서는 토큰을 어떤 구조로 나누면 좋은지, 그리고 팀이 실제로 쓰게 만들려면 무엇이 필요한지 정리해 봅니다.

분석

1. 값에 이름을 붙이는 세 단계

토큰은 보통 세 층으로 나눕니다.

• 기본 토큰(Primitive): 팔레트 그 자체입니다. blue-500, gray-100처럼 값이 무엇인지만 말합니다.
• 의미 토큰(Semantic): 그 값이 어디에 쓰이는지를 말합니다. color-action-primary, color-text-subtle처럼요.
• 컴포넌트 토큰(Component): 특정 부품에만 쓰는 값입니다. button-primary-background 같은 이름입니다.

핵심은 화면을 만들 때 기본 토큰을 직접 쓰지 않는 것입니다. 버튼에 blue-500을 바로 칠해 두면, 나중에 브랜드 색이 바뀔 때 파란색이 쓰인 모든 곳을 하나씩 찾아야 합니다. color-action-primary를 쓰면 연결된 값 하나만 바꾸면 됩니다.

2. 이름은 “어떻게 보이는가”가 아니라 “무슨 역할인가”로

color-light-gray라는 이름은 다크 모드에서 바로 거짓말이 됩니다. 어두운 화면에서는 같은 역할의 색이 짙은 회색이 되기 때문입니다. 그래서 의미 토큰의 이름은 생김새가 아니라 역할로 짓습니다. surface-raised(한 단계 떠 있는 면), border-default(기본 테두리)처럼요. 이렇게 하면 라이트와 다크 모드는 같은 이름에 다른 값을 연결하는 일로 단순해집니다.

3. 팬덤 서비스에서 특히 중요한 이유

팬덤 서비스는 화면의 분위기가 자주 바뀝니다. 아티스트나 이벤트에 따라 대표 색이 달라지고, 라이브 무대처럼 어두운 화면과 굿즈 스토어처럼 밝은 화면이 한 앱 안에 함께 있습니다. 이때 토큰 구조가 잡혀 있으면, 이벤트 테마는 의미 토큰 일부만 덮어쓰는 방식으로 만들 수 있습니다. 구조 없이 매번 새로 칠하면 이벤트가 끝날 때마다 화면 곳곳에 지난 색이 남습니다.

4. 디자인 도구와 코드를 같은 이름으로

토큰은 디자인 파일 안에서만 쓰이면 반쪽짜리입니다. 피그마의 변수 이름과 개발 코드의 변수 이름이 같아야, 핸드오프 때 “이 회색이 뭐예요?”라는 질문이 사라집니다. 이름 규칙을 한 문서에 정리하고, 디자이너와 개발자가 함께 검토하는 과정이 필요합니다.

시사점

토큰 작업에서 가장 어려운 것은 값을 정하는 일이 아니라 이름에 합의하는 일입니다. 그래서 처음부터 완벽한 체계를 만들기보다, 색과 간격처럼 자주 쓰는 영역부터 작게 시작하는 편이 좋습니다. 그리고 새 토큰을 만들기 전에 “기존 이름으로 설명할 수 없는가?”를 먼저 묻는 습관이 체계를 오래 지켜 줍니다.

또 하나, 토큰은 문서가 아니라 운영입니다. 누가 새 토큰을 승인하는지, 쓰지 않는 토큰은 언제 정리하는지 정해 두지 않으면 몇 달 뒤 다시 “거의 같은 회색”이 늘어납니다.

정리

디자인 토큰은 결국 팀이 같은 말을 쓰기 위한 사전입니다. 역할로 이름 짓고, 세 단계로 나누고, 디자인과 코드에서 같은 이름을 쓰는 것. 이 세 가지만 지켜도 화면이 늘어날 때의 혼란은 눈에 띄게 줄어듭니다. 우리도 이 사전을 계속 고쳐 가며 쓰고 있습니다.