7대 영역 자가진단 체크리스트

공감·문제제기

이번 주는 내내 '기준' 이야기를 했다. 월요일엔 KRDS가 도대체 뭔지, 왜 정부가 디자인시스템이라는 걸 만들었는지를 다뤘고, 수요일엔 그 기준을 디자인 영역에서 어떻게 적용하는지를 풀었다. 오늘 금요일은 한 단계 더 위로 올라간다. 디자인만이 아니라, 행정안전부가 「전자정부 웹사이트 품질관리 지침」에서 정한 '7대 품질 영역' 전체를 우리 손으로 한 번 훑어보는 날이다.

먼저 솔직하게 털어놓자. 7대 영역이라는 말을 처음 들으면 대부분 멈칫한다. 호환성, 접근성, 개방성, 접속성, 편의성, 효율성, 신뢰성. 일곱 개나 되는 데다 이름도 다 비슷비슷해서 '접근성이랑 접속성이 뭐가 다른 거지', '편의성이랑 효율성은 또 어떻게 구분하지' 싶어진다. 나도 이 일을 처음 시작했을 때 이 일곱 단어를 외우는 데만 한참 걸렸다. 그래서 오늘 글은 이 일곱 영역을 '외우게' 만들려는 게 아니다. 오히려 외우지 않아도 '아, 이게 그 영역 이야기구나' 하고 몸으로 느낄 수 있게, 담당자가 자기 사이트를 직접 열어 한 항목씩 따라 점검할 수 있는 자가진단 체크리스트로 풀어내려 한다.

분명히 해둘 게 있다. 이 체크리스트는 정밀 진단이 아니다. KRDS 846규칙을 전부 따지고, 7대 영역의 모든 세부 기준을 빠짐없이 검사하는 건 사람이 눈으로 할 수 있는 일이 아니다. 그건 도구의 몫이다. 오늘 우리가 할 일은 '가장 자주 걸리고, 영향이 큰' 핵심만 추려, 비전문가도 5분에서 10분 안에 '우리 사이트가 일곱 영역에서 대충 어디가 약한지' 감을 잡는 것이다. 건강에 빗대면 정밀 검진 전에 스스로 해보는 자가 체크다. '요즘 좀 피곤한데 어디가 문제지' 하고 스스로 몸을 살펴보는 그 가벼운 점검 말이다. 가볍지만, 이 가벼운 점검이 '무엇부터 손봐야 하는가'의 출발점을 잡아준다.

그런데 '왜 디자인 담당자도 아닌 내가 이런 걸 해야 하나' 싶은 분도 있을 거다. 7대 영역이라고 하면 어쩐지 IT 부서나 전문 컨설턴트의 일처럼 느껴지니까. 하지만 공공 사이트의 품질은 어느 한 사람의 책임이 아니다. 콘텐츠를 올리는 담당자, 신청 양식을 기획하는 담당자, 외주를 관리하는 담당자, 보도자료를 게시하는 담당자 — 사이트에 손을 대는 모든 사람이 조금씩 품질을 만든다. 그리고 오늘 체크리스트는 전문 지식 없이도 '쓰는 사람 입장에서 불편한지 아닌지'만 따져보면 답할 수 있게 만들었다. 오히려 전문가가 아니기에 더 잘 보이는 문제도 많다. 매일 그 사이트를 들여다보는 담당자보다, 가끔 들어오는 일반 사용자의 눈이 더 정확할 때가 잦다.

이 점검의 또 다른 매력은 '공짜'라는 점이다. 외부 컨설팅을 부르거나 유료 도구를 사기 전에, 지금 당장 5분이면 시작할 수 있다. 돈도 안 들고, 결재도 필요 없고, 누구의 허락도 필요 없다. 그저 우리 사이트를 사용자의 눈으로 일곱 가지 관점에서 한 바퀴 돌아보는 것뿐이다. 이 작은 시작이 '우리 사이트를 제대로 보기'의 첫걸음이 된다. 거창한 개편 계획을 세우기 전에, 먼저 '지금 어떤 상태인지' 아는 것 — 모든 개선은 거기서 출발한다. 개편 예산을 따내려 해도, 결국 '지금 우리가 어디가 부족한지'를 구체적으로 말할 수 있어야 한다. 오늘 체크리스트는 바로 그 '구체적으로 말할 수 있는 근거'를 손에 쥐여준다.

준비물은 단출하다. 우리 기관 사이트, 노트북이나 데스크탑 한 대, 그리고 스마트폰 하나. 데스크탑과 모바일을 둘 다 봐야 하니 둘 다 켜두면 좋다. 펜과 종이(혹은 메모 앱)에 영역마다 '예/아니오'를 적어가며 따라오면 된다. 그리고 마음가짐 하나만 다잡자. 이건 시험이 아니라 건강검진이다. 시험은 좋은 점수를 받는 게 목적이지만, 검진은 '어디가 안 좋은지 찾아내는 것'이 목적이다. 그러니 '아니오'가 많이 나올수록 점검이 잘된 거다. 문제를 많이 찾았다는 건 고칠 거리를 많이 확보했다는 뜻이고, 곧 사이트가 좋아질 여지가 그만큼 크다는 뜻이니까. 반대로 모든 항목에 '예'를 적고 있다면, 점검이 잘된 게 아니라 너무 후하게 보고 있는 건 아닌지 의심해야 한다. 좋은 점검자는 자기 사이트에 엄격하다. 이 글을 따라오는 동안만큼은, 우리 사이트를 '처음 온 까다로운 사용자'의 눈으로 봐주길 바란다.

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

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

7대 영역이라는 '일곱 개의 기둥'

■ 7대 영역이 왜 '일곱 개'여야 했나

행정안전부가 「전자정부 웹사이트 품질관리 지침」에서 일곱 개의 영역을 정한 데는 이유가 있다. 좋은 공공 웹사이트라는 건 막연한 '잘 만든 사이트'가 아니라, 서로 다른 일곱 가지 약속을 동시에 지키는 사이트라는 뜻이다. 이 일곱 가지는 어느 하나라도 빠지면 사용자가 '제대로 쓸 수 없게' 된다.

쉬운 비유로 시작하자. 공공 웹사이트를 '동사무소 건물'이라고 생각해보자. 호환성은 '어떤 방향에서 들어와도 문이 열리는가'이다. 정문으로 오든 후문으로 오든, 다른 브라우저로 접속하든 같은 건물이 보여야 한다. 접근성은 '휠체어를 탄 사람도, 눈이 안 보이는 사람도 들어올 수 있는가'이다. 경사로와 점자 안내가 있어야 한다. 개방성은 '이 건물에 무슨 부서가 있는지 밖에서도 알 수 있는가'이다. 안내판이 정직하게 붙어 있어야 길 찾는 사람이 헤매지 않는다. 접속성은 '건물이 항상 열려 있고, 들어가는 데 오래 걸리지 않는가'이다. 문 앞에서 30분씩 기다리게 하면 안 된다. 편의성은 '안에서 일을 보기가 편한가'이다. 화장실은 어디 있고 민원 창구는 어디 있는지가 분명해야 한다. 효율성은 '사람이 몰려도 빠르게 처리되는가'이다. 좁은 통로 하나로 모든 사람을 밀어 넣으면 병목이 생긴다. 신뢰성은 '이 건물이 안전하고 믿을 만한가'이다. 민원인의 개인정보가 새지 않고, 위조 안내문이 붙지 않아야 한다.

이렇게 풀어놓으면 일곱 영역이 더는 비슷비슷한 단어가 아니라, 저마다 다른 질문을 던지는 기둥으로 보인다. 그리고 이 일곱 기둥은 '하나가 무너지면 다른 기둥이 멀쩡해도 건물 전체가 위태로워진다'는 점에서 동등하다. 아무리 화면이 예쁘고(편의성) 빠르게 떠도(효율성), 보안이 뚫려 개인정보가 새면(신뢰성) 그 사이트는 쓸 수 없다. 반대로 보안이 철벽이라도(신뢰성) 휠체어 사용자가 신청을 못 하면(접근성) 그건 공공 서비스의 자격을 잃은 것이다. 그래서 7대 영역은 '우선순위 줄 세우기'가 아니라 '일곱 개를 동시에' 보라는 요구다.

이 '동시에'라는 말이 처음엔 막막하게 들린다. 한 번에 일곱 가지를 신경 쓰라니, 가뜩이나 일손도 모자란데 어떻게 하라는 건가 싶다. 하지만 조금 더 들여다보면, 이 일곱 영역은 서로 완전히 따로 노는 게 아니라 묶음으로 움직인다는 걸 알게 된다. 호환성과 접속성은 '열림'이라는 한 묶음으로 함께 다닌다. 어느 브라우저에서든 빠르게 열리는 사이트는 이 둘을 같이 챙긴 것이다. 접근성과 편의성은 '쓰임'이라는 묶음이다. 키보드로도 쓸 수 있고 흐름이 친절한 사이트는 이 둘을 함께 만족시킨다. 개방성과 신뢰성은 '정직'이라는 묶음으로 묶인다. 무슨 사이트인지 밖에서도 알 수 있고, 다루는 정보가 안전한 사이트는 사용자에게 '이곳은 믿어도 되는 곳'이라는 같은 인상을 준다. 효율성은 이 모든 묶음을 '가볍게' 떠받치는 바닥이다. 이렇게 묶어서 보면, 일곱 개를 따로따로 외우는 게 아니라 '열림·쓰임·정직, 그리고 그걸 가볍게 받치는 효율' 정도로 큰 덩어리를 잡을 수 있다. 점검할 때도 이 덩어리 감각이 있으면, 한 영역에서 발견한 문제가 옆 영역과 어떻게 연결되는지가 자연스럽게 보인다.

또 하나 강조하고 싶은 건, 이 일곱 영역이 '완벽'을 요구하는 게 아니라는 점이다. 처음 점검을 해보면 거의 모든 영역에서 크고 작은 '아니오'가 나온다. 그걸 보고 '우리 사이트는 엉망이구나' 하고 낙담할 필요가 전혀 없다. 어떤 사이트도 일곱 영역에서 만점을 받지 못한다. 잘 만든 사이트라고 '아니오'가 안 나오는 게 아니라, '덜 나오고, 나온 것을 빨리 고치는' 정도의 차이일 뿐이다. 그러니 목표는 '일곱 영역 만점'이 아니라 '일곱 영역에서 가장 약한 곳을 알아내고, 그곳부터 조금씩 단단하게 만드는 것'이다. 이 마음가짐을 가지고 점검에 임하면, '아니오' 하나하나가 부끄러움이 아니라 '다음에 할 일'의 목록으로 보이기 시작한다.

여기서 한 가지 오해를 풀고 가자. 많은 담당자가 '우리는 디자인(KRDS)만 신경 쓰면 되는 거 아니냐'고 생각한다. 하지만 KRDS 846규칙은 7대 영역과 별개의 무언가가 아니라, 그 안에서 '접근성·편의성'을 디자인으로 구현하는 구체적인 약속들이다. DS 120(디자인 기초), CP 446(부품), BP 108(기본 패턴), SP 172(서비스 패턴)로 이루어진 846규칙은 사용자가 사이트를 '쓰는 경험'을 촘촘하게 다듬는 도구다. 7대 영역이 '무엇을 지켜야 하는가'라는 큰 약속이라면, KRDS 846규칙은 '그걸 화면에서 어떻게 지키는가'라는 실행 설명서인 셈이다. 그래서 오늘 체크리스트도 7대 영역을 따라가되, 그 안에서 KRDS가 다루는 디자인·부품·흐름이 자연스럽게 함께 등장한다.

■ 체크리스트는 어떻게 구성했나

오늘 체크리스트는 7대 영역을 그대로 일곱 묶음으로 나눴다. 각 묶음에서 핵심 질문 두세 개씩만 던진다. 전부 '예/아니오'로 답할 수 있게 만들었고, 전문 도구 없이 눈과 손, 키보드만으로 확인할 수 있는 것들만 골랐다.

· 1. 호환성: 어디서 열어도 같은가

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

· 3. 개방성: 안내가 정직한가

· 4. 접속성: 빠르고 끊김 없이 열리나

· 5. 편의성: 쓰기에 편한가

· 6. 효율성: 무겁지 않고 빠른가

· 7. 신뢰성: 믿고 맡길 수 있나

왜 이 순서일까. 사용자가 사이트를 만나는 순서를 따랐다. 일단 '열려야'(호환성·접속성) 하고, 누구나 '들어올 수 있어야'(접근성) 하고, '무슨 사이트인지 알 수 있어야'(개방성) 하고, 그 안에서 '쓰기 편하고'(편의성) '빠르게 처리되며'(효율성), 끝으로 '믿고 맡길 수 있어야'(신뢰성) 한다. 이 순서대로 점검하면 사용자가 사이트를 한 바퀴 도는 여정을 그대로 따라가게 된다. 어느 단계에서 막히는지를 '사용자가 겪는 순서대로' 발견할 수 있다는 뜻이다.

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

그리고 일곱 묶음을 '순서대로' 보는 걸 권한다. 마음 가는 대로 건너뛰며 보면, 분명 어떤 영역은 통째로 빼먹게 된다. 특히 개방성(3)과 효율성(6), 신뢰성(7)은 눈에 잘 안 띄어서 자꾸 뒤로 밀리는데, 정작 행정안전부 품질 평가에서 점수가 크게 갈리는 영역이 바로 그 셋일 때가 많다. 그러니 1번부터 7번까지 차례대로, 각 묶음을 다 끝내고 다음으로 넘어가는 식으로 진행하라. 자, 하나씩 가보자.

영역별 자가진단 항목

여기서부터는 일곱 영역을 하나씩 점검한다. 각 항목 옆에는 '자주 보이는 문제'를 익명으로 곁들였다. 우리 사이트와 비교하며 읽으면 체감이 빠르다. 곁들인 사례는 전부 익명 처리한 것이다. 특정 기관을 흉보려는 게 아니라, 어디서나 반복되는 '전형'을 보여주려는 거다. 규모가 크든 작든, 예산이 많든 적든 거의 똑같이 나타나는 패턴들이라, 읽다가 '우리도 저런데' 싶은 게 나와도 자책할 필요는 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다. 중요한 건 그 패턴을 알아보는 눈을 갖추는 것이다.

각 묶음을 볼 때는 '예/아니오'만 적지 말고, '아니오' 옆에 한 줄짜리 메모를 남기길 권한다. 이를테면 '2-3 아니오 — 본문 이미지 alt가 전부 비어 있음'처럼. 이 한 줄이 나중에 '무엇을 고쳐야 하는지'를 정확히 짚어주는 작업 지시서가 된다. 점검만 하고 무엇이 문제였는지 적어두지 않으면, 며칠만 지나도 '분명 아니오가 많았는데 뭐였더라'가 된다. 점검의 가치는 '발견'이 아니라 '기록'에서 완성된다.

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

■ 1. 호환성 — 어디서 열어도 같은가

1-1. 평소 안 쓰던 다른 브라우저로 메인 페이지를 열었을 때, 화면이 깨지지 않고 똑같이 보이는가?

→ 자주 보이는 문제: 특정 브라우저에서만 메뉴가 겹치거나 버튼이 사라진다. 한 브라우저에서만 테스트하고 배포한 흔적이다.

1-2. 화면 글자 크기를 키우거나(브라우저 확대 150~200%) 창을 좁게 줄여도 내용이 잘리지 않고 읽히는가?

→ 자주 보이는 문제: 확대하면 글자가 서로 겹치거나, 가로 스크롤이 생겨 글을 읽으려고 좌우로 끌어야 한다.

1-3. 오래된 환경(낮은 해상도, 구형 기기)에서도 핵심 기능(검색·신청)이 작동하는가?

→ 자주 보이는 문제: 최신 환경만 가정해 만들어, 구형 기기에서는 버튼이 눌리지 않거나 화면이 멈춘다.

호환성은 '우리가 만든 화면이 우리 모니터에서만 멀쩡한 게 아니라, 사용자의 천차만별인 환경에서도 똑같이 작동하는가'를 묻는다. 점검은 단순하다. 평소 쓰던 브라우저 말고 다른 브라우저 한두 개를 열어 같은 페이지를 나란히 띄워보면 된다. 메뉴 위치, 버튼 모양, 글자 줄바꿈이 '거의 같으면' 통과고, 한쪽만 어딘가 어긋나 있으면 호환성에 구멍이 있는 거다. 호환성 문제는 '우리 눈에만 안 보인다'는 게 특히 까다롭다. 담당자는 늘 같은 환경에서 보니 멀쩡해 보이지만, 다른 브라우저를 쓰는 사용자에게는 '깨진 사이트'로 보인다. 행정안전부 지침에서 호환성을 여러 브라우저로 따지는 이유가 여기 있다. 공공 서비스는 '특정 브라우저를 쓰는 사람만' 위한 게 아니어야 하니까.

호환성 점검에서 의외로 많이 놓치는 게 '글자 확대'다. 시력이 약한 사용자는 화면을 키워서 본다. 그런데 화면을 키웠을 때 레이아웃이 무너지면, 그 사용자는 콘텐츠를 제대로 읽을 수 없다. 브라우저 확대 단축키로 150%, 200%까지 키워보며 글이 겹치지 않는지, 가로 스크롤이 생기지 않는지 확인하는 것만으로도 호환성의 상당 부분을 점검할 수 있다. 이건 다음에 나올 접근성과도 맞닿아 있다. 7대 영역은 이렇게 서로 손을 잡고 있다.

호환성을 '담당자의 환경'이 아니라 '사용자의 환경'으로 봐야 하는 이유를 한 번 더 짚자. 사이트를 만드는 사람은 대개 성능 좋은 컴퓨터, 큰 모니터, 최신 브라우저를 쓴다. 그래서 '우리 화면에서 잘 되니까 괜찮다'고 자신하기 쉽다. 하지만 공공 사이트의 실제 사용자는 그렇지 않다. 몇 년 된 스마트폰을 쓰는 어르신, 관공서의 오래된 공용 컴퓨터로 접속하는 사람, 인터넷이 느린 지역의 주민 — 이 다양한 환경 모두에서 '똑같이' 작동해야 진짜 호환성이다. 그래서 호환성 점검은 '내가 쓰는 가장 좋은 환경'이 아니라, '내가 상상할 수 있는 가장 열악한 환경'을 기준으로 보는 게 옳다. 가능하다면 회의실의 낡은 노트북이나 오래된 태블릿을 빌려, 그 화면에서 우리 사이트의 핵심 기능을 한 번 돌려보라. 평소 안 보이던 호환성 구멍이 그제야 드러난다.

■ 2. 접근성 — 모두가 쓸 수 있나

2-1. 마우스를 떼고 키보드 Tab 키만으로 메뉴·버튼·링크를 차례로 옮겨 다닐 수 있고, 지금 어디에 있는지 '선택 표시(초점 테두리)'가 보이는가?

→ 자주 보이는 문제: 초점 표시가 없어 키보드 사용자가 길을 잃거나, 특정 메뉴는 마우스로만 눌린다.

2-2. 의미 있는 이미지에 대체텍스트(alt)가 붙어 있는가?

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

2-3. 글자색과 배경색의 대비가 충분해, 흐린 회색 글씨가 잘 읽히는가?

→ 자주 보이는 문제: 연한 회색 본문, 옅은 색 버튼 글자가 밝은 곳에서나 노안 사용자에게 거의 안 보인다.

접근성은 '일부 사용자가 아니라 모두가 이 서비스를 쓸 수 있는가'를 묻는다. 공공 서비스에서 가장 양보할 수 없는 영역이다. 행정안전부 지침과 웹접근성 KWCAG 33항목이 가장 촘촘하게 다루는 곳이기도 하다. 점검의 핵심 도구는 '마우스를 손에서 떼는 것'이다. Tab 키만으로 페이지를 처음부터 끝까지 돌아다녀 보라. 초점이 어디로 가는지 눈에 보이는지, 그 순서가 위에서 아래로·왼쪽에서 오른쪽으로 자연스러운지, 버튼이 엔터로 눌리는지를 확인하면, 마우스로는 멀쩡해 보이던 사이트의 허점이 줄줄이 나온다. 어떤 기능이 '마우스로만' 되고 키보드로는 안 된다면, 그 기능은 키보드를 쓰는 사용자에게는 '없는 기능'이나 마찬가지다.

대체텍스트(alt)는 눈으로 화면을 못 보는 사용자에게 그림을 '읽어주는' 글이다. 이게 비어 있으면, 화면 낭독기를 쓰는 사용자에게 그 이미지는 통째로 사라진다. 중요한 안내가 이미지 한 장에 담겨 있는데 alt가 없다면, 그 사용자는 그 안내를 영영 못 받는 셈이다. 점검 방법은 의외로 쉽다. 본문의 의미 있는 이미지 몇 개에 마우스를 올려보거나, 페이지의 이미지 정보를 확인해 alt가 '그 이미지가 무슨 뜻인지'를 담고 있는지 보면 된다. 단순 장식 이미지는 비어 있어도 되지만, 정보를 담은 이미지는 반드시 그 정보를 글로 옮겨두어야 한다.

색 대비는 '젊고 눈 좋은 담당자 모니터에서는 잘 보이지만, 노안이거나 색을 구분하기 어려운 사용자, 햇빛 아래 스마트폰을 보는 사용자에게는 안 보이는' 함정이다. 연한 회색 글씨가 멋있어 보여서 쓰는 경우가 많은데, 멋과 가독성이 충돌할 땐 가독성이 이겨야 한다. 공공 서비스는 디자인 작품이 아니라 '모두가 읽어야 하는 안내문'이기 때문이다. 이 세 항목 중 '아니오'가 하나라도 나왔다면, 접근성은 단순 권장이 아니라 법적·제도적 의무 영역이라는 점에서 우선순위를 높여 다뤄야 한다.

접근성을 이야기할 때 빼놓을 수 없는 게 웹접근성 KWCAG 33항목이다. 이름이 어려워 보이지만, 핵심은 '장애가 있는 사용자도, 나이 든 사용자도, 일시적으로 불편한 상황에 놓인 사용자도 똑같이 서비스를 쓸 수 있게 하라'는 약속이다. 여기서 '일시적으로 불편한 상황'이라는 말이 중요하다. 접근성은 '장애인만을 위한 것'이라고 오해하기 쉽지만, 사실은 모두를 위한 것이다. 팔을 다쳐 한 손만 쓸 수 있는 사람, 시끄러운 곳에서 소리를 못 듣는 사람, 햇빛 아래라 화면이 잘 안 보이는 사람, 데이터가 느려 이미지가 안 뜨는 사람 — 누구나 어느 순간 '일시적 장애' 상황에 놓인다. 그때 키보드만으로도 쓸 수 있고, 이미지가 안 떠도 대체텍스트로 내용을 알 수 있고, 글자 대비가 충분해 어디서든 읽히는 사이트는, 그 모든 사람을 끝까지 붙잡아준다. 그래서 접근성에 투자한 노력은 '소수'가 아니라 '결국 모두'에게 돌아온다. 점검에서 접근성 항목에 '아니오'가 나왔다면, 그건 '일부 사용자를 배제하고 있다'는 뜻이고, 공공 서비스에서 배제는 곧 차별이 된다는 점을 무겁게 받아들여야 한다.

■ 3. 개방성 — 안내가 정직한가

3-1. 검색 엔진에서 우리 기관을 검색했을 때, 제목과 설명이 '이 사이트가 뭘 하는 곳인지' 제대로 보이는가?

→ 자주 보이는 문제: 검색 결과 제목이 '무제 문서'거나, 설명이 비어 있어 무슨 사이트인지 알 수 없다.

3-2. 페이지마다 제목(브라우저 탭에 뜨는 글)이 그 페이지 내용에 맞게 서로 다르게 붙어 있는가?

→ 자주 보이는 문제: 모든 페이지 제목이 기관명 하나로 똑같아, 탭을 여러 개 열면 어느 게 어느 페이지인지 구분이 안 된다.

3-3. 메뉴 구조가 직관적이어서, 처음 온 사람도 '원하는 정보가 어느 메뉴 아래 있을지' 짐작할 수 있는가?

→ 자주 보이는 문제: 부서 조직도를 그대로 메뉴로 옮겨, 사용자가 '내 일이 어느 부서 소관인지' 알아야만 찾을 수 있다.

개방성은 '이 사이트가 무엇을 하는 곳인지, 안에 무슨 정보가 있는지를 밖에서도 정직하게 알 수 있는가'를 묻는다. 사용자가 사이트에 들어오기도 전에, 검색 엔진을 통해 만나는 첫인상이 여기서 갈린다. 점검은 직접 검색해보는 것으로 시작한다. 검색창에 기관명을 넣어 우리 사이트가 어떻게 나오는지 보라. 제목과 설명이 '여기는 OO 업무를 보는 곳입니다'라고 또렷이 알려주면 통과고, 제목이 비어 있거나 설명이 엉뚱하면 개방성에 구멍이 있는 거다. 이건 단순한 검색 노출 문제가 아니다. 정보가 '있어도 못 찾는' 사이트는 '정보가 없는' 사이트와 다를 바 없다.

페이지 제목이 서로 다른지를 보는 것도 개방성의 핵심이다. 각 페이지가 자기 내용에 맞는 제목을 갖고 있으면, 검색 결과에서도, 즐겨찾기에서도, 여러 탭을 열었을 때도 사용자가 길을 잃지 않는다. 반대로 모든 페이지가 같은 제목이면, 사용자는 매번 '이게 그 페이지였나' 하고 헤맨다. 메뉴 구조도 마찬가지다. 사용자가 '내 일' 중심으로 찾을 수 있게 짜였는지, 아니면 '우리 조직' 중심으로 짜여 사용자에게 부서 지식을 강요하는지를 보라. 좋은 개방성은 '사용자가 우리를 공부하지 않아도 원하는 걸 찾게' 하는 것이다.

개방성을 '정보의 정직함'이라는 관점에서 한 번 더 보자. 공공 사이트의 존재 이유는 결국 '정보를 잘 전달하는 것'이다. 그런데 아무리 좋은 정보를 많이 올려놔도, 그 정보가 '찾을 수 있는 형태'로 정리돼 있지 않으면 없는 것과 같다. 검색에 안 잡히고, 제목이 엉성하고, 메뉴가 조직도를 그대로 옮긴 사이트는 '정보를 숨겨둔 사이트'나 다름없다. 숨길 의도는 없었더라도, 사용자 입장에서는 '아무리 찾아도 안 나오니 없는 거나 마찬가지'가 된다. 그래서 개방성 점검에서 '아니오'가 나왔다면, 그건 단순한 검색 노출의 문제가 아니라 '우리가 가진 정보를 사용자에게 제대로 열어주지 못하고 있다'는, 공공 서비스의 본질에 닿는 경고로 받아들여야 한다. 정보를 만드는 것만큼이나 '찾을 수 있게 정리하는 것'도 우리의 일이다.

■ 4. 접속성 — 빠르고 끊김 없이 열리나

4-1. 주소창에 기관 도메인을 입력했을 때, 자물쇠 표시(https)와 함께 안전하게 연결되는가?

→ 자주 보이는 문제: '안전하지 않음' 경고가 뜨거나, 보안 연결이 안 돼 브라우저가 접속을 막는다.

4-2. 메인 페이지가 '기다림이 느껴지지 않을 만큼' 빠르게 뜨는가? (대략 몇 초 안에 핵심 내용이 보이는가)

→ 자주 보이는 문제: 첫 화면이 한참 비어 있다가 뒤늦게 떠, 사용자가 '안 되나' 싶어 새로고침하거나 떠난다.

4-3. 특정 시간대(점심·마감일)에 접속해도 '서버 응답 없음' 없이 안정적으로 열리는가?

→ 자주 보이는 문제: 신청 마감일에 사람이 몰리면 사이트가 느려지거나 멈춘다.

접속성은 '사이트가 항상 열려 있고, 들어가는 데 오래 걸리지 않는가'를 묻는다. 아무리 좋은 콘텐츠도 '안 열리면' 없는 것과 같다. 첫 점검 항목은 보안 연결 여부다. 주소창에 자물쇠가 떠 있고 '안전하지 않음' 경고가 없는지 확인하라. 이건 접속성이면서 동시에 뒤에 나올 신뢰성과도 직결된다. 보안 연결이 안 되면 브라우저가 아예 접속을 경고하거나 막아버려, 사용자가 들어오기도 전에 등을 돌린다.

속도 점검은 '체감'으로 한다. 메인 페이지를 새로 열었을 때 '기다림'이 느껴지는지를 보라. 화면이 한참 비어 있다가 뒤늦게 떠오르면, 사용자는 '이거 안 되나' 싶어 새로고침을 누르거나 떠난다. 사람은 생각보다 참을성이 없다. 첫 화면이 느리게 뜨는 사이트는 '콘텐츠를 보여주기도 전에' 사용자를 잃는다. 그리고 특정 시간대에 사람이 몰릴 때를 떠올려보라. 신청 마감일, 발표일, 점심시간처럼 트래픽이 몰리는 순간에 사이트가 버텨주는가. 평소엔 멀쩡하다가 정작 '가장 많은 사람이 필요로 하는 순간'에 멈추는 사이트는, 접속성에서 가장 중요한 시험을 통과하지 못한 것이다.

속도 점검에서 한 가지 더 봐야 할 건 '모바일에서의 속도'다. 데스크탑은 보통 빠른 유선 인터넷에 물려 있어 웬만한 사이트가 다 빨리 뜬다. 하지만 모바일은 다르다. 지하철 안, 건물 지하, 외곽 지역처럼 신호가 약한 곳에서 접속하면, 데스크탑에서 1초에 뜨던 페이지가 모바일에선 10초가 걸리기도 한다. 그러니 속도는 '좋은 와이파이가 잡힌 사무실'이 아니라, '이동 중 약한 신호'를 기준으로 가늠하는 게 현실적이다. 가능하면 와이파이를 끄고 데이터로만, 그것도 신호가 약한 곳에서 우리 사이트를 한 번 열어보라. 그 '가장 답답한 환경'에서도 핵심 정보가 쓸 만한 시간 안에 뜬다면, 접속성은 합격이다. 반대로 그때 한참 기다리게 된다면, 그게 바로 우리 사용자의 상당수가 매일 겪는 현실이라는 걸 기억하자.

■ 5. 편의성 — 쓰기에 편한가

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

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

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

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

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

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

5-4. 같은 동작을 하는 버튼이 페이지마다 같은 말과 같은 모양을 쓰는가?

→ 자주 보이는 문제: '신청', '접수', '제출하기'가 뒤섞여, 사용자가 '이게 같은 건가' 헷갈린다.

편의성은 '사용자가 목적을 이루느냐 마느냐'를 가르는 영역이라, 여기서의 '아니오'는 곧 서비스 실패로 이어진다. KRDS의 기본 패턴(BP 108)과 서비스 패턴(SP 172)이 가장 깊게 관여하는 곳이기도 하다. 편의성 점검은 '일부러 틀려보기'가 가장 효과적이다. 필수 칸을 비워두고 제출을 눌러보고, 형식에 안 맞는 값(전화번호 칸에 한글)을 넣어보고, 신청 중간에 뒤로 가기를 눌러본다. 이렇게 일부러 어긋나게 행동했을 때 사이트가 어떻게 대응하는지를 보면 흐름의 완성도가 그대로 드러난다. 친절한 사이트는 '무엇이 왜 틀렸고 어떻게 고치라'를 그 칸 바로 옆에서 알려주고, 뒤로 가도 적던 내용을 지켜준다. 불친절한 사이트는 '오류가 발생했습니다' 한 줄만 띄우거나, 처음부터 다시 적게 만든다.

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

시간이 없다면 편의성만큼은 '우리 사이트에서 사람들이 가장 많이 하는 일' 한두 개를 골라 처음부터 끝까지 직접 따라가 보길 권한다. 민원 신청이 가장 많은 기관이라면 그 신청 흐름을, 자료 검색이 잦은 곳이라면 검색 흐름을, 예약·접수가 핵심인 곳이라면 그 과정을 '진짜 사용자처럼' 밟아본다. 가장 많이 쓰는 흐름 하나가 매끄러우면 사용자 대다수가 만족하고, 그 하나가 막히면 가장 많은 사람이 좌절한다. 그래서 편의성 점검은 '넓게 조금씩'보다 '핵심을 깊게'가 원칙이다.

■ 6. 효율성 — 무겁지 않고 빠른가

6-1. 페이지에 큰 이미지나 동영상이 잔뜩 얹혀 있어 모바일 데이터로 열면 느리지 않은가?

→ 자주 보이는 문제: 최적화 안 된 고해상도 이미지가 수십 장 올라가, 모바일에서 한참 로딩된다.

6-2. 모바일에서 한 손으로 쓸 때, 버튼이 손가락으로 누르기 충분히 큰가? (작은 링크가 다닥다닥 붙어 있지 않은가)

→ 자주 보이는 문제: 데스크탑 기준으로 만든 작은 버튼이 모바일에서 그대로 줄어, 옆 버튼을 잘못 누른다.

6-3. 불필요하게 무거운 요소(자동 재생 영상, 과한 팝업) 없이 핵심 콘텐츠가 먼저 보이는가?

→ 자주 보이는 문제: 들어가자마자 팝업 서너 개가 화면을 덮어, 정작 보러 온 내용을 찾을 수 없다.

효율성은 '같은 일을 더 가볍고 빠르게 해내는가'를 묻는다. 접속성이 '열리느냐'의 문제라면, 효율성은 '얼마나 매끄럽게 도느냐'의 문제다. 특히 모바일에서 두드러진다. 요즘 공공 사이트 방문자의 절반 이상이 모바일로 들어온다. 그런데 많은 사이트가 여전히 '데스크탑에서 만들고 모바일은 대충' 맞춘다. 점검은 반드시 스마트폰을 손에 들고 한다. 데스크탑에서 멀쩡하던 화면이 모바일에서는 글자가 깨지거나, 버튼이 너무 작아 누르기 힘들거나, 이미지가 화면을 넘어가는 일이 흔하다.

버튼 크기는 효율성에서 특히 중요하다. 손가락은 마우스 포인터보다 훨씬 뭉툭하다. 작은 링크들이 다닥다닥 붙어 있으면, 사용자는 자꾸 옆 것을 잘못 누른다. 화면을 키워 누르거나 여러 번 시도하게 되는데, 그 과정 하나하나가 '이 사이트는 불편하다'는 인상을 쌓는다. 충분히 큰 버튼, 손가락 하나가 편하게 닿는 간격 — 이것이 모바일 효율성의 기본이다. 그리고 '무게'도 점검하라. 들어가자마자 팝업 여러 개가 뜨거나, 자동 재생 영상이 데이터를 잡아먹거나, 최적화 안 된 큰 이미지가 줄줄이 얹혀 있으면, 사용자는 '보러 온 것'에 도달하기도 전에 지친다. 효율성은 '더 넣는 것'이 아니라 '덜어내는 것'으로 좋아질 때가 더 많다.

효율성이 '덜어내기'의 영역이라는 말을 조금 더 풀어보자. 사이트를 운영하다 보면 자꾸 무언가를 '더하고' 싶어진다. 새 배너, 새 팝업, 새 위젯, 화려한 슬라이드. 윗선에서 '이것도 메인에 띄워달라'는 요청이 들어오면 거절하기 어렵다. 그렇게 하나둘 얹히다 보면, 어느새 메인 페이지가 온갖 요소로 빽빽해진다. 그런데 사용자 입장에서 이건 '풍성함'이 아니라 '소음'이다. 정작 보러 온 핵심 정보가 그 소음에 묻혀버린다. 효율성 점검은 그래서 '우리 사이트가 사용자에게 던지는 정보의 양이 적당한가'를 묻는 일이기도 하다. 메인 페이지를 처음 보는 사람 입장에서, '이 사이트에서 가장 중요한 게 무엇인지'가 3초 안에 눈에 들어오는가. 만약 무엇부터 봐야 할지 한참 두리번거리게 된다면, 그건 무게의 문제이자 효율성의 '아니오'다. 잘 비운 화면이 잘 채운 화면보다 사용자를 더 빨리 목적지로 데려다준다.

■ 7. 신뢰성 — 믿고 맡길 수 있나

7-1. 개인정보처리방침과 이용약관 링크가 화면 아래쪽 등에 분명히 보이고, 눌렀을 때 제대로 열리는가?

→ 자주 보이는 문제: 링크는 있는데 눌러도 빈 페이지가 뜨거나, 방침이 몇 년째 옛날 내용 그대로다.

7-2. 신청·로그인처럼 개인정보를 다루는 화면이 안전한 연결(자물쇠 https)에서 이뤄지는가?

→ 자주 보이는 문제: 메인은 보안 연결인데 정작 개인정보를 입력하는 신청 페이지가 보안 연결이 아니다.

7-3. 공지·안내 글에 작성·수정 날짜가 적혀 있어 '이게 최신 정보인지' 확인할 수 있는가?

→ 자주 보이는 문제: 날짜가 없어, 사용자가 '이 안내가 지금도 유효한지' 알 수 없다.

신뢰성은 '이 사이트가 안전하고 믿을 만한가'를 묻는, 7대 영역의 마지막 기둥이다. 공공 서비스에서 신뢰가 무너지면 다른 모든 게 무의미해진다. 점검의 첫 항목은 개인정보처리방침과 이용약관이다. 단순히 링크가 '있는지'만이 아니라, 눌렀을 때 '제대로 열리고, 내용이 최신인지'까지 봐야 한다. 의외로 많은 사이트가 링크는 걸어두고 정작 내용은 몇 년째 갱신을 안 한다. 이건 '형식만 갖추고 책임은 비워둔' 상태다.

가장 신경 써야 할 건 '개인정보를 다루는 화면의 보안 연결'이다. 메인 페이지는 보안 연결인데 정작 로그인·신청처럼 민감한 정보를 입력하는 페이지가 보안 연결이 아닌 경우가 종종 있다. 이건 '현관문은 잠가두고 금고 문은 열어둔' 격이다. 신청 페이지, 로그인 페이지에 들어가 주소창의 자물쇠를 반드시 확인하라. 끝으로 '날짜 표기'를 본다. 공지와 안내에 작성·수정 날짜가 적혀 있으면, 사용자는 그 정보가 지금도 유효한지 스스로 판단할 수 있다. 날짜 하나가 '이 안내를 믿어도 되는가'를 결정한다. 신뢰성은 거창한 보안 기술만의 문제가 아니라, 이렇게 '정직한 표기'와 '일관된 보안'이라는 작은 약속들이 쌓여 만들어진다.

신뢰성을 마지막 기둥으로 둔 데는 이유가 있다. 앞의 여섯 영역을 아무리 잘 갖춰도, 신뢰가 한 번 무너지면 그 모든 노력이 물거품이 되기 때문이다. 사용자가 신청 페이지에서 '이거 안전한 거 맞아?' 하고 한 번 의심하는 순간, 빠른 속도도 친절한 흐름도 의미를 잃는다. 특히 공공 사이트는 주민등록번호, 주소, 연락처 같은 민감한 정보를 다룬다. 그래서 신뢰성의 '아니오'는 다른 어떤 영역의 '아니오'보다 무겁다. 그리고 신뢰는 '한 번 잘했다'로 쌓이는 게 아니라 '늘 한결같이 잘한다'로 쌓인다. 어느 페이지는 보안 연결이고 어느 페이지는 아니라면, 사용자는 '이 기관은 들쭉날쭉하다'고 느낀다. 모든 페이지가 일관되게 안전하고, 모든 안내가 정직하게 날짜를 달고 있을 때, 비로소 사용자는 마음을 놓고 우리에게 자기 정보를 맡긴다. 신뢰성 점검은 곧 '우리가 사용자의 정보를 맡을 자격이 있는가'를 스스로 묻는 일이다.

점검 결과를 '일'로 바꾸는 법

■ 채점이 아니라 '지도 그리기'다

자, 일곱 영역을 다 돌았다면 손에 '예/아니오'가 적힌 종이 한 장이 남았을 거다. 여기서 흔히 하는 실수가 '몇 점이지?' 하고 점수부터 매기려는 것이다. 하지만 자가 체크의 목적은 점수가 아니다. '우리 사이트의 어디가 강하고 어디가 약한지'를 보여주는 지도를 그리는 거다. 일곱 영역 중 '아니오'가 몰린 영역이 곧 '가장 먼저 손봐야 할 곳'이다.

예를 들어 호환성과 접속성은 대부분 '예'인데 편의성과 접근성에서 '아니오'가 쏟아졌다면, 우리 사이트는 '열리긴 잘 열리는데 정작 쓰기가 불편한' 상태다. 이런 사이트는 사용자가 들어오긴 하는데 목적을 못 이루고 떠난다. 반대로 편의성은 좋은데 접근성에서 '아니오'가 많다면, '대부분의 사용자에겐 편한데 일부 사용자는 아예 못 쓰는' 상태다. 이렇게 '아니오의 분포'를 보면, 우리 사이트가 어떤 성격의 약점을 가졌는지가 한눈에 드러난다. 점수 하나로는 절대 알 수 없는 정보다.

이 '지도'를 그릴 때 한 가지 더 권하고 싶은 건, 각 영역의 '아니오' 옆에 적어둔 한 줄 메모를 다시 읽어보는 것이다. 메모들을 죽 늘어놓으면, 흩어져 보이던 문제들 사이에서 '반복되는 패턴'이 보일 때가 많다. 이를테면 접근성에서 '초점 표시 없음', 편의성에서 '버튼 글자 제각각', 호환성에서 '확대하면 깨짐'이 한꺼번에 나왔다면, 이건 따로 노는 세 문제가 아니라 '우리 사이트가 처음부터 일관된 기준 없이 페이지마다 따로 만들어졌다'는 하나의 뿌리에서 자란 가지들일 가능성이 높다. 그렇다면 개별 증상을 하나씩 고치는 것보다, 그 뿌리 — 즉 '공유된 기준의 부재' — 를 먼저 손대는 게 효율적이다. 이게 바로 월요일과 수요일에 다룬 디자인시스템, 곧 KRDS가 '기준을 한곳에 모아 모두가 같은 걸 보고 쓰게' 하려는 이유다. 자가 체크의 지도는 단지 '어디가 약한가'만이 아니라 '왜 약한가'의 실마리까지 보여준다.

■ 우선순위는 '영향 × 빈도'로

'아니오'가 여러 개 나왔다면, 다 한꺼번에 고칠 수는 없다. 우선순위를 정해야 하는데, 기준은 단순하다. '얼마나 많은 사용자가, 얼마나 자주 이 문제를 겪는가' 그리고 '이 문제가 사용자에게 얼마나 치명적인가'이다. 두 가지를 곱해서 큰 것부터 처리한다.

가장 먼저 손봐야 할 건 '많은 사람이 자주 거치는 핵심 흐름의 치명적 결함'이다. 이를테면 방문자 대부분이 거치는 민원 신청 흐름에서 마지막 제출이 안 되는 문제(편의성)나, 휠체어·시각장애 사용자가 아예 신청을 못 하는 문제(접근성)는 '영향도 크고 빈도도 높은' 최우선 과제다. 반면 어쩌다 한 명 들어오는 잘 안 쓰는 페이지의 사소한 색 어긋남은, 중요하긴 해도 순서를 뒤로 미뤄도 된다. 모든 '아니오'가 동등한 무게를 갖는 게 아니라는 걸 기억하자. 한정된 시간과 예산을 '가장 많은 사람을 가장 크게 돕는 곳'에 먼저 쓰는 것 — 그게 점검 결과를 현명하게 쓰는 법이다.

우선순위를 정할 때 또 하나의 기준이 '고치기 쉬운가'다. 어떤 문제는 영향이 큰데 고치는 데 많은 시간과 비용이 든다. 또 어떤 문제는 영향은 중간인데 손쉽게 고칠 수 있다. 둘 중 하나를 먼저 해야 한다면, 처음엔 '영향이 크면서 고치기도 쉬운 것'을 골라 빠르게 성과를 내는 게 좋다. 작은 성공이 쌓이면 '우리도 사이트를 좋게 만들 수 있다'는 자신감이 생기고, 그 자신감이 더 큰 개선으로 이어진다. 예를 들어 '이미지에 대체텍스트 채우기'나 '공지에 날짜 달기' 같은 건 영향이 작지 않으면서도 하루 이틀이면 끝낼 수 있는 일이다. 반면 '전체 사이트의 색 기준을 다시 세우기'는 영향은 크지만 시간이 오래 걸린다. 그러니 '빨리 끝낼 수 있는 큰 개선'으로 시작해 분위기를 만들고, '오래 걸리는 근본 개선'은 그 동력을 받아 차근차근 진행하는 게 현실적인 순서다. 점검 결과를 받아 들고 '이걸 다 언제 고치나' 막막해지는 대신, '오늘 당장 할 수 있는 것 하나'부터 손대면, 개선은 생각보다 빨리 굴러가기 시작한다.

■ '말로 꺼낼 수 있게' 만드는 것의 힘

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

특히 예산을 받아야 하는 자리에서 이 효과는 크다. '개편이 필요합니다'라는 말은 매년 나오는 흔한 요청이지만, '일곱 영역 중 접근성과 신뢰성이 가장 약하고, 이게 사용자 이탈과 행정 부담으로 이어지고 있습니다'라는 말은 결재권자를 설득하는 근거가 된다. 자가 체크는 그 근거의 '초안'을 만들어준다. 물론 결재 자리에서는 더 단단한 숫자가 필요하다. 그 숫자는 정밀 진단이 채워준다.

여기서 자가 체크의 또 다른 숨은 효과를 짚고 싶다. 점검을 한 번 해본 담당자는 '보는 눈'이 달라진다. 전에는 그냥 지나치던 작은 것들 — 흐린 회색 글씨, 똑같이 생긴 제출·취소 버튼, 날짜 없는 공지 — 이 이제 '아, 저건 접근성 문제, 저건 편의성 문제, 저건 신뢰성 문제'로 분류되어 눈에 들어온다. 한번 일곱 영역의 렌즈를 끼고 사이트를 본 사람은, 그 렌즈를 쉽게 벗지 못한다. 그래서 자가 체크는 '오늘 하루의 점검'으로 끝나지 않고, 그 담당자가 앞으로 새 페이지를 만들거나 콘텐츠를 올릴 때마다 '이게 일곱 영역 기준에 맞나' 하고 스스로 점검하게 만든다. 한 사람이 이 눈을 갖추면, 그 사람이 손대는 모든 페이지의 품질이 조금씩 올라간다. 그리고 그 눈이 부서에 퍼지면, 사이트 전체가 '만들 때부터 기준을 의식하는' 문화를 갖게 된다. 자가 체크의 진짜 보상은 '오늘의 점검표'가 아니라 '바뀐 시선'일지도 모른다.

■ 자가 체크의 한계, 그리고 그다음

여기서 솔직해지자. 오늘 체크리스트는 '대충 어디가 약한지'를 알려주지만, '정확히 몇 개 규칙을 어겼고, 점수가 몇 점이며, 어느 페이지가 가장 문제인지'까지는 알려주지 못한다. 사람 눈으로는 메인과 신청 페이지 몇 개를 보는 게 한계지, 수백 개 페이지를 일일이 일곱 영역으로 따질 수는 없다. KRDS 846규칙을 한 페이지씩 손으로 검사하는 것도 현실적으로 불가능하다. 자가 체크는 '빠르고 거칠게' 윤곽을 잡는 일이고, 그 윤곽을 '느리지만 정확하게' 채우는 건 도구의 몫이다.

그래서 권하는 순서는 이렇다. 먼저 오늘 체크리스트로 '우리 사이트의 일곱 영역 지도'를 그려 감을 잡는다. 그다음 '아니오가 몰린 영역'을 중심으로 정밀 진단을 받아, 사람 눈으로는 놓친 세부와 정확한 점수를 확인한다. 마지막으로 '영향 × 빈도' 우선순위에 따라 하나씩 고쳐나간다. 자가 체크 없이 바로 정밀 진단만 받으면 '숫자는 나왔는데 뭘 봐야 할지 모르는' 상태가 되고, 정밀 진단 없이 자가 체크만 믿으면 '눈에 안 보이는 깊은 문제'를 놓친다. 둘은 경쟁하는 게 아니라 짝을 이루는 도구다.

자가 체크에서 정밀 진단으로, 그 다리를 ViewCheck가 놓는다

■ 사람 눈의 한계를 도구가 메운다

지금까지 우리는 일곱 영역을 '사람 눈과 손'으로 점검했다. 이건 분명히 가치 있는 일이지만, 동시에 분명한 한계가 있다. 첫째, 페이지 수가 많으면 못 본다. 메인과 핵심 흐름 몇 개는 사람이 볼 수 있지만, 수백 개 하위 페이지를 일곱 영역으로 일일이 따지는 건 불가능하다. 둘째, 정량화가 안 된다. '좀 느린 것 같다', '대비가 약한 것 같다'는 느낌은 사람마다 다르고, 같은 사람도 그날 기분에 따라 다르게 본다. 셋째, 빠뜨린다. 846규칙 중 사람이 눈으로 확인할 수 있는 건 일부일 뿐, 나머지는 화면 뒤 코드와 구조를 봐야 알 수 있다.

바로 이 한계를 메우려고 만든 게 ViewCheck다. ViewCheck는 공공 웹사이트를 행정안전부 7대 품질 영역과 KRDS 846규칙(DS 120 + CP 446 + BP 108 + SP 172)의 기준으로 '자동' 진단하는 SaaS다. 오늘 우리가 손으로 점검한 일곱 영역을, 도구가 수백 페이지에 걸쳐 빠짐없이, 일관된 기준으로 따져준다. 사람이 '대충 약한 것 같다'고 느낀 곳을 '정확히 몇 개 규칙을, 어느 페이지에서 어겼는지' 숫자로 확정해주는 것이다.

■ 자가 체크 항목이 그대로 '점수'가 된다

오늘 체크리스트의 항목들을 다시 떠올려보자. '다른 브라우저에서도 같은가'(호환성), '키보드로 쓸 수 있는가'(접근성), '검색에 제대로 노출되는가'(개방성), '빠르게 열리는가'(접속성), '쓰기 편한가'(편의성), '모바일에서 가벼운가'(효율성), '믿을 만한가'(신뢰성). ViewCheck는 이 일곱 영역을 자동으로 측정해 각각 점수로 환산한다. 사람이 '예/아니오'로 거칠게 답한 걸, 도구가 0부터 100까지의 점수로 정밀하게 매겨주는 셈이다.

그 결과는 분석 화면 맨 위의 점수 카드에 한눈에 들어오게 정리된다. 카테고리별로 '여기는 강하고, 저기는 약하다'가 색과 숫자로 표시되니, 오늘 손으로 그린 '일곱 영역 지도'가 도구에서는 정확한 좌표를 가진 지도로 다시 그려지는 것이다. 그리고 단순히 점수만 보여주는 게 아니라, '어느 페이지의 어떤 요소가 어떤 규칙을 어겼는지'까지 구체적으로 짚어준다. 자가 체크가 '무엇이 문제인지'를 알려줬다면, 도구는 '정확히 어디서, 왜, 어떻게 고치면 되는지'까지 데려가 준다.

특히 도구가 빛을 발하는 건 '페이지가 많을 때'다. 오늘 우리가 손으로 본 건 메인과 핵심 흐름 몇 개가 전부였다. 하지만 실제 공공 사이트는 수십, 수백 개 페이지로 이뤄져 있고, 사람 눈으로는 그 전부를 일곱 영역으로 따질 수 없다. 손으로 본 메인은 멀쩡한데, 정작 사용자가 많이 들르는 깊숙한 하위 페이지가 엉망인 경우도 흔하다. 도구는 이 '안 보이는 페이지들'까지 빠짐없이 같은 기준으로 검사해, '우리가 미처 못 본 곳'의 문제를 끌어올려 준다. 사람이 '대표 몇 페이지'로 감을 잡았다면, 도구는 '사이트 전체'로 그 감을 확정해주는 셈이다. 그래서 자가 체크와 도구는 서로의 빈자리를 메운다. 사람은 '왜 이게 문제인지'를 몸으로 이해하고, 도구는 '얼마나, 어디에 그 문제가 퍼져 있는지'를 빠짐없이 보여준다.

■ '느낌'을 '근거'로 바꾸는 일

자가 체크의 결과는 설득에 쓰기엔 약하다. '제가 보기엔 좀 그래요'라는 말은 듣는 사람마다 다르게 받아들인다. 하지만 도구가 매긴 점수와 위반 목록은 다르다. '접근성 영역 점수가 기준에 미달하고, 그중 본문 이미지 다수가 대체텍스트를 갖추지 못했습니다'라는 문장은, 느낌이 아니라 근거다. 이 근거는 부서를 움직이고, 외주 업체에 정확한 작업 지시를 내리고, 예산 결재를 설득하는 데 쓸 수 있다. ViewCheck가 하는 일을 한마디로 줄이면, 담당자의 '느낌'을 누구나 인정할 수 있는 '근거'로 바꾸는 것이다.

그리고 이 과정은 '반복'할 때 더 빛난다. 오늘 점검하고, 개선하고, 석 달 뒤 다시 진단하면, 점수가 어떻게 변했는지가 그대로 보인다. 우리가 손본 부분이 실제로 나아졌는지, 새로 추가한 페이지가 기준을 지키고 있는지를 '추세'로 확인할 수 있다. 자가 체크가 '오늘의 한 장'이라면, 도구를 통한 정기 진단은 '우리 사이트의 건강 기록부'가 되는 셈이다.

마무리

오늘 우리는 행정안전부 7대 품질 영역을 '일곱 개의 기둥'으로 풀어, 담당자가 직접 따라 할 수 있는 자가진단 체크리스트로 만들었다. 호환성(어디서 열어도 같은가), 접근성(모두가 쓸 수 있나), 개방성(안내가 정직한가), 접속성(빠르고 끊김 없이 열리나), 편의성(쓰기에 편한가), 효율성(무겁지 않고 빠른가), 신뢰성(믿고 맡길 수 있나) — 이 일곱 가지를 사용자의 여정 순서대로 한 바퀴 돌아보는 것이 핵심이었다.

기억할 세 가지만 다시 짚자. 첫째, 이건 시험이 아니라 건강검진이다. '아니오'가 많을수록 점검이 잘된 거다. 둘째, 모든 '아니오'가 같은 무게가 아니다. '많은 사람이 자주 겪는 치명적 문제'부터 고쳐라. 셋째, 자가 체크는 '감을 잡는 일'이고, 그 감을 '정확한 근거'로 바꾸는 건 도구의 몫이다. 자가 체크로 지도를 그리고, 정밀 진단으로 좌표를 찍고, 우선순위대로 하나씩 고쳐나가는 — 이 순서가 가장 현명한 길이다. 그리고 이 모든 과정을 '한 번'이 아니라 '분기마다' 반복할 때, 우리 사이트는 비로소 '점점 좋아지는 사이트'가 된다. 좋은 사이트는 한 번에 완성되는 게 아니라, 꾸준한 점검과 작은 개선이 쌓여 만들어지는 것이기 때문이다.

마지막으로, 오늘 점검에서 '아니오'가 몇 개 나왔는가. 그 '아니오'들이 일곱 영역 중 어디에 몰려 있는지, 그게 실제로 몇 점짜리 문제인지 궁금하다면, 한 번 도구로 확인해보길 권한다. krds.viewcheck.co.kr 에서는 별도의 설치나 복잡한 준비 없이, 우리 기관 사이트 주소만 넣으면 7대 영역과 KRDS 846규칙 기준으로 무료 진단을 체험할 수 있다. 오늘 손으로 그린 '일곱 영역 지도'가 도구에서는 정확한 점수 카드로 다시 그려지는 걸 직접 보게 될 것이다. 거창한 개편 계획을 세우기 전에, 먼저 '지금 우리가 어디에 서 있는지'부터 정확히 아는 것 — 그 첫걸음을 오늘, 5분만 내어 시작해보자. 일곱 개의 기둥이 얼마나 단단한지, 어디가 흔들리는지를 아는 것만으로도 우리 사이트는 이미 좋아지기 시작한 것이다.