점수 깎이는 흔한 7대 영역 실수 모음

공감·문제제기

월요일에는 KRDS가 대체 무엇이고, 공공 웹에서 '디자인 시스템'이라는 말이 왜 그렇게 자주 나오는지를 큰 그림으로 풀었다. 오늘은 분위기를 좀 바꿔서, 현장에서 실제로 점수가 깎이는 장면들을 모아보려 한다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」이 정한 7대 품질 영역 — 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성 — 을 하나씩 따라가면서, 각 영역에서 사람들이 거의 똑같이 반복하는 실수들을 익명 사례로 보여주는 글이다.

먼저 솔직하게 말하고 싶은 게 있다. 나는 이 일을 하면서 공공 사이트 점검 결과를 정말 많이 봤는데, 점수가 낮은 사이트들이 '특별히 못 만든 사이트'인 경우는 거의 없었다. 오히려 겉으로 보면 멀쩡하다. 색도 그럭저럭 통일돼 있고, 메뉴도 있고, 신청도 된다. 그런데 7대 영역으로 하나씩 뜯어보면 곳곳에서 점수가 조용히 새어 나간다. 큰 구멍이 하나 뻥 뚫린 게 아니라, 바늘구멍 수십 개로 공기가 빠지는 풍선 같은 느낌이다. 그래서 담당자분들이 결과를 받아보면 늘 비슷하게 말씀하신다. "아니, 우리 사이트 멀쩡한데 왜 이렇게 점수가 낮죠?"

그 멀쩡해 보이는데 점수가 낮은 이유, 그게 오늘의 주제다.

한 가지 더. 이 글에 나오는 ○○시, A광역지자체, 한중앙부처, B공공기관, C기관 같은 이름은 전부 익명이다. 특정 기관을 흉보려는 게 절대 아니다. 점검을 하다 보면 기관 종류·규모와 상관없이 거의 똑같은 패턴이 반복되는데, 그 '전형'을 보여주려고 가상의 사례로 묶은 것이다. 그러니 읽다가 '어, 우리도 저런데' 싶은 게 나와도 자책할 필요 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다. 중요한 건 그 실수를 '이름 붙여' 알아보는 눈을 갖추는 거다. 이름을 붙일 수 있으면 고칠 수도 있다.

왜 이름 붙이기가 그렇게 중요하냐고 묻는다면, 점수가 깎이는 실수 대부분이 '눈에 잘 안 보인다'는 공통점을 갖고 있기 때문이다. 색이 제각각인 건 그나마 눈에 띈다. 그런데 보안 헤더 하나가 빠진 것, 응답 헤더에 캐시 설정이 잘못된 것, robots.txt가 사이트 전체를 막아버린 것, 이미지에 대체 텍스트가 없는 것 — 이런 건 평범한 사용자 눈에는 전혀 안 보인다. 화면은 멀쩡하다. 그런데 기계(검색엔진, 보조기기, 자동 점검 도구)가 보는 화면에서는 큰 문제다. 그래서 담당자는 '우리 사이트 멀쩡한데'라고 믿고 있고, 점검 결과는 '여기저기 새고 있다'고 말한다. 이 간극을 메우는 게 오늘 글이 하려는 일이다.

사실 이 '안 보여서 모른다'는 게 공공 웹 품질 관리에서 가장 큰 적이다. 담당자들이 실력이 없어서가 아니다. 다들 바쁘고, 챙길 게 많고, 화면이 멀쩡하니 더 급한 일에 손이 간다. 그러는 사이 안 보이는 곳에서 점수가 새고, 누군가는 못 들어오고, 누군가는 못 읽고, 누군가는 검색으로 못 찾는다. 그 '누군가'가 통계로 잡히지 않으니 문제의 크기조차 가늠이 안 된다. 그래서 공공 웹은 '잘못 만든 사이트'보다 '안 보여서 방치된 사이트'가 훨씬 많다. 오늘 글은 바로 그 '방치'를 깨려는 글이다.

또 하나 솔직히 말하면, 7대 영역이라는 말 자체가 처음엔 좀 딱딱하게 들린다. 무슨 시험 과목 같고, '또 평가받아야 하나' 싶어서 부담스럽다. 그런데 이 일곱 개를 '평가 항목'이 아니라 '우리 사이트가 누구를 놓치고 있는지 알려주는 일곱 개의 거울'로 보면 이야기가 달라진다. 호환성 거울은 '다른 환경 쓰는 사람'을, 접근성 거울은 '몸이 불편한 사람'을, 개방성 거울은 '검색으로 찾는 사람'을, 접속성 거울은 '붐빌 때 들어온 사람'을, 편의성 거울은 '처음 온 사람'을, 효율성 거울은 '느린 환경의 사람'을, 신뢰성 거울은 '정보를 맡긴 사람'을 비춘다. 일곱 개를 다 보면, 우리가 평소에 못 보던 '우리 사이트의 진짜 사용자들'이 보인다. 평가가 아니라 발견인 셈이다.

그리고 미리 위로 한마디. 7대 영역에서 점수가 깎이는 실수들은 다행히 대부분 '고치기 어려운 문제'가 아니다. 오히려 '몰라서 못 고친 문제'가 훨씬 많다. 존재를 모르니 손을 못 댄 것뿐이다. 그래서 오늘 글의 목표는 단순하다. 그 '몰랐던 구멍'들을 하나씩 눈앞에 꺼내 보여주는 것. 보이기 시작하면 절반은 해결된 거다. 나머지 절반은 '하나씩 고쳐 나가는 손'의 몫인데, 그건 의외로 어렵지 않다. 큰 사고 몇 개만 막아도 점수표의 빨간 칸이 눈에 띄게 줄어든다.

한 가지 미리 당부하고 싶은 건, 읽으면서 '우리 사이트는 어디에 해당될까'를 계속 떠올려 보라는 거다. 그냥 남의 이야기로 읽으면 머리에 안 남는다. 각 사례를 '우리 사이트에도 이게 있을까?'라는 질문으로 바꿔 읽으면, 글이 끝날 때쯤 '우리가 먼저 점검해 볼 곳'의 목록이 자연스럽게 손에 잡힐 거다. 오늘 글은 정보를 전하려는 글이라기보다, 여러분이 자기 사이트를 '새로운 눈'으로 다시 보게 만들려는 글에 가깝다.

자, 이제 7대 영역을 하나씩 따라가 보자. 각 영역마다 '어떤 실수가 점수를 깎는가'를 익명 사례로 보여주고, '그래서 어떻게 하면 되는가'를 짧게 정리하겠다.

7대 영역이 뭔지 1분 정리

■ 점수표는 사실 '일곱 칸짜리 성적표'다

본론에 들어가기 전에, 7대 영역이라는 게 뭔지부터 아주 짧게 정리하자. 행정안전부의 「전자정부 웹사이트 품질관리 지침」은 공공 웹사이트가 갖춰야 할 품질을 일곱 개 영역으로 나눠 본다. 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성. 처음 들으면 비슷비슷한 말 같지만, 막상 뜯어보면 서로 꽤 다른 걸 본다.

쉽게 비유하면 이렇다. 사이트를 한 사람으로 본다면, 호환성은 '어떤 옷(브라우저)을 입어도 단정한가', 접근성은 '누구나(시각·청각·운동 능력과 무관하게) 대화할 수 있는가', 개방성은 '바깥 세상(검색엔진, 데이터 이용자)에 문을 열어두었는가', 접속성은 '부르면 빨리 나오는가, 안 끊기는가', 편의성은 '쓰기 편한가, 헤매지 않는가', 효율성은 '몸이 가벼운가(빨리 뜨는가)', 신뢰성은 '믿고 정보를 맡길 수 있는가(보안·개인정보)'를 본다.

이 일곱 칸이 모여 '성적표'가 된다. 그리고 대부분의 사이트는 어떤 칸은 높고 어떤 칸은 낮다. 디자인이 예쁜 사이트가 보안에서 빵점이기도 하고, 보안은 튼튼한데 접근성이 바닥이기도 하다. 7대 영역으로 본다는 건, 사이트를 '예쁘다/안 예쁘다' 같은 한 줄 평가가 아니라 일곱 개의 객관적 잣대로 본다는 뜻이다. 그래서 '우리 사이트 괜찮은데요?'라는 막연한 자신감은 7대 영역 앞에서 자주 깨진다. 괜찮다는 그 느낌은 보통 한두 칸만 보고 내린 판단이기 때문이다.

하나 더 짚어둘 게 있다. 7대 영역은 '점수가 높으면 끝'인 시험이 아니라 '꾸준히 관리해야 유지되는' 상태에 가깝다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 쌓이고 페이지가 붙고 부서가 바뀌면서 끊임없이 변한다. 작년에 만점이던 영역이 올해 새 페이지 몇 개 때문에 점수가 깎이기도 한다. 그래서 7대 영역 점검은 '한 번 받고 끝내는 자격증'이 아니라 '정기 건강검진'에 가깝다. 사람도 한 번 건강검진 받았다고 평생 건강이 보장되는 게 아니듯, 사이트도 주기적으로 들여다봐야 한다. 다행히 두 번째, 세 번째 점검부터는 '바뀐 부분만' 보면 되니 훨씬 가볍다.

여기서 KRDS 이야기를 잠깐 연결해 두자. KRDS의 846규칙(DS 120 + CP 446 + BP 108 + SP 172)은 주로 '디자인 준수' 영역을 촘촘하게 다룬다. 색·글꼴·간격 같은 기초(DS), 버튼·입력칸·카드 같은 부품(CP), 폼·필터 같은 패턴(BP), 신청·검색·로그인 같은 서비스 흐름(SP)까지 규칙으로 정해두고 하나씩 따진다. 숫자가 846개나 되니 처음 들으면 '그걸 다 어떻게 지키나' 싶지만, 실은 '잘 만든 부품을 가져다 쓰면 대부분 자동으로 지켜지는' 규칙들이다. 표준 버튼을 쓰면 버튼 관련 규칙이 통과되고, 표준 폼을 쓰면 폼 관련 규칙이 통과되는 식이다. 그래서 846규칙은 '외워야 할 시험 범위'가 아니라 '좋은 재료 목록'에 가깝다. 7대 영역은 여기에 보안·성능·검색 노출 같은 '디자인 바깥'의 품질까지 포함하는, 더 넓은 우산이다. 둘은 경쟁하는 게 아니라 겹치고 보완한다. 디자인을 잘 지키면 접근성·호환성이 따라 좋아지고, 7대 영역을 챙기면 사이트 전체의 건강이 올라간다. 오늘은 그 넓은 우산, 7대 영역 쪽에서 새는 구멍들을 본다.

영역별 흔한 실수 모음 (익명 사례)

■ 영역 1) 호환성 — "제 브라우저에서는 멀쩡한데요?"의 함정

호환성은 '어떤 환경에서 봐도 똑같이 단정하게 보이고 작동하는가'를 본다. HTML·CSS가 표준을 지켰는지, 여러 브라우저에서 깨지지 않는지가 핵심이다. 말하자면 '내가 어떤 문으로 들어가도 같은 안내를 받는가'의 문제다. 공공 사이트는 특정 사람만 쓰는 게 아니라 '누구나' 쓰는 곳이라, 이 호환성이 특히 중요하다.

여기서 가장 흔한 실수는 '만든 사람의 환경'만 보고 끝내는 거다. ○○시의 한 부서 페이지를 점검한 적이 있는데, 담당자분은 "우리 페이지 멀쩡해요, 매일 보는걸요"라고 하셨다. 그런데 그분이 매일 보는 건 회사 PC의 한 브라우저 한 종류였다. 정작 다른 브라우저로 열어보니 표가 옆으로 비어져 나오고, 어떤 메뉴는 클릭이 안 됐다. 본인은 '멀쩡한 화면'을 매일 봤으니 문제를 인지할 길이 없었던 거다.

이게 호환성 실수의 핵심 구조다. 만든 사람은 자기 환경에서만 확인하고, 그 환경에서 안 보이는 문제는 '없는 문제'가 된다. 그런데 공공 사이트는 정말 다양한 환경에서 접속된다. 최신 브라우저도 있고, 한참 오래된 환경도 있고, 회사 보안 정책 때문에 특정 브라우저만 쓰는 곳도 있다. 한 환경에서만 통과한 사이트는 '운이 좋으면 멀쩡'한 상태일 뿐이다.

또 흔한 게 '비표준 마크업'이다. HTML 태그를 규칙대로 안 닫거나, 같은 id를 여기저기 중복으로 쓰거나, 표가 아닌 걸 표 태그로 만들어 레이아웃을 잡는 식이다. 브라우저는 똑똑해서 이런 어긋남을 '알아서 추측해' 보여주는데, 문제는 브라우저마다 추측이 다르다는 거다. 그래서 A 브라우저에선 멀쩡하고 B 브라우저에선 무너진다. 표준을 지킨다는 건 '브라우저의 추측에 운명을 맡기지 않는다'는 뜻이다.

A광역지자체 사례 하나 더. 화면은 멀쩡한데 HTML 검증을 돌리면 오류가 수백 건 나오는 경우가 있다. 담당자는 "화면이 잘 나오는데 그게 무슨 문제냐"고 묻는다. 맞다, 지금 당장은 문제가 아닐 수 있다. 하지만 표준 위반은 '미래의 사고를 예약해 두는 것'과 같다. 브라우저가 업데이트되면서 '관대하게 봐주던 추측'을 어느 날 안 봐주게 되면, 그동안 운으로 버티던 페이지들이 한꺼번에 무너진다. 멀쩡해 보일 때 표준을 맞춰두는 게, 사고가 터진 뒤 수습하는 것보다 압도적으로 싸다.

호환성과 관련해 한 가지 더 자주 보는 실수가 있다. '특정 환경 전용 기능'에 의존하는 거다. 예전에 어떤 기관 사이트는 신청·발급 같은 핵심 기능이 특정 환경에서만 동작하도록 만들어져 있었다. 그 환경을 안 쓰는 시민은 핵심 서비스 자체를 이용할 수 없었다. 만든 당시에는 그 환경이 표준처럼 여겨졌을지 몰라도, 시간이 지나면서 '소수만 쓰는 환경'이 되면 그 사이트는 점점 더 많은 사람을 배제하게 된다. 호환성은 '지금 다수가 쓰는 환경'만 챙기는 게 아니라, '특정 환경에 갇히지 않게' 만드는 것까지 포함한다. 표준을 따른다는 건 결국 '특정 회사·특정 제품에 사이트의 운명을 묶지 않는다'는 뜻이기도 하다.

또 한 가지, 호환성 문제는 '모바일과 PC의 차이'에서도 크게 터진다. PC 화면 기준으로만 만든 사이트를 휴대폰으로 열면, 글자가 깨알같이 작아지거나, 표가 화면 밖으로 삐져나가거나, 가로 스크롤이 생겨서 손가락으로 좌우로 밀어야 내용을 다 볼 수 있게 된다. 요즘 공공 사이트 방문의 절반 이상이 휴대폰에서 일어나는데, 정작 휴대폰 화면을 제대로 확인 안 한 사이트가 여전히 많다. 만든 사람은 큰 모니터에서 보니 멀쩡한데, 시민의 절반 이상은 작은 화면에서 헤매고 있는 거다. 호환성을 점검할 때 '여러 브라우저'만큼이나 '여러 화면 크기'를 함께 봐야 하는 이유다.

호환성에서 점수를 지키는 길은 의외로 단순하다. 첫째, 자기 환경 하나만 보지 말 것. 적어도 서로 다른 브라우저 몇 종, 그리고 PC와 휴대폰 양쪽에서 같은 화면을 확인하는 습관. 둘째, HTML·CSS 표준 검사를 '만들 때마다' 돌릴 것. 셋째, 표는 표 태그로, 목록은 목록 태그로 — 즉 '보이는 모양'이 아니라 '의미'에 맞는 태그를 쓸 것. 넷째, 특정 환경에서만 되는 기능을 핵심 흐름에 끼워 넣지 말 것. 이 넷만 지켜도 호환성 점수의 큰 덩어리는 지킨다. 그리고 이 습관들은 한 번 몸에 붙으면 그다음부터는 거의 비용이 안 든다. 처음에만 '번거롭다' 싶을 뿐, 익숙해지면 자연스러운 작업 순서가 된다.

■ 영역 2) 접근성 — 가장 많이, 가장 조용히 깎이는 영역

솔직히 말하면, 7대 영역 중에서 점수가 가장 많이 새는 곳이 접근성이다. 그리고 가장 '억울하게' 깎이는 곳이기도 하다. 왜냐하면 접근성은 평범한 사용자 눈에는 전혀 안 보이는 영역이라서, 담당자가 문제를 인지할 기회 자체가 적기 때문이다.

접근성은 한마디로 '누구나 쓸 수 있는가'의 문제다. 눈이 안 보여도, 귀가 안 들려도, 손이 불편해 마우스를 못 써도, 그 사람이 사이트를 쓸 수 있어야 한다는 거다. 공공 서비스는 본질적으로 '모든 국민'을 위한 것이라, 접근성은 단순한 권장사항이 아니라 '빠뜨리면 안 되는 기본'에 가깝다. 웹접근성은 KWCAG 33항목으로 점검하는데, 여기서 단골로 걸리는 실수 몇 가지를 보자.

첫째, 이미지에 대체 텍스트가 없다. 한중앙부처의 한 페이지를 점검했더니, 중요한 안내가 전부 '이미지'로 들어가 있었다. 디자인은 깔끔했다. 그런데 그 이미지에 대체 텍스트(alt)가 하나도 없었다. 화면을 못 보고 소리로 듣는 사용자에게는 그 페이지가 통째로 '빈 페이지'였던 셈이다. 더 안타까운 건, 그 안내가 바로 '신청 자격'과 '제출 서류' 같은 핵심 정보였다는 점이다. 정작 가장 필요한 정보가 가장 안 닿는 형태로 들어가 있던 거다.

둘째, 색만으로 정보를 구분한다. '빨간 글씨는 필수 항목입니다' 같은 안내가 대표적이다. 색을 구분하기 어려운 사용자에게는 그 '빨강'이 안 보인다. 그러면 어디가 필수인지 알 길이 없다. 색은 '보조 신호'로만 쓰고, 별표(*)나 '필수' 같은 글자를 함께 줘야 한다. 이건 손이 거의 안 가는 수정인데도 빠뜨리는 경우가 정말 많다.

셋째, 키보드로 못 쓴다. 마우스 없이 키보드(Tab 키)만으로 사이트를 쓰는 사용자가 있다. 그런데 가이드 없이 만든 버튼·메뉴는 키보드로 초점이 안 가거나, 초점이 가도 '지금 여기 와 있다'는 시각적 표시가 없다. 그러면 키보드 사용자는 사이트 안에서 길을 잃는다. B공공기관 사이트에서 이걸 실제로 테스트해보니, 메인 메뉴를 키보드로 열 수가 없어서 하위 페이지로 아예 진입이 안 됐다. 마우스로는 멀쩡한데, 키보드 사용자에게는 '닫힌 사이트'였던 거다.

넷째, 폼 입력칸에 라벨이 없다. 입력칸 위에 '이름'이라고 글자만 떠 있고, 그 글자와 입력칸이 '프로그램적으로' 연결돼 있지 않은 경우다. 눈으로 보는 사용자는 '아, 이 칸은 이름 칸이구나' 알지만, 소리로 듣는 사용자에게는 '정체불명의 빈 칸'으로 읽힌다. 라벨을 입력칸에 제대로 연결하는 건 코드 한 줄 수준인데, 이걸 안 해서 폼 전체의 접근성이 무너진다.

다섯째, 동영상·음성에 자막이나 대본이 없다. 공공 사이트에는 정책 설명 영상, 안내 방송 같은 게 종종 올라온다. 그런데 자막이 없으면 소리를 못 듣는 사용자는 그 내용을 알 길이 없다. 반대로 화면을 못 보는 사용자를 위해서는 영상 속 시각 정보를 말로 풀어주는 설명이 필요하다. '영상 하나 올렸으니 됐다'가 아니라, 그 영상의 내용이 '듣지 못하는 사람에게도, 보지 못하는 사람에게도' 닿는지를 챙겨야 한다. 이건 손이 좀 더 가는 작업이라 자주 빠지는데, 정작 중요한 정책 안내일수록 더 많은 사람에게 닿아야 한다는 점에서 소홀히 할 수 없는 부분이다.

여섯째, '초점 순서'가 뒤죽박죽이다. 키보드로 Tab 키를 눌러 화면을 이동할 때, 초점이 위에서 아래로, 왼쪽에서 오른쪽으로 자연스럽게 흘러야 한다. 그런데 화면을 '보이는 위치'와 무관하게 코드 순서대로 짜면, Tab을 눌렀을 때 초점이 화면 여기저기로 점프한다. 위에 있다가 갑자기 맨 아래로 갔다가 다시 중간으로 오는 식이다. 눈으로 보는 사용자는 마우스로 원하는 곳을 바로 누르니 모르지만, 키보드와 보조기기에 의존하는 사용자에게는 '예측 불가능한 미로'가 된다. 이런 건 화면만 봐서는 절대 안 보이고, 실제로 Tab 키를 눌러보거나 점검 도구를 돌려봐야 드러난다.

접근성이 '억울하게' 깎인다고 한 데는 또 다른 이유도 있다. 접근성은 '특정 소수만을 위한 배려'로 오해받기 쉬운데, 실제로는 모두에게 이롭다. 자막은 소리를 못 듣는 사람만 쓰는 게 아니라, 시끄러운 곳이나 조용히 해야 하는 곳에서 영상을 보는 모든 사람이 쓴다. 충분한 색 대비는 저시력자만을 위한 게 아니라, 햇빛 쨍한 야외에서 휴대폰을 보는 모든 사람을 돕는다. 큰 글씨와 또렷한 위계는 어르신만을 위한 게 아니라, 급할 때 빠르게 훑는 모든 사람에게 편하다. 접근성을 챙긴다는 건 '소수를 위해 다수가 양보하는 것'이 아니라 '모두에게 더 나은 사이트를 만드는 것'이다. 이 관점이 잡히면 접근성 작업이 '의무'가 아니라 '이득'으로 보이기 시작한다.

접근성 실수의 공통점은 '악의 없음'이다. 누구도 '장애인이 못 쓰게 하자'고 만들지 않았다. 그냥 '안 보이는 사용자'를 떠올리지 못했을 뿐이다. 만든 사람은 다 보이고 다 들리니까, 안 보이고 안 들리는 상황을 상상하기 어렵다. 그래서 접근성은 '착한 마음'만으로는 안 되고 '점검 도구'가 필요하다. 사람의 선의는 사각지대를 못 보지만, 도구는 본다. 접근성 자동 점검을 돌려보는 것만으로도 '아, 여기 대체 텍스트가 없네, 여기 라벨이 없네, 여기 색 대비가 미달이네'가 줄줄이 나온다. 그걸 보고 고치면 된다. 몰라서 못 고친 것이지, 못 고칠 문제가 아니다. 그리고 한 가지 위로를 덧붙이자면, 접근성은 '한 번 체계를 잡아두면' 그다음부터는 자동으로 지켜지는 부분이 많다. 표준 부품을 쓰면 그 부품에 라벨·초점 표시·키보드 지원이 이미 들어 있어서, 새 페이지를 만들 때마다 따로 신경 쓰지 않아도 접근성이 따라온다. 그래서 접근성과 디자인 시스템은 사실 한 몸이다. 기초를 잘 잡으면 접근성도 함께 잡힌다.

■ 영역 3) 개방성 — 문을 열어두랬더니 통째로 잠가버린 사고

개방성은 '바깥에 적절히 문을 열어두었는가'를 본다. 검색엔진이 사이트를 잘 수집할 수 있는지, robots.txt와 sitemap.xml 같은 '안내문'이 제대로 있는지, 메타데이터(페이지 설명, 소셜 공유 정보)가 갖춰져 있는지를 본다.

여기서 가장 충격적인 실수는 robots.txt 사고다. robots.txt는 검색엔진에게 '여긴 수집해도 돼, 여긴 수집하지 마'를 알려주는 파일이다. 그런데 C기관 사이트를 점검했더니, 이 파일에 '사이트 전체를 수집하지 마'라는 한 줄이 들어 있었다. 개발하는 동안 검색엔진이 미완성 사이트를 수집하지 못하게 막아둔 설정을, 정식 오픈하면서 푸는 걸 깜빡한 거다. 결과는? 그 기관 사이트가 검색에서 거의 안 잡혔다. 시민이 기관 이름을 검색해도 사이트가 위에 안 떴다. 정성껏 만든 안내·민원·정책 페이지가, 검색이라는 가장 큰 입구에서 통째로 가려져 있던 셈이다.

이건 정말 자주 본다. '문을 열어두라'는 개방성에서, 실수로 '대문을 통째로 걸어 잠그는' 사고. 더 무서운 건 이게 화면에서는 전혀 안 보인다는 점이다. 사이트는 멀쩡히 잘 뜬다. 직접 주소를 치고 들어오는 사람에게는 아무 문제가 없다. 문제는 '검색으로 찾아오려는 사람'에게만 보이는데, 그 사람은 사이트를 못 찾았으니 민원을 넣을 수도 없다. 그래서 담당자는 몇 달이고 이 사고를 모른 채 지낸다.

두 번째 흔한 실수는 sitemap.xml 부재나 방치다. sitemap은 검색엔진에게 '우리 사이트에 이런 페이지들이 있어요' 하고 목록을 건네는 지도다. 이게 없으면 검색엔진이 일일이 링크를 따라가며 페이지를 발견해야 하는데, 깊숙이 있는 페이지는 영영 못 찾기도 한다. 있더라도 몇 년 전 상태로 멈춰 있으면, 새로 만든 페이지들은 지도에 없으니 안 잡힌다.

세 번째는 메타데이터 부실이다. 페이지마다 제목과 설명이 제대로 안 들어가 있으면, 검색 결과에 우리 페이지가 '제목 없음'이나 엉뚱한 자동 추출 문구로 뜬다. 소셜에 공유했을 때 미리보기가 깨지는 것도 같은 원인이다. 공유 미리보기에 회색 빈 상자만 뜨는 기관 게시물, 한 번쯤 본 적 있을 거다. 그게 바로 개방성 메타데이터가 빠진 결과다.

네 번째 흔한 실수는 '데이터를 닫아둔' 경우다. 개방성에는 '공공 데이터를 시민과 외부 서비스가 활용할 수 있게 열어두었는가'도 들어간다. 어떤 기관은 통계나 안내 정보를 화면에는 보여주지만, 그걸 기계가 읽을 수 있는 형태로는 전혀 제공하지 않는다. 사람이 눈으로 보고 일일이 옮겨 적어야만 쓸 수 있는 거다. 공공 정보는 '우리 화면에서만 보라'가 아니라 '누구나 가져다 다른 서비스에서 활용하게 하라'는 게 개방성의 큰 정신이다. 시민 개발자가 그 데이터로 더 편한 앱을 만들 수도 있고, 다른 기관이 그 정보를 연결해 쓸 수도 있다. 데이터를 열어두는 건 그 자체로 공공의 자산을 더 많은 곳에 쓰이게 하는 일이다.

다섯 번째는 '언어 설정 누락'이다. 페이지가 한국어인지 다른 언어인지를 알려주는 기본 설정이 빠지면, 보조기기가 엉뚱한 발음으로 읽거나, 번역 도구가 헷갈린다. 이건 코드 한 줄짜리 설정인데, 의외로 빠져 있는 사이트가 많다. 작지만 개방성과 접근성 양쪽에 걸리는 항목이라 챙겨두면 좋다.

개방성은 '열고 닫음'의 균형이다. 보안상 가려야 할 곳(관리자 페이지 등)은 제대로 닫고, 시민에게 보여줄 곳은 활짝 열어야 한다. 그런데 이 균형을 거꾸로 잡는 사고가 의외로 많다. 가려야 할 관리자 경로는 열려 있고, 열어야 할 정보 페이지는 막혀 있는 식이다. 개방성 점검은 이 균형이 제대로 잡혔는지를 본다. robots.txt 한 줄, sitemap 갱신, 메타 태그 채우기, 언어 설정 — 손은 적게 가는데 효과는 큰, 가성비 좋은 영역이다. 특히 robots.txt 사고는 '발견만 하면 1분 만에 고치는' 문제인데도, 발견을 못 해서 몇 달씩 방치되는 게 가장 안타까운 부분이다. 그래서 개방성만큼은 정기적으로 점검 도구를 한 번씩 돌려보는 것만으로도 큰 사고를 예방할 수 있다. '검색에 우리 사이트가 잘 나오나'를 가끔 직접 검색해 확인하는 작은 습관도 도움이 된다.

■ 영역 4) 접속성 — 빠른 줄 알았는데 사실 '운이 좋았던' 사이트

접속성은 '부르면 잘 나오는가, 안정적으로 접속되는가'를 본다. 서버 응답 시간, 연결의 안정성, 인증서가 제대로 갖춰졌는지 같은 걸 본다.

흔한 실수 첫 번째는 '평소엔 빠른데 몰릴 때 느려지는' 사이트다. ○○시의 어떤 신청 페이지가 그랬다. 평소에 들어가면 빠르다. 그래서 담당자는 '우리 사이트 빠른데요'라고 자신했다. 그런데 신청 마감일에, 사람이 한꺼번에 몰리는 그 순간에 사이트가 버벅이고 멈췄다. 정작 가장 중요한 순간에 못 쓰게 된 거다. 접속성은 '한가할 때의 속도'가 아니라 '붐빌 때도 버티는가'가 핵심인데, 한가할 때만 보고 안심하는 실수가 잦다.

두 번째는 인증서 문제다. 사이트가 'https'로 시작하는 안전한 연결을 쓰는지, 그 보안 인증서가 만료되지 않았는지, 발급이 제대로 됐는지가 접속성·신뢰성 양쪽에 걸린다. 한중앙부처 산하 한 페이지에서 인증서가 만료 직전이었던 적이 있다. 만료되면 브라우저가 '이 사이트는 안전하지 않습니다'라는 무시무시한 경고 화면을 띄운다. 시민 입장에서 정부 사이트에 들어갔는데 빨간 경고가 뜨면, 진짜 그 사이트가 멀쩡해도 '여기 이상한 데 아냐?' 하고 뒤로 가버린다. 인증서 만료일 관리는 사소해 보이지만, 놓치면 사이트 전체가 '위험한 곳'으로 낙인찍히는 큰 사고다.

세 번째는 리다이렉트(주소 자동 이동)가 꼬인 경우다. 옛 주소로 들어온 사람을 새 주소로 보내는 설정이 여러 겹으로 꼬여서, 한 번 들어오는 데 자동 이동이 서너 번 일어나는 사이트가 있다. 그만큼 첫 화면이 뜨는 게 느려진다. 사용자는 '왜 이렇게 오래 걸리지'만 느끼고, 그 뒤에서 주소가 몇 번이나 튕기고 있는지는 모른다.

네 번째 흔한 실수는 '점검 사각지대'다. 사이트가 잘 돌아가는지를 자동으로 지켜보는 장치 없이, 시민의 민원이 들어와야 비로소 '아, 사이트가 멈췄었구나'를 아는 경우다. 한밤중이나 주말에 사이트가 잠깐 멈췄다 돌아와도, 그걸 인지할 사람이 아무도 없으면 그냥 '아무 일 없었던 것'처럼 지나간다. 하지만 하필 그 시간에 신청하려던 시민에게는 '안 되는 사이트'였다. 접속성은 '평소에 잘 되는가'만이 아니라 '안 될 때 그걸 빨리 알아채는가'까지 포함하는 개념이다.

다섯 번째는 '무거운 첫 화면'이 접속성을 갉아먹는 경우다. 첫 화면에서 너무 많은 걸 한꺼번에 불러오려 하면, 서버가 그걸 다 준비해 내보내는 데 시간이 걸린다. 사용자는 빈 화면을 한참 보고 있어야 한다. 이건 효율성과도 겹치는데, '서버가 첫 응답을 빨리 주는가'라는 점에서 접속성에 직접 영향을 준다. 첫인상은 '화면이 뜨기까지의 기다림'에서 거의 결정되는데, 이 기다림이 길면 사용자는 내용을 보기도 전에 떠난다.

접속성에서 점수를 지키려면 '느낌'이 아니라 '숫자'를 봐야 한다. 첫 응답까지 걸린 시간, 인증서 남은 기간, 자동 이동 횟수 — 이런 건 직접 측정해야 보인다. ViewCheck 같은 진단 도구가 이런 숫자를 자동으로 뽑아주는 이유가 여기 있다. 사람은 '빠른 것 같다/느린 것 같다'는 느낌밖에 못 갖지만, 측정값은 '0.3초'와 '2.8초'의 차이를 명확히 알려준다. 그리고 그 숫자가 손에 잡히면, '무엇을 고쳐야 이 숫자가 줄어드는가'라는 구체적인 다음 단계가 보인다. 막연한 '느려요'는 행동으로 이어지지 못하지만, '첫 응답이 2.8초'라는 숫자는 '이걸 1초 아래로 줄여보자'는 목표로 바뀐다. 측정이 곧 개선의 출발점인 이유가 여기에도 있다.

■ 영역 5) 편의성 — "우리 직원은 다 찾던데요"의 착시

편의성은 '사용자가 헤매지 않고 원하는 걸 찾고 처리할 수 있는가'를 본다. 메뉴 구조, 검색 기능, 안내의 친절함, 길 안내(네비게이션) 같은 게 여기 들어간다.

가장 흔한 착시가 '우리 직원은 다 찾던데요'다. A광역지자체의 한 페이지를 점검하면서 '이 정보 찾기가 너무 어렵다'고 말씀드렸더니, 담당자분이 "그거 여기 있잖아요"라며 단번에 찾으셨다. 당연하다. 매일 그 사이트를 들여다보는 분에게는 모든 게 '뻔히 보이는 자리'에 있다. 하지만 1년에 한두 번, 그것도 급할 때 들어오는 시민에게는 그 자리가 전혀 뻔하지 않다. 만든 사람과 처음 온 사람의 '아는 정도' 차이를 잊으면, 불편한 사이트를 '편한 사이트'로 착각하게 된다.

두 번째 흔한 실수는 '부서 조직도 그대로 만든 메뉴'다. 공공 사이트의 메뉴가 기관 내부 조직 구조를 그대로 옮긴 경우가 많다. 만드는 입장에선 자연스럽다. 그런데 시민은 그 기관의 조직 구조를 모른다. '출산 지원금'을 신청하려는 시민이 그게 '여성가족과' 소관인지 '복지정책과' 소관인지 어떻게 알겠나. 시민은 '하려는 일' 기준으로 찾는데, 메뉴는 '만드는 사람의 부서' 기준으로 짜여 있으면, 그 사이에서 길을 잃는다. 좋은 편의성은 '우리 조직이 어떻게 나뉘어 있는가'가 아니라 '시민이 무엇을 하러 오는가'를 기준으로 짠다.

세 번째는 검색이 검색답지 못한 경우다. 검색창에 '출산지원금'을 넣었는데 결과가 0건, '출산 지원금'이라고 띄어 써야만 결과가 나오는 식이다. 사용자는 띄어쓰기까지 정확히 맞춰줄 의무가 없다. 비슷한 말, 띄어쓰기 차이, 오타 정도는 검색이 너그럽게 받아줘야 한다. 검색이 까다로우면 사용자는 '이 사이트엔 그 정보가 없나 보다' 하고 포기한다. 정보는 있는데 검색이 못 찾아준 것뿐인데도 말이다.

네 번째는 '막다른 길'이다. 어떤 페이지에 들어갔는데, 거기서 다음으로 갈 길이 안 보이는 경우다. 신청을 끝냈는데 '이제 뭘 해야 하는지' 안내가 없거나, 오류가 났는데 '어떻게 하라'는 말이 없이 그냥 '오류' 한마디만 떠 있는 식이다. 사용자는 거기서 막혀 이탈한다. 편의성은 '다음 행동을 늘 안내해 주는가'의 문제이기도 하다.

다섯 번째 흔한 실수는 '오류 메시지가 불친절한' 경우다. 폼을 작성하다 뭔가 잘못 입력하면 '오류가 발생했습니다' 한 줄만 빨갛게 뜨고 끝이다. 어디가 잘못됐는지, 어떻게 고쳐야 하는지는 안 알려준다. 사용자는 처음부터 끝까지 자기 입력을 다시 살펴보며 '대체 뭐가 문제지'를 혼자 찾아야 한다. 친절한 사이트는 '생년월일은 8자리 숫자로 입력해 주세요'처럼 '무엇이, 왜, 어떻게'를 콕 짚어준다. 오류 메시지는 '사용자를 막는 벽'이 아니라 '사용자를 다음으로 안내하는 표지판'이어야 한다. 이 작은 차이가 '끝까지 신청한 사람'과 '중간에 포기한 사람'을 가른다.

여섯 번째는 '너무 깊은 메뉴'다. 원하는 정보를 보려면 메뉴를 다섯 번, 여섯 번 타고 들어가야 하는 사이트가 있다. 한 단계 한 단계 들어갈 때마다 사용자는 '이 길이 맞나' 불안해하고, 한 번이라도 잘못 들어가면 처음으로 돌아가 다시 시작한다. 자주 찾는 정보일수록 얕은 곳에, 손이 닿기 쉬운 곳에 두는 게 편의성의 기본이다. '우리 사이트에서 가장 많이 찾는 정보 다섯 가지'를 첫 화면에서 바로 누를 수 있게만 해도 편의성 체감이 크게 달라진다.

편의성은 7대 영역 중에서 '만든 사람이 가장 평가하기 어려운' 영역이다. 자기가 만든 길은 자기에게 늘 편하기 때문이다. 그래서 편의성만큼은 '처음 온 사람의 눈'이 절대적으로 필요하다. 옆자리 동료에게, 우리 부서를 전혀 모르는 사람에게 '이 사이트에서 이거 한번 신청해봐' 하고 시켜보면, 우리가 못 보던 막힘이 줄줄이 드러난다. 편의성 점검의 출발은 늘 '낯선 눈'이다. 그리고 그 낯선 눈을 매번 빌리기 어렵다면, 점검 도구가 잡아주는 '구조적 신호' — 메뉴 깊이, 안내 문구의 유무, 오류 처리 패턴 — 를 참고하는 것도 큰 도움이 된다. 사람의 눈과 도구의 눈을 함께 쓰면, 편의성의 사각지대가 훨씬 줄어든다.

■ 영역 6) 효율성 — 무거운 사이트는 '느린 사이트'이기 전에 '차별하는 사이트'다

효율성은 '사이트가 가벼워서 빨리 뜨는가'를 본다. 페이지를 띄우는 데 받아야 하는 파일(이미지·스크립트·글꼴 등)의 크기와 수, 그리고 핵심 화면이 뜨는 데 걸리는 시간 같은 걸 본다.

가장 흔한 실수는 '큰 이미지 그대로 올리기'다. 한중앙부처의 한 페이지를 열어보니, 화면에 작게 보이는 썸네일 이미지인데 원본이 어마어마하게 큰 파일이었다. 화면에서는 손톱만 하게 줄여 보여주지만, 실제로는 거대한 원본을 통째로 내려받고 있던 거다. 이런 이미지가 한 페이지에 수십 개면, 그 페이지를 여는 데 받아야 할 데이터가 폭증한다. 만든 사람은 빠른 인터넷 환경에서 보니 모르지만, 데이터가 아까운 환경이나 느린 연결에서 들어오는 시민에게는 '안 열리는 페이지'가 된다.

여기서 꼭 짚고 싶은 게 있다. 무거운 사이트는 단순히 '느린 사이트'가 아니라 '차별하는 사이트'다. 빠른 환경, 좋은 기기를 가진 사람에게는 무거워도 그럭저럭 열린다. 정작 피해를 보는 건 데이터가 제한적이거나, 오래된 기기를 쓰거나, 통신이 느린 지역에 있는 사람이다. 공공 서비스는 바로 그 사람들에게 더 절실한 경우가 많다. 그래서 효율성은 '속도'의 문제처럼 보이지만 실은 '공평'의 문제다. 가벼운 사이트는 더 많은 사람에게 똑같이 도달한다.

두 번째 흔한 실수는 '안 쓰는 스크립트 더미'다. 예전에 넣었다가 지금은 안 쓰는 기능의 코드, 외부에서 가져온 무거운 위젯, 페이지마다 통째로 따라붙는 거대한 라이브러리 — 이런 게 쌓이면 페이지가 무거워진다. 사용자는 화면의 작은 버튼 하나 누르려고 들어왔는데, 보이지도 않는 코드 더미를 잔뜩 내려받고 있는 셈이다.

세 번째는 '화면이 덜컹거리는' 문제다. 페이지가 뜨는 도중에 이미지가 늦게 로드되면서 글이 아래로 밀리고, 광고나 배너가 뒤늦게 끼어들면서 레이아웃이 출렁인다. 사용자가 막 버튼을 누르려는 순간 화면이 출렁여서 엉뚱한 데를 누르게 되는 그 경험, 다들 겪어봤을 거다. 이건 '레이아웃 안정성'이라는 이름으로 효율성 점검에 들어가는데, 사용자 경험을 은근히 갉아먹는 대표적 문제다.

네 번째 흔한 실수는 '글꼴 욕심'이다. 멋을 내려고 글꼴을 여러 종, 여러 굵기로 받아오면, 그 글꼴 파일 하나하나가 다 내려받아야 할 짐이 된다. 한두 종이면 모를까, 욕심을 부려 여러 종을 깔면 페이지가 그만큼 무거워진다. 게다가 글꼴이 늦게 로드되면, 처음엔 기본 글꼴로 보였다가 갑자기 글자가 바뀌면서 화면이 출렁이는 일도 생긴다. 효율성 관점에서 글꼴은 '꼭 필요한 만큼만'이 정답이다.

다섯 번째는 '캐시를 안 쓰는' 경우다. 한 번 받은 이미지나 파일을 사용자의 기기에 잠깐 저장해 두면, 다음에 같은 페이지를 열 때 다시 안 받아도 된다. 이걸 캐시라고 하는데, 설정이 잘못돼 있으면 사용자가 매번 모든 걸 새로 받는다. 같은 로고 이미지를 페이지를 옮길 때마다 또 받고 또 받는 식이다. 캐시 설정은 화면에 전혀 안 보이지만, 제대로 잡아두면 두 번째 방문부터의 속도가 확 빨라진다. 자주 오는 사용자가 많은 공공 사이트일수록 효과가 크다.

효율성은 '빼는 미학'이다. 더 넣어서 좋아지는 게 아니라, 불필요한 걸 덜어내서 좋아진다. 이미지는 화면 크기에 맞게 줄여서, 스크립트는 안 쓰는 걸 걷어내서, 글꼴은 꼭 필요한 굵기만 받아서, 캐시는 제대로 걸어서 — 이렇게 '몸집을 줄이고 영리하게 재사용하는' 작업이 효율성 점수를 끌어올린다. 그리고 그 결과는 더 많은 사람에게 더 빨리 도달하는 사이트다. 한 가지 덧붙이면, 효율성 개선은 '한 번 해두면 오래 가는' 작업이라 가성비가 좋다. 이미지를 한 번 적정 크기로 정리해 두면 그 효과는 그 페이지가 사라질 때까지 계속된다. 들이는 노력에 비해 오래, 그리고 많은 사람에게 돌아오는 투자인 셈이다.

■ 영역 7) 신뢰성 — 가장 안 보이지만 가장 무거운 영역

신뢰성은 '믿고 정보를 맡길 수 있는가'를 본다. 보안이 제대로 갖춰졌는지, 개인정보를 안전하게 다루는지, 통신이 암호화돼 있는지 같은 걸 본다. 7대 영역 중에서 평범한 사용자 눈에 가장 안 보이는데, 사고가 나면 가장 크게 터지는 영역이다.

가장 흔한 실수는 '보안 헤더 누락'이다. 보안 헤더란 서버가 브라우저에게 '이렇게 안전하게 동작해라' 하고 거는 약속 같은 건데, 이게 빠지면 사이트가 여러 공격에 취약해진다. B공공기관 사이트를 점검했더니 기본적인 보안 헤더가 여러 개 빠져 있었다. 화면은 완벽히 멀쩡했다. 문제는 '공격자가 보는 화면'에서 드러난다. 보안 헤더는 평소엔 아무 일도 안 하는 것처럼 보이지만, 누군가 공격을 시도하는 그 순간 사이트를 지키는 방패다. 방패가 없는 줄도 모르고 평화롭게 운영되다가, 한 번의 공격으로 크게 당하는 게 신뢰성 사고의 전형이다.

두 번째는 '개인정보처리방침 미비'다. 시민의 이름·연락처·주민번호 같은 민감한 정보를 받는 페이지인데, 정작 '우리가 이 정보를 어떻게 다루는지'를 밝히는 개인정보처리방침이 없거나, 있어도 찾기 어려운 구석에 숨어 있는 경우다. 신뢰는 '우리가 당신 정보를 이렇게 안전하게 다룹니다'를 투명하게 보여줄 때 생긴다. 그 약속이 안 보이면, 아무리 실제로 잘 관리해도 시민은 불안하다.

세 번째는 '안전하지 않은 입력 처리'다. 검색창이나 입력 폼에 사용자가 넣는 값을 제대로 거르지 않으면, 악의적인 입력이 들어와 사이트를 망가뜨리거나 정보를 빼낼 수 있다. 이건 코드 수준의 문제라 평범한 점검으로는 잘 안 보이지만, 보안 점검에서는 반드시 짚어야 할 부분이다.

네 번째는 '쿠키 보안 설정 누락'이다. 로그인 상태를 유지하는 데 쓰는 쿠키에 보안 옵션이 안 걸려 있으면, 그 쿠키가 가로채일 위험이 커진다. HttpOnly·Secure 같은 작은 설정 하나가 사용자의 로그인 정보를 지키는데, 이게 빠진 사이트가 의외로 많다.

다섯 번째 흔한 실수는 '혼합 콘텐츠'다. 사이트 전체는 안전한 연결(https)을 쓰는데, 그 안에 끼워 넣은 이미지나 스크립트 일부가 안전하지 않은 연결로 불러와지는 경우다. 이렇게 되면 브라우저가 '이 페이지는 완전히 안전하지 않다'는 경고를 띄우거나, 그 안전하지 않은 부분을 아예 안 불러와서 화면이 일부 깨진다. 전체를 안전하게 만들었어도 한 군데가 새면 그 신뢰가 통째로 흔들리는 거다. 신뢰성은 '대부분 안전'으로는 부족하고 '빈틈없이 안전'이어야 의미가 있다.

여섯 번째는 '에러 화면에서 정보가 새는' 경우다. 사이트에 문제가 생겼을 때 뜨는 오류 화면에, 서버 내부 구조나 경로 같은 '안에서만 알아야 할 정보'가 그대로 노출되는 일이 있다. 평범한 사용자에겐 의미 없는 글자지만, 공격을 노리는 사람에게는 '이 사이트가 어떻게 생겼는지'를 알려주는 귀중한 단서가 된다. 오류 화면은 사용자에게 '죄송합니다, 잠시 후 다시 시도해 주세요' 정도만 보여주고, 자세한 내용은 안에서만 기록하는 게 맞다.

신뢰성에서 점수를 지키는 길은 '안 보이는 걸 보이게 만드는 것'부터다. 보안 헤더가 걸려 있는지, 인증서가 멀쩡한지, 쿠키 설정이 안전한지, 혼합 콘텐츠가 없는지 — 전부 화면에는 안 보이지만 점검 도구로는 다 보인다. 그리고 신뢰성은 '한 번 무너지면 회복이 가장 어려운' 영역이다. 개인정보 사고가 한 번 나면, 그 사이트는 '위험한 곳'으로 기억된다. 한 번 잃은 신뢰는 점수표의 숫자처럼 며칠 만에 회복되지 않는다. 그래서 신뢰성만큼은 '사고 나기 전에' 챙겨야 한다. 사고가 난 뒤에 챙기는 신뢰성은 이미 너무 비싸다. 다행히 신뢰성의 많은 부분은 '설정'의 문제라, 한 번 제대로 잡아두면 그다음부터는 자동으로 지켜진다. 보안 헤더를 한 번 걸어두고, 인증서 만료일을 달력에 적어두고, 쿠키 옵션을 한 번 설정해 두면 — 그 보호가 계속 작동한다. 무너지면 회복이 어렵다는 점을 거꾸로 보면, '한 번 잘 세워두면 오래 든든하다'는 뜻이기도 하다.

영역들은 사실 서로 손잡고 있다

■ 한 군데가 새면 옆 칸도 같이 샌다

지금까지 7대 영역을 따로따로 봤지만, 현장에서 보면 이 영역들은 의외로 손을 잡고 있다. 한 곳에서 점수가 깎이는 사이트는 옆 칸에서도 깎이는 경우가 많다. 우연이 아니다. 원인이 겹치기 때문이다.

예를 보자. 색을 눈대중으로 박아 쓰는 사이트(디자인 기초의 문제)는 동시에 색 대비가 미달이라 접근성에서도 깎인다. 큰 이미지를 그대로 올리는 사이트(효율성 문제)는, 그 이미지에 대체 텍스트도 안 달려 있어서 접근성에서도 깎인다. 표준을 안 지킨 마크업(호환성 문제)은 보조기기가 읽기도 어려워서 접근성을 함께 떨어뜨린다. 검색 노출 설정을 방치한 사이트(개방성 문제)는 대개 메타데이터 관리도 부실해서 소셜 공유까지 깨진다.

그래서 '하나의 좋은 습관'이 여러 영역을 동시에 끌어올린다. 이미지를 적정 크기로 줄이면서 대체 텍스트까지 함께 챙기면, 효율성과 접근성이 같이 좋아진다. 표준 마크업으로 정직하게 만들면 호환성과 접근성이 함께 좋아진다. 색·글꼴·간격을 표준으로 묶으면 디자인 준수와 접근성(대비)이 함께 좋아진다. 안전한 연결(https)을 빈틈없이 적용하면 신뢰성과 접속성이 함께 좋아진다. 메타데이터를 정성껏 채우면 개방성과 편의성이 함께 좋아진다. 7대 영역을 '일곱 개의 숙제'로 보면 막막하지만, '몇 개의 좋은 습관'으로 보면 훨씬 다룰 만하다.

이 '연결'을 알면 작업 우선순위를 정할 때도 유리하다. 여러 영역에 동시에 걸치는 작업을 먼저 하면, 한 번의 노력으로 여러 칸의 점수가 같이 오르기 때문이다. 예를 들어 '사이트의 모든 이미지를 점검해 적정 크기로 줄이고 대체 텍스트를 다는' 한 번의 작업은 효율성·접근성을 동시에 끌어올린다. 반대로 한 영역에만 딱 걸치는 작업은 효과가 그 칸에만 머문다. 그래서 '이 작업이 몇 개의 영역에 영향을 주는가'를 따져 우선순위를 매기면, 같은 시간을 들여도 점수표가 더 크게 움직인다. 7대 영역이 서로 손잡고 있다는 사실은, 막막함의 이유가 아니라 효율적으로 일할 수 있는 '지렛대'인 셈이다.

■ 점수표를 보는 진짜 이유

여기서 한 가지 오해를 풀고 싶다. 점수표를 보는 이유는 '점수를 잘 받기 위해서'가 아니다. 점수는 도구일 뿐이다. 진짜 목적은 '우리 사이트가 어디서 누구를 놓치고 있는가'를 아는 거다.

접근성 점수가 낮다는 건 '점수가 낮다'가 아니라 '안 보이고 안 들리는 사용자가 못 쓰고 있다'는 뜻이다. 효율성 점수가 낮다는 건 '느린 환경의 사용자가 못 들어오고 있다'는 뜻이다. 개방성 점수가 낮다는 건 '검색으로 찾아오려던 사람이 못 찾고 돌아갔다'는 뜻이다. 점수 하나하나가 '우리가 놓치고 있는 사람'을 가리키는 손가락이다. 그래서 점수를 올린다는 건 결국 '더 많은 사람에게 닿는다'는 뜻이다. 숫자 게임이 아니라 사람 이야기인 거다.

이걸 기억하면 점검이 '귀찮은 평가'가 아니라 '우리가 누굴 놓쳤는지 알려주는 지도'로 보인다. 그리고 지도가 있으면 길을 찾을 수 있다.

■ '우리만의 문제'가 아니라는 위안

마지막으로 한 가지 위안을 더하고 싶다. 오늘 나열한 실수들을 보면서 '우리 사이트도 거의 다 해당되는데' 하고 속이 철렁했을 수도 있다. 그런데 정말로 괜찮다. 이 실수들은 거의 모든 공공 사이트에 어느 정도씩 있다. 잘 관리되는 사이트라고 '하나도 없는' 게 아니라 '덜 있는' 정도의 차이다. 그러니 '우리만 이래'가 아니라 '다들 이렇고, 다들 하나씩 고쳐 나가는 중'이라고 생각하면 마음이 한결 가볍다.

오히려 이 실수들의 존재를 알게 된 지금 시점이, 그 사이트들 사이에서 한발 앞서 나갈 기회다. 대부분의 사이트가 '몰라서 방치'하고 있을 때, 우리 사이트가 '알고 챙기기' 시작하면 그 차이가 점수표에서 선명하게 드러난다. 누구나 가진 문제를 먼저 알아챈 사람이 먼저 좋아진다. 그게 오늘 이 글을 끝까지 읽은 보람이 되었으면 한다.

그래서 어떻게 시작하나

■ 한꺼번에 다 고치려 하지 말 것

7대 영역을 다 보고 나면, 처음엔 막막할 수 있다. '이걸 다 언제 고치지' 싶은 거다. 그런데 다행히 '다 한꺼번에' 할 필요는 없다. 오히려 한꺼번에 다 하려다 아무것도 못 하는 게 가장 흔한 실패다.

순서를 잡자. 첫째, '큰 사고부터'. 개방성에서 robots.txt가 사이트 전체를 막고 있다거나, 신뢰성에서 인증서가 곧 만료된다거나 하는 건 '큰 사고'다. 이런 건 손이 적게 가면서도 효과가 즉각적이라, 가장 먼저 잡아야 한다. 점수표에서 '빨간 칸'부터 본다.

둘째, '가성비 좋은 것부터'. 이미지에 대체 텍스트 달기, 폼 입력칸에 라벨 연결하기, 색만으로 구분하던 표시에 글자 함께 주기 — 이런 건 손이 거의 안 가는데 접근성 점수를 크게 끌어올린다. 작은 노력으로 큰 점수가 오르는 항목부터 처리하면, 점수가 눈에 띄게 움직여서 동기부여도 된다.

셋째, '기초부터'. 색·글꼴·간격을 표준으로 묶는 일은 당장 점수가 확 오르진 않지만, 그 위에 올리는 모든 작업의 효율을 끌어올린다. 급한 불을 끈 다음에는 이 기초 작업으로 넘어가는 게 정석이다. KRDS의 846규칙이 가장 촘촘하게 다루는 영역이 바로 이 기초와 부품·패턴이다.

이 순서에는 또 하나의 숨은 이점이 있다. '작은 성공을 먼저 만든다'는 점이다. 처음부터 가장 어려운 기초 개편에 손대면, 몇 주가 지나도 점수가 안 움직여서 '이게 효과가 있긴 한 건가' 싶어지고 동력이 떨어진다. 반대로 큰 사고 한두 개와 가성비 좋은 항목 몇 개를 먼저 처리하면, 점수표의 빨간 칸이 눈에 띄게 줄어드는 게 바로 보인다. 그 '보이는 변화'가 다음 작업을 이어갈 힘이 된다. 윗선에 보고할 때도 '이만큼 좋아졌습니다'라고 숫자로 보여줄 수 있으니 설득이 쉽다. 그래서 '큰 사고 → 가성비 → 기초' 순서는 단지 효율의 문제가 아니라, 사람의 의욕을 지켜가며 끝까지 완주하기 위한 순서이기도 하다.

넷째, '혼자 다 짊어지지 말 것'. 7대 영역은 서로 다른 성격이라, 한 사람이 전부 깊이 알기는 어렵다. 디자인은 디자인 담당이, 보안은 보안 담당이, 콘텐츠는 콘텐츠 담당이 각자의 영역에서 조금씩 챙기는 게 현실적이다. 중요한 건 '우리 사이트의 점수표'를 모두가 함께 보는 거다. 같은 점수표를 보고 있으면 '이 빨간 칸은 누가 맡을까'가 자연스럽게 정해진다. 점검 결과를 한 사람의 책상 서랍에만 두지 말고, 관련된 사람들이 함께 보는 '공통의 지도'로 삼는 것 — 그게 7대 영역을 꾸준히 관리하는 가장 현실적인 방법이다.

■ 측정 없이는 개선도 없다

오늘 글을 관통하는 한 문장이 있다면 이거다 — '안 보이면 못 고친다.' 7대 영역에서 점수가 깎이는 실수 대부분은 '몰라서' 생긴 일이다. 보안 헤더가 빠진 걸 몰랐고, robots.txt가 막힌 걸 몰랐고, 이미지가 무거운 걸 몰랐고, 대체 텍스트가 없는 걸 몰랐다. 화면이 멀쩡하니까, 문제가 있다는 걸 인지할 길이 없었던 거다.

측정의 또 다른 힘은 '변화를 추적할 수 있다'는 데 있다. 한 번 점검해서 점수를 알아두면, 몇 달 뒤 다시 점검했을 때 '좋아졌는지 나빠졌는지'가 보인다. 새 페이지를 잔뜩 붙였더니 효율성이 떨어졌다거나, 접근성을 챙겼더니 점수가 올랐다거나 하는 변화가 숫자로 남는다. 이 '변화의 기록'이 있으면, 우리가 하는 작업이 실제로 효과가 있는지를 확인할 수 있다. 막연히 '좋아졌겠지'가 아니라, '지난번 68점에서 이번에 79점'처럼 또렷하게 보인다. 개선은 한 번에 끝나는 일이 아니라 꾸준히 쌓는 일인데, 그 '쌓임'을 눈으로 확인할 수 있어야 계속할 힘이 난다.

그리고 측정은 '설득의 언어'이기도 하다. 사이트를 고치려면 보통 예산과 시간이 필요하고, 그걸 받으려면 윗선을 설득해야 한다. 그때 '우리 사이트가 좀 불편한 것 같아요'라는 느낌보다, '7대 영역 중 접근성과 신뢰성이 특히 낮고, 이걸 고치면 이만큼의 시민이 더 닿습니다'라는 측정 결과가 훨씬 힘이 세다. 숫자는 부서 간 회의에서도, 보고에서도, 외주 발주에서도 공통의 언어가 된다. 측정이 단순히 '현재 상태 확인'을 넘어, 개선을 실제로 굴러가게 만드는 '연료'인 이유다.

그래서 첫걸음은 늘 '측정'이다. 우리 사이트가 7대 영역에서 지금 어디쯤 와 있는지, 어떤 칸이 빨갛고 어떤 칸이 파란지를 '눈으로 보는 것'부터 시작해야 한다. 느낌이 아니라 숫자로. 보이기 시작하면 우선순위가 잡히고, 우선순위가 잡히면 하나씩 고칠 수 있다. 보이지 않는 문제는 영원히 안 고쳐진다. 측정이 개선의 출발점인 이유다.

마무리

■ 오늘 이야기를 한 문장으로

오늘 이야기를 한 문장으로 줄이면 이렇다 — '멀쩡해 보이는 사이트도 7대 영역으로 뜯어보면 곳곳에서 점수가 조용히 새고 있고, 그 대부분은 몰라서 못 고친 것뿐이다.'

호환성에서는 '제 환경에선 멀쩡한데요'의 함정에 빠지고, 접근성에서는 안 보이는 사용자를 깜빡하고, 개방성에서는 문을 통째로 잠가버리고, 접속성에서는 한가할 때만 보고 안심하고, 편의성에서는 '우리 직원은 다 찾던데요'로 착각하고, 효율성에서는 무거운 이미지로 느린 환경의 사용자를 밀어내고, 신뢰성에서는 안 보이는 방패가 없는 줄도 모르고 지낸다. 전부 '악의 없는 실수'다. 그래서 자책할 일이 아니라, 알아보고 고치면 되는 일이다.

그리고 이 모든 실수의 공통 해법은 결국 '보이게 만드는 것'이다. 화면 뒤에 숨은 점수의 누수를 눈앞에 꺼내 놓는 것. 그게 되면 나머지는 의외로 술술 풀린다.

■ 우리 사이트는 7대 영역에서 몇 점일까

여기까지 읽으면서 '우리 사이트는 어디서 새고 있을까'가 궁금해졌다면, 직접 한번 확인해 보길 권한다. ViewCheck(krds.viewcheck.co.kr)에서 사이트 주소만 넣으면 무료로 진단을 체험할 수 있다. KRDS 846규칙(DS 120 + CP 446 + BP 108 + SP 172)에 따른 디자인 준수는 물론, 오늘 이야기한 7대 품질 영역 — 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성 — 까지 한 번에 점검해서, 화면에 안 보이던 누수들을 '일곱 칸짜리 점수 카드'로 한눈에 보여준다.

거창한 준비도, 설치도 필요 없다. 주소 하나 넣고 결과를 기다리면, '아 여기가 빨갰구나'가 눈에 들어온다. 그 한 장의 점수 카드가, 오늘 글에서 말한 '안 보이던 구멍'을 보이게 만드는 첫걸음이다. 보이기 시작하면 절반은 해결된 거라고 했던 그 절반, 무료 진단으로 가볍게 시작해 보시면 좋겠다.

한 가지 덧붙이자면, 처음 진단 결과를 받았을 때 점수가 생각보다 낮게 나와도 너무 낙담하지 않으셨으면 한다. 앞서 말했듯 이건 거의 모든 사이트가 겪는 일이고, 낮은 점수는 '우리 사이트가 나쁘다'는 선고가 아니라 '여기부터 손대면 된다'는 안내다. 오히려 점수가 낮게 나온 칸이 많다는 건, 그만큼 '작은 노력으로 크게 좋아질 여지'가 많다는 뜻이기도 하다. 이미 만점인 칸은 더 올릴 데가 없지만, 비어 있는 칸은 채울수록 눈에 띄게 좋아진다. 그러니 첫 진단의 빨간 칸들은 '부끄러움'이 아니라 '기회의 목록'으로 받아들이시면 좋겠다. 그 목록을 위에서부터 하나씩 지워 나가는 게, 오늘 글이 권하는 가장 현실적인 시작이다.

그리고 혼자만 보지 말고, 그 점수 카드를 함께 일하는 분들과 나눠 보시길 권한다. 디자인·개발·콘텐츠·보안 담당이 같은 화면을 보면, '이 빨간 칸은 내가 챙길게요'가 자연스럽게 정해진다. 한 사람이 일곱 영역을 다 짊어지는 건 부담스럽지만, 일곱 영역을 여럿이 나눠 보면 각자의 몫은 가볍다. 점검 결과 한 장이 그렇게 '우리 팀의 공통 지도'가 되는 순간, 사이트 품질 관리는 비로소 '누군가의 숙제'에서 '함께 가꾸는 일'로 바뀐다.

다음 글에서는 오늘 가장 많이 새던 영역인 '접근성'을 따로 떼어, 어떤 항목들이 어떻게 점검되는지를 더 깊이 들여다보려 한다. 오늘은 7대 영역의 전체 지도를 그렸으니, 다음엔 그중 가장 자주 길을 잃는 골목을 함께 걸어보자.