KRDS 색상 토큰 1,082개, 왜 이렇게 많나

KRDS 색상 토큰 1,082개, 왜 이렇게 많나

---

ViewCheck 마케팅 홍보 — 2026년 9월 · W2 색상 586 토큰 (9/14~9/20)

대주제: 디자인 일관성·토큰 · 홍보 훅: 토큰 채택률 리포트

【 공감·문제제기 】

“색이 몇 개나 필요해요? 파랑 하나, 회색 몇 단계, 빨강 하나면 충분하지 않나요?”

공공 웹 개편 회의에서 디자인 토큰 이야기를 꺼내면 거의 빠짐없이 나오는 반응이다. 그럴 만도 하다. 우리가 평소에 색을 떠올릴 때는 ‘파랑’ ‘초록’ ‘빨강’ 정도의 큰 덩어리로 생각하지, 그 파랑이 사실 수십 갈래로 나뉜다는 상상은 잘 안 한다. 그런데 KRDS가 정리해둔 색상 토큰의 개수를 처음 들으면 다들 멈칫한다. 586개. 색이 오백개가 넘는다고?

솔직히 나도 그 숫자를 처음 봤을 때 ‘이건 좀 과한 거 아닌가’ 싶었다. 천 개가 넘는 색을 누가 다 쓰고, 누가 다 관리한단 말인가. 디자이너도 아닌 담당자가 이걸 들여다본다고 생각하니 벌써 머리가 아팠다. 그런데 그 586개라는 숫자의 ‘속’을 들여다보고 나서 생각이 완전히 바뀌었다. 결론부터 말하면, 그 천 개는 ‘천 개의 색’이 아니다. ‘천 개의 색을 쓰라는 강요’는 더더욱 아니다. 오히려 그 반대다. 색을 함부로 늘어나지 못하게 묶어두기 위한, 일종의 ‘색의 호적부’에 가깝다.

이 글은 그 586이라는 숫자의 정체를 풀어보려는 글이다. 디자인 토큰이라는 말이 낯선 분, ‘색이 천 개라니 부담스럽다’고 느낀 분, 혹은 ‘우리 사이트는 색 몇 개로 잘 굴러가는데 왜 이런 게 필요하냐’고 생각하는 분을 위한 입문 글이다. 어려운 용어는 최대한 풀어 쓰고, 비유를 많이 섞을 생각이다. 디자인 전공자가 아니어도, 코드를 몰라도, 사이트 하나 운영해본 사람이라면 충분히 끝까지 읽을 수 있게 쓰려고 한다.

미리 큰 그림을 그려두면 이렇다. 색상 토큰이라는 건 ‘색에 이름표를 붙이고, 그 이름표로 색을 부르는 방식’이다. ‘#1F4E79’ 같은 암호 같은 코드 대신, ‘주 버튼 배경색’ ‘경고 텍스트 색’ ‘비활성 테두리 색’처럼 역할로 색을 부르는 것이다. 그리고 그 이름표가 잘 정리되면, 색이 제멋대로 늘어나는 일을 막을 수 있다. 586개라는 숫자는 색을 ‘많이 만든’ 결과가 아니라, 공공 웹에서 필요한 색의 ‘역할’을 빠짐없이 정리하다 보니 자연스럽게 나온 결과다.

조금 더 솔직하게 이야기를 풀어보자. 공공 웹 담당자라는 자리는 색에 대해 ‘판단’은 해야 하는데 ‘기준’은 없는, 묘한 위치에 놓여 있다. 외주 업체가 시안을 가져오면 “이 파랑이 맞나?” “이건 너무 튀지 않나?” 같은 감을 동원해 검수해야 한다. 그런데 그 감이라는 게 사람마다 다르고, 같은 사람이라도 그날 컨디션에 따라 다르다. 어제는 괜찮아 보이던 색이 오늘은 거슬린다. 위에서는 “좀 더 신뢰감 있게”라고 하는데, 그 신뢰감을 색으로 어떻게 옮기라는 건지 막막하다. 결국 ‘느낌’으로 통과시키고, 그 느낌은 다음 사업에서 또 흔들린다.

색상 토큰은 바로 그 ‘느낌’을 ‘약속’으로 바꿔주는 장치다. “좀 더 신뢰감 있게”가 아니라 “주 색상 토큰을 그대로 쓰고, 강조는 강조색 토큰만 사용해 주세요”라고 말할 수 있게 된다. 모호한 요구가 구체적인 요구가 되고, 구체적인 요구는 검수 가능한 요구가 된다. 천 개가 넘는 토큰은 그 약속을 빈틈없이 만들기 위한 재료일 뿐, 담당자가 외워야 할 숙제가 아니다.

한 가지 미리 안심시켜 드리자면, 이 글을 다 읽는다고 해서 색 전체를 외우게 되는 일은 없다. 오히려 ‘아, 이래서 오백개 이상이 나온 거구나, 그러면 나는 그중 몇 개만 신경 쓰면 되겠네’ 하는 안도감을 얻게 될 거라고 본다. KRDS의 색상 토큰은 부담을 더하는 규제가 아니라, 색에 관한 끝없는 잔소리와 재작업을 줄여주는 도구다. 그 관점으로 끝까지 따라와 주면 좋겠다.

사실 이 ‘색의 난립’ 문제는 누구의 잘못이라고 딱 짚기 어려운, 구조적인 문제다. 어느 한 담당자가 게을렀거나 어느 한 업체가 무성의했던 게 아니다. 공공 웹은 부서별로, 사업별로, 시기별로 따로 만들어지고, 그 사이마다 담당자가 바뀌고 업체가 교체된다. 각자가 자기 자리에서 최선을 다해도, 그 최선들을 묶어줄 ‘공통의 색 기준’이 없으면 결과는 제각각이 된다. 그러니 이 글은 누구를 탓하려는 글이 아니다. ‘기준이 없으면 누구에게나 일어나는 일’을 짚고, ‘그래서 공통 기준이 왜 필요한가’를 함께 납득해보자는 글이다. 색이 흩어지는 건 사람의 문제가 아니라 시스템의 문제이고, 시스템의 문제는 시스템으로 풀어야 한다는 게 오늘의 출발점이다.

이 글의 흐름을 미리 일러두면 이렇다. 먼저 ‘토큰’이라는 말부터 우표·옷장 같은 비유로 쉽게 풀고, 색을 코드가 아니라 이름으로 부르는 게 왜 중요한지 짚는다. 그 다음 586개라는 숫자가 어떻게 ‘색 몇 종 × 밝기 단계 × 역할’의 곱으로 쪼개지는지 보여주고, 왜 이렇게까지 잘게 나눴는지를 설명한다. 이어서 토큰이 없을 때 공공 사이트에서 실제로 어떤 일이 벌어지는지 익명 사례로 풀고, 마지막으로 ‘그래서 담당자는 무엇부터 하면 되는지’를 실무 단계로 정리한다. 처음부터 끝까지 ‘어려운 걸 쉬운 비유로 바꾼다’는 원칙을 지킬 테니, 편하게 읽어 내려가면 된다.

【본론】

■ ‘토큰’이라는 말부터 풀어보자 — 색에 붙이는 이름표

토큰(token)이라는 단어가 거창하게 들릴 수 있다. 하지만 개념 자체는 의외로 단순하다. ‘이름표’라고 생각하면 거의 정확하다.

우리는 평소에 색을 ‘코드’로 다룬다. 웹에서 색은 ‘#1F4E79’ 같은 여섯 자리 암호로 표현된다. 이게 무슨 색인지는 그 코드만 봐서는 알 수 없다. 디자인 파일을 열어 색을 찍어봐야 ‘아, 짙은 남색이구나’를 안다. 문제는, 같은 짙은 남색이 사이트 곳곳에 흩어져 쓰일 때다. 메인 배너에도, 주 버튼에도, 표 머리글에도 그 색이 들어가 있는데, 각각이 ‘#1F4E79’라는 코드로만 적혀 있으면, 나중에 그 색을 살짝 바꾸고 싶을 때 모든 자리를 일일이 찾아다녀야 한다. 어디에 그 색이 쓰였는지 아무도 정확히 모르기 때문이다.

토큰은 이 문제를 해결한다. 색에 ‘이름’을 붙이는 것이다. ‘#1F4E79’라는 코드 대신 ‘주 색상’이라는 이름을 정해두고, 사이트 곳곳에서 그 코드를 직접 쓰는 게 아니라 ‘주 색상’이라는 이름을 불러 쓴다. 그러면 나중에 ‘주 색상’의 실제 값을 한 군데에서만 바꿔도, 그 이름을 부르고 있던 모든 자리가 한꺼번에 바뀐다. 코드를 직접 박아 넣는 것과 이름을 불러 쓰는 것의 차이는, 나중에 가서야 진가가 드러난다.

옷장 비유가 이해에 도움이 된다. 매일 아침 “남색 카디건, 회색 면바지, 흰 셔츠”라고 옷을 하나하나 떠올려 입는 사람이 있다고 하자. 그런데 어떤 사람은 옷장을 ‘출근용 한 벌’ ‘운동용 한 벌’ ‘격식 차림 한 벌’처럼 ‘용도’로 묶어둔다. 후자는 “오늘은 출근용”이라고만 정하면 어떤 옷을 입을지 자동으로 따라온다. 게다가 ‘출근용’의 구성을 바꾸고 싶으면 그 묶음만 손보면 된다. 토큰이 바로 이 ‘용도로 묶기’다. 색을 그 자체의 코드로 부르지 않고, ‘이 색은 무슨 역할을 하는가’라는 용도로 불러 관리하는 방식이다.

여기서 핵심 단어가 ‘역할’이다. 토큰의 진짜 힘은 색을 ‘무슨 색인가’가 아니라 ‘무슨 일을 하는 색인가’로 부른다는 데 있다. ‘파랑’이 아니라 ‘주 버튼 배경’, ‘빨강’이 아니라 ‘오류 안내’, ‘회색’이 아니라 ‘비활성 상태’. 이렇게 역할로 부르면, 디자인을 만드는 사람도 검수하는 사람도 같은 언어로 대화할 수 있다. “이 빨강 좀 바꿔주세요”가 아니라 “이건 오류 안내 토큰이어야 하는데 그냥 강조색 토큰을 잘못 쓴 것 같아요”라고 정확히 짚을 수 있다. 모호함이 사라지는 순간이다.

조금 더 풀어보자. 토큰은 보통 두 겹으로 이루어진다. 첫 번째 겹은 ‘원래의 색’ 그 자체다. 짙은 남색, 밝은 하늘색, 중간 회색처럼 ‘색의 원재료’를 정해두는 층이다. 두 번째 겹은 그 원재료에 ‘역할’을 붙이는 층이다. ‘주 색상은 짙은 남색을 쓴다’ ‘오류색은 진한 빨강을 쓴다’처럼, 역할이라는 이름표가 원재료를 가리키게 만드는 것이다. 이 두 겹이 분리돼 있어야, 나중에 ‘주 색상을 짙은 남색에서 약간 더 푸른 남색으로 바꾸자’는 결정이 한 줄 수정으로 끝난다. 역할이라는 이름표는 그대로 두고, 그 이름표가 가리키는 원재료만 바꾸면 되니까.

이 ‘두 겹 구조’가 586이라는 숫자를 이해하는 첫 번째 열쇠다. 색의 원재료가 수백 개, 거기에 역할이라는 이름표가 또 수백 개 붙으니, 둘을 합치면 자연스럽게 천 단위가 된다. 즉 586개는 ‘수백 가지 서로 다른 색’이 아니라, ‘색 원재료 + 역할 이름표’를 모두 합산한 ‘토큰의 총 개수’다. 이 구분만 머리에 넣어도 대략 600 개라는 숫자의 압박감이 절반은 줄어든다.

왜 굳이 두 겹으로 나눴는지, 한 겹이면 안 되는지 궁금할 수 있다. 한 겹으로만 관리하면, 즉 ‘짙은 남색’이라는 색에 곧바로 의미가 묶여버리면 어떤 일이 생길까. 나중에 ‘주 색을 좀 더 밝게 바꾸자’는 결정이 내려졌을 때, ‘짙은 남색’이라는 색 자체를 바꿔야 한다. 그런데 그 ‘짙은 남색’은 주 색으로만 쓰인 게 아니라 다른 자리에도 쓰였을 수 있다. 그러면 주 색을 바꾸려다 엉뚱한 곳까지 같이 바뀌는 사고가 난다. 두 겹으로 나누면 이 문제가 사라진다. ‘주 색상’이라는 역할 이름표가 가리키는 원재료만 ‘짙은 남색’에서 ‘조금 밝은 남색’으로 갈아 끼우면 되고, 다른 역할들은 영향을 받지 않는다. 역할과 원재료를 분리해두는 건, 변경의 ‘부작용’을 막기 위한 안전장치다.

이 두 겹 구조를 ‘우체국 사서함’에 비유해도 좋다. 사람들은 ‘김아무개 씨 집’이 아니라 ‘3번 사서함’으로 편지를 보낸다. 김아무개 씨가 이사를 가도, 3번 사서함이 새 주소를 가리키게만 해두면 편지는 계속 잘 도착한다. 보내는 사람은 이사 사실을 몰라도 된다. 토큰의 역할 이름표가 바로 이 ‘사서함 번호’다. 사이트 곳곳은 ‘3번 사서함(주 색상)’으로 색을 부르고, 그 사서함이 실제로 어떤 색을 가리키는지는 한 군데에서만 관리한다. 색이 ‘이사’를 가도 사이트는 흔들리지 않는다.

■ 색을 코드로 부르면 안 되는 이유 — 흩어진 파랑의 비극

토큰이 왜 필요한지를 가장 절절하게 느끼는 순간은 ‘색을 바꿔야 할 때’다. 평소에는 토큰이 있든 없든 사이트가 잘 굴러가는 것처럼 보인다. 그런데 어느 날 “기관 상징색을 살짝 손보자”는 결정이 내려오면, 토큰의 유무가 천국과 지옥을 가른다.

토큰이 없는 사이트를 떠올려보자. 짙은 남색이 메인 배너에 쓰이고, 주 버튼에 쓰이고, 표 머리글에 쓰이고, 푸터 배경에 쓰인다. 그런데 각각이 ‘#1F4E79’라는 코드로 직접 박혀 있다. 게다가 어떤 자리는 실수로 ‘#1E4D78’처럼 한 끗 다른 값이 들어가 있다. 사람 눈에는 똑같아 보이지만 코드는 다르다. 이제 이 남색을 약간 더 밝게 바꾸려 한다. 어디부터 손대야 할까? 코드 검색으로 ‘#1F4E79’를 찾으면 그건 잡힌다. 그런데 ‘#1E4D78’은 검색에 안 걸린다. 결국 일부만 바뀌고, 미처 못 바꾼 색이 구석에 남아 또 다른 불일치를 만든다.

이게 바로 ‘흩어진 파랑의 비극’이다. 색이 코드로 흩어져 있으면, 그 색이 어디에 몇 군데 쓰였는지 아무도 정확히 모른다. 모르니까 다 못 바꾸고, 다 못 바꾸니까 사이트는 ‘조금씩 다른 파랑’들이 공존하는 누더기가 된다. 리뉴얼할 때마다 이 작업이 반복되니, 색을 바꾸는 일 자체가 두려운 ‘대공사’로 인식된다. 결국 ‘웬만하면 색은 안 건드리는’ 보수적인 운영으로 굳어진다.

토큰이 있는 사이트는 완전히 다르다. 모든 자리가 ‘#1F4E79’라는 코드가 아니라 ‘주 색상’이라는 이름을 부르고 있다. 그래서 ‘주 색상’의 실제 값을 한 군데에서 바꾸면, 그 이름을 부르던 수십, 수백 군데가 동시에 바뀐다. 메인 배너도, 주 버튼도, 표 머리글도, 푸터도 일제히 새 색으로 갈아입는다. 누락이 없다. 한 끗 다른 값이 끼어들 여지도 없다. 색 변경이 ‘대공사’에서 ‘한 줄 수정’으로 줄어드는 것이다.

이 차이를 비유로 옮기면 이렇다. 토큰이 없는 건 회사 전체 직원에게 ‘각자 알아서 출근하라’고 한 것과 같다. 누가 어디 사는지, 어떻게 오는지 본사가 모른다. 비상 상황에 전원 소집을 하려면 한 명 한 명 연락처를 뒤져야 한다. 토큰이 있는 건 ‘전사 공지 시스템’을 갖춘 것과 같다. 공지 한 번이면 전원에게 동시에 전달된다. 평소엔 둘 다 출근을 잘 하니 차이가 없어 보이지만, ‘전원에게 동시에 무언가를 전해야 할 때’ 비로소 시스템의 가치가 드러난다.

여기서 한 가지 더 짚고 싶은 게 있다. 색을 코드로 흩뿌리면 단지 ‘바꾸기 어려운’ 문제만 생기는 게 아니다. ‘처음 만들 때부터’ 색이 슬금슬금 늘어난다. 새 페이지를 만드는 외주 디자이너가 “이 자리엔 좀 더 밝은 파랑이 어울리겠는데” 하면서 새 코드를 즉석에서 정해 넣는다. 다음 페이지에선 또 다른 사람이 또 다른 파랑을 넣는다. 이렇게 ‘그때그때 정한 색’이 쌓이면, 한 사이트 안에 비슷하지만 미묘하게 다른 파랑이 수십 종 생긴다. 토큰은 이 ‘색의 무분별한 증식’을 원천적으로 막는다. ‘쓸 수 있는 색은 이 목록 안에서만’이라는 울타리를 치기 때문이다. 586개라는 숫자가 ‘넓은 자유’가 아니라 ‘명확한 울타리’라는 점이 여기서 드러난다.

■ 색은 ‘장식’이 아니라 ‘기능’이다 — 잠깐 색의 기본기

586개를 본격적으로 해부하기 전에, 한 가지 전제를 깔아두고 싶다. 우리는 보통 색을 ‘예쁘게 꾸미는 장식’으로 여긴다. 그런데 화면에서 색은 장식이기 이전에 ‘기능’을 한다. 이 전제를 받아들이고 나면, 왜 색을 그렇게 잘게 나눠 관리해야 하는지가 자연스럽게 이해된다.

색이 하는 첫 번째 기능은 ‘구분’이다. 화면에는 수많은 요소가 있다. 제목과 본문, 중요한 정보와 부차적인 정보, 누를 수 있는 것과 그냥 보는 것. 이걸 색으로 구분해주지 않으면 사용자는 화면을 ‘평평한 글자 덩어리’로 받아들인다. 진한 색은 ‘여기를 봐’라고 끌어당기고, 옅은 색은 ‘이건 배경이야’라고 물러난다. 색의 단계가 촘촘해야 이 ‘끌어당김과 물러남’을 섬세하게 조절할 수 있다.

색이 하는 두 번째 기능은 ‘의미 전달’이다. 빨강은 위험·오류, 초록은 성공·정상, 노랑·주황은 주의를 뜻한다는 게 사회적으로 학습돼 있다. 그래서 오류 메시지를 빨강으로, 성공 안내를 초록으로 보여주면, 사용자는 글을 읽기 전에 색만으로 ‘아, 뭔가 잘못됐구나’ 혹은 ‘잘 됐구나’를 직감한다. 이 의미 전달 기능을 제대로 쓰려면, ‘성공·경고·오류·정보’ 같은 상태색이 각각 정의돼 있어야 한다. 색을 ‘파랑 하나’로 단순화하면 이 기능을 통째로 잃는다.

색이 하는 세 번째 기능은 ‘가독성 보장’이다. 글자와 배경의 밝기 차이가 충분해야 글이 읽힌다. 이 차이를 ‘명도 대비’라고 부르는데, 웹 접근성 기준은 이 대비가 일정 수준 이상이어야 한다고 못 박는다. 시력이 약한 분, 색각 이상이 있는 분, 밝은 햇빛 아래에서 화면을 보는 분 모두에게 글이 읽히려면, 본문 텍스트색과 배경색의 대비가 보장돼야 한다. 색의 밝기 단계를 잘게 나눠 관리하는 건, 바로 이 ‘충분한 대비’를 항상 확보하기 위해서다.

이렇게 색의 세 가지 기능(구분·의미 전달·가독성)을 떠올리면, 색을 ‘많이, 잘게, 역할별로’ 나눠 관리해야 하는 이유가 분명해진다. 색은 취향의 문제가 아니라 사용성의 문제이고, 사용성을 빈틈없이 챙기려면 색도 빈틈없이 정리돼야 한다. 586개라는 숫자는 ‘색의 세 기능을 모든 상황에서 보장하기 위한 최소한의 빈틈없음’이라고 봐도 좋다.

■ 그래서 586개는 어떻게 나온 숫자인가

이제 본격적으로 586이라는 숫자를 해부해보자. 수백개가 넘는 색이라고 하면 막연하지만, 이걸 ‘곱셈’으로 쪼개 보면 의외로 합리적인 구조가 드러난다.

색상 토큰은 대략 세 가지 축으로 늘어난다. 첫째는 ‘색 계열’의 수다. 주 색, 보조 색, 강조 색, 중립(회색) 색, 그리고 상태를 알리는 색들(성공·경고·오류·정보). 이렇게만 따져도 색 계열이 여러 갈래로 나뉜다. 둘째는 ‘밝기 단계’다. 하나의 계열이라도 아주 옅은 톤부터 아주 진한 톤까지 여러 단계로 나뉜다. 흔히 한 계열을 10단계 안팎으로 쪼갠다. 가장 옅은 1단계는 배경에, 중간 단계는 테두리나 보조 요소에, 진한 단계는 텍스트나 강조에 쓰는 식이다. 셋째는 ‘역할(의미)’이다. 같은 진한 빨강이라도 ‘오류 텍스트색’으로 쓰일 때와 ‘오류 배경색’으로 쓰일 때, ‘오류 테두리색’으로 쓰일 때 각각 별도의 이름표가 붙는다.

이 세 축을 곱해보자. 색 계열이 여러 개, 각 계열이 밝기 10단계 안팎, 거기에 ‘텍스트·배경·테두리·아이콘’ 같은 역할별 이름표까지. 곱하다 보면 금세 수백 개가 되고, 앞서 말한 ‘원재료 층’과 ‘역할 이름표 층’ 두 겹을 합치면 천 단위가 된다. 586개는 이렇게 ‘계열 × 단계 × 역할 × 두 겹’의 곱으로 자연스럽게 도달하는 숫자다. 누군가 천 개를 채우려고 억지로 색을 만든 게 아니라, 공공 웹에서 ‘필요한 색의 자리’를 빠짐없이 채우다 보니 약 600개가 된 것이다.

밝기 단계 이야기를 조금 더 해보자. 왜 한 색을 10단계씩이나 쪼갤까? 답은 ‘대비’와 ‘위계’에 있다. 화면에서 색은 단지 예뻐 보이려고 쓰는 게 아니라, 정보의 위계를 만들고 글자를 읽히게 하는 ‘기능’을 한다. 옅은 회색은 배경으로, 중간 회색은 보조 텍스트로, 진한 회색은 본문 텍스트로 쓰인다. 만약 회색이 한 종류뿐이라면, 배경과 본문을 구분할 수 없고, 강조와 평범함을 가를 수 없다. 단계가 촘촘해야 ‘이건 중요하고 이건 덜 중요하다’를 색만으로도 표현할 수 있다. 게다가 글자와 배경의 명도 차이가 충분해야 시력이 약한 분도 글을 읽을 수 있는데, 이 ‘충분한 차이’를 보장하려면 단계가 잘게 나뉘어 있어야 한다. 접근성과 토큰의 촘촘함은 떼려야 뗄 수 없는 관계다.

역할별 이름표 이야기도 짚자. 같은 색이라도 ‘어디에 쓰이느냐’에 따라 다른 이름을 가져야 하는 이유가 있다. 예를 들어 ‘오류’를 알리는 빨강을 떠올려보자. 오류 메시지의 ‘글자색’과 그 메시지가 놓인 ‘배경색’, 그리고 입력칸을 감싸는 ‘테두리색’은 서로 달라야 한다. 글자는 진해야 읽히고, 배경은 옅어야 글자를 받쳐주고, 테두리는 중간쯤이어야 도드라진다. 만약 이걸 ‘오류는 그냥 빨강’ 하나로 뭉뚱그리면, 배경까지 새빨개져서 글자가 안 보이는 참사가 난다. 그래서 ‘오류-텍스트’ ‘오류-배경’ ‘오류-테두리’가 각각 별도의 토큰으로 존재한다. 역할을 잘게 나눈 덕에, 디자이너는 “오류 관련 색 세트를 쓰면 알아서 글자가 읽히게 조합된다”는 안전장치를 얻는다. 천 개의 토큰은 이런 ‘안전한 조합’을 미리 짜둔 결과물이다.

여기서 오해 하나를 풀고 가자. ‘586개 토큰이 있다’는 말은 ‘한 페이지에서 천 개의 색을 쓴다’는 뜻이 절대 아니다. 실제 한 화면에서 눈에 보이는 색은 손에 꼽는다. 주 색 한둘, 회색 몇 단계, 상태색 한둘이면 대부분의 화면이 완성된다. 천 개는 ‘쓸 수 있는 색의 전체 사전’이고, 실제로 펼쳐 쓰는 건 그중 극히 일부다. 국어사전에 수십만 단어가 실려 있다고 해서 우리가 한 문장에 수십만 단어를 쓰는 게 아닌 것과 같다. 사전이 두껍다는 건 ‘필요할 때 찾아 쓸 단어가 빠짐없이 있다’는 뜻이지, ‘다 외우고 다 쓰라’는 뜻이 아니다.

■ 토큰이 없을 때 벌어지는 일 — 익명 사례 몇 가지

개념만 들으면 ‘그래서 실제로 뭐가 문제인데?’ 싶을 수 있다. 그래서 공공 사이트를 점검하다 보면 패턴처럼 반복되는 전형적인 문제들을 익명으로 풀어보겠다. 미리 양해를 구하자면, 아래 사례에는 어떤 실제 기관명도, 도메인도, 식별 가능한 정보도 들어 있지 않다. 모두 여러 사이트에서 공통으로 관찰되는 ‘유형’을 익명으로 재구성한 것이다. 읽다가 ‘어, 우리 사이트 얘긴가?’ 싶은 대목이 있다면, 그건 그만큼 흔한 문제라는 뜻이지 특정 기관만의 문제가 아니다.

첫 번째 사례. A광역지자체의 사이트를 살펴봤다고 치자. 메인 페이지의 파랑은 차분하고 깊은 남색 계열이었다. 그런데 민원 신청 페이지로 들어가니 파랑이 살짝 밝아져 있었다. 다시 공지사항 목록으로 가니 또 다른 파랑이었다. 사람 눈에 ‘완전히 다른 색’으로 느껴질 정도는 아니지만, 페이지를 옮길 때마다 미묘하게 ‘분위기가 흔들리는’ 느낌이 들었다. 색을 하나하나 찍어 코드를 확인해보니, 비슷하지만 미묘하게 다른 파랑이 무려 여남은 종류가 나왔다. 부서별로, 사업별로, 시기별로 따로 발주해서 만들다 보니, 각자 ‘대충 맞춘 파랑’을 넣은 결과였다. 토큰이라는 공통 사전이 없으니, 모두가 ‘비슷한 파랑’을 의도했지만 결과는 ‘제각각인 파랑’이 된 것이다.

이게 바로 DS(디자인 기반 요소) 차원의 문제다. 색이 토큰으로 묶여 있지 않으면, 페이지가 늘어날수록 색은 슬금슬금 분화한다. 그리고 이 분화는 ‘신뢰의 흔들림’으로 이어진다. 공공 사이트는 국민에게 ‘공식 창구’라는 신뢰를 줘야 하는데, 페이지마다 색이 미묘하게 다르면 ‘여기가 같은 기관 사이트가 맞나’ 하는 막연한 불안이 생긴다. 특히 개인정보를 입력하거나 신청을 진행하는 화면에서 이런 불안은 치명적이다. 일관된 색은 단순히 ‘예뻐 보이기 위함’이 아니라 ‘이곳은 믿을 수 있는 공식 창구다’라는 시각적 증거다.

두 번째 사례. B공공기관의 신청 폼을 점검했다. 입력칸에 잘못된 값을 넣었더니 오류 안내가 떴는데, 그 오류 글자색이 너무 옅어서 거의 읽히지 않았다. 디자이너가 ‘오류는 빨강’이라는 막연한 기준만 가지고, 글자색까지 너무 밝은 빨강을 넣은 탓이었다. 게다가 오류가 난 입력칸의 테두리는 색이 전혀 바뀌지 않아서, 어느 칸에서 오류가 났는지조차 알기 어려웠다. ‘오류-텍스트’ ‘오류-배경’ ‘오류-테두리’ 토큰이 역할별로 정리돼 있었다면 자동으로 피했을 문제다. 색을 ‘역할’이 아니라 ‘감’으로 넣었기 때문에 생긴 전형적인 사고다. 이건 단순한 미관 문제가 아니라, 사용자가 신청을 끝까지 못 마치게 만드는 ‘기능 장애’에 가깝다.

세 번째 사례. C기관 사이트는 본문 텍스트가 유난히 읽기 힘들었다. 흰 바탕에 옅은 회색 글씨를 썼는데, 그 회색이 너무 밝아서 글자가 배경에 묻혔다. 보기엔 ‘세련돼’ 보였을지 모르지만, 시력이 약한 분이나 밝은 야외에서 화면을 보는 분에게는 사실상 안 보이는 글씨였다. 회색을 ‘한 종류’로 두루뭉술하게 쓰다 보니, 본문에 써야 할 진한 회색과 보조 정보에 써야 할 옅은 회색이 뒤섞인 것이다. 밝기 단계가 토큰으로 잘 나뉘어 있고 ‘본문 텍스트는 이 단계 이상’이라는 규칙이 지켜졌다면 일어나지 않았을 일이다. 색의 촘촘한 단계가 왜 접근성과 직결되는지 보여주는 사례다.

이 세 사례의 공통점은 분명하다. 담당자나 디자이너가 일을 ‘대충’ 한 게 아니라는 것이다. 다들 자기 나름대로 정성껏 만들었다. 문제는 ‘공통의 색 사전 없이 각자 만들었다’는 사실 자체에 있었다. 합의된 토큰 없이 각자의 최선을 모으면, 그 합은 최선이 되지 않는다. 오히려 따로 노는 색 조각들의 모음이 된다. 이건 개인의 역량 문제가 아니라 시스템의 부재 문제다. 그래서 해법도 ‘담당자를 다그치는 것’이 아니라 ‘공통 토큰을 세우는 것’이어야 한다. 586개의 토큰은 바로 그 ‘공통 사전’의 역할을 한다.

네 번째 사례도 덧붙여 보자. 한 중앙부처 산하의 어느 안내 사이트는, 시기별로 진행된 캠페인 페이지들이 한곳에 모여 있었다. 봄 캠페인 페이지는 따뜻한 주황 계열, 여름 캠페인은 청량한 하늘색, 가을은 또 다른 색조였다. 캠페인 하나하나만 보면 그 시즌 분위기에 잘 맞춰진 디자인이었다. 그런데 사용자가 ‘지난 캠페인 모아보기’ 같은 목록을 통해 이 페이지들을 연달아 넘겨보면, 같은 부처의 사이트라는 느낌이 전혀 들지 않았다. 캠페인마다 ‘브랜드가 통째로 바뀐’ 듯한 인상이었다. 여기서 문제의 본질은 ‘캠페인마다 다른 색을 쓴 것’ 자체가 아니다. ‘기관 공통의 뼈대 색’과 ‘캠페인별 강조 색’을 구분하는 토큰 체계가 없었던 게 진짜 원인이다. 잘 설계된 토큰 체계라면, 헤더·푸터·내비게이션 같은 공통 골격은 기관 주 색 토큰으로 고정하고, 캠페인 색은 ‘강조 토큰’이라는 한정된 자리에서만 갈아 끼우게 한다. 그러면 시즌마다 색을 바꿔도 ‘같은 집에 벽지만 바꾼’ 느낌이 들지, ‘집 자체가 바뀐’ 느낌은 들지 않는다. 토큰은 이렇게 ‘변해도 되는 부분’과 ‘변하면 안 되는 부분’의 경계를 명확히 그어주는 역할도 한다.

다섯 번째 사례는 ‘색이 너무 많아서’가 아니라 ‘색이 너무 적어서’ 생긴 문제다. 어느 작은 기관 사이트는 색을 거의 쓰지 않았다. 검정과 흰색, 그리고 파랑 하나가 전부였다. 깔끔하긴 했지만, 문제는 ‘상태를 색으로 구분할 수단’이 없었다는 점이다. 성공 안내도 파랑, 경고도 파랑, 오류도 파랑이었다. 사용자는 메시지의 ‘색’만으로는 그게 좋은 소식인지 나쁜 소식인지 구분할 수 없었고, 매번 글자를 끝까지 읽어야 상황을 파악할 수 있었다. 이건 토큰 체계가 ‘상태색’이라는 역할군을 갖춰야 하는 이유를 거꾸로 보여준다. 색이 적은 게 무조건 좋은 게 아니다. ‘필요한 역할에 필요한 색’이 빠짐없이 있어야 한다. 586개의 토큰이 ‘성공·경고·오류·정보’ 같은 상태색을 각각 단계별로 갖춰둔 건, 바로 이런 ‘색으로 상황을 전달하는 기능’을 보장하기 위해서다. 토큰의 촘촘함은 ‘과잉’이 아니라 ‘빠짐없음’을 향한 설계다.

이 사례들을 관통하는 교훈을 한 번 더 정리하면 이렇다. 색의 문제는 거의 항상 ‘너무 많거나’ ‘너무 적거나’ ‘역할이 뒤섞이거나’ 셋 중 하나다. 그리고 이 셋을 동시에 다스리는 유일한 방법이 토큰이다. 토큰은 ‘쓸 수 있는 색의 목록’을 정해 너무 많아지는 걸 막고, ‘역할별로 빠짐없이’ 갖춰 너무 적어지는 걸 막으며, ‘역할 이름표’로 색의 쓰임을 못 박아 뒤섞이는 걸 막는다. 천 개라는 숫자는 이 세 가지를 동시에 만족시키려다 보니 도달한 균형점이다.

■ 토큰은 색에서 끝나지 않는다 — 586은 시작점

지금까지 색상 토큰만 이야기했지만, 토큰이라는 개념은 색에만 머무르지 않는다. 사실 KRDS가 토큰으로 관리하는 건 색뿐 아니라 글꼴 크기, 줄 간격, 여백, 모서리 둥글기, 그림자 같은 ‘시각의 기본 단위’ 전반이다. 색이 586개라면, 다른 종류의 토큰까지 합치면 전체 토큰의 규모는 더 커진다. 그래서 색상 토큰 586개는 ‘토큰 세계의 전부’가 아니라 ‘가장 눈에 띄고 가장 많이 분화하는 한 갈래’라고 이해하는 게 정확하다.

여백을 예로 들어보자. 화면에서 요소와 요소 사이의 간격은 아무렇게나 정하는 게 아니다. 잘 만든 디자인 시스템은 간격을 8을 기준으로 한 배수(8, 16, 24, 32…)로 정돈한다. 이렇게 하면 화면 전체에 보이지 않는 격자가 깔리고, 요소들이 그 격자에 정렬돼 ‘이유 있는 질서’가 생긴다. 이 간격 값들도 각각 토큰으로 관리된다. ‘간격-작게’ ‘간격-보통’ ‘간격-크게’처럼 역할로 부르는 것이다. 색과 똑같은 원리다. 코드(픽셀 값)를 직접 박지 않고 이름으로 부르면, 나중에 전체 여백을 한 단계 늘리고 싶을 때 토큰만 손보면 된다.

글꼴 크기도 마찬가지다. 제목용, 부제목용, 본문용, 캡션용 크기가 위계를 이루고, 각각이 토큰으로 정의된다. 모서리 둥글기도 ‘각지게’ ‘살짝 둥글게’ ‘많이 둥글게’가 토큰으로 나뉜다. 이 모든 게 ‘이름으로 부르는 디자인 단위’라는 점에서 색상 토큰과 한 가족이다. 색상 토큰의 원리를 이해하면, 나머지 토큰들도 같은 방식으로 작동한다는 걸 자연스럽게 받아들이게 된다.

그래서 색상 토큰을 제대로 이해하는 건 단지 ‘색 문제 하나를 푸는 것’이 아니다. 디자인 시스템 전체가 어떻게 ‘이름으로 관리되는가’를 이해하는 출발점이다. 색이라는, 가장 직관적이고 눈에 잘 띄는 영역에서 토큰의 작동 원리를 체득하면, 그 감각이 여백·글꼴·둥글기로 자연스럽게 확장된다. 이번 글에서 색상 토큰부터 다루는 이유가 여기에 있다. 가장 만만하고 가장 가시적인 입구이기 때문이다.

한 가지 더. 토큰이 잘 정리돼 있으면 ‘다크 모드’ 같은 변형도 훨씬 수월해진다. 밝은 배경용 색 세트와 어두운 배경용 색 세트를 ‘역할은 그대로 두고 원재료만 바꾸는’ 방식으로 전환할 수 있기 때문이다. ‘주 텍스트색’이라는 역할은 그대로인데, 밝은 모드에선 진한 회색을, 어두운 모드에선 밝은 회색을 가리키게 하면 된다. 토큰이라는 두 겹 구조가 있기에 가능한 일이다. 색을 코드로 흩뿌려놨다면 다크 모드 대응은 또 한 번의 대공사가 됐을 것이다. 토큰은 이렇게 ‘미래의 변화’까지 미리 대비해두는 투자다.

■ 토큰에 ‘이름을 잘 붙이는 일’이 왜 그렇게 중요한가

여기서 잠깐 토큰의 ‘이름’ 자체에 대해 이야기하고 싶다. 의외로 많은 사람이 놓치는 부분인데, 토큰 체계의 성패는 ‘이름을 얼마나 잘 짓느냐’에 크게 달려 있다.

앞에서 토큰은 ‘색에 이름표를 붙이는 일’이라고 했다. 그런데 그 이름표를 어떻게 짓느냐에 따라, 같은 토큰이라도 쓰기 쉬운 토큰이 되기도 하고 아무도 안 쓰는 토큰이 되기도 한다. 예를 들어 ‘파랑-3’ ‘회색-7’처럼 색과 번호로만 이름을 지으면, 그건 사실상 코드와 다를 바 없다. ‘파랑-3’이 무슨 역할을 하는지는 이름만 봐선 알 수 없으니, 결국 디자이너가 ‘이 자리엔 파랑-3쯤이 어울리겠지’ 하고 감으로 고르게 된다. 반대로 ‘주-버튼-배경’ ‘오류-텍스트’ ‘비활성-테두리’처럼 역할로 이름을 지으면, 디자이너는 ‘아, 이 자리는 오류 안내니까 오류-텍스트 토큰’ 하고 의미를 따라 고른다. 후자가 훨씬 실수가 적고, 검수도 쉽다.

그래서 잘 설계된 토큰 체계는 보통 ‘이름의 문법’을 갖는다. ‘무엇의(역할) + 어떤 상태에서(상태) + 어디에 쓰이는(속성)’ 같은 구조로 이름을 조립하는 것이다. 이런 문법이 있으면, 새로운 토큰이 필요할 때도 ‘이 자리는 무슨 역할이지’를 먼저 정하고 그에 맞는 이름을 붙이면 되니, 토큰이 무질서하게 늘어나지 않는다. 586개라는 큰 숫자가 ‘혼돈’이 아니라 ‘체계’로 느껴지는 건, 이 이름의 문법 덕분이다. 천 개를 무작정 나열한 게 아니라, 일정한 규칙으로 분류해 쌓았기 때문에 필요한 토큰을 ‘찾을’ 수 있는 것이다. 두꺼운 사전이 가나다순으로 정렬돼 있어야 쓸모 있듯, 천 개의 토큰도 이름의 문법으로 정렬돼 있어야 비로소 쓸모를 갖는다.

이 ‘이름의 문법’은 담당자에게도 큰 무기가 된다. 외주 산출물을 받았을 때, 토큰 이름만 훑어봐도 ‘이 사이트가 KRDS 토큰 체계를 제대로 따랐는지’ 대강 가늠할 수 있기 때문이다. 만약 토큰 이름이 죄다 ‘색1’ ‘색2’ 식이라면, 그건 토큰의 형식만 빌렸을 뿐 역할 기반 체계는 안 따랐다는 신호다. 반대로 역할이 분명한 이름들이 보이면, 적어도 ‘제대로 만들려고 했다’는 증거다. 이름을 읽는 것만으로도 1차 검수가 되는 셈이다.

■ 토큰과 ‘유지보수 비용’ — 안 보이는 곳에서 새는 돈

색상 토큰 이야기를 ‘디자인’의 영역으로만 보면 절반만 본 것이다. 토큰은 사실 ‘돈’의 문제이기도 하다. 정확히는 ‘유지보수 비용’의 문제다.

공공 사이트는 한 번 만들고 끝나는 게 아니다. 몇 년 주기로 개편하고, 그 사이에도 수시로 페이지를 추가하고 수정한다. 이 ‘운영의 긴 꼬리’에서 비용이 줄줄 샌다. 토큰이 없는 사이트를 떠올려보자. 새 페이지를 만들 때마다 디자이너는 ‘이 자리에 무슨 색을 쓸지’를 처음부터 다시 정한다. 기존 페이지들과 색을 맞추려면, 일일이 다른 페이지를 열어 색을 찍어보고 따라 써야 한다. 이 과정에서 한 끗 다른 색이 끼어들고, 시간도 든다. 작은 결정 하나하나는 사소해 보이지만, 페이지가 수백 개로 쌓이고 운영 기간이 몇 년으로 길어지면, 이 ‘반복되는 작은 결정과 작은 오차’가 상당한 비용으로 누적된다.

토큰이 있으면 이 비용이 극적으로 줄어든다. 새 페이지를 만드는 사람은 ‘무슨 색을 쓸지’ 고민하지 않는다. ‘이 자리는 주 버튼이니까 주-버튼-배경 토큰’ 하고 정해진 걸 가져다 쓰면 끝이다. 색을 새로 정하는 결정 자체가 사라지니, 작업이 빨라지고 오차도 없다. 게다가 앞서 말했듯 색을 한꺼번에 바꿀 수 있으니, 리뉴얼 비용도 줄어든다. 토큰은 ‘처음 만들 때의 비용’보다 ‘오래 운영할 때의 비용’에서 진짜 위력을 발휘한다. 그래서 토큰 도입을 ‘디자인 투자’가 아니라 ‘운영비 절감 투자’로 설명하면, 예산을 쥔 윗선을 설득하기가 훨씬 쉬워진다.

여기에 ‘담당자 교체’라는 공공기관 특유의 변수까지 더해보자. 공공기관은 담당자가 자주 바뀐다. 토큰이 없는 사이트는 ‘이 색이 어디에 왜 쓰였는지’를 아는 사람이 떠나면, 그 지식도 함께 사라진다. 새 담당자는 맨땅에서 다시 파악해야 한다. 토큰이 있으면 그 지식이 ‘역할 이름표’ 형태로 사이트에 박제돼 있다. 새 담당자가 와도 ‘아, 이 색은 오류 안내용이구나’를 이름만 보고 안다. 토큰은 사람에게 의존하던 지식을 시스템에 옮겨 담아, 담당자 교체의 충격을 흡수한다. 인력 변동이 잦은 조직일수록 토큰의 가치가 더 크다.

■ 자주 나오는 질문들 — 천 개의 색을 둘러싼 오해 풀기

KRDS 색상 토큰을 처음 접하는 분들이 자주 던지는 질문 몇 개를 모아 풀어보자. 대부분 ‘천 개’라는 숫자에서 비롯된 오해들이다.

“우리 디자이너가 천 개를 다 알아야 하나요?”라는 질문이 가장 많다. 답은 ‘아니다’이다. 디자이너가 실제로 쓰는 토큰은 한 화면당 손에 꼽고, 자주 쓰는 핵심 토큰은 수십 개 안팎이다. 천 개는 ‘찾아 쓸 수 있는 전체 목록’이지 ‘외워야 할 목록’이 아니다. 좋은 디자인 도구는 토큰을 역할별로 분류해 보여주기 때문에, ‘오류 관련 색이 필요하다’ 하면 그 묶음만 펼쳐 고르면 된다. 천 개를 머리에 넣을 필요가 전혀 없다.

“기존 사이트도 천 개 토큰을 다 적용해야 하나요?”라는 질문에는 ‘그럴 필요 없다’가 답이다. 토큰은 ‘쓸 수 있는 사전’이고, 우리 사이트는 그중 필요한 것만 가져다 쓰면 된다. 게다가 기존 사이트를 한 번에 다 바꿀 필요도 없다. 새로 손대는 부분부터 점진적으로 적용하는 게 정석이다. ‘천 개를 다 적용’하는 게 목표가 아니라, ‘우리가 쓰는 색이 표준 토큰 안에 들어오게’ 하는 게 목표다.

“색이 수백개나 있으면 오히려 더 헷갈리지 않나요?”라는 걱정도 있다. 직관적으로는 그럴 것 같지만, 실제로는 반대다. 토큰이 없으면 ‘쓸 수 있는 색이 무한대’라서 매번 새로 정해야 하므로 더 헷갈린다. 토큰이 있으면 ‘쓸 수 있는 색이 이 목록 안’으로 제한되고, 게다가 역할별로 정리돼 있어서 ‘이 자리엔 이 토큰’이 거의 정해진다. 선택지가 ‘무한대’에서 ‘정해진 목록’으로 좁혀지는 것이니, 오히려 결정이 쉬워진다. 식당 메뉴가 ‘아무거나 만들어 드립니다’보다 ‘이 중에서 고르세요’가 주문하기 편한 것과 같다.

“토큰을 지키면 우리 기관만의 색을 못 쓰는 거 아닌가요?”라는 질문도 자주 나온다. 그렇지 않다. 토큰 체계는 ‘색을 역할로 관리하는 방식’이지, ‘특정 색을 강요하는 것’이 아니다. 기관의 상징색을 ‘주 색상 토큰’의 원재료로 지정하면, 그 기관만의 색이 토큰 체계 안에서 그대로 살아난다. 통일하는 건 ‘색을 관리하는 방식’이지 ‘색의 정체성’이 아니다. 표준어 문법을 따른다고 모든 사람의 어휘가 똑같아지지 않는 것과 같다. 공통의 관리 방식 위에서 각 기관의 색 개성은 충분히 표현된다.

“진단 도구가 우리 사이트 색을 멋대로 평가하는 거 아닌가요?”라는 의구심도 있다. 진단은 ‘이 색이 예쁜지’를 평가하는 게 아니다. ‘이 사이트가 쓰는 색이 표준 토큰에 얼마나 들어맞는지’ ‘본문의 명도 대비가 접근성 기준을 충족하는지’ 같은, 객관적으로 측정 가능한 사실을 숫자로 보여줄 뿐이다. 미적 취향에 대한 판단이 아니라, 일관성과 접근성이라는 ‘기능’에 대한 측정이다. 그래서 진단 결과는 ‘맞다/틀리다’의 시비가 아니라 ‘얼마나 따르고 있다’의 현황 보고에 가깝다.

■ 행정안전부 7대 영역과 KRDS, 그리고 토큰의 자리

여기서 잠깐 큰 그림을 짚고 가자. KRDS 색상 토큰이 ‘예쁜 사이트를 만들기 위한 디자이너의 취향’ 정도로 오해되기 쉬운데, 실제로는 공공 웹 품질 체계의 한 축에 단단히 연결돼 있다.

행정안전부의 「전자정부 웹사이트 품질관리 지침」은 공공 웹이 갖춰야 할 품질을 일곱 가지 영역으로 정리한다. 호환성, 접근성, 개방성, 접속성, 편의성, 효율성, 신뢰성이다. 이 일곱 영역은 ‘브라우저마다 잘 보이는가’ ‘장애가 있어도 쓸 수 있는가’ ‘정보가 잘 열려 있는가’ ‘잘 접속되는가’ ‘쓰기 편한가’ ‘빠른가’ ‘믿을 수 있는가’를 두루 살핀다. 색상 토큰은 이 중 특히 ‘접근성’ ‘편의성’ ‘신뢰성’과 맞닿아 있다.

앞서 본문 텍스트가 안 읽히던 C기관 사례를 떠올려보자. 그건 회색 토큰의 밝기 단계가 흐트러진 디자인 문제이면서, 동시에 ‘명도 대비가 충분한가’라는 접근성 문제이기도 하다. 웹 접근성 지침인 KWCAG의 33개 항목 중에도 ‘콘텐츠와 배경의 명도 대비’를 따지는 항목이 있다. 색상 토큰이 단계별로 잘 정의되고 ‘본문은 이 단계 이상’이라는 규칙이 지켜지면, 이 접근성 항목은 자연스럽게 충족된다. 즉 색상 토큰을 제대로 관리하는 일은 ‘예쁘게 만드는 일’을 넘어 ‘법적으로 요구되는 접근성을 지키는 일’과 한 몸으로 움직인다.

신뢰성도 마찬가지다. 페이지마다 색이 흔들리지 않고 일관되면, 사용자는 ‘이곳이 같은 기관의 공식 창구’라는 확신을 시각적으로 얻는다. 일관된 색은 곧 ‘이 사이트는 관리되고 있다’는 신호다. 편의성 역시 색의 역할이 분명할 때 높아진다. ‘이 색이면 누를 수 있는 버튼’ ‘이 색이면 경고’라는 약속이 사이트 전체에서 지켜지면, 사용자는 매번 추측하지 않고 직관적으로 화면을 읽는다. 결국 색상 토큰은 디자인의 문제인 동시에 품질·접근성·신뢰의 문제다. 586개라는 숫자가 가벼워 보이지 않는 이유가 여기에 있다.

■ 그래서 담당자는 무엇부터 하면 되나 — 현실적인 첫걸음

여기까지 읽고 ‘좋은 건 알겠는데, 우리 같은 작은 조직이 천 개의 토큰을 어떻게 관리하느냐’는 막막함이 들 수 있다. 다시 한번 강조하면, 담당자가 천 개를 외우거나 직접 관리하는 게 아니다. 담당자의 역할은 ‘방향을 잡고, 제대로 적용됐는지 확인하는 것’이다. 세부 디테일은 도구와 표준이 챙겨준다. 그 전제 위에서, 현실적인 첫걸음을 정리해보자.

첫째, ‘우리 사이트에 색이 몇 종이나 쓰이고 있는지’부터 파악하는 것이다. 의외로 이걸 아는 담당자가 드물다. 새 토큰을 도입하기 전에, 지금 사이트가 얼마나 ‘색이 흩어진 상태’인지를 먼저 알아야 한다. 비슷한 파랑이 열 종 넘게 쓰이고 있다면, 그것 자체가 토큰 도입의 가장 강력한 근거가 된다. 현황을 숫자로 보면 윗선을 설득하기도 쉬워진다.

둘째, 새로 만드는 페이지나 개편하는 부분부터 토큰을 적용하는 것이다. 기존 사이트 전체를 한 번에 토큰화하려고 들면 엄두가 안 나고, 그러다 아예 시작을 못 한다. 정석은 ‘새로 손대는 곳부터’다. 개편 사업이 잡히면 그때 KRDS 색상 토큰을 적용 기준으로 명시하고, 외주 계약서에 ‘KRDS 토큰 준수’를 넣는 것이다. 이렇게 새 영역부터 토큰을 쌓아가면, 시간이 지나며 자연스럽게 사이트 전체가 정돈된다. 점진적 적용이 핵심이다.

셋째, ‘적용했다’와 ‘제대로 적용됐다’를 구분하는 것이다. 외주 업체가 “KRDS 토큰 다 적용했습니다”라고 말해도, 그 말을 검증할 방법이 없으면 끌려다니게 된다. 실제로 토큰이 빠짐없이 쓰였는지, 비표준 색이 슬쩍 끼어들지 않았는지, 본문 텍스트의 명도 대비는 충분한지 — 이걸 사람이 수백 페이지에서 일일이 확인하는 건 불가능에 가깝다. 그래서 ‘토큰 채택률’ 같은 지표를 자동으로 측정해주는 진단이 필요하다. 사이트가 쓰는 색 중 표준 토큰에 해당하는 비율이 얼마인지를 숫자로 보여주면, “잘 적용했다”는 말이 “채택률 몇 퍼센트”라는 검증 가능한 사실로 바뀐다.

넷째, 한 번 측정으로 끝내지 말고 ‘추세’로 관리하는 것이다. 토큰 채택률은 개편 직후 높았다가, 시간이 지나며 부서별 추가 페이지가 쌓이면서 슬금슬금 떨어지기 쉽다. 그래서 정기적으로 채택률을 점검해, 떨어지는 신호가 보이면 일찍 잡는 게 좋다. 색의 난립은 한 번 손쓰지 않고 방치하면 기하급수로 늘어난다. 정기 진단은 그 증식을 초기에 차단하는 예방주사 같은 것이다.

■ ‘토큰 채택률’이라는 숫자를 어떻게 읽을까

앞에서 ‘토큰 채택률’이라는 표현을 여러 번 썼는데, 이게 정확히 무엇이고 어떻게 읽어야 하는지 조금 더 풀어보자. 이 숫자 하나가 오늘 글의 추상적인 이야기를 ‘우리 사이트의 현실’로 끌어내리는 다리이기 때문이다.

토큰 채택률은 쉽게 말해 ‘우리 사이트가 쓰는 색 중에서, 표준 토큰에 해당하는 색의 비율’이다. 예를 들어 우리 사이트가 실제로 50종의 색을 쓰고 있는데 그중 40종이 표준 토큰과 일치하면, 채택률은 80퍼센트인 셈이다. 나머지 20퍼센트, 즉 표준 토큰을 벗어난 색들이 바로 ‘관리되지 않는 색’ ‘슬쩍 끼어든 비표준 색’이다. 이 비율을 숫자로 보면, ‘우리 사이트가 색의 질서를 얼마나 지키고 있는지’가 한눈에 드러난다.

이 숫자가 강력한 이유는, 그동안 ‘느낌’으로만 이야기하던 색의 일관성을 ‘측정 가능한 사실’로 바꿔주기 때문이다. “우리 사이트 색이 좀 들쭉날쭉한 것 같아”라는 막연한 인상이, “토큰 채택률이 60퍼센트입니다, 즉 우리가 쓰는 색의 40퍼센트가 표준을 벗어났습니다”라는 명확한 진단이 된다. 윗선에 보고할 때도, 외주 업체와 협의할 때도, 이 숫자만큼 설득력 있는 근거가 없다. 숫자는 시비를 잠재우고 대화를 ‘다음 단계’로 끌고 간다.

채택률을 읽을 때 한 가지 주의할 점은, ‘100퍼센트가 절대 목표’는 아니라는 것이다. 사이트에는 사진이나 이미지처럼 토큰으로 관리하기 어려운 색도 있고, 외부에서 가져온 콘텐츠가 섞일 수도 있다. 그러니 ‘무조건 100’을 향해 달리기보다, ‘핵심 UI 요소에서 표준 토큰이 잘 지켜지는지’ ‘비표준 색이 줄어드는 추세인지’를 보는 게 더 현실적이다. 채택률은 ‘점수 경쟁’이 아니라 ‘건강 검진’에 가깝다. 작년보다 좋아졌는지, 어느 부위에 문제가 쌓이는지를 보는 지표다.

그리고 이 채택률은 다중 페이지로 봐야 의미가 있다. 메인 페이지 하나만 잘 만들어두고 ‘우리 사이트는 토큰 잘 지킨다’고 말하는 건 착각이다. 앞서 본 사례들처럼, 문제는 거의 항상 ‘메인 말고 안쪽 페이지들’에서 터진다. 그래서 사이트의 여러 페이지를 두루 진단해 채택률을 집계해야, 진짜 현황이 보인다. 메인은 90퍼센트인데 안쪽 신청 페이지들은 50퍼센트라면, 그 격차 자체가 ‘여기를 손봐야 한다’는 신호다. 한 페이지의 점수가 아니라 사이트 전체의 분포를 봐야 하는 이유다.

■ 공공 영역이 ‘지금’ 색 토큰에 진심인 이유

색상 토큰이 새로운 개념은 아니다. 민간 IT 기업들은 이미 오래전부터 자체 디자인 시스템 안에서 색을 토큰으로 관리해왔다. 수백 명의 디자이너·개발자가 동시에 한 제품을 만드는 회사에서, 색을 토큰으로 묶지 않으면 제품이 금세 누더기가 되기 때문이다. 그런데 공공 영역에서 ‘색 토큰’이 본격적으로 화두가 된 건 비교적 최근의 일이다. 왜 하필 지금일까.

이유는 공공 웹의 ‘규모’와 ‘난립의 누적’에 있다. 대한민국에는 중앙부처, 광역·기초 지자체, 공공기관, 산하기관까지 수천 개의 공공 웹사이트가 있다. 이들이 각자 다른 외주 업체에, 다른 시기에, 다른 기준으로 만들어졌다. 한 기관 안에서도 부서별·사업별로 따로 만든 페이지들이 쌓였다. 이 ‘각자 만들기’가 십수 년 누적된 결과, 공공 웹 전체가 색의 난립으로 몸살을 앓게 됐다. 같은 기관 안에서도 파랑이 제각각이고, 기관과 기관 사이로 넘어가면 사용자가 매번 새 사이트의 ‘색 문법’을 다시 익혀야 하는 지경에 이르렀다.

이 난립을 더는 방치할 수 없다는 인식이 모이면서, 정부 차원의 공통 디자인 기준이 정리됐다. 색을 포함한 시각 요소를 토큰으로 묶어 ‘국가가 한 번 잘 정리해 공유하는’ 방식이다. 각 기관이 따로 고민하지 않아도, 잘 만들어둔 공통 토큰을 가져다 쓰면 되도록 한 것이다. 기관 입장에서는 ‘남이 잘 만들어둔 사전을 가져다 쓰는’ 셈이라 오히려 부담이 준다. 586개의 색상 토큰은 이 ‘공공재로서의 색 사전’이다.

여기에 ‘디지털 정부’ 흐름이 박차를 더했다. 점점 더 많은 행정 서비스가 온라인으로 옮겨가면서, 공공 웹은 ‘있으면 좋은 부가 채널’이 아니라 ‘없으면 행정이 멈추는 핵심 창구’가 됐다. 세금을 내고, 증명서를 떼고, 복지를 신청하는 일이 사이트에서 이뤄진다. 이 핵심 창구의 품질이 들쭉날쭉하면 그 피해는 고스란히 국민에게 간다. 그래서 ‘색의 일관성’ 같은, 예전엔 사소해 보이던 문제가 이제는 ‘서비스 품질’과 ‘국민 신뢰’의 문제로 격상됐다. 공공 영역이 지금 색 토큰에 진심인 건, 색이 더 이상 미관의 문제가 아니라 행정 서비스 품질의 문제가 됐기 때문이다.

그리고 여기서 ‘측정’의 필요성이 따라온다. 아무리 좋은 토큰 체계가 마련돼도, 그것이 실제 사이트에 적용됐는지 확인하지 않으면 기준은 문서로만 남는다. 표준을 만드는 일과 표준이 지켜지는지 확인하는 일은 한 쌍으로 굴러가야 한다. 수천 개 사이트, 수십만 페이지에서 색의 토큰 준수 여부를 사람이 일일이 확인하는 건 불가능에 가깝다. 그래서 ‘색이 표준 토큰을 얼마나 따르는지’를 자동으로 측정하는 진단이, 표준의 실효성을 떠받치는 또 하나의 축이 된다. 토큰을 ‘만드는’ 단계에서 토큰을 ‘지키는지 확인하는’ 단계로, 공공 웹의 관심이 옮겨가는 중이다.

■ 토큰을 이해하면 일이 줄어든다 — 관점의 전환

이쯤에서 글 초반의 약속을 다시 꺼내고 싶다. 이 글은 색상 토큰을 ‘공부해야 할 또 하나의 숙제’로 만들려는 글이 아니다. 오히려 그 반대다. 토큰을 이해하면 일이 줄어든다는 걸 보여주려는 글이다.

토큰이 없을 때 담당자가 쓰는 시간을 떠올려보자. 시안을 받을 때마다 ‘이 색이 맞나’ 감으로 검수하느라 쓰는 시간, 색이 미묘하게 다르다는 민원이나 지적에 대응하느라 쓰는 시간, 리뉴얼할 때 흩어진 색을 일일이 찾아 바꾸느라 쓰는 시간, 외주 업체의 “다 했습니다”를 검증할 방법이 없어 답답해하며 쓰는 시간. 이 모든 시간이 ‘공통 토큰’과 ‘자동 진단’이 있으면 확 줄어든다. 색은 정해진 사전 안에서만 쓰이고, 변경은 한 줄로 끝나고, 적용 여부는 숫자로 확인된다.

한 가지 비유를 더 보태자. 잘 정리된 큰 마트를 떠올려보자. ‘유제품 코너’ ‘냉동 코너’ ‘생필품 코너’처럼 구역이 나뉘어 있고, 각 구역 안에서도 종류별로 가지런히 진열돼 있다. 손님은 우유가 필요하면 유제품 코너로 곧장 간다. 마트에 수만 가지 물건이 있어도 손님이 헤매지 않는 건, 그 수만 가지가 ‘분류 체계’ 위에 얹혀 있기 때문이다. 586개의 색상 토큰도 마찬가지다. 천 개가 ‘색 계열 → 밝기 단계 → 역할’이라는 진열 체계 위에 얹혀 있으니, 필요한 색을 ‘찾아’ 쓸 수 있다. 수가 많다는 것과 헷갈린다는 것은 별개의 문제다. 분류만 잘돼 있으면, 많다는 건 오히려 ‘빠짐없이 갖춰져 있다’는 안심이 된다. 텅 빈 구멍가게보다 잘 정리된 큰 마트가 장 보기 편한 것과 같은 이치다.

관점을 한 번만 뒤집으면 된다. 586개를 ‘외워야 할 천 개의 색’으로 보면 부담이지만, ‘색이 제멋대로 늘어나지 못하게 막아주는 울타리’로 보면 안도다. 천 개의 토큰은 담당자에게 던져진 숙제가 아니라, 담당자 대신 색의 질서를 지켜주는 든든한 장치다. 운전자가 도로교통법 조항을 다 외우지 않아도 신호등과 표지판 덕에 안전하게 운전하듯, 담당자도 천 개의 토큰을 외우지 않아도 토큰 체계와 진단 도구 덕에 색의 일관성을 지킬 수 있다. 사람은 방향을 잡고, 도구는 디테일을 챙긴다. 이게 가장 현실적이고 지속 가능한 역할 분담이다.

마지막으로 한 가지. 색상 토큰을 이해하는 일은 단지 ‘색’의 문제를 넘어, 공공 웹을 ‘체계로 바라보는 눈’을 기르는 일이다. 색이 흩어지는 걸 막는 원리는 여백이 흩어지는 걸 막는 원리와 같고, 그건 다시 컴포넌트와 패턴이 흩어지는 걸 막는 원리로 이어진다. 토큰이라는 작은 개념 하나를 제대로 잡으면, KRDS라는 큰 시스템 전체가 ‘왜 그렇게 설계됐는지’가 보이기 시작한다. 천 개의 색에서 시작해 공공 웹의 질서 전체로 시야가 넓어지는 것이다.

【 마무리 】

오늘 이야기를 한 문장으로 줄이면 이렇다. KRDS 색상 토큰 586개는 ‘수백개의 색을 쓰라는 강요’가 아니라 ‘색을 역할로 부르고, 함부로 늘어나지 못하게 묶어두는 울타리’다.

핵심을 다시 짚어보자. 토큰은 색에 ‘역할 이름표’를 붙이는 방식이고, 그 덕에 색을 코드가 아니라 의미로 부를 수 있다. 586개라는 숫자는 ‘색 계열 × 밝기 단계 × 역할 × 두 겹 구조’의 곱으로 자연스럽게 나온 결과이지, 누가 억지로 채운 게 아니다. 토큰이 없으면 색은 흩어져 누더기가 되고, 변경은 대공사가 되며, 접근성과 신뢰성까지 흔들린다. 반대로 토큰이 있으면 색은 정해진 사전 안에서만 쓰이고, 변경은 한 줄로 끝나며, 적용 여부는 숫자로 검증된다.

담당자가 할 일은 천 개를 외우는 게 아니라 네 가지다. 우리 사이트에 색이 몇 종 쓰이는지 현황을 파악하고, 새로 만드는 곳부터 토큰을 적용하고, ‘적용했다’와 ‘제대로 적용됐다’를 구분해 검증하고, 채택률을 추세로 관리하는 것. 이 네 걸음이면 충분하다. 나머지 디테일은 표준과 도구가 챙겨준다.

그리고 바로 이 ‘검증’과 ‘추세 관리’를 사람이 손으로 하는 건 사실상 불가능하다. 수백 페이지에 흩어진 색을 일일이 찍어 표준 토큰과 대조하고, 본문의 명도 대비를 하나하나 재고, 비표준 색이 끼어들지 않았는지 살피는 일을 자동으로 해주는 도구가 필요하다. ViewCheck는 바로 그 일을 한다. 공공 웹의 KRDS 846규칙(DS 120 + CP 446 + BP 108 + SP 172) 준수 여부를 자동으로 진단하고, 그 안에서 디자인 시스템 탭의 ‘디자인 토큰 채택률’을 통해 ‘우리 사이트가 표준 색상 토큰을 얼마나 따르고 있는지’를 숫자로 보여준다. “잘 적용했다”는 막연한 말이 “토큰 채택률 몇 퍼센트”라는 검증 가능한 사실로 바뀌는 순간이다.

오늘 글에서 가장 가져가고 싶은 건 ‘천 개라는 숫자에 겁먹지 말자’는 마음가짐이다. 그 숫자는 부담이 아니라 안전장치다. 우리 사이트의 색이 지금 얼마나 흩어져 있는지, 표준 토큰을 얼마나 따르고 있는지 궁금하다면, 한 번 직접 확인해보는 게 가장 빠르다. ViewCheck는 디자인 시스템 탭의 토큰 채택률 한 줄만 봐도, 오늘 글의 이야기가 ‘남의 일’이 아니라 ‘우리 일’이라는 걸 단번에 느끼게 될 거다. 색을 감으로 검수하던 시절에 작별을 고하는 첫걸음으로, 가볍게 시작해보시길 권한다.

다음 글에서는 ‘토큰 채택률을 어떻게 읽고, 어디부터 손대야 하는지’를 한층 실전적으로 다룰 예정이다. 오늘이 ‘왜 천 개인가’를 푸는 개념 편이었다면, 다음은 ‘그래서 우리는 무엇을 할 것인가’를 푸는 실전 편이다. 색의 질서를 되찾는 여정에 함께해 주시면 좋겠다.

키워드/태그: #KRDS #공공웹 #디자인토큰 #색상토큰 #디자인시스템 #웹접근성 #KWCAG #전자정부 #공공웹디자인 #디자인일관성 #토큰채택률 #ViewCheck

ViewCheck — KRDS 자동 준수 검증 서비스
krds.viewcheck.co.kr