규칙 많다고 겁먹지 마세요 — 자주 걸리는 건 따로 있다

공감·문제제기

"846개요? 그걸 다 지키라고요?"

KRDS 이야기를 처음 꺼내면 담당자분들 표정이 딱 이렇게 굳는다. 846이라는 숫자가 주는 무게가 어마어마하다. 규칙이 8백 개가 넘는다니까, 머릿속에 '이걸 언제 다 보고, 언제 다 고치냐'는 한숨부터 차오른다. 그 마음 충분히 이해한다. 나도 처음 이 숫자를 마주했을 때 비슷했으니까.

그런데 오늘 이 글에서 제일 먼저, 제일 크게 말하고 싶은 게 이거다. 846개라는 숫자에 겁먹지 마시라. 진짜다. 8백 개를 동시에 신경 써야 하는 사이트는 세상에 없다. 현장에서 수많은 공공 사이트를 들여다본 입장에서 솔직하게 말하면, '자주 걸리는 것'은 따로 있다. 그것도 생각보다 훨씬 적은 수다. 마치 시험 범위가 책 한 권인데 실제로 시험에 나오는 건 늘 그 비슷한 단원들인 것처럼, 위반도 비슷한 자리에서 반복적으로 터진다.

오늘 글은 그래서 '겁부터 빼는' 글이다. 846이라는 숫자를 네 덩어리로 쪼개서 보면 어떻게 보이는지, 그중 실제로 사이트를 망가뜨리는 단골 위반은 무엇인지, 그리고 그 단골들이 익명의 ○○시·A광역지자체·한중앙부처·B공공기관·C기관 현장에서 '어떻게' 잘못되는지를 구체적인 사례로 풀어보려 한다. 막연한 두려움은 늘 '모르니까' 생긴다. 정체를 알면 무섭지 않다. 846개도 마찬가지다. 정체를 알고 나면, '아, 이거 우리가 손댈 수 있는 거구나' 하는 안도가 먼저 온다.

생각해보면 우리 일상에도 이런 '많아 보이지만 실은 단골이 정해진' 것들이 많다. 도로교통법 조항이 몇백 개라지만, 운전하면서 실제로 매일 신경 쓰는 건 신호·속도·차선 정도다. 맞춤법 규정이 두꺼운 책 한 권이지만, 사람들이 실제로 자주 틀리는 건 '되/돼', 띄어쓰기 몇 가지로 정해져 있다. 규칙의 총량과, 내가 실제로 자주 마주하는 규칙은 전혀 다른 이야기다. KRDS 846도 똑같다. 전체는 방대하지만, 내 사이트가 실제로 매일 걸리는 자리는 손에 꼽힌다. 그 '손에 꼽히는 자리'를 알면 846이라는 숫자는 갑자기 다룰 만해진다.

한 가지 미리 솔직하게 고백할 게 있다. 나도 한때는 '규칙이 많을수록 좋은 가이드'라고 생각했다. 빈틈없이 촘촘하면 그만큼 꼼꼼하게 챙겨준다는 뜻이니까. 그런데 현장을 다니다 보니 생각이 바뀌었다. 규칙이 많다는 건 '챙길 게 많다'는 부담이 아니라, '어떤 상황에서도 답을 찾을 수 있다'는 안심이어야 한다. 좋은 규칙집은 사용자를 압박하는 게 아니라 헤매지 않게 길을 깔아주는 거다. 846이라는 숫자도 그렇게 읽혀야 한다. '이걸 다 외워라'가 아니라 '네가 어떤 화면을 만들든, 그에 맞는 답이 여기 어딘가에 다 들어 있다'는 보증서로.

그리고 또 하나. 846개 규칙이 전부 똑같은 무게를 갖는 게 아니라는 점도 미리 말해두고 싶다. 어떤 규칙은 거의 모든 사이트에서 걸리고, 어떤 규칙은 특정 기능이 있는 사이트에서만 의미가 있고, 어떤 규칙은 아주 드물게만 해당된다. 그러니 846개를 '평평한 8백 개 목록'으로 보면 질리지만, '자주 걸리는 핵심 + 가끔 걸리는 것 + 거의 안 걸리는 것'으로 층을 나눠 보면 갑자기 다룰 만한 크기로 줄어든다. 오늘 글의 절반은 바로 그 '자주 걸리는 핵심'이 무엇인지 보여주는 데 쓸 생각이다.

한 가지 더. 이 글을 읽는 분들 중에는 '우리 사이트는 외주를 잘 줘서 깔끔하다'고 안심하는 분도 있을 거다. 그런데 현장 경험상, 외주를 줘도 '자주 걸리는 단골'은 거의 똑같이 나온다. 아니, 오히려 더 심할 때도 있다. 외주 업체가 매번 다르거나, 같은 업체라도 투입되는 사람이 바뀌면 각자의 '기본값'이 다르기 때문이다. A 업체의 기본 파랑과 B 업체의 기본 파랑이 다르고, 작년 담당자와 올해 담당자의 버튼 스타일이 다르다. 발주처에 공유된 기준이 없으면 업체는 '알아서 예쁘게' 만들 수밖에 없고, 그 '알아서'가 쌓여 누더기가 된다. 그러니 846은 '우리가 직접 만들 때'만 필요한 게 아니라 '남에게 맡길 때' 더 절실한 기준이다. 발주 문서에 "KRDS를 준수해 주세요"라는 한 줄을 넣을 수 있느냐 없느냐가, 몇 년 뒤 사이트의 운명을 가른다.

자, 그러면 가장 먼저 그 846이라는 숫자부터 분해해보자. 무서운 숫자일수록 쪼개서 보면 의외로 친근해진다.

846을 네 덩어리로 쪼개면

■ 846은 '하나의 산'이 아니라 '네 개의 언덕'이다

KRDS 846규칙을 처음 보면 거대한 산처럼 느껴진다. 그런데 이 산은 실은 네 개의 언덕으로 나뉘어 있다. DS 120개, CP 446개, BP 108개, SP 172개. 이 네 덩어리가 합쳐져 846이 된다. 숫자만 던지면 또 어렵게 들리니, 각각이 '무엇을 챙기는 영역인지'로 풀어보자.

DS(디자인 스타일) 120개는 가장 작은 기초 단위다. 색·글꼴·간격·둥근 정도·그림자 같은, 화면을 이루는 '재료'의 약속이다. 건물로 치면 벽돌과 시멘트의 규격이다. 벽돌 크기가 제각각이면 그 위에 뭘 쌓아도 비뚤어지듯, DS가 흔들리면 그 위의 모든 게 흔들린다. 숫자는 120개로 가장 적지만, 영향력으로 치면 가장 크다. 단 하나의 색 약속이 사이트의 모든 화면에 동시에 퍼지기 때문이다. 그래서 '적은 규칙으로 큰 효과'를 볼 수 있는 영역이 바로 이 DS다.

CP(컴포넌트) 446개는 가장 덩치가 크다. 버튼·입력칸·표·카드·탭·아코디언·페이지네이션 같은 '부품'들의 약속이다. 846개 중 절반이 넘는 446개가 여기 몰려 있는 이유는 단순하다. 화면을 이루는 부품의 종류가 그만큼 많기 때문이다. 한 사이트에 버튼만 있는 게 아니라 수십 종류의 부품이 들어가니, 각 부품마다 '이건 이렇게 생겨야 한다'를 정하다 보면 자연히 숫자가 커진다.

BP(베이직 패턴) 108개는 부품들이 모여 만드는 '작은 흐름'이다. 폼을 어떻게 구성하는지, 동의·확인을 어떻게 받는지, 오류가 났을 때 어떻게 알려주는지, 목록을 어떻게 거르고 정렬하는지 — 이런 '여러 부품이 협력하는 패턴'이 BP다. 부품 하나하나는 멀쩡한데 그것들을 '어떻게 엮느냐'에서 어긋나는 일이 많아서, BP는 직접 써보지 않으면 잘 안 드러난다. 입력칸도 있고 버튼도 있는데, 막상 폼을 작성해보면 '동의는 어디서 하지', '이 오류는 어느 칸 때문이지' 하고 헤매게 되는 게 전부 BP의 영역이다.

SP(서비스 패턴) 172개는 가장 위층의 '큰 흐름'이다. 검색하기, 로그인하기, 신청하기, 정책·서비스를 안내받기 같은, 사용자가 '목적을 가지고 끝까지 거쳐 가는 여정'의 약속이다. 공공 사이트의 진짜 가치는 결국 이 SP에서 결판난다. 사용자가 사이트에 오는 건 구경하러가 아니라 '뭔가를 처리하러' 오기 때문이다. 민원을 넣고, 신청을 하고, 자격을 확인하고, 정보를 찾는다. 그 목적을 끝까지 매끄럽게 이루게 해주느냐가 사이트의 존재 이유다. 그래서 SP는 숫자(172개)는 중간이지만 '무게'로 치면 가장 무겁다.

이렇게 네 층으로 나눠 보면 846이 '무질서한 8백 개'가 아니라 '기초→부품→작은 흐름→큰 흐름'으로 쌓아 올린 질서 있는 구조라는 게 보인다. 아래층이 위층을 떠받치는 탑 같은 구조다. 그래서 어디부터 손대야 할지도 자연스럽게 정해진다. 무너진 탑을 고칠 때 꼭대기부터 손대지 않듯, 사이트도 기초(DS)부터 잡는 게 정석이다.

이 '층' 개념이 왜 중요한지 한 번 더 짚고 싶다. 기초(DS)는 색·글꼴·간격 같은 '가장 작은 단위의 약속'이다. 부품(CP)인 버튼은 이 약속을 가져다 쓴다 — 버튼의 색은 DS의 '주 색'을, 버튼 안 글자는 DS의 '본문 글꼴'을, 버튼의 안쪽 여백은 DS의 '간격 단위'를 빌려온다. 그러니 DS가 들쭉날쭉하면 버튼도 자동으로 들쭉날쭉해진다. 그 들쭉날쭉한 버튼들이 모여 폼(BP)을 이루고, 폼이 모여 신청 흐름(SP)을 이룬다. 결국 최상단의 '신청 흐름'이 엉망으로 보이는 진짜 원인이, 알고 보면 맨 아래 '색 약속이 없었다'는 데 있는 경우가 허다하다. 그래서 현장에서 사이트를 점검할 때, 사용자가 "신청이 너무 불편하다"고 호소해도 우리는 가장 먼저 DS부터 들여다본다. 증상은 위에서 터지지만 원인은 아래에 있을 때가 많기 때문이다.

비유하자면 건물의 기초 공사다. 기초가 삐뚤면 1층은 약간 기울고, 2층은 더 기울고, 옥상은 위험할 만큼 기운다. 디자인도 똑같다. DS가 흔들리면 CP가 흔들리고, CP가 흔들리면 BP·SP가 무너진다. 그래서 망가진 사이트를 고칠 때도 기초부터 다시 잡는 게 정석이고, 거꾸로 '기초 몇 개만 제대로 잡으면 위층까지 한꺼번에 나아진다'는 희망도 여기서 나온다. 846이라는 숫자가 막막하게 느껴질 때, 이 '탑' 그림을 떠올리면 한결 마음이 가벼워진다. 다 동시에 챙길 필요가 없다. 맨 아래 벽돌부터 차근차근 쌓으면 된다.

■ 왜 446개가 한 덩어리(CP)에 몰려 있나

처음 이 분포를 보면 다들 한 번씩 묻는다. "왜 컴포넌트만 446개나 돼요? 너무 불균형한 거 아닌가요?" 좋은 질문이다. 답은 '부품은 상태와 변형이 많기 때문'이다.

버튼 하나만 봐도 그렇다. 평소 모습, 마우스를 올렸을 때, 키보드로 선택했을 때, 눌렀을 때, 비활성일 때, 로딩 중일 때 — 한 부품이 여러 상태를 갖는다. 게다가 주 버튼, 보조 버튼, 위험 버튼, 텍스트 버튼처럼 종류도 갈린다. 종류 × 상태 × 크기 조합을 다 챙기려면 버튼 하나에도 규칙이 여러 개 붙는다. 입력칸도 마찬가지다. 빈 상태, 입력 중, 오류, 비활성, 도움말이 붙은 경우... 부품이 살아 움직이는 만큼 챙길 게 많다.

그러니 446이라는 숫자에 또 겁먹을 필요 없다. 그건 '부품의 가짓수'가 아니라 '부품이 가질 수 있는 상황의 가짓수'다. 그리고 다행히, 내 사이트에 없는 부품의 규칙은 '해당 없음'으로 빠진다. 아코디언을 안 쓰는 사이트라면 아코디언 규칙들은 애초에 적용 대상이 아니다. 실제로 한 페이지를 진단해보면 446개 CP 규칙 중 상당수가 '해당 없음'으로 분류된다. 그 페이지에 그 부품이 없으니까. 결국 '내가 실제로 챙겨야 할 부품 규칙'은 446개 전부가 아니라, 내 사이트가 실제로 쓰는 부품들에 한정된다.

오히려 CP가 많다는 건 '좋은 일'로 봐야 한다. 규칙이 부품별로 세세하게 나뉘어 있다는 건, 내가 어떤 부품을 만들든 '이건 어떻게 만들어야 표준인지'에 대한 답이 이미 준비돼 있다는 뜻이다. 버튼을 만들 때도, 표를 만들 때도, 탭을 만들 때도, 그때그때 '이걸 어떻게 만들지'를 처음부터 고민할 필요 없이 정해진 표준을 따르면 된다. 446개는 '챙길 짐'이 아니라 '참고할 사전'이다. 사전이 두껍다고 겁내는 사람은 없다. 필요할 때 필요한 항목만 찾아보면 되니까. CP 446개도 딱 그런 사전처럼 쓰면 된다. 내가 지금 만드는 그 부품의 항목만 펼쳐 보면 그만이다.

이 '해당 없음'이라는 개념은 846을 다룰 때 굉장히 중요하다. 846개를 전부 '통과 아니면 위반'의 이분법으로 보면 숨이 막힌다. 하지만 실제 판정은 세 갈래다. 통과, 위반, 그리고 해당 없음. 내 화면에 없는 부품·기능에 대한 규칙은 '해당 없음'으로 조용히 빠진다. 그래서 실제로 신경 써야 할 '실효 규칙 수'는 846보다 훨씬 작다. 진단 결과를 처음 받아본 분들이 "생각보다 위반이 적네요?" 하고 안도하는 이유가 여기 있다.

조금 더 풀어보자. 한 페이지를 진단하면 846개 규칙이 그 페이지에 한 번씩 적용된다. 그런데 그 페이지에 아코디언이 없으면 아코디언 규칙은 '해당 없음', 표가 없으면 표 규칙은 '해당 없음', 페이지네이션이 없으면 그 규칙도 '해당 없음'이다. 이렇게 '없는 것'에 대한 규칙이 쭉 빠지고 나면, 실제로 통과·위반 판정이 내려지는 규칙은 절반 안팎으로 줄어든다. 특히 부품(CP) 446개 중에서는 '해당 없음' 비율이 꽤 높은 편이다. 한 페이지가 사이트의 모든 부품을 다 쓰지는 않으니까.

그래서 '846개를 다 봐야 한다'는 부담은 사실 환상에 가깝다. 내가 실제로 마주하는 건 '이 페이지가 실제로 쓰는 것들에 대한 판정'이다. 그리고 여러 페이지를 묶어 사이트 전체로 보면, 페이지마다 '해당 없음'이던 규칙이 다른 페이지에서 '통과/위반'으로 채워지면서 사이트 차원의 그림이 완성된다. 한 페이지엔 표가 없어도 다른 페이지엔 표가 있으니, 사이트 전체로는 표 규칙도 결국 평가된다. 이게 '여러 페이지를 함께 봐야 하는' 이유이기도 하다. 한 페이지만 보면 '해당 없음'이 많아 안심되지만, 사이트 전체를 봐야 진짜 상태가 드러난다.

자주 걸리는 건 정말 따로 있다

■ 단골 위반은 대부분 '아래층'에 있다

수많은 공공 사이트를 들여다보면서 깨달은 게 있다. 위반은 골고루 흩어지지 않는다. 특정 자리에 뭉쳐 있다. 그리고 그 '특정 자리'는 거의 항상 아래층, 즉 기초(DS)와 자주 쓰는 부품(CP) 쪽이다.

생각해보면 당연하다. 색·글꼴·간격은 모든 페이지에 들어간다. 그러니 거기에 문제가 있으면 '모든 페이지에서' 걸린다. 반대로 아주 특수한 기능의 규칙은 그 기능을 쓰는 몇몇 페이지에서만 걸린다. 그래서 '자주 걸리는 위반'의 정체는 결국 '모든 페이지가 공유하는 기초의 결함'인 경우가 압도적으로 많다.

여기에 또 하나의 이유가 겹친다. 기초 영역의 위반은 '만드는 사람이 의식하지 못한 채' 생긴다. 버튼을 하나 만들 때 '이 버튼이 표준 색을 쓰고 있나'를 매번 의식하는 사람은 드물다. 그냥 '대충 비슷한 색'을 골라 박는다. 그 무의식적인 선택이 페이지마다 반복되면서 단골 위반이 쌓인다. 반대로 '이 페이지에 표가 들어가야 하나' 같은 건 의식적으로 결정하는 일이라 상대적으로 덜 흔들린다. 그래서 위반은 '의식하지 않고 반복하는 선택'이 많은 아래층에 몰린다. 이걸 뒤집으면, 아래층에 '의식하지 않아도 표준을 따르게' 만드는 약속 — 즉 토큰과 표준 컴포넌트 — 을 깔아두는 게 가장 효과적인 처방이라는 뜻이다. 사람의 주의력에 기대지 않고 시스템이 알아서 표준을 따르게 하면, 단골 위반은 애초에 발생하지 않는다.

이게 왜 좋은 소식이냐면, 거꾸로 '기초 몇 개만 제대로 잡으면 사이트 전체가 한꺼번에 좋아진다'는 뜻이기 때문이다. 색 약속 하나를 정하면 모든 페이지의 색 위반이 동시에 사라진다. 표준 버튼 하나를 정하면 모든 페이지의 버튼이 동시에 정돈된다. 단골 위반이 아래층에 몰려 있다는 사실은, 적은 노력으로 큰 효과를 볼 수 있는 지점이 분명히 존재한다는 의미다. 846개를 막막하게 바라보지 말고, '제일 자주 걸리는 아래층 몇 개'부터 공략하면 된다.

그리고 단골 위반들은 신기하게도 '함께 다닌다'. 색이 통제 불능인 사이트는 십중팔구 글꼴도 뒤섞여 있고, 버튼 위계도 없고, 폼 라벨도 부실하다. 왜냐하면 이 모든 게 '공유된 가이드가 없다'는 하나의 원인에서 비롯되기 때문이다. 그래서 단골 하나가 보이면 '나머지도 있겠구나' 하고 함께 점검하는 게 효율적이다. 반대로 말하면, 가이드 하나를 제대로 도입하면 이 다섯 가지가 동시에 좋아진다. 원인이 하나니까 처방도 하나로 통한다. 오늘 익명 사례를 ○○시·A광역지자체·한중앙부처·B공공기관·C기관 다섯으로 나눠서 보여줬지만, 현실에서는 한 사이트가 이 다섯을 '동시에' 안고 있는 경우가 대부분이다. 색도 문제고, 글꼴도 문제고, 버튼도 문제인 식이다. 그러니 '우리는 어디부터 손대지' 고민될 때, 다섯 개를 따로따로 생각하지 말고 '아래층 약속(색·글꼴)부터' 한 번에 정리하는 걸 권한다. 그 하나가 위층 넷을 같이 끌어올린다.

여기서 한 가지 분명히 해두고 싶다. 이 단골들이 반복되는 건 누가 게을러서도, 실력이 없어서도 아니다. 그냥 '공유된 규칙이 없는 상태에서 여러 사람이 오랜 시간 손을 대면' 자연스럽게 일어나는 일이다. 규칙이 없으니 각자 최선을 다해도 결과가 제각각이 된다. ○○시 담당자도, A광역지자체 외주 디자이너도, 한중앙부처 각 부서도 다들 그 순간엔 최선을 다했다. 다만 그 최선이 '공유되지 않은 채' 쌓였을 뿐이다. 그러니 '우리 사이트가 이렇네' 싶은 대목이 나와도 자책할 필요 없다. 원인을 알면 고칠 수 있고, 고치는 출발점이 바로 이런 단골 패턴을 '이름 붙여' 인식하는 거다. 이름을 붙일 수 있으면 고칠 수도 있다.

■ 단골 1 — ○○시 사례: 파란색이 수십 종

가장 흔한 단골부터 보자. 가상의 ○○시 사이트를 점검했다고 치자. 분석을 돌리면 거의 매번 나오는 결과가 있다. 사이트 전체에서 '비슷비슷한 파란색'이 수십 종 발견되는 거다.

사람 눈에는 다 그냥 '파랑'이다. 그런데 코드를 들여다보면 미세하게 다른 파랑이 제각각 박혀 있다. 어떤 건 진하고, 어떤 건 살짝 연하고, 어떤 건 보라 끼가 돌고, 어떤 건 회색이 섞여 칙칙하다. ○○시 담당자도 이걸 보고 깜짝 놀란다. "우리 사이트가 파랑이 이렇게 많았어요?"

왜 이렇게 됐을까. ○○시를 탓하려는 게 절대 아니다. 이건 ○○시만의 문제가 아니라 거의 모든 사이트에서 반복되는 '전형'이다. 원인은 단순하다. 페이지를 만들 때마다 담당자나 외주가 '대충 비슷한 파랑'을 눈대중으로 골라 직접 코드에 박았기 때문이다. 정해진 '브랜드 파랑' 하나를 공유해 쓴 게 아니라, 각자의 머릿속 파랑을 꺼내 썼다. 그 결과 ○○시의 색이 통제 불능이 됐다.

여기서 중요한 포인트. 이걸 만든 사람들 중 누구도 '색을 망치자'고 생각하지 않았다. 다들 그 순간엔 '이 정도 파랑이면 우리 시 사이트랑 어울리겠지' 하고 최선을 다해 골랐다. 문제는 '기준이 머릿속에만 있었다'는 거다. 머릿속 파랑은 사람마다 다르고, 같은 사람도 모니터가 바뀌면 다르게 본다. 그렇게 각자의 머릿속 기준으로 만든 결과물이 모이면, 개별로는 다 그럴듯한데 전체로는 제각각인 사이트가 된다.

이게 왜 단골이냐면, ○○시처럼 색을 통제 못 한 사이트는 '색 하나 바꾸기'가 지옥이 되기 때문이다. '우리 시 파랑을 조금 더 밝게 바꾸자'는 단순한 요청이, 수십 종 파랑이 흩어진 상태에서는 '어디에 어떤 파랑이 쓰였는지 전수조사'부터 해야 하는 대공사가 된다. 시 통합, 브랜드 개편, 상위 기관 가이드 변경 — 색을 한 번에 바꿔야 할 일은 주기적으로 생기는데, 그때마다 '색 하나 바꾸는 데 왜 이렇게 오래 걸리냐'는 질문 앞에서 담당자만 진땀을 뺀다. 정돈된 사이트라면 변수 하나 수정으로 끝날 일이, 통제 불능 상태에서는 수백 군데를 일일이 찾아 고치고, 빠뜨린 곳이 없는지 다시 검수하는 큰 작업이 된다. 그 비용 차이가 바로 '디자인 부채의 이자'다. 평소엔 안 보이다가 변경이 필요한 순간 청구서로 날아온다. ○○시 담당자가 '왜 우리만 이렇게 힘들지' 자책할 일이 아니다. 색을 한 곳에 모아두지 않은 모든 사이트가 똑같이 겪는 일이다.

해결의 실마리는 '디자인 토큰'이다. 색을 '브랜드-기본-파랑'처럼 이름 붙은 변수로 한 곳에서 관리하면, 바꿀 때 그 변수 하나만 고치면 사이트 전체에 반영된다. ○○시가 처음부터 토큰으로 색을 관리했다면, '파랑 밝게' 요청은 5분이면 끝났을 일이다. (디자인 토큰은 다음 달 주제로 깊게 다룬다.)

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

그리고 색은 접근성과도 바로 연결된다. 배경과 글자의 색 대비가 충분하지 않으면 저시력 사용자나 밝은 야외에서 보는 사용자가 글을 읽지 못한다. ○○시처럼 색을 눈대중으로 박는 사이트는 이 대비 기준을 지키기가 거의 불가능하다. 매번 다른 파랑을 쓰니 어떤 조합은 우연히 대비가 충분하고 어떤 조합은 미달인데, 그걸 일일이 검사할 방법이 없기 때문이다. 표준 색 팔레트를 정해두면 '이 조합은 대비 통과'라는 걸 미리 검증해 둘 수 있다. 색을 통제한다는 건 결국 '누구나 읽을 수 있는 사이트'로 가는 첫걸음이기도 하다. ○○시 사례가 '단골 중의 단골'인 이유는, 색 하나가 미관·신뢰·접근성·유지보수 비용까지 동시에 흔들기 때문이다. 그만큼 효과도 크다. 색 약속 하나만 제대로 세워도 이 네 가지가 한꺼번에 좋아진다.

■ 단골 2 — A광역지자체 사례: 한 페이지에 글꼴 다섯 종

다음 단골은 글꼴이다. 가상의 A광역지자체 사이트를 보자. 보도자료 페이지 하나를 열었는데, 한 화면 안에 글꼴이 다섯 종이 섞여 있다. 제목은 이 글꼴, 본문은 저 글꼴, 중간에 끼워 넣은 표는 또 다른 글꼴, 외부에서 가져온 배너는 시스템 기본 글꼴, 하단의 안내문은 또 다른 글꼴.

이런 '글꼴 잔치'가 어쩌다 생겼는지 추적해보면 거의 항상 '바깥에서 온 글꼴'이 범인이다. A광역지자체 담당자가 보도자료를 워드에서 작성해 그대로 복사·붙여넣기 하면 워드의 글꼴이 따라 들어온다. 다른 자료의 표를 가져오면 그 표의 스타일이 묻어온다. 외부 위젯이나 지도를 끼워 넣으면 그 서비스의 기본 글꼴이 그대로 노출된다. 이렇게 하나둘 쌓인 외부 글꼴이 한 페이지에서 다섯 종으로 공존하게 된다.

A광역지자체의 진짜 문제는 '글꼴이 안 예뻐서'가 아니다. 신뢰가 깎인다는 거다. 사용자는 글꼴의 일관성을 의식적으로 평가하지 않지만, 무의식적으로는 '이 사이트가 잘 관리되고 있나'의 단서로 받아들인다. 글꼴이 들쭉날쭉한 보도자료를 보면 '이 정보가 최신일까', '여기 신청이 제대로 처리될까' 같은 막연한 불안이 생긴다. 공공 서비스는 본질적으로 '믿고 맡기는' 서비스다. 민원을 넣고, 개인정보를 입력하고, 신청을 맡긴다. 그 신뢰의 바탕이 '정돈된 화면'에서 시작된다는 걸 생각하면, 글꼴 통일은 미관 작업이 아니라 신뢰 관리 작업이다.

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

여기서 타이포 '위계'라는 말도 짚어두자. 위계는 단순히 글꼴 종류를 통일하는 것 이상이다. 제목은 크고 굵게, 소제목은 그보다 작게, 본문은 읽기 편한 크기로, 부가 설명은 더 작고 연하게 — 이렇게 크기와 굵기로 '정보의 중요도'를 시각적으로 표현하는 게 위계다. 위계가 잘 잡힌 페이지는 사용자가 글을 '읽기 전에' 구조를 파악한다. 어디가 제목이고 어디가 본문인지 한눈에 보이니 필요한 정보를 빠르게 찾는다. 반대로 위계가 없으면 — 모든 글자가 비슷한 크기로 나열되면 — 사용자는 처음부터 끝까지 다 읽어야 원하는 정보를 찾을 수 있다. 공공 정보는 '찾으러 오는' 정보가 많다. 민원 방법, 신청 자격, 처리 기간 같은 걸 빠르게 찾아야 하는데, 위계 없는 페이지는 그 찾기를 방해한다. A광역지자체의 보도자료 페이지가 어수선했던 진짜 이유도 글꼴 종류만이 아니라 이 '위계의 부재'에 있었다. 제목과 본문이 비슷한 크기로 늘어서 있으니, 사용자는 '어디부터 읽어야 할지' 갈피를 못 잡았던 거다. 글꼴 표준이 가독성을 지킨다면, 타이포 위계는 '찾기 쉬움'을 지킨다.

A광역지자체가 이걸 푸는 방법도 어렵지 않다. '외부에서 가져온 콘텐츠는 우리 표준 글꼴로 정리한다'는 운영 규칙 하나, 그리고 '제목·본문·캡션의 크기와 굵기를 미리 정해둔다'는 약속 하나면 된다. 글꼴 문제는 '처음 디자인'보다 '운영 중 관리'의 문제인 경우가 많아서, 콘텐츠를 올리는 담당자가 작은 습관만 들여도 크게 좋아진다. 매번 새 페이지를 그릴 필요 없이, 정해진 위계에 글자를 '얹기만' 하면 되니까.

■ 단골 3 — 한중앙부처 사례: 정체불명의 버튼들

세 번째 단골은 버튼이다. 가상의 한중앙부처 정책 안내 페이지를 보자. 화면에 버튼처럼 생긴 게 여러 개 있는데, 자세히 보면 정체가 불분명하다.

· 링크인지 버튼인지 모를 요소

· 주 버튼과 보조 버튼이 똑같이 생겨 위계가 없는 화면

· 비활성 상태인데 멀쩡해 보여 자꾸 눌리는 버튼

· 마우스를 올려도, 키보드로 선택해도 아무 반응이 없는 버튼

한중앙부처 페이지에서 특히 눈에 띈 건 두 번째, '위계 없는 버튼'이었다. 신청 페이지에 버튼이 다섯 개 있는데 전부 똑같이 생겼다. 가장 중요한 '신청하기'와 그냥 '이전' 버튼이 색도 크기도 똑같으니, 사용자는 '어느 걸 눌러야 하지?'를 매번 고민하게 된다. 버튼이 다섯 개 있는데 다 똑같이 생겼다면 그건 '선택지가 다섯 개'가 아니라 '혼란이 다섯 개'다.

'정체불명의 버튼'이 생기는 근본 원인은 '버튼에도 종류가 있다'는 걸 정해두지 않았기 때문이다. 잘 설계된 사이트는 버튼을 역할별로 나눈다. 가장 중요한 행동(신청하기, 제출하기)을 하는 주 버튼은 가장 눈에 띄게, 그다음 행동(취소, 이전)을 하는 보조 버튼은 한 단계 차분하게, 위험한 행동(삭제)은 경고색으로, 단순 이동은 링크 형태로. 이렇게 '이건 어떤 버튼이다'가 모양에서 드러나야 사용자가 망설이지 않는다.

그리고 한중앙부처 사례에서 가장 마음에 걸렸던 건 네 번째, '반응 없는 버튼'이었다. 키보드로만 사이트를 쓰는 사용자는 지금 어디에 초점이 가 있는지 시각적 신호로 알아야 하는데, 그 신호가 없으면 길을 잃는다. 이건 접근성과 직결되는 문제이고, KWCAG 33항목에서도 초점 표시는 핵심으로 다룬다. 버튼 하나의 '포커스 표시 없음'이 단순한 디자인 누락이 아니라 '누군가는 이 사이트를 못 쓰게 되는' 장벽이 되는 거다. 이 접근성 이야기는 다음 달 편에서 자세히 다룬다.

한중앙부처 버튼 문제는 모바일에서 한 번 더 터졌다. 손가락으로 누르는 환경에서는 버튼이 충분히 커야 정확히 눌린다. 가이드 없이 PC 화면 기준으로만 만든 버튼은 모바일에서 너무 작거나 서로 너무 붙어 있어, 누르려던 버튼 옆의 다른 버튼이 눌려 엉뚱한 페이지로 가는 일이 잦다. 공공 사이트는 어르신을 비롯해 디지털에 익숙하지 않은 사용자도 많이 쓴다. 버튼 하나가 작아서 못 누르면, 그 사용자에게 그 서비스는 '없는 서비스'나 마찬가지다. 표준은 누구나 정확히 누를 수 있는 최소 크기를 정해두어 이 문제를 막는다.

버튼과 관련해 한 가지 더 흔한 문제는 '버튼 글자'다. 같은 기능을 하는 버튼인데 어떤 페이지에선 '신청', 어떤 페이지에선 '접수', 또 어떤 페이지에선 '제출하기'라고 적혀 있으면 사용자는 '이게 같은 건가 다른 건가' 헷갈린다. 버튼 글자는 짧지만 사용자가 행동을 결정하는 핵심 단서다. 그래서 잘 만든 사이트는 '무슨 행동을 하는 버튼은 무슨 단어로 쓴다'는 것까지 약속해 둔다. 한중앙부처처럼 부서마다 페이지를 따로 만들면 이 '말투의 일관성'이 가장 먼저 깨진다. 부서 A는 '신청', 부서 B는 '접수'를 쓰는 식이다. 버튼은 모양만이 아니라 글자도 통일돼야 한다는 걸, 한중앙부처 사례가 잘 보여준다.

■ 단골 4 — B공공기관 사례: 폼이 사용자를 골탕 먹인다

네 번째 단골은 한 층 위로 올라간다. BP, 즉 폼 패턴이다. 가상의 B공공기관 민원 신청 폼을 보자. 겉보기엔 멀쩡한데, 실제로 작성해보면 곳곳에서 사용자가 골탕을 먹는다.

가장 흔한 건 '라벨 없는 입력칸'이다. 입력칸 안에 흐릿한 안내문(플레이스홀더)만 떠 있고 바깥에 라벨이 없으면, 사용자가 뭔가 입력하는 순간 그 안내문이 사라져서 '이 칸이 무슨 칸이었지?'를 잊어버린다. 특히 화면을 읽어주는 보조기기를 쓰는 사용자에게는 라벨 없는 칸이 '이름 없는 칸'이 된다. 뭘 넣어야 하는지 알 길이 없다.

두 번째는 '오류를 알려주지 않거나, 알려줘도 어디가 틀렸는지 안 짚어주는' 폼이다. B공공기관 폼에서는 신청 버튼을 눌렀더니 페이지 맨 위에 '입력값을 확인하세요'라는 빨간 글자만 뜨고, 정작 열다섯 개 칸 중 어디가 틀렸는지는 알려주지 않았다. 사용자는 처음부터 끝까지 다시 훑으며 틀린 곳을 찾아야 한다. 이건 작은 불편이 아니다. 신청을 포기하게 만드는 결정적 장벽이다.

세 번째는 '동의·확인 절차의 혼란'이다. 필수 동의와 선택 동의가 구분 없이 줄줄이 나열돼 있고, '전체 동의'를 누르면 선택 항목까지 다 체크돼버린다. 사용자는 자기가 뭘 동의했는지도 모른 채 다음으로 넘어간다. 공공 서비스에서 동의는 곧 권리·의무와 직결되는데, 그 동의를 흐릿하게 받는 건 위험하다.

'라벨 없는 입력칸'을 조금 더 풀어보자. 라벨 문제는 '안내문(플레이스홀더)으로 라벨을 대신하면 된다'는 흔한 착각에서 시작된다. 칸 안에 흐릿한 글씨로 '이름을 입력하세요'라고 적어두면 깔끔해 보이고 공간도 절약되니, 라벨을 따로 안 붙이고 싶은 유혹이 든다. 하지만 안내문은 입력을 시작하는 순간 사라진다. 긴 폼을 작성하다 중간에 '이 칸이 뭐였더라' 하고 위를 봐도 라벨이 없으니 확인할 길이 없다. 특히 어르신이나 천천히 입력하는 사용자일수록 이 '사라진 안내' 때문에 더 헤맨다. 그래서 표준은 '라벨은 항상 보이게, 안내문은 보조로만'을 원칙으로 둔다. 라벨에는 '무엇을 적는 칸인가'뿐 아니라 '어떻게 적어야 하는가'도 담겨야 한다. 전화번호를 하이픈 넣고 적어야 하는지, 날짜를 어떤 형식으로 적어야 하는지, 필수인지 선택인지 — 이런 정보가 입력 '전에' 보여야 사용자가 한 번에 제대로 적는다. 좋은 폼은 '틀린 다음에 알려주는' 게 아니라 '틀리기 전에 알려주는' 폼이다.

'오류 안내' 이야기도 더 보태자. 가장 나쁜 오류 메시지는 B공공기관 폼처럼 '입력값을 확인하세요' 한 줄이다. 무엇이, 어디서, 왜 틀렸는지가 없으니 사용자는 그저 막막하다. 좋은 오류 안내는 세 가지를 담는다 — 어느 칸이 문제인지(위치), 무엇이 잘못됐는지(원인), 어떻게 고치면 되는지(해결). '전화번호 형식이 올바르지 않습니다. 숫자만 입력해 주세요'처럼 구체적이어야 사용자가 바로 고친다. 그리고 그 안내는 문제가 난 칸 '바로 옆'에 떠야 한다. 페이지 맨 위에 빨간 박스로 '확인하세요'만 띄우면, 사용자는 어느 칸이 문제인지 찾느라 다시 헤맨다. 오류 안내의 질이 곧 그 사이트의 친절함이다. 흐름이 끝에서 무너지는 사이트의 십중팔구는 이 오류 안내가 부실하다.

'동의·확인' 혼란도 공공 폼에서 특히 위험하다. B공공기관처럼 필수 동의와 선택 동의가 구분 없이 줄줄이 나열되고 '전체 동의'가 선택 항목까지 다 체크해버리면, 사용자는 자기가 무엇에 동의했는지도 모른 채 넘어간다. 공공 서비스에서 동의는 곧 권리·의무, 개인정보 처리와 직결된다. 그래서 '필수와 선택을 분명히 나누고, 전체 동의가 선택까지 강제하지 않게' 하는 건 단순한 편의가 아니라 사용자의 권리를 지키는 일이다. 잘 만든 폼은 '이 동의가 왜 필요한지'까지 짧게 덧붙여, 사용자가 안심하고 체크하게 돕는다.

B공공기관 사례가 보여주는 핵심은 이거다. BP 위반은 '눈에 안 보인다'. 폼을 멀리서 보면 멀쩡해 보인다. 직접 끝까지 작성해봐야 비로소 문제가 드러난다. 그래서 BP 영역은 '써보지 않으면 모르는' 위반이 많고, 바로 그렇기 때문에 진단 도구로 체계적으로 점검하는 게 특히 빛을 발하는 영역이다. 사람이 매번 모든 폼을 끝까지 작성해보며 점검할 수는 없으니까. 라벨 유무, 필수·선택 표시, 오류 안내 구조 같은 건 자동으로 일관되게 짚어주는 게 가장 확실하다.

■ 단골 5 — C기관 사례: 신청 여정이 중간에 끊긴다

마지막 단골은 가장 위층, SP다. 가상의 C기관 온라인 신청 서비스를 보자. 사용자가 '신청하기'를 눌러 시작하는 순간부터 완료까지의 여정 전체가 SP의 무대다.

C기관에서 발견한 문제는 '여정 중간이 끊긴다'는 거였다. 신청 1단계에서 정보를 입력하고 2단계로 넘어갔는데, 2단계에서 뒤로 가니 1단계에 입력했던 내용이 전부 날아가 있었다. 사용자는 처음부터 다시 입력해야 한다. 긴 신청서를 절반쯤 채우다 한 번 뒤로 갔다가 다 날린 사용자는, 그 자리에서 신청을 포기한다.

또 하나는 '지금 어디쯤 와 있는지 모른다'는 거였다. 전체 신청이 몇 단계인지, 지금이 몇 번째 단계인지 보여주는 진행 표시가 없으면, 사용자는 '이게 언제 끝나나' 하는 막막함 속에서 작성한다. 막막함은 이탈로 이어진다. 반면 '3단계 중 2단계' 같은 표시 하나만 있어도 사용자는 '조금만 더 하면 되는구나' 하고 끝까지 간다.

세 번째는 '완료됐는지 확신을 못 주는' 마무리였다. 신청을 끝냈는데 '접수되었습니다'라는 명확한 확인이 없으면, 사용자는 '이거 진짜 된 건가?' 하고 불안해한다. 그래서 같은 신청을 두 번, 세 번 반복하기도 한다. 공공 서비스에서 이런 중복 신청은 사용자도 피곤하고 기관도 일이 늘어나는, 양쪽 모두에게 손해인 결과를 낳는다.

C기관의 '여정 끊김'이 특히 뼈아픈 이유는, 그 지점까지 사용자가 이미 많은 걸 투자했기 때문이다. 정보를 찾고, 자격을 확인하고, 여러 칸을 채우고, 첨부파일까지 올린 사용자가 마지막에서 막히면 그동안의 노력이 한순간에 무너진다. 더 안타까운 건 이렇게 끝에서 이탈한 사용자가 '재방문'을 잘 안 한다는 점이다. 한 번 '이 기관은 신청이 안 되는 곳'이라는 인상이 박히면, 다음에 같은 민원이 필요해도 '또 그 고생을 하느니 직접 방문하자'가 된다. 온라인으로 처리하면 끝날 일이 창구 방문으로 돌아오고, 결국 C기관의 행정 부담으로 되돌아온다. 사용자 한 명의 신청 실패가 기관의 업무량으로 부메랑처럼 돌아오는 거다. SP 위반은 사용자 불편으로 끝나지 않고 기관의 일거리로 직결된다.

그래서 신청 흐름을 설계할 때 가장 중요한 세 가지는 '지금 어디쯤인지 보이기'(진행 표시), '무엇이 틀렸는지 그 자리에서 알려주기'(인라인 오류 안내), '되돌아가도 입력이 날아가지 않기'(상태 유지)다. 이 세 가지는 화려한 기능이 아니라 '기본 예의'에 가깝다. 사용자에게 '당신이 지금 무엇을 하고 있고, 무엇이 남았고, 무엇을 잘못했는지'를 정직하게 알려주는 것. C기관이 이 세 가지만 갖췄어도, 절반쯤 작성하다 입력이 날아가 포기하는 사용자도, 끝이 안 보여 중도 이탈하는 사용자도, 완료를 못 믿어 중복 신청하는 사용자도 크게 줄었을 거다. 흐름의 표준화는 '끝까지 완주하게 돕는 안전장치'인 셈이다.

C기관 사례가 말해주는 건, SP 위반은 '점이 아니라 선'이라는 거다. 한 화면의 문제가 아니라 '여러 화면을 거치는 흐름' 전체의 문제다. 그래서 한 페이지만 떼어 보면 안 보이고, 사용자처럼 처음부터 끝까지 따라가 봐야 드러난다. 그리고 이 '선의 문제'는 부품 하나를 고친다고 풀리지 않는다. 신청이라는 여정 전체를 다시 설계해야 한다. 그래서 흐름 붕괴는 발견이 늦을수록 고치는 비용이 커진다. 거꾸로 말하면, 자주 쓰는 핵심 신청 흐름 하나만 표준대로 잘 잡아두면, 그 패턴을 다른 신청 서비스에도 그대로 재사용할 수 있어 효율이 크게 오른다. SP는 '한 번 잘 만들어 여러 번 우려먹는' 영역이기도 하다.

그래서 어떻게 점검하나

■ 자주 걸리는 것부터, 한 화면씩

여기까지 다섯 단골을 보고 나면 '그럼 우리 사이트는 어디서부터 봐야 하지?' 하는 질문이 자연스레 든다. 답은 이미 글 곳곳에 깔려 있다. 아래층부터, 자주 쓰는 것부터다.

가장 먼저 색이다. 우리 사이트에 '브랜드 색'이 한 곳에 정의돼 있는지, 아니면 페이지마다 눈대중으로 박혀 있는지 본다. 다음은 글꼴이다. 한 페이지에 글꼴이 몇 종 섞여 있는지, 외부에서 붙여온 콘텐츠의 글꼴이 정리되는 규칙이 있는지 본다. 그다음이 버튼이다. 주·보조·위험 버튼이 구분되는지, 마우스·키보드에 반응하는지 본다. 그러고 나서 폼, 마지막으로 신청 여정을 본다.

이 순서가 중요한 이유가 있다. 아래층을 잡으면 위층 문제의 상당수가 '저절로' 풀리기 때문이다. 색과 글꼴 약속을 세우면 버튼도 자동으로 정돈되고, 버튼이 정돈되면 폼도 한결 나아지고, 폼이 좋아지면 신청 여정도 매끄러워진다. 거꾸로 위에서부터 손대면, 아래가 흔들리니 고쳐도 고쳐도 자꾸 다시 어긋난다. 그래서 '기초부터'라는 말은 답답해 보여도 결국 가장 빠른 길이다.

여기서 점검 대상을 고르는 요령도 하나 일러두고 싶다. 점검은 '대표 페이지 몇 개'가 아니라 '사용자가 실제로 많이 쓰는 페이지'를 대상으로 해야 한다. 메인 페이지는 보통 가장 공들여 만들기 때문에 멀쩡한 경우가 많다. 정작 문제는 사용자가 진짜 일을 보러 가는 신청·민원·검색·예약 페이지에 숨어 있다. 오늘 다섯 단골이 전부 '일하는 페이지'에서 터진 것도 우연이 아니다. ○○시의 색도, A광역지자체의 글꼴도, B공공기관의 폼도, C기관의 신청 여정도 다 '사용자가 실제로 손을 대는' 화면에서 드러났다. 그러니 점검할 때는 보여주기용 페이지가 아니라 일하는 페이지를, 그것도 처음부터 끝까지 따라가며 봐야 진짜 상태가 보인다.

또 하나, 기초 점검은 '한 화면씩' 보지 말고 '여러 화면을 나란히 놓고' 보는 게 요령이다. 메인, 목록, 상세, 신청 페이지를 동시에 띄워 비교하면 같은 요소가 페이지마다 어떻게 달라졌는지 한눈에 보인다. 혼자 보면 '이 정도면 괜찮은데' 싶던 것도, 나란히 놓으면 균열이 도드라진다. 특히 색과 간격은 한 화면 안에서는 잘 안 보이고 화면을 옮길 때 비로소 차이가 드러난다. ○○시의 '파랑 수십 종'도 한 페이지만 보면 그냥 파랑이지만, 여러 페이지를 나란히 놓으면 '어, 여기 파랑이랑 저기 파랑이 다르네'가 보인다. 그래서 기초 점검은 '비교'가 핵심이다.

부품 점검에는 또 다른 요령이 있다. '마우스를 떼고' 해보는 거다. 키보드의 탭 키만으로 페이지를 돌아다녀 보면, 탭을 누를 때마다 초점이 어디로 가는지 보이는지, 순서가 자연스러운지, 버튼이 엔터로 눌리는지가 드러난다. 마우스로는 멀쩡해 보이던 사이트의 허점이 줄줄이 나온다. 한중앙부처의 '반응 없는 버튼'도 마우스로는 안 보였지만, 탭 키로 돌아다녀 보면 '지금 내가 어디 있는지'를 알 수 없어 바로 드러났다. 이건 접근성 점검의 기본이자, 부품이 제대로 만들어졌는지를 가장 빠르게 검증하는 방법이다. 잘 만든 버튼·입력칸은 마우스 없이도 다 작동한다. 그렇지 않다면 그 부품은 '보이기만 하는 부품'이다.

■ 사람 눈으로는 다 못 본다 — 그래서 진단이 필요하다

여기서 솔직한 한계를 인정해야 한다. 다섯 단골 중 어느 것도 '사람 눈으로 대충 훑어서' 다 잡아낼 수 없다. 파란색 수십 종은 눈으로는 다 '같은 파랑'으로 보인다. 코드를 일일이 까봐야 미세한 차이가 드러난다. 라벨 없는 입력칸은 직접 보조기기로 읽어봐야 '이름 없는 칸'이라는 게 드러난다. 신청 여정의 끊김은 처음부터 끝까지 따라가 봐야 안다.

그러니까 846규칙을 점검한다는 건, 사람이 8백 개 항목을 손으로 일일이 체크한다는 뜻이 아니다. 그건 불가능하고, 한다 해도 사람마다 결과가 다를 거다. 핵심은 '기준에 맞춰 자동으로, 일관되게' 점검하는 거다. 같은 기준으로 같은 방식으로 보니까 누가 돌려도 같은 결과가 나오고, 100페이지든 1,000페이지든 똑같은 엄밀함으로 본다. 이게 바로 자동 진단의 힘이다.

■ ViewCheck은 이 '자주 걸리는 것'을 한눈에 보여준다

여기서 우리가 만든 ViewCheck 이야기를 잠깐 하겠다. ViewCheck은 URL 하나만 넣으면 KRDS 846규칙을 자동으로 점검해주는 진단 도구다. 오늘 글의 다섯 단골 — 색, 글꼴, 버튼, 폼, 신청 여정 — 이 실제로 내 사이트에서 어떻게 걸리는지를 화면으로 보여준다.

ViewCheck이 846을 다루는 방식이 바로 오늘 글의 메시지와 똑같다. 8백 개를 평평하게 늘어놓지 않는다. DS·CP·BP·SP 네 덩어리로 나눠서, 각 영역의 통과·위반·해당 없음을 한눈에 보여준다. 그래서 진단을 받으면 '아, 우리는 색(DS)이 제일 문제구나', '우리는 폼(BP)이 약하구나' 하는 게 바로 보인다. 막연한 846이 '우리가 공략할 구체적인 몇 군데'로 좁혀지는 거다.

특히 진단 결과 화면 맨 위에는 네 영역의 점수를 보여주는 점수 카드가 있다. 이 카드 하나만 봐도 '우리 사이트가 어느 층에서 무너지고 있는지'가 한눈에 들어온다. 색이 빨갛게 떠 있으면 기초부터, 폼이 빨갛게 떠 있으면 폼부터 — 오늘 글에서 말한 '아래층부터, 자주 걸리는 것부터'를 그대로 실천할 수 있게 안내한다.

그리고 ViewCheck은 단순히 '몇 점'만 던지지 않는다. 각 위반이 '어느 규칙에 걸렸는지', '어느 페이지의 어느 부분에서 났는지'까지 짚어준다. 그래서 ○○시처럼 '파랑이 수십 종'인 상황도, 막연히 '색을 정리하세요'가 아니라 '이 페이지의 이 요소가 표준 색에서 벗어났다'는 구체적인 형태로 보여준다. 막연한 숙제가 '오늘 당장 손볼 수 있는 항목'으로 바뀌는 거다. 게다가 한 페이지가 아니라 여러 페이지를 한꺼번에 돌릴 수 있어서, '우리 사이트 전체가 어디서 반복적으로 걸리는지' — 즉 진짜 단골이 무엇인지 — 를 사이트 차원에서 보여준다. 앞에서 '한 페이지만 보면 해당 없음이 많아 안심된다'고 했는데, 바로 그래서 여러 페이지를 묶어 보는 게 중요하고, ViewCheck은 그걸 자동으로 해준다.

오해를 풀자면, ViewCheck은 '846개를 사람이 손으로 체크하는 수고'를 대신해주는 도구이지, 디자인 감각을 대신하는 도구가 아니다. 무엇을 어떻게 고칠지 결정하는 건 여전히 사람의 몫이다. 다만 '무엇이 어디서 걸렸는지'를 일관되고 빠짐없이 찾아주는 그 지루하고 방대한 일을, 사람보다 훨씬 정확하게 대신해준다. 그래서 담당자는 '찾는 데' 쓰던 시간을 '고치는 데' 쓸 수 있다. 오늘 글의 메시지 — 846에 겁먹지 말고 자주 걸리는 것부터 — 를 실제로 실천하려면, 결국 '자주 걸리는 게 무엇인지'를 정확히 아는 게 출발점이고, ViewCheck은 바로 그 출발점을 손쉽게 만들어준다.

■ 846을 '무서운 숫자'가 아니라 '든든한 지도'로

다시 처음 이야기로 돌아가자. 846개라는 숫자에 겁먹지 마시라고 했다. 이제 그 이유가 좀 더 분명해졌을 거다.

846은 '다 외워야 할 시험 범위'가 아니다. 네 층으로 쌓인 질서 있는 구조이고, 그중 자주 걸리는 건 따로 있으며, 그 단골들은 대부분 아래층 몇 군데에 몰려 있다. 게다가 내 사이트에 없는 부품·기능의 규칙은 '해당 없음'으로 빠지니, 실제로 챙길 건 846보다 훨씬 적다.

다시 한번 네 덩어리를 떠올려 보자. DS 120, CP 446, BP 108, SP 172. 이 숫자를 외울 필요는 없다. 다만 '기초가 가장 밑에 있고, 부품이 가장 많고, 그 위에 작은 흐름과 큰 흐름이 얹힌다'는 그림만 기억하면 된다. 그 그림을 머릿속에 두면, 내 사이트에서 문제가 터졌을 때 '이게 어느 층의 문제인가'를 가늠할 수 있다. 색이 이상하면 DS, 버튼이 이상하면 CP, 폼이 이상하면 BP, 신청이 이상하면 SP. 그리고 '증상은 위에서 터져도 원인은 아래에 있을 때가 많다'는 것까지 떠올리면, 어디부터 손볼지가 보인다. 이 정도면 846을 다루는 데 필요한 '지도 읽는 법'은 충분히 갖춘 셈이다.

그러니 846을 '무서운 숫자'가 아니라 '든든한 지도'로 받아들이면 좋겠다. 지도가 자세할수록 길을 잃지 않는다. KRDS가 8백 개가 넘는 규칙으로 촘촘한 건, 우리를 압박하려는 게 아니라 '어떤 화면을 만들든 답을 찾을 수 있게' 길을 깔아둔 거다. 그 지도를 들고, 자주 다니는 길(자주 걸리는 단골)부터 정비하면 된다.

오늘 다룬 ○○시·A광역지자체·한중앙부처·B공공기관·C기관 사례는 전부 가상의 익명 사례지만, 그 안의 패턴은 현실에서 거의 그대로 반복된다. 그러니 읽으면서 '우리도 저런데' 싶은 대목이 있었다면, 그게 바로 가장 먼저 손볼 지점이다. 자책할 필요는 전혀 없다. 가이드 없이 여러 사람이 오랜 시간 손대면 누구나 겪는 일이고, 누구나 같은 방법으로 풀어왔다. 중요한 건 그 패턴을 '알아보는 눈'을 갖추는 것이고, 오늘 글이 그 눈을 조금이라도 밝혀줬다면 더 바랄 게 없다.

그리고 KRDS가 행정안전부의 「전자정부 웹사이트 품질관리 지침」 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과도 맞물려 있다는 점을 기억하면 좋겠다. 오늘 다룬 단골들 — 색·글꼴·버튼·폼·신청 여정 — 은 디자인 일관성의 문제이면서 동시에 접근성·편의성·신뢰성과 직결된다. 색 대비가 부족하면 접근성이 깎이고, 폼이 불친절하면 편의성이 떨어지고, 글꼴이 들쭉날쭉하면 신뢰성에 흠집이 난다. 그러니 '디자인을 정돈한다'는 일은 단순히 보기 좋게 만드는 게 아니라, 공공 웹사이트가 갖춰야 할 품질의 여러 축을 동시에 끌어올리는 일이다. 846규칙을 챙기는 게 결국 그 7대 영역을 챙기는 일과 한 몸으로 굴러간다는 뜻이다.

마지막으로 '우선순위' 이야기를 한 번 더 강조하고 싶다. 모든 위반을 한꺼번에 다 잡으려 하면 시작도 못 한다. 그러지 말고 '가장 많은 페이지에 영향을 주는 것'부터, '사용자가 가장 자주 쓰는 흐름'부터 손대자. 색 약속 하나, 표준 버튼 하나, 핵심 신청 흐름 하나. 이 세 가지만 잡아도 사이트의 인상은 확연히 달라진다. 그리고 그 변화는 '노력 대비 효과'가 가장 큰 변화다. 846을 한 번에 정복하려 하지 말고, 가장 자주 걸리는 단골부터 하나씩 줄여가는 게, 멀리 보면 가장 빠르고 가장 덜 지치는 길이다.

마무리

긴 글을 정리하자. 846은 네 덩어리(DS 120·CP 446·BP 108·SP 172)로 나뉘고, 자주 걸리는 위반은 색·글꼴·버튼·폼·신청 여정이라는 단골 자리에 몰려 있으며, 그 단골은 대부분 아래층에 있어서 기초 몇 개만 잡아도 사이트 전체가 한꺼번에 좋아진다. 그리고 이 모든 점검은 사람 눈으로는 한계가 있어 '일관된 자동 진단'이 필요하다. 이게 오늘 글의 전부다.

한 문장으로 더 줄이면 이렇다. '규칙이 많다고 다 어려운 게 아니다. 자주 걸리는 건 따로 있고, 그건 충분히 잡을 수 있다.' 오늘 다섯 단골 사례를 통해 '무엇이 어떻게 잘못되는지'를 봤다면, 이제 남은 건 '내 사이트는 어떤가'를 확인하는 일뿐이다. 그 확인이 두렵게 느껴질 수 있다. 막상 열어봤다가 위반이 잔뜩 나오면 어쩌나 싶을 거다. 하지만 앞에서 말했듯, 위반의 정체를 아는 순간 두려움은 '할 일 목록'으로 바뀐다. 모르는 게 무섭지, 아는 건 그냥 처리하면 되는 일이다.

마지막으로, 백 번 듣는 것보다 한 번 보는 게 낫다. 내 사이트가 어느 층에서 무너지고 있는지, 다섯 단골 중 무엇이 걸리는지 궁금하다면 직접 확인해보시길 권한다. krds.viewcheck.co.kr 에서 URL만 넣으면 무료로 진단을 체험할 수 있다. 회원가입이나 복잡한 절차 없이, 우리 사이트의 점수 카드를 바로 받아볼 수 있다. 오늘 글을 읽으며 '우리도 저럴 것 같은데' 싶었던 그 막연한 불안을, 구체적인 숫자와 화면으로 바꿔보시라. 정체를 알면 무섭지 않다고 했다. 846도, 내 사이트의 위반도 마찬가지다. 한 번 들여다보는 순간, '이거 우리가 손댈 수 있는 거구나' 하는 안도가 먼저 찾아올 거다.

진단은 채점이 아니라 '다음에 무엇을 할지 정하는 지도'다. 점수가 낮게 나와도 좌절할 필요 없고, 높게 나와도 방심할 필요 없다. 중요한 건 '우리는 어느 층이 약한가'를 알아서 손볼 순서를 정하는 거다. 색이 약하면 색부터, 폼이 약하면 폼부터. 그 우선순위만 잡혀도 막막함은 사라지고, '오늘은 이것부터'라는 구체적인 출발선이 생긴다. 그리고 그 출발선에 서는 데 드는 비용은, 무료 진단으로 시작하면 0원이다.

겁먹지 마시라. 자주 걸리는 건 따로 있고, 그건 충분히 잡을 수 있다. 846이라는 숫자가 아니라, 그 안에 숨은 '우리 사이트의 단골 몇 개'에 집중하면 된다. 그 첫걸음을, 오늘 가볍게 한 번 떼어보시길. krds.viewcheck.co.kr 에서 URL 하나 넣는 데 1분도 안 걸린다. 그 1분이, 막연했던 846을 '손에 잡히는 할 일'로 바꿔줄 거다.