URL만 넣으면 끝 — ViewCheck 무료 진단 따라하기

공감·문제제기

이번 주 월요일엔 KRDS가 대체 뭔지, 수요일엔 디자인시스템이라는 게 왜 '있어도 그만 없어도 그만'인 장식이 아니라 사이트의 뼈대인지를 이야기했다. 오늘은 그 모든 이야기를 한 줄로 압축한 가장 실용적인 글이다. '그래서, 우리 사이트는 지금 몇 점이냐'를 직접 확인하는 방법이다.

솔직히 고백하자면, 나도 처음 이 일을 시작했을 때 '우리 사이트 KRDS 점검 좀 해달라'는 요청을 받고 제일 먼저 든 생각은 '대체 어디서부터 손을 대야 하나'였다. 846개 규칙이라는 숫자를 듣는 순간 이미 기가 질린다. 규칙 목록을 열어보면 색상 토큰이 어떻고, ARIA 속성이 어떻고, 포커스 순서가 어떻고... 전문 용어가 끝없이 이어진다. 담당자 입장에서 이걸 한 줄씩 읽으며 '우리 사이트가 이걸 지키나 안 지키나'를 따져본다는 건, 솔직히 불가능에 가깝다. 본업이 따로 있는 사람에게 이건 너무 큰 숙제다.

그런데 여기서 많은 분들이 빠지는 함정이 있다. '어차피 전부 못 볼 거니까, 아예 안 본다'는 거다. 완벽하게 못 할 바엔 시작도 안 하겠다는 마음. 충분히 이해한다. 하지만 그건 '건강검진을 한 번에 다 못 받을 거니까 아예 안 받겠다'는 말과 똑같다. 우리에게 필요한 건 846개를 전부 손으로 따지는 게 아니라, '버튼 하나로 전부 대신 따져주는 도구'를 제대로 쓰는 법을 익히는 거다. 그게 오늘 글의 전부다. URL 하나만 넣으면, 나머지는 도구가 알아서 한다.

오늘 글은 '개념 설명'이 아니라 '따라 하기'다. 그래서 가능한 한 손에 잡히게 쓰려고 한다. 진단을 시작하기 전 무엇을 준비해야 하는지, URL은 어떻게 넣는지, 결과 화면의 그 복잡해 보이는 점수 카드를 어떻게 읽어야 하는지, 그리고 '낮은 점수'를 받았을 때 멘붕에 빠지지 않고 무엇부터 손대야 하는지까지 — 담당자가 이 글을 띄워놓고 한 단계씩 따라 하면 30분 안에 '우리 사이트 첫 진단 결과'를 손에 쥘 수 있게 만드는 게 목표다.

미리 한 가지만 못 박아두자. 이 글에서 권하는 자동 진단은 '사람을 대체하는 마법'이 아니다. 도구는 '무엇이 문제인지'를 빠르고 정확하게 짚어주지만, '그래서 무엇부터, 어떻게 고칠지'를 결정하는 건 결국 사람이다. 그러니 오늘 우리가 배울 건 두 가지다. 하나는 '도구를 정확히 돌리는 법', 또 하나는 '도구가 뱉어낸 결과를 사람의 언어로 읽어내는 법'. 이 둘이 합쳐져야 진단이 비로소 '쓸모 있는 진단'이 된다.

왜 하필 '지금' 이런 진단이 필요한가도 잠깐 짚자. 공공 사이트는 더 이상 '있으면 좋은 것'이 아니라 '없으면 일이 안 되는' 핵심 창구가 됐다. 민원을 넣고, 자료를 찾고, 신청을 하고, 예약을 하는 대부분의 일이 온라인으로 옮겨왔다. 그만큼 사이트가 불편하면 그 피해는 고스란히 국민에게 돌아간다. 디지털에 익숙한 사람은 어떻게든 길을 찾아내지만, 고령층이나 장애가 있는 분, 디지털이 낯선 분들은 사이트 하나가 막히면 '그 서비스 자체를 못 받는' 상황에 놓인다. 그래서 공공 사이트의 품질은 단순한 '편의'의 문제가 아니라 '공평한 권리 보장'의 문제다. KRDS라는 기준이 만들어지고, 행정안전부가 품질관리 지침을 고시한 배경에는 바로 이런 절박함이 있다. 우리가 사이트를 점검한다는 건, 결국 '누구도 우리 서비스에서 소외되지 않게 한다'는 약속을 지키는 일이다.

준비물은 거짓말처럼 단출하다. 우리 기관 사이트의 주소(URL) 하나, 인터넷에 연결된 컴퓨터 한 대, 그리고 결과를 적어둘 메모장. 끝이다. 설치할 프로그램도, 결재받아야 할 비용도, 외주에 맡길 발주서도 없다. 지금 이 글을 읽다가 '어 한번 해볼까' 싶으면 새 탭을 열어 바로 시작할 수 있는, 그 정도로 가벼운 일이다.

한 가지만 먼저 마음에 새겨두자. 이 글을 읽는 분들 중에는 '나는 디자이너도 아니고 개발자도 아닌데' 하며 지레 겁먹는 분이 있을 거다. 하지만 자동 진단의 가장 큰 미덕이 바로 이 지점에 있다. 전문 지식이 없어도, 코드를 한 줄도 못 읽어도, URL을 넣고 결과 화면을 '읽기만' 하면 된다는 것. 어려운 판정은 전부 도구가 대신해준다. 우리가 할 일은 그 결과를 보고 '아 여기가 약하구나, 그럼 여기부터 챙겨야겠다' 하고 방향을 잡는 것뿐이다. 그 정도는 누구나 할 수 있다. 오히려 디자인 전문가가 아니기에, '사용자 입장에서 불편한가 아닌가'를 더 솔직하게 볼 수 있는 강점도 있다. 매일 그 사이트를 들여다보는 사람보다, 가끔 들어오는 일반 사용자의 눈이 더 정확할 때가 많다.

내가 현장에서 만난 담당자 한 분은 이런 말을 했다. "진단 도구가 있는 줄 몰랐을 땐, 우리 사이트가 좋은지 나쁜지조차 막연했어요. 윗선에서 '우리 사이트 어때?' 물어도 '글쎄요, 그럭저럭...' 하고 얼버무릴 수밖에 없었죠." 그분이 처음 진단을 돌려보고 한 말이 인상 깊었다. "이제는 '우리 사이트 부품 점수가 50점대인데, 신청 페이지가 특히 약합니다'라고 말할 수 있게 됐어요. 똑같은 사이트인데, 말할 수 있는 게 생기니까 일이 굴러가더라고요." 자동 진단이 주는 가장 큰 선물은 어쩌면 점수 자체가 아니라, 우리 사이트에 대해 '구체적으로 말할 수 있게 되는 능력'인지도 모른다.

자, 그럼 시작하자.

본론

■ 1. 왜 '손으로'가 아니라 '도구로' 진단해야 하나

지난주 글에서 '5분 자가 체크리스트'를 소개했다. 눈으로 보고 '예/아니오'를 적어가는 그 점검은 분명 가치가 있다. 그런데 오늘은 한 발 더 나아가, 그 눈대중을 '기계의 정밀함'으로 보완하자는 이야기다. 왜 손으로 하는 점검만으로는 부족한지, 세 가지 이유를 짚어본다.

첫째, 사람 눈으로는 '안 보이는' 것들이 너무 많다. 색 대비가 정확히 4.5대 1을 넘는지, 버튼 안에 화면 낭독기가 읽을 수 있는 이름표가 숨어 있는지, 입력칸이 라벨과 코드로 제대로 연결되어 있는지 — 이런 건 화면만 봐서는 절대 알 수 없다. 멀쩡해 보이는 회색 글씨가 사실은 기준 미달일 수도 있고, 예뻐 보이는 버튼이 키보드 사용자에겐 존재하지 않는 버튼일 수도 있다. 코드 속에 숨은 문제는 코드를 읽는 도구만이 잡아낸다. 사람은 '보이는 것'을 보지만, 도구는 '구조'를 본다.

둘째, 사람은 일관성을 유지하지 못한다. 같은 사람이 같은 항목을 봐도, 아침엔 '통과'라고 했다가 오후엔 '미달'이라고 한다. 컨디션, 모니터 밝기, 그날의 기분에 따라 판정이 흔들린다. 더구나 페이지가 100개, 1,000개로 늘어나면 사람이 모든 페이지를 같은 잣대로 보는 건 물리적으로 불가능하다. 반면 도구는 첫 페이지든 천 번째 페이지든 똑같은 기준으로 판정한다. 이 '흔들리지 않음'이야말로 자동 진단의 가장 큰 가치다. 점검 결과에 '사람의 기분'이 섞이지 않는다는 것.

셋째, 사람은 느리다. 한 페이지를 꼼꼼히 보는 데도 몇 분이 걸리는데, 공공 사이트는 보통 페이지가 수백 개다. 한 사람이 사이트 전체를 손으로 점검하려면 며칠, 길게는 몇 주가 걸린다. 그사이 콘텐츠는 또 바뀐다. 점검이 끝날 때쯤이면 처음 본 페이지는 이미 옛날 화면이 되어 있다. 도구는 이 일을 분 단위로 끝낸다. URL을 넣고 커피 한 잔 내리는 사이에, 사이트를 돌며 규칙을 비교하고 점수를 매긴다. 이 '속도'는 단순히 시간을 아껴주는 것 이상의 의미가 있다. 점검이 빨라지면 '자주' 할 수 있고, 자주 하면 변화를 '일찍' 알아챈다. 며칠 걸리는 점검은 1년에 한 번 마음먹고 하지만, 몇 분짜리 점검은 콘텐츠를 바꿀 때마다 부담 없이 돌려볼 수 있다. 결국 속도가 '점검의 빈도'를 바꾸고, 빈도가 '사이트의 건강'을 바꾼다.

그리고 사람의 점검에는 '피로'라는 변수도 있다. 첫 페이지는 눈에 불을 켜고 보지만, 50번째 페이지쯤 되면 집중력이 떨어져 대충 넘긴다. 사람이라 어쩔 수 없다. 그런데 문제는 종종 그 '대충 넘긴' 페이지에 숨어 있다. 도구는 첫 페이지든 오백 번째 페이지든 똑같은 집중력으로 본다. 지치지 않는다는 건, 곧 '마지막 페이지까지 똑같이 꼼꼼하다'는 뜻이다. 대규모 사이트일수록 이 차이는 결정적이다. 사람이 놓치는 '뒷부분'을 도구는 빠짐없이 챙긴다.

넷째, 사람은 '아는 만큼만' 본다. 846개 규칙을 통째로 외우고 있는 담당자는 세상에 없다. 그래서 손으로 점검하면 '내가 아는 항목'만 보게 되고, 모르는 항목은 통째로 빠진다. 접근성에 밝은 담당자는 색 대비를 잘 보지만 폼 구조는 놓치고, 디자인에 밝은 담당자는 색·글꼴은 잘 보지만 키보드 접근성은 놓친다. 사람의 점검은 그 사람의 전문 분야를 닮는다. 반면 도구는 846개 규칙 전부를 빠짐없이 들이댄다. 내가 아는 것이든 모르는 것이든, 신경 쓰는 것이든 무심한 것이든 똑같이 점검한다. 이 '빠짐없음'이 자동 진단의 또 다른 강점이다. 우리가 몰라서 못 챙기던 영역까지 한 번에 비춰준다.

오해는 말자. 이건 '사람이 필요 없다'는 말이 아니다. 정반대다. 도구가 '반복적이고 기계적인 비교 작업'을 떠맡아주니, 사람은 비로소 '판단과 결정'이라는 사람만이 할 수 있는 일에 집중할 수 있게 된다. 무엇을 먼저 고칠지, 어떤 문제가 우리 기관에 더 치명적인지, 한정된 예산을 어디에 쓸지 — 이런 건 도구가 못 한다. 도구는 재료를 정리해 식탁에 올려줄 뿐, 무엇을 요리할지 정하는 건 사람이다. 그러니 자동 진단을 도입한다는 건 '사람을 빼는 것'이 아니라 '사람을 더 중요한 일로 옮기는 것'이다.

여기서 잠깐, '도구가 어떻게 846개를 다 본다는 거지?' 하는 의문이 들 수 있다. 짧게 설명하면 이렇다. 도구는 페이지를 실제 브라우저로 불러와, 화면에 그려진 모든 요소를 코드 수준에서 끄집어낸다. 버튼이 몇 개인지, 입력칸에 라벨이 붙었는지, 색이 정확히 무슨 값인지, 글꼴 크기가 얼마인지 같은 '눈에 안 보이는 정보'까지 전부 읽는다. 그렇게 모은 정보를 KRDS 846규칙 하나하나와 '이 규칙은 통과인가 위반인가 아니면 해당 없음인가'로 대조한다. 사람이 며칠 걸려 손으로 할 일을, 도구는 정해진 논리에 따라 순식간에 처리한다. 게다가 코드를 못 읽는 시각적 영역(이미지로 된 버튼, 화면 레이아웃 등)은 별도의 시각 분석으로 보완한다. 요컨대 '코드로 볼 수 있는 건 코드로, 화면으로만 보이는 건 화면으로' 양쪽에서 본다. 그래서 사람보다 넓고 깊게 볼 수 있는 것이다.

여기에 하나 더 보태자면, 도구로 진단을 하면 '기록이 남는다'는 장점도 크다. 손으로 본 점검은 머릿속에 남았다 며칠이면 흐려지지만, 도구가 남긴 진단 결과는 날짜와 점수가 박힌 문서로 남는다. 석 달 뒤 다시 진단을 돌려 '지난번엔 몇 점, 이번엔 몇 점' 하고 나란히 놓고 보면, 우리 사이트가 좋아지고 있는지 나빠지고 있는지가 한눈에 보인다. 개선이라는 건 결국 '추세'의 문제다. 한 번의 점수보다, 그 점수가 움직이는 방향이 훨씬 중요하다. 자동 진단은 그 방향을 측정 가능한 숫자로 남겨준다.

그리고 도구는 '공정하다'는 미덕도 있다. 사람이 점검하면 아무래도 '내가 만든 페이지'엔 후해지고, '남이 만든 페이지'엔 박해지기 쉽다. 또 '우리 부서가 만든 신청 양식'의 문제는 어쩐지 작아 보이고, '다른 부서 페이지'의 문제는 유난히 커 보인다. 사람인 이상 어쩔 수 없는 편향이다. 그런데 도구는 그런 정서가 없다. 우리 부서가 만들었든 외주가 만들었든, 메인이든 구석 페이지든 똑같은 잣대로 본다. 이 '감정 없는 공정함'이 오히려 조직 안의 갈등을 줄여준다. '저 사람이 우리 페이지만 트집 잡는다'는 식의 다툼 없이, '도구가 똑같은 기준으로 본 결과'를 놓고 담담하게 개선을 논의할 수 있다. 객관적인 제3의 잣대가 있다는 건, 생각보다 조직 운영에 큰 도움이 된다.

물론 도구라고 만능은 아니다. 자동 진단이 못 잡는 영역도 분명히 있다. 문구가 사용자에게 정말 와닿는지, 메뉴 이름이 직관적인지, 전체 흐름이 '기분 좋게' 매끄러운지 같은 '감성과 맥락의 영역'은 여전히 사람의 몫이다. 그래서 자동 진단을 맹신해서도 안 된다. 점수가 만점이라고 '완벽한 사이트'인 건 아니다. 도구는 '규칙을 지켰는가'를 판정할 뿐, '사용자가 행복한가'까지 보진 못한다. 그러니 자동 진단은 '기본기를 빠짐없이 챙기는 도구'로 쓰되, 그 위에 사람의 감각을 얹는다는 마음으로 접근하는 게 맞다. 기본기를 도구가 받쳐주니, 사람은 더 높은 차원의 '사용자 경험'에 집중할 수 있게 되는 셈이다.

■ 2. 진단 전에 '이것'만 준비하면 됩니다

자동 진단의 매력은 준비가 거의 필요 없다는 점이지만, 그래도 미리 챙겨두면 결과를 훨씬 잘 쓸 수 있는 것들이 몇 가지 있다. 사소해 보여도 이걸 챙기느냐 안 챙기느냐에 따라 '진단을 한 번 하고 끝'과 '진단을 개선의 출발점으로 삼기'가 갈린다.

먼저 '진단할 URL'을 정해야 한다. 당연한 말 같지만 여기서 첫 단추를 잘못 끼우는 경우가 많다. 무심코 메인 페이지 주소 하나만 넣고 '우리 사이트 점검 끝'이라고 생각하는 거다. 하지만 메인 페이지는 보통 사이트에서 가장 공들여 만든, 가장 깔끔한 페이지다. 정작 문제는 사용자가 실제로 일을 처리하는 신청 페이지, 검색 결과 페이지, 상세 안내 페이지 같은 '속 페이지'에 숨어 있다. 그러니 진단할 때는 메인만 보지 말고, '사용자가 가장 많이 거치는 핵심 경로'를 함께 넣는 게 좋다. 다행히 제대로 된 진단 도구는 URL 하나만 넣어도 사이트를 따라 들어가며 여러 페이지를 자동으로 훑는다. 그래도 '우리 기관에서 가장 중요한 흐름이 뭔지'는 미리 머릿속에 정리해두자. 결과를 볼 때 그 흐름의 페이지부터 챙겨봐야 하니까.

메인 페이지만 보고 안심하는 걸 나는 '응접실 함정'이라고 부른다. 손님이 오면 우리는 응접실만 깨끗이 치운다. 정작 매일 생활하는 방이나 부엌은 어수선해도, 손님 눈에 띄는 응접실은 늘 정돈돼 있다. 사이트도 똑같다. 메인은 '응접실'이라 가장 공들여 다듬지만, 사용자가 실제로 일을 보는 '부엌' 같은 속 페이지는 손이 덜 간다. 그래서 메인만 보면 '우리 집 깨끗하네' 하고 착각하기 쉽다. 진짜 우리 사이트의 살림살이를 보려면, 응접실이 아니라 부엌을 들여다봐야 한다. 자동 진단이 여러 페이지를 자동으로 훑어주는 게 고마운 이유가 바로 이거다. 우리가 무심코 '응접실만 보여주려' 해도, 도구는 부엌까지 따라 들어가 본다.

다음으로, '무엇을 알고 싶은지' 목적을 한 줄로 정해두면 좋다. 그냥 '점수 한번 보자'와 '이번 개편 전에 현재 상태를 측정해두자'는 전혀 다른 진단이 된다. 목적이 뚜렷하면 결과 화면에서 봐야 할 곳이 또렷해진다. 접근성 민원이 들어와서 진단한다면 접근성 점수와 KWCAG 항목을 집중해서 보면 되고, 모바일에서 깨진다는 제보가 있었다면 반응형 결과를 먼저 보면 된다. 목적 없이 결과지를 받으면 '숫자는 많은데 뭘 봐야 할지 모르겠다'가 된다. 반대로 목적이 있으면 같은 결과지가 '아, 내가 궁금했던 게 이거였지'로 읽힌다.

세 번째로, '기준점'을 남길 마음의 준비를 하자. 첫 진단의 점수는 그 자체로 좋고 나쁨을 따지기보다 '앞으로의 변화를 재는 출발선'으로 보는 게 건강하다. 처음 받은 점수가 기대보다 낮아도 좌절할 필요 없다. 오히려 낮을수록 '올라갈 여지가 크다'는 뜻이다. 중요한 건 이 첫 점수를 날짜와 함께 기록해두는 것이다. 그래야 다음에 다시 진단했을 때 '올랐다/내렸다'를 말할 수 있다. 기준점 없는 개선은 '열심히는 했는데 좋아졌는지 모르겠다'로 끝나기 쉽다.

기준점을 남기는 건 사실 '나중의 나'를 위한 선물이기도 하다. 반년 뒤, 1년 뒤의 담당자(그게 나일 수도, 후임일 수도 있다)는 '예전에 우리 사이트가 어땠는지'를 궁금해할 것이다. 그때 '몇 월 며칠 첫 진단, 종합 몇 점, 가장 약했던 영역은 무엇'이라는 기록 한 장이 있으면, 그동안 우리가 얼마나 걸어왔는지를 한눈에 보여줄 수 있다. 반대로 기록이 없으면, 그 모든 노력은 '했다는 느낌'만 남고 증거는 사라진다. 공공기관에서 '우리가 무엇을 개선했는지'를 숫자로 증명할 수 있다는 건, 단순한 자기만족을 넘어 '성과를 인정받는' 근거가 된다. 그러니 첫 진단의 점수를 가볍게 흘려보내지 말고, 꼭 어딘가에 적어두자.

마지막으로, 가능하면 '혼자 보지 말 것'을 권한다. 진단 결과를 담당자 혼자 받아 들고 끙끙대면, 그 결과는 그 사람의 서랍 속에서 잠든다. 반면 결과 화면을 캡쳐해 팀과 공유하고 '여기 빨간 부분이 우리 약점인데, 이걸 어떻게 할까요'라고 안건으로 올리면, 진단은 비로소 '조직의 일'이 된다. 자동 진단의 진짜 힘은 점수 자체가 아니라, 그 점수가 '대화를 시작하게 만든다'는 데 있다. 막연했던 '우리 사이트 좀 별로인 것 같아요'가 '진단해보니 접근성에서 32점이 나왔어요'로 바뀌는 순간, 미뤄지던 개선 논의가 드디어 책상 위에 올라온다.

준비 단계에서 한 가지 더 챙기면 좋은 게 있다. '비교 대상'을 정해두는 것이다. 우리 사이트만 덜렁 진단하면 '이 점수가 높은 건지 낮은 건지' 감이 안 온다. 50점이 좋은 건지 나쁜 건지, 처음 보는 사람은 알 도리가 없다. 이럴 때 비슷한 규모의 다른 공공 사이트를 한두 곳 함께 진단해 '우리는 이 정도, 비슷한 곳은 저 정도' 하고 비교하면 우리 위치가 또렷해진다. 물론 이건 어디까지나 '참고'다. '저기보다 높으니 됐다'며 안주하라는 게 아니라, '우리가 평균쯤인지, 한참 아래인지' 감을 잡는 용도다. 비교는 '경쟁'이 아니라 '좌표 찍기'다. 같은 처지의 다른 기관들이 어디쯤 있는지를 알면, 우리가 어디로 가야 할지도 더 분명해진다.

그리고 진단 전에 '마음의 준비'도 하나 필요하다. 결과가 기대보다 나쁘게 나올 가능성을 미리 받아들이는 것이다. 사람은 누구나 자기 것을 후하게 본다. '우리 사이트 그래도 괜찮은 편이지'라는 막연한 자부심을 품고 진단을 돌렸다가, 빨간 카드가 줄줄이 뜨면 적잖이 충격을 받는다. 그래서 미리 '낮게 나와도 그건 우리 사이트가 망했다는 뜻이 아니라, 그동안 안 보이던 문제가 비로소 보이게 됐다는 뜻이다'라고 마음을 다잡아두는 게 좋다. 진단의 목적은 자랑할 점수를 받는 게 아니라, 고칠 곳을 찾는 것이다. '아니오'가 많이 나올수록, 빨간 카드가 많을수록, 그건 점검이 잘된 것이다.

■ 3. 단계별 따라 하기 — URL 넣고 결과 받기까지

이제 진짜 '따라 하기'다. 글로만 읽으면 막연하니, 실제 손이 가는 순서대로 풀어본다. 무료 진단 체험은 krds.viewcheck.co.kr/demo 에서 별도 설치 없이 브라우저만으로 바로 해볼 수 있다. 새 탭 하나 열어두고 한 단계씩 같이 가보자.

Demo 페이지에서 아래의 흐름으로 확인을 할 수 있다.

1단계, 주소창에 진단 도구를 연다. 따로 설치할 게 없다는 게 핵심이다. 무거운 프로그램을 깔거나, 권한을 신청하거나, IT팀에 부탁할 필요가 없다. 브라우저에서 진단 페이지를 열면 그 자리에서 끝이다. 공공기관 담당자에게 '설치 없이 바로 쓸 수 있다'는 건 생각보다 큰 장점이다. 내부망 정책상 새 프로그램 설치가 까다로운 환경이 많기 때문이다.

2단계, 진단할 URL을 입력칸에 붙여넣는다. 여기서 작은 요령. 주소는 'https://'부터 정확히 넣는 게 좋고, 모바일 전용 주소가 따로 있다면 그것도 따로 한번 돌려보는 게 좋다. 데스크탑 화면은 멀쩡한데 모바일에서만 깨지는 경우가 의외로 많기 때문이다. URL을 넣었으면 진단 버튼을 누른다. 이 순간부터는 도구의 시간이다. 사이트를 불러오고, 화면을 캡쳐하고, 코드 구조를 뜯어보고, 846개 규칙과 하나씩 대조하기 시작한다. 주소를 넣을 때 흔한 실수 하나만 더 짚자면, 주소 끝에 불필요한 추적 코드나 임시 파라미터가 붙은 채로 넣는 경우다. 가능하면 깔끔한 기본 주소를 넣는 게 좋다. 또 사내 테스트 서버 주소가 아니라 '실제 사용자가 보는 운영 주소'를 넣어야 의미가 있다. 우리만 보는 임시 화면이 아니라, 국민이 실제로 마주하는 그 화면을 진단해야 진짜 우리 사이트의 상태가 나온다.

3단계, 진단이 진행되는 동안 '무슨 일이 일어나는지' 알아두면 결과를 이해하기 쉽다. 도구는 단순히 화면 사진만 찍는 게 아니다. 페이지의 모든 요소를 코드 수준에서 끄집어내고, 색·글꼴·간격 같은 디자인 값을 실제 화면에서 측정하고, 버튼과 입력칸에 접근성 정보가 제대로 붙어 있는지 확인한다. 동시에 화면 모양을 보고 '이게 어떤 종류의 페이지인지(메인인지 신청인지 검색 결과인지)'를 판단해, 그 페이지에 맞는 규칙만 골라 적용한다. 신청 페이지엔 신청 흐름 규칙을, 검색 페이지엔 검색 규칙을 들이대는 식이다. 그래야 '이 페이지엔 해당 없는 규칙'으로 점수가 억울하게 깎이지 않는다.

그뿐 아니다. 진단 도구는 디자인 준수만 보는 게 아니라, 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)에 맞물린 항목들도 함께 살핀다. 페이지가 얼마나 빨리 뜨는지(효율성), 보안 설정이 제대로 됐는지(신뢰성), 검색엔진이 잘 찾을 수 있게 돼 있는지(개방성), 응답이 느리지 않은지(접속성) 같은 것들이다. 화면을 부르는 그 짧은 순간에, 도구는 이 모든 신호를 동시에 수집한다. 사람이라면 각각 따로 측정해야 할 것들을, 한 번의 진단으로 묶어서 본다. 그래서 결과 화면에는 KRDS 디자인 점수와 7대 품질 점수가 나란히 뜨고, 우리는 '우리 사이트가 디자인은 어떻고 성능은 어떻고 보안은 어떤지'를 한 화면에서 통째로 보게 된다.

이렇게 '페이지 종류를 알아서 판단하고, 그에 맞는 규칙을 골라 적용한다'는 점은 생각보다 큰 의미가 있다. 옛날식 검사 도구들은 모든 페이지에 똑같은 규칙을 들이대서, 검색 결과 페이지에 '신청 양식이 없다'고 감점하는 식의 엉뚱한 결과를 내곤 했다. 하지만 페이지 성격을 구분해 보면, 메인엔 메인에 맞는 잣대를, 신청 페이지엔 신청에 맞는 잣대를 적용해 '억울한 감점'이 사라진다. 결과의 신뢰도가 그만큼 올라간다. 우리가 결과 점수를 믿고 행동에 옮기려면, 바로 이 '맥락을 아는 진단'이 전제되어야 한다.

4단계, 잠시 기다리면 결과가 뜬다. 페이지 수에 따라 다르지만, 보통은 커피 한 모금 마실 정도의 시간이면 첫 결과가 나온다. 여러 페이지를 도는 깊은 진단이라면 조금 더 걸린다. 결과가 뜨면 가장 먼저 보이는 게 화면 상단의 '점수 카드'다. 이 점수 카드가 오늘 글의 핵심이니, 다음 소제목에서 따로 자세히 뜯어보겠다.

여기서 초보자가 자주 하는 실수 하나를 짚어두자. 결과가 뜨자마자 '점수가 낮네' 하고 창을 닫아버리는 거다. 점수는 '요약'일 뿐, 진짜 정보는 그 아래에 다 있다. 어떤 규칙을 왜 위반했는지, 어느 페이지에서 문제가 났는지, 어떻게 고치면 되는지 — 결과지는 점수 한 줄이 아니라 '개선 안내서'에 가깝다. 그러니 점수를 봤으면 반드시 한 칸 아래로 스크롤을 내려, 그 점수가 '무엇 때문에' 그렇게 나왔는지를 확인하는 습관을 들이자. 점수만 보고 닫는 건, 건강검진 결과지에서 '종합 소견' 한 줄만 읽고 상세 수치는 안 보는 것과 같다.

5단계, 결과를 '남긴다'. 화면을 캡쳐해두거나, 리포트 형태로 저장해둔다. 특히 상단 점수 카드는 진단의 '표지' 같은 거라, 이것만 캡쳐해둬도 나중에 '몇 월 며칠, 우리 사이트 첫 진단'을 또렷이 기록으로 남길 수 있다. 단, 외부에 공유할 때는 URL·도메인·기관명이 노출되지 않게 가려두는 센스가 필요하다. 진단 결과는 우리 내부의 개선 자료지, 약점을 외부에 광고할 자료가 아니니까.

따라 하기를 처음 해보는 분들이 자주 막히는 지점도 몇 가지 짚어두자. 첫째, '진단이 너무 오래 걸리는 것 같다'며 중간에 창을 닫는 경우다. 여러 페이지를 도는 진단은 생각보다 시간이 걸린다. 사이트를 한 페이지씩 실제로 불러오고, 화면을 그리고, 코드를 읽고, 수백 개 규칙과 대조하는 작업이 페이지마다 반복되기 때문이다. 화면이 한동안 '진행 중'에 머물러 있어도 멈춘 게 아니다. 조급해하지 말고 기다리면 된다. 둘째, '메인만 넣었는데 왜 다른 페이지 결과가 나오지?' 하고 당황하는 경우다. 이건 도구가 메인에서 출발해 링크를 따라 사이트 안쪽으로 들어가며 자동으로 여러 페이지를 훑었기 때문이다. 오히려 좋은 신호다. 메인 한 장만 보는 '얕은 진단'이 아니라, 사이트 전체를 보는 '깊은 진단'이 돌아갔다는 뜻이니까. 셋째, '로그인이 필요한 페이지'는 자동 진단이 들어가지 못한다는 점도 알아두자. 회원만 볼 수 있는 마이페이지나 신청 내역 같은 곳은 도구가 접근할 수 없으니, 그런 페이지는 자가 점검으로 직접 챙겨야 한다.

진단 결과를 받았을 때 가장 좋은 습관 하나만 더 권하자면, '그 자리에서 한 줄 메모를 남기는 것'이다. '오늘 며칠, 우리 사이트 첫 진단, 부품 점수가 제일 낮았음, 신청 페이지 의심' 정도면 충분하다. 이 한 줄이 나중에 큰 역할을 한다. 며칠만 지나도 '분명 뭔가 낮았는데 뭐였더라'가 되기 때문이다. 점검의 가치는 '발견'이 아니라 '기록'에서 완성된다. 발견한 걸 적어두지 않으면, 그 발견은 며칠 안에 증발한다.

■ 4. 결과 화면 읽는 법 — 상단 점수 카드 해부

자, 여기가 오늘 글에서 가장 중요한 부분이다. 결과가 떴다. 화면 맨 위에 점수 카드들이 죽 늘어서 있다. 처음 보면 '숫자가 많아서 뭘 봐야 할지 모르겠다' 싶을 거다. 하나씩 풀어보자. 사실 이 점수 카드는 우리 사이트의 '건강검진 종합표' 같은 거다. 어디가 튼튼하고 어디가 약한지를 한눈에 보여준다.

가장 먼저 봐야 할 건 KRDS 846규칙을 네 묶음으로 나눈 카테고리별 점수다. 앞선 글들에서 봤듯 846규칙은 DS(기초) 120개, CP(부품) 446개, BP(기본 패턴) 108개, SP(서비스 패턴) 172개로 나뉜다. 점수 카드는 이 네 영역을 각각 점수로 보여준다. 이걸 읽는 첫 번째 요령은 '제일 낮은 카드부터 보는 것'이다. 높은 점수 카드는 '잘하고 있다'는 칭찬이니 일단 제쳐두고, 빨갛거나 낮은 카드를 먼저 본다. 그게 곧 '우리 사이트가 가장 아픈 곳'이다.

각 카테고리가 무슨 뜻인지 다시 한번 짚자. DS(120개)가 낮다면 색·글꼴·간격 같은 '기초'가 흐트러졌다는 뜻이다. 페이지마다 색조가 다르거나, 글꼴이 제각각이거나, 여백이 들쭉날쭉할 가능성이 높다. CP(446개)가 낮다면 버튼·입력칸·메뉴 같은 '부품'에 문제가 있다는 뜻이다. 846규칙 중 가장 많은 446개가 부품에 몰려 있는 이유는, 부품이야말로 사용자가 직접 손으로 만지는 접점이기 때문이다. 그래서 CP 점수는 '사용자 체감 불편'과 가장 직결된다. BP(108개)가 낮다면 폼 구조나 오류 처리, 필터·정렬 같은 '기본 동작 패턴'이 약하다는 뜻이고, SP(172개)가 낮다면 로그인·검색·신청·정책 같은 '서비스 흐름'에 구멍이 있다는 뜻이다.

이 네 묶음은 사실 '층'의 관계다. 가장 아래에 색·글꼴·간격 같은 기초(DS)가 깔리고, 그 위에 버튼·입력칸 같은 부품(CP)이 올라가고, 다시 그 위에 폼·검색 같은 기본 동작(BP)이 얹히고, 맨 위에 신청·로그인 같은 서비스 흐름(SP)이 놓인다. 그래서 점수를 읽을 때 '아래층이 약하면 위층도 덩달아 약해진다'는 점을 염두에 둬야 한다. 예를 들어 부품(CP) 점수가 낮은데, 그 원인을 따라가 보면 사실 기초(DS)의 색 대비 기준이 없어서인 경우가 많다. 버튼이 잘 안 보이는 '증상'의 진짜 '원인'은 한 층 아래에 있는 식이다. 그러니 점수가 여러 영역에서 낮게 나왔다면, 무작정 다 손대기보다 '가장 아래층부터' 보는 게 효율적이다. 기초를 바로잡으면 그 위층 문제 중 상당수가 저절로 풀린다.

여기서 '판정률'이라는 개념도 알아두면 좋다. 어떤 카테고리는 우리 페이지에 해당 부품이 많아 대부분 규칙이 '판정'되지만, 어떤 카테고리는 해당 부품이 적어 '판정 자체가 안 된' 규칙이 많다. 예컨대 부품(CP) 446개 중 우리 페이지에 실제로 존재하는 부품이 절반뿐이라면, 나머지 절반은 '해당 없음'으로 빠진다. 이건 나쁜 게 아니다. 단지 그 페이지에 그 부품이 없다는 뜻일 뿐이다. 다만 점수를 해석할 때 '판정된 것 중 통과율'과 '전체 중 통과율'을 헷갈리지 말아야 한다. 도구는 보통 이 둘을 구분해 보여주니, '통과 / 미통과 / 해당 없음'의 세 숫자를 함께 챙겨 보는 습관을 들이자. 그래야 점수의 진짜 의미가 보인다.

여기서 점수를 '제대로' 읽는 법을 하나 알려주겠다. 점수가 높다고 무조건 좋은 게 아니고, 낮다고 무조건 나쁜 것도 아니다. 핵심은 '분모'다. 어떤 카테고리는 우리 페이지에 해당 부품이 아예 없어서 '판정 자체가 안 된' 규칙이 많을 수 있다. 예를 들어 우리 페이지에 표(table)가 없으면 표 관련 규칙은 '해당 없음'으로 빠진다. 그러니 점수와 함께 '몇 개 중 몇 개를 통과했는지', '해당 없음으로 빠진 건 몇 개인지'를 같이 봐야 한다. 통과 50개·미통과 50개로 50점인 사이트와, 통과 5개·미통과 5개로 50점인 사이트는 전혀 다른 상태다. 숫자 하나가 아니라 그 숫자의 '구성'을 봐야 한다.

점수 카드에는 KRDS 846규칙 외에도 다른 영역의 점수들이 함께 뜬다. 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과 맞물린 지표들이다. 웹접근성은 KWCAG 33항목을 기준으로, 보안·신뢰성은 보안 헤더와 인증서를, 효율성은 페이지 로딩 성능을, 개방성은 검색엔진 친화도를 본다. 이렇게 KRDS 디자인 준수와 7대 품질 영역을 한 화면에서 같이 보여주는 이유는, 좋은 공공 사이트란 '예쁘기만' 해서도, '빠르기만' 해서도 안 되고, 이 모든 게 두루 갖춰져야 하기 때문이다.

상단 점수 카드를 읽을 때 마지막 당부. 이 카드는 '사이트 전체'를 합산한 결과라는 점을 기억하자. 여러 페이지를 진단했다면, 점수 카드는 그 페이지들을 모은 평균이거나, '한 페이지라도 문제가 있으면 사이트 전체가 걸리는' 보수적 합산이다. 그래서 '메인은 멀쩡한데 왜 점수가 낮지' 싶을 때가 있는데, 그건 십중팔구 속 페이지 어딘가에서 점수가 깎인 거다. 점수 카드는 '가장 잘 만든 페이지'가 아니라 '사이트 전체의 평균적 건강 상태'를 보여준다. 그래서 점수가 낮으면 메인이 아니라 '가장 약한 페이지'를 찾아 들어가야 한다.

점수 카드를 처음 보는 사람이 가장 헷갈려 하는 게 '색깔'이다. 보통 진단 도구는 점수에 따라 카드 색을 다르게 칠한다. 초록은 '양호', 노랑은 '주의', 빨강은 '미흡' 정도로 직관적으로 읽으면 된다. 신호등을 떠올리면 쉽다. 이 색은 사실 '어디부터 봐야 하는지'를 알려주는 친절한 안내다. 빨간 카드가 곧 '지금 당장 신경 써야 할 곳'이고, 초록 카드는 '잘하고 있으니 유지만 하면 되는 곳'이다. 그러니 결과 화면을 받으면 본능적으로 '빨간색'을 찾아가는 습관을 들이자. 우리 눈이 자연스레 초록(잘된 것)에 안심하려 들지만, 개선을 위해 봐야 할 건 빨강이다.

또 한 가지, 점수를 '남과 비교'할 때 조심할 점이 있다. 같은 50점이라도 사이트마다 '50점의 의미'가 다를 수 있다. 페이지가 많고 복잡한 대형 사이트의 50점과, 단출한 소형 사이트의 50점은 같은 무게가 아니다. 복잡한 사이트일수록 챙길 게 많아 점수가 낮게 나오기 쉽다. 그러니 다른 기관과 점수를 비교할 땐 '규모가 비슷한 곳'끼리 봐야 공정하다. 더 중요한 비교 대상은 사실 '다른 기관'이 아니라 '과거의 우리'다. 남이 몇 점인지보다, 우리가 지난 분기보다 올랐는지가 훨씬 의미 있는 지표다. 진단 점수는 경쟁이 아니라 우리 자신의 성장 기록으로 쓸 때 가장 빛난다.

마지막으로, 점수 카드 아래에 펼쳐지는 '상세 영역'도 잊지 말자. 상단 카드가 '요약 표지'라면, 그 아래는 '본문'이다. 각 카테고리를 눌러 들어가면 어떤 규칙을 통과했고 어떤 규칙을 위반했는지, 위반한 규칙은 어느 페이지의 어느 부분에서 걸렸는지가 펼쳐진다. 점수만 보면 '아프다'까지만 알지만, 상세 영역까지 봐야 '어디가, 왜 아픈지'를 안다. 진짜 개선은 이 상세 영역에서 시작된다. 점수 카드는 그 상세로 들어가는 '입구'일 뿐이다.

■ 5. 점수가 낮게 나왔을 때 — 멘붕 대신 우선순위

진단을 처음 돌린 담당자들이 가장 많이 보이는 반응이 '예상보다 점수가 낮아서 당황'이다. 충분히 그럴 수 있다. 평소 '우리 사이트 그래도 괜찮은 편인데'라고 생각했는데, 막상 숫자로 보니 빨간 카드가 줄줄이 뜨면 누구나 가슴이 철렁한다. 하지만 여기서 멘붕에 빠지지 말고, '그럼 무엇부터 손대지'로 마음을 빨리 옮기는 게 중요하다. 그 순서를 정하는 법을 풀어본다.

첫째 원칙은 '영향 큰 것부터'다. 846개 규칙이 다 똑같이 중요한 게 아니다. 어떤 규칙은 안 지켜도 '조금 덜 예쁜' 정도지만, 어떤 규칙은 안 지키면 '특정 사용자가 서비스를 아예 못 쓰는' 치명적 문제다. 제대로 된 진단 도구는 위반 항목마다 심각도(우선순위)를 매겨준다. 가장 심각한 등급(보통 P0이라 부르는)부터 손대는 게 정석이다. 빨간 카드 100개를 보고 '어휴 100개를 언제 다 고치나' 하지 말고, '이 중 가장 치명적인 10개가 뭐지'를 찾는 거다. 그 10개만 고쳐도 사용자 체감은 확 달라진다.

둘째 원칙은 '많은 사람이 겪는 것부터'다. 사이트에서 사용자가 가장 많이 거치는 흐름, 가장 많이 방문하는 페이지의 문제를 먼저 고친다. 하루에 한 명 들어올까 말까 한 구석 페이지의 문제보다, 매일 수천 명이 거치는 신청 페이지의 작은 불편이 훨씬 큰 피해를 만든다. 진단 결과에서 '어느 페이지에서 이 위반이 났는지'를 보고, 트래픽이 많은 페이지의 문제에 가중치를 둔다. 같은 위반이라도 위치에 따라 무게가 다르다. 이걸 '면적의 문제'로 생각하면 쉽다. 작은 불편이라도 많은 사람이 겪으면 그 불편의 '총합'은 어마어마해진다. 반대로 큰 불편이라도 극소수만 겪는다면 우선순위는 뒤로 밀릴 수 있다. '불편의 크기 × 겪는 사람 수'로 따져 가장 넓은 면적부터 메우는 게 현명하다. 우리 기관에서 사람들이 가장 많이 하는 일이 무엇인지를 떠올리며 결과를 보면, 어디부터 손대야 할지가 자연스레 보인다.

셋째 원칙은 '고치기 쉬운 것부터(단, 영향이 비슷하다면)'다. 영향이 엇비슷한 두 문제가 있다면, 손이 덜 가는 쪽을 먼저 처리해 '빠른 성취'를 쌓는 게 좋다. 개선이라는 건 동력이 필요한 일이라, 초반에 '오 점수가 올랐네' 하는 작은 성공이 쌓여야 팀이 계속 움직인다. 대체텍스트 몇 개 채우기, 색 대비 살짝 높이기처럼 손쉬운 것부터 처리해 점수가 꿈틀대는 걸 눈으로 확인하면, 그다음 어려운 문제에도 손을 댈 의욕이 생긴다.

여기서 진단 도구의 도움이 빛난다. 좋은 도구는 단순히 '이거 틀렸어'라고 지적만 하지 않고, '어떻게 고치면 되는지' 안내와 '대략 얼마나 걸리는지' 추정까지 함께 준다. 위반 항목을 클릭하면 '이 규칙은 왜 있는 규칙이고, 어떤 점이 문제이며, 이렇게 바꾸면 통과한다'는 설명이 따라붙는다. 담당자가 이걸 그대로 외주 업체나 개발자에게 전달하면, '우리 사이트 좀 고쳐주세요'라는 막연한 요청이 '이 페이지의 이 버튼에 이 속성을 이렇게 넣어주세요'라는 구체적 작업 지시로 바뀐다. 막연함이 구체성으로 바뀌는 그 순간, 개선은 비로소 '실행 가능한 일'이 된다.

여기서 '심각도'를 어떻게 읽는지 조금 더 풀어보자. 진단 도구는 보통 위반을 몇 단계 우선순위로 나눈다. 가장 높은 등급은 '이건 안 고치면 특정 사용자가 서비스를 아예 못 쓴다' 수준의 치명적 문제다. 키보드로 신청 버튼에 닿을 수 없거나, 화면 낭독기가 입력칸을 못 읽거나, 색만으로 정보를 전달해 색맹 사용자가 구분 못 하는 경우 등이 여기 해당한다. 그다음 등급은 '크게 불편하지만 우회는 가능한' 문제, 그 아래는 '다소 거슬리는' 문제, 가장 낮은 등급은 '미관상 아쉬운' 정도다. 이 우선순위는 '무엇부터 고칠지'를 정하는 가장 든든한 나침반이다. 빨간 카드 100개에 압도당하지 말고, '가장 높은 등급'으로 분류된 항목부터 추려 보면, 손댈 곳이 의외로 몇 개 안 된다는 걸 알게 된다. 그 몇 개를 먼저 처리하는 것만으로도 '서비스를 못 쓰던 사용자'가 '쓸 수 있는 사용자'로 바뀐다.

또 하나 권하고 싶은 건 '작업 지시서 만들기'다. 진단 결과의 위반 항목을 그대로 캡쳐하거나 정리해, 개선을 맡을 사람(내부 담당자든 외주든)에게 넘기는 거다. 이때 단순히 '점수가 낮으니 고쳐주세요'가 아니라, '이 페이지의 이 버튼이 이 규칙을 위반했고, 도구 설명에 따르면 이렇게 바꾸면 통과한다'까지 정리해 넘기면 개선 속도가 확 빨라진다. 막연한 요청은 '뭘 어떻게 하라는 건지 모르겠다'는 되물음만 낳지만, 구체적인 지시는 곧장 작업으로 이어진다. 좋은 진단 도구는 위반마다 '왜 문제이고 어떻게 고치는지'를 함께 알려주니, 그 내용을 그대로 옮기기만 해도 훌륭한 작업 지시서가 된다.

마지막으로, 가장 중요한 마음가짐. '한 번에 다 고치려 하지 말 것.' 공공 사이트의 KRDS 준수는 단거리 경주가 아니라 마라톤이다. 첫 진단에서 낮은 점수를 받았다고 그걸 한 달 안에 만점으로 끌어올리려 들면 모두가 지쳐 나가떨어진다. 대신 '이번 분기엔 가장 치명적인 10개', '다음 분기엔 사용자 많은 페이지의 흐름 문제', 이런 식으로 끊어서 간다. 그리고 분기마다 다시 진단을 돌려 점수가 올라가는 걸 확인한다. 그 '올라가는 그래프'가 팀의 가장 큰 보상이 된다. 개선은 '완벽'이 아니라 '방향'이다. 어제보다 오늘이 조금 나아지면, 그걸로 충분히 잘 가고 있는 거다.

덧붙이자면, 점수를 '만점'으로 만드는 게 목표가 아니라는 점도 분명히 해두자. 어떤 위반은 우리 사이트의 특성상 '일부러 그렇게 둔' 것일 수도 있고, 어떤 '해당 없음'은 그 페이지에 그 부품이 없어서 영영 채워지지 않을 수도 있다. 그러니 '모든 카드를 초록으로' 같은 비현실적 목표에 매달리지 말고, '사용자가 실제로 불편한 지점'을 줄여간다는 마음으로 접근하는 게 건강하다. 숫자 자체에 집착하면 '점수를 위한 점수'가 되어, 정작 사용자 경험은 뒷전이 되는 본말전도가 생긴다. 점수는 어디까지나 '사용자가 편한가'를 재는 대리 지표일 뿐, 그 자체가 목적이 아니다.

■ 6. 자동 진단을 '습관'으로 만드는 법

진단을 딱 한 번 하고 마는 건, 체중을 딱 한 번 재고 마는 것과 같다. 그 순간의 숫자는 알 수 있지만, 살이 빠지고 있는지 찌고 있는지는 알 수 없다. 자동 진단의 진짜 가치는 '반복'에서 나온다. 어떻게 진단을 일회성 이벤트가 아니라 조직의 습관으로 정착시킬지, 현실적인 방법을 풀어본다.

가장 쉬운 시작은 '주기를 정하는 것'이다. 분기에 한 번, 혹은 큰 콘텐츠 개편이 있을 때마다 진단을 돌리기로 팀 안에서 약속한다. 거창한 절차가 아니어도 된다. '매 분기 첫째 주 월요일엔 사이트 진단을 돌린다' 같은 가벼운 규칙 하나면 충분하다. 주기가 정해지면 진단은 '마음먹고 하는 큰일'에서 '때 되면 하는 루틴'으로 바뀐다. 부담이 줄어드니 빠지지 않고, 빠지지 않으니 추세가 쌓인다.

다음은 '비교하는 습관'이다. 진단할 때마다 이전 결과와 나란히 놓고 본다. '지난 분기엔 부품 점수가 48점이었는데 이번엔 55점이 됐네'처럼. 이 비교가 개선의 동력을 만든다. 올랐으면 '우리가 한 게 효과가 있었구나' 하고 자신감을 얻고, 내렸으면 '어 무슨 일이 있었지' 하고 원인을 찾는다. 특히 내린 경우가 중요하다. 새 페이지를 추가하면서 기준을 안 지켰거나, 외주가 만든 페이지가 기존 규칙을 따르지 않았을 때 점수가 슬그머니 내려간다. 정기 진단은 이런 '조용한 후퇴'를 일찍 잡아낸다.

이 '조용한 후퇴'를 조금 더 풀어보자. 사이트는 가만히 둬도 시간이 지나면 품질이 떨어지는 경향이 있다. 콘텐츠가 계속 추가되고, 여러 사람이 손을 대고, 외주가 바뀌고, 새 기능이 붙으면서 처음의 통일감이 조금씩 흐트러진다. 이걸 '디지털 노후화'라고 부를 수 있겠다. 건물도 관리 안 하면 낡듯, 사이트도 방치하면 낡는다. 다만 건물의 노후는 눈에 보이지만 사이트의 노후는 잘 안 보인다. 어느 날 갑자기 '우리 사이트 왜 이렇게 됐지' 싶을 때쯤이면 이미 한참 진행된 뒤다. 정기 진단은 이 보이지 않는 노후를 '숫자가 슬금슬금 내려가는 것'으로 일찍 알아챈다. 그래서 정기 진단은 '새 문제를 찾는 일'이기도 하지만, 그 못지않게 '있던 좋은 것을 지키는 일'이기도 하다.

세 번째는 '새로 만드는 것에 진단을 끼워 넣는 것'이다. 사이트 개선의 가장 효율적인 전략은 '이미 있는 걸 다 고치기'가 아니라 '앞으로 만드는 것부터 제대로 만들기'다. 새 페이지를 만들거나 새 양식을 추가할 때, 공개 전에 진단을 한 번 돌려보는 걸 절차에 넣는다. 이렇게 하면 문제가 '세상에 나가기 전에' 걸러진다. 이미 공개된 페이지를 고치는 것보다, 공개 전에 잡는 게 열 배는 싸고 쉽다. 진단을 '사후 점검'이 아니라 '사전 관문'으로 쓰는 거다.

네 번째는 '기록을 남기고 공유하는 것'이다. 진단 결과를 캡쳐해 팀 게시판이나 공유 폴더에 날짜별로 쌓아둔다. 그러면 1년 뒤엔 우리 사이트의 '건강 일지'가 만들어진다. 새 담당자가 와도 이 일지를 보면 '우리 사이트가 어떤 길을 걸어왔는지'를 단번에 파악한다. 인수인계가 '말로 떠넘기기'에서 '기록으로 넘기기'로 바뀐다. 공공기관은 담당자 교체가 잦은 곳이라, 이 '남는 기록'의 가치가 특히 크다.

다섯 번째이자 가장 중요한 건, '진단을 의사결정에 연결하는 것'이다. 진단 점수를 그냥 보고만 하지 말고, 윗선 보고나 예산 요청의 근거로 쓴다. '우리 사이트 접근성 점수가 3분기째 기준 미달이라, 개선 예산이 필요합니다'라는 보고는, 막연한 '사이트가 좀 별로예요'보다 훨씬 힘이 세다. 행정안전부 「전자정부 웹사이트 품질관리 지침」이라는 공식 기준에 비춰 '우리가 지금 어디에 있는지'를 숫자로 제시하면, 결재권자도 움직이기 쉽다. 진단은 단순한 점검을 넘어 '예산과 인력을 끌어오는 명분'이 되어줄 수 있다.

습관화의 가장 큰 적은 '완벽주의'다. '제대로 된 진단 체계를 갖춘 다음에 시작하자', '담당자를 정하고 절차를 만든 다음에 하자' 하고 미루다 보면 영영 못 한다. 그냥 오늘 한 번 돌려보고, 다음 분기에 또 한 번 돌려보고 — 이 '가볍게 반복하기'가 거창한 체계보다 백배 낫다. 체계는 반복하다 보면 저절로 생긴다. 처음부터 완벽한 틀을 짜려 들면 시작조차 못 하고, 일단 시작하면 '아 이건 이렇게 정리하면 좋겠다'가 자연스레 따라온다. 습관은 결심이 아니라 반복으로 만들어진다.

그리고 진단을 '비난의 도구'가 아니라 '개선의 도구'로 쓰는 문화가 중요하다. 점수가 낮게 나왔을 때 '누가 이렇게 만들었어' 하고 책임자를 찾기 시작하면, 다들 진단을 피하게 된다. 진단이 무서워지면 아무도 안 돌린다. 반대로 '아 여기가 약하구나, 같이 고쳐보자'는 분위기면, 진단은 '우리를 돕는 도구'가 된다. 낮은 점수는 누구의 잘못도 아니다. 기준이 없던 시절에 만들어진 결과일 뿐이다. 중요한 건 과거를 탓하는 게 아니라 앞으로를 바꾸는 것이다. 진단을 '심판'이 아니라 '코치'로 대하는 조직이, 결국 가장 빨리 좋아진다.

이 모든 습관의 출발점은 결국 '첫 진단'이다. 거창한 계획을 다 세운 뒤에 시작하려 하면 영영 시작 못 한다. 일단 오늘, URL 하나 넣고 첫 점수를 받아보는 것 — 거기서부터 모든 게 시작된다. 첫 점수가 낮아도 괜찮다. 그 낮은 점수가 바로 우리의 출발선이고, 앞으로 올라갈 모든 점수의 기준점이 되어줄 테니까.

■ 7. 자가 점검과 자동 진단, 함께 쓰는 법

오늘 글은 자동 진단을 다뤘지만, 지난주에 소개한 '눈으로 보는 5분 자가 체크리스트'를 버리라는 말은 아니다. 둘은 경쟁 관계가 아니라 짝꿍이다. 어떻게 둘을 엮어 쓰면 가장 효과적인지, 마지막으로 정리해본다.

자가 점검과 자동 진단은 서로의 빈틈을 메운다. 자가 점검은 '사람의 직관'으로 본다. '이 흐름 어쩐지 불편한데', '이 문구 왠지 헷갈리는데' 같은, 기계가 못 잡는 '느낌'을 잡아낸다. 반면 자동 진단은 '기계의 정밀함'으로 본다. 색 대비 수치, 코드 속 접근성 속성, 수백 페이지의 일관성 같은, 사람 눈으로 못 보는 걸 잡아낸다. 그러니 둘을 함께 쓰면 '느낌으로 잡는 것'과 '수치로 잡는 것'을 모두 커버하게 된다.

권하는 순서는 이렇다. 먼저 자동 진단으로 '전체 윤곽'을 잡는다. 어느 영역이 약한지, 어느 페이지에 문제가 몰렸는지 숫자로 확인한다. 그다음 그 '약한 영역, 문제 페이지'를 들고 자가 점검으로 들어간다. 자동 진단이 'CP 점수가 낮다'고 알려줬으면, 그 페이지를 직접 열어 키보드로 돌아다녀 보고, 버튼을 눌러보고, 폼을 채워본다. 그러면 숫자로만 알던 문제가 '아, 이게 이렇게 불편했구나' 하고 몸으로 와닿는다. 기계가 '어디가 문제인지'를 빠르게 짚어주고, 사람이 '왜 문제인지, 얼마나 불편한지'를 체감하는 식이다.

이 순서가 효율적인 이유는 '시간 배분' 때문이다. 사이트 전체를 사람이 손으로 다 점검할 시간은 없다. 그래서 도구로 먼저 '어디가 약한지'를 추려, 사람의 귀한 시간을 그 약한 곳에만 집중적으로 쏟는 거다. 멀쩡한 페이지를 일일이 손으로 확인하느라 힘 빼지 말고, 도구가 '여기 문제 있어'라고 짚어준 곳만 깊이 파고든다. 한정된 인력으로 최대 효과를 내려면, 이렇게 '기계로 넓게, 사람으로 깊게' 역할을 나누는 게 정답이다. 넓이는 도구가, 깊이는 사람이 맡는다.

반대 순서도 좋다. 사용자 민원이 들어왔을 때, 먼저 자가 점검으로 '민원이 말하는 그 불편'을 직접 재현해본다. 그다음 자동 진단을 돌려 '그 불편이 어떤 규칙 위반에서 비롯됐는지'를 확인한다. 그러면 막연한 민원이 '구체적인 규칙 위반'으로 번역되고, 그걸 고치는 작업 지시로 곧장 이어진다. 민원 → 재현 → 진단 → 수정으로 이어지는 이 흐름이 자리 잡으면, 사용자의 목소리가 사이트 개선으로 빠르게 연결된다.

핵심은 '사람과 기계의 역할을 나누되 손은 맞잡는 것'이다. 기계에게 반복적이고 정밀한 비교를 맡기고, 사람은 판단과 공감을 맡는다. 기계는 지치지 않고 흔들리지 않으며, 사람은 맥락을 읽고 우선순위를 정한다. 이 둘이 만나면 '빠르면서도 정확하고, 정밀하면서도 따뜻한' 점검이 된다. 어느 한쪽만으로는 반쪽짜리다. 자동 진단만 믿으면 '숫자는 좋은데 어쩐지 쓰기 불편한' 사이트가 되기 쉽고, 자가 점검만 믿으면 '느낌은 괜찮은데 코드 속에 문제가 숨은' 사이트가 된다. 둘을 함께 써야 비로소 '진짜 좋은 사이트'에 다가간다.

실제 현장에서 이 둘을 엮는 가장 간단한 방법을 하나 소개한다. '진단 결과를 들고 사용자 흉내 내기'다. 자동 진단이 '이 신청 페이지의 흐름 점수가 낮다'고 알려줬다고 하자. 그러면 그 페이지를 직접 열어, 마우스를 책상 서랍에 넣어두고 키보드만으로 신청을 끝까지 해본다. 일부러 필수 칸을 비우고 제출도 눌러본다. 모니터 밝기를 확 낮추고 글씨가 읽히는지도 본다. 이렇게 '진단이 짚어준 약한 페이지'에서 '직접 사용자가 되어보는' 체험을 하면, 숫자가 '아 이래서 낮았구나' 하고 살아 움직인다. 도구가 길을 안내하고, 사람이 그 길을 직접 걸어보는 셈이다. 이 한 번의 체험이 백 마디 설명보다 강력하게 개선 의지를 불러일으킨다.

또 하나, 두 점검을 '번갈아' 쓰는 리듬도 추천한다. 분기마다 자동 진단으로 전체 추세를 잡고, 그 사이사이 새 페이지를 만들 때마다 가벼운 자가 점검으로 기본기를 챙기는 식이다. 무거운 자동 진단을 매번 돌릴 필요는 없다. 큰 그림은 도구에 맡기고, 일상적인 작은 점검은 눈으로 빠르게 처리한다. 이렇게 강약을 조절하면 점검이 부담이 아니라 '몸에 밴 습관'이 된다. 건강을 위해 1년에 한 번 정밀검진을 받되, 평소엔 가볍게 체중을 재고 산책을 하는 것과 같은 이치다. 큰 검진과 작은 관리가 함께 가야 건강이 유지되듯, 사이트도 그렇다.

마무리

오늘 우리는 'URL 하나만 넣으면 끝나는' 자동 진단의 처음부터 끝까지를 따라가 봤다. 왜 손이 아니라 도구로 진단해야 하는지(사람 눈에 안 보이는 것, 일관성, 속도), 진단 전에 무엇을 준비하면 좋은지(대표 URL·목적·기준점·공유), URL을 넣고 결과를 받기까지의 단계, 그 결과 화면의 상단 점수 카드를 어떻게 읽어야 하는지(낮은 카드부터·분모를 함께·사이트 전체 평균), 점수가 낮을 때 무엇부터 손대야 하는지(영향 큰 것·많은 사람 겪는 것·쉬운 것 순), 진단을 습관으로 만드는 법, 그리고 자가 점검과 자동 진단을 함께 쓰는 법까지 — 한 바퀴를 돌았다.

긴 글이었지만, 정작 행동은 단순하다. 새 탭을 열고, 우리 사이트 주소를 넣고, 진단 버튼을 누르는 것. 그게 전부다. 이 작은 행동 하나가 '우리 사이트를 제대로 보기'의 첫걸음이 된다. 거창한 개편 계획을 세우기 전에, 먼저 '지금 우리가 어디에 있는지'를 아는 것 — 모든 개선은 거기서 출발한다. 그리고 그 출발선을 긋는 데는 5분이면 충분하다.

기억하자. 첫 점수가 낮아도 괜찮다. 그건 실패가 아니라 출발선이다. 빨간 카드가 많다는 건 '고칠 거리가 많다'는 뜻이고, 그건 곧 '좋아질 여지가 그만큼 크다'는 뜻이다. 중요한 건 점수의 높낮이가 아니라, 그 점수가 분기마다 조금씩 올라가는 '방향'이다. 오늘 첫 진단으로 그 기준점 하나를 찍어두면, 다음 진단부터는 '얼마나 좋아졌는가'를 말할 수 있게 된다.

혹시 '우리 사이트는 지금 몇 점일까' 궁금해졌다면, 지금 바로 확인해볼 수 있다. krds.viewcheck.co.kr 에서 URL 하나만 넣으면 무료로 진단 체험을 해볼 수 있다. KRDS 846규칙(DS 120 + CP 446 + BP 108 + SP 172)을 기준으로 우리 사이트가 어디에 있는지, 상단 점수 카드 한 장으로 한눈에 보여준다. 설치도, 비용도, 결재도 필요 없다. 이 글을 다 읽은 지금이 바로 첫 진단을 돌려볼 가장 좋은 때다. 5분 뒤, 당신은 우리 사이트의 '첫 건강검진표'를 손에 쥐게 될 것이다. 그리고 그 한 장이, 미뤄두었던 개선의 첫 단추가 되어줄 것이다.

오늘 글에서 줄곧 강조한 '따라 하기'의 핵심을 마지막으로 한 번 더 압축하면 이렇다. 첫째, 메인만 보지 말고 사용자가 많이 거치는 핵심 흐름까지 진단할 것. 둘째, 결과가 떴을 때 점수만 보고 닫지 말고 한 칸 아래 상세까지 내려가 '왜 그 점수인지'를 확인할 것. 셋째, 빨간 카드부터 보되 '가장 심각한 등급' 몇 개에 먼저 집중할 것. 넷째, 첫 점수를 날짜와 함께 기록해 '다음 진단과 비교할 기준점'으로 삼을 것. 다섯째, 혼자 끙끙대지 말고 결과를 팀과 공유해 '대화의 출발점'으로 쓸 것. 이 다섯 가지만 지키면, 자동 진단은 단순한 점수 놀이가 아니라 진짜 사이트를 바꾸는 도구가 된다.

다음 주부터는 한 달 내내 '접근성'을 깊게 파고든다. 모두가 쓸 수 있는 공공 사이트가 왜 선택이 아니라 의무인지, KWCAG 33항목을 어떻게 하나씩 챙길 수 있는지를 차근차근 풀어볼 예정이다. 오늘 진단으로 우리 사이트의 접근성 점수를 미리 확인해두면, 다음 달 글이 훨씬 더 와닿을 것이다.

끝으로 한마디. 완벽한 사이트는 세상에 없다. 잘 만든 사이트와 방치된 사이트의 차이는 '문제가 없는 것'이 아니라 '문제를 알고 고쳐가는 것'이다. 오늘의 진단 한 번이 그 '고쳐가는 여정'의 첫 발자국이다. 거창하게 시작할 필요 없다. 새 탭을 열고, 주소를 넣고, 버튼을 누르는 것 — 딱 거기까지만 하면 된다. 나머지는 도구가, 그리고 차곡차곡 쌓이는 우리의 작은 노력이 채워간다. 그럼 다음 글에서 만나자.