2026. 5. 18. 07:50ㆍUX 가벼운 이야기
AI의 등장과 디자인 자동화가 본격화되면서, 이제는 작업 속도 자체보다 그 속도 안에서도 서비스의 일관성을 끝까지 유지할 수 있는지가 더 중요해졌습니다.
한 때는 정말 픽셀 하나, 간격 하나에 목숨 걸며 그 정교함이 디자인의 실력을 가늠하는 기준처럼 여겨지던 시절도 있었는데요.
이제는 손으로 어떻게 만들었는지보다, 어떤 기준을 세워 그 결과가 나오도록 만들었는지가 더 중요해졌다는 것이죠.
이러한 변화 속에서 디자인 시스템은 서비스를 안정적으로 운용하기 위한 핵심 인프라로 자리 잡았으며, 이를 전담 조직으로 운영하는 기업 역시 빠르게 늘어나고 있습니다.
그렇다면 디자인 시스템 중에서도 가장 기초이면서도, 동시에 가장 큰 영향을 미치는 컬러 토큰 설계는 어떤 관점에서 접근해야 할까요?
최근 진행했던 프로젝트에서 컬러 토큰 체계를 새롭게 구축하는 과정에서 얻은 경험과 인사이트를 바탕으로, 컬러 토큰 설계를 어떤 관점에서 선택하고 구조화할 수 있는지 공유해보려고 합니다.
💡 컬러 토큰의 기본 개념은 아래 글을 참고하세요 :)
3. 유연함을 갖춘 시맨틱 컬러 시스템
4. 균일한 대비값을 가진 스케일 컬러 시스템
컬러 토큰 설계 방식 살펴보기
디자인 토큰은 '무엇(Scale)'인지와 '어디(Semantic)'에 쓰이는지에 따라 스케일 중심, 시멘틱 중심, 그리고 두 방식을 접목한 하이브리드 구조로 설계할 수 있어요.
1) 스케일 토큰 : 가장 직관적이고 빠른 시작
스케일 토큰의 가장 큰 장점은 '무엇(기초값)'인지를 바로 이야기 하기 때문에 별도의 해석이나 학습, 합의 같은 과정이 필요없다는 거예요. 이는 스케일 토큰이 디자인 과정에서 만들어지는 공통 컬러 팔레트를 구조화 하고, 이를 코드화해 관리하는 방식이기 때문이죠.
예를 들어 포인트 컬러로 #1244C5(Hex값)를 사용하는 Blue가 있다면, 이 값을 기준으로 밝기와 톤을 조정해 컬러 스케일을 정의하고 $blue-100, $blue-300, $blue-500처럼 단계별 값으로 관리하는거죠. 이렇게 정의된 스케일 토큰을 “주요 액션 버튼에는 $blue-500을 사용한다”와 같은 가이드를 통해 디자이너와 개발자 간에 바로 커뮤니케이션될 수 있어요.
하지만 서비스의 복잡도가 높아진다면 이야기는 달라지죠.
기초값으로만 정의되어 있기 때문에 그 색을 ‘왜' 여기에 썼는지 맥락이 남아있지 않은 상태로 존재하게 되는데요.
이로인해 서비스의 확장이 어려울 수 있어요. 의미와 목적이 명시되어 있지 않기 때문에 기존 화면을 다시 분석하거나, 히스토리 추적을 해야하는 불필요한 공수가 발생하게 되죠.
또한 공통 수정이 필요한 경우에도 해당 색이 사용된 화면을 직접 찾아 맥락을 파악하고, 코드까지 함께 수정해야 하는 상황이 반복되며 시간이 지날수록 누적되어 부채로 남게 되기도 합니다.
그래서 관리자는 서비스의 방향성과 디자인 맥락을 충분히 이해한 상태에서, 새로운 색이 언제, 어떤 기준으로 스케일에 편입되는지를 꾸준히 트래킹하고 관리해야 해요. 관리자의 판단이 서비스의 품질과 확장 비용에 직접적인 영향을 미치기 때문이죠.
이런 이유로 스케일 토큰 중심 설계는 설계에 투입할 수 있는 리소스가 제한된 초기 프로젝트나, 최소한의 브랜드 컬러를 중심으로 빠른 대응이 필요한 서비스, 혹은 브랜드 아이덴티티를 깊이 이해한 디자이너가 주도하는 소규모 팀에 적합한 구조라고 볼 수 있어요.
2) 시멘틱 토큰 : 다양한 환경에 유연한 대응
시멘틱 토큰 중심 설계는 색상 값 자체보다, 그 색이 어떤 역할과 상태를 가지는지를 먼저 정의하는 방식입니다.
UI 맥락에 맞는 토큰명을 먼저 정하고, 그 안에 실제 Hex 값을 연결해 사용하는 구조라고 볼 수 있어요. 이렇게 설계하면 디자인과 개발 모두가 색을 값이 아니라 역할과 맥락의 관점에서 다루게 돼요.
예를 들면 “블루를 사용한다”가 아니라 “이 블루는 버튼에 사용한다" 라고 말해주는 거라고 보면 쉬워요. 색 자체보다, 어디에 쓰이는지 목적을 명확히 해주는거죠. 이처럼 공통으로 합의된 의미로 소통하기 때문에 각자의 해석이 개입할 수 없다는 점이 가장 큰 장점이에요. 그 결과 시스템 전반의 일관성을 비교적 안정적으로 관리할 수 있어요.
그래서 시멘틱 토큰 중심 설계는 멀티 테마를 운영하거나, 접근성 기준을 체계적으로 반영해야하는 서비스에서 특히 효과적으로 활용할 수 있어요. 색에 대한 합의가 구조 안에 들어가면서 커뮤니케이션 비용일 확실히 줄어들어요.
이미 코드에는 '의미'로 부여되어 있기 때문에 "버튼의 배경색을 라이트 모드에서는 블루를 쓰고, 다크 모드에서는 화이트를 써." 처럼 의도만 전달해주면 구체적인 색상 값은 시스템이 알아서 처리하는거죠.
다만 시멘틱 토큰 중심 설계는 초기 설계와 합의 과정에 드는 비용이 비교적 큰 편이에요.
각 컬러가 어떤 역할을 하고, 어디까지 사용될 수 있는지를 미리 정의해야하고, 토큰 이름 하나하나에도 조직 차원의 합의가 필요하기 때문이죠. 이 과정이 충분하지 않으면 의미가 모호한 토큰만 늘어나게 되고, 결국 관리하기 어려운 구조로 이어지면서 코드 부채가 쌓이게 될 가능성도 커져요.
시멘틱 토큰은 "결정론적 디자인"이라고 볼 수 있어요.
어떠한 상황에서도 시스템이 예측 가능한 결과물을 내놓아야한다는게 기본 전제죠.
그렇다 보니 디자인은 제한적일 수 밖에 없고, 디자이너의 역할 역시 그 기준 안에서 판단하고 적용하는 오퍼레이터의 역할로 축소되죠.
그래서 시멘틱 토큰 중심 설계는 브랜딩이 강한 서비스보다 Hexagrid와 같이 다국어, 다중 테마 등과 같이 유연하게 대응해야 하는 서비스에서 활용도가 높아요. 일관된 기준을 유지한 채로 변화를 관리해야 하는 경우에 강점을 발휘하는 방식이라고 볼 수 있어요.
3) 스케일과 시멘틱의 하이브리드 : 변화에 강한 시스템 구조
하이브리드 구조는 스케일 토큰과 시멘틱 토큰의 강점을 접목해서 설계하는 방식이라고 볼 수 있어요.
디자인 컬러값은 스케일 토큰으로 설계해 디자인 유연성을 열어두고, 소통은 의미와 맥락을 담아 시멘틱 토큰으로 적용해 소통과 운영을 구조화하는 방식이에요.
예를 들어 $blue-100, $blue-300, $blue-500 등 과 같은 스케일 토큰을 정의한 뒤, 이를 $fill/brand/primary처럼 역할이 명확한 시멘틱 토큰에 연결해 사용하는 방식이에요. 화면과 디자인 커뮤니케이션에서는 의미를 담고 있는 시멘틱 토큰명으로 소통하고, 실제 색상 값의 변경이나 조정은 스케일 토큰 단계에서 관리를 하게 되는 구조죠.
이 구조의 가장 큰 장점은 유연성과 확장성을 동시에 가져갈 수 있다는 거에요.
리브랜딩처럼 컬러 조정이 필요할 경우, 스케일 토큰 값만 변경하면 이와 연결된 시멘틱 토큰도 자동으로 업데이트되면서 제품 전반에 한 번에 반영할 수 있죠.
컬러 테마를 추가할 경우도 마찬가지예요. 이미 시멘틱 토큰 기준으로 구조가 잡혀 있기 때문에, 테마별로 참조하는 컬러 스케일만 정의해주면 새로운 테마도 비교적 수월하게 확장할 수 있어요. 이 덕분에 컬러 변경이 화면 수정이 아니라, 구조를 조정하는 작업으로 바뀌게 되는거죠.
이런 이유로 서비스의 확장성과 유연성을 동시에 만족해야 하는 기업들에서는 하이브리드 구조를 많이 선택하고 있어요.
실제로 당근이나 토스처럼 서비스 규모가 크고, 다양한 환경과 사용 맥락을 함께 고려해야 하는 경우에 이 구조가 효과적으로 활용되고 있는 것으로 알려져 있어요. 특히 당근의 사례를 보면, 시멘틱 토큰 단계에서 가독성과 대비 기준을 함께 고려하는 접근을 취하고 있고, APCA 알고리즘* 과 같은 지각 대비 기준을 참고해 기기 모드나 환경에 따라 컬러 명도가 자연스럽게 조정될 수 있는 적응형 컬러 구조를 설계한 것으로 소개되고 있어요.
※ APCA 알고리즘 이란?
APCA는 단순한 명도 차이가 아니라, 사람이 실제로 인식하는 가독성을 기준으로 텍스트와 배경의 대비를 계산하는 알고리즘이에요.
기존의 WCAG 대비 비율이 숫자 중심의 기준이었다면, APCA는 글자의 크기, 두께, 화면 환경까지 고려해 “이 텍스트가 읽히는가”를 판단하는 데 초점을 둡니다. 그래서 다크 모드나 다양한 기기 환경에서도 보다 안정적인 가독성을 확보하는 데 활용되고 있어요.
또한 현재 개발 중인 WCAG 3.0에서 이 APCA를 새로운 색상 대비 표준으로 채택할 예정이라고 해요.
이런 구조에서는 스케일 토큰이 변경될 때, 대비 부족으로 인해 가독성이 떨어질 가능성을 화면 단위가 아니라 토큰 단계에서 미리 발견하고 조정할 수 있어요. 이게 가능한 이유는 스케일 토큰으로 컬러가 묶여져 있고, 이 값이 시멘틱 토큰을 통해 어디에, 어떤 목적으로 사용되는지 명확하게 정의되어 있기 때문이에요.
하지만 하이브리드 구조는 단일 구조로 설계할 때보다 초기 설계 비용이 더 많이 드는 방식이기도 합니다.
스케일 토큰과 시멘틱 토큰을 각각 설계해야 할 뿐만 아니라, 두 계층을 어떻게 연결할지에 대한 구조까지 함께 고민해야 하기 때문이에요.
초기 설계가 충분히 정리되지 않은 상태에서 하이브리드 구조를 도입하면, 값과 의미가 동시에 늘어나면서 토큰 수가 과도하게 증가하는 이른바 ‘토큰 스프롤(Token Sprawl)’ 상태로 이어질 수 있습니다.
이 경우 문제는 문서나 구조에만 머무르지 않고, 색의 일관성 저하나 가독성, 속도 문제처럼 서비스 품질로 바로 체감되기 시작하죠.
그래서 하이브리드 구조에서는 새로운 토큰을 추가할 때마다 “이건 새로운 값의 문제인가, 아니면 새로운 의미의 문제인가”를 먼저 판단하는 과정이 중요해요. 이 기준이 명확할수록 토큰 구조는 불필요하게 비대해지지 않고, 확장성과 안정성을 비교적 균형 있게 유지할 수 있습니다.
그래서, 어떤 선택이 우리에게 맞을까
컬러 토큰 체계를 도입할 때, 서비스가 지금 어떤 단계에 있는지, 무엇을 가장 우선해야 하는지를 분명히 짚고 넘어가야 합니다.
당연한 이야기처럼 들릴 수 있지만, 방향이 정리되지 않은 상태에서 특정 ‘방식’부터 선택해버리면 이후에 감당해야 할 리스크는 생각보다 훨씬 커져요.
이와 함께 조직의 구조와 성격도 아주 중요한 고려사항이에요.
디자인 중심의 의사결정이 중요한 조직인지, 개발 중심으로 빠른 구현이 우선되는 환경인지, 혹은 협업과 유연함을 얼마나 중시하는지에 따라 적합한 설계 방식을 채택해야하죠.
그리고 무엇보다 중요한 건, 그 선택을 팀 안에서 하나의 ‘약속’으로 명확히 공유하는 일이라고 생각해요.
컬러 토큰은 개인의 취향이나 노하우가 아니라, 함께 일하는 사람들이 같은 기준으로 판단하고 움직이기 위해 합의한 구조이기 때문입니다. 결국 컬러 토큰 설계의 완성도는 어떤 방식을 선택했느냐보다, 그 기준을 팀이 얼마나 일관되게 이해하고 지켜나가느냐에 달려 있습니다.