공공웹 품질, 정부는 이 7가지로 본다 (행안부 지침 쉽게)

공감·문제제기

"우리 사이트, 품질 점검은 통과했어요?"

연초 업무보고 자리에서 이 질문을 받고 잠깐 말문이 막힌 적이 있다. 분명 작년에 사이트를 새로 개편했고, 외주 업체도 꽤 이름 있는 곳이었고, 오픈할 때 별 탈도 없었다. 그런데 "품질 점검을 통과했냐"고 물으면, 막상 "네, 통과했습니다"라고 자신 있게 답하기가 어려웠다. 통과의 기준이 뭔지부터가 흐릿했기 때문이다.

공공웹 담당자라면 한 번쯤 비슷한 경험이 있을 거다. '품질'이라는 말은 다들 쓰는데, 정작 그 품질을 무엇으로, 어떤 잣대로 재는지를 명확하게 설명할 수 있는 사람은 의외로 드물다. 누구는 '디자인이 깔끔하면 품질이 좋은 것'이라 하고, 누구는 '에러 없이 잘 돌아가면 됐지'라고 한다. 또 누구는 '접근성만 통과하면 되는 거 아니냐'고 한다. 다 일리는 있는데, 다 일부분일 뿐이다.

사실 우리나라에는 공공 웹사이트의 품질을 어떻게 봐야 하는지를 정리한 공식 기준이 이미 있다. 행정안전부가 정한 「전자정부 웹사이트 품질관리 지침」이다. 이름이 길고 딱딱해서 그렇지, 핵심은 의외로 단순하다. '공공 웹사이트가 잘 만들어졌는지를 일곱 가지 측면에서 본다'는 것이다. 그 일곱 가지가 바로 호환성, 접근성, 개방성, 접속성, 편의성, 효율성, 신뢰성이다.

나도 처음 이 일곱 단어를 봤을 때 솔직히 머리가 지끈거렸다. 단어 하나하나는 다 아는 말인데, 막상 '접속성과 효율성이 뭐가 다르지?' '개방성은 또 무슨 소리야?' 하고 헷갈렸다. 비슷비슷해 보이는 단어들이 줄지어 있으니, 외워야 할 또 하나의 행정 용어 묶음처럼 느껴졌다. 그런데 하나하나 뜯어보고 나니 생각이 바뀌었다. 이 일곱 가지는 따로 노는 추상 개념이 아니라, '사용자가 사이트에 들어와서 목적을 이루기까지' 거쳐야 하는 단계들을 빠짐없이 짚은, 꽤 잘 짜인 체크리스트였다.

이 글은 그 일곱 가지를 처음 접하거나, 이름은 들어봤지만 실체가 흐릿한 공공웹 담당자를 위한 입문 글이다. 전문 용어를 최대한 일상 비유로 풀어서, '아, 이게 그 소리였구나' 하고 감을 잡을 수 있게 쓰려고 한다. 개발자가 아니어도, 디자인 전공자가 아니어도 괜찮다. 사이트 하나 운영해본 사람이라면, 또는 운영을 앞두고 막막한 사람이라면 충분히 따라올 수 있는 이야기다.

미리 결론부터 말하면 이렇다. 공공웹 품질은 '디자인이 예쁘냐' 하나로 결정되는 게 아니다. 잘 열리는가(호환성), 누구나 쓸 수 있는가(접근성), 정보가 잘 공개돼 있는가(개방성), 끊김 없이 접속되는가(접속성), 쓰기 편한가(편의성), 빠른가(효율성), 믿을 수 있는가(신뢰성) — 이 일곱 축이 골고루 받쳐줘야 '품질이 좋다'고 말할 수 있다. 어느 한 축만 잘하고 나머지가 무너지면, 사용자는 결국 그 무너진 지점에서 떠난다.

조금 더 솔직하게 풀어보자. 공공 웹 담당자라는 자리는 묘하게 외롭다. 디자인이면 디자인, 보안이면 보안, 성능이면 성능 — 각 분야엔 전문가가 따로 있는데, 정작 그 모든 걸 '하나의 사이트'로 묶어 책임지는 건 담당자 한 명인 경우가 많다. 외주 업체는 자기가 맡은 부분만 "문제없습니다"라고 하지만, 그 조각들을 합쳤을 때 사이트 전체가 '품질 좋은 서비스'가 되는지는 누구도 보장해주지 않는다. 그 빈틈을 메우라고 만들어진 게 바로 이 7대 품질 영역이다. '조각이 아니라 전체를 보라'는 신호인 셈이다.

그리고 이 7대 영역은 KRDS와도 떼어놓고 볼 수 없다. 지난 글들에서 KRDS가 '공공 웹을 일관되고 쓰기 쉽게 만드는 디자인 시스템'이라고 설명했는데, 그 KRDS를 잘 지키면 7대 품질 영역의 상당 부분이 자연스럽게 따라온다. 거꾸로 7대 영역을 점검하다 보면 '아, 여기는 KRDS 기준을 안 지켜서 무너졌구나' 하는 지점이 보인다. 둘은 한 몸처럼 맞물려 돌아간다. 그래서 이번 주는 KRDS 입문의 연장선에서, '정부는 공공웹 품질을 대체 무엇으로 보는가'를 이 일곱 개의 창문으로 들여다보려 한다.

이 글의 흐름을 미리 일러두면 이렇다. 먼저 '품질을 일곱 가지로 나눠 본다는 것'이 왜 합리적인지를 비유로 풀고, 일곱 영역을 하나씩 일상 언어로 설명한다. 그다음 이 일곱 가지가 KRDS 846규칙과 어떻게 연결되는지, 어디서 자주 무너지는지를 익명 사례로 보여준다. 마지막으로 '그래서 우리는 무엇부터 점검하면 되는지'를 실무 단계로 정리한다. 처음부터 끝까지 '어려운 행정 용어를 쉬운 비유로 바꾸는 것'을 원칙으로 삼았으니, 편하게 읽어 내려가면 된다.

왜 '일곱 가지'로 나눠서 보는가

■ 품질은 한 덩어리가 아니라 여러 결의 합이다

'품질이 좋다'는 말은 사실 굉장히 뭉뚱그린 표현이다. 음식점을 떠올려보자. '이 식당 좋아'라고 할 때, 그 '좋다' 안에는 여러 가지가 섞여 있다. 음식 맛, 위생, 가격, 서비스, 접근성(주차나 위치), 분위기, 대기 시간... 이 중 하나만 좋아서는 '좋은 식당'이 되기 어렵다. 맛은 끝내주는데 위생이 엉망이면 못 간다. 다 좋은데 너무 멀어서 갈 수가 없어도 마찬가지다. 결국 '좋다'는 건 여러 결의 평가가 합쳐진 결과다.

공공 웹사이트도 똑같다. '이 사이트 품질 좋아'라는 한마디 안에는, 사실 따져봐야 할 여러 측면이 뭉쳐 있다. 정부가 그 뭉친 덩어리를 일곱 개의 결로 풀어놓은 게 바로 7대 품질 영역이다. 한 덩어리로 보면 '좋다/나쁘다'밖에 말할 수 없지만, 일곱 결로 나눠 보면 '디자인은 좋은데 속도가 느리다' '보안은 탄탄한데 접근성이 약하다'처럼 구체적으로 진단할 수 있다. 진단이 구체적이어야 처방도 구체적이다.

이게 왜 중요하냐면, 막연한 '우리 사이트 좀 별로인 것 같아'라는 느낌은 아무것도 바꾸지 못하기 때문이다. 느낌은 행동으로 이어지지 않는다. 하지만 '우리 사이트는 효율성 점수가 특히 낮고, 그중에서도 이미지 용량이 문제다'라고 짚이면, 그때부터는 할 일이 보인다. 일곱 영역으로 나눈다는 건 결국 '막연한 불안을 구체적인 할 일 목록으로 바꾸는 도구'를 손에 쥐는 것과 같다.

조금 더 깊이 들어가 보자. '나눠서 본다'는 행위 자체가 사실 굉장히 실용적인 발명이다. 병원에서 종합검진을 받을 때를 떠올려보자. 의사가 "건강이 안 좋네요"라고만 말하면, 우리는 무엇을 해야 할지 모른다. 하지만 "혈압은 정상인데 콜레스테롤이 높고, 간 수치가 약간 올라 있습니다"라고 하면, 그때부터는 행동이 가능해진다. 식단을 바꾸고, 운동을 늘리고, 특정 수치를 추적할 수 있게 된다. 7대 품질 영역은 공공 웹의 종합검진표 같은 것이다. 한 덩어리의 '건강'을 일곱 개의 검사 항목으로 풀어, 어디가 약하고 어디가 튼튼한지를 수치로 보여준다.

그리고 '나눠서 본다'는 건 책임을 나눌 수 있게 해준다는 점에서도 중요하다. 사이트 전체를 한 덩어리로 보면, 문제가 생겼을 때 '누가 책임질 일인가'가 흐려진다. 하지만 효율성 문제라면 인프라·자원 담당이, 접근성 문제라면 화면 제작 담당이, 신뢰성 문제라면 보안 담당이 — 영역별로 책임 주체가 또렷해진다. 막연한 '다 같이 잘하자'보다, 영역별로 '여기는 누가 챙긴다'가 정해질 때 일이 실제로 굴러간다. 일곱 영역이라는 칸막이는 일을 복잡하게 만드는 게 아니라, 오히려 책임을 또렷하게 만들어 일을 단순하게 한다.

또 하나, 일곱 영역으로 나눠 보면 '과잉 투자'와 '과소 투자'를 함께 잡아낼 수 있다. 어떤 기관은 디자인에만 막대한 비용을 쏟고 효율성·접근성은 손도 안 댄다. 어떤 기관은 보안에만 신경 쓰고 편의성은 방치한다. 한 영역에 자원이 쏠려 있으면, 다른 영역의 빈자리가 더 도드라진다. 일곱 영역의 점수를 한 줄로 늘어놓고 보면, '어디에 더 쓰고 어디는 그만 써도 되는지'가 한눈에 보인다. 자원이 한정된 공공 영역일수록 이 균형 감각이 중요하다.

■ 일곱 영역은 '사용자의 여정'을 따라간다

이 일곱 가지가 왜 하필 이 일곱 가지인지, 처음엔 임의로 묶어놓은 것처럼 보일 수 있다. 그런데 사용자가 사이트를 쓰는 순서대로 따라가 보면, 의외로 자연스럽게 배열돼 있다는 걸 알게 된다.

사용자가 어떤 공공 서비스를 이용한다고 해보자. 먼저 사용자는 자기 기기와 브라우저로 사이트를 '연다'. 이때 화면이 깨지지 않고 제대로 떠야 한다 — 이게 호환성이다. 다음으로, 그 사용자가 시각장애가 있든 손이 불편하든 누구든 '조작할 수 있어야' 한다 — 이게 접근성이다. 그리고 사이트가 검색엔진이나 외부에서도 잘 '발견되고 연결돼야' 한다 — 이게 개방성이다.

이어서 사용자가 접속을 시도했을 때 '끊기지 않고 안정적으로 연결돼야' 하고(접속성), 막상 들어가서는 '헤매지 않고 편하게 써야' 하며(편의성), 그 과정이 '답답하지 않게 빨라야' 한다(효율성). 마지막으로, 사용자가 개인정보를 입력하거나 중요한 신청을 할 때 '이 사이트를 믿어도 되는가'가 받쳐줘야 한다(신뢰성).

이렇게 늘어놓고 보면, 일곱 영역은 그냥 나열된 항목이 아니라 '사용자가 사이트에 도착해서 목적을 이루고 떠나기까지의 전 과정'을 빠짐없이 훑는 점검표라는 게 드러난다. 어느 한 단계에서 막히면 사용자는 거기서 멈춘다. 화면이 깨지면(호환성) 시작도 못 하고, 조작이 안 되면(접근성) 진행을 못 하고, 너무 느리면(효율성) 기다리다 떠나고, 못 믿겠으면(신뢰성) 정보 입력을 포기한다. 그래서 '일곱 영역 골고루'가 중요하다는 말이, 막연한 구호가 아니라 사용자 여정의 현실인 것이다.

이 '여정'의 관점을 한 번 더 밀고 가보자. 사용자가 어떤 단계에서 막히면, 그 막힘은 단지 그 사람 한 명의 불편으로 끝나지 않는다. 막힌 사용자는 전화 문의를 하거나, 직접 기관을 방문하거나, 민원을 넣는다. 즉 웹에서 막힌 일이 오프라인의 비용으로 전가된다. 콜센터가 바빠지고, 창구에 줄이 길어지고, 담당 부서의 업무가 늘어난다. 그래서 일곱 영역을 챙기는 일은 '사용자 친절'의 문제이기도 하지만, 동시에 '기관 내부의 업무 부담을 줄이는' 일이기도 하다. 웹에서 한 사람이 스스로 일을 끝내면, 그만큼 오프라인의 일손이 줄어든다.

또 하나 흥미로운 건, 이 일곱 단계가 '앞 단계가 무너지면 뒤 단계는 의미가 없어지는' 순서로 쌓여 있다는 점이다. 화면이 아예 안 뜨면(호환성 실패) 그 뒤의 편의성이나 효율성은 따질 기회조차 없다. 접속이 안 되면(접속성 실패) 아무리 디자인이 좋아도 볼 수가 없다. 그래서 일곱 영역은 '동등하게 나열된' 듯 보이지만, 실은 일종의 우선순위 사다리이기도 하다. 가장 아래의 '열림·연결'이 받쳐줘야 그 위의 '편함·빠름·믿음'이 의미를 가진다. 이 사다리 구조를 이해하면, 한정된 자원을 어디부터 투입해야 할지 감이 잡힌다.

■ KRDS와 7대 영역은 한 몸이다

여기서 잠깐, 지금까지 다뤄온 KRDS와 이 7대 품질 영역의 관계를 정리하고 가자. 둘을 별개의 숙제로 오해하면 일이 두 배로 느껴지기 때문이다.

KRDS는 '어떻게 만들 것인가'에 대한 설계 기준이다. 색은 어떻게, 버튼은 어떻게, 폼 흐름은 어떻게, 서비스 여정은 어떻게 — 공공 웹을 구성하는 요소를 DS(120)·CP(446)·BP(108)·SP(172) 네 영역, 총 846개 규칙으로 정리해둔 디자인 시스템이다. 한편 7대 품질 영역은 '잘 만들어졌는가'를 평가하는 진단의 틀이다. 만드는 기준과 평가하는 틀, 둘은 동전의 양면이다.

그리고 이 둘은 실제로 맞물린다. 예를 들어 KRDS가 정한 버튼·폼·내비게이션 규칙(CP·BP)을 잘 지키면, 사용자가 헤매지 않으니 편의성이 올라간다. KRDS의 접근성 관련 요구를 지키면 7대 영역의 접근성이 따라 올라간다. KRDS의 시각 기본 단위(DS)를 토큰으로 잘 관리하면 페이지가 가벼워져 효율성에 도움이 된다. 즉 KRDS를 잘 지키는 것 자체가 7대 품질의 상당 부분을 끌어올리는 지름길이다.

거꾸로도 성립한다. 7대 영역을 점검해서 '편의성이 낮다'가 나오면, 그 원인을 추적하다 보면 결국 KRDS의 어떤 컴포넌트·패턴 규칙을 안 지킨 지점에 닿는 경우가 많다. 그래서 '7대 영역 점검 결과'와 'KRDS 846규칙 점검 결과'를 함께 보면, 무엇이 잘못됐고(7대 영역) 왜 잘못됐는지(KRDS 규칙)가 한 번에 맞춰진다. 증상과 원인을 동시에 보는 셈이다. 이 글의 뒷부분에서 자동 진단 이야기를 꺼내는 것도 이 때문이다 — 두 점검을 따로 돌리면 비효율적이라서다.

일곱 영역을 하나씩 쉽게 풀어보자

■ 호환성 — 어느 문으로 들어와도 똑같이 열려야 한다

호환성은 가장 직관적인 영역이다. 한마디로 '어떤 환경에서 열어도 화면이 똑같이, 제대로 보여야 한다'는 것이다. 여기서 환경이란 브라우저 종류(크롬, 엣지, 사파리, 파이어폭스 등), 기기(PC, 태블릿, 스마트폰), 운영체제 같은 것들을 말한다.

비유하자면 호환성은 '건물의 출입문'이다. 정문으로 들어오든 옆문으로 들어오든, 안에 들어왔을 때 같은 로비를 만나야 한다. 그런데 어떤 사이트는 크롬에서는 멀쩡한데 사파리에서는 레이아웃이 와장창 깨진다. 어떤 페이지는 PC에서는 보이는데 스마트폰에서는 버튼이 화면 밖으로 삐져나가 누를 수가 없다. 정문으로 들어온 사람은 멀쩡한 로비를 보는데, 옆문으로 들어온 사람은 공사판을 마주하는 격이다.

공공 서비스에서 호환성이 특히 중요한 이유는, 사용자가 어떤 기기·브라우저를 쓸지 '선택할 수 없기' 때문이다. 민간 서비스라면 '크롬에서 가장 잘 보입니다' 같은 안내를 붙이고 사용자에게 권할 수도 있다. 하지만 공공 서비스는 '낡은 PC를 쓰는 어르신'도, '오래된 폰을 쓰는 사람'도 다 받아야 한다. 특정 환경을 강요할 수 없으니, 모든 주요 환경에서 동작하도록 만들어야 한다.

기술적으로 호환성은 '웹 표준을 지켰는가'와 깊이 연결된다. HTML과 CSS를 표준에 맞게 작성하면, 표준을 따르는 모든 브라우저에서 일관되게 동작할 확률이 높아진다. 반대로 특정 브라우저에서만 통하는 비표준 방식으로 만들면, 다른 브라우저에서 깨질 위험이 커진다. KRDS가 표준 컴포넌트와 표준 마크업을 강조하는 이유도 여기에 있다. 표준을 지키는 것 자체가 호환성의 토대다. 즉 호환성은 '여러 브라우저에서 일일이 잘 보이게 손보는 노동'이라기보다, '처음부터 표준대로 만들어 깨질 일을 줄이는 설계'의 문제에 가깝다.

호환성에는 '반응형'이라는 또 다른 얼굴이 있다. 같은 사이트를 PC의 넓은 화면에서 보느냐, 스마트폰의 좁은 화면에서 보느냐에 따라 레이아웃이 알아서 적절히 바뀌어야 한다. PC에서는 가로로 넓게 펼쳐지던 메뉴가, 스마트폰에서는 접혀서 '햄버거 버튼' 안으로 들어가는 식이다. 이게 잘 안 되면, 스마트폰에서 글자가 너무 작아 돋보기를 켜야 하거나, 가로로 스크롤을 해야 내용을 볼 수 있거나, 버튼이 너무 작아 손가락으로 누르기가 어렵다. 특히 공공 서비스는 스마트폰으로 접속하는 비중이 점점 커지고 있어서, '작은 화면에서도 멀쩡한가'는 호환성의 핵심 중 핵심이다. 손가락으로 누르는 버튼이 충분히 큰지, 글자가 읽을 만한 크기인지 같은 건 '작은 배려'처럼 보이지만, 작은 화면 사용자에겐 '쓸 수 있다/없다'를 가르는 문제다.

여기서 한 가지 오해를 풀고 가자. 사람들은 호환성을 '모든 브라우저에서 픽셀 하나까지 똑같이 보이게 하는 것'으로 생각하곤 한다. 하지만 그건 현실적이지도 않고 필요하지도 않다. 호환성의 진짜 목표는 '똑같이'가 아니라 '제대로'다. 어느 환경에서 열든 정보를 읽을 수 있고, 기능을 쓸 수 있고, 흐름이 깨지지 않으면 된다. 색조가 미세하게 다르거나 여백이 약간 차이 나는 건 문제가 아니다. 버튼을 못 누르거나, 글자가 겹쳐 안 읽히거나, 메뉴가 사라지는 게 문제다. 이 구분을 해두면, 호환성 점검에서 무엇을 중하게 보고 무엇을 넘겨도 되는지 판단이 선다.

■ 접근성 — 한 사람도 문 앞에서 돌려보내지 않는다

접근성은 일곱 영역 중에서도 무게가 남다른 영역이다. 다른 영역들이 주로 '얼마나 편하고 빠른가'의 문제라면, 접근성은 '아예 쓸 수 있는가, 없는가'의 문제이기 때문이다. 어떤 사용자에게는 접근성이 부족하면 불편한 정도가 아니라, 그 서비스를 '전혀' 이용하지 못하게 된다.

쉬운 비유로, 접근성은 '건물의 경사로와 점자블록'이다. 계단만 있는 건물은 휠체어를 탄 사람에게 '들어오지 마라'고 말하는 것과 같다. 시각장애인을 위한 점자블록과 음성 안내가 없는 공간은, 그들에게는 미로다. 웹에서도 똑같은 일이 벌어진다. 화면을 못 보는 사용자는 '화면 읽기 프로그램(스크린 리더)'으로 사이트를 소리로 듣는데, 이미지에 대체텍스트가 없으면 그 이미지는 '무명의 이미지'로 읽혀 아무 정보도 전달하지 못한다. 마우스를 못 쓰는 사용자는 키보드만으로 조작하는데, 키보드로 닿지 않는 버튼은 그 사람에게 '없는 버튼'이다.

여기서 중요한 건, 웹 접근성이 '권장 사항'이 아니라 '법적 의무'라는 점이다. 우리나라에는 웹 접근성을 보장하도록 하는 법적 근거가 있고, 공공기관은 이를 더 엄격하게 지켜야 한다. 그래서 접근성은 '여유 되면 챙기는 것'이 아니라 '반드시 충족해야 하는 것'이다. 점검 기준으로는 한국형 웹 콘텐츠 접근성 지침인 KWCAG가 쓰이는데, 색 대비, 대체텍스트, 키보드 조작, 명확한 라벨, 초점 표시 같은 항목들이 33개 항목으로 정리돼 있다.

KRDS와 접근성의 연결도 단단하다. KRDS는 컴포넌트마다 '이 부품은 이렇게 만들면 접근성이 보장된다'는 기준을 품고 있다. 버튼에 적절한 이름표(라벨)를 붙이고, 폼 입력칸에 설명을 연결하고, 색만으로 정보를 전달하지 않게 하는 것 — 이런 게 모두 KRDS 컴포넌트 규칙 안에 녹아 있다. 그래서 KRDS를 충실히 따르면 접근성의 상당 부분이 자동으로 채워진다. '디자인 따로, 접근성 따로'가 아니라, 잘 만든 디자인 안에 접근성이 이미 들어 있는 구조다. 접근성을 나중에 덧붙이는 '장식'으로 보지 말고, 처음부터 설계에 녹아 있는 '구조'로 봐야 하는 이유다.

접근성을 이야기할 때 빠지지 않는 오해가 하나 있다. '접근성은 장애인을 위한 것'이라는 생각이다. 물론 장애가 있는 사용자에게 접근성은 절대적으로 중요하다. 하지만 접근성이 좋은 사이트는 사실 '모두에게' 좋다. 색 대비가 충분한 사이트는 햇빛 아래에서 스마트폰을 보는 사람에게도 잘 읽힌다. 키보드로 조작할 수 있는 사이트는 마우스가 고장 난 사람에게도 유용하다. 명확한 라벨과 안내가 있는 사이트는 디지털에 서툰 어르신에게도 친절하다. 즉 접근성을 챙기는 일은 '소수를 위한 배려'를 넘어 '다수의 사용성'까지 함께 끌어올리는 일이다. 가장 약한 고리에 맞춰 설계하면, 강한 고리는 자연히 함께 편해진다.

접근성이 무너지는 흔한 장면도 몇 개 짚어두자. 첫째, 이미지로 만든 글자다. 멋진 안내문을 이미지 한 장으로 만들어 올리면, 보기엔 예쁘지만 화면 읽기 프로그램은 그걸 '읽지' 못한다. 둘째, 색깔만으로 구분한 정보다. '빨간색은 마감, 초록색은 접수 중'처럼 색에만 의존하면, 색을 구분하기 어려운 사용자는 그 정보를 놓친다. 색과 함께 글자나 모양으로도 구분해줘야 한다. 셋째, 초점이 보이지 않는 경우다. 키보드로 화면을 이동할 때 '지금 어디에 있는지'가 시각적으로 표시돼야 하는데, 이게 빠지면 키보드 사용자는 길을 잃는다. 이런 항목들이 KWCAG 33항목에 구체적으로 담겨 있고, KRDS 컴포넌트 규칙은 이를 부품 단위에서 미리 막아준다.

■ 개방성 — 정보가 갇혀 있지 않고 잘 통해야 한다

개방성은 일곱 영역 중에서 가장 생소하게 느껴지는 단어일 거다. '개방'이라니 무슨 정보 공개법 같은 건가 싶지만, 웹 품질에서의 개방성은 조금 더 구체적이다. '사이트의 정보가 외부에서도 잘 발견되고, 잘 연결되고, 기계도 이해할 수 있게 정리돼 있는가'를 본다.

비유하자면 개방성은 '건물의 간판과 안내판'이다. 아무리 좋은 가게라도 간판이 없으면 사람들이 찾아오지 못한다. 검색엔진은 인터넷 세상의 길 안내자인데, 사이트가 검색엔진에게 자기를 제대로 알리지 못하면 '있어도 없는 것처럼' 묻힌다. 그래서 개방성은 검색엔진이 사이트를 잘 읽어갈 수 있도록, 페이지마다 제목과 설명을 잘 달아두고, 어떤 페이지가 있는지 목록(사이트맵)을 제공하고, 어디까지 수집해도 되는지 규칙(robots 파일)을 명확히 해두는 일과 연결된다.

또 개방성에는 '메타데이터' 이야기가 빠지지 않는다. 메타데이터는 '데이터에 대한 데이터', 즉 페이지의 제목·설명·대표 이미지 같은 '이 페이지가 무엇에 관한 것인지'를 기계가 알아볼 수 있게 정리한 정보다. 이게 잘 돼 있으면 검색 결과에도 깔끔하게 노출되고, 메신저나 SNS에 링크를 붙였을 때도 제목과 미리보기가 제대로 뜬다. 반대로 이게 비어 있으면, 링크를 공유했을 때 정체불명의 회색 박스만 뜨거나 엉뚱한 텍스트가 노출된다.

공공 서비스에서 개방성이 중요한 이유는, 정보가 '닿아야 할 사람에게 닿아야' 하기 때문이다. 아무리 중요한 공지나 복지 정보를 올려도, 검색으로 발견되지 않으면 그 정보는 닫힌 서랍 속 서류와 같다. 국민이 필요한 정보를 검색으로 쉽게 찾을 수 있게 하는 것 — 그게 공공 서비스의 개방성이 가진 진짜 의미다. '우리는 정보를 올렸다'와 '국민이 그 정보를 찾을 수 있다'는 전혀 다른 이야기이고, 그 간극을 메우는 게 개방성이다.

개방성의 또 다른 축은 '구조화된 정보'다. 사람은 페이지를 보면 '이건 제목이고, 이건 본문이고, 이건 날짜구나'를 직관적으로 안다. 하지만 기계는 그렇지 않다. 페이지의 정보가 '어디부터 어디까지가 무슨 의미인지' 구조적으로 표시돼 있어야, 검색엔진이나 다른 시스템이 그 의미를 정확히 읽어간다. 제목은 제목답게, 목록은 목록답게, 표는 표답게 — 이렇게 의미에 맞는 구조로 만드는 것이 개방성의 기본이다. 겉보기에 똑같아 보여도, 의미 구조가 잘 짜인 페이지와 그렇지 않은 페이지는 기계가 읽을 때 천지 차이다.

여기서 짚을 게, 개방성은 '아무 정보나 다 공개하라'는 뜻이 아니라는 점이다. 공개해야 할 정보는 잘 발견되게 하되, 보호해야 할 정보(개인정보 등)는 단단히 막는 것 — 이 두 가지가 모순 없이 함께 가야 한다. 개방성과 신뢰성이 충돌하는 게 아니라, '공개할 건 잘 공개하고 막을 건 잘 막는' 분별이 둘을 동시에 만족시킨다. 그래서 개방성을 점검할 때도 '무엇을 열고 무엇을 닫을지'의 규칙(앞서 말한 robots 파일 같은 것)이 명확한지를 함께 본다. 열림과 닫힘의 경계가 또렷한 사이트가 결국 양쪽을 다 잘하는 사이트다.

■ 접속성 — 가려고 하면 언제든 열려 있어야 한다

접속성은 '사용자가 접속하려 할 때 사이트가 안정적으로 열려 있는가'를 본다. 쉽게 말해 '얼마나 안 끊기고, 얼마나 빨리 응답하는가'의 문제다. 효율성과 비슷해 보이지만 결이 다르다. 효율성이 '페이지를 빨리 그려내는가(화면 렌더링)'라면, 접속성은 '서버까지 가는 길이 안정적인가(연결·응답)'에 가깝다.

비유하자면 접속성은 '가게의 영업시간과 입구 상태'다. 24시간 연다고 써놨는데 막상 가보면 문이 잠겨 있거나, 사람이 몰리는 시간엔 입구가 막혀 못 들어간다면, 그건 영업을 안 하는 것과 다를 게 없다. 공공 서비스는 특정 시기에 접속이 폭증하는 경우가 많다. 신청 마감일, 발표일, 모집 개시 시각 같은 때다. 평소엔 멀쩡하다가 정작 사람이 가장 많이 몰리는 그 순간에 사이트가 느려지거나 멈추면, 사용자는 가장 절박한 순간에 문 앞에서 발길을 돌려야 한다.

접속성을 측정할 때 자주 쓰는 개념이 '응답 시간'이다. 사용자가 주소를 입력하고 첫 반응이 올 때까지 걸리는 시간(흔히 TTFB라고 부른다), DNS로 주소를 찾는 시간, 서버와 연결을 맺는 시간, 보안 연결을 맺는 시간 등으로 잘게 나눠 본다. 이 단계 중 어디가 느린지를 알면, 어디를 손봐야 할지가 보인다. 그냥 '느려요'가 아니라 '연결 단계에서 시간이 새고 있어요'처럼 구체적으로 짚을 수 있는 것이다.

공공 서비스에서 접속성은 '있어도 못 쓰면 없는 것'이라는 원칙과 직결된다. 좋은 서비스도 접속이 안 되면 무용지물이다. 그래서 평상시 점검만큼이나 '몰리는 순간을 견디는가'를 함께 보는 게 중요하다. 진단 도구가 응답 시간과 연결 단계를 측정해주는 이유도, 이 '보이지 않는 길의 상태'를 숫자로 드러내기 위해서다.

접속성을 조금 더 풀어보면, '안정성'과 '응답성'이라는 두 결로 나눌 수 있다. 안정성은 '사이트가 멈추지 않고 계속 떠 있는가'이고, 응답성은 '요청했을 때 얼마나 빨리 첫 반응이 오는가'다. 둘 다 사용자 입장에서는 '답답함'으로 체감되지만, 원인과 해법은 다르다. 안정성이 문제면 서버 용량이나 분산 처리를 손봐야 하고, 응답성이 문제면 어디서 시간이 새는지(주소 찾기, 연결 맺기, 보안 연결 맺기 중 어디인지)를 단계별로 쪼개 봐야 한다. 그래서 '느려요'라는 막연한 호소를, '연결 단계에서 0.5초가 새고 있어요'처럼 구체적인 진단으로 바꾸는 게 접속성 점검의 핵심이다.

여기서 효율성과의 차이를 한 번 더 분명히 해두자. 사용자 입장에서 '느리다'는 느낌은 접속성 문제일 수도, 효율성 문제일 수도 있다. 서버까지 가는 길이 막혀 첫 반응이 늦으면 접속성 문제고, 반응은 빨리 왔는데 화면을 그리는 데 오래 걸리면 효율성 문제다. 비유하자면, 식당에 전화를 걸었는데 한참 안 받는 게 접속성 문제라면, 전화는 금방 받았는데 음식이 늦게 나오는 게 효율성 문제다. 둘 다 '느림'이지만, 고쳐야 할 곳이 다르다. 그래서 '느리다'는 한마디를 접속성과 효율성으로 갈라 보는 것만으로도, 무엇을 손봐야 할지가 훨씬 또렷해진다.

■ 편의성 — 헤매지 않고 목적지에 닿게 한다

편의성은 '사용자가 사이트를 쓸 때 얼마나 헤매지 않고 편하게 목적을 이루는가'를 본다. 일곱 영역 중에서 KRDS와 가장 직접적으로 맞물리는 영역이라고 봐도 좋다. 메뉴 구조, 검색 기능, 버튼 배치, 폼 입력 흐름, 오류 안내 — 이런 '쓰기 편함'을 좌우하는 요소들이 모두 여기 들어간다.

비유하자면 편의성은 '매장 안의 동선과 안내 표지'다. 들어갔는데 어디로 가야 할지 모르겠고, 원하는 물건이 어디 있는지 안 보이고, 계산대가 어딘지조차 헷갈리는 매장은 아무리 물건이 좋아도 짜증이 난다. 반대로 동선이 자연스럽고, 표지판이 적절히 붙어 있고, 계산이 매끄러운 매장은 '편하다'는 인상을 남긴다. 웹의 편의성도 똑같다. 사용자가 '다음에 뭘 해야 하지?' 하고 멈추는 순간이 적을수록 편의성이 좋은 것이다.

편의성이 무너지는 흔한 장면들을 떠올려보자. 검색창이 어디 있는지 한참 찾아야 하는 사이트, 신청 양식을 다 채우고 제출을 눌렀더니 '오류' 한 줄만 뜨고 어디가 틀렸는지 안 알려주는 사이트, 메뉴 이름이 내부 행정 용어라 일반 국민은 무슨 뜻인지 모르는 사이트. 이런 것들이 다 편의성의 실패다. 사용자는 '내가 멍청해서 못 하는 건가' 자책하다가, 결국 전화 문의를 하거나 포기한다. 그 부담은 고스란히 콜센터와 담당 부서로 돌아온다.

KRDS의 컴포넌트(CP)·기본 패턴(BP)·서비스 패턴(SP) 규칙은 사실상 이 편의성을 떠받치는 뼈대다. 버튼은 어떻게 생겨야 누를 수 있는 것처럼 보이는지, 오류는 어디에 어떤 말투로 안내해야 하는지, 신청 흐름은 어떤 순서로 짜야 사용자가 끝까지 가는지 — 이 모든 게 KRDS 규칙으로 정리돼 있다. 그래서 '편의성을 높이고 싶다'는 막연한 목표는, KRDS를 따라가다 보면 '구체적으로 무엇을 어떻게 고칠지'로 바뀐다. 편의성은 감각의 문제처럼 보이지만, 실은 지킬 수 있는 기준의 문제다.

편의성에서 특히 자주 간과되는 게 '말의 문제'다. 화면에 쓰이는 문구가 행정 내부 용어로 가득하면, 일반 국민은 그 뜻을 모른다. '교부' '열람' '징구' 같은 단어, 부서명을 그대로 따온 메뉴 이름, 법 조항을 그대로 옮긴 안내문은 담당자에겐 익숙하지만 사용자에겐 외국어다. 좋은 편의성은 '사용자의 언어로 말하는 것'에서 시작한다. 무엇을 하는 버튼인지 한눈에 알 수 있는 라벨, 오류가 났을 때 '무엇이 잘못됐고 어떻게 고치면 되는지'를 사람의 말로 알려주는 안내 — 이런 게 쌓여야 사용자가 헤매지 않는다. KRDS가 컴포넌트의 라벨과 안내 문구까지 기준으로 다루는 이유가 여기에 있다.

또 하나, 편의성은 '사용자가 실수해도 회복할 수 있는가'와 깊이 연결된다. 사람은 누구나 실수한다. 잘못된 항목을 누르고, 입력을 빠뜨리고, 엉뚱한 메뉴로 들어간다. 좋은 사이트는 그 실수를 '되돌릴 수 있게' 해준다. 뒤로 가도 입력한 내용이 날아가지 않고, 잘못 입력하면 어디가 틀렸는지 그 자리에서 알려주고, 중요한 행동을 하기 전엔 한 번 확인을 받는다. 반대로 나쁜 사이트는 작은 실수 하나에 처음부터 다시 하게 만든다. 긴 신청서를 다 채웠는데 마지막에 오류가 나서 전부 날아가는 경험 — 그 한 번이면 사용자는 그 사이트를 포기한다. 편의성은 '잘할 때 편한가'만이 아니라 '실수해도 너그러운가'까지 포함하는 개념이다.

■ 효율성 — 기다리게 하지 않는다

효율성은 '사이트가 얼마나 빠르게 화면을 보여주는가'를 본다. 페이지 로딩 속도, 화면이 그려지는 속도, 사용자가 클릭했을 때 반응하는 속도 같은 것들이 여기 들어간다. 요즘 사용자는 인내심이 짧다. 화면이 몇 초만 안 떠도 '이 사이트 고장났나' 하고 뒤로 가기를 누른다.

비유하자면 효율성은 '음식이 나오는 속도'다. 맛있는 음식점이라도 주문하고 한 시간을 기다려야 한다면 다시 가기 어렵다. 웹도 마찬가지다. 아무리 정보가 알차도, 그 정보가 화면에 뜨기까지 한참 걸리면 사용자는 그 알찬 정보를 보기도 전에 떠난다. 특히 모바일 환경, 그것도 느린 네트워크에서 접속하는 사용자에게 무거운 페이지는 치명적이다.

효율성을 떨어뜨리는 주범은 대개 정해져 있다. 용량이 큰 이미지를 줄이지 않고 그대로 올린 경우, 불필요하게 무거운 스크립트가 잔뜩 들어간 경우, 폰트나 외부 자원을 과하게 불러오는 경우 등이다. 그래서 효율성 점검은 '무엇이 무거운가'를 찾아내는 일이 핵심이다. 이미지가 무거운지, 스크립트가 무거운지, 폰트가 무거운지 — 자원 종류별로 용량을 따져보면 어디서 시간이 새는지 보인다.

효율성을 측정할 때는 흔히 '핵심 웹 지표(Core Web Vitals)'라는 개념을 쓴다. 주요 콘텐츠가 화면에 뜨기까지의 시간, 화면이 갑자기 들썩이지 않고 안정적으로 뜨는지, 사용자의 첫 조작에 얼마나 빨리 반응하는지 같은 지표들이다. 어려워 보이지만, 결국 '사용자 체감 속도'를 숫자로 바꾼 것이다. 공공 서비스에서 효율성은 '공평함'과도 연결된다. 좋은 기기와 빠른 인터넷을 쓰는 사람은 어떤 사이트든 잘 쓰지만, 낡은 기기와 느린 망을 쓰는 사람은 무거운 사이트 앞에서 더 크게 좌절한다. 가벼운 사이트는 그 격차를 줄인다. 효율성은 단순한 '빠름'의 문제가 아니라, '누구에게나 비슷하게 빠른가'의 문제이기도 하다.

효율성에서 자주 놓치는 함정 하나는 '들썩임'이다. 페이지가 뜨는 도중에 광고 배너나 이미지가 뒤늦게 끼어들면서, 읽고 있던 내용이 갑자기 아래로 밀려나는 경험이 있을 거다. 막 누르려던 버튼이 다른 자리로 도망가서 엉뚱한 걸 누르게 되는 그 황당함. 이게 화면 안정성의 문제다. 속도가 빠른 것도 중요하지만, '떠 있는 동안 흔들리지 않는 것'도 그만큼 중요하다. 사용자는 빠르되 안정적인 화면에서 안심하고, 들썩이는 화면에서는 무의식적으로 긴장한다. 효율성을 '체감 속도'라고 부르는 건, 이렇게 숫자로는 잘 안 드러나지만 몸으로 느껴지는 부분까지 포함하기 때문이다.

효율성을 개선할 때 좋은 점은, 비교적 '투자 대비 효과'가 큰 영역이라는 것이다. 무거운 이미지 몇 장만 적절히 줄여도 페이지가 눈에 띄게 가벼워지고, 불필요한 외부 자원 몇 개만 정리해도 로딩이 빨라진다. 디자인을 갈아엎거나 기능을 새로 만드는 큰 공사가 아니라, '무거운 것을 가볍게 다듬는' 비교적 작은 손질로도 체감 효과가 크다. 그래서 '무엇부터 손볼지 막막하다' 싶을 때, 효율성은 빠른 성취감을 주는 좋은 출발점이 되기도 한다. 작은 손질로 점수가 눈에 띄게 오르는 경험은, 다음 영역으로 넘어갈 동력이 된다.

■ 신뢰성 — 안심하고 정보를 맡길 수 있어야 한다

신뢰성은 '이 사이트를 믿고 내 정보를 맡겨도 되는가'를 본다. 보안, 암호화된 연결, 개인정보 보호, 정확한 정보 제공 같은 것들이 여기 들어간다. 공공 서비스는 주민등록번호, 주소, 계좌 정보 같은 민감한 정보를 다루는 경우가 많아서, 신뢰성이 무너지면 그 피해가 단순한 불편을 넘어선다.

비유하자면 신뢰성은 '은행 창구의 안전장치'다. 은행에 돈을 맡길 때 우리는 그 건물의 금고와 보안 시스템을 믿는다. 만약 은행 창구가 누구나 들여다볼 수 있는 유리벽이고, 서류가 아무 데나 굴러다니면, 아무도 거기에 돈을 맡기지 않는다. 웹에서도 똑같다. 사용자가 개인정보를 입력하는 그 순간, 그 정보가 안전하게 암호화돼 전송되는지, 엉뚱한 곳으로 새지 않는지가 신뢰성의 핵심이다.

기술적으로 신뢰성은 '보안 연결(HTTPS)'에서 출발한다. 주소창에 자물쇠 표시가 뜨는 그것이다. 이게 안 돼 있으면 사용자가 입력한 정보가 중간에 노출될 위험이 있다. 여기에 더해 다양한 보안 설정(보안 헤더), 인증서의 유효기간, 쿠키 보안 설정 같은 세부 항목들이 신뢰성을 받친다. 또 '개인정보처리방침' 같은 안내가 제대로 마련돼 있는지, 사용자가 자기 정보가 어떻게 쓰이는지 확인할 수 있는지도 신뢰성의 일부다.

신뢰성에는 보안만이 아니라 '정보의 정확성과 최신성'이라는 결도 있다. 공공 사이트에 올라온 정보는 국민이 '공식 정보'로 받아들인다. 그래서 이미 끝난 공고가 그대로 걸려 있거나, 바뀐 제도가 옛날 내용 그대로 남아 있거나, 끊긴 링크가 방치돼 있으면, 그것 자체가 신뢰를 깎는다. '이 사이트는 관리가 안 되는구나'라는 인상은 보안 사고만큼이나 신뢰에 금을 낸다. 신뢰성은 한 번 잘 만들어두고 끝나는 게 아니라, 꾸준히 관리되고 있다는 '생활감'에서 나온다. 살아 있는 사이트와 방치된 사이트는 사용자가 금방 알아챈다.

공공 서비스에서 신뢰성은 단순한 보안 문제를 넘어 '기관에 대한 믿음'과 직결된다. 한 번 정보 유출 사고가 나면, 그 기관 전체에 대한 국민의 신뢰가 흔들린다. 그래서 신뢰성은 '문제가 없을 때는 티가 안 나지만, 문제가 생기면 모든 걸 잃는' 영역이다. 평소에 보이지 않아도 가장 단단하게 받쳐야 하는 토대인 셈이다. 신뢰성은 화려하게 자랑할 거리는 아니지만, 무너지는 순간 다른 여섯 영역의 노력이 한꺼번에 빛을 잃는다.

신뢰성을 점검할 때 좋은 점은, 상당수가 '있다/없다' '맞다/틀리다'로 비교적 명확하게 판정된다는 것이다. 보안 연결이 돼 있는지, 보안 설정 항목이 켜져 있는지, 인증서가 유효한지, 개인정보처리방침 안내가 있는지 — 이런 건 감각이 아니라 사실의 문제다. 그래서 신뢰성은 자동 진단이 특히 강점을 보이는 영역이기도 하다. 사람이 일일이 보안 설정을 항목별로 확인하는 건 지루하고 놓치기 쉽지만, 도구는 이런 항목들을 빠짐없이, 매번 똑같은 기준으로 점검한다. '티가 안 나서 방치되기 쉬운' 영역일수록, 지치지 않고 들여다보는 도구의 도움이 빛을 발한다.

일곱 영역은 어떻게 무너지는가 (익명 사례)

■ 한 영역만 좋고 나머지가 무너진 사이트

이론으로만 설명하면 잘 와닿지 않으니, 그동안 본 익명 사례들을 몇 개 풀어보겠다. 실제 기관명·도메인은 모두 가리고, 패턴만 추렸다.

한 광역지자체(A광역지자체로 부르자)의 사이트는 디자인이 꽤 세련됐다. 메인 화면만 보면 '잘 만든 사이트'라는 인상을 준다. 그런데 효율성 점검을 돌려보니 점수가 바닥이었다. 원인은 메인 화면을 가득 채운 고화질 배경 이미지와 영상이었다. 보기엔 멋졌지만, 그 멋짐의 대가로 페이지가 무거워져 로딩이 한참 걸렸다. 빠른 인터넷을 쓰는 사람은 몰랐지만, 느린 망을 쓰는 사용자에게는 첫 화면조차 버거웠다. '예쁜데 느린' 전형이다. 디자인 한 축만 잘 챙기고 효율성 축을 놓친 결과였다.

반대 사례도 있다. 한 공공기관(B공공기관)의 사이트는 속도는 빨랐다. 군더더기 없이 가벼웠다. 그런데 접근성 점검에서 무더기로 걸렸다. 이미지에 대체텍스트가 거의 없었고, 폼 입력칸에 라벨 연결이 빠져 있었으며, 색만으로 정보를 구분하는 곳이 많았다. 화면을 보는 사람에겐 멀쩡했지만, 화면을 못 보는 사용자에겐 '들어갈 수 없는 건물'이었다. 빠르지만 누군가에겐 닫혀 있는 사이트인 것이다.

이 두 사례가 말하는 건 명확하다. 품질은 '가장 약한 고리'에서 결정된다는 것이다. 여섯 영역이 100점이어도 한 영역이 0점이면, 그 한 영역에서 막힌 사용자에게는 그 사이트가 '못 쓰는 사이트'다. 그래서 일곱 영역을 '골고루' 봐야 한다는 말이, 단순한 균형론이 아니라 사용자 현실에 뿌리를 둔 원칙인 것이다.

■ 부서마다 따로 노는 사이트

또 흔한 패턴이 '부서마다 따로 노는 사이트'다. 한 중앙부처 산하의 사이트(C기관)를 여러 페이지에 걸쳐 점검한 적이 있다. 메인과 주요 안내 페이지는 비교적 멀쩡했다. 그런데 부서별 하위 페이지로 내려가니 풍경이 달라졌다. 어떤 부서 페이지는 버튼 스타일이 메인과 전혀 달랐고, 어떤 부서는 옛날 디자인을 그대로 쓰고 있었으며, 어떤 신청 페이지는 폼 흐름이 뚝뚝 끊겼다.

원인을 짐작하긴 어렵지 않다. 부서마다 다른 시기에, 다른 업체에, 다른 기준으로 만들었기 때문이다. 메인만 보면 통과인데, 깊숙이 들어가면 무너져 있다. 이게 '한 페이지만 보고 판단하면 안 되는' 이유다. 사용자는 메인에만 머물지 않는다. 오히려 실제로 목적을 이루는 건 깊숙한 신청·조회 페이지에서다. 그 깊은 곳이 무너져 있으면, 메인이 아무리 멀끔해도 사용자 경험은 무너진다.

이 사례는 편의성과 KRDS의 일관성 문제를 동시에 보여준다. 부서마다 버튼이 다르고 흐름이 다르면, 사용자는 페이지를 옮길 때마다 사용법을 새로 익혀야 한다. 같은 기관 사이트인데도 '여러 기관을 떠도는' 느낌을 준다. KRDS가 일관성을 그토록 강조하는 이유, 그리고 7대 품질 점검을 '여러 페이지에 걸쳐' 해야 하는 이유가 여기서 만난다.

이런 '따로 노는 사이트'가 생기는 건 누구 한 사람의 잘못이라기보다 구조의 문제다. 공공기관은 담당자 교체가 잦고, 개편도 한 번에 전체를 갈지 못하고 부분부분 진행되는 경우가 많다. 그러다 보니 시기마다, 담당마다, 업체마다 조금씩 다른 결과물이 쌓인다. 바로 이 지점이 KRDS 같은 '공통 기준'이 필요한 이유다. 누가 만들든 같은 기준을 따르면, 시기와 사람이 달라도 결과물이 한 방향을 가리킨다. 공통 기준은 '사람의 교체'가 '품질의 단절'로 이어지지 않게 막아주는 안전장치다. 담당자가 바뀌어도 사이트가 흔들리지 않는 조직, 그게 기준이 잘 선 조직이다.

■ 평소엔 멀쩡한데 결정적 순간에 무너지는 사이트

마지막 패턴은 접속성·신뢰성과 얽힌다. 평소엔 아무 문제 없다가, 특정 순간에 무너지는 사이트들이다. 어떤 모집 공고 사이트는 평소 한산할 땐 빠릿빠릿하다가, 접수 개시 시각에 사람이 몰리자 한참을 먹통이 됐다. 가장 중요한 그 순간에, 가장 절박한 사용자들을 문 앞에 세워둔 것이다.

또 어떤 사이트는 보안 연결 설정에 빈틈이 있어, 사용자가 정보를 입력하는 페이지의 일부가 안전하게 보호되지 않았다. 평소엔 아무도 눈치채지 못했지만, 이런 빈틈은 한 번 문제가 터지면 기관 전체의 신뢰를 흔든다. '티가 안 나서 방치했다'가 가장 위험한 태도인 이유다.

이 사례들의 공통점은, 모두 '평상시 한 페이지 눈으로 보기'로는 발견되지 않는다는 점이다. 부하가 걸린 순간의 응답, 연결의 보안 상태, 깊은 페이지의 일관성 — 이런 건 사람이 눈으로 훑어서는 잡아내기 어렵다. 측정해야 보이고, 여러 페이지를 함께 봐야 드러난다. 결국 '제대로 보려면 도구의 힘을 빌려야 한다'는 결론으로 자연스럽게 이어진다.

그래서 우리는 무엇부터 점검하면 되는가

■ 1단계: 일곱 영역으로 '현황'부터 찍어본다

7대 품질 영역을 처음 접하면 '이걸 다 어떻게 챙기나' 싶어 막막할 거다. 하지만 시작은 단순하다. 일단 '지금 우리 사이트가 일곱 영역에서 각각 어느 수준인가'를 한 번 찍어보는 것이다. 완벽하게 고치는 게 1단계가 아니다. 현황을 아는 게 1단계다.

현황을 모르면 막연한 불안만 쌓인다. '우리 사이트 괜찮나'라는 걱정은 끝이 없다. 하지만 일곱 영역 점수를 한 번 찍어보면, 그 막연함이 '호환성은 양호, 접근성은 미흡, 효율성은 보통'처럼 구체적인 지도로 바뀐다. 지도가 있어야 어디로 갈지 정할 수 있다. 첫 점검의 목적은 '완벽'이 아니라 '지도 만들기'다.

■ 2단계: 약한 영역부터, 영향 큰 것부터

현황을 찍었으면, 다음은 우선순위다. 일곱 영역을 동시에 다 손볼 필요도, 그럴 수도 없다. 가장 약한 영역부터, 그중에서도 영향이 큰 것부터 잡는 게 현실적이다.

여기서 두 가지 기준이 유용하다. 첫째는 '사용 가능/불가능을 가르는 것'을 가장 위에 둔다. 접근성처럼 일부 사용자에게 '아예 못 쓰게 되는' 문제는, 단순한 불편보다 무겁게 다뤄야 한다. 둘째는 '반복 노출되는 것'을 우선한다. 상단 메뉴, 공통 버튼, 푸터처럼 모든 페이지에 공통으로 들어가는 요소는 한 번 고치면 사이트 전체에 효과가 퍼진다. 같은 노력으로 더 넓은 개선을 얻는 길이다.

이 우선순위 잡기에서 KRDS가 다시 빛을 발한다. 7대 영역 점검으로 '무엇이 약한가'를 알았다면, KRDS 846규칙 점검으로 '구체적으로 어떤 규칙을 안 지켜서 그런가'를 짚을 수 있다. 증상(7대 영역)과 원인(KRDS 규칙)을 함께 보면, '무엇을 먼저 고칠지'가 또렷해진다. 막연한 '개선하자'가 '이 컴포넌트의 이 규칙부터 고치자'로 바뀌는 것이다.

■ 3단계: 한 번 점검하고 끝내지 않는다

7대 품질도, KRDS 준수도 '한 번 맞추고 끝'이 아니다. 사이트는 계속 바뀐다. 새 페이지가 올라가고, 부서가 콘텐츠를 추가하고, 일부를 외주로 개편한다. 그때마다 기준에서 다시 멀어질 수 있다.

그래서 정기적으로 '지금 우리 사이트가 일곱 영역에서 어디쯤인가'를 다시 찍어보는 습관이 필요하다. 분기에 한 번이든, 개편 직후든, 정기 점검 루틴을 두는 것이다. 특히 '개편 직후 점검'은 강하게 권한다. 많은 기관이 개편에 큰돈을 들이고도, 정작 '계약한 기준대로 잘 만들어졌는지'는 확인하지 않은 채 오픈한다. 산출물을 받는 시점에 진단을 돌려보면, '기준대로 만들어졌는가'를 객관적으로 확인할 수 있고, 부족한 부분은 추가 비용 없이 보완을 요구할 근거가 된다. 진단을 '검수의 마지막 관문'으로 두는 것이다.

그리고 점검 결과는 기록해두는 게 좋다. 1분기엔 어땠고, 2분기엔 어떻게 바뀌었는지를 남기면, 개선의 흐름이 눈에 보인다. 점수가 오르는 추세면 그 자체가 성과 보고 자료가 되고, 떨어지는 추세면 어디서 새는지 빨리 알아챌 수 있다. 일회성 점검은 사진 한 장이지만, 기록된 점검은 동영상이다. 사이트가 어느 방향으로 가는지는 동영상으로만 보인다.

정리하면, 출발점은 거창한 결심이 아니라 '현황 파악 → 우선순위 → 정기 점검'이라는 단순한 루틴이다. 이 한 바퀴를 돌리고 나면 다음 바퀴는 훨씬 가볍다. 완벽을 목표로 두면 시작조차 못 하지만, '이번 분기엔 한 바퀴 돌려본다'를 목표로 두면 누구나 시작할 수 있다.

여기까지 읽었다면 한 가지 현실적인 고민이 생길 거다. "취지는 알겠는데, 일곱 영역을 사람이 어떻게 다 점검하지? 게다가 KRDS 846규칙까지?"

맞는 고민이다. 호환성을 보려면 여러 브라우저에서 일일이 열어봐야 하고, 접근성을 보려면 화면 읽기 프로그램으로 페이지마다 확인해야 하고, 효율성을 보려면 자원 용량을 일일이 재야 하고, 신뢰성을 보려면 보안 설정을 항목별로 점검해야 한다. 여기에 KRDS 846규칙까지 페이지마다 따지면, 한 페이지 점검에만 며칠이 걸린다. 사람이 하면 빠뜨리는 게 생기고, 점검하는 사람마다 기준이 흔들린다.

이건 능력의 문제가 아니라 '양과 일관성'의 문제다. 아무리 꼼꼼한 사람도 수백 페이지를 똑같은 집중력으로 끝까지 점검할 수는 없다. 처음 몇 페이지는 빠짐없이 보다가, 뒤로 갈수록 피로해져 놓치는 게 생긴다. 또 어제의 나와 오늘의 나는 같은 화면을 보고도 다른 판단을 내릴 수 있다. 기계는 첫 페이지든 오백 번째 페이지든 똑같은 잣대로, 똑같은 집중력으로 본다. 이 '지치지 않는 일관성'이야말로 자동 진단이 사람을 돕는 핵심 지점이다.

그래서 우리는 이 과정을 자동화하는 ViewCheck을 만들었다. 사이트 주소(URL)를 넣으면, 페이지를 자동으로 열어 화면 구조를 분석하고 KRDS 846규칙을 기준으로 '무엇이 통과했고, 무엇이 미준수이고, 무엇이 해당 없음인지'를 판정해준다. DS·CP·BP·SP 네 영역별로 점수가 나오기 때문에, KRDS의 네 서랍을 한 화면에서 바로 볼 수 있다.

특히 공공 담당자에게 유용한 건, 오늘 글에서 다룬 행안부 전자정부 웹사이트 품질관리 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)을 함께 본다는 점이다. KRDS 디자인 준수만 보는 게 아니라, 웹 접근성 KWCAG 33항목, 보안·신뢰성 점검, 효율성(핵심 웹 지표), 개방성(검색엔진 친화 요소)까지 한 번의 진단으로 묶어서 보여준다. '디자인 점검 따로, 품질 점검 따로, 접근성 점검 따로' 돌릴 필요 없이, 한 번에 전체 그림이 나온다.

여기서 오해를 막기 위해 분명히 해둘 게 있다. 자동 진단은 '사람의 판단을 대체'하는 게 아니라 '사람의 판단을 돕는' 도구다. 도구가 하는 일은 수많은 규칙과 항목을 페이지마다 빠짐없이 기계적으로 훑어서, '여기는 통과, 여기는 미준수, 여기는 해당 없음'이라는 1차 분류를 빠르게 해주는 것이다. 사람이 며칠 걸려 할 일을 몇 분으로 줄여준다. 그렇게 정리된 결과를 보고 '무엇을 먼저 고칠지, 어떻게 고칠지'를 결정하는 건 여전히 사람의 몫이다. 도구는 '어디가 아픈지'를 빠르게 짚어주는 건강검진이고, 처방과 치료의 방향은 담당자가 잡는다.

또 하나 실무적으로 중요한 건 '다중 페이지' 진단이다. 앞서 '부서마다 따로 노는 사이트' 사례에서 봤듯, 사이트는 메인 한 장으로 끝나지 않는다. 메인은 멀쩡한데 깊숙한 신청 페이지가 무너져 있는 경우가 허다하다. 그래서 한 페이지만 보고 '우리 사이트는 괜찮다'고 판단하면 큰 오산이다. 여러 페이지를 한꺼번에 분석해, 사이트 전체의 일관성과 약한 고리를 함께 봐야 진짜 현황이 나온다. 일곱 영역을 '사이트 전체 차원'에서 보려면 다중 페이지 진단이 필수인 것이다.

말로만 설명하면 와닿지 않으니, 실제 진단 결과 화면을 보자. 아래는 분석을 마치면 가장 먼저 보이는 상단 점수 카드다. 네 카테고리(DS·CP·BP·SP) 점수와 전체 준수율이 한눈에 들어온다. (캡쳐는 URL·도메인·기관명을 가린 것이다.)

마무리

정리해보자. 행정안전부 「전자정부 웹사이트 품질관리 지침」은 공공 웹사이트의 품질을 일곱 가지 측면에서 본다. 잘 열리는가(호환성), 누구나 쓸 수 있는가(접근성), 정보가 잘 통하는가(개방성), 안정적으로 접속되는가(접속성), 헤매지 않고 쓰는가(편의성), 답답하지 않게 빠른가(효율성), 안심하고 맡길 수 있는가(신뢰성). 이 일곱 축이 골고루 받쳐줘야 비로소 '품질 좋은 공공 웹'이라 부를 수 있다.

오늘 글의 핵심을 한 줄로 줄이면 이렇다. "공공웹 품질은 하나의 점수가 아니라, 일곱 개의 결이 만드는 합주다." 어느 한 악기만 잘 연주해서는 좋은 연주가 되지 않는다. 일곱 악기가 함께 균형을 이뤄야 한다.

조금 더 길게 정리하자면 이렇다. 첫째, 일곱 영역은 임의의 항목이 아니라 '사용자가 사이트에 도착해 목적을 이루고 떠나기까지'의 전 과정을 짚은 점검표다. 그래서 어느 한 단계가 막히면 사용자는 거기서 멈춘다. 둘째, 7대 품질은 KRDS와 한 몸이다. KRDS를 잘 지키면 품질의 상당 부분이 따라 오르고, 품질 점검 결과를 KRDS 규칙으로 들여다보면 증상과 원인이 함께 잡힌다. 셋째, 시작은 '완벽'이 아니라 '현황 찍기'다. 일곱 영역으로 지금 어디쯤인지를 한 번 재보는 것에서 모든 개선이 출발한다. 이 세 가지만 가져가도 오늘 글의 절반은 챙긴 셈이다.

그리고 마지막으로 강조하고 싶은 건, 시작의 문턱이 생각보다 낮다는 점이다. '일곱 영역을 완벽히 공부한 다음에 점검하자'고 미루면 영영 시작 못 한다. 오히려 '일단 우리 사이트가 지금 일곱 영역에서 어디쯤인지 한번 재보자'에서 출발하는 게 맞다. 현황을 알면 막연한 불안이 구체적인 할 일 목록으로 바뀌고, 할 일이 보이면 우선순위를 잡을 수 있고, 우선순위가 잡히면 한 걸음씩 나아갈 수 있다. 완벽한 이해가 아니라 첫 측정이 출발점이다.

그 전에, 우리 사이트가 지금 어디쯤 와 있는지 궁금하다면 직접 한번 확인해보길 권한다. ViewCheck(krds.viewcheck.co.kr)에서 URL만 넣으면 KRDS 846규칙과 7대 품질 영역 기준의 자가 진단을 무료로 체험할 수 있다. 막연한 '괜찮겠지'를 구체적인 점수로 바꿔보는 것, 그게 모든 개선의 첫걸음이다.

부담 갖지 않아도 된다. 진단을 한번 돌려본다고 해서 당장 무언가를 고쳐야 하는 건 아니다. '우리 사이트의 현재 점수가 몇 점이고, 일곱 영역 중 어디가 강하고 어디가 약한지'를 아는 것만으로도 충분한 출발이다. 그 결과를 보고 '아, 우리는 접근성은 괜찮은데 효율성이 약하구나' 하고 감을 잡으면, 다음에 무엇을 먼저 손볼지가 자연스럽게 보인다. 이번 한 달 동안 KRDS 입문을 함께 따라오면, 그 점수표가 점점 더 또렷하게 읽히기 시작할 거다.

이번 주는 '7대 품질 영역'이라는 큰 틀로 시작했지만, 한 해 동안 우리는 디자인 토큰, 컴포넌트, 서비스 패턴, 웹 접근성, 성능, 보안까지 공공 웹을 둘러싼 거의 모든 주제를 차근차근 짚어갈 예정이다. 매주 월·수·금, 한 번에 다 소화하려 하지 말고 한 편씩 편하게 읽어주면 된다. 오늘 '정부는 공공웹 품질을 일곱 가지로 본다'는 큰 그림을 잡았다는 것만으로도, 당신은 이미 막막함에서 한 걸음 빠져나온 셈이다. 다음 글(이번 주 수요일)에서는 이 일곱 영역 중 몇 가지를 더 깊이, 실제 화면과 함께 파고들 예정이다. 오늘 잡은 큰 그림 위에, 한 조각씩 지식을 얹어가면 된다. 다음 글에서 또 만나자.