감으로 ‘괜찮겠지’ 했다가 놓치는 것들

공감·문제제기

솔직히 고백부터 하자. 나도 '괜찮겠지'를 참 많이 했다. 공공 사이트를 점검하는 일을 하면서도, 새 페이지 하나 만들 때 '이 정도면 됐지' 하고 넘긴 게 한두 번이 아니다. 그런데 그렇게 '감으로 괜찮겠지' 하고 넘긴 것들이, 시간이 좀 지나서 보면 거의 다 문제로 돌아왔다. 그것도 처음엔 아주 작게, 티도 안 나게 돌아왔다가, 나중엔 '이걸 진작 잡았어야 했는데' 싶은 큰 일로 커져 있었다.

오늘은 그 이야기를 하려고 한다. 공공 사이트를 만들고 운영하는 사람이라면 누구나 한 번쯤 해봤을 그 말, '괜찮겠지'. 이 한마디가 어떻게 사이트를 조용히 갉아먹는지, 가상의 ○○시·A광역지자체·한중앙부처·B공공기관 사례를 통해 구체적으로 풀어볼 생각이다. 미리 말해두는데, 이건 누굴 흉보려는 글이 아니다. 등장하는 사례는 전부 익명이고, 실제 어떤 기관을 가리키지도 않는다. 다만 현장에서 점검을 하다 보면 기관 종류·규모와 상관없이 '판박이처럼' 반복되는 장면들이 있는데, 그 전형을 모아 보여주는 거다.

먼저 '감으로 괜찮겠지'가 왜 그렇게 위험한지부터 짚자. 사람의 감은 의외로 믿을 게 못 된다. 특히 '디자인'이나 '사용성' 같은 영역에서는 더 그렇다. 왜냐하면 그 사이트를 만든 사람은 '이미 그 사이트를 다 아는 사람'이기 때문이다. 어디에 뭐가 있는지, 이 버튼을 누르면 어디로 가는지, 이 글자가 작아도 무슨 내용인지 — 만든 사람은 다 안다. 그래서 만든 사람의 눈에는 늘 '괜찮아' 보인다. 정작 그 사이트를 처음 보는 사용자, 작은 글씨가 안 보이는 어르신, 키보드로만 화면을 쓰는 사용자, 한 손으로 휴대폰을 든 채 급하게 신청을 하려는 사용자 — 이런 사람들의 눈으로는 한 번도 본 적이 없다. '괜찮겠지'는 결국 '내 눈에는 괜찮다'는 말일 뿐이다. 그런데 공공 사이트는 '내'가 쓰는 게 아니라 '모두'가 쓴다.

그래서 '감'의 빈자리를 메우는 게 '기준'이다. 행정안전부가 만든 KRDS(공공 디자인 시스템)와 「전자정부 웹사이트 품질관리 지침」 같은 공식 기준은, 다른 말로 하면 '감으로 놓치기 쉬운 것들을 빠짐없이 적어둔 점검표'다. 만든 사람의 눈에는 안 보이지만 사용자에게는 치명적인 그 '사각지대'를, 누군가 미리 정리해 둔 거다. 기준이 있으면 '괜찮겠지' 대신 '이 항목 지켰나?'로 물을 수 있다. 감이 아니라 확인으로 바뀌는 거다. 오늘 글의 큰 줄기가 바로 이거다 — '괜찮겠지'를 '확인했나'로 바꾸는 일.

여기서 솔직하게 한 가지 더 인정하자. 우리가 '괜찮겠지'를 하는 진짜 이유는 게을러서가 아니다. 시간이 없어서다. 마감은 코앞이고, 처리할 민원은 쌓였고, 새로 만들 페이지는 줄을 섰다. 그 와중에 '이 버튼이 키보드로도 눌리나?', '이 글자가 어르신 눈에도 보이나?'를 일일이 챙길 여유가 없다. 그래서 '일단 돌아가니까 괜찮겠지' 하고 넘긴다. 이해한다. 정말 이해한다. 그런데 바로 그렇기 때문에 '기준'과 '자동 점검 도구'가 필요하다. 사람이 매번 모든 걸 챙길 수 없으니, 챙길 항목을 정해두고(기준), 그걸 자동으로 확인해주는 장치(도구)를 두는 거다. 바쁠수록 감에 의존하면 안 되고, 바쁠수록 도구에 기대야 한다. 이게 오늘 글이 도달하려는 지점이다.

조금 더 솔직히 털어놓자면, '괜찮겠지'에는 묘한 중독성이 있다. 한 번 '괜찮겠지'로 넘겼는데 아무 일도 안 일어나면, '거봐, 괜찮았잖아' 하는 안도가 생긴다. 그 안도가 다음 '괜찮겠지'를 더 쉽게 만든다. 그렇게 두 번, 세 번 넘기다 보면 '괜찮겠지'가 습관이 된다. 문제는, 아무 일도 안 일어난 게 아니라 '아직 안 들킨' 것뿐이라는 데 있다. 손해는 조용히 쌓이고 있는데, 표면적으로는 평온하니 '괜찮다'고 착각하는 거다. 이 착각이 깨지는 순간은 대개 두 가지다. 하나는 위에서 '우리 사이트 왜 이래'라는 지적이 내려올 때, 다른 하나는 큰 개편이나 점검을 앞두고 '그동안 쌓인 게 다 드러날 때'다. 그때서야 '아, 진작 봤어야 했는데' 하고 후회한다. 후회의 크기는 '괜찮겠지'를 반복한 시간에 비례한다.

그리고 이런 '괜찮겠지'들의 공통점이 하나 있다. 큰 사고처럼 빨간불이 켜지지 않는다는 거다. 서버가 다운되면 바로 안다. 결제가 안 되면 민원이 빗발친다. 그런데 '버튼 위계가 없어서 사용자가 헷갈린다'거나 '색 대비가 부족해 어떤 사용자는 글을 못 읽는다'는 문제는 아무도 신고하지 않는다. 그 사용자는 그냥 '좀 불편하네' 하고 조용히 떠난다. 통계에는 '이탈'로만 찍히지, '왜' 떠났는지는 안 찍힌다. 그래서 이런 문제는 '있다는 걸 인지하는 것' 자체가 가장 어렵다. 오늘 이 글의 목적은 그 '보이지 않는 손해'를 눈에 보이게 만드는 거다. 보이기 시작해야 고칠 마음이 생기니까. 자, 그럼 '괜찮겠지'가 실제로 무엇을 놓치는지, 현장 사례로 하나씩 들어가 보자.

개념·왜 중요한가

■ '감'이 자꾸 틀리는 이유 — 만든 사람의 저주

업계에 '지식의 저주'라는 말이 있다. 한번 무언가를 알게 되면, 그걸 모르던 상태로 돌아갈 수 없다는 뜻이다. 사이트를 만든 사람은 '이 화면의 모든 것을 아는' 상태가 돼버린다. 그래서 그 화면을 처음 보는 사람이 어디서 헤맬지, 무엇을 못 찾을지를 상상하기가 굉장히 어려워진다. '이게 왜 안 보여? 여기 떡하니 있는데' 싶은 순간, 사실 그 '떡하니 있는' 건 만든 사람에게만 떡하니 있는 거다.

가상의 사례를 하나 들어보자. A광역지자체 담당자가 새 보조금 신청 페이지를 만들었다. 신청 버튼을 화면 오른쪽 아래에 작게 두고, 그 위에 안내문을 길게 적었다. 담당자 눈에는 '신청 버튼이 당연히 보이는' 위치였다. 자기가 거기 뒀으니까. 그런데 실제 사용자들은 긴 안내문을 읽다가 지쳐서, 혹은 휴대폰 화면이라 버튼이 화면 밖으로 밀려나서, '신청은 어디서 하지?' 하고 한참을 헤맸다. 민원실에 '신청 버튼이 없다'는 전화가 왔다. 버튼은 분명히 있었다. 다만 '만든 사람 눈에만' 잘 보였을 뿐이다.

이게 '감'의 한계다. 감은 늘 '나'를 기준으로 작동한다. 그런데 공공 서비스의 사용자는 '내'가 아니다. 나보다 나이가 많거나 적고, 나보다 화면이 작거나 크고, 나와 다른 방식으로(마우스 대신 키보드로, 눈 대신 화면 낭독기로) 사이트를 쓴다. 이 다양한 사용자 모두를 머릿속으로 상상해서 챙기는 건, 아무리 베테랑이라도 불가능하다. 그래서 '감' 대신 '다양한 사용자를 대표하는 기준'이 필요한 거다. KRDS와 품질관리 지침은 그 '내가 미처 못 챙기는 사용자들'을 대신 챙겨주는 대리인인 셈이다.

조금 더 솔직하게 말하면, 감이 틀리는 데는 또 다른 이유가 있다. 우리는 '내가 본 것'을 '남도 똑같이 본다'고 착각한다. 같은 화면이라도 사람마다 보는 게 다르다. 어떤 사람은 화면 밝기를 최대로 켠 사무실에서 보고, 어떤 사람은 햇빛 쨍한 야외에서 본다. 어떤 사람은 27인치 모니터로, 어떤 사람은 손바닥만 한 폰으로 본다. 어떤 사람은 한눈에 화면 전체를 훑지만, 어떤 사람은 화면 낭독기가 위에서 아래로 한 줄씩 읽어주는 걸 '귀로' 듣는다. 만든 사람이 '내 환경'에서 '괜찮아 보였다'는 건, 수많은 사용 환경 중 단 하나에서만 확인했다는 뜻이다. 나머지 수십 가지 환경에서는 한 번도 안 본 거다. 그런데 우리는 그 '하나의 확인'을 '전체의 확인'으로 착각한다. 이게 '괜찮겠지'의 핵심 메커니즘이다.

그래서 나는 '괜찮겠지'를 '게으름'이 아니라 '구조적 한계'라고 부른다. 아무리 성실한 담당자라도, 아무리 실력 좋은 디자이너라도, '내 눈'이라는 한 개의 창문으로 세상을 볼 수밖에 없다. 그 창문 하나로 모든 사용자의 시야를 대신할 수는 없다. 이 한계를 인정하는 게 출발점이다. '나는 다 챙길 수 있어'가 아니라 '나는 못 챙기는 게 있을 수밖에 없어, 그러니 기준과 도구로 메우자'가 건강한 태도다. 일을 오래 한 사람일수록 이걸 빨리 받아들인다. 반대로 자기 감을 너무 믿는 사람일수록 '괜찮겠지'의 함정에 자주 빠진다.

한 가지 비유를 더 들면, 작가가 자기 글의 오타를 못 잡는 것과 비슷하다. 분명 열 번을 읽었는데도, 남이 한 번 보면 단번에 오타를 찾아낸다. 왜냐하면 작가는 '자기가 쓰려던 글'을 머릿속에 갖고 있어서, 실제로 쓰인 글이 아니라 '쓰려던 글'을 읽기 때문이다. 사이트를 만든 사람도 똑같다. '만들려던 화면'을 머릿속에 갖고 있어서, 실제 사용자가 마주하는 화면이 아니라 '이상적인 화면'을 본다. 그래서 '제3자의 눈'이 반드시 필요하다. 자동 점검 도구는 바로 그 '오타를 잡아주는 남의 눈' 역할을 한다. 감정 없이, 피로 없이, 빠짐없이, 화면을 '있는 그대로' 읽어준다.

■ '괜찮겠지'의 진짜 정체 — 검증을 건너뛴다는 것

'괜찮겠지'를 한 문장으로 정의하면 이렇다 — '확인을 생략하고 결과를 낙관하는 상태'. 핵심은 '확인의 생략'이다. 사실 '괜찮을지 아닐지' 자체는 죄가 아니다. 누구나 모든 걸 완벽히 알 순 없다. 문제는 '확인해보지 않고 괜찮다고 결론 내리는' 데 있다. 다리를 놓고 '튼튼하겠지' 하고 하중 시험을 건너뛰면, 그 다리는 무너질 때까지 '괜찮은 다리'다. 사이트도 똑같다. 검증을 건너뛴 '괜찮음'은 진짜 괜찮음이 아니라 '아직 안 들킨 문제'일 뿐이다.

그럼 무엇을 확인해야 하나. 여기서 KRDS의 구조가 도움이 된다. KRDS는 공공 웹이 갖춰야 할 것을 846개 규칙으로 잘게 쪼개 놓았다. 이게 막연하게 들릴 텐데, 사실 '괜찮겠지'로 넘기기 쉬운 것들을 846개의 구체적인 질문으로 바꿔놓은 목록이라고 보면 된다. '색이 통일됐나', '버튼 위계가 있나', '폼에 라벨이 붙었나', '신청 흐름이 매끄러운가' 같은 질문들 말이다. 846개는 다시 네 묶음으로 나뉜다. 가장 기초가 되는 디자인 스타일(DS) 120개, 화면의 부품인 컴포넌트(CP) 446개, 부품을 조합한 사용 패턴(BP) 108개, 그리고 신청·검색 같은 서비스 흐름(SP) 172개. 합하면 120+446+108+172 = 846이다.

이 숫자를 외우라는 게 아니다. 중요한 건 '우리가 감으로 넘기던 것들이 이렇게 많은 항목으로 쪼개질 수 있다'는 사실 자체다. '이 페이지 괜찮나?'라는 막연한 질문이, 'DS는 몇 개 지켰나, CP는, BP는, SP는?'이라는 측정 가능한 질문으로 바뀐다. 감이 측정으로 바뀌는 순간, '괜찮겠지'는 설 자리를 잃는다.

왜 '쪼개는 것'이 그렇게 중요할까. '이 사이트 좋게 만들어주세요'라는 요청은 너무 막연해서 아무도 책임 있게 답할 수 없다. '좋다'의 기준이 사람마다 다르기 때문이다. 그런데 '이 버튼에 호버 효과가 있나요?', '이 입력칸에 라벨이 붙어 있나요?', '이 색 대비가 기준을 넘나요?' 같은 질문은 '예/아니오'로 답이 떨어진다. 막연한 것을 '예/아니오로 답할 수 있는 작은 질문들'로 쪼개는 것 — 이게 모든 품질 관리의 기본이다. 비행기 정비사가 '비행기 괜찮나?'라고 감으로 판단하지 않고 수백 개 항목의 체크리스트를 하나씩 '예/아니오'로 확인하는 것과 똑같은 원리다. 공공 웹도 사람들의 생활과 직결되는 '공공 인프라'다. 감이 아니라 체크리스트로 다뤄야 마땅하다.

그리고 '쪼개기'에는 또 다른 이점이 있다. 문제를 '덩어리'로 보면 막막해서 손을 못 댄다. '우리 사이트 디자인이 엉망이다'라고 하면 어디서부터 손대야 할지 막막하다. 그런데 'DS 항목 중 색 관련 12개가 미달이다'라고 쪼개지면, '그럼 그 12개부터 보자'가 된다. 큰 산도 작은 계단으로 나누면 오를 수 있다. KRDS의 846규칙은 '공공 웹이라는 큰 산'을 846개의 작은 계단으로 나눠둔 지도다. 한꺼번에 다 오르라는 게 아니라, 한 계단씩 올라가라는 거다. 그리고 '지금 내가 몇 번째 계단에 있는지'를 알려주는 게 진단이다.

■ 망가짐은 '기초'에서 시작된다 — 한 부처의 사례

여기서 중요한 패턴 하나. 사이트 붕괴는 거의 항상 '기초(DS)'에서 시작된다. 색·글꼴·간격이라는 가장 작은 약속이 흔들리면, 그 위에 쌓는 부품(CP)도 흔들리고, 부품을 조합한 패턴(BP·SP)도 따라 무너진다. 건물의 기초가 삐뚤면 1층은 약간, 2층은 더, 옥상은 위험할 만큼 기우는 것과 똑같다.

한중앙부처의 가상 사례를 보자. 이 부처는 '신청 절차가 너무 불편하다'는 지적을 자주 받았다. 그래서 신청 페이지(SP 영역)만 새로 손봤다. 그런데 고치고 나서도 '여전히 어수선하다'는 평이 줄지 않았다. 왜였을까. 점검해보니 진짜 원인은 신청 페이지가 아니라 그 아래 기초에 있었다. 사이트 전체의 색이 제각각이고(DS), 버튼도 페이지마다 다르게 생겨서(CP), 신청 페이지만 아무리 예쁘게 고쳐도 '혼자만 다른 섬'처럼 보였던 거다. 신청 흐름이 매끄럽지 않다고 느낀 건 사실 '흐름' 자체보다 '각 단계 화면이 서로 안 어울려서'였다. 증상은 위(SP)에서 터졌는데, 원인은 아래(DS)에 있었다.

그래서 '괜찮겠지'를 가장 조심해야 할 영역이 바로 기초다. 색 하나, 간격 하나 같은 '작아 보이는' 것들이야말로 '이 정도면 괜찮겠지'로 넘기기 가장 쉽고, 동시에 사이트 전체에 가장 넓게 영향을 미친다. 작은 균열이 위로 갈수록 커지기 때문이다. 점검을 할 때 우리가 사용자의 '신청이 불편하다'는 호소를 듣고도 가장 먼저 DS부터 들여다보는 이유가 여기 있다. 증상을 따라가지 말고 원인을 따라가야 하는데, 그 원인은 대개 가장 밑바닥에 깔려 있다.

여기서 '간격' 이야기를 잠깐 따로 해야겠다. 색과 글꼴은 그래도 눈에 띄는 편인데, 간격은 가장 티 안 나게 사이트를 어수선하게 만드는 주범이다. 요소와 요소 사이의 여백, 문단과 문단 사이의 거리, 카드 안쪽의 패딩 — 이런 간격이 페이지마다, 요소마다 제각각이면 사이트가 '정렬이 안 맞는' 느낌을 준다. 사용자는 '뭔가 비뚤어 보인다'고 느끼지만 정확히 뭐가 문제인지는 짚지 못한다. 잘 만든 사이트가 '깔끔하다'고 느껴지는 이유의 절반은 사실 이 간격의 규칙성이다. KRDS가 간격을 일정한 단위로 정해두는 이유가 여기 있다. 간격에 규칙이 있으면 누가 만들어도 '정렬된' 화면이 나오고, 규칙이 없으면 아무리 색과 글꼴이 통일돼 있어도 어딘가 어수선하다. 기초의 세 요소 중 간격이 가장 과소평가되지만, 실은 가장 꾸준히 사이트의 인상을 좌우한다. '간격쯤이야 한두 픽셀 다른들 누가 알겠어, 괜찮겠지' — 이게 가장 위험한 '괜찮겠지' 중 하나다. 한두 픽셀의 차이가 수백 군데 쌓이면, 사이트 전체가 '대충 만든 느낌'을 풍긴다.

또 하나 기억해 둘 것. 기초가 흔들린 사이트는 '부분 수리'가 잘 안 먹힌다. 눈에 띄는 페이지 하나만 예쁘게 고쳐도, 옆 페이지로 넘어가면 다시 누더기다. 사용자는 사이트를 페이지 단위로 보지 않고 '하나의 경험'으로 본다. 그래서 한 페이지만 잘 만들면 오히려 다른 페이지와의 격차가 도드라져서, '여기는 새로 만들었나 본데 저기는 왜 이래' 하는 인상을 준다. 진짜 해결은 기초 약속을 정해두고 모든 페이지가 그 약속을 공유하게 만드는 거다. 이게 디자인 시스템을 '페이지 디자인'이 아니라 '시스템'이라고 부르는 이유다. '이 페이지만 급하니까 이것만 고치면 괜찮겠지'가 통하지 않는 이유이기도 하다.

흔한 실수·사례 (익명)

이제 '괜찮겠지'가 구체적으로 무엇을 놓치는지, 현장에서 거의 매번 만나는 단골 사례들을 보자. 미리 일러두면, 아래 사례들은 따로 떨어진 게 아니라 대개 함께 나타난다. '괜찮겠지'가 한 군데에서 보이면 다른 군데에서도 어김없이 보인다. 왜냐하면 이 모든 게 '검증을 건너뛰는 습관'이라는 하나의 원인에서 나오기 때문이다. 그러니 '우리도 저런데' 싶은 게 나와도 자책하지 마시라. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다. 중요한 건 그 패턴을 알아보는 눈이다.

■ 놓치는 것 1: '이 파랑이면 비슷하겠지' — 색 통제 불능

가장 흔한 '괜찮겠지'는 색에서 나온다. ○○시의 가상 사례를 보자. 부서마다, 사업마다 페이지를 만들 때 담당자나 외주가 '우리 시 색이 파랑이니까 이 정도 파랑이면 비슷하겠지' 하고 눈대중으로 색을 골라 코드에 박았다. 한 명이 한 번 그러는 건 별일 아니다. 그런데 그게 수십 명이, 수년에 걸쳐 쌓이면, 사이트 전체에서 미세하게 다른 파랑이 수십 종 발견되는 사태가 된다. 사람 눈에는 다 '파란색'인데, 코드를 들여다보면 어떤 건 진하고, 어떤 건 약간 연하고, 어떤 건 보라 끼가 돈다.

흥미로운 건, 이걸 만든 사람들 중 누구도 '색을 망치자'고 생각하지 않았다는 점이다. 다들 그 순간엔 '이 정도면 우리 사이트랑 어울리겠지'라고 최선을 다해 골랐다. 문제는 그 기준이 '머릿속에만' 있었다는 거다. 머릿속의 파랑은 사람마다 다르고, 같은 사람도 모니터가 바뀌면 다르게 본다. 어제 본 파랑과 오늘 고른 파랑이 미묘하게 다른데 본인은 같다고 믿는다. 이렇게 '각자의 머릿속 기준'으로 만든 결과물이 모이면, 개별로는 다 그럴듯한데 전체로는 제각각인 사이트가 된다. 색은 '잘 고르는 능력'의 문제가 아니라 '하나의 기준을 공유하느냐'의 문제다.

이게 왜 큰일이냐면, 나중에 브랜드 색을 바꿔야 할 때 지옥이 펼쳐지기 때문이다. '우리 시 파랑을 조금 더 밝게 바꾸자'는 단순한 요청이, 수십 종의 파랑이 흩어진 상태에서는 '어디에 어떤 파랑이 쓰였는지 전수조사'부터 해야 하는 대공사가 된다. 그리고 이런 상황은 생각보다 자주 온다. 기관 통합, 브랜드 개편, 상위 기관 가이드 변경 — 색을 한 번에 바꿔야 할 일은 주기적으로 생긴다. 그때마다 '색 하나 바꾸는 데 왜 이렇게 오래 걸리고 돈이 드냐'는 질문을 받는데, 답은 '색이 한 곳에 모여 있지 않아서'다. 정돈된 사이트라면 변수 하나 수정으로 끝날 일이, 통제 불능 상태에서는 수백 군데를 찾아 고치고 빠뜨린 곳이 없는지 다시 검수하는 큰 작업이 된다. 그 비용 차이가 바로 '괜찮겠지의 청구서'다. 평소엔 안 보이다가 변경이 필요한 순간 날아온다.

색 난립은 '의미'까지 무너뜨린다. 잘 설계된 사이트에서 색은 장식이 아니라 신호다. 빨강은 경고나 삭제, 초록은 성공, 파랑은 주요 행동. 그런데 색이 통제 불능이 되면 이 신호 체계가 깨진다. 어떤 페이지에선 빨강이 '중요 공지'인데, 다른 페이지에선 그냥 '제목 강조'다. 사용자는 색이 주는 신호를 더 이상 믿지 못하게 되고, 결국 색을 정보로 읽지 않고 무시한다. 정작 진짜 경고를 빨강으로 띄워도 '또 그냥 강조겠지' 하고 넘긴다. 색의 일관성은 미관 문제가 아니라 '정보 전달의 신뢰' 문제다.

그리고 색은 접근성과 바로 연결된다. 배경과 글자의 색 대비가 충분하지 않으면 저시력 사용자나 밝은 야외에서 보는 사용자가 글을 못 읽는다. 색을 눈대중으로 박는 사이트는 이 대비 기준을 지키기가 거의 불가능하다. 매번 다른 파랑을 쓰니 어떤 조합은 우연히 대비가 충분하고 어떤 조합은 미달인데, 그걸 일일이 검사할 방법이 없기 때문이다. 표준 색 팔레트를 정해두면 '이 조합은 대비 통과'라는 걸 미리 검증해 둘 수 있다. 색을 통제한다는 건 결국 '누구나 읽을 수 있는 사이트'로 가는 첫걸음이기도 하다.

이 '색 대비' 이야기는 조금 더 강조하고 싶다. 만든 사람은 시력이 좋고, 밝은 사무실에서, 선명한 모니터로 화면을 본다. 그 환경에서는 연한 회색 글씨도 '잘 보인다'. 그래서 '이 정도 연한 회색이면 세련돼 보이고 읽기도 괜찮겠지' 한다. 그런데 그 글씨를, 노안이 온 어르신이, 햇빛 아래에서, 오래된 폰으로 본다고 상상해보자. 거의 안 보인다. 디자인 잡지에서 자주 보이는 '연한 회색 본문'은 멋있어 보이지만 공공 사이트에서는 독이다. 공공 정보는 '멋'보다 '읽힘'이 먼저다. 색 대비 기준은 바로 이 '가장 안 좋은 환경의 사용자도 읽을 수 있나'를 숫자로 정해둔 안전선이다. 감으로 '보이겠지' 하지 말고, 그 숫자를 확인해야 한다. 그리고 이건 사람이 눈으로 일일이 재기 어렵다. 두 색의 대비를 정확히 계산하려면 도구가 필요하다. 또 한 번, 감이 아니라 도구의 영역이다.

마지막으로 색에 대해 '디자인 토큰'이라는 해법을 짧게 언급하고 넘어가자. 색을 '브랜드-기본-파랑'처럼 이름 붙은 변수로 한 곳에서 관리하면, 바꿀 때 그 변수 하나만 고치면 사이트 전체에 반영된다. 단순히 '파랑 한 종'이 아니라 '주요 행동 색', '경고 색', '배경 색'처럼 역할 이름을 붙여 관리하면, 디자인할 때 '무슨 색을 쓸까'가 아니라 '이건 무슨 역할인가'로 생각하게 된다. 색이 그냥 숫자가 아니라 '의미를 가진 약속'이 되는 거다. (이 디자인 토큰은 다음 달에 한 주제로 깊게 다룰 예정이다. 오늘은 '눈대중 색은 반드시 통제 불능으로 간다'는 것만 기억하면 충분하다.)

■ 놓치는 것 2: '글꼴쯤이야 괜찮겠지' — 글꼴 5종 잔치

두 번째 '괜찮겠지'는 글꼴이다. B공공기관의 가상 사례를 보자. 보도자료를 워드에서 복사해 붙이고, 다른 사이트의 표를 그대로 가져오고, 외부 위젯과 지도를 끼워 넣다 보니, 한 페이지에서 글꼴이 네다섯 종 섞여버렸다. 본문은 이 글꼴, 제목은 저 글꼴, 표는 또 다른 글꼴, 위젯은 시스템 기본 글꼴. 담당자는 '글꼴쯤이야 누가 신경 쓰겠어, 괜찮겠지' 하고 넘겼다.

그런데 글꼴이 섞이면 가독성과 신뢰감이 함께 떨어진다. 사용자는 '왜인지 모르게 어수선하다'고 느끼고, 정보를 읽는 데 미세한 피로가 쌓인다. 특히 '신뢰감'이 떨어진다는 건 공공 사이트에서 가볍지 않다. 사용자는 글꼴 일관성을 의식적으로 평가하진 않지만, 무의식적으로 '이 사이트가 잘 관리되고 있나'의 단서로 받아들인다. 글꼴이 들쭉날쭉한 페이지를 보면 '여기 정보가 최신일까', '이 신청 제대로 처리될까' 같은 막연한 불안이 생긴다. 공공 서비스는 본질적으로 '믿고 맡기는' 서비스다. 민원을 넣고, 개인정보를 입력하고, 신청을 맡긴다. 그 신뢰의 바탕이 '정돈된 화면'에서 시작된다는 걸 생각하면, 글꼴 통일은 단순한 미관 작업이 아니라 신뢰 관리 작업이다.

여기서 '괜찮겠지'가 한 번 더 숨어 있다. 바로 '글자 크기'다. 만든 사람은 큰 모니터에서 보니 '이 정도 크기면 괜찮겠지' 한다. 그런데 정작 그 정보가 가장 필요한 어르신이나 시력이 약한 분들에게는 깨알 같은 글씨가 된다. 공공 정보는 '누구나' 읽을 수 있어야 한다는 게 대전제인데, 본문이 작으면 그 대전제부터 무너진다. KRDS가 본문 최소 크기와 줄 간격까지 기준으로 두는 건 멋을 내려는 게 아니라 '읽을 사람을 빠뜨리지 않으려는' 배려다. 글꼴 통일이 신뢰의 문제라면, 글자 크기는 곧 '읽을 권리'의 문제다. 화면을 키우지 않아도, 안경을 고쳐 쓰지 않아도 편히 읽히는 크기 — 그게 공공 서비스가 지켜야 할 최소선이다.

타이포 '위계'도 짚어두자. 위계는 글꼴 종류를 통일하는 것 이상이다. 제목은 크고 굵게, 소제목은 그보다 작게, 본문은 읽기 편한 크기로, 부가 설명은 더 작고 연하게 — 이렇게 크기와 굵기로 '정보의 중요도'를 시각적으로 표현하는 게 위계다. 위계가 잘 잡힌 페이지는 사용자가 글을 '읽기 전에' 구조를 파악한다. 어디가 제목이고 어디가 본문인지 한눈에 보이니, 필요한 정보를 빠르게 찾는다. 공공 정보는 '찾으러 오는' 정보가 많다. 민원 방법, 신청 자격, 처리 기간 같은 걸 빠르게 찾아야 하는데, 위계 없는 페이지는 그 찾기를 방해한다. 글꼴 표준이 가독성을 지킨다면, 타이포 위계는 '찾기 쉬움'을 지킨다.

글꼴 난립이 생기는 경로도 알아두면 예방에 도움이 된다. 가장 흔한 건 '외부 콘텐츠 붙여넣기'다. 보도자료를 워드에서 복사해 붙이면 그 워드의 글꼴이 따라 들어온다. 다른 사이트의 표를 그대로 가져오면 그 사이트의 스타일이 묻어온다. 외부 위젯이나 지도, 결제창 같은 걸 끼워 넣으면 그 서비스의 기본 글꼴이 그대로 노출된다. 이렇게 '바깥에서 온 글꼴'이 하나둘 쌓여 한 페이지에 다섯 종이 공존하게 된다. 그래서 글꼴 통제는 '처음 디자인'보다 '운영 중 관리'의 문제인 경우가 많다. 콘텐츠를 올릴 때 글꼴을 표준으로 정리하는 작은 습관, 외부 요소를 넣을 때 스타일을 우리 기준으로 덮어쓰는 처리 — 이런 운영 규칙이 있어야 글꼴이 흐트러지지 않는다. '붙여넣은 그대로 둬도 내용만 맞으면 괜찮겠지'가 글꼴 잔치의 시작점인 셈이다.

그리고 여기서 한 가지 '괜찮겠지'의 함정을 더 짚자. 만든 사람의 컴퓨터에는 온갖 글꼴이 깔려 있다. 그래서 어떤 글꼴을 써도 본인 화면에선 멀쩡히 보인다. 그런데 그 글꼴이 사용자의 컴퓨터에는 없을 수 있다. 그러면 사용자 화면에서는 엉뚱한 기본 글꼴로 대체되어, 만든 사람이 의도한 것과 전혀 다른 모습이 된다. '내 화면에선 예쁘게 나오니 괜찮겠지' 했지만, 정작 사용자 화면에서는 깨진 모습인 거다. KRDS가 '공공 표준 서체'를 정해두는 이유 중 하나가 이거다. 누구의 컴퓨터에서도 똑같이 보이는, 공공이 보장하는 글꼴을 쓰자는 거다. 이런 건 만든 사람이 자기 화면만 봐서는 절대 발견할 수 없다. 여러 환경에서의 확인 — 다시 도구의 영역이다.

■ 놓치는 것 3: '버튼 다 비슷하면 알아서 누르겠지' — 정체불명의 버튼

세 번째는 버튼이다. 가이드 없는 사이트의 버튼은 정체가 불분명하다. 링크인지 버튼인지 모를 요소, 주 버튼과 보조 버튼이 똑같이 생겨 위계가 없는 화면, 비활성 상태인데 멀쩡해 보여 눌리는 버튼, 호버·포커스 시 아무 반응이 없는 버튼. 만든 사람은 '버튼 다 비슷하게 생겨도 알아서 누르겠지' 한다. 그런데 사용자는 '어느 걸 눌러야 하지?'를 매번 고민하게 된다.

'정체불명의 버튼'이 생기는 근본 원인은 '버튼에도 종류가 있다'는 걸 정해두지 않았기 때문이다. 잘 설계된 사이트는 버튼을 역할별로 나눈다. 가장 중요한 행동(신청하기, 제출하기)을 하는 주 버튼은 가장 눈에 띄게, 그 다음 행동(취소, 이전)을 하는 보조 버튼은 한 단계 차분하게, 위험한 행동(삭제)은 경고색으로, 단순 이동은 링크 형태로 — 이렇게 '이건 어떤 버튼이다'가 모양에서 드러나야 한다. 화면에 버튼이 다섯 개 있는데 다 똑같이 생겼다면, 그건 '선택지가 다섯 개'가 아니라 '혼란이 다섯 개'다. 버튼의 위계는 사용자가 '무엇을 해야 하는지'를 망설임 없이 알게 해주는 안내판이다.

특히 '반응 없는 버튼'은 접근성과 직결된다. 키보드로만 사이트를 쓰는 사용자는 지금 어디에 초점이 가 있는지 시각적 신호로 알아야 하는데, 그 신호가 없으면 길을 잃는다. '마우스로 눌러보니 잘 되네, 괜찮겠지' 하고 넘긴 버튼이, 키보드 사용자에게는 '아예 닿을 수 없는 벽'이 되는 거다. 만든 사람이 마우스로만 테스트하면 이걸 영영 발견하지 못한다.

버튼은 모바일에서 한 번 더 터진다. 손가락으로 누르는 환경에서는 버튼이 충분히 커야 정확히 눌린다. 가이드 없는 사이트의 버튼은 PC 화면 기준으로만 만들어져서, 모바일에서 너무 작거나 서로 너무 붙어 있는 경우가 많다. 누르려던 버튼 옆의 다른 버튼이 눌려 엉뚱한 페이지로 가거나, 잘못 신청 버튼을 눌러 당황하는 일이 생긴다. '내 폰에선 잘 눌리던데 괜찮겠지' 하지만, 손가락 큰 사용자, 손이 떨리는 사용자, 화면 작은 폰을 쓰는 사용자에게는 다르다. 공공 사이트는 디지털에 익숙하지 않은 사용자도 많이 쓴다. 버튼 하나가 작아서 못 누르면, 그 사용자에게 그 서비스는 '없는 서비스'나 마찬가지다. 표준은 누구나 정확히 누를 수 있는 최소 크기를 정해두어 이 문제를 막는다.

버튼 '글자'도 흔한 '괜찮겠지'다. 같은 기능인데 어떤 페이지에선 '신청', 어떤 페이지에선 '접수', 또 어떤 페이지에선 '제출하기'라고 적혀 있으면, 사용자는 '이게 같은 건가 다른 건가' 헷갈린다. 버튼 글자는 짧지만 사용자가 행동을 결정하는 핵심 단서다. 잘 만든 사이트는 '무슨 행동을 하는 버튼은 무슨 단어로 쓴다'는 것까지 약속해 둔다. '글자야 뭐 어때, 뜻만 통하면 괜찮겠지'가 아니라, 글자의 통일까지 챙겨야 진짜 일관성이다.

여기서 한 가지 짚고 넘어갈 게 있다. 위 네 가지 버튼 문제 — 정체불명, 위계 없음, 비활성 오인, 반응 없음 — 는 거의 항상 '함께' 나타난다. 버튼에 대한 약속이 없는 사이트는 이 네 가지를 한꺼번에 갖고 있다. 왜냐하면 원인이 하나, '버튼이라는 부품의 표준을 안 정했다'는 것이기 때문이다. 그래서 버튼 하나를 제대로 '표준 부품'으로 정의하면, 이 네 가지가 동시에 풀린다. 표준 버튼에는 '이건 주 버튼/보조 버튼/위험 버튼'이라는 역할 구분이 들어 있고(위계 해결), 비활성 상태의 모양이 정의돼 있고(오인 해결), 마우스를 올리거나 키보드로 선택했을 때의 반응이 내장돼 있다(반응 해결). 부품 하나를 잘 만들어 두고 그걸 '가져다 쓰기만' 하면, 매번 새로 만들면서 생기던 실수들이 통째로 사라진다. 이게 컴포넌트(CP)를 '표준화'하는 진짜 이유다. '예쁜 버튼을 만들자'가 아니라 '한 번 잘 만든 버튼을 모두가 똑같이 쓰자'는 거다.

■ 놓치는 것 4: '폼은 입력만 되면 괜찮겠지' — 라벨 없는 입력칸

네 번째는 폼이다. 신청·문의·민원 — 공공 사이트의 핵심 기능은 대부분 '폼에 입력하고 제출하기'다. 그런데 이 폼이야말로 '괜찮겠지'가 가장 많이 숨는 곳이다. 만든 사람은 '입력칸 있고, 제출 버튼 있고, 돌아가니까 괜찮겠지' 한다. 그런데 폼은 '돌아가는 것'과 '제대로 된 것' 사이의 간격이 가장 큰 영역이다.

가장 흔한 누락이 '라벨'이다. 입력칸 위나 옆에 '이름', '연락처', '주소' 같은 설명이 글자로 또렷이 붙어 있어야 하는데, 디자인을 깔끔하게 한답시고 입력칸 안에 흐린 회색 글씨(플레이스홀더)로만 표시하는 경우가 많다. 보기엔 깔끔하다. 그런데 사용자가 거기 글자를 입력하기 시작하면 그 안내 글씨가 사라진다. '어, 이 칸이 뭐였더라?' 하고 다시 지워서 확인해야 한다. 더 큰 문제는 화면 낭독기를 쓰는 시각장애 사용자다. 라벨이 제대로 붙어 있지 않으면, 낭독기가 '이 입력칸이 무엇을 위한 것인지'를 읽어주지 못한다. 그 사용자에게는 폼이 '정체 모를 빈칸들의 나열'이 되어, 신청 자체가 불가능해진다.

또 흔한 게 '오류 안내의 부실함'이다. 한중앙부처의 가상 사례에서, 긴 신청 폼을 다 채우고 제출 버튼을 눌렀더니 '입력 오류'라는 메시지만 빨갛게 떴다. 어느 칸이 잘못됐는지, 무엇을 어떻게 고쳐야 하는지는 안 알려줬다. 사용자는 처음부터 끝까지 모든 칸을 다시 훑으며 '어디가 틀렸지?'를 찾아야 했다. 그러다 지쳐서 신청을 포기한다. 만든 사람은 '오류 표시 떴으니 괜찮겠지' 했지만, 사용자에게 필요한 건 '오류가 있다'가 아니라 '어느 칸이, 왜, 어떻게'다. 잘 만든 폼은 오류가 난 칸 바로 옆에 '연락처는 숫자만 입력해 주세요'처럼 구체적으로 알려준다.

'필수 항목 표시'도 '괜찮겠지'의 단골이다. 무엇이 꼭 채워야 하는 칸이고 무엇이 선택인지 표시가 없으면, 사용자는 다 채워야 하나 망설이다가 불필요한 개인정보까지 입력하거나, 반대로 필수 칸을 빠뜨리고 제출했다가 위의 '불친절한 오류'를 만난다. 폼은 사용자가 가장 많은 '노동'을 하는 화면이다. 그 노동을 조금이라도 덜어주는 게 좋은 폼이고, '입력만 되면 괜찮겠지'는 그 노동을 사용자에게 통째로 떠넘기는 태도다.

폼에서 놓치기 쉬운 게 하나 더 있다. '긴 폼을 한 화면에 다 때려 넣는' 문제다. 신청서가 길면 만든 쪽은 '한 페이지에 다 있으면 한눈에 보여서 괜찮겠지' 한다. 그런데 사용자에게는 끝없이 이어지는 입력칸이 그 자체로 압박이다. '이걸 언제 다 채우지' 하는 부담에 시작도 전에 포기한다. 잘 만든 폼은 긴 입력을 의미 단위로 나눠서 '기본 정보 → 신청 내용 → 확인'처럼 단계로 보여준다. 그러면 사용자는 '지금은 이만큼만 하면 되는구나' 하고 한 걸음씩 나아간다. 또 입력 형식도 친절해야 한다. 전화번호를 '하이픈 넣어서'인지 '숫자만'인지 안 알려주면 사용자는 매번 추측해야 한다. 날짜를 직접 타이핑하게 하는 것보다 달력에서 고르게 하는 게 실수를 줄인다. 이런 '작은 친절'들이 쌓여 폼의 완성도를 만든다. '대충 칸만 있으면 알아서 채우겠지'는, 사용자에게 추측과 시행착오라는 비용을 떠넘기는 거다.

폼이 특히 중요한 이유는, 공공 서비스에서 폼이 '돈과 권리가 오가는 지점'이기 때문이다. 보조금 신청, 민원 접수, 증명서 발급 — 사용자가 폼을 제대로 못 채워서 신청에 실패하면, 그건 단순한 불편이 아니라 '받았어야 할 혜택을 못 받는' 실질적 손해다. 디지털에 익숙한 사람은 어떻게든 채워 넣겠지만, 정작 그 혜택이 가장 절실한 분들(어르신, 장애인, 디지털 소외계층)이 폼의 벽에 막혀 신청을 포기한다면, 그 서비스는 '가장 필요한 사람에게 닿지 못하는' 서비스가 된다. 폼의 '괜찮겠지'는 이렇게 공공성의 핵심을 건드린다.

■ 놓치는 것 5: '흐름이야 어떻게든 끝나면 괜찮겠지' — 끊기는 서비스 동선

다섯 번째는 '흐름(SP)'이다. 앞의 네 가지가 '한 화면 안의 문제'라면, 이건 '여러 화면을 거치는 동선'의 문제다. 검색해서 → 결과를 보고 → 상세로 들어가서 → 신청하고 → 확인받는, 이 일련의 흐름이 매끄럽게 이어져야 하는데, 가이드 없는 사이트는 이 연결이 자꾸 끊긴다.

A광역지자체의 가상 사례를 보자. 보조금을 검색해서 찾은 다음 '신청하기'를 눌렀더니, 갑자기 다른 부서가 만든 별도 시스템으로 튕겨 나갔다. 화면 디자인이 완전히 달라지고, 로그인을 처음부터 다시 하라고 했다. 사용자는 '내가 길을 잘못 든 건가' 싶어 당황한다. 만든 쪽은 '어쨌든 신청 시스템으로 연결됐으니 괜찮겠지' 했지만, 사용자 입장에선 '한 사이트인 줄 알았는데 갑자기 남의 집에 들어온' 느낌이다. 흐름이 끊기는 순간, 사용자는 자기가 제대로 가고 있는지에 대한 확신을 잃는다. 그 확신을 잃으면 '이거 진짜 신청된 거 맞나' 하는 불안으로 이어지고, 결국 이탈한다.

흐름에서 또 흔히 놓치는 게 '지금 어디쯤인지 알려주기'다. 여러 단계로 된 신청이라면 '3단계 중 2단계'처럼 진행 상황을 보여줘야 사용자가 끝이 보인다는 안도감을 갖는다. 이게 없으면 '이거 언제 끝나지?' 하는 막막함에 중간에 그만둔다. 또 하나, '되돌아갈 길'이다. 잘못 입력했을 때 이전 단계로 안전하게 돌아갈 수 있어야 하는데, 브라우저 뒤로가기를 눌렀더니 입력한 내용이 다 날아가는 경험을 하면 사용자는 다시 시도할 엄두를 못 낸다.

흐름의 문제가 무서운 건, 앞의 네 가지(색·글꼴·버튼·폼)를 다 잘해놓고도 마지막 흐름 하나에서 무너질 수 있다는 점이다. 각 화면은 멀쩡한데 화면과 화면 사이가 끊기면, 사용자는 결국 목적을 달성하지 못한다. 그리고 공공 서비스에서 '목적 미달성'은 곧 '서비스 실패'다. 멋진 화면을 보러 오는 사람은 없다. 신청을 하러, 정보를 찾으러, 민원을 넣으러 온다. 그 일을 끝까지 마치게 해주는 게 흐름의 역할이다. '어떻게든 끝나기만 하면 괜찮겠지'가 아니라 '누구나 헤매지 않고 끝낼 수 있나'를 물어야 한다.

흐름의 '괜찮겠지'가 유독 발견하기 어려운 이유가 있다. 만든 사람은 그 흐름을 '수백 번' 지나가 봤다. 검색하고, 신청하고, 확인받는 과정을 테스트하느라 몸이 그 길을 외운다. 그래서 어디서 화면이 갑자기 바뀌는지, 어디서 로그인을 다시 해야 하는지, 어디서 입력이 날아가는지를 '이미 알고 피해 가는' 상태가 된다. 본인은 한 번도 헤맨 적이 없으니 '이 흐름 괜찮네' 한다. 그런데 그 길을 처음 가는 사용자는, 만든 사람이 무의식적으로 피해 가던 그 모든 함정에 하나씩 빠진다. 흐름의 문제는 '처음 가보는 사람'의 눈으로만 보인다. 그래서 진짜 좋은 점검은 '그 사이트를 한 번도 안 써본 사람'에게 시켜보는 거다. 자동 점검 도구도 마찬가지다. 도구는 그 사이트에 대한 '선입견'이 없어서, 만든 사람이 외워서 피해 가던 끊김을 '있는 그대로' 잡아낸다.

흐름과 관련해 '일관성'도 한 번 더 강조하자. 한 사이트 안에서 검색 결과 화면, 목록 화면, 상세 화면이 서로 다른 규칙으로 만들어져 있으면, 사용자는 페이지를 넘을 때마다 '새로운 사이트'를 만나는 셈이 된다. 한 화면에서 익힌 사용법이 다음 화면에서 안 통하니, 매 화면을 처음부터 더듬어야 한다. 잘 만든 사이트는 '한 번 익히면 어디서나 통하는' 예측 가능함을 준다. 그 예측 가능함이 곧 '이 사이트는 다룰 줄 알겠다'는 자신감이 되고, 그 자신감이 사용자를 끝까지 머물게 한다. 흐름의 일관성은 결국 '사용자가 사이트를 신뢰하고 끝까지 따라오게 만드는 힘'이다.

그래서 어떻게 '확인'으로 바꾸나

지금까지 '괜찮겠지'가 놓치는 다섯 가지를 봤다. 색, 글꼴, 버튼, 폼, 흐름. 다시 보면 이게 바로 KRDS가 846규칙을 네 묶음(DS·CP·BP·SP)으로 나눈 이유와 정확히 겹친다. 색·글꼴은 기초인 DS, 버튼은 부품인 CP, 폼은 사용 패턴인 BP, 흐름은 서비스 패턴인 SP. 우연이 아니다. '사람이 감으로 놓치기 쉬운 곳'과 'KRDS가 규칙으로 챙기는 곳'이 같기 때문이다. KRDS는 결국 '인간이 자주 빠뜨리는 사각지대 목록'인 셈이다.

■ '괜찮겠지'를 '확인했나'로 바꾸는 3단계

그럼 이걸 어떻게 현장에 적용하나. 거창할 것 없다. 세 단계면 된다.

첫째, '기준이 있다는 걸 안다'. 많은 담당자가 KRDS나 품질관리 지침이 '있다'는 사실조차 모른 채 매번 감으로 결정한다. 기준이 있다는 걸 아는 것만으로도 절반은 해결된다. '아, 이건 내가 정할 문제가 아니라 이미 정해진 표준이 있구나'를 아는 순간, 불필요한 고민과 제각각의 결정이 사라진다.

둘째, '발주 문서에 한 줄을 넣는다'. 직접 만들든 외주를 주든, 'KRDS를 준수해 주세요'라는 한 줄을 명세에 넣는 것만으로 결과물의 출발선이 달라진다. 이 한 줄은 검수 기준도 만들어준다. 가이드가 없으면 '예쁘다/안 예쁘다'의 주관적 다툼이 되지만, 기준이 있으면 '이 버튼은 표준 위계를 안 지켰다'고 근거를 들어 객관적으로 수정을 요청할 수 있다. 발주처와 업체가 같은 기준을 보니, '말이 다르다'는 소모적 분쟁도 준다.

셋째, '자동으로 확인한다'. 그런데 846개 규칙을 사람이 일일이 손으로 확인하는 건 현실적으로 불가능하다. 바쁜 현장에서 '이 페이지 846개 다 봤나'를 매번 챙길 수는 없다. 그래서 자동 점검 도구가 필요하다. 사람이 감으로 놓치는 걸 도구가 빠짐없이 훑어주는 거다. 이 세 번째 단계가 바로 우리가 만든 도구가 들어가는 자리다.

이 세 단계의 핵심은 '점점 사람의 감에서 멀어진다'는 데 있다. 1단계는 '기준이 있다는 인식'이고, 2단계는 '그 기준을 문서로 요구하는 행동'이고, 3단계는 '그 기준을 기계가 확인하는 자동화'다. 단계가 올라갈수록 '사람의 컨디션·시간·실수'에 덜 의존하게 된다. 가장 이상적인 건, 담당자가 바뀌든, 바쁘든, 피곤하든 상관없이 '사이트 주소만 넣으면 항상 같은 기준으로 점검되는' 상태다.

그래야 품질이 '특정 사람의 실력'에 좌우되지 않고 '조직의 표준'으로 안정된다. 사람이 잘해서 좋은 사이트가 되는 게 아니라, 시스템이 받쳐줘서 누가 와도 일정 수준이 보장되는 것 — 그게 '디자인 시스템'이 추구하는 궁극의 모습이다.

■ ViewCheck — '괜찮겠지'를 '점수'로 바꿔주는 도구

여기서 잠깐 우리 이야기를 하겠다. ViewCheck는 공공 웹사이트를 KRDS 846규칙에 맞춰 자동으로 진단해주는 도구다. 사이트 주소를 넣으면, 우리 시스템이 그 사이트를 직접 돌아다니며 화면을 수집하고, DS 120 + CP 446 + BP 108 + SP 172, 합쳐서 846개 규칙을 하나하나 확인한다. 사람이라면 며칠이 걸릴 점검을, 자동으로 처리한다.

결과는 '점수'로 나온다. 분석이 끝나면 화면 상단에 점수 카드(OverviewCards)가 뜨는데, 거기에 색·글꼴 같은 디자인 스타일(DS), 버튼·입력칸 같은 컴포넌트(CP), 폼 같은 사용 패턴(BP), 신청·검색 같은 서비스 패턴(SP)이 각각 몇 점인지 한눈에 보인다. '괜찮겠지'라는 막연한 감이, 'DS 60점, CP 45점, BP 70점, SP 55점' 같은 구체적인 숫자로 바뀌는 거다. 점수가 낮은 영역이 곧 '우리가 감으로 놓치고 있던 곳'이다.

그리고 점수만 던지지 않는다. 각 규칙별로 '어디가, 왜 어긋났는지'를 짚어준다. '이 페이지의 이 버튼이 위계가 없다', '이 입력칸에 라벨이 없다', '이 색 조합이 대비 기준에 미달이다' — 이렇게 구체적인 위치와 이유를 알려주니, 막연히 '어디가 문제지' 하고 헤맬 필요가 없다. 앞서 본 다섯 가지 붕괴 패턴이 우리 사이트에서 실제로 몇 개나, 어디서 일어나고 있는지를 데이터로 보여준다.

이 '구체적으로 짚어주는' 부분이 사실 가장 큰 차이다. 많은 사람이 '우리 사이트가 좀 별로인 건 아는데, 그래서 뭘 어떻게 하라는 건지를 모르겠다'고 한다. 막연한 불만은 있는데 구체적인 할 일이 없으니, 결국 아무것도 안 하게 된다. 진단의 가치는 그 막연함을 '할 일 목록'으로 바꿔주는 데 있다. '이 버튼에 호버 효과를 넣으세요', '이 입력칸에 라벨을 추가하세요'처럼 손에 잡히는 작업으로 바뀌면, 비로소 개선이 시작된다. 앞서 '쪼개기'가 중요하다고 했던 것과 같은 맥락이다. 진단은 '우리 사이트의 막연한 문제'를 '하나씩 처리할 수 있는 구체적 항목들'로 쪼개주는 도구다. 그리고 그 항목 하나하나가 KRDS 846규칙과 연결돼 있으니, '왜 이걸 고쳐야 하는지'의 근거도 함께 따라온다. 윗선을 설득할 때도, 외주에 수정을 요구할 때도, '감'이 아니라 '공식 기준'을 들이밀 수 있는 거다.

ViewCheck는 KRDS 846규칙만 보는 게 아니다. 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과, 웹접근성 KWCAG 33항목까지 함께 점검한다. '디자인이 잘 됐나'를 넘어 '표준을 지키나, 누구나 쓸 수 있나, 안전한가, 빠른가'까지 종합적으로 본다. 한 번의 진단으로 사이트의 '건강검진표'를 받는 셈이다.

특히 강조하고 싶은 건, ViewCheck가 '여러 페이지'를 함께 본다는 점이다. '괜찮겠지'의 무서움은 '한 페이지는 괜찮은데 다른 페이지가 망가지는' 데 있다고 했다. 메인 페이지만 예쁘게 만들고 안쪽 페이지들은 방치되는 경우가 많은데, ViewCheck는 사이트 전체를 돌며 페이지마다 점검하고, '이 사이트 전체로 봤을 때'의 점수를 낸다. 한 페이지의 우연한 '괜찮음'에 속지 않고, 사이트 전체의 진짜 상태를 보여주는 거다.

이게 왜 중요한지 다시 한번 짚자. 많은 점검이 '메인 페이지 한 장'만 보고 끝난다. 그런데 메인 페이지는 보통 가장 공들여 만든, 가장 깔끔한 페이지다. 정작 사용자가 실제로 일을 처리하는 건 안쪽 깊숙한 신청 페이지, 목록 페이지, 상세 페이지들이다. 그 안쪽 페이지들이야말로 '괜찮겠지'로 방치되기 쉽다. 메인만 보고 '우리 사이트 괜찮네' 하는 건, 잘 꾸민 거실만 보고 '이 집 깨끗하네' 하는 것과 같다. 진짜 상태는 안 보이는 방, 창고, 화장실에서 드러난다. 여러 페이지를 함께 보는 진단이라야 '진짜 우리 사이트'를 본다. 우리가 '다중 페이지 분석'을 그렇게 강조하는 이유가 여기 있다.

■ 점검은 '끝'이 아니라 '시작'이다

오해하지 말아야 할 게 있다. 자동 점검 도구가 '점수를 낮게 줬다'고 해서 그게 끝이 아니다. 오히려 시작이다. 점수가 보이기 시작하면 그제야 '무엇부터 고칠지' 우선순위를 정할 수 있다. 모든 걸 한 번에 다 고칠 순 없다. 하지만 '가장 점수가 낮은 곳', '가장 많은 사용자에게 영향을 주는 곳'부터 차근차근 손대면 된다. 점검의 진짜 가치는 '완벽한 사이트'를 만드는 게 아니라, '지금 어디가 문제인지 알게 해주는' 데 있다. 알아야 고친다. 보여야 움직인다.

그리고 이건 한 번 하고 끝낼 일도 아니다. 사이트는 살아 있다. 새 페이지가 붙고, 콘텐츠가 쌓이고, 부분 개편이 이뤄지면서 계속 변한다. 그 변화 속에서 '괜찮겠지'는 다시 스며든다. 그래서 좋은 운영은 '주기적으로 점검하는' 거다. 분기에 한 번이든, 큰 개편 직후든, 정기적으로 진단을 돌려 '우리 사이트가 지금도 기준을 지키고 있나'를 확인하는 습관. 그 습관이 디자인 부채가 다시 쌓이는 걸 막는다. 건강검진을 한 번 받았다고 평생 건강한 게 아니듯이.

한 가지 더. 점검 결과를 받아들일 때 '방어적'이 되지 않는 게 중요하다. 점수가 낮게 나오면 마음이 상한다. '우리가 그동안 열심히 했는데' 싶어 억울하기도 하다. 충분히 이해한다. 그런데 점검 도구는 '너희가 못했다'고 비난하는 게 아니다. 앞서 말했듯, 가이드 없이 여러 사람이 오래 손대면 누구의 사이트든 '괜찮겠지'가 쌓이게 돼 있다. 그건 담당자 잘못이 아니라 구조의 문제다. 점수는 '비난'이 아니라 '지도'다. 지금 우리가 어디 있는지, 어디로 가면 되는지를 알려주는 좌표다. 낮은 점수에 기죽을 게 아니라 '아, 여기를 고치면 올라가는구나' 하고 길로 삼으면 된다. 그리고 한두 가지만 고쳐도 점수가 눈에 띄게 오르는 걸 보면, 그 자체가 다음 개선의 동기가 된다. 보이면 움직이고, 움직이면 좋아진다. 이 선순환을 만드는 게 진단의 진짜 가치다.

마무리

긴 이야기를 했지만, 결국 하고 싶은 말은 하나다. '감으로 괜찮겠지'를 '확인했나'로 바꾸자는 것.

오늘 우리는 '괜찮겠지'가 놓치는 다섯 가지를 봤다. 눈대중으로 고른 색이 통제 불능이 되고, '글꼴쯤이야' 했던 게 신뢰를 떨어뜨리고, '비슷한 버튼이면 알아서 누르겠지'가 사용자를 헤매게 하고, '입력만 되면 괜찮겠지'가 폼을 장벽으로 만들고, '어떻게든 끝나면 괜찮겠지'가 서비스 흐름을 끊었다. 다섯 가지 모두 '만든 사람 눈에는 괜찮아 보였지만 사용자에게는 그렇지 않았던' 것들이다. 그리고 다섯 가지 모두, 큰 사고처럼 빨간불이 켜지지 않고 '조용히' 손해를 냈다.

다시 강조하지만, 이 다섯 가지는 '만든 사람이 못나서' 생긴 게 아니다. 공유된 기준 없이 여러 사람이 오래 손대면 누구의 사이트에서도 자연스럽게 생기는 일이다. 그러니 발견했다고 자책할 필요가 전혀 없다. 발견했다는 건 오히려 '이제 고칠 수 있게 됐다'는 좋은 소식이다.

이 '조용한 손해'를 막는 길은 결국 두 가지다. 하나는 '기준'을 갖는 것 — KRDS와 품질관리 지침이라는, 감이 놓치는 곳을 미리 적어둔 점검표. 다른 하나는 '도구'로 그 기준을 자동으로 확인하는 것 — 사람이 매번 846개를 손으로 못 보니, 도구가 대신 빠짐없이 훑어주는 것. 기준과 도구, 이 둘이 '괜찮겠지'의 빈자리를 메운다.

한 가지 덧붙이고 싶은 말이 있다. '괜찮겠지'의 반대말은 '완벽하게 하자'가 아니다. 완벽은 누구도 못 한다. 사이트는 늘 어딘가 부족하기 마련이고, 그건 정상이다. '괜찮겠지'의 진짜 반대말은 '확인하자'다. 완벽하지 않아도 좋다. 다만 '내가 무엇을 놓치고 있는지는 알자'는 거다. 모르고 놓치는 것과 알고도 (지금은 여력이 없어) 못 고치는 것은 천지 차이다. 전자는 손해가 어디서 나는지조차 모르지만, 후자는 적어도 '다음에 여기부터 고치자'는 계획을 세울 수 있다. 그러니 부담 갖지 말자. 이 글은 '완벽한 사이트를 만들라'는 압박이 아니라, '눈을 뜨고 보자'는 권유다. 눈을 뜨는 데는 큰 비용이 들지 않는다.

그러니 한 가지만 부탁드리고 싶다. 지금 운영하는 사이트가 있다면, '괜찮겠지' 대신 '한번 확인해볼까'로 바꿔보시라. 거창한 개편을 하라는 게 아니다. 그냥 우리 사이트가 지금 어디쯤 와 있는지, 무엇을 놓치고 있는지를 '보는 것'부터 시작하면 된다. krds.viewcheck.co.kr에서 데모(https://krds.viewcheck.co.kr/demo)로 진단 과정을 볼 수 있습니다. 몇 분 뒤 화면 상단에 뜨는 점수 카드를 보는 순간, '아, 우리가 이걸 놓치고 있었구나' 하는 게 눈에 보일 거다. 그 '보임'이, 모든 개선의 출발점이다.

월요일 글에서 '디자인 시스템이 무엇인가'를 큰 그림으로 그렸다면, 오늘 글은 '그게 없을 때 무엇을 놓치는가'를 현장의 눈으로 들여다본 셈이다. 금요일에는 한 걸음 더 나아가, '그럼 우리 사이트를 직접 한번 점검해보려면 어떻게 시작하면 되는지'를 차근차근 안내하려 한다. 이번 주 글들이 '감으로 괜찮겠지'에서 '직접 확인해보자'로 넘어가는 작은 다리가 되었으면 한다. 거창한 개편 계획을 세우라는 게 아니다. 그냥 한 번, 우리 사이트 주소를 진단 창에 넣어보는 것 — 그 작은 행동 하나가 시작이다.

감으로 '괜찮겠지' 했던 것들을, 오늘부터는 눈으로 확인하자. 보이기 시작하면, 고칠 수 있다.