우리 사이트 KRDS 적용 여부, 5분 자가 체크리스트

[금·체크리스트] 우리 사이트 KRDS 적용 여부, 5분 자가 체크리스트

══════════════════════════════════════════════════

공감·문제제기

이번 주 월요일엔 KRDS가 뭔지, 수요일엔 가이드 없는 사이트가 어떻게 망가지는지를 다뤘다. 오늘은 가장 실용적인 이야기다. '우리 사이트가 KRDS 기준에서 얼마나 떨어져 있는지'를 5분 만에 스스로 가늠해보는 체크리스트다.

먼저 분명히 해두자. 이 체크리스트는 846개 규칙을 다 따지는 정밀 진단이 아니다. 그건 사람이 손으로 할 수 있는 일이 아니다. 대신 '가장 자주 걸리고, 영향이 큰' 핵심 항목만 추려, 비전문가도 눈으로 빠르게 확인할 수 있게 만든 거다. 일종의 자가 건강 체크다. 정밀 검사는 도구에 맡기되, 그 전에 '대충 어디가 안 좋은지' 감을 잡는 용도다.

왜 '디자인 담당자도 아닌 내가' 이런 걸 해야 하나 싶을 수 있다. 하지만 공공 사이트의 품질은 디자이너 한 사람의 책임이 아니다. 콘텐츠를 올리는 담당자, 신청 양식을 기획하는 담당자, 외주를 관리하는 담당자 — 사이트에 손을 대는 모든 사람이 조금씩 사이트의 품질을 만든다. 그래서 '무엇이 좋은 사이트인가'에 대한 감각을 모두가 조금씩 갖추는 게 중요하다. 오늘 체크리스트는 디자인 전문 지식이 없어도 '쓰는 사람 입장에서 불편한지 아닌지'만 따져보면 답할 수 있게 만들었다. 전문가가 아니어도, 아니 오히려 전문가가 아니기에 더 잘 보이는 문제들이 있다. 매일 그 사이트를 들여다보는 담당자보다, 가끔 들어오는 일반 사용자의 눈이 더 정확할 때가 많다.

그리고 이 점검이 '비용이 안 드는 일'이라는 것도 매력이다. 외부 컨설팅을 부르거나 도구를 사기 전에, 지금 당장 5분이면 시작할 수 있다. 돈도 안 들고, 결재도 필요 없고, 누구의 허락도 필요 없다. 그저 우리 사이트를 사용자의 눈으로 한 바퀴 돌아보는 것뿐이다. 이 작은 시작이 '우리 사이트를 제대로 보기'의 첫걸음이 된다. 거창한 개편 계획을 세우기 전에, 먼저 '지금 어떤 상태인지' 아는 것 — 모든 개선은 거기서 출발한다.

준비물은 간단하다. 우리 기관 사이트, 그리고 스마트폰 하나. 데스크탑과 모바일 둘 다 봐야 하니 둘 다 켜두면 좋다. 펜과 종이(혹은 메모 앱)에 '예/아니오'를 적어가며 따라오면 된다. 시작하자.

점검을 시작하기 전에 마음가짐 하나만 다잡자. 이건 '시험'이 아니라 '건강검진'이다. 시험이라면 좋은 점수를 받는 게 목적이지만, 검진은 '어디가 안 좋은지 찾아내는 게' 목적이다. 그러니 '아니오'가 많이 나올수록 오히려 점검이 잘된 거다. 문제를 많이 찾았다는 건 고칠 거리를 많이 확보했다는 뜻이고, 그건 곧 사이트가 좋아질 여지가 그만큼 크다는 뜻이다. 반대로 모든 항목에 '예'를 적고 있다면, 점검이 잘된 게 아니라 '너무 후하게 보고 있는' 건 아닌지 의심해야 한다. 좋은 점검자는 자기 사이트에 엄격하다. 이 글을 따라오는 동안만큼은, 우리 사이트를 '처음 온 까다로운 사용자'의 눈으로 봐주길 바란다.

한 가지 미리 당부하자면, 체크할 때는 '만든 사람'의 마음이 아니라 '쓰는 사람'의 마음으로 보는 게 중요하다. 우리는 우리 사이트를 너무 잘 안다. 어느 메뉴가 어디 있는지, 신청 버튼이 어느 구석에 숨어 있는지 다 외우고 있다. 그래서 '이 정도면 알아보겠지' 하고 넘기기 쉽다. 하지만 처음 방문한 사용자는 아무것도 모른다. 그 사람의 눈으로 봐야 진짜 문제가 보인다. 가능하면 사이트를 잘 모르는 동료나 가족에게 '이 페이지에서 OO 신청을 해보라'고 부탁하고 옆에서 지켜보는 것도 좋은 방법이다. 그 사람이 어디서 멈칫하고, 어디서 '이거 어떻게 하는 거예요?'라고 묻는지가 곧 우리 사이트의 약점이다.

그리고 이 체크리스트는 '한 번 하고 끝'이 아니라 '정기적으로 반복'할 때 진가가 드러난다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 추가되고 페이지가 늘어나면서 계속 변한다. 오늘 '예'였던 항목이 반년 뒤엔 '아니오'가 되어 있을 수 있다. 그래서 분기에 한 번쯤 같은 체크리스트로 다시 점검하면, 사이트가 좋아지고 있는지 나빠지고 있는지 추세가 보인다. 오늘의 점검은 그 첫 번째 기준점을 찍는 일이다.

왜 중요한가

■ 왜 '자가 체크'부터 해야 하나

"그냥 도구 돌리면 되는 거 아니에요?"라고 물을 수 있다. 맞다, 정밀 진단은 도구가 한다. 하지만 자가 체크를 먼저 해보는 데는 분명한 이유가 있다.

첫째, '내 눈으로' 문제를 봐야 개선 의지가 생긴다. 점수만 받으면 '아 낮네' 하고 끝나기 쉽다. 직접 버튼을 눌러보고, 키보드로 돌아다녀 보고, 폼을 채워보면 '아 이게 이렇게 불편했구나'가 몸으로 와닿는다. 그 체감이 개선을 밀어붙이는 동력이 된다.

둘째, 도구 결과를 '읽을 줄' 알게 된다. 자가 체크로 항목들의 의미를 한번 이해해두면, 나중에 자동 진단 리포트를 봤을 때 숫자가 그냥 숫자가 아니라 '아 이게 그 항목이구나'로 읽힌다. 자동 진단 결과지를 처음 받아 든 담당자들이 가장 흔히 하는 말이 '숫자는 많은데 뭘 봐야 할지 모르겠다'이다. 항목 하나하나가 무슨 뜻인지 모르면, 점수가 빨강이든 파랑이든 '그래서 어쩌라는 거지'에서 멈춘다. 오늘처럼 직접 버튼을 눌러보고 폼을 채워본 경험이 있으면, 같은 결과지가 '아, 그때 그 불편했던 게 이 항목이구나'로 살아 움직인다. 도구는 '무엇이 문제인지'를 알려주지만, 그 문제가 '왜 문제인지'를 아는 건 결국 사람의 몫이다. 자가 체크는 바로 그 '왜'를 몸으로 익히는 과정이다.

셋째, 빠르다. 5분이면 '우리 사이트가 대충 어느 수준인지' 감이 온다. 본격적인 진단과 개선에 들어가기 전, 가벼운 워밍업으로 딱이다. 그리고 이 '빠름'에는 또 다른 가치가 있다. 무거운 진단은 마음먹고 날을 잡아야 하지만, 5분짜리 체크는 점심시간에도, 회의 시작 전에도 할 수 있다. 부담이 작으니 자주 하게 되고, 자주 하니 변화를 일찍 알아챈다. 큰 검진을 1년에 한 번 받는 것보다, 작은 체크를 분기마다 하는 쪽이 사이트 건강에는 더 이롭다.

넷째, '대화의 출발점'이 생긴다. 사이트 개선은 혼자 하는 일이 아니다. 담당 부서, 윗선, 외주 업체가 함께 움직여야 한다. 그런데 '우리 사이트 좀 별로인 것 같아요'라는 막연한 말로는 누구도 움직이지 않는다. 반면 '제가 자가 체크를 해봤더니 17개 항목 중 흐름과 접근성에서 아니오가 7개 나왔습니다'라고 하면, 이야기가 구체적인 안건이 된다. 자가 체크는 '문제를 말로 꺼낼 수 있게' 만들어주는 도구다. 손에 쥔 점검 결과 하나가, 미뤄지던 개선 논의를 시작하게 만드는 방아쇠가 된다.

자가 체크가 '정밀 진단'을 대체하는 게 아니라는 점도 분명히 해두자. 둘은 역할이 다르다. 자가 체크는 '빠르고 거칠게' 전체 윤곽을 잡는 일이고, 정밀 진단은 '느리지만 정확하게' 세부를 따지는 일이다. 건강에 빗대면 자가 체크는 '요즘 좀 피곤한데 어디가 문제지' 하고 스스로 살펴보는 것이고, 정밀 진단은 병원에서 정밀 검사를 받는 것이다. 둘 다 필요하다. 자가 체크 없이 바로 정밀 진단만 받으면 '숫자는 나왔는데 뭘 봐야 할지 모르는' 상태가 되고, 정밀 진단 없이 자가 체크만 믿으면 '눈에 안 보이는 깊은 문제'를 놓친다. 그래서 오늘 글은 '자가 체크로 감을 잡고, 그다음 정밀 진단으로 확정하라'는 순서를 권한다.

■ 체크리스트의 구성

오늘 체크리스트는 KRDS의 네 영역(DS·CP·BP·SP)에 운영 관점을 더해 다섯 묶음으로 구성했다. 각 묶음에서 핵심 질문 몇 개씩만 던진다. 전부 '예/아니오'로 답할 수 있게 만들었다.

· A. 기초(DS): 색·글꼴·간격

· B. 부품(CP): 버튼·폼·메뉴

· C. 흐름(BP·SP): 신청·검색·오류

· D. 접근성: 모두가 쓸 수 있나

· E. 모바일·운영

왜 이 다섯 묶음일까. 앞선 두 글에서 봤듯, KRDS는 사이트를 '층'으로 본다. 가장 아래에 색·글꼴·간격 같은 기초(DS)가 있고, 그 위에 버튼·입력칸 같은 부품(CP)이 올라가고, 다시 그 위에 신청·검색 같은 흐름(BP·SP)이 얹힌다. 기초가 흔들리면 그 위의 부품과 흐름도 함께 흔들린다. 그래서 점검도 이 층의 순서를 따른다. 거기에 '모두가 쓸 수 있는가'를 보는 접근성, '앞으로도 유지되는가'를 보는 운영을 더해 다섯 묶음이 됐다. 이 다섯을 차례로 보면, 사이트를 '기초→부품→흐름→모두에게→앞으로까지' 한 바퀴 빠짐없이 훑게 된다. 이 순서에는 또 다른 장점이 있다. 아래층(기초)에서 문제가 발견되면, 그 위층(부품·흐름)의 문제 중 상당수가 '아래층 때문에 생긴 것'임을 알게 된다. 예를 들어 버튼이 잘 안 보이는 문제(B)가 사실은 색 대비 기준이 없는 기초(A)의 문제에서 비롯된 경우가 많다. 그래서 아래층부터 보면 '진짜 원인'과 '그 원인이 만든 증상'을 구분할 수 있고, 증상만 쫓아 고치다 같은 문제가 또 터지는 일을 막을 수 있다. 점검을 층의 순서로 하는 건, 단지 빠짐없이 보기 위해서만이 아니라 '원인과 결과를 제대로 가려내기' 위해서이기도 하다.

체크할 때 '예/아니오'가 애매한 항목이 분명 나올 거다. '이게 예인가 아니오인가' 싶을 땐, 망설이지 말고 '아니오'로 적는 걸 권한다. 점검의 목적은 좋은 점수를 받는 게 아니라 '고칠 곳을 찾는 것'이기 때문이다. 후하게 채점해서 '우리 괜찮네' 하고 넘어가면, 정작 손봐야 할 곳을 놓친다. 의심스러우면 사용자 편에 서서 더 엄격하게 보는 게, 결국 사용자에게도 우리에게도 이득이다.

한 가지 더, 다섯 묶음을 '순서대로' 보는 걸 권한다. 마음 가는 대로 이것저것 건너뛰며 보면, 분명 어떤 영역은 통째로 빼먹게 된다. 특히 접근성(D)과 운영(E)은 눈에 잘 안 띄어서 자꾸 뒤로 밀리는데, 정작 가장 중요한 영역이 그 둘일 때가 많다. 그러니 A부터 E까지 차례대로, 각 묶음을 다 끝내고 다음으로 넘어가는 식으로 진행하라. 5분이 조금 넘더라도, 빠짐없이 한 바퀴 도는 게 '대충 많이 보는 것'보다 낫다.

자, 하나씩 가보자.

흔한 실수·사례 (익명)

여기서는 체크 항목과 함께, 각 항목에서 자주 발견되는 실제 문제 양상을 익명으로 곁들인다. 내 사이트와 비교하며 읽으면 체감이 빠르다.

곁들이는 사례들은 전부 익명 처리한 것이다. 특정 기관을 흉보려는 게 아니라, 어디서나 반복되는 '전형'을 보여주려는 거다. 이 패턴들은 규모가 크든 작든, 예산이 많든 적든 거의 똑같이 나타난다. 잘 만든 사이트라고 안 나오는 게 아니라 '덜 나오는' 정도의 차이일 뿐이다. 그러니 읽으면서 '우리도 저런데' 싶은 게 나와도 자책할 필요는 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다. 중요한 건 그 패턴을 알아보는 눈을 갖추는 것이다.

각 묶음을 볼 때는 '예/아니오'만 적지 말고, '아니오' 옆에 한 줄짜리 메모를 남기길 권한다. 이를테면 'B-2 아니오 — 신청 페이지에서 제출·취소 버튼이 똑같이 생김'처럼. 이 한 줄이 나중에 '무엇을 고쳐야 하는지'를 정확히 짚어주는 작업 지시서가 된다. 점검만 하고 무엇이 문제였는지 적어두지 않으면, 며칠만 지나도 '분명 뭔가 아니오가 많았는데 뭐였더라'가 된다. 점검의 가치는 '발견'이 아니라 '기록'에서 완성된다.

사례를 읽을 때 한 가지 당부하자면, '우리는 저 정도는 아니다'라고 성급히 넘기지 말기를 바란다. 자기 사이트의 문제는 늘 '남의 것보다 가벼워 보인다'. 매일 보던 화면이라 익숙해진 탓이다. 그래서 사례를 읽을 때는 '우리는 아니겠지'가 아니라 '혹시 우리도?' 하는 마음으로, 실제로 우리 사이트의 해당 페이지를 열어 확인해보는 게 좋다. 아래 사례들은 특정 기관의 흠이 아니라 '공공웹 어디에나 있는 전형'이라, 십중팔구 우리 사이트에서도 비슷한 장면을 찾게 될 것이다. 그걸 찾았다고 부끄러워할 일은 전혀 없다. 못 찾는 게, 다시 말해 '안 보이는 게' 더 위험하다.

■ A. 기초(DS) 체크

A-1. 메인에서 하위 페이지로 두세 단계 들어갔을 때 색·분위기가 일관적인가?

→ 자주 보이는 문제: 부서별로 만든 페이지마다 색조가 달라 '다른 사이트' 느낌. 들어갈수록 통일감이 깨진다.

A-2. 한 페이지 안에서 글꼴이 두 종 이하로 유지되는가?

→ 자주 보이는 문제: 본문·제목·표·외부 위젯이 제각각 글꼴. 어수선하고 신뢰감이 떨어진다.

A-3. 요소 간 간격과 정렬이 가지런한가?

→ 자주 보이는 문제: 여백이 들쭉날쭉해 '아마추어처럼' 보인다. 8단위 같은 간격 규칙이 없을 때 흔하다.

세 항목 중 '아니오'가 있다면 기초(DS)에서 점수가 깎이고 있을 가능성이 높다. A 영역을 점검하는 가장 쉬운 방법은 '여러 페이지를 빠르게 넘겨보는 것'이다. 메인에서 출발해 부서 페이지, 신청 페이지, 안내 페이지를 차례로 열어 화면을 죽 스크롤해 보라. 색조와 분위기가 '같은 사이트 안에 있다'는 느낌으로 이어지면 통과고, 페이지마다 '여기는 좀 다른 데 들어온 것 같은데' 싶으면 일관성이 깨진 거다. 글꼴도 마찬가지다. 한 화면 안에서 제목·본문·표·버튼의 글자 모양이 제각각이면, 우리는 그걸 또렷이 의식하진 못해도 '어수선하다' '덜 정돈됐다'는 인상을 받는다. 기초는 이렇게 '딱 집어 말하긴 어렵지만 분명히 느껴지는' 영역이라, 한 페이지만 보지 말고 여러 페이지를 나란히 놓고 비교하는 게 핵심이다.

기초가 중요한 이유를 한 번 더 짚자. 색·글꼴·간격은 사용자가 '의식하지 않지만 가장 먼저 느끼는' 요소다. 사이트에 들어선 순간, 글을 읽기도 전에 '여기 정돈됐네' 혹은 '여기 어수선하네' 하는 인상이 0.1초 만에 박힌다. 그 첫인상이 '이 기관이 일을 꼼꼼히 하는가'에 대한 무의식적 판단으로 이어진다. 내용이 아무리 좋아도 기초가 흐트러져 있으면 신뢰가 깎인다. 그래서 기초 점검에서 '아니오'가 나왔다면, 그건 단순한 미관 문제가 아니라 '사이트 전체의 신뢰도가 새고 있다'는 신호로 봐야 한다.

A 영역을 체크할 때 요령 하나. 한 페이지만 보지 말고, 메인·목록·상세·신청 페이지를 '동시에 띄워 비교'해 보라. 같은 '파랑'인데 페이지마다 미묘하게 다른지, 같은 '제목'인데 크기가 들쭉날쭉한지는 한 화면만 봐서는 잘 안 보인다. 여러 화면을 나란히 놓고 눈을 옮겨야 비로소 차이가 도드라진다. 색과 간격의 균열은 '화면을 넘나들 때' 가장 잘 드러나기 때문이다. 혼자 한 페이지씩 보면 '이 정도면 괜찮은데' 싶던 것도, 모아 놓으면 '아, 제각각이구나'가 한눈에 들어온다.

기초가 흐트러지는 근본 원인은 거의 항상 같다. '기준이 머릿속에만 있고, 화면 어디에도 적혀 있지 않다'는 것이다. 페이지를 만들 때마다 담당자나 외주가 '대충 비슷한 파랑'을 눈대중으로 골라 코드에 직접 박는다. 정해진 '브랜드 파랑' 하나를 공유해 쓴 게 아니라 각자 기억에 의존한다. 그런데 머릿속의 파랑은 사람마다 다르고, 같은 사람도 모니터가 바뀌면 다르게 본다. 이렇게 '각자의 기억'으로 만든 결과물이 모이면, 개별로는 다 그럴듯한데 전체로는 제각각인 사이트가 된다. 그래서 기초 문제의 해법은 '색을 더 잘 고르는 것'이 아니라 '기준을 화면 밖으로 꺼내 모두가 같은 걸 보고 쓰게 하는 것'이다. 이게 바로 디자인 토큰이고, KRDS가 색·글꼴·간격을 토큰으로 정리해 둔 이유다.

A 영역에서 '아니오'가 나왔다면, 당장 모든 페이지의 색을 다 고치려 들지 말자. 그건 끝이 안 보이는 일이다. 대신 '앞으로 만드는 것부터 기준을 지키게' 하고, 기존 페이지는 자주 쓰는 것부터 천천히 정리하는 게 현실적이다. 기초는 한 번에 다 잡는 게 아니라, 기준을 세워두고 점진적으로 수렴시키는 영역이다. 새 페이지가 모두 같은 파랑을 쓰기 시작하면, 시간이 지날수록 사이트는 저절로 정돈된다. 이렇게 보면 기초(A) 영역의 '아니오'는 '지금 당장 큰일'이라기보다 '기준을 세울 때가 됐다'는 신호에 가깝다. 색·글꼴·간격의 기준 하나만 정해 모두가 공유하면, 그날 이후의 모든 페이지가 그 기준을 따라가며 사이트가 서서히 한 몸이 된다. 급하게 다 뜯어고치는 것보다, 기준을 세우고 그 위에 차곡차곡 쌓는 쪽이 기초 영역에서는 정답이다.

■ B. 부품(CP) 체크

B-1. 화면에서 '무엇을 누를 수 있는지' 한눈에 보이는가?

→ 자주 보이는 문제: 버튼인지 텍스트인지 모를 요소들. 눌러봐야 안다.

B-2. '제출/확인' 같은 주 버튼과 '취소' 같은 보조 버튼이 시각적으로 구분되는가?

→ 자주 보이는 문제: 둘이 똑같이 생겨 실수로 취소를 눌러 작업이 날아간다.

B-3. 입력칸마다 바깥에 라벨이 붙어 있는가? (칸 안 흐린 글씨 말고)

→ 자주 보이는 문제: 입력 시작하면 안내문이 사라져 무슨 칸인지 헷갈린다.

B-4. 키보드 Tab 키로 버튼·링크를 이동할 때, 지금 어디에 있는지 '선택 표시(초점 테두리)'가 보이는가?

→ 자주 보이는 문제: 초점 표시가 없어 키보드 사용자가 길을 잃는다.

'아니오'가 많을수록 부품(CP) 품질이 낮은 것이다. 특히 B-4는 접근성과 직결되니 중요하게 본다.

부품 영역을 점검하는 가장 확실한 방법은 '마우스를 손에서 떼는' 것이다. 키보드의 Tab 키만으로 페이지를 처음부터 끝까지 돌아다녀 보라. Tab을 누를 때마다 초점이 어디로 가는지 눈에 보이는지, 그 순서가 위에서 아래로·왼쪽에서 오른쪽으로 자연스러운지, 버튼이 엔터로 눌리는지를 확인하면, 마우스로는 멀쩡해 보이던 사이트의 허점이 줄줄이 나온다. 잘 만든 버튼과 입력칸은 마우스 없이도 다 작동한다. 만약 어떤 기능이 '마우스로만' 되고 키보드로는 안 된다면, 그 부품은 '보이기만 하는 부품'이고, 키보드를 쓰는 사용자에게는 '없는 기능'이나 마찬가지다.

부품 점검에서 의외로 많이 놓치는 게 '버튼 글자의 일관성'이다. 같은 동작을 하는 버튼인데 어느 페이지에선 '신청', 어디선 '접수', 또 어디선 '제출하기'라고 적혀 있으면, 사용자는 '이게 같은 건가' 헷갈린다. 버튼 글자는 짧지만 사용자가 행동을 결정하는 핵심 단서다. 그러니 B 영역을 볼 때 '버튼이 잘 보이나'뿐 아니라 '같은 일을 하는 버튼이 같은 말을 쓰나'도 함께 확인하면 좋다. 모양의 일관성만큼이나 '말의 일관성'도 부품 품질의 일부다.

부품(CP)이 KRDS 846규칙 중 가장 많은 446개를 차지하는 데는 이유가 있다. 버튼·입력칸·메뉴·표·알림창 같은 부품은 사용자가 '직접 손으로 만지는' 접점이기 때문이다. 기초(DS)가 '분위기'라면 부품은 '손잡이'다. 손잡이가 헐겁거나 어디 있는지 안 보이면, 아무리 분위기가 좋아도 문을 못 연다. 그래서 부품 점검에서 '아니오'가 나오면, 사용자가 실제로 '하려던 일을 못 하는' 상황으로 바로 이어진다. B 영역은 다섯 묶음 중에서도 '체감 불편'이 가장 즉각적으로 드러나는 곳이라, 여기서 잡아낸 문제는 고쳤을 때 효과도 가장 빠르게 느껴진다.

부품 점검에서 한 가지 더 봐야 할 건 '상태가 보이는가'다. 버튼에 마우스를 올렸을 때 색이 살짝 바뀌는지, 누르는 순간 '눌렸다'는 반응이 있는지, 처리 중일 때 '잠시만 기다리세요' 같은 표시가 뜨는지를 본다. 이런 '상태 표시'가 없으면 사용자는 '이게 눌린 건가 안 눌린 건가' 헷갈려 같은 버튼을 여러 번 누르게 된다. 신청 버튼을 두 번 눌러 중복 접수가 되는 사고도 대개 여기서 난다. 부품은 '보이기만' 하면 안 되고 '반응해야' 한다. 사용자가 무언가를 했을 때 사이트가 '응, 받았어'라고 대꾸해주는 것 — 그 작은 반응이 사용자에게 '이 사이트를 믿어도 되겠다'는 안정감을 준다.

■ C. 흐름(BP·SP) 체크

C-1. 신청·예약 같은 여러 단계 흐름에서 '지금 몇 단계 중 어디인지'가 보이는가?

→ 자주 보이는 문제: 진행 표시가 없어 '끝이 안 보이는' 느낌. 중도 이탈이 많다.

C-2. 폼을 잘못 채웠을 때, '어느 칸이, 왜 틀렸고, 어떻게 고치라'고 그 칸 옆에 알려주는가?

→ 자주 보이는 문제: 화면 맨 위 빨간 한 줄("입력을 확인하세요")만 뜨고 어디가 문제인지 안 알려준다.

C-3. 검색 결과가 0건일 때, 다음에 뭘 하라고(검색어 수정, 추천 등) 안내하는가?

→ 자주 보이는 문제: "결과가 없습니다"만 뜨고 막다른 길이 된다.

C-4. 로그인·본인인증 단계가 불필요하게 길지 않은가?

→ 자주 보이는 문제: 단계가 많아 중간에 다 이탈한다.

흐름은 사용자가 '목적을 이루느냐 마느냐'를 가르는 영역이라, 여기서의 '아니오'는 곧 서비스 실패로 이어진다. 그리고 흐름의 문제는 '평소에 잘 안 보인다'는 게 특히 까다롭다. 만든 사람은 그 흐름을 수십 번 따라가 봤으니 어디에 뭐가 있는지 다 알고, 막힘없이 통과한다. 그래서 '우리 신청 흐름은 멀쩡한데'라고 자신하기 쉽다. 하지만 처음 온 사용자는 우리가 당연하게 여긴 그 모든 단계에서 멈칫한다. '이 칸은 뭘 적으라는 거지' '다음 버튼이 어디 있지' '이거 잘못 누르면 처음부터 다시 하나' — 이런 망설임이 쌓이다 어느 지점에서 '에이, 그냥 전화하자'가 된다. 그래서 C 영역만큼은 반드시 '우리 흐름을 한 번도 안 써본 사람'에게 부탁해 옆에서 지켜보는 게 가장 정확하다.

흐름 점검은 '일부러 틀려보기'가 가장 효과적이다. 필수 칸을 비워두고 제출 버튼을 눌러보고, 형식에 안 맞는 값(이를테면 전화번호 칸에 한글)을 넣어보고, 신청 중간에 뒤로 가기를 눌러본다. 이렇게 일부러 어긋나게 행동했을 때 사이트가 어떻게 대응하는지를 보면 흐름의 완성도가 그대로 드러난다. 친절한 사이트는 '무엇이 왜 틀렸고 어떻게 고치라'를 그 칸 바로 옆에서 알려주고, 뒤로 가도 적던 내용을 지켜준다. 불친절한 사이트는 '오류가 발생했습니다' 한 줄만 띄우거나, 처음부터 다시 적게 만든다. 핵심 흐름 한두 개만 이렇게 끝까지 가보면, 사용자가 실제로 어디서 좌절하는지 금방 알 수 있다.

C 영역을 점검할 때는 '우리 사이트에서 사람들이 가장 많이 하는 일' 한두 개를 골라 그것부터 보는 게 좋다. 모든 흐름을 다 따라가 볼 시간은 없으니, 방문자 대부분이 거치는 '대표 흐름'에 집중하는 거다. 민원 신청이 가장 많은 기관이라면 그 신청 흐름을, 자료 검색이 잦은 곳이라면 검색 흐름을, 예약·접수가 핵심인 곳이라면 그 과정을 처음부터 끝까지 '진짜 사용자처럼' 밟아본다. 가장 많이 쓰는 흐름 하나가 매끄러우면 사용자 대다수가 만족하고, 그 하나가 막히면 가장 많은 사람이 좌절한다. 그래서 흐름 점검은 '넓게 조금씩'보다 '핵심을 깊게'가 원칙이다.

흐름 점검에서 특히 신경 써야 할 건 '우리가 가장 자주 쓰는 흐름'이다. 사이트엔 페이지가 수십, 수백 개지만 사용자가 실제로 많이 거치는 흐름은 몇 개로 정해져 있다. 자주 들어오는 민원 신청, 자주 찾는 정보 검색, 자주 하는 예약 — 이런 핵심 흐름이 막히면 그 피해는 사용자 한두 명이 아니라 '대다수'에게 미친다. 그러니 시간이 없다면 C 영역만큼은 '가장 많이 쓰는 흐름 하나'를 골라 처음부터 끝까지 직접 따라가 보길 권한다. 그 한 번의 완주가 다른 어떤 점검보다 많은 걸 알려준다. 그리고 그 흐름이 막히는 지점을 찾았다면, 그게 바로 '가장 먼저 고쳐야 할 곳'이다.

흐름의 결함이 유독 뼈아픈 이유가 하나 더 있다. 그 결함은 사용자가 '많은 걸 투자한 뒤에' 드러난다는 점이다. 정보를 찾고, 자격을 확인하고, 여러 칸을 채우고, 첨부파일까지 올린 사용자가 마지막 제출 단계에서 정체불명의 오류를 만나면, 그동안의 노력이 한순간에 무너진다. 더 안타까운 건 이렇게 끝에서 이탈한 사용자가 '재방문'을 잘 안 한다는 점이다. 한 번 '이 사이트는 신청이 안 되는 곳'이라는 인상이 박히면, 다음에 같은 일이 필요해도 '또 그 고생을 하느니 직접 방문하자'가 된다. 온라인으로 끝날 일이 창구 방문으로 돌아오고, 결국 기관의 행정 부담으로 되돌아온다. 사용자 한 명의 신청 실패가 기관의 업무량으로 부메랑처럼 돌아오는 셈이다. 그래서 C 영역의 '아니오'는 '사용자 불편'을 넘어 '기관 비용'의 문제이기도 하다.

C 영역을 점검할 때 꼭 봐야 할 세 가지를 다시 정리하면 이렇다. 첫째, '지금 어디쯤인지 보이는가'(진행 표시). 끝이 보이는 길은 걸을 수 있지만 끝이 안 보이는 길은 포기하게 된다. 둘째, '무엇이 틀렸는지 그 자리에서 알려주는가'(인라인 오류 안내). 좋은 오류 안내는 어느 칸이 문제인지, 무엇이 잘못됐는지, 어떻게 고치면 되는지 세 가지를 담아, 문제가 난 칸 바로 옆에 떠야 한다. 셋째, '되돌아가도 입력이 날아가지 않는가'(상태 유지). 이 세 가지는 화려한 기능이 아니라 '기본 예의'에 가깝다. 사용자에게 당신이 지금 무엇을 하고 있고, 무엇이 남았고, 무엇을 잘못했는지를 정직하게 알려주는 것 — 그게 끝까지 완주하게 돕는 안전장치다.

■ D. 접근성 체크

D-1. 이미지에 대체텍스트(alt)가 있는가? (의미 있는 이미지 기준)

→ 자주 보이는 문제: alt가 비어 있거나 '이미지' '사진' 같이 무의미하게 채워져 있다.

D-2. 글자와 배경의 색 대비가 충분한가? (연한 회색 글씨가 잘 안 보이지 않는가)

→ 자주 보이는 문제: 흐린 회색 글씨로 '안 보인다'는 민원이 들어온다.

D-3. 마우스 없이 키보드만으로 주요 기능을 쓸 수 있는가?

→ 자주 보이는 문제: 특정 메뉴·기능이 마우스로만 작동해 키보드 사용자가 접근 불가.

접근성은 일부 사용자에게 '불편'이 아니라 '사용 가능/불가능'의 문제다. 그래서 우선순위를 항상 위에 둔다. (다음 달 한 달 내내 접근성을 깊게 다룰 예정이다.) 접근성 점검이 막막하게 느껴진다면, '내가 잠깐 그 사용자가 되어보는' 방법이 가장 직관적이다. 모니터 밝기를 확 낮추고 글씨가 읽히는지, 마우스를 책상 서랍에 넣어두고 키보드만으로 신청까지 가능한지, 화면을 음성으로 읽어주는 기능을 켜고 우리 사이트가 무슨 말을 하는지 들어보는 것이다. 평소엔 1초도 안 걸리던 일이 갑자기 막막해지는 그 순간, 누군가는 매일 그 막막함 속에서 우리 사이트를 쓰고 있다는 걸 체감하게 된다. 접근성은 '규칙이라서 지키는 것'이 아니라, '그 사람의 입장이 되어보면 안 지킬 수가 없는 것'이다.

D 영역은 '어떻게 점검하는지'가 잘 안 알려져 있어서, 실무 팁을 조금 더 풀어 둔다. D-1 대체텍스트는 '이미지에 마우스를 잠깐 올려두면' 풍선처럼 뜨는 설명을 확인하거나, 화면을 읽어주는 보조기기를 켜고 직접 들어보는 방법이 가장 확실하다. 핵심은 '이 이미지가 없어도 내용을 이해할 수 있는 설명인가'다. 단순 장식 이미지라면 대체텍스트를 비워두는 게 오히려 맞고, 정보가 담긴 이미지(안내도·표를 그림으로 넣은 경우)라면 그 내용을 글로 풀어줘야 한다. D-2 색 대비는 '눈으로 대충 보기'보다 대비 측정 도구에 두 색을 넣어보는 게 정확하다. 사람 눈은 익숙해지면 흐린 글씨도 '보인다'고 착각하지만, 처음 온 사람·시력이 약한 사람에게는 안 보인다. D-3 키보드 점검은 가장 간단하다. 마우스에서 손을 떼고 Tab 키만으로 메뉴를 돌아다녀 보라. 검색하고, 로그인하고, 신청 버튼까지 누를 수 있으면 통과다. 어느 지점에서 '여기서 막힌다' 싶으면, 그 기능은 마우스 없이는 못 쓰는 것이고, 그건 누군가에게 '서비스 자체를 못 받는다'는 뜻이 된다.

접근성을 '소수를 위한 배려' 정도로 가볍게 여기면 안 된다. 첫째, 공공 서비스는 '모든 국민'이 대상이다. 시력이 약한 분, 손이 불편해 마우스를 쓰기 어려운 분, 화면을 음성으로 읽어주는 보조기기에 의존하는 분 — 이들도 똑같이 민원을 넣고 정보를 찾을 권리가 있다. 민간 서비스라면 '일부 사용자가 못 써도 다른 데로 가면 된다'고 할 수 있지만, 공공 서비스는 '대체할 곳이 없다'. 우리 사이트에서 막히면 그 사람은 그 행정 서비스 자체를 못 받는 것이다. 둘째, 접근성은 법으로도 정해진 의무다. 공공기관 웹사이트는 웹 접근성 기준을 지켜야 하고, 안 지키면 법적 문제가 될 수 있다. 셋째, 접근성을 잘 지킨 사이트는 '모두에게' 더 편하다. 색 대비를 높이면 햇빛 아래 스마트폰을 보는 사람도 잘 보이고, 키보드로 다 되게 만들면 마우스가 고장 난 사람도 쓸 수 있다. 접근성은 '특정 누군가'만이 아니라 '결국 모두'를 위한 것이다. 그래서 D 영역에서 '아니오'가 나왔다면, 다른 무엇보다 먼저 손대야 한다.

■ E. 모바일·운영 체크

E-1. 스마트폰으로 봤을 때 가로 스크롤이 생기거나 레이아웃이 깨지지 않는가?

→ 자주 보이는 문제: PC에선 멀쩡한데 폰에서 글자가 잘리거나 가로로 밀린다.

E-2. 모바일에서 버튼·링크가 손가락으로 누르기에 충분히 큰가?

→ 자주 보이는 문제: 버튼이 작아 옆 버튼이 잘못 눌린다.

E-3. 색·글꼴을 '한 곳에서' 바꿀 수 있는 구조인가?

→ 자주 보이는 문제: 수십 군데에 색이 박혀 있어 바꾸기가 대공사다.

모바일 점검을 따로 빼둔 데는 이유가 있다. 요즘 공공 사이트 방문자의 절반 이상이 스마트폰으로 들어온다. 어떤 서비스는 모바일 비중이 7할을 넘기도 한다. 그런데도 사이트를 만들거나 점검할 때는 여전히 '큰 모니터' 기준으로만 보는 경우가 많다. 큰 화면에서 멀쩡하던 페이지가 작은 화면에서는 글자가 잘리고, 표가 가로로 삐져나오고, 버튼이 손가락보다 작아진다. '우리 사이트 잘 만들었다'는 자신감이 정작 가장 많은 사용자가 쓰는 환경에서 무너지는 거다. 그러니 E 영역만큼은 반드시 '실제 스마트폰을 손에 쥐고' 확인하라. 개발자 도구의 모바일 미리보기로는 손가락 터치의 불편함, 햇빛 아래 가독성 같은 '진짜 모바일 경험'이 안 잡힌다.

운영 항목(E-3)은 당장 눈에 안 보이지만 가장 멀리 가는 항목이다. 색을 '한 곳에서' 바꿀 수 있는 구조라면, 나중에 브랜드 색이 바뀌거나 접근성 기준이 강화돼도 한 번의 수정으로 전체가 따라온다. 반대로 색이 수백 군데에 흩어져 박혀 있으면, 작은 변경 하나도 '대공사'가 된다. 그래서 E-3에 '아니오'가 나왔다면, 지금 당장은 문제가 없어 보여도 '앞으로 모든 변경이 비싸진다'는 뜻이다. 이 항목은 사이트의 '체질'을 보는 질문이라고 생각하면 된다.

E-3 같은 운영 항목은 '예/아니오'를 가르는 기준이 애매하게 느껴질 수 있다. 직접 코드를 보지 않고도 가늠하는 방법이 있다. 사이트를 만든 업체나 담당 개발자에게 '버튼 색을 한 번에 다 바꾸려면 시간이 얼마나 걸리느냐'고 물어보라. '반나절이면 됩니다'라는 답이 오면 구조가 잘 잡혀 있다는 뜻이고, '여러 페이지를 일일이 봐야 해서 며칠 걸립니다'라는 답이 오면 색이 여기저기 흩어져 박혀 있다는 신호다. 일상의 작은 변경 요청에 '그건 큰 작업입니다'라는 답이 자주 돌아온다면, E-3은 '아니오'에 가깝다고 봐도 된다. 운영 구조는 평소에는 안 보이다가, 무언가 바꿔야 할 때 비로소 정체를 드러낸다.

E 영역을 마지막에 둔 또 다른 이유는, 이 두 항목(모바일·운영)이 '가장 많은 사용자'와 '가장 긴 시간'을 각각 대표하기 때문이다. 모바일은 '지금 가장 많은 사람'이 쓰는 환경이고, 운영 구조는 '앞으로 가장 오래' 영향을 주는 토대다. 둘 다 눈앞의 화면만 봐서는 점검이 안 되고, '실제 손에 폰을 쥐어보는 행동'과 '앞으로의 변경을 상상해보는 질문'이 필요하다. 그래서 A~D가 '지금 화면이 괜찮은가'를 묻는다면, E는 '이 사이트가 앞으로도 괜찮을까'를 묻는 항목이라고 정리할 수 있다. 당장 급하지 않다고 E를 건너뛰면, 그 '앞으로'의 비용을 나중에 한꺼번에 치르게 된다. 그러니 지금 당장 손대지 않더라도, '우리 사이트의 체질이 이렇구나' 하고 인식해두는 것만으로도 E 영역 점검은 충분한 값을 한다.

실무 적용·체크리스트

■ 점수 매기는 법

위 항목을 다 체크했다면, 간단히 점수를 내보자. 각 '예'를 1점으로 친다. 전체 항목은 다음과 같다.

· A 기초: 3항목

· B 부품: 4항목

· C 흐름: 4항목

· D 접근성: 3항목

· E 모바일·운영: 3항목

· 합계: 17항목

대략적인 해석:

· 14~17점: 기본기가 탄탄하다. 정밀 진단으로 세부 개선점을 찾는 단계.

· 9~13점: 군데군데 디자인 부채가 쌓였다. 우선순위를 정해 개선 시작.

· 8점 이하: 기초부터 다시 잡는 게 좋다. 특히 '아니오'가 몰린 영역부터.

다시 강조하지만 이건 '정밀 진단'이 아니라 '감 잡기'다. 17점 만점이라도 846규칙 정밀 점검에서는 놓친 게 나올 수 있고, 점수가 낮아도 핵심 몇 개만 고치면 빠르게 좋아질 수 있다. 그러니 점수 구간에 너무 일희일비하지 말자. 14점이라고 '우린 충분해'라며 멈추면 곤란하고, 7점이라고 '우린 글렀어'라며 손을 놓아도 안 된다. 14점인 사이트도 정밀 진단을 받으면 미처 몰랐던 접근성 결함이 무더기로 나올 수 있고, 7점인 사이트도 가장 아픈 항목 두세 개만 고치면 사용자 체감이 확 달라질 수 있다. 점수는 '대략 어느 수준인지'를 알려주는 신호등일 뿐, 그 자체가 목표가 아니다. 진짜 목표는 점수 너머에 있는 '사용자가 우리 사이트에서 일을 끝낼 수 있는가'이다.

점수 자체보다 더 중요하게 봐야 할 게 '아니오가 어느 영역에 몰렸는가'다. 총점이 같은 11점이어도, A(기초)에서 다 깎인 사이트와 C(흐름)에서 다 깎인 사이트는 처방이 완전히 다르다. 기초에서 깎였다면 색·글꼴 약속을 정하는 '토대 작업'이 필요하고, 흐름에서 깎였다면 신청·검색 같은 핵심 여정을 다시 설계하는 '서비스 작업'이 필요하다. 그래서 점검을 마치면 '몇 점이네'에서 끝내지 말고, '우리는 어느 층이 약한가'를 한 줄로 적어보라. '우리 사이트는 기초는 그럭저럭인데 흐름이 약하다' 같은 한 문장이, 앞으로의 모든 개선 방향을 정해준다.

또 하나, 영역별로 항목 수가 다르다는 점도 감안해서 읽어야 한다. 부품(B)과 흐름(C)은 각 4항목, 나머지는 3항목이다. 그래서 단순 합산 점수만 보면 항목이 많은 영역의 비중이 커 보인다. 정확히 보려면 '영역별로 몇 개 중 몇 개가 예인지'를 따로 적어, 영역끼리 비율로 비교하는 게 좋다. 이를테면 '접근성은 3개 중 1개만 예(33%), 기초는 3개 중 3개 예(100%)'처럼 적으면, 어느 영역이 상대적으로 더 취약한지가 또렷이 보인다. 점수는 거들 뿐, 진짜 정보는 '영역별 분포'에 있다.

점수를 낼 때 한 가지 더 권하고 싶은 건, '혼자 매기지 말기'다. 만든 사람은 자기 사이트의 흠을 잘 못 본다. 매일 보던 화면이라 어색한 부분도 익숙해져 버렸기 때문이다. 가능하면 그 사이트를 처음 보는 동료, 혹은 전문가가 아닌 가족·지인에게 '이 버튼 한번 눌러봐' '여기서 뭘 신청하려면 어떻게 해?' 하고 부탁해보라. 만든 사람은 1초 만에 찾는 걸 처음 온 사람은 한참 헤맨다. 그 '헤매는 지점'이 곧 '아니오'가 나와야 할 항목이다. 자가 체크는 '내가 매기는 점수'이기 이전에, '처음 온 사람의 눈으로 다시 보는 연습'이다. 점수가 후하게 나왔다면, 혹시 내가 너무 익숙해진 채로 본 건 아닌지 한 번쯤 의심해보는 게 좋다.

점수 자체는 '절대 평가'가 아니라 '우리 안의 기준점'으로 쓰는 게 맞다. 이 17점 척도는 옆 기관과 우열을 가리려고 만든 게 아니다. 다른 기관과 비교하려면 같은 사람이 같은 잣대로 양쪽을 봐야 하는데, 자가 체크는 그러기 어렵다. 그러니 '우리가 11점이고 옆 기관이 13점이더라' 같은 비교는 큰 의미가 없다. 대신 '우리 사이트가 지난 분기 9점에서 이번 분기 12점이 됐다'처럼 '과거의 우리'와 비교할 때 이 점수는 가장 정직하게 작동한다. 남과 겨루는 점수가 아니라, 어제의 우리보다 나아졌는지를 재는 자다. 그렇게 쓰면 점수가 낮게 나와도 주눅 들 일이 없다. 출발점이 어디든, 다음 분기에 한 점이라도 올리면 그게 곧 '우리 사이트가 좋아지고 있다'는 증거이기 때문이다.

■ 개선 우선순위 정하기

체크가 끝나면 '아니오'가 나온 항목들을 이렇게 줄 세운다.

1순위: 접근성(D) 항목 — 사용 가능/불가능을 가르므로 최우선

2순위: 자주 쓰는 핵심 흐름(C) — 신청·검색이 막히면 서비스가 실패

3순위: 눈에 가장 잘 띄는 부품(B) — 메인의 주 버튼 등

4순위: 기초(A)·운영(E) — 중장기로 토큰화·구조 개선

이렇게 '영향 큰 것 + 자주 마주치는 것' 순으로 잡으면, 적은 노력으로 큰 개선 효과를 낼 수 있다.

우선순위를 정할 때 흔히 빠지는 함정이 '쉬운 것부터 하기'다. 색 몇 개 정리하는 건 금방 되고 눈에도 보이니 손이 먼저 간다. 하지만 사용자 입장에서 가장 아픈 건 대개 흐름이나 접근성 쪽이다. 색이 조금 어긋나도 신청은 할 수 있지만, 신청 흐름이 막히면 일 자체를 못 끝낸다. 그러니 '하기 쉬운 순서'가 아니라 '사용자가 아픈 순서'로 줄을 세워야 한다. 물론 현실에서는 '아주 아프지만 고치기 어려운 것'과 '덜 아프지만 금방 고칠 수 있는 것' 사이에서 균형을 잡아야 한다. 그럴 땐 '가장 아픈 것 하나'와 '금방 고칠 수 있는 것 몇 개'를 함께 잡는 게 현명하다. 큰 것 하나로 임팩트를 내고, 작은 것 여럿으로 '개선되고 있다'는 분위기를 만드는 거다.

우선순위를 줄 세울 때 '영향 범위'도 함께 보면 좋다. 같은 '아니오'라도, 모든 페이지에 공통으로 나타나는 문제와 특정 한 페이지에만 있는 문제는 무게가 다르다. 예를 들어 '주 버튼 색이 흐려서 안 보인다'는 문제가 사이트 전체에 깔려 있다면, 그 하나를 고치는 순간 수백 페이지가 한꺼번에 좋아진다. 반대로 잘 안 쓰는 안내 페이지 하나의 표가 깨진 거라면, 급하지 않다. 그래서 점검할 때 '이 문제가 우리 사이트에서 몇 군데에 걸쳐 있나'를 함께 메모해두면, 우선순위가 훨씬 또렷해진다. 적은 손으로 넓게 좋아지는 항목 — 그게 가장 먼저 손대야 할 '남는 장사'다.

우선순위를 정했다면, 한 번에 다 하려 들지 말고 '이번 분기엔 이 세 개' 식으로 끊어서 가는 걸 권한다. 개선은 마라톤이다. 한꺼번에 전부 바꾸려다 지쳐 멈추는 것보다, 작게라도 꾸준히 나아가는 게 멀리 간다. 그리고 작은 개선이라도 '끝냈다'는 성취가 쌓이면, 다음 개선을 밀어붙일 동력이 생긴다. 거대한 전면 개편보다, 분기마다 손에 잡히는 개선 몇 개를 끝내가는 팀이 결국 더 좋은 사이트를 만든다.

우선순위를 정한 뒤에는, 그 목록을 '혼자 들고 있지 말고' 관련된 사람들과 공유하는 게 좋다. 콘텐츠 담당자, 외주 업체, 윗선까지 같은 목록을 보고 있어야 개선이 한 방향으로 움직인다. '1순위는 접근성 두 항목, 2순위는 신청 흐름 하나'처럼 정리된 목록은 그 자체로 회의 안건이 되고, 외주 발주서의 요구사항이 되고, 다음 예산을 설명하는 근거가 된다. 자가 체크의 진짜 결실은 '점수'가 아니라 이 '우선순위 목록'이다. 점수는 현재 상태의 요약일 뿐이지만, 우선순위 목록은 '앞으로 무엇을 어떤 순서로 할지'를 담은 실행 계획이기 때문이다. 그러니 오늘 체크를 마쳤다면, 마지막에 꼭 이 목록 한 장을 정리해 남겨두자.

■ 체크 결과를 '기록'으로 남기기

마지막 팁. 자가 체크 결과를 날짜와 함께 기록해두자. 다음에 개편하거나 정기 점검할 때 '전에 비해 나아졌는지' 비교할 기준점이 된다. 개선은 '전후 비교'가 될 때 비로소 설득력이 생긴다. 윗선 보고나 예산 확보에도 '이만큼 좋아졌다'는 기록이 큰 힘이 된다.

기록은 거창할 필요 없다. '2026년 O월 O일, 총 17점 중 11점. 접근성 1/3, 흐름 2/4가 약함' 정도의 메모면 충분하다. 중요한 건 '남겨두는 것' 자체다. 사람의 기억은 생각보다 빨리 흐려진다. 반년 뒤 '작년에 우리 사이트가 어땠더라'를 떠올리려 하면 '그냥 좀 별로였던 것 같은데' 이상은 안 나온다. 하지만 그때 적어둔 한 줄이 있으면, '작년엔 접근성이 1/3이었는데 올해는 3/3이 됐네'라는 명확한 비교가 가능하다. 이 비교가 곧 '우리가 일을 제대로 하고 있다'는 증거가 된다.

특히 담당자가 바뀌는 공공기관에서 이 기록은 더욱 값지다. 전임자가 어디까지 봤고 무엇이 문제였는지가 기록으로 남아 있으면, 후임자는 처음부터 다시 헤매지 않고 그 위에서 이어갈 수 있다. 점검 기록은 개인의 메모가 아니라 '조직의 기억'이 되는 셈이다. 사람은 바뀌어도 사이트는 남고, 기록이 있으면 그 사이트를 돌보는 일도 끊기지 않고 이어진다.

기록을 남길 때는 '점수 한 줄'보다 '아니오가 나온 항목과 그 이유'를 함께 적는 게 훨씬 유용하다. '11점'이라는 숫자만 남기면 반년 뒤에 '그래서 뭐가 문제였더라'를 다시 떠올려야 한다. 하지만 'C-2 아니오 — 신청 폼 오류 안내가 맨 위 한 줄뿐, D-3 아니오 — 메뉴가 키보드로 안 열림'처럼 적어두면, 그 자체가 다음에 손볼 작업 목록이 된다. 그리고 다음 점검 때 그 항목들이 '예'로 바뀌었는지만 확인하면, 우리가 실제로 무엇을 고쳤는지가 또렷이 보인다. 기록의 형식은 자유롭다. 엑셀 한 장이든, 공유 문서 한 페이지든, 메신저 채널에 분기마다 남기는 메모든 상관없다. 중요한 건 '같은 양식으로, 같은 항목을, 꾸준히' 남기는 것이다. 그래야 시점 간 비교가 가능하고, 비교가 가능해야 '나아지고 있다'는 사실을 증명할 수 있다.

자가 체크로 감을 잡았다면, 다음은 '정밀 진단' 차례다. 17개 항목을 눈으로 보는 것과, 846규칙을 기준으로 페이지를 자동 분석하는 것은 깊이가 다르다. 오늘 다룬 17개 항목은 846규칙 가운데 '가장 자주 걸리고 영향이 큰' 것들을 추린 '맛보기'에 가깝다. 17개로도 큰 윤곽은 잡히지만, 846규칙은 그 윤곽 안쪽의 결까지 들여다본다. 같은 '버튼' 하나를 두고도 자가 체크는 '잘 보이나/구분되나' 정도를 묻지만, 규칙 엔진은 크기·색 대비·상태별 표시·키보드 접근성·라벨 적절성까지 항목을 나눠 따진다. 5분짜리 자가 체크가 '체온 재기'라면, 846규칙 분석은 '피검사'인 셈이다. 둘 다 필요하지만, 깊이가 다르다.

ViewCheck은 오늘 자가 체크한 항목들을 포함해, 사람이 일일이 확인하기 어려운 부분까지 자동으로 잡아낸다. 색 대비 값을 실제로 측정하고, 대체텍스트 누락을 찾아내고, 버튼·폼 구조를 점검하고, 네 영역(DS·CP·BP·SP)별 점수를 매긴다. 거기에 행안부 품질관리 7대 영역과 KWCAG 접근성 33항목까지 한 번에 본다.

무엇보다 좋은 건, 결과를 '기록'으로 남길 수 있다는 점이다. 앞에서 말한 '전후 비교'가 자동으로 된다. 개선 전 점수와 개선 후 점수를 나란히 두면, '무엇이 얼마나 좋아졌는지'가 한눈에 보인다.

자가 체크와 자동 진단의 가장 큰 차이는 '세는 능력'에 있다. 사람은 한 페이지에서 색이 몇 종 쓰였는지 눈으로 세지 못한다. 비슷한 파랑이 다섯 종 섞여 있어도 '대충 파랗네'로 뭉뚱그려 본다. 글자 대비가 4.3:1인지 4.6:1인지도 눈으로는 판별이 안 된다. 자동 진단은 이런 '사람이 셀 수 없는 것'을 정확히 센다. 색이 몇 종인지, 디자인 토큰을 몇 % 채택했는지, 대체텍스트가 빠진 이미지가 몇 개인지, 대비 기준에 미달하는 텍스트가 몇 군데인지 — 막연한 느낌이 전부 숫자로 바뀐다. 숫자가 되면 목표를 세울 수 있고, 목표가 있으면 개선이 시작된다.

또 하나의 결정적 차이는 '규모'다. 자가 체크로는 기껏해야 페이지 몇 개를 직접 둘러볼 수 있다. 그런데 공공 사이트는 페이지가 수십, 수백 개다. 손으로는 다 못 본다. 그래서 사람은 보통 '대표 페이지 몇 개'만 보고 사이트 전체를 판단하는데, 정작 문제는 사용자가 많이 쓰는 안쪽 페이지에 숨어 있는 경우가 많다. 자동 진단은 여러 페이지를 한꺼번에 돌려, 사이트 전체의 평균과 페이지별 편차를 같이 보여준다. '메인은 90점인데 신청 페이지는 50점' 같은 격차가 드러나면, 어디부터 손봐야 할지가 분명해진다. 사람이 표본으로 놓치기 쉬운 '방치된 안쪽 페이지'를 자동 진단은 빠짐없이 짚어준다.

그리고 자동 진단의 결과는 '느낌'이 아니라 '근거'다. 윗선에 개선을 건의하거나 외주 발주를 정당화할 때, '제가 보기엔 좀 어수선해서요'보다 '기초 영역 통과율 60%, 미준수 규칙 180건'이라는 숫자가 훨씬 설득력 있다. 게다가 그 숫자는 KRDS라는 공식 기준에 근거하니 누가 봐도 객관적이다. 막연한 문제의식을 '움직일 수 있는 근거'로 바꿔주는 것 — 이게 자동 진단이 실무에서 발휘하는 가장 큰 힘이다. 오늘 자가 체크로 잡은 감을, 자동 진단의 숫자로 확정하면, 개선 논의는 '감정 싸움'이 아니라 '데이터 기반 의사결정'이 된다. 공공기관에서 무언가를 바꾸려면 '왜 바꿔야 하는지'를 설득해야 하는데, 그 설득의 가장 강력한 무기가 '객관적 근거'다. '제 느낌엔 우리 사이트가 불편한 것 같습니다'와 'KRDS 846규칙 기준 준수율이 OO%이고, 접근성 영역에서 미준수가 OO건입니다'는 회의실에서의 무게가 전혀 다르다. 후자는 누구도 '그건 네 주관이잖아'라고 반박할 수 없다. 자동 진단은 막연했던 문제의식에 '공식 기준이라는 권위'와 '숫자라는 객관성'을 입혀, 미뤄지던 개선을 실제로 움직이게 만든다.

물론 자동 진단이 모든 걸 대신하진 않는다. 시각적 완성도, 콘텐츠의 적절함, 사용자 정서 같은 건 결국 사람이 판단해야 한다. 그래서 가장 좋은 방식은 '분업'이다. 자동 진단은 사람이 일일이 세기 힘든 것을 대신 세어주고, 사람은 그 결과 위에서 '무엇을 먼저 고칠지', '이 개선이 우리 사용자에게 정말 도움이 되는지'를 판단한다. 오늘 한 자가 체크는 바로 그 '사람의 판단력'을 기르는 연습이기도 하다. 항목 하나하나의 의미를 몸으로 이해해두면, 나중에 자동 진단 리포트를 봤을 때 숫자 너머의 '진짜 문제'가 보인다.

자동 진단을 한 번 받아두면 얻는 또 하나의 이점은 '반복 점검의 비용이 0에 수렴한다'는 것이다. 자가 체크는 할 때마다 사람의 5분, 10분을 쓴다. 페이지가 많은 사이트라면 그 시간이 만만치 않다. 반면 자동 진단은 한 번 URL을 넣어두면, 다음 점검 때도 같은 기준으로 같은 페이지들을 일관되게 분석한다. 사람이 그날 컨디션이나 기분에 따라 후하게/박하게 채점하는 '들쭉날쭉함'도 없다. 같은 기준으로 같은 방식으로 매번 측정하니, 시점 간 비교가 정확하다. '작년 이맘때보다 좋아졌나'를 따질 때, 사람의 기억보다 동일 기준의 자동 점수가 훨씬 믿을 만하다. 자가 체크가 '사람의 감각을 기르는 일'이라면, 자동 진단은 '그 감각을 흔들림 없는 숫자로 고정하는 일'이다.

오늘 자가 체크에서 '아니오'가 많이 나왔다면, 그 막연한 불안을 구체적인 점수와 항목으로 바꿔보자. 아래 상단 점수 카드 한 화면에서 시작할 수 있다. (캡쳐는 기관 식별 정보를 가린 것이다.)

마무리

이번 주 정리. 월요일엔 KRDS의 개념(DS·CP·BP·SP, 846규칙)을, 수요일엔 가이드 없는 사이트의 붕괴 패턴을, 그리고 오늘은 5분 자가 체크리스트를 다뤘다. 핵심은 하나다. '막연한 느낌'을 '구체적인 점검'으로 바꾸는 것. 그게 개선의 시작이다.

오늘 17개 항목 체크 결과는 꼭 날짜와 함께 적어두길 바란다. 그게 우리 사이트 개선 여정의 첫 번째 기준점이 된다. 한 가지만 더 당부하면, 이 글을 '읽기만 하고' 닫지 말고 지금 바로 우리 사이트를 한 탭에 띄워 '예/아니오' 몇 개라도 적어보길 바란다. 읽고 고개를 끄덕이는 것과, 직접 우리 화면을 열어 항목을 짚어보는 것은 남는 게 완전히 다르다. 5분이면 된다. 그 5분이 '막연한 불안'을 '구체적인 할 일 목록'으로 바꿔준다.

오늘 글을 읽으며 '우리도 저런데' 싶은 항목이 한두 개 떠올랐다면, 그것만으로도 절반은 온 거다. 문제를 '이름 붙여 인식한' 순간부터 개선이 시작되기 때문이다. 이제 막연한 '좀 불편한 것 같다'가 '버튼 위계가 없구나', '오류 안내가 부실하구나' 같은 구체적인 진단으로 바뀌었다. 구체적인 진단은 구체적인 행동으로 이어진다. 그리고 그 행동은 거창할 필요가 없다. 오늘 찾은 '아니오' 중 가장 아픈 것 하나만 골라 손대도, 우리 사이트는 어제보다 나은 사이트가 된다.

한 가지 더 기억해 둘 것. 점수가 낮게 나왔다고 자책할 필요는 전혀 없다. 대부분의 공공 사이트가 비슷한 과정을 거친다. 가이드 없이 오래 운영하다 보면 부채가 쌓이는 게 자연스럽다. 중요한 건 '지금 알아차렸다'는 것이고, 알아차린 순간부터는 얼마든지 좋아질 수 있다는 점이다. 오늘 체크는 '우리 사이트가 나쁘다'를 확인하는 자리가 아니라, '우리 사이트를 더 좋게 만들 출발점'을 찍는 자리다.

생각해보면, 좋은 공공 사이트와 그렇지 않은 사이트의 차이는 '처음부터 완벽했는가'가 아니라 '꾸준히 돌봤는가'에서 갈린다. 어떤 사이트든 처음엔 어딘가 부족하다. 다만 그 부족함을 '알아차리고 조금씩 메워온' 사이트는 시간이 갈수록 좋아지고, '방치한' 사이트는 부채가 쌓여 점점 나빠진다. 오늘 자가 체크는 그 '돌봄'의 가장 가벼운 첫 단계다. 거창한 개편 예산도, 외부 전문가도 필요 없이, 우리 손으로 '지금 우리 사이트가 어떤 상태인지'를 들여다보는 것 — 모든 좋은 사이트가 그렇게 시작했다. 오늘 17개 항목을 한 바퀴 돈 것만으로도, 당신은 이미 '돌보는 사람'의 자리에 선 것이다.

그리고 자가 체크보다 한 단계 깊은 진단이 필요할 때, ViewCheck(krds.viewcheck.co.kr)에서 URL만 넣으면 KRDS 846규칙 기준 무료 진단을 받을 수 있다. 자가 체크로 잡은 감과, 자동 진단의 정밀함을 함께 쓰면 개선의 방향이 또렷해질 거다. 오늘 손으로 체크한 17개 항목이 '우리 사이트는 어디가 약한가'를 알려줬다면, 자동 진단은 '얼마나, 정확히 어디가 약한가'를 숫자로 확정해 준다. 추측을 숫자로 바꾸는 데는 몇 분이면 충분하다. 오늘 잡은 감 위에 그 숫자를 얹으면, 우리 사이트 개선의 첫 한 걸음이 비로소 단단해진다.

끝으로, 오늘 체크리스트는 '출력해서 책상에 붙여두는 것'도 권한다. 새 페이지를 만들거나 외주 결과물을 받을 때, 이 17개 항목을 옆에 두고 하나씩 짚어보면 '완성한 다음에 문제를 발견하는' 일을 크게 줄일 수 있다. 만들기 전과 만든 후가 아니라 '만드는 도중에' 기준을 적용하는 것 — 그게 부채를 애초에 쌓지 않는 가장 싼 방법이다. 점검은 '다 만든 뒤 잘못을 찾는 일'이 아니라, '만드는 내내 옆에 두고 보는 기준'일 때 가장 큰 힘을 낸다. 오늘의 17개 항목이 우리 팀의 그런 '상시 기준'이 되기를 바란다.

다음 주에는 '왜 공공 사이트마다 버튼·색·메뉴가 다 다를까'를 주제로, 제각각인 공공웹의 구조적 이유와 표준화의 효과를 더 깊이 다룬다.