디자인 토큰? 색·글자·간격을 변수로 관리한다는 것

디자인 토큰? 색·글자·간격을 변수로 관리한다는 것

---

ViewCheck 마케팅 홍보 — 2026년 9월 · W1 디자인 토큰이란 (9/7~9/13)

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

【 공감·문제제기 】

“그 파란색, 코드값이 뭐예요?”

홈페이지 개편 회의에서 내가 외주 디자이너에게 던진 질문이었다. 화면에 깔린 메인 배너의 파란색이 마음에 들어서, 같은 색을 다른 페이지에도 쓰고 싶었다. 그런데 돌아온 대답이 묘했다. “어… 그 페이지는 1F4E79이고요, 옆 페이지는 1E5090이에요. 거의 비슷한 파란색이긴 한데요.” 거의 비슷하다니. 내 눈엔 같은 파란색이었는데, 알고 보니 사이트 안에 ‘거의 비슷한 파랑’이 일곱 개쯤 굴러다니고 있었다.

그날 화면 캡처를 모아 색만 뽑아봤다. 파랑 일곱 종, 회색 열한 종, 빨강도 ‘경고용 빨강’과 ‘강조용 빨강’과 ‘그냥 어쩌다 들어간 빨강’이 따로 있었다. 글자 크기는 더 가관이었다. 본문이라고 부르는 글자가 어떤 페이지는 15px, 어떤 페이지는 16px, 또 어떤 페이지는 14px이었다. 누가 봐도 같은 본문인데 페이지마다 미묘하게 달랐다. 간격은 말할 것도 없었다. 18px, 20px, 22px… 자로 잰 듯 들쭉날쭉했다.

솔직히 처음엔 ‘이게 무슨 문제야’ 싶었다. 1px, 2px 차이를 누가 알아채겠나. 그런데 이게 쌓이니까 사이트 전체가 어딘가 ‘정돈 안 된’ 느낌을 줬다. 분명 각 페이지는 그럴듯한데, 모아 놓으면 손때 묻은 잡동사니 서랍 같았다. 그리고 더 큰 문제는 따로 있었다. 윗선에서 “우리 기관 상징색을 살짝 바꾸기로 했으니 사이트 파란색을 새 색으로 교체해줘”라고 했을 때, 외주 업체가 견적서에 적어온 작업 기간이 ‘3주’였다. 색 하나 바꾸는 데 3주라니. 파랑이 사이트 곳곳에 일곱 종으로 흩어져 박혀 있으니, 그걸 일일이 찾아 바꾸는 데만 3주가 걸린다는 얘기였다.

이 글은 바로 그 사건의 해결책에 관한 이야기다. 답은 ‘디자인 토큰’이라는 개념에 있었다. 색·글자·간격 같은 디자인의 기본 재료를 그냥 숫자로 흩뿌리는 게 아니라, ‘변수’라는 이름표를 붙여 한 곳에서 관리하는 방식이다. 이름만 들으면 개발자나 알 법한 전문 용어처럼 들리지만, 개념 자체는 의외로 살림살이에 가깝다. 양념통에 라벨을 붙여 정리하는 일, 콘센트 규격을 통일하는 일, 회사 서식을 표준 양식으로 묶는 일과 본질이 똑같다.

먼저 결론부터 말하면 이렇다. 디자인 토큰은 ‘색은 무슨 색, 글자는 몇 픽셀, 간격은 얼마’ 같은 디자인의 원자 단위를 숫자가 아니라 ‘의미를 가진 변수’로 부르기로 약속한 것이다. 1F4E79라는 헥스 코드 대신 ‘주-색상’이라고 부르고, 16px 대신 ‘본문-글자크기’라고 부른다. 그리고 그 변수가 실제로 어떤 값을 가질지는 단 한 곳에 정의해둔다. 그러면 색을 바꿀 때 그 한 곳만 고치면 사이트 전체가 따라 바뀐다. 3주짜리 작업이 30초짜리 작업이 되는 마법이 여기서 나온다.

대한민국 정부가 정리한 공공 웹 디자인 시스템 KRDS도 이 토큰을 가장 밑바닥 토대로 삼는다. KRDS는 846개 규칙으로 이루어진 공식 디자인 시스템인데, 그중 DS(디자인 시스템 기반 요소) 약 120개 규칙의 상당수가 바로 이 토큰을 다룬다. 색 토큰, 타이포 토큰, 간격 토큰, 모서리 둥글기 토큰… 공공 웹이 ‘일관되게 보이는’ 비결의 절반은 이 토큰 체계에 있다. 그래서 토큰을 이해하면 KRDS의 가장 단단한 기초를 손에 쥐는 셈이 된다.

이 글은 디자인 토큰을 처음 듣는 공공웹 담당자를 위한 입문 글이다. 디자인 전공자가 아니어도, 개발자가 아니어도 괜찮다. 나처럼 ‘그 파란색 코드값이 뭐냐’고 물었다가 충격받아 본 사람이라면 더 잘 와닿을 거다. 어려운 용어는 최대한 살림살이 비유로 풀어쓸 생각이니, 차 한 잔 들고 편하게 읽어 내려가면 된다.

한 가지 미리 안심시켜 드리자면, 이 글은 토큰을 ‘또 공부해야 할 숙제’로 만들려는 게 아니다. 오히려 반대다. 토큰을 알면 일이 줄어든다는 걸 보여주려는 글이다. 매번 색을 새로 고르느라 드는 시간, 페이지마다 다른 글자를 맞추느라 드는 시간, 변경 한 번에 며칠씩 걸리던 시간 — 이 모든 게 ‘기본 재료를 변수로 묶는’ 단순한 발상 하나로 줄어든다. 그러니 부담을 더하는 개념이 아니라, 부담을 더는 도구로 토큰을 바라봐 주시면 좋겠다. 그리고 솔직히 말하면, 이건 디자인의 영역이라기보다 ‘정리정돈’의 영역에 더 가깝다. 어수선한 서랍을 칸막이로 나누고 라벨을 붙이는 일, 누구나 한 번쯤 해본 그 일과 본질이 같다.

이 글의 흐름은 이렇다. 먼저 ‘변수’라는 말부터 가계부에 빗대 쉽게 푼다. 그다음 토큰이 색·글자·간격에서 각각 어떻게 작동하는지를 하나씩 본다. 토큰이 없을 때 실제로 어떤 사고가 나는지 익명 사례로 보여주고, 토큰을 ‘이름 짓는 방식’의 묘미를 짚는다. 마지막으로 ‘우리 기관은 무엇부터 시작하면 되는지’를 실무 단계로 정리하고, 토큰이 얼마나 잘 적용됐는지를 어떻게 측정하는지(토큰 채택률)까지 다룬다. 끝까지 읽으면 ‘토큰? 별거 아니네, 진작 할 걸’ 싶어질 거라고 확신한다.

【본론 1 — 개념·왜 중요한가】

■ 변수가 대체 뭔데? — 가계부로 풀어보는 이야기

‘변수’라는 단어가 수학 시간의 트라우마를 건드릴 수 있다. x니 y니 하는 그 변수 말이다. 하지만 디자인 토큰에서 말하는 변수는 훨씬 다정하다. 살림하는 사람이라면 이미 매일 쓰고 있는 개념이다.

가계부를 떠올려 보자. 매달 ‘교통비’ 항목에 5만 원을 적는다. 그런데 어느 날 대중교통 요금이 올라서 교통비가 6만 원이 됐다고 치자. 만약 당신이 1월부터 12월까지 가계부 곳곳에 ‘교통비 5만 원’이라고 숫자를 일일이 적어뒀다면, 요금이 오른 순간 열두 달 치 숫자를 전부 손으로 고쳐야 한다. 하나라도 빠뜨리면 합계가 틀어진다.

그런데 똑똑한 사람은 이렇게 한다. 맨 위에 ‘교통비 = 5만 원’이라고 딱 한 번 정의해두고, 본문에서는 그냥 ‘교통비’라고만 적는다. 그러면 요금이 오를 때 맨 위 정의 한 줄만 ‘교통비 = 6만 원’으로 바꾸면, 본문의 모든 ‘교통비’가 자동으로 6만 원으로 계산된다. 이게 바로 변수다. ‘이름 하나에 값 하나를 연결해두고, 값이 바뀌면 한 곳만 고치는’ 방식. 엑셀을 써본 사람이라면 셀 참조를 떠올리면 정확하다. A1 셀에 값을 넣고 다른 셀에서 =A1이라고 참조해두면, A1만 바꿔도 참조한 모든 셀이 따라 바뀌는 그 원리다.

디자인 토큰은 이 가계부의 ‘교통비’ 자리에 디자인 재료를 넣은 것이다. ‘주-색상 = #1F4E79’라고 한 번 정의해두고, 사이트 곳곳의 버튼·링크·강조 영역에서는 그냥 ‘주-색상’이라고만 부른다. 그러면 나중에 상징색이 바뀌어도 정의 한 줄만 고치면 사이트 전체가 새 색으로 갈아입는다. 내가 겪었던 ‘3주 작업’이 ‘30초 작업’이 되는 이유가 바로 이거다. 파랑이 사이트 곳곳에 헥스 코드 숫자로 흩어져 있었기 때문에 3주가 걸렸던 거지, 처음부터 ‘주-색상’이라는 변수 하나로 묶여 있었다면 정의 한 줄 수정으로 끝났을 일이었다.

여기서 ‘토큰’이라는 이름이 왜 붙었는지도 짚어두자. 토큰은 원래 ‘대신하는 표식’이라는 뜻이다. 옛날 목욕탕에서 동전 대신 쓰던 그 토큰, 게임 오락실의 토큰을 떠올리면 된다. 실제 값(헥스 코드, 픽셀 숫자)을 직접 쓰는 대신, 그것을 ‘대신 가리키는 이름표’를 쓰는 것이다. 1F4E79라는 암호 같은 숫자 대신 ‘주-색상’이라는 사람이 읽을 수 있는 이름을 쓰면, 코드를 들여다보지 않아도 ‘아, 여기는 주 색상을 쓰는 자리구나’ 하고 의미가 바로 읽힌다. 토큰은 ‘값에 의미를 붙이는 일’이기도 한 셈이다.

조금 더 밀고 가보자. 토큰이 진짜 강력해지는 건 ‘여러 단계로 쌓을’ 때다. 가장 밑바닥에 ‘파랑-700 = #1F4E79’ 같은 순수한 색 정의가 있다. 이걸 ‘원시 토큰’ 혹은 ‘기본 토큰’이라 부른다. 이름만 봐선 어디 쓰는 색인지 알 수 없는, 그냥 색 그 자체다. 그 위에 ‘주-색상 = 파랑-700’이라는 한 층을 더 얹는다. 이걸 ‘의미 토큰’이라 부른다. ‘주된 행동을 나타낼 때 쓰는 색’이라는 역할을 이름에 담은 것이다. 그리고 또 그 위에 ‘버튼-배경색 = 주-색상’처럼 ‘어디에 쓰는지’까지 구체화한 ‘부품 토큰’을 얹기도 한다.

이 층위 구조를 옷장에 빗대면 이렇다. 맨 아래 ‘원시 토큰’은 옷장 안의 실제 옷들이다 — 남색 셔츠, 회색 바지처럼 구체적인 물건. ‘의미 토큰’은 ‘출근복’ ‘운동복’ 같은 용도별 묶음이다. 어떤 옷을 출근복으로 정할지는 바뀔 수 있지만, ‘출근할 때 입는 옷’이라는 용도는 그대로다. 그래서 출근복으로 입던 남색 셔츠를 회색 셔츠로 바꿔도, ‘출근복을 입는다’는 일상은 한 줄도 안 바뀐다. 토큰의 층위가 이렇게 ‘구체적인 값’과 ‘쓰임의 의미’를 분리해두기 때문에, 값이 바뀌어도 쓰는 쪽은 흔들리지 않는다.

왜 이렇게 번거롭게 층을 쌓을까? 유연함 때문이다. 예를 들어 브랜드 색을 파랑에서 청록으로 바꾸기로 했다면, 맨 밑바닥의 ‘파랑-700’을 ‘청록-700’으로 바꾸는 게 아니라, ‘주-색상 = 파랑-700’을 ‘주-색상 = 청록-700’으로 바꾸면 된다. 그러면 ‘주-색상’을 참조하던 버튼·링크·강조가 전부 청록으로 바뀌지만, 정작 ‘파랑-700’ 자체를 직접 참조하던 일부 장식 요소는 그대로 파랑을 유지한다. 즉 ‘의도한 것만 바꾸고, 건드리면 안 되는 건 보존하는’ 정교한 제어가 가능해진다. 이 층위 구조가 처음엔 과해 보여도, 사이트가 커질수록 진가를 발휘한다.

■ 색 토큰 — ‘파랑’이 아니라 ‘무엇을 위한 파랑’인가

이제 색부터 구체적으로 보자. 토큰이 없는 사이트의 색은 ‘파랑’ ‘회색’ ‘빨강’처럼 그냥 색 이름이거나, 더 나쁘게는 1F4E79 같은 암호 숫자다. 토큰을 도입한 사이트의 색은 ‘주-색상’ ‘보조-색상’ ‘강조-색상’ ‘경고-색상’ ‘배경-색상’ ‘테두리-색상’처럼 ‘역할’로 불린다. 이 차이가 생각보다 크다.

색을 역할로 부르면 어떤 일이 생기나. 첫째, 일관성이 자동으로 따라온다. ‘주된 행동을 유도하는 버튼은 항상 주-색상을 쓴다’는 규칙만 지키면, 누가 어느 페이지를 만들든 주요 버튼 색이 통일된다. 더 이상 ‘이 페이지의 파랑은 1F4E79, 저 페이지의 파랑은 1E5090’ 같은 사고가 안 난다. 색을 직접 고르는 게 아니라 역할에 맞는 토큰을 골라 쓰기 때문이다.

둘째, 의미가 코드에 박힌다. ‘경고-색상’이라고 쓰여 있으면 그게 빨강이든 주황이든, 코드를 읽는 사람은 ‘아 여기는 경고를 표시하는 자리구나’ 하고 안다. 반대로 그냥 ‘#D32F2F’라고만 쓰여 있으면, 이게 경고인지 강조인지 그냥 예뻐서 쓴 빨강인지 알 길이 없다. 토큰은 색에 ‘왜 이 색인가’라는 이유를 함께 묶어 보관하는 셈이다.

셋째, 다크 모드나 고대비 모드 같은 ‘여러 테마’를 깔끔하게 다룰 수 있다. 사이트가 밝은 모드와 어두운 모드를 둘 다 지원해야 한다고 치자. 토큰이 없으면 모든 색을 두 벌로 만들어 페이지마다 분기 처리를 해야 한다. 끔찍한 작업이다. 토큰이 있으면 ‘배경-색상’이라는 이름은 그대로 두고, 밝은 모드에서는 흰색, 어두운 모드에서는 짙은 회색을 가리키도록 정의 묶음만 두 벌 준비하면 된다. 화면 코드는 한 줄도 안 바뀌고 테마만 갈아끼우는, 그야말로 ‘옷만 갈아입히는’ 방식이 가능해진다. 공공 웹에서 점점 중요해지는 고대비·저시력 사용자 대응도 이 토큰 구조 위에서 훨씬 수월해진다.

KRDS의 색 체계가 바로 이 역할 기반 토큰으로 짜여 있다. 단순히 ‘이 색을 쓰세요’가 아니라, 주·보조·강조·상태(성공/경고/오류/정보)·중립(회색 계열)처럼 역할별로 색을 정의하고, 각 역할 안에서도 명도 단계(밝은 단계부터 짙은 단계까지)를 체계적으로 나눠둔다. 회색 하나만 해도 ‘가장 옅은 배경 회색’부터 ‘본문 글자에 쓰는 짙은 회색’까지 여러 단계로 정리돼 있어서, 담당자는 ‘대충 적당한 회색’이 아니라 ‘이 자리에 맞는 회색 단계’를 정확히 고를 수 있다. 색 대비(콘트라스트) 기준을 충족시키기도 훨씬 쉬워진다. 단계가 명확하면 ‘배경과 글자가 충분히 대비되는 조합’을 미리 검증해둘 수 있기 때문이다.

■ 글자 토큰 — 본문이 15px인지 16px인지가 왜 중요한가

색 다음은 글자, 그러니까 타이포그래피다. 솔직히 글자 크기 1px 차이는 보통 사람 눈에 거의 안 보인다. 그런데도 이게 토큰으로 관리돼야 하는 이유가 있다.

먼저 ‘위계’ 이야기를 해야 한다. 잘 정돈된 사이트의 글자는 ‘아무 크기나’ 쓰는 게 아니라 ‘정해진 몇 단계’만 쓴다. 큰 제목, 중간 제목, 작은 제목, 본문, 보조 설명, 캡션… 보통 예닐곱 단계 정도로 정리한다. 이걸 ‘타입 스케일’이라 부른다. 이 단계가 정해져 있으면, 글을 읽는 사람은 글자 크기만 보고도 ‘이건 큰 제목, 이건 본문, 이건 부연 설명’이라는 정보의 무게를 직감한다. 종이 신문에서 헤드라인과 기사 본문과 사진 설명의 글자 크기가 명확히 다른 것과 같은 이치다.

문제는 이 위계가 무너질 때다. 토큰 없이 페이지마다 ‘적당히’ 크기를 정하면, 어떤 페이지의 본문은 16px인데 어떤 페이지의 ‘작은 제목’이 15px인 황당한 역전이 생긴다. 본문보다 작은 제목이라니. 이러면 사용자의 눈은 ‘뭐가 더 중요한 정보인지’ 판단할 기준을 잃는다. 글자 크기가 정보의 위계를 알려주는 신호인데, 그 신호가 뒤죽박죽이면 화면이 한눈에 안 읽힌다.

타이포 토큰은 이 위계를 ‘이름표가 붙은 변수’로 고정한다. ‘제목-대 = 32px’ ‘제목-중 = 24px’ ‘본문 = 16px’ ‘캡션 = 13px’처럼 단계마다 이름을 붙여두고, 화면에서는 그냥 ‘본문’ ‘캡션’이라고 부른다. 그러면 ‘본문’이라고 쓴 글자는 사이트 어디서나 똑같이 16px이 된다. 본문 크기를 통째로 17px로 키우고 싶으면? 토큰 정의 한 줄만 고치면 사이트 전체 본문이 한 번에 커진다. 고령층 사용자 비중이 높은 공공 사이트에서 ‘본문 글자를 조금 키우자’는 결정이 내려졌을 때, 토큰이 없으면 수천 군데를 고쳐야 하지만 토큰이 있으면 한 줄로 끝난다.

타이포 토큰은 크기만 다루는 게 아니다. 글꼴 종류, 굵기(두께), 줄 간격(행간), 자간(글자 사이 간격)까지 묶음으로 관리한다. 예를 들어 ‘본문’ 토큰은 ‘본문용 글꼴 + 16px + 보통 굵기 + 줄 간격 1.6배’를 한 세트로 정의한다. 그러면 본문을 쓸 때마다 이 다섯 가지를 일일이 지정하지 않아도, ‘본문’ 하나만 적용하면 끝이다. 줄 간격이 너무 좁아서 답답하다는 피드백이 오면, ‘본문’ 토큰의 줄 간격만 1.6에서 1.7로 바꾸면 사이트 전체 본문의 숨통이 한꺼번에 트인다.

KRDS는 공공 웹에 적합한 글꼴과 타입 스케일을 권장한다. 가독성이 좋고 여러 기기에서 안정적으로 표시되는 글꼴을 기준으로 삼고, 제목부터 캡션까지의 단계를 체계적으로 제시한다. 여기서 핵심은 ‘공공 서비스는 읽기 위해 오는 곳’이라는 점이다. 쇼핑몰처럼 화려하게 시선을 끌 필요보다, 정보를 정확하고 편하게 읽히게 하는 게 우선이다. 그래서 KRDS의 타이포 토큰은 ‘멋’보다 ‘읽힘’에 초점이 맞춰져 있고, 그 읽힘을 모든 페이지에서 균일하게 보장하기 위해 토큰이라는 장치를 쓴다.

■ 간격 토큰 — 8의 배수라는 보이지 않는 격자

세 번째 재료는 간격, 즉 여백이다. 요소와 요소 사이의 거리, 글과 글 사이의 틈, 박스 안쪽의 여백 같은 것들이다. 색이나 글자보다 더 ‘안 보이는’ 영역이지만, 사이트의 정돈된 느낌을 좌우하는 숨은 주인공이다.

토큰이 없는 사이트의 간격은 그야말로 무법지대다. 어떤 요소는 위에 18px, 어떤 건 20px, 어떤 건 22px, 또 어떤 건 그냥 23px… 만든 사람이 그때그때 눈대중으로 정했기 때문이다. 개별로 보면 다 괜찮아 보이는데, 모아 놓으면 어딘가 ‘리듬이 안 맞는’ 느낌을 준다. 음악으로 치면 박자가 미묘하게 어긋난 연주 같은 거다.

간격 토큰은 이 무법지대에 ‘격자’를 깐다. 가장 널리 쓰이는 방식이 ‘8의 배수’ 체계다. 간격을 4, 8, 16, 24, 32, 40, 48… 처럼 일정한 배수로만 쓰기로 약속하는 것이다. 19px, 21px 같은 어중간한 숫자는 아예 쓰지 않는다. 왜 하필 8일까? 8은 2로도 4로도 깔끔하게 나뉘고, 대부분의 화면 해상도와 잘 맞아떨어져서 픽셀이 흐려지지 않는다. 무엇보다 ‘선택지가 줄어드는’ 게 핵심이다. 18이냐 20이냐 22냐를 고민할 필요 없이, ‘16이냐 24냐’ 둘 중 하나만 고르면 된다. 선택지가 줄면 결정이 빨라지고, 모두가 같은 격자 위에서 작업하니 결과가 저절로 정돈된다.

간격 토큰도 이름표를 붙인다. ‘간격-소 = 8px’ ‘간격-중 = 16px’ ‘간격-대 = 24px’처럼. 그러면 ‘카드 안쪽 여백은 간격-중’ ‘섹션 사이는 간격-특대’ 같은 규칙을 세울 수 있고, 누가 만들든 같은 호흡으로 여백이 들어간다. 사이트 전체의 ‘답답함’이나 ‘허전함’을 조정하고 싶을 때도 토큰 단계 정의만 손보면 일관되게 바뀐다. 이 ‘8의 배수 격자’는 눈에 보이진 않지만, 사용자가 무의식적으로 느끼는 ‘이 사이트 정돈됐네’의 정체 중 하나다.

KRDS 역시 이런 간격 체계를 기준으로 삼아, 요소 사이의 여백과 레이아웃 격자를 규칙으로 정리해둔다. 모서리 둥글기(버튼이나 카드의 둥근 정도)도 마찬가지로 토큰화한다. ‘작은 둥글기’ ‘중간 둥글기’ ‘큰 둥글기’처럼 단계를 정해두면, 어떤 버튼은 4px 둥글고 어떤 버튼은 6px 둥근 미묘한 불일치가 사라진다. 그림자(입체감을 주는 음영)도 단계별 토큰으로 관리해서, 카드가 떠 보이는 정도가 화면마다 제멋대로이지 않게 한다. 색·글자·간격·둥글기·그림자 — 이 모든 ‘디자인의 원자’가 토큰이라는 같은 원리로 묶이는 것이다.

■ 토큰이 없을 때 진짜로 무엇이 비싸지는가

여기서 잠깐, ‘토큰이 없으면 불편하다’는 막연한 말 대신, 무엇이 실제로 비싸지는지를 조금 더 구체적으로 짚어보고 싶다. 토큰이 없는 사이트의 진짜 비용은 ‘처음 만들 때’가 아니라 ‘운영하는 내내’ 발생하기 때문이다.

먼저 ‘결정의 비용’이다. 토큰이 없으면 페이지를 만들 때마다 색·글자·간격을 새로 정해야 한다. 이 결정은 하나하나는 몇 초짜리지만, 페이지가 수백 개고 요소가 수십 개씩이면 ‘몇 초 × 수만 번’이 된다. 게다가 이 결정은 ‘틀려도 티가 잘 안 나서’ 검수에서 걸러지지도 않는다. 그냥 조용히 쌓여 사이트를 너저분하게 만든다. 토큰은 이 결정 횟수를 ‘한 번 정하고 계속 가져다 쓰기’로 바꿔, 결정의 총량 자체를 극적으로 줄인다.

다음은 ‘소통의 비용’이다. 토큰이 없으면 담당자와 외주 업체 사이의 대화가 자꾸 모호해진다. “그 파랑 말고 좀 더 진한 파랑이요” “여백을 조금만 더 주세요” 같은 말은 사람마다 다르게 해석된다. ‘조금’이 누구에겐 4px, 누구에겐 12px이다. 토큰이 있으면 “여기는 주-색상이 아니라 강조-색상이 맞아요” “이 카드 안쪽은 간격-중으로 맞춰주세요”처럼 ‘공통 어휘’로 말할 수 있다. 모호한 형용사가 정확한 명사로 바뀌면, 회의가 짧아지고 재작업이 줄어든다. 이건 디자인 품질의 문제이기 이전에 ‘일이 매끄럽게 굴러가느냐’의 문제다.

마지막은 ‘위험의 비용’이다. 토큰 없이 흩어진 값을 다룰 때 가장 무서운 건 ‘빠뜨림’이다. 색을 바꾸다 한두 군데를 놓치면, 새 색들 사이에 옛 색이 섞여 오히려 더 지저분해진다. 그리고 그 빠뜨림은 보통 ‘잘 안 들어가는 페이지’에서 일어나, 한참 뒤 민원으로 발견된다. 토큰은 ‘값을 한 곳에 모아두기’ 때문에 빠뜨릴 곳 자체가 없다. 한 곳만 고치면 끝이니, 빠뜨림이라는 위험이 구조적으로 사라진다.

이 세 가지 비용 — 결정·소통·위험 — 은 평소엔 잘 안 보인다. 그래서 토큰의 가치도 평소엔 잘 안 보인다. 토큰의 진가는 ‘무언가를 바꿔야 할 때’ ‘담당자가 교체될 때’ ‘외주가 바뀔 때’처럼 변화의 순간에 드러난다. 공공 사이트는 개편 주기가 길고 그사이 담당자와 업체가 여러 번 바뀌므로, 이 ‘변화에 강한 구조’의 가치가 민간보다 오히려 더 크다.

■ 토큰은 ‘디자인 언어’를 통일하는 일이다

조금 더 큰 틀에서 보면, 디자인 토큰은 단순한 기술 장치가 아니라 ‘조직이 디자인을 말하는 언어’를 통일하는 일이다. 한 조직 안에서도 디자이너는 색을 ‘브랜드 블루’라 부르고, 개발자는 ‘1F4E79’라 부르고, 기획자는 ‘그 진한 파랑’이라 부른다. 같은 색을 세 사람이 세 가지로 부르면, 소통할 때마다 번역 비용이 든다.

토큰은 이 세 사람이 ‘주-색상’이라는 하나의 단어로 같은 것을 가리키게 만든다. 디자이너의 의도, 개발자의 구현, 기획자의 요구가 같은 단어 위에서 만난다. 이게 왜 중요하냐면, 디자인 시스템의 가장 큰 적이 ‘오해’이기 때문이다. 디자이너는 A를 의도했는데 개발자가 B로 구현하고, 검수자는 그게 틀렸는지도 모른 채 통과시키는 일이 토큰 없는 조직에서 끝없이 반복된다. 공통 어휘가 있으면 이 오해의 사슬이 끊긴다.

그래서 토큰을 도입하는 일은 ‘색을 정리하는 일’처럼 보이지만 실은 ‘조직의 협업 방식을 정리하는 일’에 가깝다. 색·글자·간격이라는 구체적 재료를 매개로, 사람들이 같은 언어로 디자인을 말하게 되는 것이다. 이 언어가 한 번 자리 잡으면, 신입이 와도, 외주가 바뀌어도, 부서가 협업해도 ‘같은 말’로 일할 수 있다. 토큰의 가장 깊은 가치는 어쩌면 여기에 있다.

【본론 2 — 흔한 실수·사례 (익명)】

개념을 들었으니 ‘토큰이 없으면 실제로 무슨 사고가 나는지’ 익명 사례로 보자. 아래 이야기들은 특정 기관 사례가 아니라, 공공 사이트를 점검하다 보면 패턴처럼 반복되는 전형적인 상황을 익명으로 재구성한 것이다. 읽다가 ‘어, 우리 얘긴가?’ 싶으면, 그건 그만큼 흔한 일이라는 뜻이지 당신 기관만의 문제가 아니다.

■ 사례 하나: 색 하나 바꾸는 데 3주

앞서 도입부에서 꺼낸 내 경험이 사실 전형적인 사례다. 한 A광역지자체 사이트가 상징색을 미세하게 조정하기로 했다고 치자. 기존 파랑보다 살짝 밝고 산뜻한 톤으로 바꾸자는 결정이었다. 디자인 관점에선 ‘파랑 코드 하나 바꾸면 되는 일’처럼 보인다.

그런데 막상 작업에 들어가니 견적이 3주가 나왔다. 이유는 단순했다. 사이트가 ‘토큰’ 없이 만들어져 있었던 거다. 파랑이 헥스 코드 형태로 사이트 곳곳에 직접 박혀 있었고, 게다가 ‘거의 비슷한 파랑’이 일곱 종이나 흩어져 있었다. 작업자는 이 일곱 종을 일일이 찾아내, 어떤 건 새 색으로 바꾸고 어떤 건 그대로 둬야 할지 판단하며 수천 군데를 손봐야 했다. 게다가 하나라도 빠뜨리면 ‘옛날 파랑’이 새 파랑들 틈에 섞여 더 지저분해진다. 빠뜨림 검수에만 며칠이 더 들었다.

이게 ‘DS 서랍의 문제’다. 가장 밑바닥 색 토큰이 정리돼 있지 않으니, 가장 사소해 보이는 변경이 가장 비싼 작업이 됐다. 만약 처음부터 ‘주-색상’이라는 토큰 하나로 묶여 있었다면? 정의 한 줄을 새 파랑으로 바꾸고, 검수는 ‘주-색상을 안 쓰고 헥스를 직접 박은 예외가 있나’만 확인하면 됐다. 3주가 반나절로 줄어든다. 토큰은 ‘지금 당장’보다 ‘나중에 바꿀 때’ 진가를 발휘하는데, 공공 사이트는 개편 주기가 길고 그사이 상징색·정책색이 바뀌는 일이 잦아서 이 효과가 특히 크다.

■ 사례 둘: 같은 ‘본문’인데 페이지마다 다른 글자

한 B공공기관 사이트를 점검하다가, 본문 글자 크기를 페이지별로 뽑아본 적이 있다고 치자. 결과가 흥미로웠다. 메인은 16px, 보도자료 목록은 15px, 사업안내 상세는 14px, 그런데 또 어떤 안내 페이지는 17px이었다. 전부 ‘본문’이라고 부르는 글자였는데, 페이지마다 제각각이었다.

원인은 ‘토큰 없는 협업’이었다. 페이지를 만든 시기가 다르고, 만든 업체가 다르고, 그때그때 담당자 취향도 달랐다. ‘본문은 16px’이라는 약속이 없으니 다들 ‘이 정도면 적당하지’ 하고 눈대중으로 정한 것이다. 개별 페이지만 보면 다 읽을 만했다. 문제는 사용자가 페이지를 옮겨 다닐 때다. 14px 페이지에서 17px 페이지로 넘어가면, 같은 사이트인데 글자가 갑자기 커져서 ‘어, 화면이 바뀌었나’ 하는 미세한 위화감을 준다. 특히 글자를 키워 쓰는 고령 사용자에게는 이 들쭉날쭉함이 더 크게 느껴진다.

이건 ‘DS 토큰 + BP(기본 패턴)’가 함께 얽힌 문제다. 본문 토큰이 없으니(DS) 페이지 간 일관성이 깨지고(패턴), 그 결과 ‘읽기’라는 가장 기본적인 사용 흐름이 매끄럽지 못했다. 해법은 ‘본문 = 16px’ 토큰을 정하고, 모든 본문이 그 토큰을 참조하게 바꾸는 것이다. 그러면 나중에 ‘고령층 민원이 많으니 본문을 17px로 키우자’는 결정이 나와도, 토큰 한 줄만 고치면 사이트 전체 본문이 일제히 커진다. ‘읽힘’이라는 공공 웹의 본질을 한 곳에서 통제할 수 있게 되는 셈이다.

■ 사례 셋: 어중간한 간격이 만든 ‘리듬 깨짐’

C기관 사이트는 색도 글자도 그럭저럭 통일돼 있었는데, 묘하게 ‘정돈 안 된’ 인상을 줬다. 한참 들여다보니 범인은 간격이었다. 카드와 카드 사이가 어떤 곳은 18px, 어떤 곳은 22px이었고, 박스 안쪽 여백도 제각각이었다. 누가 봐도 알아챌 정도는 아닌데, 전체적으로 ‘리듬이 안 맞는’ 느낌이 깔려 있었다.

이건 ‘8의 배수’ 같은 간격 격자가 없었기 때문이다. 만드는 사람마다 ‘적당히’ 여백을 줬고, 그 ‘적당히’가 사람마다 1~2px씩 달랐다. 각각은 사소하지만 화면 전체에 쌓이니 미묘한 불협화음이 됐다. 해법은 간격 토큰을 도입해 ‘여백은 8의 배수만 쓴다’는 약속을 세우는 것이다. 19px, 21px 같은 숫자를 아예 선택지에서 지우면, 만드는 사람의 ‘눈대중 편차’가 사라지고 사이트가 같은 박자로 호흡하게 된다.

■ 사례 넷: 알림 색이 제각각이라 생긴 혼란

한 D기관 사이트에서는 ‘성공’과 ‘경고’와 ‘오류’를 알리는 색이 페이지마다 달랐다고 치자. 어떤 페이지는 오류를 빨강으로, 어떤 페이지는 주황으로 표시했고, 또 어떤 페이지에서는 성공 안내가 파랑이었다가 다른 페이지에서는 초록이었다. 사용자 입장에서는 ‘이 색이 좋은 신호인가 나쁜 신호인가’를 페이지마다 새로 판단해야 했다.

이건 ‘상태 색 토큰’이 정리되지 않아서 생긴 문제다. 성공·경고·오류·정보 같은 ‘상태’는 사용자에게 보내는 신호인데, 이 신호의 색이 일관되지 않으면 신호로서 기능을 못 한다. 신호등의 빨강이 어디선 멈춤이고 어디선 출발이라면 사고가 나듯, 알림 색이 제각각이면 사용자가 혼란에 빠진다. 특히 오류 메시지는 사용자가 가장 긴장하는 순간에 뜨는데, 그 색마저 들쭉날쭉하면 불안이 가중된다. 해법은 ‘성공-색상’ ‘경고-색상’ ‘오류-색상’ ‘정보-색상’을 상태 토큰으로 묶어, 사이트 어디서나 같은 색으로 같은 신호를 보내게 하는 것이다. 토큰은 색의 일관성뿐 아니라 ‘의미의 일관성’까지 지켜준다.

이 네 사례의 공통점은 분명하다. 모두 ‘디자인의 기본 재료를 변수로 묶지 않아서’ 생긴 일이다. 색·글자·간격을 그때그때 숫자로 흩뿌린 결과, 일관성이 깨지고, 변경이 비싸지고, 사용자가 미세한 불편을 누적해서 느끼게 됐다. 토큰은 이 병들을 한 번에 예방하는 백신 같은 것이다. ‘기본 재료를 이름표 붙여 한 곳에서 관리한다’는 단순한 원칙 하나가, 일관성·유지보수·사용성을 동시에 끌어올린다.

그리고 이 네 사례에는 한 가지 더 중요한 공통점이 있다. 어느 것도 ‘만든 사람이 게을러서’ 생긴 게 아니라는 점이다. 다들 그 순간엔 최선을 다해 ‘적당히 예쁘게’ 만들었다. 문제는 ‘적당히’의 기준이 사람마다, 시기마다 달랐다는 것뿐이다. 즉 이건 개인의 실력 문제가 아니라 ‘공통 기준의 부재’라는 구조의 문제다. 그래서 해법도 누군가를 탓하는 게 아니라, 모두가 따를 수 있는 기준 — 토큰 — 을 세우는 데 있다. 기준이 있으면 평범한 담당자도 일관된 결과를 내고, 기준이 없으면 뛰어난 담당자조차 시간이 지나며 불일치를 만든다. 토큰은 ‘사람을 바꾸는’ 게 아니라 ‘구조를 바꾸는’ 해법이라는 점에서, 누구나 부담 없이 받아들일 수 있는 접근이다.

【본론 3 — 토큰 이름 짓기와 적용 전략】

■ 이름을 어떻게 짓느냐가 절반이다

토큰의 가치는 ‘이름’에서 나온다고 해도 과언이 아니다. 변수에 좋은 이름을 붙이면 코드가 문장처럼 읽히고, 나쁜 이름을 붙이면 토큰을 쓰고도 여전히 헷갈린다.

나쁜 이름의 대표가 ‘파랑-1, 파랑-2, 파랑-3’ 같은 식이다. 이건 색을 변수로 묶긴 했지만, 정작 ‘파랑-2가 어디 쓰는 색인지’는 알려주지 않는다. 결국 ‘이 자리엔 파랑-2를 써야 하나 파랑-3을 써야 하나’를 매번 고민하게 된다. 변수만 만들고 의미는 못 담은 셈이다.

좋은 이름은 ‘역할’을 담는다. ‘주-색상’ ‘강조-색상’ ‘경고-색상’ ‘비활성-색상’처럼, 이름만 봐도 ‘언제 쓰는 색인지’가 드러나야 한다. 그래야 만드는 사람이 색을 ‘고르는’ 게 아니라 ‘역할에 맞게 부르는’ 단계로 올라선다. 앞서 말한 ‘원시 토큰 → 의미 토큰 → 부품 토큰’의 층위 구조가 여기서 빛난다. 밑바닥엔 ‘파랑-700’ 같은 순수 색을 두되, 화면에서 직접 부르는 건 ‘주-색상’ 같은 의미 토큰이어야 한다. 화면 코드가 ‘파랑-700’을 직접 부르기 시작하면, 나중에 색을 바꿀 때 다시 ‘파랑이 어디 박혔나’를 찾아 헤매는 옛날 문제로 돌아간다.

이름 짓기에는 한 가지 원칙이 더 있다. ‘일관된 규칙’으로 짓는 것이다. 어떤 토큰은 ‘색상-주’라고 짓고 어떤 건 ‘주색’이라고 짓고 또 어떤 건 ‘primary’라고 영어로 지으면, 토큰이 있어도 찾기가 어렵다. ‘영역-역할-단계’처럼 이름 짓는 틀을 한 번 정해두고 모든 토큰이 그 틀을 따르게 하면, 토큰 목록이 사전처럼 정돈되어 누구나 필요한 토큰을 쉽게 찾는다. 토큰은 ‘만드는 것’보다 ‘찾아 쓰는 것’이 더 자주 일어나는 일이라, 찾기 쉬운 이름 체계가 곧 토큰의 수명을 좌우한다.

■ 우리 기관은 무엇부터 시작하면 되나

“좋은 건 알겠는데, 우리 사이트는 이미 토큰 없이 만들어졌는데 이제 와서 어떻게 하냐”는 게 가장 현실적인 질문이다. 답은 ‘한 번에 다 바꾸지 말고, 단계적으로’다.

1단계는 ‘현황 파악’이다. 지금 우리 사이트에 색이 몇 종 쓰이고 있는지, 글자 크기는 몇 단계인지, 간격은 어떤 숫자들이 굴러다니는지를 먼저 ‘세어보는’ 것이다. 앞에서 내가 ‘파랑 일곱 종, 회색 열한 종’을 세어봤던 그 작업이다. 이 현황을 모르면 어디서부터 손대야 할지 알 수가 없다. 흩어진 값을 모아 보면 ‘이렇게나 중구난방이었나’ 하고 놀라게 되고, 그 충격이 곧 개선의 동력이 된다.

2단계는 ‘토큰 정의하기’다. 흩어진 색들을 역할별로 묶어 ‘주-색상’ ‘보조-색상’ 같은 의미 토큰으로 정리하고, 글자 단계를 ‘제목-대/중/소·본문·캡션’으로, 간격을 ‘8의 배수’로 표준화한다. 이때 KRDS가 큰 도움이 된다. ‘우리가 처음부터 다 정하는’ 게 아니라, ‘국가가 잘 정리해둔 공공 웹 토큰 체계를 가져다 맞추는’ 방식이라 부담이 훨씬 적다. 바닥부터 설계하는 것과 잘 된 본을 따라 정리하는 것은 노력의 크기가 다르다.

3단계는 ‘점진적 교체’다. 한 번에 전 사이트를 갈아엎는 건 위험하고 비싸다. 새로 만드는 페이지부터 토큰을 적용하고, 기존 페이지는 개편이나 유지보수 시점에 맞춰 조금씩 토큰으로 옮긴다. 자주 바뀌는 페이지, 사용자가 많이 드나드는 페이지부터 우선 적용하면 효과를 빨리 체감한다. 이 ‘점진적’이라는 단어가 중요하다. 토큰 전환은 마라톤이지 단거리 경주가 아니다.

4단계는 ‘유지’다. 토큰을 도입해도, 누군가 급하다고 또 헥스 코드를 직접 박기 시작하면 도로 무너진다. 그래서 ‘새 색이 필요하면 토큰을 추가하고, 화면에서 값을 직접 쓰지 않는다’는 규칙을 팀의 약속으로 삼아야 한다. 그리고 이 약속이 지켜지는지를 ‘측정’하는 게 마지막 열쇠다. 측정 없는 규칙은 곧 잊힌다.

■ 토큰을 무너뜨리는 흔한 함정들

토큰을 도입하고도 다시 무너지는 조직이 적지 않다. 그 이유를 미리 알아두면 같은 실수를 피할 수 있다.

첫 번째 함정은 ‘급할 때 직접 박기’다. 마감이 코앞이고 새 색이 필요한데 토큰에 마땅한 게 없으면, 누군가 “일단 이 색 직접 넣고 나중에 정리하자”고 한다. 그 ‘나중’은 거의 오지 않는다. 직접 박은 값 하나가 둘이 되고 셋이 되어, 어느새 토큰은 ‘있긴 한데 잘 안 지켜지는 약속’으로 전락한다. 그래서 ‘새 색이 필요하면 직접 박지 말고 토큰을 추가한다’는 규칙을 예외 없이 지키는 게 중요하다. 토큰 추가는 몇 분이면 되지만, 직접 박은 값을 나중에 찾아 정리하는 건 며칠이 걸린다.

두 번째 함정은 ‘토큰이 너무 많아지는 것’이다. 역설적으로 들리겠지만, 토큰을 마구 늘리면 토큰이 없는 것만 못해진다. ‘파랑-1’부터 ‘파랑-37’까지 있으면, 막상 쓸 때 ‘어떤 파랑을 써야 하지’를 다시 고민하게 된다. 좋은 토큰 체계는 ‘충분히 적어서 외울 수 있고, 충분히 많아서 필요를 채우는’ 절묘한 균형을 찾는다. 색은 역할별로 꼭 필요한 만큼만, 단계는 실제로 쓰는 만큼만 둔다. 토큰의 목적은 ‘선택지를 늘리는 것’이 아니라 ‘선택지를 의미 있게 줄이는 것’임을 잊으면 안 된다.

세 번째 함정은 ‘문서 없이 토큰만 만드는 것’이다. 토큰을 정의해두고도 ‘이 토큰을 언제 쓰는지’ 설명이 없으면, 사람마다 다르게 해석해 쓴다. ‘강조-색상’을 누구는 버튼에, 누구는 경고에 쓰면 의미가 흐트러진다. 그래서 토큰에는 ‘이 토큰은 이런 자리에 씁니다’라는 짧은 사용 안내가 따라붙어야 한다. KRDS가 단순히 값만 제시하지 않고 ‘언제 어떻게 쓰는지’를 함께 설명하는 이유가 여기에 있다. 토큰은 ‘값 + 의미 + 사용법’이 한 묶음일 때 비로소 살아 있는 시스템이 된다.

이 세 함정의 공통점은, 토큰이 ‘한 번 만들고 끝나는 것’이 아니라 ‘계속 가꿔야 하는 정원’이라는 점을 일깨운다. 잡초(직접 박은 값)를 뽑고, 너무 무성해진 가지(과잉 토큰)를 치고, 어디에 무엇을 심었는지 팻말(문서)을 붙이는 일을 꾸준히 해야 토큰 체계가 건강하게 유지된다. 그리고 이 ‘건강 상태’를 가늠하는 가장 좋은 지표가 바로 다음에 이야기할 토큰 채택률이다.

■ 토큰 채택률 — 잘 지키고 있는지 ‘숫자’로 보기

여기서 오늘의 홍보 훅인 ‘토큰 채택률’ 이야기를 꺼낼 차례다. 토큰을 정해두는 것과, 그 토큰이 실제로 사이트 곳곳에서 ‘제대로 쓰이고 있는가’는 별개의 문제다. 멋지게 토큰 체계를 만들어두고도, 실제 페이지에서는 여전히 헥스 코드를 직접 박은 ‘예외’가 수두룩한 경우가 흔하다. 그래서 필요한 게 ‘토큰 채택률’이라는 지표다.

토큰 채택률은 쉽게 말해 ‘화면에 쓰인 색·글자·간격 중에서 정해둔 토큰을 따른 비율’이다. 예를 들어 색의 토큰 채택률이 70%라면, 화면에 등장한 색 가운데 70%는 정의된 토큰을 쓰고 있고 30%는 토큰 밖의 ‘떠돌이 값’이라는 뜻이다. 이 30%가 바로 일관성을 좀먹고, 나중에 ‘색 하나 바꾸는 데 3주’를 만드는 주범이다. 채택률을 측정하면 ‘우리 토큰이 종이 위 약속으로만 남았는지, 실제로 화면을 지배하고 있는지’가 숫자로 드러난다.

문제는 이 채택률을 사람이 손으로 재기가 거의 불가능하다는 점이다. 한 사이트에 페이지가 수백 개고, 각 페이지마다 색·글자·간격이 수십 군데 쓰인다. 이걸 사람이 일일이 눈으로 보고 ‘이건 토큰, 이건 떠돌이 값’으로 분류하려면 평생 걸린다. 그래서 토큰 채택률은 ‘자동 진단’의 영역이다. 도구가 페이지의 실제 스타일 값을 전부 긁어와, 정의된 토큰 목록과 대조해 ‘몇 %가 토큰을 따랐는지’를 계산해준다. 사람은 그 숫자를 보고 ‘어느 영역의 채택률이 낮은지’를 파악해 개선 우선순위를 잡으면 된다.

【본론 4 — 토큰이 KRDS 전체에서 갖는 위치】

■ 토큰은 846규칙의 ‘1층’이다

지금까지 색·글자·간격 토큰을 따로따로 봤는데, 한 발 물러서서 KRDS 전체 그림에서 토큰이 어디에 위치하는지 보자. KRDS는 846개 규칙으로 이루어지고, 크게 네 영역으로 나뉜다. DS(디자인 시스템 기반 요소) 약 120개, CP(컴포넌트) 약 446개, BP(기본 패턴) 약 108개, SP(서비스 패턴) 약 172개. 합치면 정확히 846이다.

토큰은 이 중 가장 밑바닥인 DS 영역의 핵심이다. 비유하자면 토큰은 건물의 ‘1층이자 기초’다. DS라는 기초 위에 CP라는 부품이 세워지고, 부품이 모여 BP라는 패턴이 되고, 패턴이 이어져 SP라는 서비스가 완성된다. 색 토큰(DS)이 정해져야 버튼(CP)에 색을 입힐 수 있고, 버튼이 있어야 폼 입력 흐름(BP)이 굴러가고, 그 흐름들이 모여야 민원신청 서비스(SP)가 완성된다. 그래서 토큰이 흔들리면 그 위에 쌓인 모든 게 함께 흔들린다. ‘기초 공사’인 셈이다.

이걸 거꾸로 말하면, 토큰만 잘 잡아도 위쪽 영역의 일관성이 자동으로 따라온다는 뜻이기도 하다. 버튼·카드·입력칸이 전부 같은 색 토큰·간격 토큰을 참조하면, 굳이 부품 하나하나를 일일이 통일하지 않아도 ‘기초가 같으니 결과가 비슷’해진다. 그래서 KRDS 적용을 시작하는 기관에 ‘토큰부터 잡으라’고 권하는 것이다. 위에서부터 손대면 끝이 없지만, 기초부터 다지면 위쪽이 함께 정돈된다. 디자인 시스템 도입의 가성비가 가장 높은 지점이 바로 토큰이다.

■ 토큰이 주는 진짜 이득 — 시간·신뢰·접근성

토큰을 도입하면 얻는 이득을 세 가지로 정리해보자. 첫째는 ‘시간’이다. 반복 결정이 사라지고, 변경이 한 곳에서 끝난다. 색 하나 바꾸는 3주가 반나절이 되고, 본문 글자 키우는 작업이 한 줄이 된다. 새 페이지를 만들 때마다 ‘색 뭐 쓸까, 간격 얼마 줄까’를 고민하지 않아도 되니 제작 속도도 빨라진다. 아낀 시간은 ‘정말 고민해야 할 것’ — 이 페이지에서 국민이 뭘 하려는지, 어떻게 하면 덜 헤맬지 — 에 쓸 수 있다.

둘째는 ‘신뢰’다. 사이트 전체가 같은 색·글자·간격으로 통일되면, 사용자는 ‘여기는 한 기관의 공식 창구다’라는 안정감을 느낀다. 페이지마다 분위기가 제각각인 사이트는 ‘여기가 진짜 그 기관 맞나’라는 막연한 불안을 주는데, 토큰으로 통일된 사이트는 그 불안을 없앤다. 일관성은 단지 ‘예뻐 보임’이 아니라 ‘믿을 수 있음’의 시각적 증거다. 개인정보를 입력하거나 민원을 신청하는 화면일수록 이 신뢰의 무게는 커진다.

셋째는 ‘접근성’이다. 앞서 다크 모드·고대비 모드를 토큰으로 쉽게 다룬다고 했는데, 이게 곧 접근성으로 이어진다. 저시력 사용자를 위한 고대비 테마, 글자를 키워 쓰는 고령 사용자, 색 구분이 어려운 사용자… 이 모두를 토큰 구조 위에서 훨씬 수월하게 대응할 수 있다. 색 토큰의 명도 단계가 정리돼 있으면 ‘배경과 글자의 대비가 충분한가’를 미리 검증해둘 수 있고, 그 검증은 웹접근성 KWCAG 33항목 중 색 대비 관련 항목을 충족하는 데 직접 보탬이 된다. 토큰은 멋을 위한 장치가 아니라, ‘누구나 쓸 수 있게’라는 공공 웹의 본질을 떠받치는 토대다.

■ 토큰과 ‘한 사람 천재’ 문제

공공기관의 가장 큰 숙제 중 하나가 ‘담당자 교체’다. 디자인 감각이 좋은 담당자가 한 명 있으면 그 사람이 있는 동안은 사이트가 그럴듯하다. 문제는 그 사람이 부서를 옮기거나 그만두는 순간이다. 후임자는 ‘전임자가 무슨 기준으로 만들었는지’를 알 길이 없어서, 또 자기 감각으로 새로 만들기 시작한다. 그렇게 사이트는 담당자가 바뀔 때마다 조금씩 다른 얼굴이 되어간다.

토큰은 이 ‘한 사람 천재’ 의존을 끊는 장치다. 전임자의 감각이 ‘주-색상’ ‘본문 = 16px’ ‘간격은 8의 배수’ 같은 토큰으로 박제되어 있으면, 후임자는 그 감각을 그대로 물려받아 일할 수 있다. 감각이 ‘사람의 머릿속’이 아니라 ‘조직의 자산’으로 옮겨가는 것이다. 신입이 와도, 외주가 바뀌어도 일정 수준 이상이 보장되는 건 이 때문이다. 토큰은 ‘누구나 같은 결과를 내게 하는’ 평준화 장치인 동시에, 잘 만든 결과를 ‘떠나지 않게 붙잡아두는’ 보존 장치이기도 하다.

이걸 회사의 업무 매뉴얼에 빗대면 이해가 쉽다. 일 잘하는 직원의 노하우가 그 사람 머릿속에만 있으면, 그가 떠나는 순간 조직의 역량이 뚝 떨어진다. 하지만 그 노하우가 매뉴얼로 정리돼 있으면 누구든 일정 수준으로 일할 수 있다. 디자인 토큰은 ‘디자인 노하우의 매뉴얼화’다. 담당자 교체가 잦은 공공 조직일수록, 이 매뉴얼화의 가치는 민간보다 훨씬 크다.

■ 토큰이 만드는 ‘체감되지 않는 좋음’

토큰이 잘 적용된 사이트의 특징은 역설적이게도 ‘티가 안 난다’는 것이다. 사용자는 ‘이 사이트 색이 일관되네’라고 의식적으로 칭찬하지 않는다. 다만 헤매지 않고, 답답하지 않고, 불안하지 않을 뿐이다. 좋은 디자인은 ‘좋다’고 느껴지기보다 ‘아무 문제 없이 자연스럽게 쓰인다’. 토큰은 바로 이 ‘체감되지 않는 좋음’을 만드는 토대다.

반대로 토큰이 없는 사이트의 문제는 ‘콕 집어 말하기 어려운 불편’으로 나타난다. 사용자는 ‘왜인지 모르게 이 사이트는 좀 불편해’라고만 느낀다. 정확히 색이 일곱 종이라서, 글자가 페이지마다 달라서, 여백이 들쭉날쭉해서라고 설명하지 못한다. 그래서 이 불편은 민원으로도 잘 안 올라오고, 개선 우선순위에서도 자꾸 밀린다. ‘눈에 띄는 고장’이 아니라 ‘스며든 불편’이기 때문이다.

토큰 채택률이라는 지표가 의미 있는 이유가 여기에 있다. 이 ‘스며든 불편’을 숫자로 끌어내 보이게 만들기 때문이다. ‘색 토큰 채택률 62%’라는 숫자가 나오면, 비로소 ‘아, 우리 사이트의 막연한 불편함이 여기서 나왔구나’를 손에 잡히게 인식할 수 있다. 보이지 않던 문제가 숫자로 보이는 순간, 비로소 개선이 시작된다. 측정은 개선의 출발점이고, 토큰 채택률은 그 측정을 가능하게 하는 자다.

【본론 5 — 자주 받는 질문 정리】

■ “디자이너가 없는데 토큰을 정할 수 있나요?”

가장 많이 받는 질문이다. 답은 ‘처음부터 직접 정할 필요가 없다’다. KRDS가 공공 웹에 맞는 토큰 체계를 이미 정리해두었기 때문에, 기관은 그것을 ‘가져다 맞추는’ 방식으로 시작하면 된다. 바닥부터 색 팔레트와 타입 스케일을 설계하는 건 전문 디자이너의 영역이지만, ‘잘 된 표준을 따라 정리하는 일’은 담당자도 충분히 주도할 수 있다. 오히려 디자이너가 없는 조직일수록, 의지할 수 있는 공식 기준의 가치가 더 크다.

■ “이미 만든 사이트도 다 바꿔야 하나요?”

아니다. 앞서 말한 단계적 전략대로 가면 된다. 새로 만드는 부분부터 토큰을 적용하고, 기존 부분은 개편·유지보수 시점에 맞춰 점진적으로 옮긴다. 한 번에 다 바꾸려다 사고 나는 것보다, 자주 쓰는 페이지부터 차근차근 옮기는 게 안전하고 효과도 빨리 체감된다. 토큰 전환은 ‘완벽한 한 방’이 아니라 ‘꾸준한 정리’의 문제다.

■ “토큰을 쓰면 우리 기관 개성이 사라지지 않나요?”

그렇지 않다. 토큰은 ‘구조와 일관성’을 위한 장치이지, ‘개성을 지우는’ 장치가 아니다. 기관의 상징색은 ‘주-색상’ 토큰에 그대로 담으면 되고, 기관 고유의 콘텐츠와 분위기는 얼마든지 살아 있다. 토큰이 통일하는 건 ‘색을 관리하는 방식’이지 ‘색 자체’가 아니다. 표준 양식으로 문서를 쓴다고 글의 내용이 똑같아지지 않는 것과 같다. 공통 토대 위에서 각 기관의 얼굴은 충분히 표현된다.

■ “개발자랑 디자이너만 알면 되는 거 아닌가요?”

토큰을 ‘기술적인 것’으로 여겨 담당자가 손을 떼는 경우가 많은데, 이건 오해다. 토큰은 만들기는 디자이너·개발자가 하더라도, ‘무엇을 기준으로 만들지 정하고, 제대로 지켜지는지 확인하는’ 건 결국 발주처인 담당자의 몫이다. 토큰이 무엇인지 모르면 “토큰 채택률이 낮으니 정리해주세요” 같은 정확한 요구를 할 수 없고, 정확한 요구를 못 하면 업체가 하는 말을 검증할 수 없어 끌려다니게 된다. 토큰을 안다는 건 직접 색을 고르는 능력이 아니라, ‘제대로 된 디자인 관리를 요구하고 확인하는’ 발주·검수 능력의 문제다. 그래서 디자인 비전공자인 담당자야말로 토큰 개념을 알아둘 가치가 가장 크다.

■ “토큰 도입에 돈이 많이 드나요?”

‘새로 큰 사업을 발주해야 하는 것 아니냐’는 걱정이 흔한데, 꼭 그렇지 않다. 토큰 도입은 ‘별도의 거대 프로젝트’가 아니라 ‘앞으로의 작업 방식을 바꾸는 일’에 가깝다. 새 페이지를 만들 때 토큰을 쓰도록 약속하고, 기존 페이지는 어차피 하게 될 개편·유지보수 때 함께 정리하면, 추가 비용이 거의 들지 않으면서도 시간이 갈수록 토큰화된 비율이 늘어난다. 오히려 토큰이 자리 잡으면 변경 작업이 싸지고 빨라져서, 길게 보면 비용을 ‘줄이는’ 쪽이다. ‘색 하나 바꾸는 데 3주’가 ‘반나절’로 줄어든 만큼이 곧 절약이다. 토큰은 지출이 아니라 투자에 가깝다.

■ “채택률 숫자가 낮으면 안 좋은 건가요?”

낮다고 ‘틀린’ 게 아니라, ‘개선 여지가 보인다’고 받아들이는 게 맞다. 처음 측정하면 채택률이 낮게 나오는 게 당연하다. 토큰 없이 만들어온 사이트라면 떠돌이 값이 많을 수밖에 없으니까. 중요한 건 ‘지금 몇 %냐’보다 ‘어느 영역이 낮고, 어디부터 올릴 수 있느냐’다. 채택률은 점수표가 아니라 지도다. 어디를 손보면 일관성이 가장 많이 오를지를 알려주는 안내판으로 쓰면 된다. 그리고 채택률이 한 번 측정되고 나면, 다음 개편 후 다시 재서 ‘얼마나 좋아졌는지’를 비교할 수 있다. 막연히 ‘개선했다’가 아니라 ‘62%에서 84%로 올랐다’처럼 성과를 숫자로 보고할 수 있게 되는 것이다. 이건 윗선 보고나 사업 성과 정리에서도 든든한 근거가 된다. 느낌이 아니라 숫자로 말할 수 있다는 건, 담당자에게 의외로 큰 힘이다.

【 마무리 】

여기까지 따라온 분이라면, 글 첫머리의 ‘그 파란색 코드값이 뭐예요?’라는 질문이 이제 다르게 들릴 거다. 토큰이 없는 사이트에선 이 질문에 답이 일곱 개쯤 나오고, 토큰이 있는 사이트에선 ‘주-색상이요’ 한마디로 끝난다. 디자인 토큰은 결국 ‘디자인의 기본 재료에 이름표를 붙여, 한 곳에서 관리하기로 한 약속’이다. 색은 ‘무엇을 위한 색’인지, 글자는 ‘어떤 위계의 글자’인지, 간격은 ‘어떤 격자 위의 간격’인지 — 숫자가 아니라 의미로 부르기로 한 것이다.

이 단순한 약속 하나가 일관성·유지보수·신뢰·접근성을 동시에 끌어올린다. 색 하나 바꾸는 3주가 반나절이 되고, 페이지마다 들쭉날쭉하던 글자가 한 호흡으로 정리되고, 어중간하던 여백이 같은 박자로 맞아 들어간다. 그리고 무엇보다, ‘누가 만들든 일정 수준 이상’을 보장한다. 담당자가 바뀌고 외주가 교체돼도 토대가 흔들리지 않는다. 공공기관처럼 담당자 교체가 잦은 조직에서 이건 특히 큰 의미가 있다.

KRDS는 이 토큰을 846규칙의 가장 밑바닥 기초로 삼는다. 그래서 KRDS 적용을 시작한다면, 화려한 부품이나 복잡한 서비스 흐름보다 ‘토큰부터’ 잡는 게 가성비가 가장 높다. 기초가 단단하면 그 위는 함께 정돈되기 때문이다.

그런데 여기서 한 가지, ‘우리가 정한 토큰이 실제 화면에서 제대로 지켜지고 있는가’는 눈으로 봐선 알기 어렵다. 수백 페이지에 흩어진 색·글자·간격을 사람이 일일이 세어 ‘토큰 채택률’을 계산하는 건 사실상 불가능하다. 그래서 우리는 이 측정을 자동으로 해주는 도구를 만들었다. ViewCheck는 공공 웹사이트의 URL만 넣으면, 페이지의 실제 스타일 값을 긁어와 KRDS 토큰 체계와 대조하고, ‘디자인 시스템 탭’에서 디자인 토큰 채택률을 한눈에 보여준다. 색·글자·간격이 각각 토큰을 얼마나 따르고 있는지, 어디에 ‘떠돌이 값’이 숨어 있는지를 숫자와 함께 짚어준다. KRDS 846규칙 전체에 대한 진단도 함께 제공해서, 토큰이라는 기초부터 부품·패턴·서비스까지 한 번에 현황을 파악할 수 있다.

‘우리 사이트의 토큰 채택률은 몇 %일까?’가 궁금하다면, 굳이 결재를 받거나 사업을 발주하지 않아도 지금 이 자리에서 바로 확인할 수 있다. 무언가를 결심하기 전에, 먼저 ‘지금 우리가 어디쯤 있는지’를 아는 게 순서다. 첫 화면 상단의 점수 카드만 봐도 ‘아, 우리가 생각보다 떠돌이 값이 많았구나’ 혹은 ‘생각보다 잘 지키고 있었네’를 바로 알 수 있다. 그 숫자가 다음 개편을 어디서부터 시작할지에 대한 가장 정직한 출발점이 되어줄 거다. 진단 결과 상단의 점수 카드는 색·글자·간격이 KRDS 토큰을 얼마나 따르는지를 영역별로 보여주니, 회의 자료로 바로 캡처해 쓰기에도 좋다.

다음 글에서는 오늘 맛만 본 ‘색 토큰’을 한 걸음 더 깊이 들어가, 공공 웹에서 색을 역할별로 어떻게 설계하고 대비 기준을 어떻게 맞추는지를 다룰 예정이다. 오늘 ‘토큰? 별거 아니네’ 하고 감을 잡으셨다면, 다음 글은 ‘그래서 색을 이렇게 짜는구나’로 이어질 거다. 색·글자·간격을 변수로 관리한다는 이 단순한 발상이, 공공 웹을 얼마나 단단하게 바꿔놓는지 — 이번 한 달 동안 차근차근 함께 보시면 좋겠다.

키워드/태그: #KRDS #디자인토큰 #디자인시스템 #공공웹 #공공웹디자인 #디자인일관성 #토큰채택률 #웹접근성 #전자정부 #UIUX #공공기관홈페이지 #ViewCheck

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