실무에서 헷갈리지 않는 디자인 토큰(컬러 토큰) 이름 짓기 기준과 원칙

서론

디자인 시스템을 구축하거나 팀 프로젝트를 진행할 때, 디자이너와 개발자가 가장 먼저 부딪히는 난관 중 하나는 바로 색상의 이름을 정하는 일입니다. 처음에는 단순히 '파란색', '연한 파란색' 정도로 부르다가도, 프로젝트 규모가 커지고 테마가 복잡해지면 어느 순간 파란색만 수십 개가 넘어가는 상황에 직면하게 됩니다.

이때 도입하는 것이 바로 디자인 토큰, 그중에서도 컬러 토큰입니다. 하지만 토큰을 도입하더라도 이름을 어떻게 짓느냐에 따라 시스템의 확장성이 완전히 달라집니다. 일관성 없는 이름은 오히려 소통 비용을 증가시키고 다크 모드 같은 테마 확장을 불가능하게 만듭니다. 컬러 토큰의 이름을 정할 때 어떤 기준을 세워야 유지보수가 편해지고 구성원 모두가 직관적으로 사용할 수 있는지 그 구체적인 원칙을 살펴보겠습니다.

글로벌(기본) 토큰과 시맨틱(의미) 토큰의 명확한 분리

컬러 토큰 이름을 지을 때 가장 흔히 하는 실수는 '색상 자체의 이름'과 '그 색상이 쓰이는 용도'를 섞어서 사용하는 것입니다. 이를 방지하기 위해 실무에서는 보통 토큰을 두 가지 계층으로 나누어 설계합니다. 첫 번째는 시각적인 속성 자체를 정의하는 글로벌 토큰(또는 베이스 토큰)입니다. 여기서는 색상의 이름과 명도 단계를 결합하여 'blue-100', 'gray-900'과 같이 철저히 형태 중심적인 이름을 부여합니다.

두 번째는 실제 UI 요소에 적용될 때 사용하는 시맨틱 토큰입니다. 시맨틱 토큰은 글로벌 토큰을 참조하여 '어디에', '어떤 목적'으로 쓰이는지를 설명합니다. 예를 들어 'blue-500'이라는 글로벌 토큰을 'text-primary' 또는 'button-bg-action'이라는 시맨틱 토큰으로 연결하는 방식입니다. 이렇게 두 단계를 분리해야 브랜드 컬러가 파란색에서 보라색으로 바뀌더라도, 코드 상에서는 글로벌 토큰의 참조값만 변경하면 되므로 전체 UI 코드를 수정할 필요가 없어집니다.

실무에 바로 적용하는 시맨틱 토큰 네이밍 공식

시맨틱 토큰의 이름을 지을 때는 누구나 유추할 수 있는 일관된 규칙이 필요합니다. 일반적으로 가장 많이 쓰이는 공식은 '카테고리-요소-속성-상태'의 조합을 따르는 것입니다. 예를 들어 '버튼의 배경색인데 마우스를 올렸을 때(hover)의 색상'이라면 'button-bg-hover'처럼 조합하는 식입니다. 이 공식을 팀 내에서 합의해 두면, 새로운 UI 컴포넌트가 추가되더라도 기존 규칙에 맞춰 자연스럽게 새 토큰 이름을 생성할 수 있습니다.

여기서 중요한 판단 기준은 '얼마나 구체적으로 지을 것인가'입니다. 너무 포괄적으로 'primary-color'라고만 지으면 배경, 텍스트, 테두리 중 어디에 써야 할지 모호해집니다. 반대로 'login-button-bg-hover'처럼 특정 화면이나 너무 구체적인 컴포넌트 이름을 넣으면 재사용성이 급격히 떨어집니다. 따라서 'surface', 'text', 'border', 'icon'과 같이 보편적으로 쓰이는 UI 카테고리를 활용하여 적절한 범용성을 유지하는 것이 핵심입니다.

또한 상태(State)를 나타내는 접미사를 통일하는 것도 빼놓을 수 없습니다. 기본 상태인 default부터 hover, active, disabled, focused 등의 상태값이 규칙적으로 토큰 맨 끝에 위치하도록 정렬하면, 자동완성 기능을 사용할 때 관련된 색상들을 한눈에 묶어서 볼 수 있어 개발 생산성이 크게 향상됩니다.

다크 모드와 테마 확장을 고려할 때의 주의점

디자인 토큰을 도입하면서 가장 실패하기 쉬운 패턴은 다크 모드를 고려하지 않고 이름을 짓는 경우입니다. 라이트 모드에서는 글씨가 검은색이기 때문에 시맨틱 토큰 이름을 'text-black'이라고 지었다고 가정해 보겠습니다. 이 이름은 다크 모드로 전환되는 순간 치명적인 모순을 낳습니다. 다크 모드에서는 해당 텍스트가 흰색으로 보여야 하는데, 변수 이름은 여전히 'black'을 가리키고 있기 때문입니다.

이러한 문제를 방지하려면 시맨틱 토큰의 이름에서 '시각적인 색상 명칭'을 완전히 배제해야 합니다. 검은색 텍스트라는 결과보다는 '주요 본문 텍스트'라는 역할에 집중하여 'text-primary'나 'text-body'로 지어야 합니다. 그래야 라이트 모드에서는 'gray-900'을, 다크 모드에서는 'gray-100'을 참조하도록 유연하게 분기 처리를 할 수 있습니다. 토큰 이름은 결과가 아니라 '의도'를 담아야 한다는 점을 반드시 기억해야 합니다.

컴포넌트 종속성을 피하기 위한 설계 기준

토큰을 설계할 때 겪는 또 다른 딜레마는 컴포넌트 전용 토큰을 만들지 여부입니다. 초기에는 직관성을 높이겠다고 'header-bg', 'footer-border'처럼 특정 영역의 이름을 직접적으로 명시하는 경우가 많습니다. 하지만 이는 프로젝트가 확장될 때 유지보수를 어렵게 만드는 요인이 됩니다. 만약 헤더와 동일한 시각적 속성을 가진 사이드바가 추가된다면, 사이드바에 'header-bg'를 쓰는 어색한 상황이 발생하거나, 값은 똑같지만 이름만 다른 'sidebar-bg'를 중복해서 만들어야 하기 때문입니다.

따라서 특정 UI 영역의 이름을 직접 짓는 것보다는, 시각적 계층과 용도를 기준으로 추상화하는 것이 좋습니다. 예를 들어 헤더나 모달 창처럼 배경과 분리되어 위로 떠 있는 요소들의 배경색을 묶어 'surface-elevated'라는 이름으로 정의하는 방식입니다. 이렇게 범용적인 계층 구조로 이름을 지어두면, 향후 어떤 새로운 컴포넌트가 등장하더라도 기존 토큰 시스템 안에서 무리 없이 색상을 할당할 수 있습니다.

결론

디자인 토큰에서 컬러의 이름을 짓는 과정은 단순한 네이밍 작업이 아니라, 디자이너와 개발자가 함께 사용할 '공용어'를 정의하는 매우 중요한 설계 과정입니다. 초기에 철저한 기준 없이 직관에만 의존해 이름을 짓다 보면, 결국 시스템의 일관성이 무너져 처음부터 다시 구축해야 하는 막대한 비용을 치르게 됩니다.

색상의 본질적 형태를 정의하는 글로벌 토큰과 역할을 정의하는 시맨틱 토큰을 엄격히 분리하고, 이름 안에서 시각적 정보를 배제하는 원칙만 지켜도 절반 이상의 성공입니다. 당장은 계층을 나누고 규칙을 정하는 것이 번거롭게 느껴질 수 있지만, 이 기준이 한 번 단단하게 자리 잡으면 향후 테마 추가, 브랜드 리뉴얼, 유지보수 과정에서 소통 오류를 획기적으로 줄여줄 것입니다.