카테고리별 우선 점검 규칙 정리

공감·문제제기

이번 주는 내내 846개 규칙 이야기를 했다. 월요일엔 "846이라는 숫자에 겁먹지 마라, 결국 네 묶음(DS·CP·BP·SP)으로 나뉜다"고 했고, 수요일엔 그 네 묶음이 각각 무엇을 보는지, 왜 그렇게 나눴는지를 풀었다. 그래서 오늘은 한 발 더 들어가려 한다. "그래서, 그 846개 중에 내가 뭘 먼저 봐야 하는데?"에 대한 답이다.

솔직히 고백하자면, 나도 처음 846이라는 숫자를 마주했을 때 가장 먼저 든 생각은 '이걸 어느 세월에 다 보냐'였다. 규칙 목록을 쭉 내려보다가 스크롤 바가 손가락 한 마디만큼 줄어드는 걸 보고 그냥 창을 닫아버린 적도 있다. 그런데 일을 하면서 깨달은 게 하나 있다. 846개가 다 똑같이 중요한 게 아니라는 것. 어떤 규칙은 위반하면 당장 사용자가 신청을 못 하고, 어떤 규칙은 위반해도 '조금 덜 예쁜' 정도에 그친다. 어떤 규칙은 한 번 어기면 사이트 전체에 영향이 번지고, 어떤 규칙은 그 페이지 한 칸에서 끝난다. 그러니까 진짜 필요한 건 '846개를 다 보는 법'이 아니라, '846개 중 먼저 봐야 할 것부터 골라내는 안목'이다.

오늘 글은 바로 그 안목을 만드는 글이다. 카테고리별로 '이건 무조건 먼저 봐라' 하는 우선 점검 규칙을 추려, 담당자가 자기 사이트를 열어놓고 그 자리에서 바로 따라 할 수 있게 정리했다. 디자인 전공이 아니어도, 코드를 못 읽어도 괜찮다. 화면을 보고 '예/아니오'만 판단하면 되는 항목들로 골랐으니까.

먼저 분명히 해두자. 이건 846개를 전부 사람 손으로 검사하라는 글이 아니다. 그건 가능하지도 않고, 그러라고 만든 글도 아니다. 정밀한 전수 검사는 도구의 몫이다. 그런데도 사람이 '우선 점검 규칙' 정도는 직접 손에 익혀둬야 하는 이유가 있다. 도구가 빨강·노랑으로 결과를 뱉어줘도, 그게 무슨 의미인지 모르면 그냥 '색깔 있는 숫자판'일 뿐이기 때문이다. 카테고리마다 '가장 중요한 몇 개'를 직접 눈으로 확인해 본 사람은, 나중에 자동 진단 리포트를 받았을 때 그 숫자들이 살아 움직인다. '아, 이 빨강이 그때 내가 직접 봤던 그 문제구나' 하고.

준비물은 단출하다. 우리 기관 사이트, 데스크탑 브라우저 하나, 스마트폰 하나, 그리고 메모할 종이나 메모 앱. 키보드도 손 닿는 곳에 둬라. 뒤에서 '마우스 떼고 키보드만으로 돌아다니기' 같은 동작을 할 거니까. 시간은 카테고리당 5분, 전부 다 해도 30분이면 충분하다. 점심시간 한 번이면 우리 사이트가 어느 카테고리에서 새고 있는지 윤곽이 잡힌다.

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

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

이 점검이 '비용이 안 드는 일'이라는 것도 큰 매력이다. 외부 컨설팅을 부르거나 도구를 사기 전에, 지금 당장 30분이면 시작할 수 있다. 돈도 안 들고, 결재도 필요 없고, 누구의 허락도 필요 없다. 그저 우리 사이트를 사용자의 눈으로 한 바퀴 돌아보는 것뿐이다. 이 작은 시작이 '우리 사이트를 제대로 보기'의 첫걸음이 된다. 거창한 개편 계획을 세우기 전에, 먼저 '지금 어떤 상태인지' 아는 것 — 모든 개선은 거기서 출발한다. 그리고 솔직히 말하면, 이렇게 한 번 내 손으로 훑어본 사람과 그렇지 않은 사람은 이후 일하는 결이 완전히 달라진다. 외주 업체가 '이건 원래 이렇게 합니다'라고 둘러댈 때, 한 번이라도 직접 점검해본 담당자는 '아니요, 여기 신청 흐름에서 진행 표시가 빠져 있던데요' 하고 구체적으로 받아칠 수 있다. 막연히 '좀 별로인 것 같은데'라고 말하는 사람과, 항목을 짚어 말하는 사람은 협상 테이블에서 무게가 다르다.

마지막으로 점검에 임하는 태도 하나만 더. 이 체크리스트는 '한 번 하고 끝'이 아니라 '정기적으로 반복'할 때 진가가 드러난다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 추가되고 페이지가 늘어나면서 계속 변한다. 오늘 '예'였던 항목이 반년 뒤엔 '아니오'가 되어 있을 수 있다. 새 부서 페이지가 생기면서 색이 또 제각각이 되고, 외주가 새로 손댄 신청 폼에서 진행 표시가 사라지는 식이다. 그래서 분기에 한 번쯤 같은 체크리스트로 다시 점검하면, 사이트가 좋아지고 있는지 나빠지고 있는지 추세가 보인다. 오늘의 점검은 그 첫 번째 기준점을 찍는 일이다. 자, 그럼 카테고리별로 '무엇을 먼저 봐야 하는지' 하나씩 들어가 보자.

왜 '우선순위'가 필요한가

■ 846개를 다 보지 말고, '먼저 새는 곳'부터 막아라

846개 규칙을 처음 접한 담당자들이 가장 흔히 빠지는 함정이 있다. '이걸 다 통과해야 한다'는 강박이다. 그래서 첫 페이지 하나를 붙들고 규칙 번호 1번부터 차례로 대조하다가, 30분쯤 지나 지쳐서 손을 놓는다. 그러고는 'KRDS는 너무 복잡해서 우리 같은 작은 기관은 못 한다'는 결론을 내린다. 안타깝지만 아주 흔한 풍경이다.

그런데 생각해보면 이건 '다 보려다 아무것도 못 보는' 전형적인 실패다. 집에 물이 새는데 모든 수도관을 동시에 점검하려 들면, 정작 지금 줄줄 새는 그 한 곳을 놓친다. 먼저 할 일은 '가장 크게 새는 곳'을 찾아 막는 거다. 규칙도 똑같다. 846개 중에는 '지금 당장 사용자에게 피해를 주는 규칙'과 '있으면 좋지만 없어도 큰 탈은 없는 규칙'이 섞여 있다. 우선순위란 그 둘을 가려내는 일이다.

그럼 무엇을 '먼저 새는 곳'으로 볼 것인가. 나는 세 가지 기준으로 판단하길 권한다. 첫째, '영향 범위'다. 그 규칙을 어겼을 때 사이트 전체가 영향받는가, 아니면 그 페이지 한 칸에서 끝나는가. 색·글꼴의 기준이 없는 건 사이트 전체에 번지는 문제고, 특정 페이지 한 이미지의 대체텍스트가 빠진 건 그 자리에서 끝나는 문제다. 당연히 전자가 우선이다. 둘째, '사용자 피해의 종류'다. 그 규칙을 어겼을 때 사용자가 '조금 불편한' 데 그치는가, 아니면 '하려던 일을 아예 못 하는'가. 신청 버튼이 안 보여서 신청 자체를 못 하는 건 전자가 아니라 후자다. 셋째, '얼마나 자주 걸리는가'다. 우리 같은 공공 사이트들이 거의 다 똑같이 틀리는 항목이 있다. 그런 항목은 '우리도 십중팔구 틀렸다'고 보고 먼저 확인하는 게 효율적이다.

이 세 기준으로 추리면, 846개는 '반드시 먼저 볼 수십 개'로 좁혀진다. 오늘 글은 그 수십 개를 카테고리별로 정리한 것이다. 이걸 다 봤다고 사이트가 KRDS를 완전히 준수하는 건 아니다. 하지만 적어도 '가장 크게 새던 곳'은 막게 된다. 그리고 그렇게 큰 구멍부터 막아두면, 남은 미세한 항목들은 도구에 맡기고 천천히 채워가면 된다. 순서가 핵심이다. 큰 것부터, 자주 걸리는 것부터, 사용자가 일을 못 하게 만드는 것부터.

여기서 한 가지 오해를 풀고 가자. '우선순위를 둔다'는 건 '나머지를 버린다'는 뜻이 아니다. 먼저 볼 것을 정하는 일이지, 안 볼 것을 정하는 일이 아니다. 우선 점검에서 통과한 항목이라고 영영 안전한 것도 아니고, 오늘 미뤄둔 미세 항목이 영영 무시해도 되는 것도 아니다. 다만 '한정된 시간 안에 무엇부터 손댈까'를 정할 때, 아무 기준 없이 1번 규칙부터 순서대로 보는 것보다 '영향·피해·빈도'를 따져 보는 게 훨씬 효율적이라는 것이다. 우선순위는 '선택과 집중'을 위한 도구이지, '일부를 포기하기' 위한 핑계가 아니다. 큰 구멍을 막은 뒤에는 반드시 도구를 동원해 나머지까지 마저 채워야, 비로소 한 바퀴가 닫힌다.

■ 네 카테고리, 점검 순서도 '아래층부터'

지난 글에서 KRDS의 네 묶음이 '층'을 이룬다고 했던 걸 기억하는가. 가장 아래에 색·글꼴·간격 같은 기초(DS·디자인 스타일, 120개)가 있고, 그 위에 버튼·입력칸·메뉴 같은 부품(CP·컴포넌트, 446개)이 올라가고, 다시 그 위에 신청·검색 같은 흐름(BP·BasicPatterns 108개, SP·ServicePatterns 172개)이 얹힌다. 이 층 구조는 점검 순서에도 그대로 적용된다.

왜 아래층(기초)부터 봐야 하나. 아래층이 흔들리면 그 위층도 같이 흔들리기 때문이다. 예를 들어 '버튼이 잘 안 보인다'는 부품(CP)의 문제가, 알고 보면 '색 대비 기준이 없다'는 기초(DS)의 문제에서 비롯된 경우가 아주 많다. 만약 기초를 건너뛰고 부품부터 봤다면, 우리는 '버튼을 더 진하게 칠하자'는 임시방편만 반복하다 같은 문제를 계속 만났을 거다. 하지만 기초부터 보면 '아, 색 기준 자체가 없구나' 하는 진짜 원인이 잡힌다. 그 원인 하나를 잡으면 그 위에서 파생된 여러 부품 문제가 한꺼번에 정리된다.

그래서 오늘 점검은 DS(기초) → CP(부품) → BP·SP(흐름)의 순서를 따른다. 거기에 '모두가 쓸 수 있는가'를 보는 접근성 관점, '모바일에서도 작동하는가'를 보는 반응형 관점, '앞으로도 유지되는가'를 보는 운영 관점을 곁들인다. 이 순서대로 한 바퀴 돌면, 사이트를 '기초→부품→흐름→모두에게→어디서나→앞으로까지' 빠짐없이 훑게 된다.

이 '아래층부터' 원칙에는 또 하나의 실용적 이점이 있다. 고칠 때의 '비용 대비 효과'가 아래층일수록 크다는 점이다. 기초(DS)의 색 기준 하나를 바로잡으면, 그 색을 쓰는 수백 개의 버튼·배너·링크가 한꺼번에 정돈된다. 한 곳을 고쳐 여러 곳이 좋아지는 셈이다. 반대로 가장 위층의 개별 항목, 이를테면 특정 페이지 한 이미지의 대체텍스트를 고치는 건 딱 그 한 자리에서 끝난다. 물론 둘 다 필요하지만, '한정된 시간과 예산을 어디부터 쓸까'를 정할 때는 아래층, 즉 영향이 넓은 곳부터 손대는 게 합리적이다. 그래서 점검 순서가 곧 '개선 투자 순서'의 힌트가 되기도 한다.

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

DS(디자인 스타일) 우선 점검

■ DS, 120개 중 '이것부터' 보라

DS는 색·글꼴·간격·아이콘 같은 '기초 재료'를 다루는 카테고리다. 846개 중 120개로 숫자만 보면 적은 편이지만, 영향 범위로 따지면 가장 무겁다. 기초 재료가 흔들리면 그 위에 올라가는 모든 부품과 흐름이 함께 흔들리기 때문이다. 그래서 DS는 '개수는 적지만 우선순위는 가장 높은' 카테고리다.

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

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

DS-우선② 한 페이지 안에서 글꼴이 두 종 이하로 유지되는가?

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

DS-우선③ 본문 글자와 배경의 색 대비가 충분해 또렷이 읽히는가?

→ 자주 보이는 문제: 회색 배경에 연회색 글자, 옅은 파랑 위에 흰 글자처럼 '예뻐 보이려다 안 읽히는' 조합.

DS-우선④ 요소 사이 간격과 정렬이 가지런한가?

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

이 네 항목을 점검하는 가장 쉬운 방법은 '여러 페이지를 빠르게 넘겨보는 것'이다. 메인에서 출발해 부서 페이지, 신청 페이지, 안내 페이지를 차례로 열어 화면을 죽 스크롤해 보라. 색조와 분위기가 '같은 사이트 안에 있다'는 느낌으로 이어지면 통과고, 페이지마다 '여기는 좀 다른 데 같은데' 싶으면 일관성이 깨진 거다. 한 페이지만 보면 '이 정도면 괜찮은데' 싶던 것도, 여러 화면을 나란히 띄워놓고 눈을 옮기면 '아, 제각각이구나'가 한눈에 들어온다. 색과 간격의 균열은 '화면을 넘나들 때' 가장 잘 드러나기 때문이다.

DS-우선③, 즉 색 대비는 특별히 강조하고 싶다. 이건 '미관'의 문제가 아니라 '읽히느냐 마느냐'의 문제이기 때문이다. 디자이너가 보기엔 세련된 연회색 글자가, 노안이 온 어르신이나 햇빛 아래서 스마트폰을 보는 사용자에겐 '아예 안 보이는 글자'가 된다. 공공 사이트는 '잘 보이는 사람'이 아니라 '잘 안 보이는 사람'까지 읽을 수 있어야 하는 곳이다. 그래서 색 대비는 DS 카테고리에서도 가장 먼저, 가장 엄격하게 봐야 할 항목이다. 점검할 때 '나는 보이는데?'가 아니라 '우리 부모님도 이게 보일까?'를 기준으로 삼아보라. 그러면 통과시켰던 항목 중 적잖은 수가 '아니오'로 바뀐다.

DS에서 '아니오'가 나오는 근본 원인은 거의 항상 같다. '기준이 머릿속에만 있고, 화면 어디에도 적혀 있지 않다'는 것이다. 페이지를 만들 때마다 담당자나 외주가 '대충 비슷한 파랑'을 눈대중으로 골라 코드에 직접 박는다. 정해진 '우리 기관의 파랑' 하나를 공유해 쓴 게 아니라, 각자 기억에 의존해 그때그때 새로 고른다. 그런데 머릿속의 파랑은 사람마다 다르고, 같은 사람도 모니터가 바뀌면 다르게 본다. 이렇게 '각자의 기억'으로 만든 결과물이 모이면, 개별로는 다 그럴듯한데 전체로는 제각각인 사이트가 된다.

그래서 DS 문제의 해법은 '색을 더 잘 고르는 것'이 아니라 '기준을 화면 밖으로 꺼내 모두가 같은 걸 보고 쓰게 하는 것'이다. 이게 바로 디자인 토큰이고, KRDS가 색·글꼴·간격을 토큰으로 정리해 둔 이유다. DS에서 '아니오'가 여럿 나왔다면, 당장 모든 페이지의 색을 다 고치려 들지 마라. 그건 끝이 안 보이는 일이고, 하다가 지쳐 포기하기 십상이다. 대신 '앞으로 만드는 것부터 기준을 지키게' 하고, 기존 페이지는 사용자가 가장 많이 보는 것부터 천천히 정리하는 게 현실적이다. 기준 하나를 정해 모두가 공유하면, 그날 이후의 모든 페이지가 그 기준을 따라가며 사이트가 서서히 한 몸이 된다. DS의 '아니오'는 '지금 당장 큰일'이라기보다 '기준을 세울 때가 됐다'는 신호에 가깝다.

■ DS 점검 요령: '동시에 띄워 비교하기'

DS를 볼 때 가장 효과적인 요령 하나를 더 일러두겠다. 한 페이지씩 따로 보지 말고, 메인·목록·상세·신청 네 페이지를 '동시에 띄워' 화면을 좌우로 옮겨가며 비교하라. 같은 '파랑'인데 페이지마다 미묘하게 다른지, 같은 '제목'인데 크기가 들쭉날쭉한지는 한 화면만 봐서는 잘 안 보인다. 여러 화면을 나란히 놓고 눈을 옮겨야 비로소 차이가 도드라진다. 모니터가 하나뿐이면 브라우저 창을 둘로 쪼개 나란히 놓거나, 캡처를 떠서 한 이미지에 붙여놓고 봐도 된다.

또 하나, DS는 '딱 집어 말하긴 어렵지만 분명히 느껴지는' 영역이다. '여기 어딘가 어수선한데 뭐가 문제인지는 모르겠다' 싶을 때가 바로 DS가 새고 있다는 신호다. 그 '어딘가 어수선함'의 정체는 십중팔구 '기준 없는 색'과 '제각각인 간격'이다. 그러니 DS 점검에서는 논리적으로 따지기보다 '첫인상'을 믿어도 좋다. 사이트에 들어선 순간 '여기 정돈됐네' 혹은 '여기 좀 산만하네' 하는 0.1초의 느낌 — 그게 사용자가 받는 첫인상이고, 그 첫인상이 '이 기관이 일을 꼼꼼히 하는가'에 대한 무의식적 판단으로 이어진다. 내용이 아무리 좋아도 기초가 흐트러져 있으면 신뢰가 깎인다. DS의 '아니오'를 단순한 미관 문제로 가볍게 넘기면 안 되는 이유가 여기에 있다.

DS에서 의외로 많이 새는 또 하나가 '아이콘'이다. 같은 '검색'을 뜻하는데 어느 페이지엔 돋보기 모양, 어디선 다른 모양을 쓰거나, 아이콘 크기가 페이지마다 들쭉날쭉하거나, 아이콘만 덩그러니 있고 글자 설명이 없어 '이게 무슨 버튼이지' 싶은 경우다. 아이콘은 '말 없이 뜻을 전하는 그림'이라, 일관성이 깨지면 사용자가 매번 그 뜻을 다시 해석해야 한다. DS를 볼 때 아이콘도 '같은 뜻은 같은 모양, 같은 크기로, 가능하면 글자 설명과 함께' 쓰이는지 슬쩍 확인하라. 작아 보여도 사용자의 인지 부담에 직접 영향을 준다.

간격 이야기도 한 번 더 짚자. KRDS가 간격을 '8단위' 같은 규칙으로 정리해 둔 데는 이유가 있다. 사람 눈은 '규칙적인 리듬'을 편안하게 느낀다. 8, 16, 24처럼 일정한 단위로 여백이 떨어지면 화면이 '정돈된 음악'처럼 읽히고, 7, 11, 13처럼 제멋대로면 '박자 어긋난 소음'처럼 느껴진다. 우리는 그 차이를 또렷이 의식하진 못하지만 몸은 안다. 그래서 DS의 간격 점검은 '자로 재는 일'이 아니라 '리듬을 느끼는 일'에 가깝다. 화면을 죽 훑었을 때 어딘가 '턱턱 걸리는' 느낌이 든다면, 십중팔구 간격의 리듬이 깨진 것이다.

CP(컴포넌트) 우선 점검

■ CP, 446개 중 '이것부터' 보라

CP는 846개 규칙 중 가장 많은 446개를 차지하는 카테고리다. 버튼·입력칸·메뉴·표·알림창·탭 같은 '부품'을 다룬다. 왜 이렇게 많을까. 부품은 사용자가 '직접 손으로 만지는' 접점이기 때문이다. 기초(DS)가 '분위기'라면 부품은 '손잡이'다. 손잡이가 헐겁거나 어디 있는지 안 보이면, 아무리 분위기가 좋아도 문을 못 연다. 그래서 CP의 '아니오'는 사용자가 실제로 '하려던 일을 못 하는' 상황으로 바로 이어진다.

446개를 다 볼 순 없으니, 우선순위가 높은 다섯 개만 추렸다.

CP-우선① 화면에서 '무엇을 누를 수 있는지' 한눈에 보이는가?

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

CP-우선② '제출·확인' 같은 주 버튼과 '취소·뒤로' 같은 보조 버튼이 시각적으로 구분되는가?

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

CP-우선③ 입력칸마다 바깥에 라벨이 붙어 있는가? (칸 안 흐린 글씨 말고)

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

CP-우선④ 키보드 Tab 키로 이동할 때, 지금 어디에 있는지 '선택 표시(초점 테두리)'가 보이는가?

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

CP-우선⑤ 버튼을 눌렀을 때 '눌렸다'는 반응(색 변화·로딩 표시)이 있는가?

→ 자주 보이는 문제: 아무 반응이 없어 사용자가 같은 버튼을 여러 번 누른다. 중복 신청 사고가 여기서 난다.

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

CP-우선④(초점 표시)와 CP-우선①(누를 수 있는 것 구분)은 특히 우선순위가 높다. 이 둘은 접근성과 직결되기 때문이다. 마우스를 못 쓰는 사용자, 화면을 못 보고 키보드로만 사이트를 쓰는 사용자에게 초점 표시는 '지금 내가 어디 있는지 알려주는 유일한 등불'이다. 그 등불이 꺼져 있으면 그들은 캄캄한 방에서 손으로 더듬는 것과 같다. 디자이너가 '초점 테두리가 보기 싫다'며 일부러 없애버리는 경우가 의외로 많은데, 이건 '미관을 위해 접근성을 끈' 대표적인 실수다. CP 점검에서 이 항목이 '아니오'라면, 미관 논쟁을 떠나 무조건 먼저 고쳐야 한다.

■ CP 점검 요령: '일부러 헷갈려 보기'와 '말의 일관성'

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

또 CP-우선②(주·보조 버튼 구분)를 점검할 땐 '일부러 헷갈려 보기'가 효과적이다. 신청 페이지의 맨 아래로 내려가 '제출'과 '취소' 버튼을 0.5초만 흘끗 보고, 어느 게 제출인지 직관적으로 구분되는지 확인하라. 둘이 같은 크기·같은 색이면 '아니오'다. 주 버튼은 진하고 크게, 보조 버튼은 옅고 작게 — 이 단순한 위계 하나가 '실수로 취소 눌러 처음부터 다시'를 막는다. 특히 어르신 사용자가 많은 공공 사이트에서 이건 사소한 게 아니다. 신청서를 다 채우고 마지막에 취소를 눌러 모든 게 날아간 경험은, 그 사용자에게 '이 사이트는 두 번 다시 안 와'라는 결심을 심어준다.

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

CP는 다섯 카테고리 중에서도 '체감 불편'이 가장 즉각적으로 드러나는 곳이다. 그래서 여기서 잡아낸 문제는 고쳤을 때 효과도 가장 빠르게 느껴진다. DS(기초)는 고쳐도 '어딘가 정돈됐다'는 정도의 미묘한 개선이지만, CP는 '안 되던 게 된다'는 명확한 변화가 온다. 그래서 '개선 효과를 윗선에 보여줘야 하는' 담당자라면, CP의 우선 항목부터 손대는 게 설득에 유리하다. '예전엔 신청 버튼이 안 보였는데 이제 또렷이 보입니다' 같은 변화는 누가 봐도 알아챈다.

■ CP에서 자주 놓치는 '표·알림창·메뉴'

버튼과 입력칸은 그래도 다들 신경을 쓰는 편이다. 정작 CP에서 자주 새는 곳은 표·알림창·메뉴 같은 '덜 주목받는 부품'이다. 이것들도 우선 점검에 넣어두자.

먼저 표. 공공 사이트엔 통계·일정·요금 같은 표가 정말 많다. 그런데 이 표가 '제목 칸과 내용 칸이 구분되는지', '모바일에서 가로로 넘치지 않는지'를 점검하는 경우는 드물다. 제목 칸 구분이 없는 표는 화면 낭독기 사용자에게 '숫자가 줄줄이 나열되는 의미 불명의 소리'가 된다. 표 하나를 점검할 때는 '이 표를 눈으로 안 보고 소리로만 들어도 무슨 내용인지 알 수 있을까'를 상상해보라. 그 답이 '아니오'라면 표 구조에 손이 필요하다.

다음은 알림창(팝업·모달). '저장되었습니다' '정말 삭제하시겠습니까' 같은 창이 뜰 때, 그 창이 키보드로 닫히는지, 닫고 나면 초점이 원래 자리로 돌아오는지를 본다. 마우스로만 닫히는 팝업은 키보드 사용자를 '영원히 그 창 안에 가두는' 함정이 된다. 그리고 알림창의 '확인'과 '취소' 버튼도 CP-우선②와 똑같이 구분돼야 한다. 특히 '삭제' 같은 되돌릴 수 없는 동작의 확인 창에서, 위험한 버튼(삭제)과 안전한 버튼(취소)이 똑같이 생겼다면 그건 사고를 부르는 설계다.

마지막은 메뉴. 메뉴는 사이트의 '지도'다. 메뉴가 키보드로 펼쳐지는지, 하위 메뉴가 마우스 호버로만 열리지는 않는지, 모바일에서 햄버거 버튼이 충분히 크고 또렷한지를 본다. 메뉴는 모든 사용자가 가장 먼저, 가장 자주 마주치는 부품이라 여기서의 '아니오'는 파급이 크다. 메뉴를 못 펼치면 사용자는 사이트의 나머지 전부를 못 보는 셈이니까. 그래서 메뉴는 CP 안에서도 '버튼·입력칸 다음으로' 우선순위를 높게 두는 게 좋다.

BP·SP(흐름) 우선 점검

■ 흐름, 사용자가 '목적을 이루느냐'를 가르는 영역

BP(108개)와 SP(172개)는 '흐름'을 다룬다. BP는 폼 작성·필터·정렬·오류 처리 같은 '공통 행동 패턴'을, SP는 로그인·검색·신청·예약·정책 안내 같은 '서비스별 흐름'을 본다. 둘을 묶어 '흐름'이라 부르는 이유는, 둘 다 '사용자가 한 화면에 머무는 게 아니라 여러 단계를 거쳐 목적을 이루는' 과정을 다루기 때문이다.

흐름은 사용자가 '목적을 이루느냐 마느냐'를 가르는 영역이라, 여기서의 '아니오'는 곧 서비스 실패로 이어진다. DS·CP가 '불편함'의 영역이라면, BP·SP는 '성패'의 영역이다. 버튼이 좀 안 예뻐도 신청은 할 수 있지만, 흐름이 막히면 신청 자체가 안 된다.

BP·SP-우선① 신청·예약 같은 여러 단계 흐름에서 '지금 몇 단계 중 어디인지'가 보이는가?

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

BP·SP-우선② 폼을 잘못 채웠을 때, '어느 칸이, 왜 틀렸고, 어떻게 고치라'고 그 칸 옆에서 알려주는가?

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

BP·SP-우선③ 검색 결과가 0건일 때, 다음에 뭘 하라고(검색어 수정·추천 등) 안내하는가?

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

BP·SP-우선④ 신청 도중 '뒤로 가기'를 눌러도 적던 내용이 보존되는가?

→ 자주 보이는 문제: 한 칸 잘못 눌러 뒤로 갔다가 처음부터 다시 적어야 한다.

BP·SP-우선⑤ 로그인·본인인증 단계가 불필요하게 길지 않은가?

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

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

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

■ 흐름 점검은 '넓게 조금씩'보다 '핵심을 깊게'

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

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

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

여기에 더해 SP에서만 특별히 봐야 할 게 하나 있다. '정책·약관·개인정보 안내가 사용자가 이해할 수 있는 말로 적혀 있는가'다. 신청 흐름에서 마주치는 동의 항목들이 법조문 그대로 빽빽하게 적혀 있으면, 사용자는 '읽지 않고 동의'를 누른다. 그건 동의가 아니라 '포기'다. 좋은 SP는 꼭 알아야 할 핵심을 사용자의 언어로 한 줄 요약해 주고, 자세한 원문은 펼쳐볼 수 있게 둔다. 흐름의 마지막을 가르는 게 바로 이런 '읽히는 안내'다.

■ 검색과 로그인, 두 '관문'을 따로 챙겨라

SP 안에서도 특히 두 흐름은 따로 떼어 점검하길 권한다. 검색과 로그인이다. 이 둘은 사이트의 '관문'이라, 여기서 막히면 사용자는 사이트 안으로 아예 들어오지도 못한다.

먼저 검색. 공공 사이트에서 검색은 메뉴를 못 찾은 사용자가 마지막으로 기대는 '구명줄'이다. 그런데 이 검색이 부실한 경우가 의외로 많다. 검색어를 한 글자라도 다르게 쓰면 결과가 0건이 되거나, 띄어쓰기 하나에 결과가 달라지거나, 결과가 나와도 '무엇이 중요한 결과인지' 순서가 엉망인 식이다. 검색을 점검할 때는 '일반 사용자가 쓸 법한 말'로 검색해보라. 행정 용어가 아니라 보통 사람의 말로. 예를 들어 담당자는 '영업신고'라고 검색하지만 사용자는 '가게 내려고'라고 친다. 그 차이를 사이트가 메워주는지가 검색 품질의 핵심이다. 그리고 결과가 0건일 때 '검색어를 바꿔보세요' '이런 건 어떠세요' 같은 다음 행동을 안내하는지도 꼭 보라. 막다른 길에서 손을 내미는 게 좋은 검색이다.

다음은 로그인·본인인증. 이건 '하기 싫지만 해야만 하는' 관문이라, 조금만 길고 복잡해도 사용자가 등을 돌린다. 점검할 때는 '로그인부터 실제 목적(신청·조회)에 도달하기까지 몇 번의 클릭·입력이 필요한가'를 세어보라. 단계가 불필요하게 많거나, 인증 수단이 하나뿐이라 그게 없는 사용자는 아예 진입이 막히거나, 인증 도중 다른 앱·창을 오가야 해서 길을 잃는다면 모두 '아니오'다. 로그인은 '보안'이라는 명분으로 불편이 정당화되기 쉬운 영역인데, 보안과 편의는 양자택일이 아니다. 꼭 필요한 인증만 남기고, 한 번 인증하면 그 세션 동안은 다시 묻지 않으며, 인증 수단을 여럿 두어 선택지를 주는 것 — 이게 보안을 지키면서도 관문을 낮추는 길이다.

이 두 관문에서 '아니오'가 나왔다면 우선순위를 아주 높게 두라. 안쪽의 신청 흐름이 아무리 매끄러워도, 관문에서 막히면 사용자는 그 매끄러움을 경험할 기회조차 없기 때문이다. 가장 좋은 신청서도, 들어오지 못한 사용자에겐 존재하지 않는 것과 같다.

접근성·모바일·운영, 카테고리 너머의 우선 점검

■ 접근성: 네 카테고리를 가로지르는 '공통 점검선'

지금까지 DS·CP·BP·SP 네 카테고리를 봤는데, 이 넷을 '세로로 가로지르는' 점검선이 하나 있다. 바로 접근성이다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」 7대 영역 중 '접근성'이 여기에 해당하고, 우리나라 웹접근성 지침인 KWCAG는 33개 항목으로 이를 구체화한다. 접근성은 특정 카테고리에만 있는 게 아니라 DS(색 대비)에도, CP(초점 표시·대체텍스트)에도, BP·SP(키보드로 흐름 완주)에도 다 걸쳐 있다. 그래서 카테고리 점검과 별개로, 접근성만 따로 한 번 더 훑는 '공통 점검선'이 필요하다.

접근성-우선① 의미 있는 이미지에 대체텍스트(alt)가 있는가?

→ 자주 보이는 문제: alt가 비어 있거나 '이미지' '사진'처럼 무의미하게 채워져, 화면을 못 보는 사용자가 그 이미지의 내용을 알 수 없다.

접근성-우선② 마우스 없이 키보드만으로 사이트의 모든 기능을 쓸 수 있는가?

→ 자주 보이는 문제: 마우스 호버로만 열리는 메뉴, 클릭으로만 닫히는 팝업이 키보드 사용자를 가둔다.

접근성-우선③ 색에만 의존해 정보를 전달하지는 않는가?

→ 자주 보이는 문제: '빨간 글씨=필수'처럼 색으로만 구분해, 색을 구별 못 하는 사용자가 정보를 놓친다.

접근성-우선④ 글자 크기를 키워도(브라우저 확대) 레이아웃이 깨지지 않는가?

→ 자주 보이는 문제: 200%로 키우면 글자가 잘리거나 버튼이 화면 밖으로 밀려난다.

접근성은 '소수의 특별한 사용자를 위한 배려' 정도로 여겨지기 쉬운데, 이건 큰 오해다. 공공 사이트는 '모든 국민'이 이용 대상이다. 노안이 온 어르신, 손이 불편해 마우스를 못 쓰는 사용자, 색을 잘 구별 못 하는 사용자, 화면 낭독기로 사이트를 '듣는' 사용자 — 이들은 '특별한 소수'가 아니라 '우리 모두의 미래이거나 이웃'이다. 그리고 접근성이 좋은 사이트는 비장애인에게도 더 쓰기 편하다. 초점 표시가 또렷하면 키보드 빠른 입력이 편하고, 색 외에 모양으로도 구분해 두면 누구에게나 더 명확하다. 접근성은 '소수를 위한 양보'가 아니라 '모두를 위한 품질'이다.

접근성을 점검하는 가장 빠른 방법 하나를 일러두겠다. 브라우저에서 글자 크기를 200%로 키워보고, 마우스를 손에서 떼고 키보드로만 한 바퀴 돌아보는 것 — 이 둘만 해봐도 접근성의 큰 구멍은 거의 다 드러난다. 화면 낭독기 점검은 좀 더 전문적이라 처음엔 어렵지만, 위 두 가지는 누구나 5분이면 한다. 그리고 이 두 가지에서 통과하면, 접근성 점수의 상당 부분을 이미 확보한 셈이다.

접근성을 '법적 의무'의 관점으로만 보는 시각도 바로잡고 싶다. 물론 공공 사이트의 웹접근성은 법으로 정해진 의무가 맞다. 하지만 '의무라서 마지못해' 하는 점검과 '이 사람들이 정말 우리 서비스를 못 쓰고 있다'는 마음으로 하는 점검은 결과물이 다르다. 전자는 '기준을 형식적으로 통과'하는 데 그치지만, 후자는 '실제로 쓸 수 있게' 만든다. 화면 낭독기를 한 번이라도 켜서 우리 사이트를 '귀로 들어본' 담당자는, 그 경험을 잊지 못한다. 줄줄이 읽히는 '이미지, 이미지, 이미지' 소리, 어디가 버튼인지 알 수 없는 막막함을 직접 들어보면, alt 텍스트 하나가 누군가에겐 '눈'이라는 걸 몸으로 알게 된다. 접근성 점검의 '아니오'는 숫자가 아니라 사람이다.

■ 모바일: '작은 화면에서 다시 보기'

요즘 공공 사이트 방문의 절반 이상이 스마트폰에서 일어난다. 그런데 점검은 데스크탑에서만 하고 끝내는 경우가 많다. 그래서 '모바일에서 다시 보기'를 별도 우선 점검선으로 둔다.

모바일-우선① 손가락으로 누를 버튼·링크가 충분히 크고, 서로 너무 붙어 있지 않은가?

→ 자주 보이는 문제: 버튼이 작고 빽빽해 엉뚱한 걸 누른다. 최소 44×44 픽셀이 권장 기준이다.

모바일-우선② 가로 스크롤 없이 세로로만 읽히는가?

→ 자주 보이는 문제: 표나 이미지가 화면을 넘쳐 좌우로 밀어야 보인다.

모바일-우선③ 글자가 확대 없이 바로 읽히는가?

→ 자주 보이는 문제: 데스크탑 화면을 그대로 줄여놔서 글자가 깨알같다.

모바일 점검은 '진짜 스마트폰으로' 하는 게 핵심이다. 데스크탑 브라우저의 '모바일 보기' 기능으로 흉내 낼 수도 있지만, 손가락으로 실제 버튼을 눌러보는 감각은 진짜 기기에서만 나온다. 특히 '터치 타깃 크기'는 화면으로 보면 멀쩡해 보여도 손가락으로 누르면 옆 버튼이 같이 눌리는 경우가 많다. 그러니 모바일-우선①만큼은 반드시 실제 폰으로, 그것도 가능하면 손가락이 큰 사람에게 부탁해 눌러보게 하라.

모바일에서 또 자주 놓치는 게 '신청 폼'이다. 데스크탑에선 한 화면에 시원하게 펼쳐지던 폼이, 작은 화면에선 칸이 빽빽하게 겹치거나, 키보드가 올라오면서 정작 입력 중인 칸이 가려지거나, '다음' 버튼이 키보드에 가려 안 보이는 식이다. 모바일 방문이 절반을 넘는 시대에, 신청을 모바일에서 끝까지 해보지 않고 '됐겠지' 하는 건 위험하다. 데스크탑에서 잘 되는 흐름도 모바일에서 다시 한 번, 손가락으로 끝까지 밟아보라. 의외로 '여기서 막히는구나' 싶은 지점이 나온다. 그리고 그 지점이 바로 '가장 많은 사용자가 실제로 좌절하는 곳'이다. 데스크탑 점검만 하고 모바일을 건너뛰면, 사용자 절반의 경험을 통째로 모르고 지나치는 셈이다.

■ 운영: '앞으로도 유지되는가'

마지막 점검선은 운영이다. 지금 좋아도 6개월 뒤에 다시 무너지면 소용없다. 운영 관점은 '이 품질이 지속될 구조인가'를 본다.

운영-우선① 색·글꼴·간격의 '기준 문서'가 있고, 새 페이지를 만들 때 그걸 참고하는가?

→ 기준이 머릿속에만 있으면, 담당자가 바뀌는 순간 품질이 리셋된다.

운영-우선② 외주에 맡길 때 'KRDS를 따르라'는 요구가 계약·과업지시서에 명시돼 있는가?

→ 명시가 없으면 외주는 '예전 방식'으로 만든다. 품질은 요구하는 만큼만 나온다.

운영-우선③ 정기적으로(분기 1회 등) 같은 점검을 반복할 계획이 있는가?

→ 사이트는 살아 있는 생물이라 콘텐츠가 늘면서 계속 변한다. 한 번 점검으로 끝내면 반년 뒤 도로 무너진다.

운영은 눈에 잘 안 띄어 자꾸 뒤로 밀리는데, 사실 '가장 비용 대비 효과가 큰' 점검선이다. 기준 문서 하나, 계약서 한 줄, 분기 점검 일정 하나 — 이 세 가지를 갖춰두면 이후의 모든 작업이 '저절로' 품질을 유지하게 된다. 반대로 이게 없으면 아무리 열심히 고쳐도 새는 독에 물 붓기가 된다. 그래서 운영-우선①·②·③은 '지금 당장 화면을 고치는 일'보다 우선순위가 낮아 보여도, 길게 보면 가장 먼저 챙겨야 할 항목들이다.

운영을 점검할 때 특히 '외주 계약' 항목(운영-우선②)을 강조하고 싶다. 공공 사이트의 상당수는 외부 업체가 만들고 유지한다. 그런데 과업지시서에 'KRDS를 따르라' '웹접근성 기준을 충족하라'는 요구가 빠져 있으면, 업체는 그걸 '안 해도 되는 일'로 본다. 일은 요구한 만큼만 나온다. 반대로 계약서에 그 한 줄이 명시돼 있으면, 그건 검수의 근거가 되고 업체도 처음부터 그 기준에 맞춰 작업한다. 이미 만들어진 사이트를 나중에 KRDS에 맞추는 것보다, 처음 만들 때부터 맞추게 하는 게 비용이 훨씬 적게 든다. 그래서 다음 개편이나 신규 구축 계약을 앞두고 있다면, 화면을 고치는 것보다 '계약서 한 줄'을 챙기는 게 먼저다.

또 하나, 운영 점검에는 '담당자가 바뀌어도 품질이 유지되는가'라는 관점이 깔려 있다. 공공기관은 인사이동이 잦다. 사이트를 잘 알던 담당자가 다른 부서로 가고 새 담당자가 오면, 그동안 머릿속에만 있던 기준이 한순간에 증발한다. 그래서 '색은 이걸 쓰고, 신청 폼은 이렇게 만든다'는 약속이 문서로 남아 있어야 한다. 사람은 떠나도 문서는 남는다. 운영 점검의 본질은 '지식을 사람의 기억에서 조직의 자산으로 옮기는 일'이다.

점검 결과를 '다음 행동'으로 잇기

■ '아니오'를 한 줄 메모로 남겨라

여기까지 따라왔다면 손에 적잖은 '아니오'가 모였을 거다. 이제 그 '아니오'를 그냥 '아니오'로 두지 말고, 옆에 한 줄짜리 메모를 남겨라. 이를테면 'CP-우선② 아니오 — 신청 페이지에서 제출·취소 버튼이 똑같이 생김'처럼. 이 한 줄이 나중에 '무엇을 고쳐야 하는지'를 정확히 짚어주는 작업 지시서가 된다. 점검만 하고 무엇이 문제였는지 적어두지 않으면, 며칠만 지나도 '분명 뭔가 아니오가 많았는데 뭐였더라'가 된다. 점검의 가치는 '발견'이 아니라 '기록'에서 완성된다.

메모를 모았으면 다음은 '분류'다. 모인 '아니오'를 세 칸으로 나눠보라. 첫째 칸은 '지금 당장 고칠 수 있는 것'(글자 색 진하게, 버튼 라벨 통일 등 손쉬운 것). 둘째 칸은 '담당 부서·외주와 협의해야 할 것'(흐름 재설계, 초점 표시 추가 등). 셋째 칸은 '기준·계약을 손봐야 할 것'(색 기준 문서 만들기, 계약서에 KRDS 명시 등). 이렇게 나눠두면, 막막하던 '아니오' 더미가 '오늘 할 일·이번 달 할 일·올해 할 일'로 정리된다.

■ '영향 × 노력' 격자로 우선순위를 매겨라

세 칸으로 나눴어도 여전히 항목이 많아 막막하다면, 한 단계 더 들어가 '영향 × 노력' 격자를 그려보라. 가로축은 '고치는 데 드는 노력'(쉬움↔어려움), 세로축은 '고쳤을 때의 영향'(작음↔큼)이다. 모인 '아니오'를 이 격자의 네 칸에 흩뿌려 보면, 어디부터 손대야 할지가 한눈에 보인다.

가장 먼저 칠 곳은 '영향 크고 노력 적은' 칸이다. 색 대비 한 줄 바꾸기, 버튼 라벨 통일하기, 초점 표시 되살리기 같은 게 대개 여기 들어간다. 적은 손으로 큰 효과를 내니, 점검 직후 '성과를 빨리 보여줘야 하는' 상황에 딱이다. 그다음은 '영향 크고 노력 큰' 칸 — 신청 흐름 재설계, 검색 개편 같은 무거운 일이다. 이건 시간을 잡아 계획적으로 가야 한다. '영향 작고 노력 적은' 칸은 짬날 때 틈틈이, '영향 작고 노력 큰' 칸은 솔직히 당분간 미뤄도 된다. 한정된 자원을 '큰 효과부터' 쏟는 게 핵심이다.

이 격자가 좋은 또 다른 이유는, '윗선 설득'에 그대로 쓸 수 있다는 점이다. '이 다섯 개는 거의 공짜로 큰 효과가 납니다'라고 격자로 보여주면, 결재가 빨라진다. 막연한 '개선이 필요합니다'보다 '영향 크고 노력 적은 다섯 건부터 이번 주에 처리하겠습니다'가 훨씬 설득력 있다. 점검의 가치는 결국 '다음 행동을 구체적으로 만드는 것'에서 완성된다.

■ 자가 점검의 한계를 정직하게 인정하기

오늘 우리가 한 점검은 '우선 점검'이지 '전수 점검'이 아니다. 카테고리마다 가장 중요한 몇 개를 눈으로 확인했을 뿐, 846개를 다 본 게 아니다. 그러니 '우리 사이트는 이제 KRDS를 다 지킨다'고 결론 내리면 안 된다. 자가 점검은 '빠르고 거칠게 전체 윤곽을 잡는 일'이고, 정밀 진단은 '느리지만 정확하게 세부를 따지는 일'이다. 둘은 역할이 다르고, 둘 다 필요하다.

특히 사람 눈으로는 '비슷해 보이지만 미묘하게 어긋난' 것들을 잡아내기 어렵다. 같은 파랑인데 색 코드가 한 끗 다른 것, 간격이 7픽셀인지 8픽셀인지, 글꼴 크기가 규격에서 1픽셀 벗어났는지 — 이런 건 사람이 눈으로 따질 수 없다. 그리고 846개를 모든 페이지에서 일일이 대조하는 건, 페이지가 수십 개만 돼도 사람 손으로는 물리적으로 불가능하다. 바로 이 지점에서 자동 진단 도구가 필요해진다. 사람은 '우선순위가 높은 큰 구멍'을 막고, 도구는 '사람이 놓치는 미세한 어긋남과 방대한 양'을 채운다. 둘의 역할 분담이 명확할 때 점검이 완성된다.

여기서 '페이지 수'의 문제를 한 번 더 짚고 싶다. 오늘 우리가 한 우선 점검은 보통 메인과 대표 흐름 몇 개를 본 것이다. 그런데 공공 사이트는 페이지가 수백, 많게는 수천 개에 이른다. 메인은 멀쩡한데 깊숙한 부서 페이지나 오래된 공지 페이지에서 같은 위반이 잔뜩 쌓여 있는 경우가 흔하다. 사용자가 검색을 타고 들어오는 '입구'는 메인이 아니라 그런 깊은 페이지일 때가 많다. 그래서 '메인만 점검하고 안심하기'는 위험하다. 사람 손으로 수백 페이지를 다 볼 순 없으니, 이 '넓이의 문제'야말로 도구가 빛을 발하는 지점이다. 한 페이지를 깊게 보는 건 사람이, 수백 페이지를 빠짐없이 훑는 건 도구가 — 이 분담이 '우선 점검'과 '전수 진단'의 경계를 가른다.

그래서 오늘 글의 결론은 이렇다. '카테고리별 우선 점검으로 큰 구멍부터 막고, 그다음 자동 진단으로 나머지를 확정하라.' 순서가 중요하다. 자가 점검 없이 바로 도구만 돌리면 '숫자는 나왔는데 뭘 봐야 할지 모르는' 상태가 되고, 도구 없이 자가 점검만 믿으면 '눈에 안 보이는 깊은 문제'를 놓친다. 둘을 차례로 거쳐야 비로소 '우리 사이트가 어디가 좋고 어디가 나쁜지'가 또렷해진다.

한 가지 덧붙이면, 자가 점검을 거친 뒤 도구를 돌리면 '도구의 결과를 검증하는' 효과도 생긴다. 내가 손으로 '이 버튼은 구분이 안 된다'고 적어둔 항목이 자동 진단에서도 CP 위반으로 잡히면, '아, 이 도구가 내 눈과 같은 걸 보는구나' 하고 결과를 신뢰하게 된다. 반대로 내가 멀쩡하다고 본 곳을 도구가 위반으로 짚으면, '내가 놓친 게 있구나' 하고 다시 들여다보게 된다. 사람과 도구가 서로의 눈을 검증해주는 셈이다. 그 교차 검증을 거친 결과지는 윗선이나 외주를 설득할 때도 훨씬 단단한 근거가 된다. 사람도 그렇게 봤고 도구도 그렇게 봤다면, 그건 더 이상 '담당자 개인의 의견'이 아니라 '확인된 사실'이 되니까.

마무리

오늘 우리는 846개라는 막막한 숫자를 '카테고리별 우선 점검'이라는 손에 잡히는 일로 바꿔봤다. 기초(DS)에서는 색·글꼴·간격의 일관성과 대비를, 부품(CP)에서는 누를 수 있는 것의 구분·초점 표시·상태 반응을, 흐름(BP·SP)에서는 진행 표시·인라인 오류 안내·상태 유지를 먼저 봤다. 거기에 접근성·모바일·운영이라는 세 점검선을 가로질러 '모두가, 어디서나, 앞으로도' 쓸 수 있는지를 확인했다.

핵심은 '다 보려 하지 말고, 먼저 새는 곳부터 막아라'였다. 846개가 다 똑같이 중요한 게 아니다. 영향이 넓고, 사용자가 일을 못 하게 만들고, 다들 자주 틀리는 것 — 그 순서로 보면 막막하던 일이 30분짜리 점검으로 줄어든다. 그리고 그 점검에서 나온 '아니오' 하나하나를 한 줄 메모로 남겨 '오늘·이번 달·올해'로 분류하면, 그게 곧 우리 사이트 개선의 첫 로드맵이 된다.

다만 솔직하게 다시 짚자. 오늘 한 건 '우선 점검'이지 '전수 점검'이 아니다. 큰 구멍은 막았지만, 사람 눈으로는 잡히지 않는 미세한 어긋남과 방대한 양이 남아 있다. 같은 파랑인데 색 코드가 한 끗 다른 것, 간격이 1픽셀 어긋난 것, 수십 페이지에 걸쳐 반복되는 같은 위반 — 이런 건 도구의 몫이다.

그래서 자가 점검을 한 바퀴 돌았다면, 그다음은 도구로 '확정'할 차례다. 우리 ViewCheck는 바로 그 '사람이 놓치는 부분'을 메우려고 만든 진단 서비스다. KRDS 846규칙 — DS 120, CP 446, BP 108, SP 172 — 을 페이지마다 대조해 '어느 카테고리에서, 어떤 규칙을, 어디서 위반했는지'를 점수 카드와 위반 목록으로 한눈에 보여준다. 오늘 손으로 본 우선 항목들이 자동 진단에서는 어떻게 나오는지 비교해보면, 내 점검이 맞았는지 확인하는 재미도 있다. '아, 내가 의심했던 그 버튼이 실제로 CP에서 걸렸구나' 하고.

krds.viewcheck.co.kr에 들어가 우리 기관 주소를 넣으면 무료로 진단을 체험해볼 수 있다. 결재도, 설치도, 회원가입의 부담도 없이 그저 주소 하나 넣고 결과를 받아보면 된다. 오늘 자가 점검에서 '아니오'가 많이 나왔다면, 그건 부끄러운 일이 아니라 '고칠 거리를 그만큼 많이 찾았다'는 뜻이다. 그 발견을 도구로 확정하고, 한 줄 메모를 작업 지시서로 바꿔, 가장 크게 새던 곳부터 차근차근 막아가자. 모든 좋은 사이트는 '지금 어디가 새는지 정직하게 들여다보는 일'에서 시작한다. 오늘 그 첫 바퀴를 돌린 당신은, 이미 그 길에 들어선 거다.

끝으로 한마디만 더. 오늘 점검에서 '아니오'가 유난히 많이 나왔더라도 기죽지 마시길. 그건 우리 사이트가 유독 나쁜 게 아니라, 그동안 '제대로 본 적이 없었던' 것뿐이다. 대부분의 공공 사이트가 똑같은 항목에서 똑같이 걸린다. 규모가 크든 작든, 예산이 많든 적든 비슷하게 나타나는 '전형'들이라, 우리만의 흠이 아니다. 오히려 그 '아니오'를 찾아냈다는 사실 자체가 절반의 성공이다. 보이지 않던 문제가 보이기 시작했다는 뜻이고, 보이는 문제는 고칠 수 있는 문제이기 때문이다. 가장 위험한 건 '아니오'가 많은 사이트가 아니라, '아니오'가 있는데도 그걸 못 보고 '우리는 괜찮다'고 믿는 사이트다.

다음 주에는 이렇게 찾아낸 위반들을 '무엇부터, 어떤 순서로, 누구와 함께' 고쳐갈지 — 개선의 실행 단계를 다뤄보겠다. 오늘은 '무엇이 문제인지 보는 눈'을 길렀으니, 다음엔 '그걸 고치는 손'을 이야기할 차례다. 점검은 시작일 뿐이고, 진짜 가치는 그다음에 나온다. 그날까지, 오늘 적은 '아니오' 메모를 잘 간직해두시길.