토큰 없이 하드코딩한 색상, 리뉴얼 때 지옥 된다

토큰 없이 하드코딩한 색상, 리뉴얼 때 지옥 된다

---

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

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

【 공감·문제제기 】

월요일 글에서는 ‘디자인 토큰이 대체 뭐냐’를 큰 그림으로 풀었다. 색·글꼴·간격 같은 값에 이름을 붙여서 한곳에서 관리하는 약속, 그게 토큰이라고 말이다. 오늘은 그 반대편 이야기를 하려고 한다. 토큰 없이, 그냥 색깔 코드를 화면마다 손으로 박아 넣으면 — 그러니까 ‘하드코딩’을 하면 — 나중에 어떤 일이 벌어지는지. 솔직히 말하면 이건 내가 현장에서 가장 자주 마주치는 풍경이고, 동시에 가장 안타까운 풍경이기도 하다.

먼저 고백 하나 하고 시작하자. 나도 예전엔 색을 그냥 박았다. 부끄럽지만 사실이다. 페이지 하나 급하게 만들 때, ‘파랑이 필요하네’ 싶으면 머릿속에 떠오르는 파랑 코드를 그 자리에 그냥 적었다. 그게 잘못이라고 생각하지도 않았다. 화면에 파랑이 잘 나오면 된 거 아닌가? 당장은 멀쩡해 보였으니까. 문제는 그 ‘당장’이 영원히 지속되지 않는다는 거였다. 1년쯤 지나 그 사이트를 다시 손볼 일이 생겼을 때, 나는 내가 무슨 짓을 했는지 알게 됐다. 비슷비슷한 파랑이 사이트 곳곳에 수십 개 박혀 있었고, 그게 다 미묘하게 달랐다. 그날 이후로 나는 색을 손으로 박는 걸 그만뒀다.

오늘 글은 그래서 일종의 ‘예방 접종’ 같은 글이다. 토큰을 안 쓰면 어떤 병에 걸리는지를 미리 보여줘서, ‘아 저건 걸리지 말아야겠다’고 마음먹게 하는 글. ○○시, A광역지자체, 중앙부처, B공공기관, C기관 — 익명으로 바꾼 여러 현장 사례를 통해, 하드코딩이 만들어내는 ‘리뉴얼 지옥’을 최대한 생생하게 그려보려 한다. 특정 기관을 흉보려는 게 절대 아니다. 이건 누구나, 정말 거의 모두가 한 번쯤 빠지는 함정이라서, 흉볼 자격이 있는 사람이 별로 없다.

그리고 미리 짚어두고 싶은 게 하나 더 있다. 사이트가 망가지는 건 대부분 ‘한 방에 크게’가 아니다. 오히려 ‘조금씩, 티 안 나게’ 망가진다. 처음 만들 때는 그럭저럭 괜찮았는데, 시간이 지나면서 부서별 콘텐츠가 쌓이고, 새 사업 페이지가 붙고, 일부만 개편되면서 — 어느 순간 정신 차려보니 사이트가 누더기가 돼 있다. 큰 사고처럼 빨간불이 켜지는 게 아니라, 사용자가 ‘뭔가 좀 불편한데 왜인지는 모르겠네’ 하고 조용히 떠나버리는 식으로 손해가 난다. 그래서 담당자 입장에서는 문제가 있다는 걸 인지하기조차 어렵다. 민원이 들어오는 것도 아니고, 통계에 ‘색이 일관되지 않아 이탈했습니다’라고 찍히는 것도 아니니까. 오늘 글의 목적은 그 ‘조용한 손해’를 눈에 보이게 만드는 거다. 보이기 시작해야 고칠 마음이 생긴다.

한 가지 미리 말해두면, 하드코딩의 무서움은 ‘처음엔 아무 문제가 없다’는 데 있다. 색을 박은 그날, 그 다음 주, 심지어 그 해 내내 아무 일도 안 일어난다. 화면은 잘 나오고, 사용자도 불만이 없다. 그래서 우리는 ‘이거 괜찮네’ 하고 안심한다. 문제는 시간이 지나 ‘색을 바꿔야 하는 순간’이 왔을 때다. 그 순간이 오기 전까지 하드코딩은 완벽하게 숨어 있다가, 그 순간이 오는 즉시 청구서로 날아온다. 마치 무이자 할부처럼 보이지만 사실은 만기에 원금이 폭탄으로 터지는 금융 상품 같달까. 오늘 이 글은 그 ‘숨어 있는 청구서’를 미리 꺼내 보여주는 글이다.

그리고 솔직히, 이 청구서는 생각보다 자주 날아온다. ‘색 바꿀 일이 뭐 그렇게 자주 있겠어’ 싶겠지만, 공공 사이트는 의외로 색을 바꿀 일이 많다. 기관이 통합되거나 분리되고, 상위 기관의 브랜드 가이드가 개정되고, CI(기업·기관 이미지)가 리뉴얼되고, 캠페인 테마 컬러가 바뀌고, 다크 모드를 도입하라는 지침이 내려오고… 이 모든 게 ‘색을 한 번에 바꿔야 하는’ 사건이다. 그때마다 하드코딩한 사이트는 비명을 지른다. 반면 토큰으로 관리한 사이트는 변수 하나 고치고 점심 먹으러 간다. 그 차이를 오늘 끝까지 보여주겠다.

조금 더 솔직하게 덧붙이면, 나는 ‘색을 박는 습관’이 단순히 게으름의 문제라고 생각하지 않는다. 오히려 그 반대다. 마감이 코앞이고, 화면은 당장 떠야 하고, 윗선은 ‘언제 올라가냐’고 묻는 상황에서 — 색 하나를 ‘제대로 토큰으로 정의하고 참조하는’ 정석을 밟는 건 사치처럼 느껴진다. ‘일단 박고 나중에 정리하자’가 가장 합리적인 선택처럼 보인다. 그게 바로 함정이다. 빚이 합리적으로 보이는 순간, 우리는 빚을 진다. 그리고 그 ‘나중’은 좀처럼 오지 않는다. 새 마감이 또 오고, 또 다른 화면을 또 박고, 그렇게 부채만 차곡차곡 쌓인다. 그래서 나는 하드코딩을 ‘잘못’이라기보다 ‘구조적으로 유도되는 함정’이라고 부른다. 개인을 탓할 일이 아니라, 함정의 구조를 알고 미리 피해야 할 일이다.

이 글을 끝까지 읽고 나면, 적어도 그 함정의 모양은 또렷이 보일 거다. 함정이 어떻게 생겼는지 알면, 다음번에 ‘일단 박자’는 유혹이 올 때 ‘아, 이게 그 함정이지’ 하고 한 번 멈칫하게 된다. 그 멈칫 한 번이 5년 뒤의 3주짜리 대공사를 막는다. 오늘 글의 진짜 목적이 바로 그 ‘멈칫’을 심어주는 데 있다.

【본론 1 — 하드코딩이란 정확히 무슨 상태인가】

■ ‘색을 박는다’는 게 왜 문제인가

먼저 용어부터 정리하자. ‘하드코딩(hard-coding)’은 값을 ‘딱딱하게’ 코드 안에 직접 적어 넣는 걸 말한다. 색으로 치면, ‘이 버튼의 색은 #1F4E79’라고 그 버튼이 있는 자리에 직접 박는 거다. 반대로 토큰을 쓰면 ‘이 버튼의 색은 우리 브랜드 주색’이라고 적고, ‘브랜드 주색이 정확히 무슨 값인지’는 딱 한 곳에서 따로 정의한다. 둘의 차이는 작아 보이지만, 시간이 지나면 천지차이가 된다.

비유를 하나 들어보자. 하드코딩은 친구 전화번호를 외우는 것과 같다. 토큰은 그 번호를 ‘민수’라는 이름으로 연락처에 저장해두는 것과 같다. 친구가 한 명일 땐 별 차이가 없다. 근데 친구가 100명이고, 그중 한 명이 번호를 바꿨다고 생각해보자. 연락처에 저장해뒀으면 그 한 명의 번호만 고치면 끝이다. 그런데 번호를 일일이 종이에, 수첩에, 메모장에, 다른 친구에게 보낸 문자 안에 다 적어뒀다면? 그 친구 번호가 적힌 곳을 전부 찾아다니며 고쳐야 한다. 그러다 한 군데를 빠뜨리면, 나중에 그 옛날 번호로 전화를 걸어 엉뚱한 사람을 깨우게 된다. 하드코딩한 색이 정확히 이렇게 동작한다.

여기서 핵심은 ‘값이 흩어져 있다’는 점이다. 같은 색이 사이트 곳곳에, 같은 의미인데도 각자 따로 적혀 있다. 그래서 그 색을 바꾸려면 ‘그 색이 적힌 모든 곳’을 찾아야 하는데, 문제는 그게 어디어디인지 아무도 모른다는 거다. 사이트를 만든 사람이 이미 퇴사했거나, 외주가 끝났거나, 시간이 너무 지나 기억이 안 난다. 그래서 ‘전수조사’부터 해야 한다. 색 하나 바꾸는 데 ‘조사’가 필요하다는 게 이미 비정상인데, 하드코딩한 사이트에서는 이게 정상이 된다.

이 ‘흩어짐’을 조금 더 구체적으로 그려보자. 색은 한 곳에만 적히지 않는다. 어떤 색은 화면 디자인 파일 안에, 어떤 색은 스타일 정의 파일 안에, 어떤 색은 페이지마다 따로 붙은 인라인 코드 안에, 어떤 색은 관리자가 글을 올릴 때 쓰는 편집기 설정 안에, 또 어떤 색은 외부에서 가져온 위젯의 내부에 박혀 있다. 같은 ‘우리 기관 파랑’이 다섯 군데 서로 다른 방식으로 박혀 있는 거다. 그러니 ‘색을 바꾼다’는 건 이 다섯 군데를 전부 찾아 각각 다른 방식으로 고친다는 뜻이 된다. 그중 하나라도 빠뜨리면 ‘대부분은 새 색인데 한 군데만 옛날 색’인 어색한 화면이 남는다. 이게 하드코딩이 만드는 ‘영원히 끝나지 않는 술래잡기’다.

그리고 한 가지 더. 하드코딩한 색은 ‘검색’으로도 잘 안 잡힌다. 같은 파랑이라도 어떤 곳은 코드 한 형식으로, 어떤 곳은 다른 형식으로 적혀 있어서, ‘이 코드를 찾아 바꿔라’라는 단순 치환이 안 통한다. 게다가 미세하게 다른 값이 섞여 있으니, 정확히 그 값을 검색해도 ‘비슷하지만 한 글자 다른’ 색들은 그물을 빠져나간다. 결국 사람이 눈으로 화면을 하나하나 보며 ‘이건 우리 파랑이 맞나’를 판정하는 수밖에 없다. 자동화가 안 되는 단순 노동, 그게 하드코딩이 만드는 가장 비싼 비용이다.

■ ‘비슷한 색’이 가장 위험하다

여기서 사람들이 잘 모르는 함정이 하나 있다. 완전히 다른 색이 섞이는 건 차라리 눈에 띈다. 진짜 위험한 건 ‘비슷한 색’이다. 사람 눈에는 다 똑같은 파랑인데, 코드로는 미세하게 다른 파랑이 수십 종 박혀 있는 상태. 이게 가장 고치기 어렵다.

왜냐하면 ‘틀린 색’을 찾을 수가 없기 때문이다. 색이 명백히 빨강과 파랑으로 갈렸으면 ‘어, 여긴 색이 잘못됐네’ 하고 바로 안다. 그런데 다 비슷한 파랑이면, 코드를 일일이 뜯어보기 전엔 어떤 게 ‘진짜 우리 색’이고 어떤 게 ‘눈대중으로 박은 가짜’인지 구분이 안 된다. 사람 눈은 미세한 색 차이를 잘 못 잡는다. 특히 모니터가 다르면 같은 코드도 다르게 보이고, 다른 코드도 같아 보인다. 그래서 ‘비슷한 색의 난립’은 만들 때도 모르고, 쓸 때도 모르고, 고치려고 들여다볼 때 비로소 ‘아, 이게 다 다른 색이었구나’ 하고 경악하게 된다.

한 광역지자체(A광역지자체로 부르자) 사이트를 점검한 적이 있다. 메인 색이 파랑인 곳이었는데, 코드를 분석해보니 사이트 전체에서 ‘파랑 계열’만 마흔 종이 넘게 나왔다. 헤더의 파랑, 버튼의 파랑, 링크의 파랑, 강조 박스의 파랑, 푸터의 파랑 — 다 ‘우리 기관 파랑’이라고 생각하고 박은 건데, 정작 같은 값은 거의 없었다. 담당자분께 이걸 보여드렸더니 “저는 다 같은 색인 줄 알았는데요”라고 하셨다. 그게 정상적인 반응이다. 눈으로는 정말 같아 보이니까. 문제는 컴퓨터한테는 다 다른 색이라, 나중에 ‘우리 파랑을 한 톤 밝게 바꾸자’는 결정이 내려졌을 때 ‘그 파랑’이 어느 파랑인지 특정할 수가 없었다는 거다.

이게 왜 이렇게까지 되는지 원리를 짚어보자. 사람의 눈은 색을 ‘절대값’으로 기억하지 못한다. 우리는 ‘파랑’이라는 범주로 기억할 뿐, 그게 정확히 어느 파랑인지는 못 외운다. 게다가 모니터마다 색을 다르게 보여주고, 같은 모니터도 밝기 설정에 따라 다르게 보인다. 사무실 형광등 아래서 고른 파랑과 집에서 어두운 조명 아래 고른 파랑이 다른데, 본인은 ‘같은 파랑’이라고 믿는다. 그래서 ‘눈대중으로 색을 고르는’ 방식은 본질적으로 일관성을 가질 수 없다. 아무리 꼼꼼한 사람이라도, 기준이 머릿속에만 있으면 그 기준은 매번 미세하게 흔들린다.

여기서 흥미로운 건, 이걸 만든 사람들 중 누구도 ‘색을 망치자’고 생각하지 않았다는 점이다. 다들 그 순간엔 ‘이 정도 파랑이면 우리 사이트랑 어울리겠지’라고 최선을 다해 골랐다. 문제는 ‘기준이 머릿속에만 있었다’는 거다. 이렇게 각자의 머릿속 기준으로 만든 결과물이 모이면, 개별로는 다 그럴듯한데 전체로는 제각각인 사이트가 된다. 그래서 색은 ‘잘 고르는 능력’의 문제가 아니라 ‘하나의 기준을 사람 바깥에 저장하고 공유하느냐’의 문제다. 토큰은 바로 그 ‘사람 바깥에 저장된 기준’이다. 머릿속 파랑은 흔들려도, 한 곳에 적힌 ‘브랜드-주색’은 흔들리지 않는다.

또 하나 무서운 점. A광역지자체의 그 마흔 종 파랑은 ‘한 번에 생긴’ 게 아니다. 5년, 10년에 걸쳐 한 종씩, 한 종씩 늘어난 거다. 매번 ‘파랑 하나 더 박는’ 그 순간엔 아무도 문제를 못 느꼈다. ‘기존에 비슷한 파랑이 있겠지만 찾기 귀찮으니 그냥 새로 박자’가 반복됐을 뿐이다. 한 번의 ‘귀찮음’이 한 종의 부채를 낳고, 그게 마흔 번 반복돼 마흔 종이 됐다. 부채는 이렇게 ‘아주 작은 편의’가 누적된 결과다. 그래서 더 무섭다. 큰 결정이 아니라 사소한 편의들이 쌓여 만든 산이라, 어디서부터 잘못됐는지조차 짚기 어렵다.

■ 하드코딩은 ‘디자인 부채’를 무제한으로 쌓는다

이걸 흔히 ‘디자인 부채(design debt)’라고 부른다. 빚처럼 처음엔 작지만 이자가 붙어 점점 커진다는 비유다. 하드코딩은 이 부채를 한도 없이 쌓을 수 있는 신용카드 같은 거다. 색을 박을 때마다 ‘작은 빚’이 하나 생긴다. 그 빚은 박는 순간엔 공짜처럼 느껴지지만, 나중에 그 색을 건드려야 할 때 이자까지 붙여서 갚아야 한다.

부채의 무서운 점은 ‘복리’다. 색이 제각각인 사이트에 새 페이지를 하나 추가한다고 해보자. 그 새 페이지를 만드는 사람은 ‘기존 페이지의 파랑’을 참고하려는데, 기존 파랑이 마흔 종이니 어느 걸 따라야 할지 모른다. 그래서 또 ‘대충 비슷한 파랑’을 골라 박는다. 부채가 한 종 더 늘었다. 즉 부채가 있는 상태에서 만드는 모든 새 작업이 부채를 더 키운다. ‘나중에 한 번에 정리하자’는 생각이 거의 항상 실패하는 이유가 여기 있다. 정리하기로 마음먹은 그 ‘나중’이 올 때쯤이면 부채가 두세 배로 불어 있다.

그리고 디자인 부채에는 ‘숨은 이자’가 하나 더 있다. 사람의 피로다. 색이 통제 불능인 사이트를 운영하는 담당자는 새 페이지 하나 올릴 때마다 ‘무슨 파랑을 써야 하지’를 고민하느라 지친다. 윗선에서 ‘왜 이렇게 들쭉날쭉하냐’는 지적을 받으면 마음이 무겁고, 그렇다고 정리하자니 엄두가 안 난다. 부채는 사이트만 망가뜨리는 게 아니라 그걸 다루는 사람의 의욕까지 함께 갉아먹는다. 잘 정리된 토큰 하나가 담당자에게 주는 가장 큰 선물은, 어쩌면 ‘매번 색을 고민하지 않아도 되는 편안함’일지 모른다.

【본론 2 — 리뉴얼 지옥의 실제 풍경 (익명 사례)】

■ 사례 1: ‘파랑 한 톤만 밝게’가 3주짜리 대공사가 된 A광역지자체

A광역지자체 이야기를 조금 더 해보자. 상급 기관의 브랜드 가이드가 개정되면서, ‘기관 대표 파랑을 한 톤 밝게’ 바꾸라는 지침이 내려왔다. 디자인적으로는 정말 사소한 변경이다. 색 하나, 그것도 ‘조금 밝게’. 토큰으로 관리했다면 정의 한 줄 고치고 끝났을 일이다.

그런데 이 사이트는 색이 전부 하드코딩돼 있었다. 그래서 작업이 이렇게 흘러갔다. 먼저 ‘우리 사이트에 파랑이 몇 종이나 박혀 있는지’ 전수조사를 했다. 이것만 며칠이 걸렸다. 그다음, 그 마흔 종의 파랑 중에서 ‘이건 우리 대표 파랑을 의도한 것’과 ‘이건 그냥 장식용 파랑’과 ‘이건 외부에서 가져온 위젯의 파랑’을 구분해야 했다. 코드만 봐서는 구분이 안 되니, 화면을 하나하나 띄워놓고 ‘이 파랑은 무슨 의도였을까’를 추리했다. 이건 거의 고고학 발굴 수준이었다.

구분이 끝났다고 끝이 아니다. 이제 ‘대표 파랑으로 판정된 것들’을 일일이 새 값으로 고친다. 수백 군데다. 그러다 한두 군데 빠뜨리면, 리뉴얼 후 어떤 페이지의 어떤 버튼만 옛날 파랑인 채로 남는다. 그걸 또 사용자나 윗선이 발견하고 ‘여기 색 안 바뀌었어요’ 하고 지적하면, 다시 찾아 고친다. 이 ‘빠뜨림 → 발견 → 수정’의 반복이 몇 주를 잡아먹었다. 결국 ‘색 한 톤 밝게’라는 한 줄짜리 요청이 3주짜리 프로젝트가 됐다.

여기서 가장 뼈아픈 건, 이 3주의 비용이 ‘디자인 작업’이 아니라 ‘찾고 고치고 검수하는 단순 노동’에 쓰였다는 점이다. 새로운 가치를 만든 게 아니라, 과거에 쌓은 부채를 갚느라 시간을 태운 거다. 만약 처음부터 토큰을 썼다면, 그 3주를 사용자에게 더 나은 서비스를 만드는 데 쓸 수 있었을 거다. 부채의 이자는 이렇게 ‘미래에 할 수 있었던 좋은 일’까지 빼앗아 간다.

그리고 이 3주에는 ‘보이지 않는 비용’이 하나 더 숨어 있다. 바로 ‘심리적 위축’이다. 한 번 이런 대공사를 겪고 나면, 담당자는 다음부터 ‘색 바꾸자’는 말 자체를 두려워하게 된다. 윗선에서 ‘파랑 좀 산뜻하게 바꿔보면 어때’라고 가볍게 던져도, 담당자 머릿속엔 지난번 3주짜리 지옥이 떠올라 ‘그건 좀 어렵습니다’가 먼저 나온다. 그래서 마땅히 개선해야 할 것도 ‘건드리면 큰일 난다’는 이유로 방치된다. 하드코딩은 사이트를 ‘바꾸기 어렵게’ 만드는 데 그치지 않고, 사람을 ‘바꾸기 싫어하게’ 만든다. 변화를 두려워하는 조직이 되는 거다. 토큰이 주는 진짜 선물은 ‘색을 쉽게 바꿀 수 있다’가 아니라, ‘색을 바꾸자는 제안을 두려움 없이 할 수 있는 분위기’일지도 모른다.

A광역지자체 담당자분이 작업 막바지에 하셨던 말이 인상 깊었다. “이번에 고생하면서 깨달았어요. 색이 문제가 아니라, 색을 관리할 ‘체계’가 없었던 게 문제였다는 걸요.” 정확한 진단이다. 색 한 톤은 작은 문제다. 그걸 3주짜리 대공사로 키운 건 ‘체계의 부재’였다. 그래서 그 기관은 이번 작업을 끝내면서, 흩어진 파랑을 표준 토큰 한 종으로 모으는 작업을 함께 진행했다. 비싼 수업료를 냈지만, 적어도 다음번엔 같은 지옥을 반복하지 않게 됐다. 부채는 한 번 제대로 갚고, 다시 안 지는 게 핵심이다.

■ 사례 2: 기관 통합으로 색 두 개를 합쳐야 했던 한중앙부처

한중앙부처의 경우는 더 복잡했다. 두 조직이 통합되면서, 한쪽의 색 체계와 다른 쪽의 색 체계를 ‘하나로 합쳐야’ 했다. 새 통합 기관의 대표 색이 정해졌고, 양쪽 사이트의 색을 모두 그 새 색으로 맞춰야 했다.

문제는 양쪽 다 하드코딩 사이트였다는 거다. A쪽 사이트엔 A의 파랑이 제각각 박혀 있고, B쪽 사이트엔 B의 녹색이 제각각 박혀 있었다. 이걸 새 색 하나로 통일하려니, 두 사이트의 ‘색 고고학’을 동시에 진행해야 했다. 게다가 두 사이트는 만든 시기도, 만든 업체도, 코드 구조도 전부 달라서, 한쪽에서 찾은 노하우가 다른 쪽엔 안 통했다.

여기서 진짜 골치 아팠던 건 ‘의미가 충돌하는 색’이었다. A쪽에서는 녹색이 ‘성공/완료’를 뜻했는데, B쪽에서는 녹색이 그냥 ‘기관 대표색’이었다. 두 사이트를 합치면서 이 녹색을 어떻게 처리할지가 문제였다. 만약 토큰으로 ‘성공색’, ‘대표색’이라고 역할에 이름을 붙여 관리했다면, ‘A의 성공색은 그대로 두고, B의 대표색만 새 색으로 바꾼다’가 명확했을 거다. 그런데 둘 다 그냥 ‘#어떤녹색’으로 박혀 있으니, 코드만 봐서는 이 녹색이 ‘성공’인지 ‘대표색’인지 알 수가 없었다. 결국 화면을 하나하나 보며 ‘이 녹색은 무슨 의미였나’를 일일이 판정해야 했다.

이 사례가 주는 교훈은, 하드코딩은 단지 ‘값이 흩어진’ 문제가 아니라 ‘의미가 사라진’ 문제라는 거다. ‘#1F4E79’라는 코드만 봐서는 그게 ‘주요 행동’인지 ‘제목 강조’인지 ‘그냥 장식’인지 알 길이 없다. 반면 토큰으로 ‘주요-행동-색’, ‘제목-강조-색’처럼 이름을 붙여두면, 코드를 읽는 것만으로 ‘이 색이 왜 여기 있는지’가 보인다. 색에 ‘이름’이 있다는 건 색에 ‘의미’가 있다는 거고, 의미가 있어야 나중에 ‘무엇을 어떻게 바꿀지’ 판단할 수 있다. 하드코딩은 그 의미를 통째로 날려버린다.

이 ‘의미의 소실’이 통합 상황에서 얼마나 치명적인지 조금 더 풀어보자. 통합은 단순히 ‘두 사이트를 합치는’ 일이 아니라, ‘두 색 언어를 번역해 하나로 만드는’ 일이다. 번역을 하려면 원문의 ‘뜻’을 알아야 한다. 그런데 하드코딩한 색은 ‘뜻이 적혀 있지 않은 단어’ 같은 거다. ‘#2E7D32’라는 코드는 사전을 찾아도 뜻이 안 나온다. 이게 ‘성공’이라는 뜻인지 ‘기관 정체성’이라는 뜻인지는, 그 단어가 쓰인 ‘문맥(화면)’을 일일이 봐야 알 수 있다. 그러니 통합 작업은 사실상 ‘뜻 없는 단어 수천 개의 의미를 문맥으로 일일이 복원하는’ 번역 작업이 된다. 시간도, 오역의 위험도 폭발한다.

반면 토큰을 쓴 사이트끼리 통합하는 건 ‘뜻이 적힌 사전을 가진 두 언어를 합치는’ 일이다. ‘성공-색’과 ‘대표-색’이라는 이름이 이미 붙어 있으니, ‘성공-색은 양쪽 다 의미가 같으니 통일하고, 대표-색은 새 통합 기관 색으로 바꾼다’가 명확하다. 의미가 보존돼 있으면 통합도 논리적으로 풀린다. 그래서 나는 통합·분리가 잦은 공공기관일수록 토큰이 더 절실하다고 본다. 조직은 합쳐지고 나뉘는데, 그때마다 ‘색 고고학’을 반복할 수는 없는 노릇이니까.

■ 사례 3: 다크 모드 도입에서 무너진 B공공기관

요즘은 ‘다크 모드(어두운 배경 화면)’를 지원하라는 요구가 부쩍 늘었다. 눈의 피로를 줄이고, 야간 사용성을 높이고, 접근성 차원에서도 의미가 있어서다. B공공기관도 그 흐름을 타고 다크 모드를 도입하려 했다.

다크 모드의 핵심은 ‘색을 상황에 따라 바꾸는’ 거다. 밝은 모드에서 흰 배경에 검은 글씨였던 게, 어두운 모드에서는 검은 배경에 흰 글씨로 바뀌어야 한다. 이건 토큰 구조에서는 비교적 자연스럽다. ‘배경색’, ‘글자색’ 같은 역할 토큰을 정의해두고, 모드에 따라 그 토큰이 가리키는 실제 값만 갈아끼우면 되기 때문이다. 토큰이 ‘스위치’ 역할을 한다.

그런데 B공공기관 사이트는 색이 전부 하드코딩돼 있었다. 흰 배경도 박혀 있고, 검은 글씨도 박혀 있고, 그 사이의 회색들도 다 박혀 있었다. 다크 모드를 하려면 이 박힌 값들을 전부 ‘상황에 따라 바뀌는 값’으로 바꿔야 하는데, 흩어져 있으니 어디부터 손대야 할지 막막했다. 결국 ‘일부 페이지만 다크 모드’라는 어정쩡한 결과가 나왔다. 메인은 다크 모드가 되는데, 안쪽 신청 페이지로 들어가면 갑자기 눈부신 흰 화면이 튀어나오는 식이다. 사용자 입장에서는 ‘이게 되다 만 건가?’ 싶은 경험이 됐다.

이 사례가 보여주는 건, 하드코딩이 단지 ‘과거의 변경’만 어렵게 하는 게 아니라 ‘미래의 새 기능’까지 막는다는 점이다. 토큰이 없으면 다크 모드 같은 ‘색을 동적으로 바꾸는’ 기능 자체를 시도하기가 어렵다. 색이 한곳에 모여 있고 의미로 정리돼 있어야, 그 위에 새로운 모드, 새로운 테마, 새로운 캠페인 색을 얹을 수 있다. 하드코딩은 사이트를 ‘한 가지 모습으로 굳혀버리는’ 시멘트 같은 거다. 한 번 굳으면 다른 모습으로 바꾸기가 거의 불가능해진다.

여기서 ‘반쪽 다크 모드’가 사용자에게 어떤 인상을 주는지 더 생각해보자. 사용자가 어두운 메인 화면을 보고 ‘오, 이 기관 다크 모드 되네’ 하고 안심하며 안쪽 신청 페이지로 들어갔는데, 갑자기 새하얀 화면이 눈을 찌른다. 밤에 침대에서 휴대폰을 보던 사용자라면 그 순간 눈이 부셔 인상을 찌푸린다. ‘되다 만 기능’은 차라리 ‘아예 없는 기능’보다 나쁜 인상을 준다. 없으면 기대를 안 하지만, 되다 말면 ‘기대했다가 배신당한’ 느낌이 들기 때문이다. 그래서 다크 모드 같은 기능은 ‘일부만’ 하면 안 하느니만 못한 경우가 많다. 그런데 하드코딩 사이트는 구조상 ‘전부 다’가 거의 불가능해서, 결국 ‘일부만’에 머무르고 만다.

토큰 구조가 다크 모드를 어떻게 쉽게 만드는지 한 번만 더 짚자. 핵심은 ‘화면은 역할 이름만 안다’는 점이다. 신청 페이지의 배경은 ‘#ffffff’를 모르고 ‘배경색’이라는 역할만 안다. 글자는 ‘#000000’을 모르고 ‘글자색’이라는 역할만 안다. 그러니 다크 모드로 전환할 때, ‘배경색이 실제로는 어두운 값’, ‘글자색이 실제로는 밝은 값’이라고 역할 토큰의 ‘실제 값’만 통째로 갈아끼우면 된다. 화면 코드는 한 줄도 안 건드리는데 사이트 전체가 어두워진다. 이게 ‘추상화’의 힘이다. 화면이 구체적인 색값을 직접 알지 못하게 하고, ‘역할’이라는 중간 다리를 통해서만 색을 참조하게 하면, 그 다리 끝의 색을 바꾸는 것만으로 모든 게 따라온다.

■ 사례 4: ‘일부만 개편’이 만든 누더기, C기관

C기관은 또 다른 전형이다. 예산이 한정돼 있다 보니, 사이트를 한 번에 다 못 고치고 ‘눈에 띄는 메인부터’ 개편했다. 메인은 새 색, 새 글꼴로 산뜻하게 단장했다. 문제는 안쪽 페이지들이었다. 예산이 모자라서, 혹은 시간이 없어서, 안쪽은 옛날 그대로 뒀다.

그 결과 메인을 클릭해 안으로 들어가는 순간 사이트가 ‘두 개’가 됐다. 산뜻한 새 메인과, 칙칙한 옛날 안쪽 페이지. 사용자는 ‘여기 새로 만든 거 맞아? 왜 안은 이래?’ 하고 의아해한다. 더 나쁜 건, 새 메인의 색과 옛 안쪽의 색이 ‘비슷한데 다른’ 파랑이라 더 어색하다는 거였다. 차라리 완전히 다르면 ‘아, 여긴 다른 영역이구나’ 하겠는데, 비슷하니까 ‘같은 사이트인데 왜 미묘하게 다르지?’라는 더 불편한 인상을 준다.

이게 ‘일부만 개편’의 함정이다. 토큰 없이 일부만 새 색으로 바꾸면, 그 ‘일부’가 오히려 ‘나머지와 다른 섬’이 돼서 부조화를 키운다. 사용자는 사이트를 페이지 단위로 보지 않고 ‘하나의 경험’으로 본다. 그래서 한 페이지만 잘 만들면 다른 페이지와의 격차가 도드라진다. 반면 토큰으로 관리했다면, ‘대표색 토큰’ 하나만 새 값으로 바꿔도 메인이든 안쪽이든 그 토큰을 쓰는 모든 페이지가 동시에 새 색으로 바뀐다. 예산이 부족할수록 토큰이 더 절실한 이유가 여기 있다. ‘적은 손길로 사이트 전체를 바꾸는’ 게 토큰의 본질이니까.

여기서 역설이 하나 있다. 흔히 ‘예산이 넉넉하면 토큰을 도입하고, 빠듯하면 일단 눈에 보이는 것만 고친다’고 생각한다. 그런데 실제론 정반대다. 예산이 빠듯할수록 토큰이 더 이득이다. 왜냐하면 토큰은 ‘적은 자원으로 큰 범위를 바꾸는’ 도구이기 때문이다. 예산이 무한하면 사실 토큰이 없어도 사람을 갈아 넣어 사방을 다 고칠 수 있다. 하지만 예산이 빠듯하면, 그 적은 예산으로 ‘사이트 전체’를 바꿔야 하는데, 그건 토큰 없이는 불가능하다. C기관이 ‘메인만 개편하고 안쪽은 포기’한 것도 결국 ‘토큰이 없어서 적은 예산으로 전체를 못 바꿨기’ 때문이다. 만약 토큰이 있었다면, 같은 예산으로 ‘메인만’이 아니라 ‘전체’를 한 번에 산뜻하게 바꿀 수 있었을 거다. 가난할수록 좋은 연장이 필요한 법이다.

C기관 담당자분이 하셨던 말이 기억에 남는다. “돈 들여 개편했는데 왜 더 누더기 같아 보이냐는 말을 들었어요.” 정확히 토큰 없는 ‘일부 개편’의 결과다. 노력과 예산은 분명히 들어갔는데, 결과는 오히려 더 어수선해 보인다. 이런 일을 막으려면, 개편의 첫 단계가 ‘색을 토큰으로 정리하는’ 작업이어야 한다. 그게 안 되면, 아무리 메인을 예쁘게 만들어도 ‘섬’만 하나 더 생길 뿐이다.

■ 사례 5: 색맹 검사에서 통째로 걸린 ○○시

마지막 사례는 접근성과 얽힌 이야기다. ○○시 사이트가 접근성 점검을 받았는데, ‘색 대비’ 항목에서 무더기로 지적을 받았다. 색 대비란, 배경과 글자의 밝기 차이가 충분해야 저시력 사용자나 밝은 야외에서 보는 사용자도 글을 읽을 수 있다는 기준이다. 웹접근성 지침(KWCAG 33항목) 중에서도 자주 걸리는 단골 항목이다.

왜 무더기로 걸렸을까. 색이 하드코딩돼 있었기 때문이다. 페이지마다 ‘대충 비슷한 회색’ 글씨를 다른 값으로 박아뒀는데, 그중 어떤 회색은 우연히 대비가 충분했고 어떤 회색은 미달이었다. 매번 눈대중으로 박으니, 어떤 조합은 통과하고 어떤 조합은 떨어지는 ‘복불복’ 상태였다. 그리고 그게 사이트 전체에 무작위로 흩어져 있으니, 어디가 통과고 어디가 미달인지 일일이 검사하기 전엔 알 수가 없었다.

만약 색을 토큰으로 관리했다면 어땠을까. ‘본문 글자색’, ‘배경색’ 같은 역할 토큰을 정해두고, 그 조합이 대비 기준을 통과하는지 ‘한 번만’ 검증해두면 된다. 그 토큰을 쓰는 모든 페이지는 자동으로 검증된 조합을 쓰게 되니, 페이지마다 복불복으로 걸릴 일이 없다. 즉 토큰은 단지 ‘바꾸기 편한’ 것만이 아니라 ‘품질을 한 번에 보장하는’ 장치이기도 하다. 한 곳에서 검증하면 모든 곳이 검증된다.

○○시 사례는 ‘하드코딩이 접근성까지 망친다’는 걸 보여준다. 색을 통제하지 못하면 대비도 통제하지 못하고, 대비를 통제 못 하면 ‘누군가는 글을 못 읽는 사이트’가 된다. 공공 정보는 ‘누구나’ 읽을 수 있어야 한다는 게 대전제인데, 하드코딩은 그 대전제를 우연에 맡겨버린다. 색을 토큰으로 정리하는 건 결국 ‘누구나 읽을 수 있는 사이트’로 가는 첫걸음이기도 하다.

색 대비 이야기가 나온 김에 한 가지 더 짚고 싶다. 색은 ‘정보를 전달하는 신호’이기도 하다. 빨강은 경고나 오류, 초록은 성공이나 완료, 파랑은 주요 행동 — 잘 설계된 사이트에서 색은 단순한 장식이 아니라 ‘읽히는 정보’다. 그런데 색이 하드코딩으로 통제 불능이 되면 이 신호 체계가 무너진다. 어떤 페이지에선 빨강이 ‘중요 공지’인데 다른 페이지에선 빨강이 그냥 ‘제목 강조’다. 사용자는 색이 주는 신호를 더 이상 믿지 못하게 되고, 결국 색을 정보로 읽지 않고 무시하게 된다. 정작 진짜 경고를 빨강으로 띄워도 ‘또 그냥 강조겠지’ 하고 넘겨버리는 거다. 색의 일관성은 미관 문제가 아니라 ‘정보 전달의 신뢰’ 문제다.

그리고 색맹·색약 사용자를 떠올리면 이 문제는 더 심각해진다. 우리나라 남성의 상당수가 어떤 형태로든 색각 이상을 가지고 있다고 알려져 있다. 이분들에게 ‘빨강과 초록’은 비슷하게 보일 수 있어서, 색만으로 정보를 구분하면 그 정보를 놓친다. 그래서 접근성 기준은 ‘색 외에 다른 단서(아이콘, 텍스트, 패턴)도 함께 제공하라’고 요구한다. 그런데 색이 하드코딩으로 제멋대로면, 애초에 ‘이 색이 무슨 의미인지’조차 일관되지 않으니, 그에 맞는 보조 단서를 체계적으로 붙이는 것도 불가능하다. 토큰으로 ‘경고-색’을 정의해두면, ‘경고-색을 쓸 땐 경고 아이콘도 함께 쓴다’는 규칙을 한 번에 적용할 수 있다. 색의 체계화가 접근성 보조 단서의 체계화로 이어지는 거다. 결국 ○○시가 색 대비에서 무더기로 걸린 건, 단지 ‘색이 어두웠다’의 문제가 아니라 ‘색을 체계로 다루지 못한’ 더 근본적인 문제의 한 증상이었던 셈이다.

■ 색만의 문제가 아니다 — 글꼴·간격도 똑같이 박힌다

지금까지 색 이야기만 했지만, 하드코딩의 지옥은 색에만 있는 게 아니다. 글꼴과 간격도 똑같이 박힌다. 오히려 이쪽이 더 은근하게, 더 광범위하게 사이트를 망친다.

글꼴부터 보자. 가이드 없는 사이트의 페이지를 열어보면 글꼴이 네다섯 종 섞여 있는 경우가 흔하다. 본문은 이 글꼴, 제목은 저 글꼴, 어디선가 복사해온 표는 또 다른 글꼴, 외부에서 가져온 위젯은 시스템 기본 글꼴. 이게 왜 생기냐면, 글꼴 역시 ‘박혀’ 있기 때문이다. 보도자료를 워드에서 복사해 붙이면 그 워드의 글꼴이 따라 들어오고, 다른 사이트의 표를 가져오면 그 사이트의 스타일이 묻어온다. 이렇게 ‘바깥에서 온 글꼴’이 하나둘 쌓여 한 페이지에 다섯 종이 공존한다. 글꼴이 섞이면 가독성과 신뢰감이 함께 떨어진다. 사용자는 ‘왜인지 모르게 어수선하다’고 느끼고, 무의식적으로 ‘이 사이트가 제대로 관리되고 있나’를 의심하게 된다. 공공 서비스는 본질적으로 ‘믿고 맡기는’ 서비스라, 이 무의식적 불신은 결코 가볍지 않다.

글꼴도 토큰으로 풀린다. ‘본문 글꼴’, ‘제목 글꼴’ 같은 역할 토큰을 정해두고, 글자 크기와 굵기까지 ‘제목 크기’, ‘본문 크기’, ‘캡션 크기’로 단계를 정해두면(이걸 타이포 위계라고 한다), 누가 만들어도 정돈된 글자 체계가 나온다. KRDS가 공공 표준 서체와 타이포 위계를 제시하는 이유가 여기 있다. 특히 글자 크기는 ‘읽을 권리’의 문제이기도 하다. 본문이 너무 작으면, 그 정보가 가장 필요한 어르신이나 시력이 약한 분들이 못 읽는다. 화면을 키우지 않아도, 안경을 고쳐 쓰지 않아도 편히 읽히는 크기 — 그게 공공 서비스의 최소선이고, 토큰으로 ‘본문 최소 크기’를 정해두면 그 최소선이 모든 페이지에서 보장된다.

간격은 더 은근하다. 색과 글꼴은 그래도 눈에 띄는 편인데, 간격은 가장 티 안 나게 사이트를 어수선하게 만드는 주범이다. 요소와 요소 사이의 여백, 문단 사이의 거리, 카드 안쪽의 패딩 — 이런 간격이 페이지마다 제각각이면 사이트가 ‘정렬이 안 맞는’ 느낌을 준다. 사용자는 ‘뭔가 비뚤어 보인다’고 느끼지만 정확히 뭐가 문제인지는 짚지 못한다. 잘 만든 사이트가 ‘깔끔하다’고 느껴지는 이유의 절반은 사실 이 간격의 규칙성이다. KRDS가 간격을 일정한 단위로 정해두는 이유가 여기 있다. 간격에 규칙이 있으면 누가 만들어도 ‘정렬된’ 화면이 나오고, 규칙이 없으면 아무리 색과 글꼴이 통일돼 있어도 어딘가 어수선하다. 간격도 ‘8 단위’, ‘16 단위’처럼 토큰으로 정해두면, 매번 ‘여백을 몇으로 줄까’ 고민할 필요 없이 정해진 단위 중 하나를 고르기만 하면 된다. 고민이 줄고, 결과는 정돈된다.

그러니까 ‘하드코딩한 색의 지옥’이라고 제목을 달았지만, 정확히는 ‘하드코딩한 디자인 값 전부의 지옥’이다. 색, 글꼴, 간격 — 이 세 가지 기초 값이 토큰 없이 박히면, 세 방향에서 동시에 부채가 쌓인다. 그리고 이 세 가지는 따로 노는 게 아니라 함께 무너진다. 색이 통제 불능인 사이트는 십중팔구 글꼴도 뒤섞여 있고 간격도 들쭉날쭉하다. 원인이 하나 — ‘기초 값을 토큰으로 관리하지 않았다’ — 이기 때문이다.

【본론 3 — 그래서 토큰이 무엇을 해결하는가】

■ 토큰의 첫 번째 힘: ‘한 곳에서 바꾸면 전부 바뀐다’

지금까지 본 다섯 가지 지옥은 모두 하나의 원인에서 나왔다. ‘같은 의미의 색이 여러 곳에 따로 적혀 있다.’ 토큰은 정확히 이 문제를 푼다. 색을 ‘브랜드-주색’, ‘성공-색’, ‘경고-색’ 같은 이름 붙은 변수로 한 곳에서 정의하고, 화면에서는 그 변수만 참조한다. 그러면 변수의 값을 한 번 바꾸는 순간, 그 변수를 쓰는 모든 화면이 동시에 바뀐다.

A광역지자체의 ‘파랑 한 톤 밝게’가 토큰 사이트였다면 어땠을까. ‘브랜드-주색’ 변수의 값을 새 파랑으로 바꾸는 한 줄 수정. 그걸로 헤더도, 버튼도, 링크도, 강조 박스도 전부 새 파랑이 된다. 3주가 3분이 된다. 이게 토큰의 가장 직관적인 힘이다. ‘흩어진 걸 한 곳으로 모으는 것’만으로 변경 비용이 수백 배 줄어든다.

이 ‘한 곳으로 모은다’는 게 단순해 보여도, 사실 모든 좋은 시스템의 공통 원리다. 좋은 시스템은 ‘바뀔 수 있는 것’을 한 곳에 모아둔다. 그래야 변화가 왔을 때 그 한 곳만 손대면 되니까. 반대로 나쁜 시스템은 ‘바뀔 수 있는 것’을 사방에 흩어둔다. 그래서 작은 변화에도 사방을 뒤져야 한다. 색은 ‘반드시 언젠가 바뀌는 것’이다. 브랜드는 개편되고, 기관은 통합되고, 트렌드는 변한다. ‘언젠가 바뀔 게 확실한 것’을 흩어두는 건, 미래의 나에게 폭탄을 심어두는 셈이다. 토큰은 그 폭탄을 한 곳에 모아 ‘안전하게 다룰 수 있는 스위치’로 바꾸는 작업이다. 변화를 피하는 게 아니라, 변화를 ‘쉽게 받아들일 수 있는 구조’를 미리 만들어두는 거다.

■ 토큰의 두 번째 힘: ‘색에 의미를 붙인다’

토큰은 단순히 값을 모으는 데 그치지 않는다. 색에 ‘역할 이름’을 붙인다는 게 더 중요한 차이다. ‘#1F4E79’가 아니라 ‘주요-행동-색’이라고 부르면, 그 색이 ‘왜 거기 있는지’가 코드에 그대로 드러난다. 신청 버튼에는 ‘주요-행동-색’을, 삭제 버튼에는 ‘경고-색’을, 안내 박스에는 ‘정보-색’을 쓰는 식이다.

이렇게 역할로 관리하면 두 가지가 좋아진다. 첫째, 만들 때 ‘무슨 색을 쓸까’가 아니라 ‘이건 무슨 역할인가’로 생각하게 된다. 색 선택이 ‘미적 취향’에서 ‘논리적 판단’으로 바뀐다. 신입 담당자도 ‘이건 신청 버튼이니 주요-행동-색’이라고 규칙대로 고르면 되니, 색 감각이 뛰어나지 않아도 정돈된 결과를 낸다. 둘째, 한중앙부처 통합 사례에서 봤듯, 나중에 ‘우리 주요 행동 색을 바꾸자’는 결정이 사이트 전체의 모든 신청 버튼에 일관되게 반영된다. 의미 단위로 바꾸니까, ‘성공색은 그대로 두고 대표색만 바꾼다’ 같은 정교한 변경도 가능해진다. 색이 그냥 숫자가 아니라 ‘의미를 가진 약속’이 되는 거다. 이게 토큰이 단순한 ‘색 모음’을 넘어 ‘디자인 언어’로 불리는 이유다. 언어에 단어와 문법이 있듯, 토큰에는 역할과 규칙이 있다. 그리고 언어가 그렇듯, 한번 익히면 모두가 같은 말로 소통하게 된다 — 발주처도, 외주 업체도, 새로 온 담당자도.

■ 토큰의 세 번째 힘: ‘품질을 한 번에 보장한다’

○○시 색 대비 사례에서 봤듯, 토큰은 품질 검증을 ‘한 곳’으로 모은다. ‘본문색 + 배경색’ 조합이 대비 기준을 통과하는지 토큰 단계에서 한 번 검증해두면, 그 토큰을 쓰는 모든 페이지가 자동으로 그 품질을 물려받는다. 페이지마다 복불복으로 검사할 필요가 없다. 이건 색뿐 아니라 글꼴 크기, 간격에도 똑같이 적용된다. ‘본문 최소 크기’를 토큰으로 정해두면 어느 페이지든 그 크기 이상이 보장된다.

그래서 토큰은 ‘디자인의 일관성’만 지키는 게 아니라 ‘디자인의 품질 하한선’을 지킨다. 잘 만든 토큰 체계는 ‘이 토큰들만 쓰면 적어도 못 만들 수는 없다’는 안전망을 깔아준다. 신입 담당자가 와도, 새 외주가 들어와도, 그들이 토큰만 쓰면 일정 수준 이상의 결과가 나온다. 이게 행정안전부가 「전자정부 웹사이트 품질관리 지침」에서 표준화를 강조하고, KRDS(공공 디자인 시스템)가 토큰 체계를 제공하는 이유다. 표준 토큰은 ‘누가 만들어도 일정 품질 이상’을 보장하는 공공의 안전장치다.

■ KRDS 846규칙 속에서 토큰이 차지하는 자리

여기서 KRDS 846규칙 이야기를 잠깐 하자. KRDS는 공공 웹사이트가 지켜야 할 규칙을 846개로 정리해둔 체계인데, 크게 네 묶음으로 나뉜다. 디자인 기초를 다루는 DS 120개, 부품(컴포넌트)을 다루는 CP 446개, 화면 패턴을 다루는 BP 108개, 서비스 흐름을 다루는 SP 172개. 합치면 846개다.

오늘 다룬 ‘색·글꼴·간격’의 토큰은 이 중 DS(디자인 스타일) 120개 규칙의 핵심을 이룬다. 색 팔레트가 표준을 따르는지, 본문 글자가 최소 크기 이상인지, 간격이 일정한 단위를 쓰는지 — 이런 것들이 DS 영역에서 점검된다. 그리고 흥미로운 건, 이 DS가 흔들리면 그 위의 CP·BP·SP가 줄줄이 흔들린다는 점이다. 버튼(CP)의 색은 DS의 주색을 가져다 쓰고, 신청 폼(BP)은 그 버튼들로 구성되고, 신청 흐름(SP)은 그 폼들로 이뤄지니까. 토큰이 무너지면 맨 아래 기초가 무너지는 거고, 기초가 무너지면 위로 올라갈수록 균열이 커진다.

그래서 사이트를 점검할 때, 사용자가 “신청이 너무 불편하다”고 호소해도 우리는 가장 먼저 DS — 즉 토큰부터 들여다본다. 증상은 위에서 터지지만 원인은 아래에 있을 때가 많기 때문이다. 토큰을 정리하는 건 단순히 ‘색을 예쁘게’가 아니라, 846규칙 전체의 기초를 다지는 일이다.

이 ‘기초의 전파’를 건물 비유로 다시 보자. DS는 건물의 기초 공사다. 기초가 삐뚤면 1층은 약간 기울고, 2층은 더 기울고, 옥상은 위험할 만큼 기운다. 색·글꼴·간격이 통일 안 된 상태(DS 부실)에서 버튼(CP)을 만들면 버튼이 제각각이 되고, 그 제각각인 버튼으로 신청 폼(BP)을 만들면 폼이 어수선해지고, 그 어수선한 폼으로 신청 흐름(SP)을 엮으면 흐름 전체가 불편해진다. 그래서 망가진 사이트를 고칠 때도 기초부터 다시 잡는 게 정석이다. 눈에 보이는 신청 페이지가 불편하다고 그것부터 고치면, 그 페이지만 ‘혼자 다른 섬’이 되어 새로운 부조화를 만든다. 반면 기초(토큰)를 먼저 정하면, 그 약속으로 신청 페이지를 고치는 순간 그 작업물이 ‘다른 모든 페이지와 어울리는’ 결과가 된다.

그리고 KRDS가 846개나 되는 규칙을 굳이 정해둔 이유도 여기서 이해할 수 있다. 처음 846이라는 숫자를 들으면 ‘그렇게 많이 지켜야 하나’ 싶어 막막하다. 하지만 그 846개는 ‘남을 괴롭히려는 규제’가 아니라, ‘누가 만들어도 일정 품질이 나오게 하는 안전망’이다. 그리고 그 846개의 맨 아래 기초가 바로 오늘 이야기한 DS — 색·글꼴·간격의 토큰이다. 기초 120개를 제대로 지키면, 그 위의 CP·BP·SP 규칙들이 상당 부분 자동으로 따라온다. 버튼의 색이 표준 토큰을 쓰면 ‘버튼 색 규칙’이 자동으로 지켜지고, 간격이 표준 단위를 쓰면 ‘간격 규칙’이 자동으로 지켜지는 식이다. 그래서 846개를 한꺼번에 외워 지키려 하지 말고, 가장 아래 토큰부터 잡으라고 권하는 거다. 기초가 잡히면 위층은 훨씬 쉬워진다.

【본론 4 — 그럼 지금 우리 사이트는 어떤 상태일까】

■ ‘우리는 괜찮겠지’가 가장 위험하다

여기까지 읽고 ‘우리 사이트는 그래도 괜찮을 거야’라고 생각한다면, 잠깐 멈추자. 내가 현장에서 만난 거의 모든 담당자가 점검 전엔 그렇게 생각했다. ‘우리는 외주를 잘 줬으니까’, ‘우리는 최근에 개편했으니까’, ‘우리는 색이 통일돼 보이니까.’ 그런데 막상 코드를 열어보면 거의 예외 없이 ‘비슷한데 다른 색’이 수십 종 나왔다. 눈으로 보기엔 괜찮아 보여도, 코드 속에서는 부채가 조용히 쌓이고 있는 거다.

특히 ‘외주를 잘 줘서 괜찮다’는 안심이 가장 위험하다. 외주를 줘도 발주처에 공유된 디자인 토큰 가이드가 없으면, 업체는 ‘알아서 예쁘게’ 만들 수밖에 없고, 그 ‘알아서’가 매번 다르다. A 업체의 기본 파랑과 B 업체의 기본 파랑이 다르고, 같은 업체라도 작년 디자이너와 올해 디자이너의 기본값이 다르다. 발주 문서에 “KRDS 토큰을 준수해 주세요”라는 한 줄을 넣을 수 있느냐 없느냐가, 5년 뒤 사이트의 운명을 가른다. 그 한 줄은 검수의 기준도 만들어준다. ‘예쁘게 만들었습니다’라는 주관적 평가 대신, ‘이 색이 표준 토큰을 벗어났다’는 객관적 근거로 수정을 요청할 수 있으니까.

■ 그래서 ‘토큰 채택률’을 본다

그럼 우리 사이트가 토큰을 잘 쓰고 있는지를 어떻게 알 수 있을까. 가장 직관적인 지표가 ‘토큰 채택률’이다. 사이트에서 쓰인 색·글꼴·간격 값 중에서, ‘표준 토큰에 해당하는 값’이 몇 퍼센트인지를 보는 거다. 채택률이 높으면 ‘대부분의 색이 표준 안에서 관리되고 있다’는 뜻이고, 낮으면 ‘제멋대로 박은 값이 많다’는 뜻이다.

이 채택률이 중요한 이유는, ‘말’로는 가늠이 안 되는 걸 ‘숫자’로 보여주기 때문이다. ‘우리 색 좀 들쭉날쭉한 것 같아’는 막연한 느낌이지만, ‘우리 사이트 색 토큰 채택률 38%’는 명확한 사실이다. 숫자가 나오면 ‘올려야겠다’는 목표가 생기고, 작업의 진척도 숫자로 확인된다. 38%를 70%로, 90%로 올려가는 과정이 곧 부채를 갚아가는 과정이다.

여기서 ViewCheck가 하는 일을 잠깐 소개하겠다. ViewCheck는 공공 웹사이트의 KRDS 준수 여부를 자동으로 진단해주는 서비스인데, 이 ‘토큰 채택률’을 자동으로 계산해 보여준다. 사이트 주소만 넣으면, 사이트 곳곳에 박힌 색·글꼴·간격 값을 전부 수집해서 표준 토큰과 대조하고, ‘색 토큰 채택률 몇 %, 글꼴 채택률 몇 %, 간격 채택률 몇 %’를 리포트로 만들어준다. 사람이 코드를 일일이 뒤져 ‘색 고고학’을 하던 그 작업을, 자동으로 해주는 셈이다.

■ 채택률을 ‘올리는’ 현실적인 순서

채택률이 낮다고 절망할 필요는 없다. 부채는 갚으면 되고, 갚는 데도 현실적인 순서가 있다. 한 번에 다 뜯어고치려 들면 엄두가 안 나서 결국 손을 못 댄다. 그래서 나는 ‘작게, 그러나 멈추지 않게’를 권한다.

첫 단계는 ‘더 쌓지 않기’다. 이미 쌓인 부채를 당장 다 갚지는 못해도, 적어도 ‘오늘부터 만드는 새 페이지는 토큰만 쓴다’는 규칙을 세우는 거다. 빚이 그렇듯, 부채는 ‘더 늘지 않게 멈추는 것’이 첫 번째 할 일이다. 새 페이지가 표준 토큰만 쓰기 시작하면, 적어도 부채의 복리는 멈춘다. 이것만으로도 시간이 지날수록 ‘토큰을 쓰는 새 페이지’의 비중이 늘어 채택률이 자연히 오른다.

두 번째 단계는 ‘가장 많이 쓰이는 것부터’ 정리하기다. 마흔 종의 파랑을 한 번에 한 종으로 모으긴 어렵지만, 그중 ‘가장 자주 쓰이는 대표 파랑 한두 종’을 표준 토큰으로 지정하고, 새로 만들 땐 그것만 쓰게 하면 효과가 크다. 자주 쓰이는 색일수록 통일했을 때 화면에 미치는 영향이 크기 때문이다. ‘20%의 핵심 값이 80%의 화면을 차지한다’는 식의 우선순위를 잡으면, 적은 노력으로 큰 인상 변화를 만든다.

세 번째 단계는 ‘바꿀 일이 생길 때 함께 정리하기’다. 어차피 어떤 페이지를 개편할 일이 생기면, 그 김에 그 페이지의 박힌 값을 토큰으로 바꾼다. ‘토큰 정리만을 위한 별도 프로젝트’를 따로 잡기는 예산상 어렵지만, ‘하던 작업에 묻어서’ 조금씩 정리하는 건 부담이 적다. 이렇게 ‘새 작업마다 그 범위만큼 토큰화’를 누적하면, 몇 년에 걸쳐 사이트 전체가 자연스럽게 정리된다. 중요한 건 속도가 아니라 방향이다. 매 작업이 부채를 ‘늘리는’ 방향이 아니라 ‘줄이는’ 방향이기만 하면, 사이트는 시간이 갈수록 좋아진다.

이 모든 단계의 출발점은 결국 ‘지금 채택률이 몇 %인지 아는 것’이다. 출발선을 모르면 얼마나 왔는지도 모른다. 그래서 정기적으로 진단해서 채택률 숫자를 기록해두면, ‘작년 38%에서 올해 61%로 올랐네’ 하고 진척을 확인할 수 있다. 숫자로 보이는 진척만큼 담당자에게 힘이 되는 것도 없다. 막연히 ‘열심히 정리 중’이 아니라 ‘부채를 23%p 갚았다’는 게 보이니까.

■ 캡쳐로 보는 토큰 채택률 리포트

말로만 하면 감이 안 오니, 실제 화면을 보자. 아래 캡쳐는 ViewCheck의 ‘디자인 시스템 탭’에서 토큰 채택률을 보여주는 부분이다. 사이트를 진단하면 상단에 점수 카드(OverviewCards)가 뜨고, 디자인 시스템 탭으로 들어가면 색·글꼴·간격별 토큰 채택률이 한눈에 보인다. ‘우리 사이트의 색 중 표준 토큰을 쓰는 비율은 몇 %’가 막대로 표시되고, 표준을 벗어난 ‘제멋대로 값’이 몇 종인지도 함께 나온다.

이 리포트의 가치는 ‘막연한 불안을 구체적인 할 일로 바꿔준다’는 데 있다. ‘우리 사이트 색이 좀 이상한 것 같은데…’라는 막연함이, ‘색 토큰 채택률 38%, 표준 외 파랑 41종 발견’이라는 구체적 사실로 바뀐다. 그러면 다음 행동이 분명해진다. ‘이 41종을 표준 파랑 한 종으로 모으자.’ 작업의 시작점과 목표가 동시에 생기는 거다. 그리고 작업을 진행할 때마다 다시 진단해서 채택률이 오르는 걸 확인하면, ‘우리가 부채를 갚고 있다’는 게 숫자로 보인다.

또 하나, 이 숫자는 ‘보고’에도 큰 힘이 된다. 담당자가 윗선에 ‘디자인 정리가 필요합니다’라고 말하면 ‘그게 그렇게 급한가’라는 반응이 돌아오기 쉽다. 미관 문제로 들리기 때문이다. 그런데 ‘우리 사이트 색 토큰 채택률이 38%인데, 이대로면 다음 브랜드 개편 때 색 하나 바꾸는 데 수 주가 걸립니다’라고 숫자와 비용으로 말하면 이야기가 달라진다. 막연한 ‘예쁘게 하자’가 아니라 ‘미래의 비용을 줄이자’는 명확한 근거가 생기는 거다. 객관적 지표는 설득의 무기다. 디자인 정리를 ‘취향의 문제’가 아니라 ‘관리의 문제’로 끌어올려야, 비로소 우선순위를 받을 수 있다. 토큰 채택률 리포트는 바로 그 ‘끌어올림’을 도와주는 도구다.

【 마무리 】

오늘 길게 이야기했지만, 핵심은 단순하다. ‘색을 손으로 박지 마라. 이름을 붙여 한 곳에서 관리하라.’ 그게 토큰이다. 토큰 없이 하드코딩한 색은 박는 순간엔 공짜처럼 보이지만, 색을 바꿔야 하는 순간 — 그리고 그 순간은 반드시 온다 — 이자까지 붙여 청구서로 날아온다. A광역지자체의 3주짜리 대공사, 한중앙부처의 의미 충돌, B공공기관의 반쪽 다크 모드, C기관의 누더기 개편, ○○시의 접근성 무더기 지적. 다섯 가지 지옥이 전부 ‘색이 흩어져 있었다’는 한 가지 원인에서 나왔다.

반대로 말하면, 토큰 하나 제대로 도입하면 이 다섯 가지가 동시에 좋아진다. 변경이 쉬워지고, 의미가 살아나고, 품질이 보장되고, 새 기능을 얹을 수 있고, 접근성까지 챙겨진다. 원인이 하나니까 처방도 하나로 통한다. 다섯 군데를 따로따로 고치는 게 아니라, 뿌리 하나를 바로 세우면 다섯 가지 증상이 함께 가라앉는 거다. 토큰은 ‘일을 더 시키는 규제’가 아니라 ‘일을 덜어주고 미래를 지켜주는 도구’다. 처음 정리하는 데 약간의 품이 들 뿐, 한번 정리해두면 매번 똑같은 고민을 반복하지 않아도 된다.

그리고 그 첫걸음은 ‘지금 우리 사이트가 어떤 상태인지 아는 것’이다. 막연히 ‘괜찮겠지’ 하지 말고, 한 번 진단을 받아보길 권한다. 우리 사이트의 색 토큰 채택률이 몇 %인지, 표준을 벗어난 값이 몇 종이나 흩어져 있는지를 숫자로 확인하는 순간, 막연한 불안이 구체적인 할 일로 바뀐다. 그게 부채를 갚는 출발점이다.

마지막으로 한 번 더 강조하고 싶다. 하드코딩은 ‘게으른 사람의 잘못’이 아니라 ‘바쁜 사람이 빠지는 구조적 함정’이다. 그러니 우리 사이트에서 그 함정의 흔적을 발견하더라도 자책할 필요 없다. 대부분이 겪는 일이고, 대부분이 같은 방법 — 토큰으로 한 곳에 모으기 — 으로 풀어왔다. 중요한 건 그 함정을 알아보는 눈을 갖추고, ‘오늘부터 더 쌓지 않기’를 시작하는 거다. 이미 쌓인 부채는 천천히 갚아도 된다. 다만 더 쌓지 않는 것, 그게 출발점이다.

다음 글에서는 오늘 살짝 미뤄둔 이야기 — ‘그럼 토큰을 실제로 어떻게 도입하고, 어디서부터 정리하면 되는가’를 더 구체적으로 풀어보려 한다. 오늘 글이 ‘하드코딩의 지옥’을 보여주는 글이었다면, 다음 글은 ‘그 지옥에서 빠져나오는 사다리’를 그리는 글이 될 거다. 오늘 우리 사이트의 토큰 채택률부터 한 번 확인해두면, 다음 글이 훨씬 더 와닿을 거다. 숫자 하나를 알고 다음 글을 읽는 것과, 막연한 채로 읽는 것은 와닿는 정도가 완전히 다르다.

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

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