ViewCheck LLM 분석 리포트 읽는 법 — 점수·등급·근거·우선순위 해석에서 행동까지

숫자는 받았는데, 다음에 무엇을 해야 할지 모르겠다면 — 분석 결과를 실질적인 개선 행동으로 바꾸는 가이드

들어가며 — "74점"을 받았다. 그다음은?

분석이 끝나고 화면에 숫자가 떴다. 종합 74점. KRDS 846규칙 중 289개 통과, 228개 미통과, 329개 해당없음. 접근성 68점. 보안 91점. 위반 매트릭스에는 빨간 칸과 노란 칸이 뒤섞여 있다.

그런데 막상 이 결과를 받아 든 담당자의 표정이 묘하다. 뭔가 많이 나왔는데, 무엇을 먼저 봐야 할지 모르겠다. 228개를 전부 고쳐야 하는 건지, 74점이 좋은 건지 나쁜 건지, 빨간 칸부터 잡으면 되는 건지 — 결과는 나왔지만 행동으로 연결되지 않는 이 순간, 많은 담당자들이 멈춘다.

이 글은 그 순간에 대한 이야기다. ViewCheck LLM 분석이 내놓는 점수·등급·근거·우선순위가 각각 무엇을 의미하는지, 어떤 순서로 읽어야 하는지, 그리고 숫자에서 실제 개선 행동으로 어떻게 넘어가는지를 최대한 구체적으로 풀어본다.

미리 솔직히 말해 두겠다. 이 글은 "ViewCheck를 쓰면 모든 게 자동으로 해결됩니다" 같은 이야기가 아니다. 분석 결과는 도구가 내주지만, 그 결과를 해석하고 행동으로 연결하는 것은 여전히 사람의 몫이다. 우리가 도울 수 있는 건, 그 해석과 연결의 방식을 조금 더 체계적으로 만드는 것뿐이다. 그 체계를 최대한 솔직하게 꺼내보는 게 이 글의 목적이다.

두 대의 모니터 앞에 앉은 한국인 공공기관 담당자. 한쪽 화면에는 웹 감사 리포트의 점수 카드와 막대 그래프가, 다른 쪽에는 손으로 메모한 체크리스트가 펼쳐진 사무실 풍경. — 분석 결과는 나왔다. 그런데 이 숫자들을 어떻게 읽고, 무엇부터 해야 할까.

분석 결과의 구조 이해하기 — 숫자는 다 같은 숫자가 아니다

ViewCheck LLM 분석의 결과 화면을 처음 보면 꽤 많은 숫자가 한꺼번에 쏟아진다. 종합 점수, 카테고리별 점수, 통과/미통과/해당없음 건수, 심각도 분류, 페이지별 점수, 위반 매트릭스의 색깔들. 이걸 한꺼번에 해석하려 하면 오히려 혼란스럽다. 먼저 이 숫자들이 어떤 층위로 구성되어 있는지를 이해하는 것이 출발점이다.

크게 보면 결과 데이터는 세 개의 층으로 나뉜다.

첫 번째 층: 요약 지표 (Overview)

가장 바깥 층이다. 종합 점수, 7대 품질 영역별 점수, DS·CP·BP·SP 4개 카테고리 점수처럼 한 숫자로 표현되는 값들이다. 이 숫자들은 "전체적으로 어느 위치에 있는가"를 빠르게 파악하는 데 쓴다. 경영진 보고나 초기 상황 파악에 적합하다. 다만 이 숫자만 보고 "뭘 고쳐야 하는가"를 판단하려 하면 안 된다. 요약은 어디까지나 요약이고, 그 안에 무엇이 들어 있는지는 아래 층을 봐야 안다.

두 번째 층: 규칙별 판정 결과 (Rule-Level)

KRDS 846개 규칙 각각의 통과/미통과/해당없음 판정과 그 근거다. "이 규칙이 왜 미통과인가"에 대한 답이 이 층에 있다. 개발자나 디자이너가 실제로 수정 작업을 할 때 보는 층이다. 규칙 ID(DS-xxx, CP-xxx, BP-xxx, SP-xxx), 위반 내용 요약, 해당 페이지, 관련 DOM 요소 정보가 함께 제공된다.

세 번째 층: 위치 데이터 (Location-Level)

어느 페이지의 어느 요소가 문제인지를 나타낸다. 위반 매트릭스에서 특정 규칙과 특정 페이지가 교차하는 지점이 이 층의 데이터다. "이 사이트에서 CP-023 규칙 위반은 메인·검색·목록·상세 4개 페이지 전체에 걸쳐 나타난다"처럼 위반의 '퍼짐 정도'를 보여주는 게 이 층이다.

왜 이 세 층을 구분해야 하는가. 왜냐하면 각 층을 사용하는 상황과 사람이 다르기 때문이다. 경영진은 1층, 개발자는 2층, QA나 운영 담당자는 3층을 주로 본다. 그리고 좋은 리포트 활용은 이 세 층 사이를 맥락에 따라 자유롭게 오가는 능력이다. 1층에서 문제를 발견하고 → 2층에서 원인을 파악하고 → 3층에서 위치를 특정해서 → 수정 작업에 들어가는 것. 이 흐름이 리포트를 행동으로 연결하는 기본 경로다.

점수 숫자를 읽는 법 — 절대값보다 맥락이 중요하다

종합 74점을 받았다. 이게 좋은 건가, 나쁜 건가. 이 질문에 "74점이면 좋습니다" 혹은 "나쁩니다"라고 바로 답하는 건 사실 어렵다. 점수는 항상 맥락 안에서만 의미가 있기 때문이다. 맥락은 적어도 세 가지 차원에서 만들어진다.

차원 1: 이전 측정값과의 비교 (시간 축)

같은 사이트를 지난달에 측정했을 때 68점이었는데 이번에 74점이 됐다면, 6점이 올랐다는 사실 자체가 의미 있는 정보다. 절대값으로 좋고 나쁨을 논하기 이전에, "이 방향으로 움직이고 있는가"가 먼저다. 점수가 떨어졌다면 그건 무언가가 퇴보했다는 신호이고, 그 원인을 찾아야 한다. 개선 로드맵의 가치는 단발 점수가 아니라 이 시간 축의 추이에서 나온다.

차원 2: 비슷한 유형의 사이트와의 비교 (유형 축)

지자체 포털과 중앙행정기관 포털은 구조도 다르고, 제공하는 서비스 유형도 다르다. 단순 정보 제공 중심의 사이트와 신청·민원 처리가 핵심인 사이트는 KRDS 규칙 중 어떤 규칙이 더 중요한지도 달라진다. 그러므로 비교는 가능하면 비슷한 유형의 사이트 사이에서 해야 의미가 있다. ViewCheck의 벤치마킹 카드는 이런 맥락에서 활용하는 것이다.

차원 3: 7대 품질 영역 간의 균형 (영역 축)

종합 74점인데 보안이 91점, 접근성이 55점이라면, 이 사이트는 보안은 잘 갖췄지만 접근성에서 심각한 문제가 있다는 뜻이다. 이때 종합 점수에 안도해서는 안 된다. 행정안전부의 7대 품질 영역은 각각 독립적으로 의미 있는 영역이고, 하나가 매우 낮은 점수를 받았다면 그 영역은 별도로 집중해서 다뤄야 한다. 종합 점수는 전체를 조감하는 숫자지, 특정 영역의 심각성을 희석하는 숫자가 아니다.

이 세 차원을 떠올리며 점수를 보면, "74점이니 괜찮다" 혹은 "74점이니 나쁘다"가 아닌, "접근성이 유독 낮은데 왜인가", "지난번보다 보안이 올랐는데 무엇을 고쳤기 때문인가"처럼 더 정확한 질문을 할 수 있게 된다. 좋은 리포트 독해는 결국 좋은 질문을 만드는 데 있다.

참고로, 접근성 진단 도구들이 내놓는 점수를 어떻게 해석해야 하는지에 대해 AllAccessible의 WCAG 2025 가이드는 이렇게 정리한다. 자동화 도구가 발견하는 접근성 이슈는 전체 접근성 문제의 일부이며, 점수가 높다고 해서 완전한 접근성을 보장하지 않는다는 것이다. 도구가 잡아내지 못하는 수동 검사 필요 항목이 항상 남는다는 점을 감안해야 한다(AllAccessible, 2025). 이 원칙은 ViewCheck에도 똑같이 적용된다. 846규칙 중 일부는 여전히 사람의 눈으로 직접 확인해야 하는 영역이고, 자동화가 "해당없음(N/A)"으로 남긴 항목은 그 사실 자체를 인지하고 있어야 한다.

심각도(Severity) 등급을 읽는 법 — P0·P1·P2·P3이 의미하는 것

ViewCheck 분석 결과에는 각 위반 항목에 심각도 등급이 붙는다. P0·P1·P2·P3 또는 Critical·High·Medium·Low처럼 표현되는 이 등급이, 실제 개선 우선순위를 정하는 가장 중요한 기준이다.

심각도 등급이 왜 필요한가. 228개 미통과 항목을 나열만 해두면, 무엇부터 고쳐야 하는지 알 수 없다. "중요한 것부터"라는 원칙은 모두 알지만, 무엇이 더 중요한지를 판단하는 기준이 있어야 비로소 우선순위가 생긴다. 그 기준이 심각도다.

심각도를 판단하는 요소는 크게 세 가지다.

첫째, 사용자 영향의 크기 (User Impact)

이 위반이 실제 이용자에게 얼마나 큰 불편이나 장벽을 만드는가. WebAIM은 접근성 위반의 심각도를 네 수준으로 분류한다. Critical — 콘텐츠나 기능에 일부 이용자가 완전히 접근할 수 없게 만드는 것. Significant — 매우 어렵게 만드는 것. Moderate — 불필요한 시간과 노력을 쓰게 만드는 것. Recommendation — 더 잘 만들 수 있지만 즉각적인 장벽은 아닌 것(WebAIM, "Using Severity Ratings to Prioritize Web Accessibility Remediation"). 이 네 수준의 핵심 질문은 단 하나다 — "이 문제가 있으면 어떤 이용자가 무엇을 할 수 없게 되는가?"

둘째, 발생 빈도 (Frequency)

같은 위반이 한 페이지에만 있는지, 아니면 사이트 전체 수십 개 페이지에 반복되는지. 단 한 페이지에 존재하는 P1 위반보다, 50개 페이지 전체에 퍼진 P2 위반이 실질적 영향은 훨씬 클 수 있다. 위반 매트릭스가 이 '퍼짐 정도'를 시각화한다. 매트릭스에서 한 행(규칙)이 여러 열(페이지)에 걸쳐 색이 들어온다면, 그 규칙은 사이트 전체에 구조적으로 영향을 미치는 문제다. 한 번 고치면 여러 페이지가 함께 나아진다는 뜻이기도 하다.

셋째, 수정의 파급 효과 (Leverage)

수정했을 때 얼마나 많은 규칙이, 얼마나 많은 페이지에서 동시에 개선되는가. 글로벌 CSS나 공통 컴포넌트에 있는 문제는, 한 번 수정으로 사이트 전체에 효과가 퍼진다. 반면 특정 페이지의 특수한 케이스는 그 페이지만 고쳐진다. 같은 노력이라면 파급 효과가 큰 수정부터 하는 것이 합리적이다.

이 세 가지 — 사용자 영향, 발생 빈도, 파급 효과 — 를 종합해서 P0·P1·P2·P3이 결정된다. P0는 "지금 당장 막아야 하는 것", P1은 "이번 스프린트 안에 잡아야 하는 것", P2는 "다음 사이클에 처리할 것", P3는 "여유 있을 때 다듬을 것"에 대응한다.

닐슨 노먼 그룹의 Jakob Nielsen이 제안한 휴리스틱 평가의 심각도 척도도 이 개념을 잘 보여준다. 0점(문제 없음)부터 4점(사용성 재앙 — 출시 전에 반드시 수정)까지의 5단계 척도로, 각 점수는 단순히 "얼마나 나쁜가"를 넘어 "얼마나 빨리 고쳐야 하는가"의 행동 지침까지 담고 있다(Nielsen Norman Group, "Severity Ratings for Usability Problems"). ViewCheck의 P0~P3 등급은 이 개념의 공공 웹 도메인 적용판이다.

KRDS 4개 카테고리별 점수를 읽는 법 — DS·CP·BP·SP

종합 점수 하나만 보는 것보다, KRDS 4개 카테고리(DS·CP·BP·SP)의 점수를 각각 읽는 것이 훨씬 구체적인 진단이 된다. 각 카테고리는 다른 영역을 보고, 다른 성격의 수정을 요구하기 때문이다.

DS(디자인 스타일, 120개 규칙) — 색상·타이포·간격·레이아웃

DS 점수는 사이트의 시각적 언어가 KRDS 디자인 토큰과 얼마나 일치하는지를 본다. 색상 대비가 기준을 충족하는지, 폰트 크기·줄간격·자간이 KRDS 스펙 범위 안에 있는지, 8pt 그리드와 정렬 원칙이 지켜지는지 같은 것들이다.

DS 점수가 낮다는 건 대개 두 가지 중 하나다. 디자인 토큰을 아예 사용하지 않고 커스텀 값으로 구현했거나, 디자인 토큰을 쓰긴 했지만 일부 컴포넌트에서 벗어난 값이 있는 경우. 전자는 전체 디자인 시스템 적용을 고려해야 하는 큰 작업이고, 후자는 예외값을 찾아 수정하는 비교적 작은 작업이다. DS 카드 안의 '토큰 채택률' 지표가 이 두 경우를 구분하는 데 도움이 된다.

DS 개선은 디자이너와 프론트엔드 개발자가 협업하는 영역이다. 색상 값 하나를 바꾸는 게 아니라, "왜 이 값이 토큰 밖에 있는가"라는 원인을 찾는 것이 핵심이다. 디자인 도구와 개발 코드 사이에서 토큰이 제대로 연결되어 있는가, 디자인 결정이 이후 구현에서 어긋났는가 — 이런 흐름을 추적하는 것이 DS 개선의 실질이다.

CP(컴포넌트, 446개 규칙) — 요소의 존재·속성·구조

CP 점수는 4개 카테고리 중 규칙 수가 가장 많다(446개). 버튼, 입력창, 탭, 모달, 카드, 알림 등 다양한 컴포넌트들이 KRDS가 정의한 구조와 속성을 갖추고 있는지를 본다. 특히 ARIA 속성(스크린리더 등 보조기술이 읽는 메타데이터)이 올바르게 붙어 있는지가 중심이다.

CP에서 "해당없음(N/A)" 비율이 높다면, 대개 그 컴포넌트 자체가 해당 페이지에 없기 때문이다. 메인 페이지에 모달이 없으면 모달 관련 CP 규칙은 전부 N/A가 된다. 이건 정상이다. 문제가 되는 건 실제로 그 컴포넌트가 있는데 N/A로 처리된 경우다. 이 구분을 위해 위반 매트릭스와 개별 규칙 근거를 함께 봐야 한다.

CP 미통과의 가장 많은 패턴은 ARIA 속성 누락이다. <button> 태그에 aria-label이 없거나, 폼 요소에 <label>이 연결되어 있지 않거나, 동적으로 나타나는 영역에 role, aria-live 같은 속성이 빠진 경우. 이런 수정은 HTML 수준의 수정이라 비교적 실행이 용이하다. 단, 공통 컴포넌트가 여러 페이지에서 재사용되는 경우, 한 컴포넌트를 고치면 여러 페이지가 동시에 개선된다. CP의 수정은 컴포넌트 단위로 묶어서 처리하는 것이 효율적인 이유다.

BP(기본 패턴, 108개 규칙) — 폼·동의·오류·필터

BP 점수는 사용자가 사이트에서 반복적으로 수행하는 상호작용이 KRDS의 권장 패턴대로 구현되어 있는지를 본다. 폼 작성 흐름, 동의 절차, 오류 메시지 표시, 필터·정렬 UI 같은 것들이다.

BP 미통과가 많다는 건, 사이트의 핵심 기능(주로 민원 신청, 검색, 회원 가입 등)에서 이용자 경험이 KRDS 기준에 미치지 못한다는 의미다. 이 부분은 단순한 HTML 속성 수정보다 더 복잡한 UX 재설계가 필요할 수 있다. 예를 들어 오류 메시지를 "오류가 발생했습니다"가 아니라 "이름을 입력해 주세요"처럼 구체적으로 바꾸는 건 메시지 수정이지만, 폼 전체의 오류 처리 흐름을 바꾸는 건 설계 수준의 작업이다.

BP 점수를 볼 때는 특히 어떤 패턴 유형에서 미통과가 집중되는지를 확인하는 것이 좋다. 오류 처리 패턴이 집중적으로 미통과라면 오류 UX를 집중 개선하면 되고, 필터·정렬 패턴이 문제라면 검색 결과 페이지에 집중하면 된다. 위반 목록을 단순히 나열된 항목으로 보지 말고, "어떤 패턴 유형이 문제인가"를 묶어 읽는 것이 BP 독해의 핵심이다.

SP(서비스 패턴, 172개 규칙) — 검색·로그인·신청·정책

SP 점수는 서비스 단위의 흐름이 KRDS 패턴을 따르는지를 본다. 검색 서비스, 로그인 서비스, 신청 서비스, 정책 안내 서비스처럼, 한 기능 단위 전체가 KRDS가 권장하는 흐름과 구조를 갖추고 있는지가 기준이다.

SP 판정은 페이지 단위가 아니라 서비스 흐름 단위다. 검색 입력창이 있는 페이지, 검색 결과 페이지, 상세 결과 페이지까지를 하나의 흐름으로 보고 판정한다. 그러므로 SP 미통과를 해석할 때는 "이 서비스 전체의 어느 단계에서 흐름이 끊기는가"를 추적해야 한다.

SP에서 특히 주의할 점은, 같은 서비스 유형이 여러 메뉴 경로에 복수로 존재하는 경우다. 로그인이 여러 경로에 있다면, 하나의 로그인 구현이 나아져도 다른 경로의 로그인이 그대로라면 SP 점수가 크게 달라지지 않는다. SP 개선은 그러므로 서비스의 모든 진입 경로를 파악하고 일관되게 적용하는 것이 중요하다.

근거(Rationale)를 읽는 법 — "왜 미통과인가"가 행동의 출발점이다

많은 점검 도구가 "이 항목은 미통과입니다"라고 결론만 내린다. 그러면 담당자는 "왜요?"라는 질문을 들고 개발자에게 가고, 개발자는 "그건 도구가 그렇다는데요"라고 한다. 이 대화는 생산적이지 않다. 미통과의 '이유'가 없으면, 수정의 '방향'도 없다.

ViewCheck의 각 규칙 판정에는 가능한 한 근거가 붙는다. "이 요소(예: 3번째 탭 컴포넌트)에서 ARIA role 속성이 누락되어 있어 CP-089 규칙을 충족하지 못했습니다"처럼. 이 근거는 두 가지 역할을 한다.

역할 1: 수정의 방향 제시

근거가 구체적일수록 수정도 구체적이 된다. "ARIA role 속성이 없다"는 근거가 있으면 개발자는 "그거면 role='tablist'랑 role='tab'을 추가하면 되겠네"라는 구체적 행동으로 바로 이어갈 수 있다. 근거 없는 "미통과"는 어디를 보고 어떻게 고쳐야 할지 알 수 없다.

역할 2: 결과의 신뢰 확인

근거를 보면 이 판정이 타당한지 아닌지를 담당자가 직접 확인할 수 있다. "이 페이지에는 탭 컴포넌트가 없는데 탭 관련 규칙이 미통과로 나왔다"면, 그건 도구가 잘못 판정한 것일 수 있다. 근거가 있으면 그 오판을 발견할 수 있고, 근거가 없으면 오판을 발견할 수 없다.

이 원칙은 ViewCheck가 RAG(Retrieval-Augmented Generation)를 쓰는 이유와 연결된다. 각 판정 옆의 참조 패널에는 그 판정의 근거가 된 KRDS 공식 문서 조각이 함께 제시된다. 사용자는 그 참조를 클릭해 원문을 직접 확인할 수 있다. "AI가 그렇대"가 아니라 "KRDS 원문에 이런 기준이 있어서 그렇다"를 볼 수 있는 것이다.

Deque의 접근성 감사 가이드는 근거 중심의 리포트가 왜 중요한지를 이렇게 표현한다. "전문가 리포트를 받고 나서 다음 단계는, 각 발견 사항의 근거(evidence)를 이해하고, 어디서 어떻게 수정할지를 결정하는 것"이라고(Deque, "Accessibility Audit Results: Next Steps"). ViewCheck가 단순히 체크 결과를 내는 것 이상으로 근거를 제시하려는 이유가 바로 이것이다.

물론 근거가 항상 완벽하게 제시되는 건 아니다. 일부 규칙은 DOM 데이터만으로 근거를 세밀하게 만들기 어렵고, 일부는 시각적 판단이 필요해 근거 자체가 "스크린샷을 확인하세요" 수준에 머물기도 한다. 이건 우리가 솔직히 인정해야 할 한계다. 근거의 품질을 높이는 것은 현재 진행 중인 엔진 개선 작업 중 하나다.

ViewCheck LLM 분석의 위반 매트릭스 실제 화면 캡처. 사이트의 여러 페이지(가로)와 KRDS 규칙(세로)이 교차하는 격자 형태로, 각 셀의 색상이 위반 심각도를 나타내며 빨간색·주황색·노란색으로 구분되어 있다. — ViewCheck LLM 분석의 위반 매트릭스 화면. 가로축은 페이지, 세로축은 KRDS 규칙이며 각 교차점의 색상이 위반 존재 여부와 심각도를 나타낸다. 빨간 칸이 넓게 퍼진 규칙은 사이트 전반에 걸친 구조적 문제를 의미한다. — 실제 분석 화면

위반 매트릭스를 읽는 법 — 색깔이 전하는 이야기

위반 매트릭스는 ViewCheck의 24개 분석 결과 카드 중 가장 정보 밀도가 높은 시각화다. 처음 보면 색깔이 복잡해 보이지만, 읽는 법을 알면 사이트의 '문제 구조'가 한눈에 들어온다.

매트릭스의 가로축은 '페이지'다. 메인, 검색, 목록, 상세, 신청, 로그인 등 분석된 페이지들이 열로 나열된다. 세로축은 'KRDS 규칙'이다. DS-xxx, CP-xxx, BP-xxx, SP-xxx 규칙들이 행으로 나열된다. 각 셀(교차점)의 색은 그 페이지에서 그 규칙이 어떤 상태인지를 나타낸다.

빨간 셀 — 해당 페이지에서 해당 규칙이 P0 또는 P1 수준으로 위반됨. 즉각적인 주의가 필요하다. 주황 셀 — P2 수준 위반. 이번 사이클 안에 처리해야 한다. 노란 셀 — P3 수준 위반. 여유 있을 때 개선한다. 회색 셀 — 해당없음(N/A). 그 페이지에 해당 규칙을 적용할 컴포넌트나 상황이 없다. 흰 셀 또는 초록 셀 — 통과.

매트릭스를 읽을 때 눈여겨볼 패턴이 있다.

패턴 1: 가로로 긴 빨간 행

한 규칙이 여러 페이지에 걸쳐 빨간 셀이 이어진다면, 그 규칙은 사이트 전체의 구조적 문제다. 대개 공통 레이아웃이나 공통 컴포넌트에 기인한 경우가 많다. 예를 들어 전체 헤더 컴포넌트의 네비게이션에 ARIA 속성이 빠져 있다면, 그 컴포넌트가 사용된 모든 페이지에서 관련 CP 규칙이 미통과가 된다. 이런 규칙은 하나를 고치면 전체가 나아지는 '고효율 수정'의 대상이다. 찾는 방법: 가로로 빨간 셀이 가장 많이 이어진 행을 찾는다.

패턴 2: 특정 열에 빨간 칸이 몰린 경우

반대로 특정 페이지(열)에서만 여러 규칙이 미통과라면, 그 페이지에 특수한 문제가 있다는 뜻이다. 신청 페이지나 로그인 페이지에 빨간 칸이 집중되어 있다면, 핵심 서비스 기능에 집중적인 문제가 있는 것이다. 이용자가 실제로 가장 많이 쓰는 페이지이므로, 우선적으로 다뤄야 한다.

패턴 3: 특정 규칙 카테고리(DS/CP/BP/SP)에서 색이 몰린 경우

매트릭스를 카테고리별로 구역을 나눠 보면, "이 사이트는 컴포넌트(CP) 쪽에서 문제가 집중되는구나" 또는 "서비스 패턴(SP)은 비교적 양호한데 디자인 스타일(DS)에서 빨간 칸이 많구나" 같은 패턴이 보인다. 이게 보이면 개선 자원을 어느 카테고리에 우선 배분할지가 결정된다.

Deque의 접근성 우선순위 전술 로드맵은 이런 패턴 분석을 "최소한의 노력으로 최대의 영향"이라는 원칙으로 정리한다(Deque, "Accessibility Prioritization: Tactical Roadmap"). 한 수정이 여러 페이지, 여러 규칙에 동시에 영향을 미치는 지점을 찾는 것이 전략의 핵심이라는 것이다. 위반 매트릭스는 그 지점을 찾는 시각적 도구다.

우선순위 결정 — "다음에 무엇을 해야 하는가"를 정하는 5단계

리포트의 숫자를 다 읽었다면, 이제 행동 순서를 정해야 한다. 228개를 어떻게 정렬할 것인가. 우선순위를 정하는 실용적인 5단계를 제안한다.

1단계: P0 항목부터 전수 확인

P0는 "지금 사이트가 제대로 작동하지 않는 수준의 문제"다. 핵심 기능(신청, 로그인, 검색)에 접근할 수 없게 만드는 문제, 키보드 트랩처럼 특정 이용자가 페이지를 빠져나올 수 없게 만드는 문제 등이 여기에 해당한다. P0는 다른 모든 우선순위 판단에 앞서 무조건 먼저 처리한다. 보통 P0 항목은 많지 않고(많다면 사이트에 심각한 문제가 있다는 신호다), 수정도 비교적 명확하다. P0를 처리하지 않은 채 P2, P3를 건드리는 건 순서가 맞지 않는다.

2단계: 고빈도 × 고심각도 규칙 파악

위반 매트릭스에서 가로로 빨간 행이 가장 많이 이어진 규칙들을 추린다. 이것이 "이 사이트에서 가장 광범위하게 퍼진 고심각도 위반"이다. 이 규칙들의 원인을 분석해 보면, 공통 컴포넌트나 공통 레이아웃에 기인하는 경우가 많다. 이 수정은 한 번에 여러 페이지를 동시에 개선하는 효율적 수정이다. 수정 후 매트릭스의 해당 행 전체가 통과로 바뀌는 것을 확인할 수 있다면 가장 이상적이다.

3단계: 핵심 서비스 페이지 집중

사이트의 핵심 서비스 페이지(신청, 로그인, 검색 결과, 주민 민원 처리 등)에서 발생하는 위반은 영향 이용자 수가 많다. 설령 심각도가 P2라도, 매일 수천 명이 이용하는 페이지에서 발생하는 P2는 거의 쓰이지 않는 페이지의 P1보다 실질적 영향이 클 수 있다. 3단계는 심각도 외에 '사용 빈도'를 곱해서 실제 영향을 추정하는 단계다.

4단계: 유사 항목 묶기 (Batching)

남은 미통과 항목 중 같은 유형의 수정으로 해결되는 것들을 묶는다. "이미지 alt 속성 누락"이 20개의 서로 다른 이미지에서 발생했다면, 이건 20개의 개별 작업이 아니라 "이미지 alt 작성 작업"이라는 하나의 작업 묶음이다. 묶어서 처리하면 컨텍스트 전환 비용이 줄고, 완료 기준이 명확해진다.

AllAccessible의 WCAG 2025 가이드는 이 방법을 "템플릿 단위로 묶기(group by template)"라고 표현한다. "글로벌 스타일 가이드의 색상 대비를 업데이트하면 사이트 전체에 광범위한 개선 효과가 생기는 것처럼, 빠른 승리(quick win)를 찾으라"는 것이다(AllAccessible, 2025). 개별 위반이 아닌 유형 단위로 보는 것이 효율적인 개선의 핵심이다.

5단계: 개선 로드맵에 넣기

4단계까지 정리한 항목들을 시간 축에 배분한다. P0 → P1(이번 스프린트) → P2(다음 사이클) → P3(분기 목표)의 순서로 배분하되, 팀의 자원과 일정을 현실적으로 반영한다. ViewCheck의 개선 로드맵 카드가 이 배분을 도와주는 형태로 제시된다. 로드맵에는 수정의 예상 난이도, 예상 소요 공수(MM)도 함께 표시되므로, "이번 스프린트에 실제로 처리할 수 있는 양"을 추정하는 데 참고할 수 있다.

세 명의 한국인 전문가가 우선순위 열로 나뉜 포스트잇 가득한 화이트보드 앞에서 공공 웹사이트 개선 로드맵을 논의하는 모습. — 위반 항목을 우선순위 열로 분류한 화이트보드. 개선 작업은 '전체 수정'이 아니라 '우선순위 배분'에서 시작된다.

KWCAG 접근성 결과를 읽는 법 — 34항목의 의미와 행동

ViewCheck의 접근성(KWCAG) 카드는 행안부 한국형 웹 콘텐츠 접근성 지침(KWCAG)의 34개 항목에 대한 준수 현황을 보여준다. 이 결과를 읽는 법은 KRDS 결과를 읽는 법과 큰 틀에서 같지만, 접근성 특유의 몇 가지 맥락을 알면 더 정확하게 읽을 수 있다.

WCAG/KWCAG의 적합성 수준 이해

WCAG(웹 콘텐츠 접근성 지침, W3C)는 세 가지 적합성 수준을 정의한다. A(기본), AA(표준), AAA(향상)다. 수준은 누적적이어서 AA가 되려면 A의 모든 기준도 충족해야 한다. WCAG 2.2는 총 87개의 성공 기준을 갖고 있으며, 레벨별 분포는 A 32개, AA 24개, AAA 31개다(W3C, WCAG 2.2). 대부분의 법적 의무는 AA 수준 충족을 요구한다. 미국 재활법 제508조, 유럽 EN 301 549, 그리고 국내 법령도 AA 수준을 기준으로 삼는다.

이게 KWCAG 결과를 읽을 때 중요한 이유가 있다. AA 기준의 미통과가 특히 법적·의무적 관점에서 먼저 처리해야 할 것들이고, AAA 기준의 미통과는 '더 잘 만들기'의 목표에 해당한다. 모든 미통과를 동일한 무게로 보면 안 된다.

자동화 탐지의 한계를 알고 읽기

접근성 자동화 도구는 WCAG 항목 중 약 30~40%만 자동으로 판정할 수 있다. 나머지는 수동 검사가 필요하다. 색상 대비, 키보드 접근성, 초점 이동 순서, 스크린리더 읽기 순서 같은 항목들은 실제 보조기술을 사용해봐야 알 수 있다. ViewCheck의 접근성 결과는 이 자동화 탐지 가능 범위 안에서의 결과다.

그래서 접근성 카드의 "통과" 항목도 "완전히 문제없다"고 단정하면 위험하다. 자동화가 탐지한 범위에서 통과라는 것이고, 수동 검사에서 다른 결과가 나올 수 있다. TestParty의 접근성 감사 가이드는 이 점을 명확히 한다. "완전한 WCAG 적합성 테스트는 자동화 도구와 수동 테스트의 조합을 요구하며, 전문가의 수동 테스트 없이는 접근성 보증이 불완전하다"고(TestParty, 2025). 그러므로 접근성 카드는 "이만큼 해결했고, 이 부분은 수동으로 추가 확인이 필요하다"는 식으로 활용하는 것이 정확하다.

오류 리스트 카드와 함께 읽기

접근성 카드에서 미통과 항목을 발견하면, 오류 리스트 카드로 이동해 그 항목의 구체적인 위치와 근거를 확인하는 것이 좋다. 오류 리스트 카드는 페이지와 DOM 요소 수준까지 내려가 "어디서 어떤 문제가 발생했는지"를 보여준다. 접근성 카드에서 방향을 잡고, 오류 리스트 카드에서 구체적인 수정 지점을 찾는 것이 접근성 개선의 효율적인 경로다.

보안 점수를 읽는 법 — "높다"는 게 끝이 아니다

보안 점수가 91점으로 높게 나왔다. 좋은 건가? 대체로 좋은 신호지만, 여기서도 숫자 하나에 안도하기 전에 안을 봐야 한다.

ViewCheck의 보안 분석은 13종의 보안 헤더, SSL/TLS 인증서, 혼합 콘텐츠, CORS, 쿠키 보안 플래그, 개인정보처리방침 링크 존재 여부 같은 항목들을 검사한다. 91점이라면 이 항목들 대부분을 갖추고 있다는 뜻이다. 그러나 점수가 높아도 반드시 확인해야 할 지점들이 있다.

SSL 인증서 만료일

인증서의 만료일이 얼마나 남았는지를 확인한다. 지금 당장 유효하더라도 30일 이내에 만료된다면, 갱신 계획이 있어야 한다. 만료되면 사이트에 접근 시 경고 화면이 뜨고, 공공기관 사이트에서 이런 화면은 신뢰성에 치명적이다.

CSP(콘텐츠 보안 정책) 헤더의 실질

CSP 헤더가 존재한다고 해서 충분한 것이 아니다. Content-Security-Policy: * 처럼 모든 것을 허용하는 CSP는 보안 헤더가 있다는 체크만 통과하고, 실질적인 보호 효과는 없다. 보안 카드에서 CSP의 설정 값이 무엇인지를 함께 확인하는 것이 좋다.

HSTS(HTTP Strict Transport Security) 설정 기간

HSTS 헤더가 있는지만 체크하는 게 아니라 max-age 값이 충분한지도 본다. 단기 설정(예: 1일)은 실질적 보호 효과가 낮고, 최소 1년(31,536,000초) 이상이 권장된다.

신뢰성 영역(개인정보처리방침, 이용약관 존재)

공공 사이트에서 개인정보처리방침 링크가 하단에 노출되어 있는지는 법적 의무이기도 하다. 보안 카드의 신뢰성 항목에서 이것이 탐지되었는지 확인하고, 없다면 이건 단순한 품질 문제가 아니라 법적 의무 준수의 문제다.

성능(웹 비탈) 점수를 읽는 법 — 수치 뒤의 사용자 경험

성능 분석은 LCP(최대 콘텐츠풀 페인트), CLS(누적 레이아웃 이동), FCP(첫 콘텐츠풀 페인트), TTFB(서버 응답 시간), INP(다음 페인트까지의 상호작용 시간)의 Core Web Vitals를 중심으로 제시된다.

이 숫자들은 "어떤 느낌의 사이트인가"를 수치로 번역한 것이다. LCP가 4초라면 메인 콘텐츠가 화면에 나타나는 데 4초가 걸린다는 뜻이고, 그건 사용자가 "이 사이트 느리다"고 느끼는 기준(2.5초 이상이면 개선 필요)을 훨씬 넘은 것이다. CLS가 높다면 페이지를 로딩하는 동안 요소들이 예고 없이 이동해 사용자가 클릭을 잘못하는 경험을 한다는 뜻이다.

성능 점수를 읽을 때 중요한 건 "느린 리소스(Slow Resources)"다. ViewCheck의 성능 카드에는 응답 시간 기준 상위 5개의 느린 리소스가 표시된다. 이미지 파일인지, JavaScript 파일인지, 외부 폰트인지에 따라 수정 방법이 달라진다. 이미지가 느리다면 WebP 변환이나 lazy loading을, JS 파일이 문제라면 코드 스플리팅이나 미사용 코드 제거를, 외부 폰트가 문제라면 폰트 사전 로드(preload) 또는 로컬 호스팅을 검토한다.

SEO 결과를 읽는 법 — 개방성과 검색 노출

SEO 카드는 메타 태그, Open Graph, 구조화 데이터, 헤딩 구조, 이미지 alt, robots.txt, sitemap.xml 같은 항목들을 보여준다. 이 결과는 "검색 엔진이 이 사이트를 얼마나 잘 이해하고 노출할 수 있는가"를 나타내는 동시에, 행안부 7대 품질 중 '개방성' 영역의 핵심 지표이기도 하다.

SEO 카드에서 특히 주의할 점은 robots.txt와 sitemap.xml이다. robots.txt가 없거나 접근이 차단되어 있다면, 검색 엔진 크롤러가 사이트를 제대로 색인하지 못할 수 있다. 2025년 고시 개정에서 개방성 기준이 일부 조정되어 "부분적 크롤링 차단"은 허용하되, 무분별한 전면 차단은 여전히 문제가 된다. ViewCheck는 robots.txt의 User-agent 설정, Disallow 규칙, Sitemap 지시어 등을 실제로 파싱해 결과를 제시한다.

헤딩 구조(H1~H6) 항목도 중요하다. 헤딩이 시각적 디자인을 위해 순서 없이 쓰이면, 스크린리더를 쓰는 사용자가 페이지의 정보 구조를 파악할 수 없게 된다. "H1이 한 페이지에 없거나 여러 개"이거나, "H2 없이 H3가 쓰인" 경우가 흔한 패턴이다.

다중 페이지 일관성을 읽는 법 — 사이트 전체 품질의 핵심

ViewCheck의 분석은 메인 페이지 한 장이 아니라 여러 페이지를 함께 본다. 이 다중 페이지 관점에서 나오는 결과 중 가장 중요한 것이 '일관성(Consistency)' 분석이다.

일관성 분석은 간단히 말하면 "메인 페이지에서 잘 된 것이 다른 페이지에서도 잘 되고 있는가"를 본다. 실제로 많은 사이트에서 메인은 잘 만들어져 있지만, 서브 페이지들은 개발 시점이나 작업자가 달라서 품질이 제각각인 경우가 많다. 일관성 점수가 낮다면 이 사이트는 "메인은 좋지만 실제로 이용자가 쓰는 서비스 페이지들은 기준에 미치지 못한다"는 패턴일 가능성이 크다.

일관성 카드에서 나오는 "이상 페이지" 목록에 주목하자. 전체 평균보다 현저히 낮은 점수를 받은 페이지들이 여기에 모인다. 이 페이지들은 개별 점검이 필요하다. 왜 유독 이 페이지의 점수가 낮은지 — 다른 팀이 개발한 것인지, 외주 작업인지, 오래된 레거시 코드인지 — 원인을 파악하면 수정 방향이 명확해진다.

GOV.UK의 공공 부문 접근성 모니터링 보고서(2022~2024)는 이와 관련해 흥미로운 데이터를 제시한다. 조사된 거의 모든 공공 웹사이트와 앱에서 접근성 이슈가 발견됐고, 특히 "사이트의 여러 부분이 서로 다른 시기에 서로 다른 팀에 의해 개발될 때 일관성 문제가 두드러졌다"는 점이 지적됐다(GOV.UK, "Accessibility monitoring of public sector websites and mobile apps from 2022 to 2024"). 이건 한국의 공공 웹도 마찬가지 상황이다.

한국인 웹 개발자가 동일한 정부 사이트의 여러 페이지 화면을 여러 브라우저 창에 띄워 나란히 비교하며, 일부 화면에 색상 포스트잇을 붙여 표시하는 모습. — 동일한 사이트의 여러 페이지를 나란히 비교하는 일관성 검토. 메인이 좋다고 전체가 좋은 건 아니다.

법적 리스크 카드를 읽는 법 — 숫자가 아닌 '책임'의 언어

ViewCheck의 법적 리스크 카드는 다른 분석 카드와 성격이 조금 다르다. 점수가 아니라 "이 위반 항목이 어떤 법적·행정적 책임과 연관될 수 있는가"를 정리한 것이다.

공공 웹사이트의 접근성 미준수는 「장애인차별금지 및 권리구제 등에 관한 법률」(장차법)에 따른 시정 명령의 대상이 될 수 있다. 개인정보처리방침 부재는 「개인정보 보호법」 위반 소지가 있다. SSL/보안 헤더 미흡은 보안 감사에서 지적 사항이 된다.

법적 리스크 카드를 읽을 때 중요한 것은, 이 카드의 내용이 법률 자문이 아니라는 점이다. "이런 위반이 있으면 법적으로 문제될 수 있다"는 리스크의 방향을 가리키는 것이지, 실제 법적 판단은 전문 법무 검토가 필요하다. 다만 이 카드를 경영진 보고에 활용할 때는, "품질 점수가 몇 점입니다"보다 "이런 리스크 항목이 있습니다"가 더 강한 개선 동기를 만들어내는 경우가 많다.

벤치마킹 카드를 읽는 법 — 비교는 경쟁이 아니라 참조다

벤치마킹 카드는 우리 사이트의 점수와 유사 유형의 다른 사이트들의 점수를 비교하는 참조 정보다. 이 카드를 볼 때 "경쟁에서 이겼나 졌나"로 읽으면 잘못이다. 벤치마킹의 올바른 용도는 두 가지다.

현실 수준 파악: 동일한 분류(예: 지자체 포털)의 사이트들이 평균적으로 어느 수준인지를 알면, 우리 사이트가 상대적으로 어느 위치인지가 맥락이 생긴다. 74점이 이 분류에서 상위 20%라면 다른 의미가 되고, 하위 30%라면 또 다른 의미가 된다.

목표 설정: 동일 분류에서 높은 점수를 받은 사이트들이 어떤 항목에서 두드러지는지를 보면, 우리가 집중해야 할 방향의 힌트가 된다. "이 유형의 사이트들은 SP(서비스 패턴)에서 평균적으로 높은 점수를 내는데, 우리는 여기가 특히 낮다"면, SP 개선이 우선이 된다.

비용·MM 카드를 읽는 법 — 예산 언어로 번역하기

비용·MM 카드는 분석 결과에서 나온 개선 항목들의 예상 공수(MM, 인월 단위)와 비용을 추정한 것이다. 이 숫자는 어디까지나 추정이고, 실제 공수는 팀의 역량과 환경에 따라 크게 달라진다는 점을 먼저 알아야 한다.

그 한계를 알고 사용하면, 이 카드는 매우 유용하다. 특히 경영진이나 예산 결정권자에게 "왜 이 개선 작업에 예산이 필요한가"를 설명할 때 구체적인 언어가 생긴다. "접근성 개선이 필요합니다"보다 "식별된 접근성 미통과 항목의 개선에 약 X MM, Y백만원의 예산이 예상되며, P0 항목만 우선 처리한다면 Z MM으로 줄일 수 있습니다"가 훨씬 의사결정이 용이한 언어다.

비용·MM 카드를 활용해 작성하는 가장 간결한 개선 요청서의 구조는 이렇다.

현황: 현재 KRDS 준수율 X%, 미통과 N건 (P0 A건, P1 B건, P2 C건, P3 D건)
위험: 법적 리스크 항목 M건, 핵심 서비스 영향 페이지 K개
제안: 단계 1 (P0+P1) — 예상 공수 X MM, 목표 준수율 Y%
      단계 2 (P2)   — 예상 공수 A MM, 목표 준수율 Z%
예산 요청: 단계 1 약 Y백만원 (외주 기준), 완료 목표 MM월

이 구조는 경영진이 "이 일이 왜 필요하고, 얼마나 들고, 어느 시점에 얼마나 나아지는가"를 한 화면에서 파악할 수 있게 해준다. 리포트의 결과를 '예산 언어'로 번역하는 작업이 담당자의 몫이고, 비용·MM 카드는 그 번역에 필요한 숫자를 제공하는 도구다.

AI 종합 리포트를 읽는 법 — AI의 말을 어떻게 신뢰할 것인가

24개 카드의 마지막, AI 종합 리포트 카드는 앞의 모든 분석 결과를 LLM이 종합해 서술한 것이다. 문장으로 된 서술이라 가장 읽기 쉽지만, 동시에 가장 조심해서 읽어야 하는 카드이기도 하다.

AI가 서술한 내용이 앞의 구조화된 결과와 어긋나 보인다면, 구조화된 결과를 기준으로 삼아야 한다. AI 서술은 패턴을 요약하는 것에 강하고, 수치 데이터를 정확히 전달하는 것에는 약할 수 있다. "이 사이트의 접근성 문제가 심각하다"는 서술은 신뢰하되, "접근성 점수가 X점입니다"라는 수치는 접근성 카드의 실제 숫자로 재확인하는 것이 좋다.

AI 종합 리포트의 올바른 활용은 두 가지다. 첫째는 경영진이나 비전문가에게 리포트 내용을 설명할 때 서술을 참고 자료로 쓰는 것. 둘째는 내가 리포트를 읽으며 놓쳤을 수 있는 패턴을 AI의 시각으로 한 번 더 확인하는 것. "AI가 이 사이트에서 특히 언급한 문제가 내 독해와 일치하는가"를 대조해 보는 것이다.

AI 종합 리포트를 그대로 복사해서 공식 보고서에 넣는 건 주의가 필요하다. AI 서술은 표준 문체가 아닐 수 있고, 내용의 정확성은 항상 담당자가 확인해야 한다. AI 리포트는 보고서의 초안 참고 자료이지, 최종 보고서 본문이 아니다.

결과를 개발자에게 전달할 때 — "미통과"에서 "이렇게 고쳐줘"로

리포트를 읽은 담당자가 다음으로 하는 일은 대개 개발자 혹은 외주 개발사에 수정을 요청하는 것이다. 이 전달의 품질이 실제 개선의 품질을 좌우한다.

"접근성 점수가 낮아요. 개선해 주세요"라는 요청은 개발자 입장에서 행동하기 어렵다. 반면 "이 페이지의 이 요소에서 이 속성이 없어서 CP-089 규칙을 위반하고 있습니다. ARIA role='tablist'와 role='tab'을 추가하면 됩니다. KRDS 공식 문서의 이 링크를 참고해 주세요"라는 요청은 명확하다.

ViewCheck의 각 규칙 판정에 붙은 근거와 참조 패널이 이 전달을 위한 재료다. 미통과 규칙 ID, 위반 요소, 수정 방향, 관련 KRDS 공식 문서 링크를 함께 전달하는 것이 기본 형식이다. 오류 리스트 카드에서 특정 항목을 내보내기하거나, 채팅에서 직접 질문("이 규칙을 어떻게 수정해야 하나요?")을 통해 구체적인 수정 가이드를 추가로 얻을 수도 있다.

개발자에게 전달하는 요청서의 항목 단위 형식:

규칙 ID: CP-089
위반 요소: 메인 페이지 / <nav class="gnb"> 내 탭 컴포넌트
문제: ARIA role 속성 누락 — 스크린리더가 이 영역을 탭 컴포넌트로 인식하지 못함
수정 방법: <ul>에 role="tablist", 각 <li>에 role="tab" 추가
관련 규칙: KRDS 컴포넌트 > 탭(Tab) 명세 (https://krds.go.kr/...)
우선순위: P1

이 형식을 일관되게 쓰면 개발자는 각 항목이 무엇이고, 어디를 고치면 되고, 왜 중요한지를 한눈에 파악할 수 있다. 수정 완료 후 ViewCheck로 동일 URL을 다시 분석해 해당 규칙이 통과로 전환됐는지 확인하는 것이 검증의 마무리다.

개선 이후 재분석을 언제 해야 하나 — 측정의 주기성

한 번 분석했다고 끝이 아니다. 수정이 이루어진 뒤, 그 수정이 실제로 효과가 있었는지를 확인하는 재분석이 필요하다. 그리고 사이트는 계속 바뀐다 — 새 콘텐츠가 올라오고, 컴포넌트가 수정되고, 외부 스크립트가 추가된다. 한 번 통과한 항목이 다음 업데이트에서 다시 미통과로 돌아올 수 있다.

그러므로 분석을 일회성 이벤트가 아니라 주기적인 측정으로 운영하는 것이 좋다. 대규모 업데이트 이후, 분기 단위 정기 점검, 또는 연간 품질 보고 시점에 맞춰 재분석하는 루틴이 있으면 "점점 나아지고 있는가 아니면 다시 나빠지고 있는가"를 추적할 수 있다. 앞서 이야기한 '시간 축의 비교'가 바로 이 주기적 측정에서 나온다.

GOV.UK의 공공 부문 접근성 모니터링은 이 점을 구체적인 사례로 보여준다. 일회성 감사에서 이슈를 지적받은 기관들이 3개월 후 어떻게 대응했는지를 추적한 결과, 62%는 접근성 규정에 대한 인식이 높아졌지만, 실제 사이트의 접근성 이슈가 감소한 곳은 그 중 일부에 불과했다(GOV.UK, "How organisations respond to accessibility monitoring", 2023). 인식과 행동 사이의 간극이 여기서도 나타난다. 주기적 측정과 그에 따른 액션은 이 간극을 좁히는 가장 실용적인 방법이다.

한국인 IT 관리자가 큰 모니터 화면에 웹사이트 감사 점수의 '개선 전·후' 비교를 나란히 띄워 놓고 집중해서 살펴보는 모습. — 개선 이전과 이후를 나란히 비교하는 재분석. 수정이 실제로 효과가 있었는지 확인하는 것까지가 개선이다.

담당자가 가장 많이 하는 실수 — 그리고 어떻게 피할 것인가

ViewCheck 분석 결과를 활용하는 과정에서 우리가 자주 목격하는 실수 패턴들을 정리한다. 이건 담당자를 비판하는 게 아니다. 도구가 복잡할수록 이런 패턴이 나타나는 건 자연스러운 일이고, 그걸 미리 알면 피할 수 있다.

실수 1: 종합 점수만 보고 개별 항목은 보지 않는다

종합 74점을 보고 "나쁘지 않네"라고 마감하는 경우. 보안이 30점이라도 종합 74점이 될 수 있다. 개별 영역 점수와 카테고리 점수를 반드시 함께 확인한다.

실수 2: 모든 미통과를 동일 중요도로 취급한다

228개를 나열된 목록으로 보고 위에서부터 처리하려 한다. 위에서부터가 아니라 P0부터 처리한다. 리스트 정렬을 심각도 기준으로 바꿔두는 것이 좋다.

실수 3: 메인 페이지만 분석하고 사이트 전체에 적용한다

"메인 페이지는 74점이니 사이트가 74점이다"라고 보고한다. 이건 틀렸다. 다중 페이지 분석 결과의 일관성 카드와 페이지별 점수 분포를 함께 봐야 한다.

실수 4: 근거를 확인하지 않고 미통과를 그대로 전달한다

"도구가 미통과래요"라고 개발자에게 전달한다. 근거를 함께 보내야 개발자가 행동할 수 있다. 판정의 근거와 관련 KRDS 문서 링크를 반드시 포함한다.

실수 5: 일회성으로 끝낸다

한 번 분석하고 보고서를 제출하면 끝이라고 생각한다. 개선 후 재분석으로 효과 확인, 정기 측정으로 품질 추이 관리가 이어져야 한다.

실수 6: N/A를 "통과"로 해석한다

"해당없음"은 "통과"가 아니다. 그 규칙을 판정할 조건(컴포넌트, 페이지 유형 등)이 없어서 판정을 유보한 것이다. N/A 비율이 높다면 "이 사이트에 이런 컴포넌트가 없구나" 또는 "분석이 이 부분을 못 봤구나" 중 하나를 의심하고 확인해야 한다.

결과를 보고서에 담을 때 — 실무 보고 형식

분석 결과를 활용해 실제 보고서를 작성할 때 필요한 최소 구조를 제안한다. ViewCheck의 임원보고서 카드가 이 구조의 초안을 제공하지만, 기관 내 보고 형식에 맞게 조정할 필요가 있다.

1페이지 요약용 (경영진 보고)

[사이트명] KRDS 품질 진단 결과 요약 (진단일: 0000.00.00)

종합 점수: X점 / 7대 품질 영역
─ 호환성 X점 / 접근성 X점 / 개방성 X점 / 접속성 X점
  편의성 X점 / 효율성 X점 / 신뢰성 X점

KRDS 846규칙: 통과 N건 / 미통과 N건 / 해당없음 N건
주요 미통과 유형: (예: CP 컴포넌트 ARIA 속성 누락 N건, BP 오류 처리 패턴 미적용 N건)

즉각 조치 필요 항목 (P0): N건
 - 항목 요약 1
 - 항목 요약 2

권고 조치 계획:
 단계 1 (이번 분기): P0+P1 처리 — 예상 공수 X MM
 단계 2 (다음 분기): P2 처리 — 예상 공수 Y MM

개발팀 전달용 (규칙별 수정 목록)

위반 규칙 ID, 페이지, 요소, 수정 방법, 우선순위, KRDS 참조 링크로 구성된 표 형식. 오류 리스트 카드의 내보내기 기능 활용을 권장한다.

정기 점검 기록용 (시계열 추이)

진단일, 종합 점수, 4개 카테고리 점수, 미통과 건수, 주요 변화 항목을 날짜별로 기록한 시계열 표. 분기마다 한 행이 추가되면, 수년 후에는 사이트의 품질 변화 이력이 된다.

이 글이 다루지 않은 것들 — 여전히 어려운 문제

한 편의 글에 다 담을 수 없는 것들을 솔직하게 적는다. 이 글은 ViewCheck 분석 결과를 읽고 행동하는 방법에 집중했지만, 그 경계 바깥에도 중요한 문제들이 있다.

수동 접근성 검사의 영역: 자동화가 탐지하지 못하는 약 60~70%의 접근성 이슈는 실제 보조기술(스크린리더, 키보드 전용 탐색, 음성 입력)을 쓰는 사람이 실제로 사이트를 사용해봐야 발견된다. 이건 ViewCheck가 대신할 수 없는 부분이고, 전문 접근성 검사자나 장애 당사자 참여 검사(사용자 테스트)가 필요하다.

코드 외부의 품질 문제: 콘텐츠의 언어 난이도, 이미지 정보의 충분성, 영상의 자막 품질처럼 코드가 아닌 콘텐츠 자체의 품질은 도구로 판정하기 어렵다. 이건 콘텐츠 담당자가 별도로 다뤄야 한다.

브라우저·기기 다양성: ViewCheck는 분석 시점에 특정 브라우저 환경으로 접속한다. 실제 이용자는 다양한 브라우저, 다양한 기기, 다양한 OS로 접속한다. 특정 브라우저 버그나 기기별 렌더링 차이는 별도의 크로스 브라우저 테스트가 필요하다.

동적 상호작용 시나리오: 버튼을 눌렀을 때의 동작, 폼 제출 후의 처리, 오류 상태가 표시됐을 때의 구조 — 이런 런타임 상호작용 중에 발생하는 문제는 정적 분석만으로는 탐지가 어렵다. 이건 ViewCheck가 지속적으로 개선하는 방향이지만, 현재도 한계가 있다.

이 한계들을 알고 ViewCheck 결과를 사용하는 것과, 모르고 사용하는 것은 다른 결과를 낳는다. 도구의 한계를 이해한 사용자가 도구를 더 잘 쓴다. 그리고 도구를 더 잘 쓰는 사람이 더 좋은 공공 웹을 만드는 데 기여한다.

리포트 읽기를 습관으로 만드는 법 — 세 가지 제안

마지막으로, 분석 결과를 일회성 이벤트가 아니라 운영의 루틴으로 만들기 위한 세 가지 구체적 제안을 드린다.

제안 1: 분기 정기 점검 일정 고정

분기당 한 번, 같은 URL로 동일한 조건(분석 페이지 수, 포함 경로)으로 분석을 실행한다. 결과를 누적 기록해 추이를 관리한다. 특별한 개선 작업이 없었더라도, 사이트가 어떻게 변화하는지를 주기적으로 확인하는 것 자체가 중요하다.

제안 2: 수정 완료 항목은 재분석으로 확인

개발팀에서 "수정 완료"가 오면, 반드시 ViewCheck 재분석으로 해당 규칙이 통과로 전환됐는지 확인한다. "완료 보고"와 "검증된 완료"는 다르다. 재분석으로 확인하는 것이 검증의 마지막 단계다.

제안 3: 리포트 독해 역량을 팀 내에 공유

담당자 한 명만 리포트를 읽을 줄 알면, 그 담당자가 바뀌면 역량이 사라진다. 팀 내에서 리포트 읽는 법을 공유하고, 개발팀에도 "어떤 규칙 ID가 어떤 수정을 의미하는지"를 안내해 두는 것이 장기적인 품질 관리의 기반이다. 이 글이 그런 공유 자료의 일부로 쓰일 수 있다면 우리로서는 가장 반가운 활용이다.

회의실에서 네 명의 한국인 팀원이 분기 정기 검토 회의를 하는 모습. 한 명은 화면에 품질 개선 추이 그래프를 띄워 발표하고, 나머지는 노트를 취하고 있다. — 분기 정기 점검이 팀의 루틴이 될 때, 일회성 감사가 아닌 지속적 품질 관리가 된다.

마무리 — 숫자를 행동으로 연결하는 것은 사람이다

이 글을 통해 전하고 싶었던 건 하나다. 분석 결과는 도구가 내주지만, 그 결과를 읽고 이해하고 행동으로 연결하는 것은 여전히 사람이 하는 일이다. 74점이라는 숫자, 228개 미통과라는 숫자, 빨간 칸들이 가득한 위반 매트릭스 — 이것들은 행동의 재료이지 결론이 아니다.

좋은 리포트 독해는 "이 숫자가 무엇을 의미하는가"를 묻는 데서 시작해, "그러면 나는 다음에 무엇을 해야 하는가"로 끝난다. 이 글이 그 중간 과정을, 처음 분석 결과를 받아 든 담당자가 조금 덜 막막하게 건너갈 수 있게 도왔으면 한다.

ViewCheck는 아직 완성된 도구가 아니다. 근거의 정밀도, N/A를 줄이는 능력, 시각적 판단이 필요한 영역의 커버리지 — 모두 계속 개선하고 있는 중이다. 리포트 독해 가이드인 이 글도 마찬가지다. 실제 사용 과정에서 "이 부분이 더 필요하다"는 피드백이 있다면, 다음 편에서 보완하려 한다.

이 시리즈 G 트랙의 마지막 편에서는 분석 결과를 외주 개발사에 전달하고, 수정이 완료됐을 때 어떻게 검수하는지를 더 실무 중심으로 다룰 예정이다. 이번 편이 리포트 '읽기'에 집중했다면, 그 다음은 리포트를 '현장으로 가져가기'에 집중할 것이다.

공공 웹의 품질은 도구가 혼자 만들 수 없다. 도구가 빠르게 훑고, 근거를 대고, 우선순위를 정렬해 줄 수 있지만 — 그것을 팀 안에서 공유하고, 개발자에게 전달하고, 수정하고, 다시 확인하는 과정은 사람이 있어야 한다. 그 사람들을 위한 작은 안내서가 됐길 바란다.

참고문헌

본문에 인용한 모든 출처는 작성 시점에 실재 여부를 WebSearch로 검증했다. 확인되지 않은 출처는 사용하지 않았다.

국내 — 공식 기준·정책자료

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정 시행). 국가법령정보센터. https://www.law.go.kr/admRulLsInfoP.do?admRulId=37565
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부 개정 및 「전자정부 웹사이트 품질관리 가이드」 수정본 안내(고시 제2025-46호). https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디지털 정부서비스 UI/UX 가이드라인. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/

해외 — 접근성 표준·심각도 방법론·감사 리포트 독해

W3C, Web Content Accessibility Guidelines (WCAG) 2.2. (WCAG 2.2는 87개 성공 기준: Level A 32개, Level AA 24개, Level AAA 31개.) https://www.w3.org/TR/WCAG22/
WebAIM, "Using Severity Ratings to Prioritize Web Accessibility Remediation". (Critical / Significant / Moderate / Recommendation 4수준 심각도 체계.) https://webaim.org/blog/severity-ratings/
Nielsen Norman Group, Jakob Nielsen, "Severity Ratings for Usability Problems". (0~4 척도: 0=문제 없음, 4=사용성 재앙 — 출시 전 필수 수정.) https://www.nngroup.com/articles/how-to-rate-the-severity-of-usability-problems/
Deque, "Accessibility Audit Results: Next Steps — I've Received the Results of My Accessibility Audit. Now What?". (감사 결과 이후 우선순위 결정, 빠른 승리, 검증 방법론.) https://www.deque.com/blog/ive-received-the-results-of-my-accessibility-audit-now-what/
Deque, "Accessibility Prioritization: Tactical Roadmap Part II". (고빈도·고심각도 위반 우선 처리, 파급 효과 기반 전략.) https://www.deque.com/blog/accessibility-prioritization-tactical-roadmap-part-ii/
AllAccessible, "Website Accessibility Audit: Complete 2025 WCAG 2.2 Guide + Free Template". (자동화 도구와 수동 검사 조합, 템플릿 단위 묶기 전략.) https://www.allaccessible.org/blog/website-accessibility-audit-guide-wcag-template
GOV.UK Government Digital Service, "Accessibility monitoring of public sector websites and mobile apps from 2022 to 2024". (1,203개 공공 사이트·21개 앱 모니터링 결과. 거의 모든 사이트에서 이슈 발견.) https://www.gov.uk/government/publications/accessibility-monitoring-of-public-sector-websites-and-mobile-apps-from-2022-to-2024/accessibility-monitoring-of-public-sector-websites-and-mobile-apps-from-2022-to-2024
GOV.UK Government Digital Service, "How organisations respond to accessibility monitoring". (접근성 모니터링 지적 이후 기관 대응 추적, 인식 향상 62%.) https://accessibility.blog.gov.uk/2023/08/23/how-organisations-respond-to-accessibility-monitoring/
TestParty, "Accessibility Audit Reports: Complete Guide for 2025". (자동화·수동 검사 조합, 완전한 WCAG 적합성 보증 요건.) https://testparty.ai/blog/accessibility-audit-reports-complete-guide-for-2025