컬러 토큰 설계 방식 공부 정리 | 스케일이냐, 시멘틱이냐
스케일·시멘틱·하이브리드 세 가지 방식을 비교하며 정리해봤다.
디자인 시스템 공부를 하다 보면 컬러 토큰 얘기가 자주 나온다. 근데 막상 “토큰 구조를 어떻게 잡냐”까지 구체적으로 다루는 글은 많지 않더라. PXD 블로그에서 스케일·시멘틱·하이브리드 세 가지 방식을 프로젝트 경험과 함께 비교한 글을 봤는데, 정리가 잘 되어 있어서 읽어봤다.
읽으면서 계속 마음에 걸렸던 게 하나 있었다. “어떤 방식이 더 낫냐”가 아니라 “지금 서비스가 어느 단계냐”가 결국 선택을 결정한다는 것. 그 지점이 흥미로웠다.
1️⃣ 이게 뭐냐?
컬러 토큰은 두 기준으로 나뉜다. “무엇인가($blue-500처럼 색상값 그 자체)”와 “어디 쓰이는가($fill/brand/primary처럼 역할)”다. 이 두 기준을 어떻게 조합하느냐가 세 가지 방식의 갈림길이 된다.
스케일 토큰은 색상값을 단계로 팔레트화해두는 방식이다. $blue-100, $blue-300, $blue-500 식으로 정리하고, 가이드를 통해 “버튼에는 $blue-500“처럼 소통한다. 빠르게 시작할 수 있다는 게 가장 큰 장점이다. 다만 서비스가 복잡해지면 “이 색을 왜 여기에 쓴 건지”가 코드에도 파일에도 남지 않는다. 히스토리를 추적하거나 공통 수정이 생길 때 그게 부채로 쌓인다.
시멘틱 토큰은 역할 이름을 먼저 정하고 거기에 값을 연결하는 구조다. $fill/brand/primary에 실제 색상값을 연결하는 식이다. 색이 아니라 역할로 소통하게 되니 일관성 관리가 훨씬 안정적이다. 다크 모드나 멀티 테마를 염두에 두는 서비스에 잘 맞는다. 단점은 초기 설계 비용이 높다는 것. 팀 전체가 토큰 이름 체계를 합의해야 하고, 그게 충분히 이루어지지 않으면 관리가 오히려 꼬인다.
하이브리드는 두 층을 쌓는 방식이다. 스케일 토큰이 기초값을 들고 있고, 시멘틱 토큰이 그걸 참조한다. 리브랜딩이 생기면 스케일 층만 바꿔도 시멘틱 층 전체가 따라온다. 강력하긴 한데, 새 토큰을 추가할 때마다 “이게 새 값의 문제냐, 새 의미의 문제냐”를 계속 판단해야 한다. 그 기준이 흔들리면 토큰 수가 비대해지는 문제가 생긴다.
2️⃣ 내가 든 생각
처음 세 방식을 나란히 보면서 “이건 무조건 하이브리드가 맞겠다”고 생각했다. 확장성도 되고, 리브랜딩 대응도 되니까.
근데 읽다 보니 생각이 조금 달라졌다. 하이브리드의 전제 조건이 생각보다 무겁더라. 스케일과 시멘틱을 동시에 설계해야 하고, 운영 중에도 기준 판단을 팀이 계속 공유해야 한다. 그 구조를 유지할 수 있는 조직이어야 효과가 나온다는 게 느껴졌다. 당근·토스 같은 곳이 하이브리드를 쓰는 건, 결국 그 복잡성을 감당할 규모이기 때문인 것 같았다.
👉🏻 글에서 가장 인상적이었던 지점은 마지막이었다. “선택한 기준을 팀이 약속으로 공유하는 것이 완성도를 결정한다”는 문장. 어떤 방식이냐보다 그게 핵심에 더 가까운 것 같았다.
💡 여기서 드는 질문? 소규모 팀에서 디자인 시스템을 처음 시작할 때, 스케일부터 잡고 나중에 시멘틱 층을 얹는 게 오히려 현실적인 접근일 수 있지 않을까?
3️⃣ 앞으로 어떻게 볼까?
지금 단계에서는 직접 토큰 구조를 짜볼 상황보다 남이 만든 디자인 시스템을 읽거나 참고하는 경우가 많다. 문서만 본 입장에서는 어떤 방식으로 설계됐는지를 알고 보면, 왜 이런 네이밍인지가 조금 더 이해되는 것 같다.
특히 시멘틱 토큰 기반 시스템을 볼 때, 토큰명에 역할이 담겨있으면 컴포넌트 설계 의도를 읽기가 훨씬 쉬웠다. 공부한 내용 기준으로는 그게 시멘틱 방식의 실질적인 이점인 것 같다.
⭐️ 마지막으로, 디자인 시스템을 공부하면서 느낀 것
공부 끝에 남은 건 “선택의 기준은 도구보다 팀의 상태”라는 한 줄이다.
스케일이든 시멘틱이든 하이브리드든, 어느 걸 고르느냐보다 팀이 그 기준을 얼마나 일관되게 유지할 수 있는지가 설계의 완성도를 만드는 것 같았다. 컬러 토큰 설계가 기술 선택보다 팀의 약속에 더 가까운 일이라는 게, 공부하면서 생각보다 오래 남는 부분이었다.