브랜드 색 제멋대로 쓰다 통일성 깨진 사례

브랜드 색 제멋대로 쓰다 통일성 깨진 사례

---

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

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

【 공감·문제제기 】

월요일 글에서는 ‘디자인 일관성이 왜 돈이 되는가’를 큰 그림으로 그렸다. 오늘은 그 그림 안으로 한 발 더 들어간다. 주제는 딱 하나, ‘색’이다. 그것도 ‘브랜드 색을 제멋대로 쓰다가 사이트 전체의 통일성이 어떻게 무너지는가’를, 가상의 익명 사례로 아주 구체적으로 들여다보려 한다.

솔직히 말하면 색 이야기는 처음엔 좀 시시하게 들린다. 버튼이 안 눌린다거나, 신청 폼이 제출이 안 된다거나 하는 건 ‘사고’처럼 보이는데, ‘파란색이 여러 종류다’는 사고로 안 느껴진다. 화면이 떠 있고, 글자가 읽히고, 링크가 눌리니까. 그런데 바로 그게 함정이다. 색의 난립은 ‘사고’가 아니라 ‘병’이다. 사고는 한 번 터지고 수습하면 끝이지만, 병은 조용히 진행되면서 사이트 전체를 갉아먹는다. 그리고 어느 날 ‘브랜드 색을 바꾸자’는 말이 나오는 순간, 그동안 쌓인 병이 한꺼번에 청구서로 날아온다.

내가 공공 웹사이트를 점검하면서 가장 자주 마주치는 장면 중 하나가 바로 이 ‘색 청구서’다. 담당자는 윗선에서 “우리 기관 파랑을 조금 더 밝고 신뢰감 있게 바꾸라”는 한 줄짜리 지시를 받는다. 한 줄이다. 받아 든 담당자는 ‘색 하나 바꾸는 건데 뭐’ 하고 가볍게 시작한다. 그런데 막상 사이트를 열어 보니, 비슷비슷한 파랑이 수십 종 흩어져 있다. 어디서부터 손대야 할지 막막하다. 한 줄짜리 지시가 몇 주짜리 대공사가 되는 순간이다. 오늘 글은 바로 그 막막함의 ‘원인’과 ‘예방법’에 대한 이야기다.

먼저 분명히 해두자. 이 글은 누구를 탓하려는 글이 아니다. 색이 제멋대로가 된 사이트를 만든 사람들은 게으르지도, 실력이 없지도 않았다. 오히려 그 반대인 경우가 많다. 다들 자기 차례에 ‘우리 사이트랑 잘 어울리는 파랑’을 고르느라 나름 신경을 썼다. 문제는 ‘각자 신경 썼다’는 데 있다. 공유된 기준 없이 각자 최선을 다하면, 개별로는 다 그럴듯한데 모아 놓으면 제각각인 결과가 나온다. 색 난립은 무능의 증거가 아니라 ‘기준 부재’의 증거다. 그래서 이건 사람을 바꿔서 풀 문제가 아니라 ‘약속을 만들어서’ 풀 문제다.

또 하나 미리 말해두고 싶은 건, 색 문제는 ‘조용한 손해’라는 점이다. 색이 들쭉날쭉하다고 민원이 들어오지는 않는다. 통계에 ‘색이 일관되지 않아 이탈했습니다’라고 찍히지도 않는다. 사용자는 그냥 ‘뭔가 좀 정돈이 안 됐네’ 하고 무의식적으로 신뢰를 깎고는, 별말 없이 떠난다. 그래서 담당자 입장에서는 문제가 있다는 사실 자체를 인지하기가 어렵다. 오늘 이 글의 목적은 그 ‘보이지 않는 손해’를 눈에 보이게 만드는 거다. 보여야 고칠 마음이 생기니까. 그리고 글 말미에는, 그 보이지 않던 색의 난립을 ‘숫자’로 보이게 만드는 방법 — ViewCheck의 디자인 토큰 채택률 리포트 — 도 자연스럽게 소개하려 한다.

마지막으로 범위 정리. KRDS(디지털 정부 서비스 디자인 시스템)는 846개 규칙으로 이뤄져 있다. 크게 보면 디자인 기초(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개다. 오늘 다룰 ‘색’은 이 중에서 가장 아래, 가장 기초인 DS 영역에 속한다. 가장 아래에 있다는 건 ‘가장 사소하다’는 뜻이 아니라 ‘가장 많은 것을 떠받친다’는 뜻이다. 색이 흔들리면 그 위에 쌓은 모든 것이 함께 흔들린다. 왜 그런지를, 지금부터 익명 사례들과 함께 하나씩 풀어보겠다.

미리 한 가지 당부하고 싶은 게 있다. 이 글을 읽으면서 ‘우리 사이트도 이런데’ 싶은 대목이 분명 나올 거다. 그때 자책하지 말았으면 한다. 색이 제멋대로가 되는 건 거의 모든 공공 사이트가 한 번쯤 거치는 길이고, 규모가 크든 작든, 예산이 많든 적든 비슷하게 나타난다. 잘 만든 사이트라고 안 나오는 게 아니라 ‘덜 나오는’ 정도의 차이일 뿐이다. 중요한 건 그 패턴을 알아보는 눈을 갖추는 거다. ‘아, 이게 그 색 난립이구나’ 하고 이름을 붙일 수 있으면, 고칠 수도 있다. 이름 없는 문제는 못 고치지만, 이름 붙은 문제는 절반은 해결된 거나 마찬가지다. 오늘 글이 그 ‘이름 붙이기’를 돕는 글이 되길 바란다.

【본론 1 — 색이 ‘제멋대로’가 된다는 건 정확히 무슨 상태인가】

■ 사람 눈엔 다 ‘파랑’인데, 코드엔 수십 종의 파랑

A광역지자체의 대표 포털을 가상으로 점검했다고 해보자. 첫인상은 멀쩡하다. 전체적으로 ‘파란 계열’의 차분한 사이트다. 그런데 화면 곳곳의 색을 하나씩 뽑아내 코드 단위로 늘어놓으면 풍경이 달라진다. 메인 배너의 파랑, 상단 메뉴의 파랑, 주요 버튼의 파랑, 링크 글자의 파랑, 푸터의 파랑 — 이게 다 ‘미세하게 다른’ 파랑이다. 어떤 건 진하고, 어떤 건 약간 연하고, 어떤 건 보라 끼가 살짝 돈다.

사람 눈은 관대하다. ‘대충 파랑이면 다 같은 파랑’으로 본다. 그래서 화면만 보면 문제를 못 느낀다. 하지만 코드는 정직하다. 코드에는 ‘대충’이 없다. 색은 정확한 값으로 박혀 있고, 그 값이 조금만 달라도 컴퓨터에게는 완전히 다른 색이다. 점검을 해보면 ‘비슷한 파랑’이 열 종, 스무 종, 많게는 수십 종이 발견되는 경우가 흔하다. 한 사이트 안에서 말이다.

이 ‘사람 눈은 관대하고 코드는 정직하다’는 차이가, 색 문제가 오래 방치되는 가장 근본적인 이유다. 만약 색이 어긋날 때마다 화면이 눈에 띄게 망가져 보였다면, 누구든 바로 알아채고 고쳤을 거다. 그런데 미세하게 다른 파랑 스무 종은 화면에서 ‘그냥 파란 사이트’로 뭉뚱그려 보인다. 문제가 눈에 안 보이니 고칠 동기도 안 생기고, 그사이 색은 계속 늘어난다. 그래서 색 난립은 ‘무관심으로 방치된’ 문제라기보다 ‘인지조차 못 한’ 문제에 가깝다. 담당자가 게을러서가 아니라, 애초에 보이지 않아서 손을 못 댄 거다. 그러니 색 문제 해결의 진짜 출발점은 ‘고치겠다는 의지’보다 ‘일단 보이게 만드는 것’이다.

왜 이렇게 됐을까. 답은 단순하다. 페이지를 만들 때마다 누군가가 ‘대충 비슷한 파랑’을 직접 골라 코드에 박았기 때문이다. 정해진 ‘브랜드 파랑’ 하나를 공유해 쓴 게 아니라, 각자 그때그때 눈대중으로 골랐다. 작년에 만든 페이지의 담당자와 올해 만든 페이지의 담당자가 다르고, 같은 담당자라도 모니터가 바뀌면 같은 파랑을 다르게 본다. 이렇게 ‘각자의 머릿속 파랑’이 코드에 하나씩 박히면서, 사이트의 색은 통제 불능이 됐다.

여기서 꼭 짚어야 할 게 있다. 이걸 만든 사람들 중 누구도 ‘색을 망치자’고 마음먹지 않았다는 점이다. 다들 그 순간엔 ‘이 정도 파랑이면 우리 사이트랑 어울리겠지’라고 최선을 다해 골랐다. 문제는 ‘기준이 머릿속에만 있었다’는 거다. 머릿속의 파랑은 사람마다 다르고, 같은 사람도 어제와 오늘이 다르다. 그래서 색은 ‘잘 고르는 능력’의 문제가 아니라 ‘하나의 기준을 바깥에 적어두고 공유하느냐’의 문제다. 이 한 문장이 오늘 글 전체를 관통하는 핵심이다.

이 대목에서 사람들이 자주 하는 반박이 하나 있다. “요즘은 색 추출 도구도 좋은데, 다들 같은 브랜드 색을 보고 골랐을 텐데 왜 달라지냐”는 거다. 충분히 나올 만한 질문이다. 그런데 현장을 보면 ‘같은 색을 보고도 다르게 박는’ 경로가 의외로 많다. 첫째, 출처가 제각각이다. 누구는 인쇄물 브랜드 매뉴얼에서 색을 따오고, 누구는 기존 사이트 화면을 캡처해 스포이드로 찍고, 누구는 상급 기관 홈페이지의 파랑을 ‘대충 이거랑 비슷하게’ 본떠 온다. 출처가 다르니 시작점부터 다르다. 둘째, 같은 색이라도 표현 방식이 여러 가지다. 같은 파랑을 어떤 문서는 한 표기법으로, 어떤 코드는 다른 표기법으로 적는데, 변환 과정에서 미세한 반올림 오차가 생긴다. 셋째, ‘조금만 손보자’는 유혹이다. 표준 파랑을 가져다 쓰면서도 ‘이 페이지에선 배경이 어두우니 살짝 밝게’ 하고 한 끗 조정하는데, 그 ‘한 끗’들이 모여 수십 종이 된다. 결국 ‘같은 색을 봤다’와 ‘같은 색을 박았다’는 전혀 다른 이야기다. 약속이 코드 한곳의 변수로 박혀 있지 않은 한, 사람의 선의는 색의 일관성을 보장하지 못한다.

그리고 이 문제는 시간이 갈수록 ‘저절로’ 악화된다는 특징이 있다. 색이 한 종일 때는 새 페이지를 만드는 사람이 그 한 종을 따라 쓰기 쉽다. 그런데 이미 다섯 종, 열 종이 흩어진 상태라면, 새 페이지를 만드는 사람은 ‘그중 뭐가 진짜 표준인지’를 알 수 없다. 그래서 또 자기 눈에 맞는 걸 하나 골라 박는다. 혼란이 또 다른 혼란을 부르는 구조다. 즉 색 난립은 ‘한번 일정 수준을 넘으면’ 방치만 해도 알아서 더 심해진다. 그래서 더더욱 ‘쌓이기 전에 막는’ 게 압도적으로 싸다.

■ ‘제멋대로’의 정의 — 결정을 매번 새로 하는 상태

색이 제멋대로라는 걸 사람들은 흔히 ‘색 감각이 없다’ 정도로 오해한다. 그게 아니다. 색이 제멋대로라는 건 ‘색을 매번 새로 결정한다’는 뜻이다.

생각해 보자. 새 페이지에 버튼을 하나 넣어야 한다. 브랜드 색이 한 곳에 적혀 있고 공유돼 있으면, 그 결정은 0초 만에 끝난다. “주요 행동 색을 가져다 쓰면 됨.” 끝. 그런데 그 약속이 없으면 매번 누군가 “이번 버튼은 무슨 파랑으로 하지?”를 새로 고민하고 새로 결정한다. 결정하는 사람이 다르고 시기가 다르니, 결과도 다르다. 페이지가 100개면 100번의 제각각인 결정이 코드에 쌓인다.

이 ‘매번 새로 결정하는 비용’은 생각보다 무겁다. 결정에는 시간이 들고, 그 결정을 다시 설명하는 데 또 시간이 들고, 나중에 ‘저번에 무슨 색으로 했더라’를 찾는 데 또 시간이 든다. 약속이 없는 조직은 같은 결정을 몇 번이고 반복한다. 작년에 누군가 ‘우리 파랑은 이거’라고 정했어도, 그게 코드 한곳의 변수로 기록되지 않으면 그 사람이 부서를 옮기는 순간 사라진다. 그리고 새 담당자가 와서 또 처음부터 고른다. 이렇게 ‘조직의 색 기억’이 사람에게만 의존하면, 사람이 바뀔 때마다 사이트의 색도 함께 흔들린다.

그래서 ‘색이 제멋대로’인 상태를 한 문장으로 정리하면 이렇다 — ‘공유되고 기록된 색 약속이 없어서, 매번 사람에 따라 색이 달라지는 상태.’ 이 정의를 기억해 두면 왜 색이 미관 문제가 아니라 운영 문제인지가 분명해진다. 예쁘냐 안 예쁘냐의 문제가 아니라, 예측 가능하냐 아니냐의 문제다.

이 ‘예측 가능함’이라는 말을 조금 더 풀어보고 싶다. 색이 약속돼 있으면, 그 사이트를 처음 보는 사람도 ‘아, 이 사이트에서 파란 건 누르는 거구나’를 한 번 익히면 어디서나 그 규칙이 통한다. 익숙해진다는 건 결국 ‘예측이 맞아떨어지는 경험’이 쌓이는 거다. 반대로 색이 제멋대로면 한 페이지에서 익힌 ‘파란 건 버튼’이라는 예측이 다음 페이지에서 빗나간다. 그러면 사용자는 매 페이지를 ‘처음 오는 곳’처럼 다시 더듬어야 한다. 익숙해질 기회를 주지 않는 사이트인 셈이다. 공공 사이트는 자주 오는 곳이 아니라 ‘필요할 때 어쩌다 한 번’ 오는 곳이 많다. 어쩌다 온 사용자일수록 ‘예측 가능함’이 절실한데, 색 난립은 바로 그 예측을 무너뜨린다.

한 가지 더. ‘운영 문제’라는 말에는 ‘사람이 바뀌어도 유지돼야 한다’는 뜻이 담겨 있다. 잘 굴러가는 색 약속은 담당자가 바뀌어도, 외주가 교체돼도 흔들리지 않는다. 왜냐하면 약속이 사람 머릿속이 아니라 코드와 문서에 적혀 있기 때문이다. 가이드는 결국 ‘조직의 색 기억을 사람 바깥에 저장하는 장치’다. 이 관점에서 보면 색 정리는 ‘디자이너의 일’이 아니라 ‘조직 운영의 일’에 가깝다. 누가 와도 같은 결과가 나오게 만드는 것 — 그게 운영의 본질이고, 색 약속은 그 운영을 디자인 영역에서 실현하는 도구다.

【본론 2 — 색 난립이 부르는 다섯 가지 붕괴】

이제 색이 통제 불능이 되면 구체적으로 무엇이 망가지는지를 보자. 점검 현장에서 거의 매번 함께 따라오는 단골 증상들이다. 이 다섯 가지는 따로 떨어진 게 아니라 대개 한 묶음으로 나타난다. 원인이 ‘색 약속이 없다’ 하나니까, 증상도 한꺼번에 온다.

■ 붕괴 1: 색 하나 바꾸려다 ‘전수조사’가 시작된다

가장 먼저 터지는 건 ‘변경 비용’이다. 앞서 말한 그 ‘한 줄짜리 지시’를 다시 떠올려 보자. “우리 기관 파랑을 조금 더 밝게.” 색이 한 곳에 모여 있는 사이트라면, 이건 변수 하나를 수정하는 일이다. 5분이면 끝난다. 그런데 수십 종의 파랑이 코드 곳곳에 흩어진 사이트에서는 이야기가 완전히 달라진다.

먼저 ‘어디에 어떤 파랑이 쓰였는지’를 전부 찾아야 한다. 수백, 수천 줄의 코드를 뒤지며 파란색 값을 일일이 색출한다. 그런데 여기서 진짜 어려운 문제가 생긴다. 찾아낸 파랑들 중에서 ‘바꿔야 할 브랜드 파랑’과 ‘건드리면 안 되는 다른 파랑(예: 링크색, 정보 알림색)’을 구분해야 한다. 둘 다 비슷한 파랑이라 코드만 봐서는 구분이 안 된다. 잘못 바꾸면 멀쩡하던 링크색까지 함께 바뀌어 새로운 사고가 난다. 그래서 한 군데 한 군데 ‘이건 브랜드 파랑인가, 다른 용도의 파랑인가’를 판단하며 신중하게 고쳐야 한다.

여기서 토큰이 있었다면 어땠을지를 잠깐 그려보자. 토큰을 썼다면 ‘브랜드 파랑’과 ‘링크 파랑’은 애초에 다른 이름의 변수로 분리돼 있었을 거다. 그러면 브랜드 파랑 변수 하나만 바꾸면 되고, 링크 파랑은 손도 안 댄다. 구분할 필요조차 없다. 이름이 이미 구분해 두었으니까. 반대로 토큰 없이 색값을 직접 박은 사이트에서는, 코드에 적힌 건 ‘색의 값’뿐이고 ‘색의 의미’는 어디에도 안 적혀 있다. 그러니 같은 파랑값을 보고 ‘이게 브랜드용인지 링크용인지’를 사람이 매번 추리해야 한다. 토큰의 핵심 가치가 바로 이 ‘의미의 기록’에 있다. 토큰은 색에 값만이 아니라 ‘이건 무엇을 위한 색이다’라는 의미까지 함께 적어둔다. 그래서 나중에 누가 봐도, 어떤 색을 바꿔도 되고 어떤 색은 건드리면 안 되는지가 코드만 봐도 분명하다.

다 고쳤다고 끝이 아니다. 빠뜨린 곳이 없는지 사이트 전체를 다시 검수해야 한다. 100개 페이지를 일일이 열어 ‘옛날 파랑이 남아 있지 않나’ 확인한다. 그러다 보면 꼭 한두 군데 놓친 곳이 발견되고, 다시 고치고, 다시 검수한다. 5분이면 될 일이 몇 주짜리 작업이 되는 거다. 그리고 이런 변경은 한 번으로 끝나지 않는다. 기관 통합, 브랜드 개편, 상위 기관의 가이드 변경 — 색을 한꺼번에 바꿔야 할 일은 주기적으로 찾아온다. 그때마다 같은 지옥이 반복된다. 이게 바로 ‘디자인 부채의 이자’다. 평소엔 안 보이다가 변경이 필요한 순간 청구서로 날아온다.

이 변경 비용에는 숨은 항목이 하나 더 있다. 바로 ‘무서워서 못 건드리는 비용’이다. 색이 어디에 어떻게 박혀 있는지 아무도 정확히 모르는 사이트에서는, 색을 바꾸자는 제안 자체가 부담스럽다. ‘건드렸다가 어디가 깨질지 모른다’는 불안 때문이다. 그래서 분명히 손봐야 할 색인데도 ‘일단 두자’가 반복된다. 이건 단순히 작업이 미뤄지는 게 아니라, 사이트가 점점 ‘손댈 수 없는 상태’로 굳어간다는 뜻이다. 시간이 지날수록 부채는 커지고, 커질수록 더 못 건드리고, 못 건드리니 더 방치되고, 방치되니 더 커진다. 이 악순환에 한번 들어가면 빠져나오기가 정말 어렵다. 그래서 색 정리는 ‘여유 있을 때 미리’ 해야지, ‘급할 때 한 번에’는 거의 불가능에 가깝다.

또 하나, 이 변경 비용은 ‘돈’으로만 청구되지 않는다. 담당자의 ‘마음의 비용’으로도 청구된다. 윗선의 ‘색 하나 바꾸는 거 아니냐’는 가벼운 인식과, 실제로는 몇 주가 걸리는 현실 사이의 간극을 담당자가 온몸으로 받아낸다. ‘왜 이렇게 오래 걸리냐’는 추궁을 들으면서도 ‘예전 사람들이 색을 제각각 박아놔서요’라고 설명하기도 민망하다. 결국 묵묵히 야근으로 메운다. 잘 정리된 색 약속 하나가 담당자에게 주는 가장 큰 선물은, 어쩌면 ‘색 바꾸라는 지시에 당당히 5분 만에 끝낼 수 있는 마음의 여유’일지도 모른다.

■ 붕괴 2: 색의 ‘의미’가 무너진다

색 난립의 더 무서운 점은 ‘의미’까지 흐트러진다는 거다. 잘 설계된 사이트에서 색은 단순한 장식이 아니라 신호다. 빨강은 경고나 삭제, 초록은 성공이나 완료, 파랑은 주요 행동 — 이렇게 색마다 역할이 있다. 사용자는 이 신호를 무의식적으로 학습하고, 그 학습에 기대 빠르게 판단한다. ‘아, 빨간 버튼이니까 조심해서 눌러야지’ 하는 식이다.

그런데 색이 통제 불능이 되면 이 신호 체계가 무너진다. 한중앙부처의 어떤 가상 페이지에서는 빨강이 ‘중요 공지’인데, 다른 페이지에서는 같은 빨강이 그냥 ‘제목 강조’다. 어떤 페이지의 파랑 박스는 ‘안내 정보’인데, 옆 페이지의 비슷한 파랑 박스는 ‘눌러야 하는 버튼’이다. 이렇게 같은 색이 페이지마다 다른 의미로 쓰이면, 사용자는 색이 주는 신호를 더 이상 믿지 못한다. 결국 색을 정보로 읽지 않고 무시하게 된다. 정작 진짜 경고를 빨강으로 띄워도 ‘또 그냥 강조겠지’ 하고 넘겨버리는 거다. 색의 일관성은 미관 문제가 아니라 ‘정보 전달의 신뢰’ 문제다.

이게 공공 사이트에서 특히 위험한 이유가 있다. 공공 정보에는 ‘놓치면 안 되는 경고’가 많다. 신청 마감일, 서류 누락 안내, 잘못 입력 경고, 환급·과태료 같은 금전 관련 알림. 이런 것들을 사용자가 ‘색 신호’로 빠르게 알아채야 하는데, 색의 신뢰가 무너진 사이트에서는 그 경고가 묻혀버린다. 결국 ‘몰라서 못 한’ 민원이 늘고, 그 화살은 다시 담당 부서로 돌아온다. 색의 일관성을 지키는 건 단순히 보기 좋자는 게 아니라, ‘중요한 것을 중요하게 보이게’ 하는 안전장치를 지키는 일이다.

색이 신호라는 걸 가장 절실하게 느끼는 순간은, 사용자가 ‘바쁠 때’다. 사람은 화면을 차분히 정독하지 않는다. 특히 신청이나 민원 같은 ‘일을 처리하러’ 온 사용자는 화면을 훑으며 빠르게 다음 행동을 찾는다. 이때 색은 ‘읽지 않고도 알아채는’ 정보다. 빨강이 보이면 멈칫하고, 파랑 버튼이 보이면 ‘여기 누르면 되겠구나’ 한다. 글자를 한 자 한 자 읽기 전에, 색이 먼저 길을 안내하는 거다. 그런데 그 색 신호가 페이지마다 제멋대로면, 사용자는 ‘훑어서 알아채는’ 능력을 쓸 수가 없다. 매번 글자를 다 읽어 확인해야 한다. 이건 단순히 불편한 정도가 아니라, 사이트를 ‘빠르게 쓸 수 없게’ 만드는 거다. 색의 일관성은 사용자에게 ‘읽지 않아도 되는 편의’를 돌려주는 일이다.

반대로 색 신호가 잘 지켜진 사이트는, 사용자가 ‘안심하고 빠르게’ 행동한다. 초록은 ‘잘 됐다’, 빨강은 ‘조심해라’, 파랑은 ‘여기를 눌러라’가 사이트 전체에서 한결같으면, 사용자는 그 약속을 믿고 망설임 없이 움직인다. 이 ‘믿고 움직임’이 쌓이면 사이트에 대한 신뢰가 된다. 신뢰는 거창한 데서 오는 게 아니라, 이렇게 ‘예상한 대로 동작한다’는 작은 경험들이 모여 만들어진다. 색 한 종을 통일하는 일이 사소해 보여도, 그 끝에는 ‘믿을 수 있는 사이트’라는 큰 결과가 달려 있다.

■ 붕괴 3: 글자가 안 읽히는 색 조합이 생긴다 (접근성)

색을 눈대중으로 박으면 접근성에서 바로 사고가 난다. 핵심은 ‘대비’다. 배경색과 글자색의 명암 차이가 충분하지 않으면, 저시력 사용자나 밝은 야외에서 휴대폰을 보는 사용자는 글을 읽지 못한다. 이건 취향의 문제가 아니라 ‘읽힘/안 읽힘’의 문제다.

그런데 색이 제멋대로인 사이트는 이 대비 기준을 지키기가 거의 불가능하다. 매번 다른 파랑을 배경이나 글자에 쓰니, 어떤 조합은 우연히 대비가 충분하고 어떤 조합은 미달이다. 문제는 그걸 ‘일일이 검사할 방법이 없다’는 거다. 색이 수십 종이고 조합이 수백 가지인데, 어느 조합이 대비 통과이고 어느 조합이 탈락인지를 사람이 손으로 다 확인할 수는 없다. 그래서 색 난립 사이트에는 ‘우연히 안 읽히는 글자’가 곳곳에 숨어 있게 된다.

표준 색 팔레트를 정해두면 이 문제가 근본적으로 풀린다. 쓰는 색이 정해진 몇 종으로 줄어드니, 그 색들의 조합이 대비 기준을 통과하는지를 미리 검증해 둘 수 있다. ‘이 글자색-배경색 조합은 통과’라는 걸 한 번 확인해 두면, 그 조합을 쓰는 모든 페이지가 자동으로 안전해진다. 색을 통제한다는 건 결국 ‘누구나 읽을 수 있는 사이트’로 가는 첫걸음이기도 하다. 색 통일은 미관 작업이자 동시에 접근성 작업인 셈이다. 참고로 웹접근성 한국형 지침(KWCAG)은 33개 항목으로 이런 것들을 점검하는데, 색 대비는 그 중에서도 가장 기본에 속하는 항목이다.

여기에 ‘색만으로 정보를 구분하지 말라’는 또 다른 원칙도 색 난립과 맞물린다. 색을 구분하기 어려운 사용자도 정보를 똑같이 받아야 하므로, 중요한 구분은 색 외에 글자나 모양 같은 보조 신호로도 알려줘야 한다. 예컨대 ‘필수 입력’을 빨간색으로만 표시하면, 그 빨강을 구분 못 하는 사용자는 무엇이 필수인지 알 수 없다. 그런데 색이 제멋대로인 사이트는 이런 ‘보조 신호’를 챙길 여력조차 없다. 색 자체가 통제 불능이니 ‘색 + 보조 신호’의 조합을 일관되게 설계할 수가 없는 거다. 결국 색의 난립은 ‘색을 구분 못 하는 사용자’를 두 번 소외시킨다. 색 신호도 못 믿게 만들고, 그걸 대신할 보조 신호도 못 챙기게 만든다. 색을 표준으로 정리한다는 건, 이런 보조 신호까지 체계적으로 설계할 토대를 마련하는 일이다.

그리고 접근성은 ‘남을 위한 배려’로만 생각하기 쉬운데, 사실은 ‘모두를 위한 기본기’다. 색 대비가 충분한 화면은 저시력 사용자만 잘 읽는 게 아니라, 밝은 햇빛 아래에서 휴대폰을 보는 보통 사용자, 오래된 모니터를 쓰는 사용자, 피곤한 눈으로 야근 중인 사용자 모두가 잘 읽는다. 공공 서비스는 특정 계층이 아니라 ‘국민 전체’를 대상으로 한다. 그래서 ‘누구 한 사람도 빠뜨리지 않는’ 색 설계가 곧 서비스의 기본 품질이 된다. 색을 표준화해 대비를 보장하는 일은, 결국 가장 많은 사람을 위한 가장 기본적인 친절이다.

■ 붕괴 4: 색이 흔들리니 그 위의 모든 것이 흔들린다

여기서 KRDS의 구조 이야기를 잠깐 해야겠다. 앞서 말했듯 846규칙은 기초(DS) → 컴포넌트(CP) → 기본 패턴(BP) → 서비스 패턴(SP)의 층으로 쌓여 있다. 색은 가장 아래 기초(DS)에 있다.

이게 왜 중요하냐면, 위층이 아래층을 ‘빌려 쓰기’ 때문이다. 컴포넌트인 버튼은 색을 어디서 가져올까. 기초에 정해둔 ‘주요 행동 색’을 빌려 온다. 버튼 안 글자색도, 비활성 상태의 회색도 다 기초의 색 약속에서 가져온다. 그러니 기초의 색이 들쭉날쭉하면 버튼도 자동으로 들쭉날쭉해진다. 그 들쭉날쭉한 버튼들이 모여 폼(BP)을 이루고, 폼이 모여 신청 흐름(SP)을 이룬다. 결국 최상단의 ‘신청 흐름이 어수선하다’는 증상의 진짜 원인이, 알고 보면 맨 아래 ‘색 약속이 없었다’는 데 있는 경우가 허다하다.

비유하자면 건물의 기초 공사다. 기초가 삐뚤면 1층은 약간 기울고, 2층은 더 기울고, 옥상은 위험할 만큼 기운다. 그래서 현장에서 사이트를 점검할 때, 사용자가 “신청 화면이 너무 정신없다”고 호소해도 우리는 가장 먼저 색·글꼴·간격 같은 기초부터 들여다본다. 증상은 위에서 터지지만 원인은 아래에 있을 때가 많기 때문이다. 색을 통제하는 건 단지 색 하나를 정리하는 게 아니라, 그 위에 쌓이는 모든 화면의 토대를 다지는 일이다.

이 ‘아래가 위를 떠받친다’는 구조 때문에, 색을 잡으면 ‘기대 이상의 효과’가 난다는 점도 강조하고 싶다. 색 약속 하나를 제대로 세우면, 그걸 빌려 쓰는 모든 버튼이 자동으로 정돈되고, 그 버튼으로 만든 모든 폼이 정돈되고, 그 폼으로 이뤄진 모든 신청 흐름이 정돈된다. 손은 한 군데(기초)에 댔는데 효과는 사이트 전체로 퍼지는 거다. 반대로 위에서부터 고치면 — 신청 흐름만 손보면 — 그 아래의 색이 여전히 제멋대로니, 고친 흐름도 곧 다시 어수선해진다. 그래서 ‘어디부터 고칠까’를 물으면 답은 거의 항상 ‘가장 아래, 색부터’다. 가장 적은 노력으로 가장 넓은 효과를 내는 지점이 거기이기 때문이다.

한 가지 덧붙이면, 이 기초 영역(DS) 120개 규칙은 ‘자동으로 검사하기 가장 좋은’ 영역이기도 하다. 색·글꼴·간격은 코드에 정확한 숫자로 박혀 있어서, 기계가 그 숫자를 읽어 표준과 비교하기 쉽다. 반대로 위층의 서비스 패턴 같은 건 ‘사용자가 실제로 써봐야’ 알 수 있는 부분이 많아 자동 검사가 까다롭다. 그래서 ‘무엇부터 자동으로 점검할 수 있나’를 따져도 답은 또 색·글꼴·간격, 즉 기초다. 고치기에도 가장 효율적이고, 점검하기에도 가장 명확한 영역 — 그게 색이 속한 기초 영역이다.

■ 붕괴 5: 부분 수리가 안 먹힌다

마지막 붕괴는 ‘고치기가 어렵다’는 거다. 색이 흔들린 사이트는 ‘부분 수리’가 잘 안 먹힌다. 눈에 띄는 메인 페이지 하나만 예쁘게 색을 정리해도, 옆 페이지로 넘어가면 다시 예전 파랑들이 난립한다. 사용자는 사이트를 페이지 단위로 보지 않고 ‘하나의 경험’으로 본다. 그래서 한 페이지만 잘 고치면 오히려 다른 페이지와의 격차가 도드라져서, ‘여기는 새로 했나 본데 저기는 왜 이래’ 하는 인상을 준다.

진짜 해결은 ‘색 약속을 한 곳에 정해두고, 모든 페이지가 그 약속을 공유하게’ 만드는 거다. 이게 색을 ‘페이지마다 칠하는 일’이 아니라 ‘시스템으로 관리하는 일’로 바꾸는 핵심이다. 그리고 이 ‘한 곳에 정해두고 공유한다’를 기술적으로 구현하는 장치가 바로 다음 본론에서 다룰 ‘디자인 토큰’이다.

여기서 ‘시스템’이라는 단어를 한 번 더 강조하고 싶다. 사람들은 디자인 시스템을 ‘예쁜 화면 모음’이나 ‘디자인 가이드 문서’ 정도로 생각하기 쉬운데, 핵심은 ‘시스템’에 있다. 시스템이란 ‘한 곳을 바꾸면 연결된 모든 곳이 함께 바뀌는 구조’를 말한다. 색을 페이지마다 따로 칠하면 그건 시스템이 아니라 ‘100개의 독립된 색칠’이다. 반면 색을 한 곳에 정의하고 모든 페이지가 그걸 참조하면, 비로소 ‘하나로 연결된 시스템’이 된다. 부분 수리가 안 먹히던 이유도 여기 있다. 시스템이 아닌 상태에서는 한 페이지를 고쳐도 다른 페이지와 연결돼 있지 않으니 따로 논다. 시스템으로 바꾸는 순간, 한 번의 수정이 전체에 퍼진다. 색을 정리한다는 건 결국 ‘따로 노는 색칠들’을 ‘하나로 연결된 시스템’으로 묶는 일이다.

【본론 3 — 해법: 디자인 토큰, 색에 ‘이름’과 ‘의미’를 붙이기】

■ 토큰이란 — 색을 ‘변수’로 바꾸는 일

디자인 토큰을 한마디로 풀면 ‘이름 붙인 디자인 값’이다. 색으로 좁혀 말하면, 파란색 값을 코드 곳곳에 직접 박는 대신 ‘브랜드-기본-파랑’이라는 이름의 변수에 한 번만 담아 두고, 필요한 곳에서는 그 이름을 불러 쓰는 방식이다.

차이는 명확하다. 색값을 직접 박으면, 그 색은 100군데에 100개의 복사본으로 흩어진다. 반대로 토큰으로 관리하면, 색은 한 곳에 ‘원본’으로 존재하고 100군데는 그 원본을 ‘참조’할 뿐이다. 그래서 원본 하나를 바꾸면 그걸 참조하던 100군데가 한꺼번에 바뀐다. 앞서 ‘5분이면 될 일이 몇 주가 된다’던 그 변경 지옥이, 토큰을 쓰면 정말로 5분 만에 끝나는 일이 된다. 토큰은 결국 ‘색을 한 곳에서 통제할 수 있게 만드는 장치’다.

KRDS는 이런 색 토큰을 무려 586개나 정의해 두고 있다. ‘색 하나에 토큰 586개씩이나?’ 싶을 텐데, 여기엔 이유가 있다. 색 토큰은 단순히 ‘파랑·빨강·초록’ 같은 원색 목록이 아니다. 같은 파랑이라도 ‘기본 파랑’이 있고, 그보다 진한 ‘강조 파랑’, 마우스를 올렸을 때의 ‘호버 파랑’, 눌렀을 때의 ‘활성 파랑’, 비활성일 때의 ‘흐린 파랑’, 배경으로 깔 때의 ‘옅은 파랑’ 등 ‘상태와 용도’별로 세분된다. 거기에 글자색, 배경색, 테두리색, 경고색, 성공색 같은 역할별 색까지 더해지면 숫자가 금세 1,000개를 넘어간다. 이렇게 촘촘하게 정의해 두는 이유는 단 하나, ‘담당자가 색을 직접 고를 일을 없애기 위해서’다. 필요한 모든 상황의 색이 미리 이름 붙어 준비돼 있으니, 만드는 사람은 ‘고르지’ 않고 ‘가져다 쓰면’ 된다.

이 586개라는 숫자를 처음 들으면 ‘너무 많아서 오히려 더 복잡한 거 아니냐’는 걱정이 들 수 있다. 그런데 실제로는 정반대다. 토큰이 촘촘할수록 ‘고민할 일’이 줄어든다. 예를 들어 토큰이 없는 상태에서 ‘비활성 버튼은 무슨 색으로 하지’를 고민하면, 그 답을 매번 새로 내야 한다. 반면 ‘비활성 버튼 배경색’이라는 토큰이 이미 정의돼 있으면, 고민 없이 그걸 불러 쓰면 된다. 토큰의 가짓수가 많다는 건 ‘이미 누군가가 그 많은 경우의 수를 다 고민해서 답을 적어뒀다’는 뜻이다. 그러니 토큰이 많을수록 ‘내가 새로 결정할 일’은 줄어든다. 586개는 부담이 아니라 ‘586번의 고민을 면제받는 것’이라고 보는 게 맞다.

또 하나 오해하기 쉬운 게, ‘이 586개를 다 외워야 하냐’는 거다. 전혀 아니다. 토큰은 외우는 게 아니라 ‘찾아 쓰는’ 거다. 잘 정리된 토큰은 이름만 봐도 용도를 짐작할 수 있게 체계적으로 명명돼 있다. ‘주요 행동 색’, ‘경고 배경색’, ‘본문 글자색’처럼 말이다. 그래서 만드는 사람은 ‘지금 내가 필요한 게 무슨 역할의 색인가’만 알면, 그 역할에 맞는 토큰을 찾아 쓸 수 있다. 색의 정확한 값(어떤 파랑인지)은 몰라도 된다. 알아야 할 건 ‘역할’뿐이다. 이게 토큰 체계가 주는 진짜 편리함이다. 색을 ‘기억’의 영역에서 ‘조회’의 영역으로 옮겨준다.

■ 토큰의 진짜 힘 — ‘무슨 색’이 아니라 ‘무슨 역할’

토큰의 더 깊은 힘은 ‘색에 의미를 붙일 수 있다’는 데 있다. 단순히 ‘파랑 한 종’이 아니라 ‘주요 행동 색’, ‘경고 색’, ‘배경 색’처럼 역할 이름을 붙여 관리하면, 디자인할 때 생각의 단위가 바뀐다. ‘무슨 색을 쓸까’가 아니라 ‘이건 무슨 역할인가’로 사고하게 된다.

예를 들어 신청 버튼에는 ‘주요 행동 색’을, 삭제 버튼에는 ‘경고 색’을, 단순 안내 박스에는 ‘정보 색’을 쓰는 식이다. 이렇게 역할로 관리하면 두 가지가 좋아진다. 첫째, 만드는 사람이 헷갈리지 않는다. ‘이건 가장 중요한 행동이니까 주요 행동 색’이라고 역할만 판단하면 색은 저절로 정해진다. 둘째, 나중에 ‘우리 주요 행동 색을 바꾸자’는 결정이 사이트 전체의 모든 신청 버튼에 일관되게 반영된다. 색이 그냥 숫자가 아니라 ‘의미를 가진 약속’이 되는 거다. 이게 토큰이 단순한 ‘색 모음’을 넘어 ‘디자인 언어’로 불리는 이유다.

이 ‘역할로 생각하기’가 익숙해지면, 디자인 결정의 속도와 품질이 동시에 올라간다. 예전엔 ‘이 버튼 무슨 파랑으로 하지’를 고민하며 색을 만지작거렸다면, 이제는 ‘이건 주요 행동인가 보조 행동인가’만 판단하면 끝이다. 판단의 차원이 ‘색의 미묘한 톤’에서 ‘기능의 명확한 역할’로 올라간 거다. 후자가 훨씬 판단하기 쉽고, 사람마다 답도 잘 갈리지 않는다. ‘무슨 파랑이 예쁜가’는 사람마다 다르지만, ‘이게 가장 중요한 행동인가’는 대체로 의견이 모인다. 그래서 역할 기반 토큰은 색을 ‘취향의 영역’에서 ‘논리의 영역’으로 옮긴다. 취향은 다투기 쉽지만 논리는 합의하기 쉽다. 색을 둘러싼 소모적인 ‘이게 더 예쁘다 저게 더 예쁘다’ 논쟁이, 토큰을 쓰면 ‘이건 무슨 역할이다’라는 명확한 대화로 바뀐다.

이 ‘역할 기반 색’은 앞서 말한 붕괴들을 한꺼번에 막는다. 의미가 흐트러지는 붕괴(붕괴 2)는 ‘경고 색은 오직 경고에만’이라는 약속으로 막힌다. 대비 미달 붕괴(붕괴 3)는 역할별 색 조합을 미리 검증해 두는 것으로 막힌다. 변경 지옥(붕괴 1)은 역할 색 하나만 바꾸면 끝나는 것으로 막힌다. 색 토큰 하나를 제대로 도입하면, 따로 놀던 다섯 가지 붕괴가 동시에 좋아지는 것이다. 원인이 하나였으니 처방도 하나로 통한다.

■ 그런데 토큰만 ‘선언’한다고 끝이 아니다 — 채택률 이야기

여기서 현장에서 가장 자주 보는 함정을 짚어야겠다. 많은 기관이 ‘우리는 디자인 토큰을 도입했다’고 말한다. 디자인 시스템 문서도 있고, 색 변수도 정의돼 있다. 그런데 막상 사이트를 점검해 보면, 정의된 토큰을 실제로는 거의 안 쓰고 여전히 옛날 방식대로 색값을 직접 박은 페이지가 수두룩하다. 토큰을 ‘선언’만 해놓고 ‘채택’은 안 한 상태다.

이게 가장 위험한 함정이다. 왜냐하면 ‘우리는 토큰 쓴다’는 안심 때문에 실제 난립을 못 보기 때문이다. B공공기관의 가상 사례를 들면, 디자인 가이드 문서에는 브랜드 파랑이 토큰으로 멋지게 정의돼 있었다. 그런데 실제 페이지 코드를 까보니, 그 토큰을 쓴 건 신규 페이지 일부뿐이고, 오래된 페이지·외주로 만든 페이지·급하게 올린 행사 페이지는 죄다 직접 박은 색이었다. 문서상으로는 ‘토큰 도입 완료’인데, 현실은 ‘토큰 채택률 30%’인 셈이다.

이런 ‘문서와 현실의 괴리’는 생각보다 흔하다. 디자인 가이드를 만드는 일과 그 가이드를 사이트 전체에 실제로 적용하는 일은 완전히 다른 작업이기 때문이다. 가이드 문서는 디자이너 몇 명이 몇 주면 만들 수 있지만, 그걸 수백 개 페이지에 빠짐없이 반영하는 건 훨씬 길고 지난한 작업이다. 그래서 많은 기관이 ‘문서는 완성, 적용은 미완’ 상태에서 멈춘다. 문제는 문서가 있다는 사실이 ‘다 됐다’는 착각을 부른다는 거다. 정작 점검해야 할 ‘실제 적용 상태’는 아무도 안 보고 넘어간다. 그래서 진짜 중요한 질문은 ‘가이드가 있느냐’가 아니라 ‘가이드대로 돼 있느냐’다. 그리고 그 질문에 답하려면 ‘문서’가 아니라 ‘실제 사이트 코드’를 봐야 한다. 이게 바로 자동 진단이 필요한 지점이다. 문서는 사람이 읽으면 되지만, 수백 페이지의 실제 적용 상태는 기계가 훑어야 비로소 진실이 드러난다.

그래서 색 일관성을 진짜로 관리하려면 ‘토큰을 정의했나’가 아니라 ‘토큰을 실제로 얼마나 쓰고 있나’를 측정해야 한다. 이걸 ‘토큰 채택률’이라고 부른다. 정의된 토큰 대비 실제 사용 비율, 그리고 토큰을 안 쓰고 직접 박은 색이 몇 군데인지를 숫자로 보는 거다. 이 숫자가 있어야 비로소 ‘우리 사이트의 색이 얼마나 통제되고 있는가’를 객관적으로 알 수 있다. 보이지 않던 ‘조용한 손해’를 숫자로 끌어내는 것 — 이게 다음에 소개할 도구의 핵심이다.

‘선언과 채택의 격차’가 왜 생기는지도 짚어두면 예방에 도움이 된다. 가장 흔한 경로는 ‘신규는 토큰, 기존은 방치’다. 새 페이지를 만드는 디자이너·개발자는 새로 정한 토큰 규칙을 따르지만, 이미 있던 수십·수백 개의 옛 페이지는 ‘건드리면 깨질까 봐’ 그대로 둔다. 그러니 시간이 지나도 옛 페이지의 직접 박은 색은 그대로 남는다. 두 번째 경로는 ‘급한 페이지’다. 행사·캠페인·긴급 공지처럼 빠르게 올려야 하는 페이지는 ‘일단 보이게만’ 하느라 토큰을 건너뛰고 색을 직접 박는다. 그 ‘일단’이 영구가 된다. 세 번째는 ‘외부에서 들어온 요소’다. 지도, 결제창, 외부 위젯처럼 바깥 서비스에서 가져온 요소는 그쪽의 색을 그대로 달고 들어와, 우리 토큰 체계 밖에 머문다. 이 세 경로를 알고 있으면, 채택률을 점검할 때 ‘어디를 의심해야 하는지’가 분명해진다. 옛 페이지, 급한 페이지, 외부 요소 — 이 셋이 거의 항상 채택률을 갉아먹는 주범이다.

그래서 ‘우리는 토큰을 도입했다’는 말은 출발점이지 도착점이 아니다. 도입은 ‘약속을 만든 것’이고, 채택은 ‘약속을 지키는 것’이다. 약속을 만들어 놓고 안 지키면 약속이 없는 것과 다를 바 없다. 오히려 ‘우리는 했다’는 착각 때문에 점검을 안 하게 되니 더 위험하다. 그래서 토큰을 도입한 기관일수록 ‘우리 채택률이 진짜 몇 %인가’를 주기적으로 재봐야 한다. 도입했다는 사실에 안심하지 말고, 지켜지고 있다는 증거를 숫자로 확인하는 습관 — 그게 색 일관성을 진짜로 유지하는 길이다.

【본론 4 — 보이지 않던 색의 난립을 ‘숫자’로 보는 법】

■ 자가 진단의 한계 — 사람 눈으로는 색 난립을 못 잡는다

여기까지 읽고 ‘그럼 우리 사이트는 어떨까’ 궁금해진 담당자라면, 가장 먼저 떠오르는 게 ‘직접 한번 봐야겠다’일 거다. 그런데 앞서 말했듯 사람 눈으로는 색 난립을 잡기가 거의 불가능하다. 비슷한 파랑 스무 종을 눈으로 구별할 수 없고, 100개 페이지의 모든 색을 손으로 뽑아 비교할 수도 없다. 자가 진단의 한계가 여기에 있다. 색 문제는 ‘느낌’으로는 ‘좀 어수선하네’까지밖에 못 간다. 그 너머의 ‘정확히 몇 종의 파랑이, 어느 페이지에, 토큰을 안 쓰고 박혀 있는가’는 도구의 영역이다.

그래서 우리는 ViewCheck를 만들었다. 공공 웹사이트의 KRDS 준수 상태를 자동으로 진단하는 서비스다. URL만 넣으면 페이지를 크롤링해서 색·글꼴·간격 같은 기초(DS)부터 컴포넌트·패턴까지 846규칙 기준으로 자동 점검한다. 사람이 못 보는 ‘코드 단위의 색’을 기계가 다 뽑아내 비교해 주는 거다.

■ ‘디자인 토큰 채택률’ 리포트가 보여주는 것

오늘 주제와 가장 맞닿은 기능이 바로 ‘디자인 시스템 탭’의 ‘디자인 토큰 채택률’ 리포트다. 이 리포트는 색 난립이라는 ‘보이지 않던 손해’를 정확히 숫자로 보여준다.

구체적으로 이 리포트는 이런 것들을 보여준다. 첫째, KRDS가 정의한 색 토큰을 우리 사이트가 실제로 얼마나 따르고 있는지를 ‘채택률 %’로 보여준다. 채택률이 높으면 ‘색이 통제되고 있다’는 뜻이고, 낮으면 ‘직접 박은 색이 많다=난립 중’이라는 뜻이다. 둘째, 토큰을 안 쓰고 직접 박은 색이 몇 종이나 발견됐는지를 보여준다. ‘비슷한 파랑 23종 발견’ 같은 식의, 사람 눈으로는 절대 못 잡는 숫자다. 셋째, 그 난립한 색들이 어느 페이지·어느 위치에 있는지를 짚어준다. 그래서 ‘어디부터 손대야 하나’라는 막막함이, ‘여기 이 23군데부터’라는 구체적 작업 목록으로 바뀐다.

특히 ViewCheck가 ‘여러 페이지를 함께 본다’는 점이 색 진단에서는 결정적이다. 색 난립은 한 페이지만 봐서는 잘 안 드러난다. 한 페이지 안에서는 파랑이 두세 종뿐이라 멀쩡해 보여도, 사이트 전체 100개 페이지를 모아 보면 그 두세 종이 페이지마다 미묘하게 달라서 결국 수십 종이 되는 식이다. 그래서 색 진단은 ‘사이트 전체를 한꺼번에 모아 비교하는’ 능력이 필요하다. ViewCheck는 여러 페이지를 크롤링해 색을 한데 모아 비교하기 때문에, ‘한 페이지에서는 안 보이던 전체 차원의 난립’을 잡아낸다. 사람이 페이지를 하나씩 열어보는 방식으로는 절대 도달할 수 없는 시야다.

또 이 리포트는 ‘좋다·나쁘다’의 막연한 평가가 아니라 ‘무엇을 어떻게 고치면 점수가 얼마나 오르는지’를 짚어주는 방향으로 설계돼 있다. 단순히 ‘채택률 낮음’이라고 끝내는 게 아니라, ‘이 색들을 표준 토큰으로 합치면 채택률이 이만큼 오른다’는 식의 실행 가능한 정보를 준다. 진단의 목적은 ‘혼내기’가 아니라 ‘고치기’이기 때문이다. 그래서 리포트를 받아 든 담당자가 ‘아 망했네’가 아니라 ‘아 이거부터 하면 되겠네’라고 느끼도록 만드는 데 초점을 둔다. 막막함을 줄이고 첫걸음을 명확히 하는 것 — 그게 좋은 진단 도구의 역할이라고 본다.

이게 왜 중요하냐면, 색 정리는 ‘마음먹기’가 아니라 ‘목록 만들기’에서 시작되기 때문이다. ‘우리 색을 좀 정리하자’는 다짐은 막연해서 잘 실행되지 않는다. 반면 ‘난립한 23종의 색이 여기 이 목록에 있으니, 이걸 5개 표준 색으로 합치자’는 구체적 목표는 실행된다. ViewCheck의 토큰 채택률 리포트는 그 ‘실행 가능한 목록’을 자동으로 만들어 준다.

그리고 이 리포트의 또 다른 쓸모는 ‘전후 비교’다. 색을 정리한 뒤 다시 진단을 돌리면, 채택률이 올라가고 직접 박은 색의 수가 줄어든 게 숫자로 확인된다. 그동안 ‘했는데 티가 안 난다’던 디자인 정리 작업이, 비로소 윗선에 보고할 수 있는 ‘성과 숫자’가 되는 거다. 막연했던 일이 측정 가능한 일로 바뀌는 순간, 일이 굴러가기 시작한다.

■ 진단은 색 하나에서 끝나지 않는다

색 이야기로 시작했지만, ViewCheck의 진단은 거기서 멈추지 않는다. 분석을 돌리면 화면 상단에 점수 카드가 뜬다. 디자인 기초(DS)·컴포넌트(CP)·기본 패턴(BP)·서비스 패턴(SP) 네 영역의 준수 점수가 한눈에 들어온다. 앞서 ‘색이 흔들리면 그 위의 모든 게 흔들린다’고 했는데, 이 점수 카드를 보면 그 연쇄가 실제로 보인다. 기초 점수가 낮은 사이트는 대개 그 위 영역 점수도 함께 낮다.

여기에 더해 ViewCheck는 행정안전부의 「전자정부 웹사이트 품질관리 지침」이 정한 7대 영역 — 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성 — 도 함께 점검한다. 색 대비처럼 접근성과 직결되는 항목은 KWCAG 33항목 기준으로도 확인한다. 즉 ‘색 하나가 궁금해서’ 시작한 진단이, 사이트 전체의 건강 검진으로 이어지는 셈이다. 색이라는 작은 창문으로 들여다봤더니, 사이트 전체의 상태가 보이는 거다.

이게 자가 진단으로는 도저히 불가능한 이유를 한 번 더 짚고 싶다. 846개 규칙을, 그것도 사이트 전체 페이지에 대해 사람이 손으로 점검한다고 생각해 보자. 색 한 종을 비교하는 것만으로도 벅찬데, 글꼴·간격·버튼·폼·신청 흐름까지 다 합치면 사람이 며칠을 매달려도 끝나지 않는다. 게다가 사람은 피곤하면 놓치고, 같은 걸 두 번 보면 다르게 판단하기도 한다. 반면 기계는 846개 규칙을 같은 기준으로, 빠짐없이, 매번 동일하게 점검한다. 자동 진단의 가치는 ‘사람보다 똑똑해서’가 아니라 ‘사람이 지치고 놓치는 일을 지치지 않고 빠짐없이 해서’다. 색 난립처럼 ‘양이 많고 미세한’ 문제일수록, 기계의 이 우직함이 진가를 발휘한다.

그리고 진단 결과는 ‘점수’로만 끝나지 않고 ‘근거’와 함께 제시된다. ‘점수가 낮다’가 아니라 ‘어느 규칙을 어디서 어겼다’를 짚어주기 때문에, 담당자는 그 결과를 들고 곧바로 작업에 들어갈 수 있다. 또 이 근거는 외주 업체에 수정을 요청할 때도 큰 힘이 된다. ‘어쩐지 색이 어수선하니 다듬어 주세요’ 같은 막연한 요청 대신, ‘이 규칙들을 이 위치에서 어겼으니 표준 토큰으로 맞춰 주세요’라고 객관적 근거를 들어 요청할 수 있다. 발주처와 업체가 같은 진단 결과를 보고 일하면, ‘말이 다르다’는 소모적 다툼이 크게 줄어든다. 진단은 결국 발주처와 업체 모두에게 ‘공통의 언어’를 주는 셈이다.

【본론 5 — 색을 정리하는 현실적인 순서】

자, 그럼 색 난립을 발견했다고 치자. 무엇부터 해야 할까. 현장에서 효과를 본 순서를 정리해 본다.

■ 1단계: 멈추기 — ‘더 쌓이지 않게’가 먼저

색 부채도 빚이라, 갚기 전에 ‘더 늘지 않게 막는 것’이 첫 번째다. 지금부터 만드는 모든 새 페이지는 ‘직접 색을 박지 않는다’는 규칙을 세운다. 표준 색이 아직 정리 안 됐어도, 최소한 ‘새로 박는 색’은 멈춰야 한다. 그렇지 않으면 정리하는 사이에도 부채가 계속 불어난다. ‘나중에 한 번에 정리하자’가 거의 항상 실패하는 이유가 이거다. 정리하기로 한 그 ‘나중’이 올 때쯤이면 색이 더 늘어 있다.

이 ‘멈추기’를 실무로 옮기는 가장 확실한 방법은 ‘발주 문서와 작업 규칙에 한 줄을 박아두는 것’이다. 새 페이지·새 사업을 외주에 맡길 때 ‘KRDS 색 토큰을 준수하고, 색값을 직접 박지 말 것’이라는 조건을 명시한다. 이 한 줄이 있으면 업체도 처음부터 토큰 기준으로 작업하고, 발주처도 ‘토큰을 썼는지’로 검수할 수 있다. 반대로 이 한 줄이 없으면 업체는 ‘알아서 예쁘게’ 만들 수밖에 없고, 그 ‘알아서’가 또 새로운 색을 낳는다. 색 정리는 ‘우리가 직접 만들 때’보다 ‘남에게 맡길 때’ 더 절실하다. 발주 문서의 한 줄이, 5년 뒤 사이트의 색 상태를 좌우한다.

■ 2단계: 측정하기 — 현황을 숫자로

멈췄으면 현황을 잰다. 앞서 말한 토큰 채택률 리포트로 ‘지금 몇 종의 색이, 어디에, 채택률 몇 %로’ 쓰이고 있는지를 숫자로 확보한다. 이 숫자가 출발점이자 나중의 비교 기준이 된다. 측정 없이 정리에 들어가면 ‘얼마나 나아졌는지’를 영영 모른 채 막연한 작업만 반복하게 된다.

■ 3단계: 합치기 — 비슷한 색을 표준 색으로

발견된 ‘비슷한 파랑 23종’을 노려보며, 이걸 표준 색 몇 종으로 합칠지 정한다. 보통 사용자는 미세한 색 차이를 알아채지 못하므로, 스무 종 넘는 파랑도 서너 종의 표준 색으로 충분히 통합된다. 이때 중요한 건 ‘역할’로 정리하는 거다. ‘주요 행동 파랑’, ‘링크 파랑’, ‘배경 파랑’처럼 의미를 붙여 정리하면, 이후 관리가 훨씬 수월해진다.

합치는 과정에서 한 가지 주의할 점이 있다. ‘비슷하니까 무조건 하나로’가 아니라, ‘역할이 같은 것만 합친다’는 원칙을 지켜야 한다. 같은 파랑처럼 보여도 하나는 ‘버튼색’이고 하나는 ‘링크색’이면, 지금 당장은 색이 같더라도 역할이 다르니 토큰을 따로 두는 게 맞다. 나중에 ‘버튼색만 바꾸고 링크색은 유지’하고 싶은 순간이 반드시 오기 때문이다. 역할로 나눠두면 그때 버튼 토큰만 바꾸면 되지만, 역할 구분 없이 그냥 ‘같은 파랑’으로 묶어버리면 버튼을 바꾸는 순간 링크색까지 따라 바뀐다. 그래서 합치기의 기준은 ‘색이 비슷한가’가 아니라 ‘역할이 같은가’여야 한다. 이 구분을 처음에 잘해두면, 토큰 체계가 두고두고 유연하게 작동한다.

■ 4단계: 토큰화하고 바꿔치기

합칠 표준 색이 정해지면, 그걸 토큰(이름 붙은 변수)으로 등록하고, 코드 곳곳에 직접 박힌 색들을 하나씩 토큰 참조로 바꿔치기한다. 한 번에 다 못 해도 괜찮다. 트래픽이 많은 핵심 페이지부터, 그리고 새로 손대는 페이지부터 점진적으로 토큰으로 옮겨가면 된다. 중요한 건 ‘방향’이다. 모든 변경이 ‘토큰 쪽으로’만 가면, 시간이 지날수록 채택률은 자연히 올라간다.

■ 5단계: 재측정하고 지키기

정리가 어느 정도 됐으면 다시 진단을 돌려 채택률이 올랐는지 확인한다. 그리고 이걸 ‘일회성 이벤트’가 아니라 ‘정기 점검’으로 만든다. 분기에 한 번이든 개편 때마다든, 색 채택률을 주기적으로 재서 ‘다시 난립하고 있지 않은지’를 감시하는 거다. 색은 가만 둬도 다시 흐트러지는 성질이 있다. 새 사람이 오고, 외주가 바뀌고, 급한 페이지가 추가되면서. 그래서 ‘한 번 정리’가 아니라 ‘계속 지키기’가 진짜 관리다.

이 다섯 단계를 관통하는 정신은 ‘완벽하게 한 번에’가 아니라 ‘방향을 정해 꾸준히’다. 색이 수십 종 난립한 사이트를 하루아침에 다 정리하는 건 불가능하고, 무리하게 시도하면 오히려 사고가 난다. 대신 ‘새로 만드는 건 무조건 토큰으로, 손대는 김에 옛 페이지도 토큰으로’라는 방향만 일관되게 지키면, 시간이 갈수록 채택률은 저절로 올라간다. 중요한 건 속도가 아니라 방향이다. 모든 변경이 ‘토큰 쪽으로만’ 흐르게 만들어 두면, 어느 순간 사이트의 색이 깔끔하게 정리돼 있는 걸 발견하게 된다. 부채를 한 번에 갚으려 들지 말고, 더 이상 빚지지 않으면서 조금씩 갚아나가는 것 — 그게 가장 현실적이고 가장 확실한 길이다.

마지막으로, 이 과정의 ‘성과’를 윗선에 보고할 수 있게 숫자로 남기는 걸 잊지 말자. ‘색을 정리했습니다’는 막연하지만, ‘토큰 채택률이 분기 초 30%에서 분기 말 70%로 올랐고, 직접 박은 색이 40종에서 8종으로 줄었습니다’는 명확한 성과다. 디자인 정리 작업은 그동안 ‘했는데 티가 안 난다’는 평가를 받기 쉬웠는데, 채택률이라는 숫자가 있으면 그 노력이 비로소 ‘보이는 성과’가 된다. 보이는 성과는 다음 작업의 예산과 명분을 만들어 준다. 측정하고, 개선하고, 다시 측정해 성과를 남기는 이 선순환이, 색 관리를 ‘이벤트’에서 ‘문화’로 바꾸는 힘이다.

【 마무리 】

오늘 이야기를 한 문장으로 줄이면 이렇다. ‘색이 제멋대로인 건 색 감각의 문제가 아니라, 색을 한 곳에 적어두고 공유하는 약속이 없는 운영의 문제다.’

브랜드 파랑 하나가 수십 종으로 흩어지는 순간, 변경 비용이 폭발하고(붕괴 1), 색의 의미가 무너지고(붕괴 2), 안 읽히는 글자가 생기고(붕괴 3), 그 위에 쌓인 모든 화면이 함께 흔들리고(붕괴 4), 부분 수리로는 고쳐지지 않는(붕괴 5) 상태가 된다. 그리고 이 모든 게 ‘색 약속이 없다’는 단 하나의 원인에서 나온다. 원인이 하나니까, 해법도 하나다 — 색에 이름과 의미를 붙여 한 곳에서 관리하는 ‘디자인 토큰’, 그리고 그걸 실제로 얼마나 쓰는지를 재는 ‘토큰 채택률’.

가장 어려운 건 ‘우리 사이트가 지금 어떤 상태인지’를 아는 첫 단계다. 사람 눈으로는 안 보이니까. 그 보이지 않는 상태를 숫자로 바꿔주는 것만으로도, 막연했던 문제가 손에 잡히는 과제로 변한다. 그 첫 단계를 ViewCheck가 대신해 준다. krds.viewcheck.co.kr 에서 확인 수 있다. URL 하나만 넣으면, 디자인 시스템 탭의 ‘디자인 토큰 채택률’ 리포트가 우리 사이트의 색이 얼마나 통제되고 있는지를 숫자로 보여준다. ‘비슷한 파랑 몇 종이 어디에 박혀 있는지’까지 짚어주니, 막막했던 색 정리가 구체적인 작업 목록으로 바뀐다.

색 정리는 거창한 결심이 아니라 작은 측정에서 시작된다. ‘우리도 좀 어수선한 것 같은데’ 하는 막연한 느낌이 있다면, 오늘 한번 진단을 돌려 그 느낌을 숫자로 확인해 보길 권한다. 보이기 시작하면, 고칠 길도 보인다. 색이라는 작은 창문 하나가, 사이트 전체의 건강을 들여다보는 출발점이 되어줄 것이다.

돌이켜보면, 잘 정돈된 색을 가진 사이트는 사용자에게 한 가지 조용한 메시지를 던진다. ‘이곳은 잘 관리되고 있습니다’라는 메시지다. 사용자는 그 메시지를 의식적으로 읽지 않지만, 무의식적으로는 분명히 받아들인다. 그리고 그 인상이 ‘여기는 믿고 신청해도 되겠다’는 신뢰로 이어진다. 공공 서비스는 본질적으로 ‘믿고 맡기는’ 서비스다. 민원을 넣고, 개인정보를 입력하고, 신청을 맡긴다. 그 신뢰의 첫인상이 ‘정돈된 색’에서 시작된다는 걸 생각하면, 색을 통일하는 작은 작업이 결코 작지 않다는 걸 알 수 있다. 색은 사이트가 사용자에게 건네는 첫 악수 같은 거다. 그 악수가 단정하고 한결같으면, 그다음 대화도 한결 매끄러워진다.

다음 글에서는 오늘 잠깐 미뤄둔 ‘글꼴과 타이포 위계’ 이야기를 같은 방식으로, 익명 사례와 함께 풀어보겠다. 색 다음은 글꼴이다. 기초의 두 번째 기둥이다. 색과 글꼴, 그리고 간격까지 — 이 세 가지 기초가 단단해지면, 그 위에 올리는 버튼도 폼도 신청 흐름도 자연스럽게 정돈된다. 오늘의 색 이야기가 그 출발점이 되었으면 한다. 작은 색 하나를 통제하는 데서 시작해, 결국 사이트 전체가 한 몸처럼 움직이는 ‘시스템’으로 나아가는 그 길의 첫걸음 말이다. 그 첫걸음을 떼는 가장 쉬운 방법은, 오늘 우리 사이트의 색이 지금 어떤 상태인지를 한번 들여다보는 거다. 보는 데서 모든 게 시작된다.

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

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