AI 진단, 어디까지 믿어야 하나 — ViewCheck를 활용하는 사람을 위한 정직한 가이드
2026년 어느 날, 공공기관의 웹 담당자 한 명이 AI 분석 결과를 출력해 상사에게 내밀었다고 상상해 보자. "AI가 분석했더니 우리 사이트 KRDS 준수율이 68점입니다." 상사는 고개를 끄덕이며 "그럼 개선 계획 짜세요"라고 했다. 담당자는 돌아가 개발사에 수정 목록을 전달했다. 문제는, 그 68점이 무엇을 근거로
자동화 편향의 경계, 그리고 사람이 개입해야 할 지점을 찾아가는 실험 기록
들어가며 — "AI가 그랬어요"라는 보고서
2026년 어느 날, 공공기관의 웹 담당자 한 명이 AI 분석 결과를 출력해 상사에게 내밀었다고 상상해 보자. "AI가 분석했더니 우리 사이트 KRDS 준수율이 68점입니다." 상사는 고개를 끄덕이며 "그럼 개선 계획 짜세요"라고 했다. 담당자는 돌아가 개발사에 수정 목록을 전달했다. 문제는, 그 68점이 무엇을 근거로 나왔는지, 어떤 페이지를 봤는지, 어떤 규칙을 적용했는지, 그리고 그 결과를 믿을 수 있는지를 아무도 확인하지 않았다는 점이다.
이 장면은 가상이지만, AI 도구가 일선 업무에 깊이 들어오기 시작한 지금, 현실에서 그리 멀지 않다. 그리고 이것이 우리가 이 편에서 다루려는 주제다. ViewCheck LLM 분석이 무엇을 잘하는지는 이 시리즈의 앞선 편들에서 충분히 이야기했다. 이번에는 반대편 이야기를 한다. AI 진단 결과를 어디까지 믿을 수 있는가. 어디서부터는 사람이 직접 확인해야 하는가. 이 선을 정직하게 그어 두는 일이, 도구를 제대로 쓰는 출발점이라고 생각한다.
미리 밝혀두자. 이 글은 ViewCheck를 불신하게 만들려는 게 아니다. 오히려 반대다. 도구의 한계를 정확히 알아야, 그 도구를 제대로 쓸 수 있다. 무조건 믿는 것도 위험하고, 무조건 불신하는 것도 낭비다. 우리가 찾고자 하는 건 신뢰의 선(trust boundary) — 어디까지는 결과를 그대로 활용할 수 있고, 어디서는 반드시 사람이 들어가 확인해야 하는가 하는 경계선이다.
이 경계를 찾는 일은 ViewCheck를 만드는 우리에게도 진행 중인 연구다. 완성된 답을 내놓는 게 아니라, 우리가 어디까지 생각했는지를 솔직하게 공유하는 글이다.
자동화 편향이라는 심리적 함정
이야기를 시작하기 전에 개념 하나를 짚어두자. 심리학과 인간-컴퓨터 상호작용 연구에서 **자동화 편향(automation bias)**이라는 현상이 있다.
자동화 편향이란, 사람이 자동화 시스템의 출력을 비판적 검토 없이 수용하거나, 자동화 시스템이 틀렸을 때도 그 신호를 무시하는 경향을 뜻한다. 2025년 Springer의 AI & SOCIETY 저널에 발표된 Giuseppe Romeo와 Daniela Conti의 리뷰 논문 「Exploring automation bias in human–AI collaboration: a review and implications for explainable AI」는 헬스케어, 법률, 공공행정 등 고위험 도메인에서 수집한 35개 연구를 분석하며, 자동화 편향을 "AI가 생성한 출력을 신뢰할 만한 것으로 인식하게 만드는 경향"으로 정의한다. 특히 이 리뷰가 흥미로운 점은, 설명 가능한 AI(XAI)와 투명성 메커니즘이 자동화 편향을 오히려 강화할 수 있다는 역설을 지적한다는 것이다. 시스템이 "설명"을 더 많이 붙일수록, 사용자가 "아, 이유가 있구나"라며 더 쉽게 결과를 받아들이게 될 수 있다는 것이다.
이 연구는 2015년부터 2025년 4월까지 발표된 연구를 대상으로 하며, 2023~2024년이 가장 활발한 연구 시기였다고 밝힌다. 자동화 편향은 의료 진단, 국가 안보, 금융, 인사관리, 공공 행정 등 거의 모든 고위험 도메인에서 관찰됐다.
왜 이 개념이 중요한가. ViewCheck 같은 AI 기반 진단 도구를 쓸 때, 사용자는 자동으로 자동화 편향의 위험에 놓인다. 분석 결과가 숫자와 표로 깔끔하게 정리되어 나오면, 우리는 그것이 "정확하다"고 느끼는 경향이 있다. 특히 846개 규칙이라는 숫자, 통과/미통과/해당없음이라는 명확한 분류, KRDS 규칙 원문이라는 근거가 함께 붙어 나오면, 결과를 의심하는 일이 인지적으로 불편하게 느껴진다.
그런데 자동화 편향 연구들이 공통적으로 경고하는 건 바로 그 지점이다. 근거가 붙어 있다고 해서 판정이 항상 옳은 건 아니다. 근거는 "이 판정이 왜 그렇게 나왔는지"를 설명하지, "이 판정이 맞다"를 보증하지 않는다.
비슷한 맥락에서, TechTarget의 자동화 편향 정의 문서는 이 현상을 이렇게 설명한다. "자동화 편향은 자동화된 시스템의 제안이나 결정을 맹목적으로 따르는 경향이며, 그 시스템이 틀렸을 때조차 인간 판단이 그것을 무시하거나 과소평가하게 만든다." 이건 일부러 나쁜 짓을 하는 게 아니라, 인간의 인지 구조가 그렇게 작동하기 때문이다. 시간이 없고, 정보는 많고, 시스템이 그럴듯해 보이면 — 우리는 자연스럽게 그것을 따른다.
ViewCheck는 이 함정을 알고 있다. 그래서 우리는 처음부터 "AI가 그렇다고 하니 그런 거야"가 아니라 "근거를 확인할 수 있는 구조"를 만들려 했다. 하지만 그것만으로는 부족하다. 도구를 쓰는 사람도 이 함정을 인식하고 있어야 한다.
AI 진단 결과에는 세 가지 층위가 있다
ViewCheck LLM 분석이 내놓는 결과를 살펴보면, 사실 모든 결과가 같은 신뢰도를 갖지 않는다. 우리는 내부적으로 결과를 크게 세 가지 층위로 구분해서 생각한다.
첫 번째 층위: DOM 기반 규칙 판정 (높은 신뢰)
KRDS 846규칙 중 상당 부분은 DOM(페이지의 HTML 구조와 ARIA 속성, CSS 값)을 직접 읽어서 if/else 로직으로 판정된다. 예를 들어 "버튼 요소에 aria-label이 있는가", "색상 대비 비율이 기준값 이상인가", "폼 입력 필드에 label이 연결되어 있는가" 같은 규칙이다. 이런 류의 판정은 논리가 명확하다. DOM에 그 값이 있거나 없거나 — 둘 중 하나다. 판정 과정에서 AI의 "판단"이 개입하는 여지가 적다.
이 층위의 결과는 상대적으로 신뢰도가 높다. 물론 100%는 아니다. DOM 추출 과정에서 데이터가 누락될 수도 있고, 자바스크립트로 동적으로 생성되는 요소를 놓칠 수도 있다. 하지만 "이 페이지의 이 버튼에 label이 없다"는 식의 판정은 확인하기도 쉽다. 사용자가 해당 페이지에서 개발자 도구를 열어 직접 확인하면 된다.
두 번째 층위: AI·Vision 기반 판정 (중간 신뢰)
DOM으로는 알 수 없는 영역이 있다. 이미지나 비표준 HTML로 만든 UI 요소, 시각적 레이아웃, 텍스트의 의미적 적절성 같은 것들이다. 이런 영역에서 ViewCheck는 Vision AI와 LLM을 활용한다. 스크린샷을 분석해 "여기에 버튼처럼 생긴 요소가 있다"고 감지하거나, "이 텍스트가 KRDS UX라이팅 원칙에 부합하는가"를 판정하는 식이다.
이 층위는 두 번째로 신뢰도가 떨어진다. AI는 시각적으로 그럴듯한 추론을 하지만, 그 추론이 항상 맞지는 않는다. 특히 감지 결과에는 오탐(false positive)과 미탐(false negative)이 모두 존재한다. ViewCheck가 Vision 판정 결과에 confidence 수치를 함께 제공하는 이유가 여기에 있다. 신뢰도가 낮은 감지 결과는 특히 더 주의 깊게 봐야 한다.
세 번째 층위: '해당없음(N/A)' 으로 남겨진 것들 (신뢰 아님 — 미판정)
잘 간과되는 층위다. 846규칙 중 특정 규칙이 N/A로 나온 경우, 이건 "이 사이트는 이 규칙에서 문제가 없다"는 뜻이 아니다. 두 가지 의미가 있다.
하나는 정당한 N/A — 해당 페이지에 그 규칙이 다루는 컴포넌트가 실제로 없는 경우다. 로그인 버튼이 없는 페이지에서 로그인 관련 규칙이 N/A가 나오는 건 당연하다.
다른 하나는 분석 한계로 인한 N/A — 그 컴포넌트가 실제로 있는데도, DOM 추출이나 Vision AI가 감지하지 못해서 N/A로 처리된 경우다. 이게 문제다. 이 경우 N/A는 "이상 없음"이 아니라 "확인 안 됨"이다.
실제로 ViewCheck의 서울시 메인 페이지 분석 예시에서, 846규칙 중 통과 289개, 미통과 228개, 해당없음 329개가 나왔다. N/A 329개 중 진짜 N/A와 미감지 N/A가 섞여 있다. 이 둘을 구분하지 않고 "329개는 해당없음이니 신경 안 써도 된다"고 생각하면 위험하다.
우리는 N/A 중 어떤 것이 정당한 N/A이고 어떤 것이 미감지인지를 점점 더 명확히 구분하려 하고 있다. 하지만 이건 지금도 완전히 해결된 문제가 아니다.
자동화가 잘 잡는 것과 못 잡는 것
이 세 층위를 조금 더 구체적으로 들여다보자. 도구를 쓰는 사람에게 실질적으로 도움이 되는 방식으로.
자동화가 잘 잡는 것들:
aria 속성 누락: 버튼에 aria-label이 없는 것, 이미지에 alt 속성이 없는 것, 폼 필드에 label이 연결되지 않은 것 — 이런 건 DOM을 읽으면 바로 알 수 있다. 자동화가 사람보다 훨씬 빠르고 정확하다.
색상 대비: 텍스트 색상과 배경 색상을 수치로 비교해 WCAG 기준(4.5:1 이상 등)을 통과하는지 판정한다. 사람이 눈으로 보면 "비슷해 보이는데 괜찮은 건가?" 애매하게 느낄 수 있지만, 계산은 명확하다.
HTML 구조의 순서와 위계: 헤딩이 H1 → H2 → H3 순서를 건너뛰는지, 리스트 구조가 올바른지 같은 것들.
보안 헤더의 존재: HSTS, CSP, X-Frame-Options 같은 HTTP 응답 헤더가 설정돼 있는지. 서버에 직접 요청해보면 알 수 있다.
Core Web Vitals: LCP, CLS, FCP, TTFB 같은 성능 지표. 실제 브라우저로 로딩해서 측정한 값이다.
robots.txt, sitemap.xml 존재와 구조: 파일이 있는지, 기본 지시어가 제대로 쓰여 있는지.
이 항목들은 "도구가 말하면 그냥 믿어도 되나요?"라는 질문에 "그렇다"에 가장 가깝게 답할 수 있는 것들이다. 물론 여전히 결과를 샘플링해서 직접 확인하는 습관은 좋다. 하지만 자동화가 이런 류의 항목을 수백, 수천 페이지에 걸쳐 빠짐없이 훑는 능력은 사람이 따라갈 수 없다.
자동화가 못 잡거나 잘못 잡을 수 있는 것들:
이미지의 alt 텍스트 품질: "이 이미지에 alt가 있는가"는 잘 잡는다. 하지만 "이 alt가 이미지의 내용을 적절하게 설명하는가"는 매우 다른 문제다. alt="이미지"처럼 의미 없는 alt가 있어도 자동화는 "있다"고 판정한다. 이건 사람이 봐야 한다.
읽기 순서의 논리적 타당성: DOM의 순서가 시각적 표현의 순서와 다를 때, 스크린 리더 사용자가 혼란을 겪는다. 이걸 자동화로 잡기 어렵다. DOM 순서가 맞아도 CSS로 시각적 위치를 바꿔버리면, 자동화는 모른다.
폼 오류 메시지의 충분성: "오류 메시지가 표시되는가"는 잡을 수 있다. "그 오류 메시지가 사용자가 뭘 어떻게 고쳐야 하는지를 충분히 안내하는가"는 사람의 판단이 필요하다.
실제 상호작용 후의 동작: 버튼을 눌렀을 때, 폼을 제출했을 때 — 동적으로 변하는 상태는 정적 분석으로 잡기 어렵다. 스크린 리더로 직접 써봐야 아는 영역이 많다.
문화적·맥락적 UX 판단: "이 표현이 한국 공공기관 사용자에게 자연스러운가", "이 버튼 위치가 예상 가능한 곳에 있는가" — 이런 건 아직 자동화가 대신하기 어렵다.
Deque Systems의 연구가 이 한계를 수치로 보여준다. 세계적인 웹 접근성 도구 업체인 Deque는 2,000개 이상의 감사 데이터(13,000+ 페이지, 약 300,000개 이슈)를 분석해, 자동화 테스트(axe suite)가 평균 57%의 접근성 이슈를 잡아낸다는 결과를 발표했다(Deque Systems, The Automated Accessibility Coverage Report, 2021). 그리고 나머지 43%는 자동화로는 감지할 수 없다. GOV.UK의 정부디지털서비스(GDS)는 2017년 연구에서 자동화 도구가 접근성 이슈의 약 30%만 찾아낸다고 결론짓고, 이를 근거로 자동 테스트와 수동 테스트를 병행하는 전략을 공식 채택했다(GOV.UK Design System, Accessibility Strategy, 2023 업데이트).
비율에는 다소 차이가 있지만, 핵심 메시지는 같다. 자동화는 절반도 채 안 되는 문제를 잡는다. 나머지는 여전히 사람 몫이다.
'근거가 있다'는 것과 '옳다'는 것은 다르다
ViewCheck는 모든 판정에 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 기반의 근거를 함께 제공하려 한다. KRDS 규칙 원문, 공식 가이드, 컴포넌트 스펙 같은 문서를 검색해서 "이 판정이 어떤 문서의 어떤 내용에 근거한 것인지"를 참조패널에 보여주는 방식이다.
이건 중요한 설계 원칙이다. "AI가 그렇대"가 아니라 "이 규칙 원문에 이렇게 명시되어 있고, 그래서 이렇게 판정됐다"를 보여주는 것이 훨씬 낫다. 적어도 사용자가 "그 원문을 내가 직접 읽어볼 수 있다"는 검증의 가능성이 열려 있기 때문이다.
그런데 여기서 오해가 생길 수 있다. 근거 문서가 있다는 것이, 판정의 정확성을 보증하지는 않는다. 두 가지 이유에서다.
첫 번째는, RAG가 올바른 문서를 검색해도, 그 문서를 올바르게 해석했는가의 문제다. 규칙 원문이 "A여야 한다"고 쓰여 있을 때, "이 페이지가 A를 충족하는가"를 판정하는 건 여전히 추론의 영역이다. 그 추론이 틀릴 수 있다.
두 번째는, LLM 자체의 환각(hallucination) 가능성이다. 대규모 언어 모델은 그럴듯하게 틀린다. 연구에 따르면 GPT-4 기준으로 29%의 환각률이 보고된 사례도 있으며, 법률 도메인 특화 모델에서도 17~33%에 달하는 경우가 있다(관련 연구 참조). 환각은 자신감 있는 어조로, 맥락적으로 그럴듯하게 제시된다. 비전문가는 이를 사실과 구분하기 어렵다.
ViewCheck는 이 문제를 DOM 기반의 if/else 판정을 우선으로 두고, AI는 DOM이 판정할 수 없는 영역에만 개입시킴으로써 구조적으로 억제하려 한다. DOM이 "통과"로 판정한 건 AI가 함부로 뒤집지 않는다. 이게 중요한 원칙이다. AI를 1차 판정자로 쓰는 게 아니라, DOM의 명확한 영역은 DOM에 맡기고 AI는 보조자로 쓰는 구조다.
하지만 이 구조도 완벽하지 않다. DOM 추출에서 데이터가 누락됐다면, 그 누락이 이후 모든 판정을 오염시킬 수 있다. 우리가 "코드 경로만 보고 '문제없다'고 결론 내지 말고, 실제 프로덕션에서 돌려보고 결과를 눈으로 확인하라"를 내부 원칙으로 삼는 이유가 이것이다. 제품이 사용자에게 요구하는 것을, 만드는 우리가 먼저 지키는 것이다.
XAI(설명 가능한 AI) 연구는 이 역설을 냉정하게 지적한다. IBM의 Explainable AI 정의에 따르면, "설명 가능한 AI의 목표는 AI 모델의 과정과 결과를 인간이 이해할 수 있게 하는 것"이다. 그런데 Springer의 리뷰 연구(Romeo & Conti, 2025)가 보여주듯, 설명이 너무 복잡하거나, 반대로 너무 단순화될 때 — 양쪽 모두 오히려 자동화 편향을 강화할 수 있다. 설명을 보여주는 것만으로 신뢰 문제가 해결되지 않는다는 것이다.
자동화 편향에 맞서는 설계 원칙들
그렇다면 ViewCheck는 자동화 편향의 위험을 어떻게 줄이려 하는가. 몇 가지 설계 원칙을 정직하게 공유한다.
원칙 1: 판정 근거를 항상 노출한다
판정 결과만 보여주지 않고, 그 판정이 어떤 규칙·어떤 문서에서 왔는지를 참조패널로 노출한다. 사용자가 "이 근거 맞나?" 하고 직접 확인할 수 있도록. 결과를 블랙박스에 담아 숫자만 보여주지 않는다는 뜻이다.
원칙 2: 신뢰도의 차이를 구분한다
모든 판정이 같은 신뢰도를 가지는 것처럼 보이지 않게 하려 한다. DOM 기반 확정 판정과 AI 추론 기반 판정은 다르다. Vision AI의 감지 결과에는 confidence 수치가 있다. 이 차이를 사용자가 볼 수 있어야 한다. (이 부분은 아직 UI에서 더 명확하게 표현해야 할 과제가 있다.)
원칙 3: '해당없음'을 '문제없음'으로 오해하지 않게 한다
N/A는 미확인일 수 있다. 이 사실을 사용자에게 전달하는 방식을 계속 개선하고 있다. N/A 항목 중 "이 페이지에서 해당 컴포넌트가 없어서 N/A"와 "분석이 감지하지 못해서 N/A"를 점점 더 명확히 구분하려 한다.
원칙 4: 다중 페이지 결과를 기본으로 한다
메인 페이지 한 장의 결과가 사이트 전체를 대표하지 않는다. ViewCheck가 다중 페이지 분석을 기본으로 설계한 이유다. 메인은 깔끔한데 신청 페이지에서 접근성이 무너지는 사례를 우리는 실제로 많이 봤다.
원칙 5: AI가 DOM을 뒤집지 않는다
DOM이 명확히 판정한 결과를, Vision AI나 LLM이 "나는 다르게 본다"는 이유로 바꾸지 않는다. 충돌 방지 원칙이다. AI는 DOM이 비워둔 빈칸(N/A, PENDING)만 채운다. 이게 없으면 결과가 일관성 없이 흔들린다.
이 다섯 가지 원칙이 자동화 편향을 완전히 없애주지는 않는다. 하지만 최소한 "AI가 그렇다고 하니까"라는 단순 수용을 구조적으로 어렵게 만드는 방향으로 설계된 원칙들이다.
사람이 반드시 들어가야 할 다섯 가지 지점
ViewCheck 결과를 받은 뒤, 어디서 사람이 직접 확인해야 할까. 우리가 정리한 다섯 가지 지점을 공유한다. 이건 ViewCheck만이 아니라, AI 기반 웹 품질 진단 도구를 쓰는 어느 경우에도 해당하는 이야기다.
지점 1: 높은 우선순위(P0) 위반 항목
ViewCheck는 위반의 심각도를 P0(긴급)~P3(낮음)으로 분류한다. P0 항목은 서비스 이용 자체를 막거나, 법적 의무 위반과 직결될 수 있는 것들이다. 이 항목들은 AI 판정을 믿더라도, 사람이 실제 화면에서 직접 확인하고 재현해보는 과정이 필요하다. "AI가 P0라고 했으니 긴급하게 고쳐야 한다"고 외주 개발사에 전달하기 전에, 그 위반이 실제로 존재하는지를 눈으로 한 번 확인하는 습관이 중요하다.
지점 2: alt 텍스트 품질과 같은 '내용적 적절성' 판단
앞서 말했듯, alt 속성의 존재 유무는 자동화가 잘 잡는다. 하지만 alt의 내용이 적절한지는 사람이 봐야 한다. 이미지를 보고, "이 alt 설명이 이 이미지를 본 적 없는 사람에게 이미지의 의미를 충분히 전달하는가"를 판단하는 건 아직 자동화가 대신하기 어려운 영역이다.
지점 3: 실제 스크린 리더·보조기술 사용자 관점의 검증
WCAG와 KRDS 준수의 궁극적 목적은 장애가 있는 사용자도 사이트를 동등하게 이용할 수 있게 하는 것이다. 자동화 검사는 구조적 규칙을 확인하지만, "실제로 스크린 리더로 이 페이지를 탐색하면 어떤 경험인가"를 대신하지 못한다. 중요한 서비스(신청, 로그인, 검색)는 NVDA, 나레이터, VoiceOver 같은 보조기술로 직접 테스트하는 것을 권장한다. Deque의 데이터처럼, 자동화가 5057%의 이슈를 잡는다면 나머지 4350%는 수동 테스트 없이는 보이지 않는다.
지점 4: 사이트의 특수 기능과 서비스 흐름
공공 웹사이트에는 외부 연계 시스템, 공인인증(전자서명), 동영상 플레이어, 지도 서비스, PDF 뷰어 같은 특수 기능들이 있다. 이런 요소들은 표준 DOM 분석으로 품질을 판정하기 어렵다. 민원 신청 흐름, 신고 프로세스처럼 여러 단계를 거치는 서비스도 마찬가지다. 이런 영역은 ViewCheck가 N/A 처리하거나 불완전하게 감지할 가능성이 높다. 이 부분은 반드시 사람이 직접 흐름을 따라가며 확인해야 한다.
지점 5: 결과가 '기대와 크게 다를 때'
가장 중요한 지점이다. AI 분석 결과가 사용자의 직관이나 사전 지식과 크게 다를 때 — "이 사이트가 갑자기 이렇게 높은 점수가 나온다고?" 또는 반대로 "이건 분명히 잘 만든 사이트인데 왜 이렇게 낮지?" — 이럴 때 결과를 그냥 받아들이지 말아야 한다. 차이의 원인을 추적해야 한다. 어쩌면 크롤링이 특정 페이지를 놓쳤을 수도 있고, 어쩌면 특정 규칙이 잘못 적용됐을 수도 있다.
이 다섯 지점은 엄밀한 의미에서의 "반드시 이렇게 하세요" 지침이 아니라, "우리가 실제 사용을 관찰하면서 발견한, 자동화가 비교적 취약한 곳들"이다. 사이트의 특성과 담당자의 상황에 따라 더 많은 수동 검토가 필요할 수 있다.
'100점 짜리 자동 결과'를 주의해야 하는 이유
자동화 진단에서 가장 역설적인 위험 중 하나가 완벽한 점수다. 자동화 검사에서 모든 항목이 통과로 나오면, 우리는 자연스럽게 "이 사이트는 괜찮구나"라고 결론짓는다. 그런데 실제로는, 자동화가 잡을 수 없는 영역이 있기 때문에 완벽한 점수가 나왔을 때 오히려 더 주의해야 할 수 있다.
Adrian Roselli의 2023년 분석 「Comparing Manual and Free Automated WCAG Reviews」는 자동화 도구의 결과와 수동 검사의 결과를 비교하며, "자동화 검사에서 이슈가 전혀 없다는 결과는, 이슈가 없다는 뜻이 아니라 자동화가 감지할 수 있는 이슈가 없다는 뜻"이라고 명확히 한다. 다른 말로, 100점은 "이슈 없음"이 아니라 "자동화가 찾은 이슈 없음"이다.
이건 ViewCheck에도 그대로 적용된다. ViewCheck가 KRDS 846규칙 판정에서 모든 규칙을 "통과"로 반환한다면, 그것은 두 가지 중 하나다. 진짜로 모든 규칙을 충족하는 드문 경우거나, 아니면 많은 규칙이 N/A 처리되어 판정 자체가 일어나지 않은 경우. 두 번째가 더 흔하다.
ViewCheck의 프로덕션 실측에서 서울시 메인 페이지의 경우, 846규칙 중 해당없음(N/A)이 329개였다. 이 329개는 점수 계산에서 분모에서 빠진다. 즉 점수는 846개 전체가 아니라, 판정이 실제로 일어난 규칙들을 기준으로 계산된다. 이 사실을 모르면, 높은 점수를 "846개 규칙 전부 괜찮다"는 의미로 오해할 수 있다.
우리는 이 부분을 UI에서 더 명확하게 표현하려 한다. "이 점수는 판정된 N개의 규칙 기준"이라는 것을, 숫자만큼 눈에 잘 보이게 만드는 일이 아직 과제로 남아 있다.
인간-AI 협업에서 신뢰를 calibrate하는 법
자동화 편향에 대응하는 이론적 프레임 중 하나가 **신뢰 calibration(trust calibration)**이다. 이는 AI 시스템에 대한 신뢰를 실제 시스템의 능력에 맞게 조정하는 과정이다. 너무 낮은 신뢰(과도한 불신)는 유용한 도구를 버리게 만들고, 너무 높은 신뢰(맹목적 신뢰)는 오류를 방치하게 만든다.
EDPS(유럽 데이터보호 감독관)의 2025년 TechDispatch는 자동화된 의사결정에 대한 인간 감독을 다루며, "자동화 편향과 자동화 유발 안일함(automation-induced complacency)은 같은 종류의 자동화 오남용을 반영하는 겹치는 개념"이라고 정리한다. 즉, 자동화 편향은 결과를 맹목적으로 따르는 것이고, 안일함은 자동화 모니터링 자체를 게을리하는 것인데, 둘 다 같은 결말로 이어진다.
신뢰를 calibrate하는 실용적인 방법들:
방법 1: 샘플 검증을 습관화한다
전체 결과를 일일이 수동 확인할 수는 없다. 하지만 무작위 혹은 의심되는 항목을 샘플로 골라 직접 확인하는 것은 가능하다. "이 서비스 패턴 규칙이 통과라고 나왔는데, 실제 신청 화면에서 그게 맞나?"를 한 번씩 확인하다 보면, 도구가 어디서 잘 맞고 어디서 어긋나는지가 감으로 잡힌다.
방법 2: 과거 결과와 비교한다
이번 달 결과와 지난 달 결과를 비교했을 때 갑자기 점수가 크게 올랐다면, 기쁘기 전에 "왜 올랐지?"를 먼저 물어야 한다. 실제로 개선이 됐을 수도 있지만, 크롤링 대상 페이지가 바뀌었거나, 분석 로직이 업데이트됐거나, 특정 페이지가 점검에서 빠진 것일 수도 있다.
방법 3: 다른 도구와 교차 검증한다
ViewCheck만으로 모든 걸 판단하지 않는다. axe-core, WAVE, IBM Equal Access 같은 접근성 도구의 결과와 비교하거나, 직접 개발자 도구로 DOM을 열어보는 것이 도움이 된다. 서로 다른 도구가 같은 문제를 지적하면 신뢰도가 올라가고, 한 도구만 지적한다면 그 도구가 맞는지를 더 주의 깊게 살펴야 한다.
방법 4: 'AI가 말했다'와 '확인됐다'를 언어적으로 구분한다
보고서를 쓸 때나 상사에게 설명할 때, "AI 분석 결과 68점입니다"와 "우리 팀이 AI 분석을 기반으로 검토한 결과, 샘플 확인을 거쳐 68점 수준으로 판단됩니다"는 다른 무게를 갖는다. 후자가 더 정직하고, 책임의 소재도 명확하다. 이 언어적 구분이 자동화 편향에 맞서는 실용적인 방패다.
공공 영역에서 AI 진단 결과의 법적 책임 문제
잠깐 무거운 이야기를 해야 할 것 같다. 공공기관 웹사이트의 KRDS·접근성 준수는 단순한 품질 문제가 아니라 법적 의무와 연결된다.
「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정, 법제처 국가법령정보센터·행정안전부)은 중앙행정기관, 소속기관, 공공기관이 웹사이트의 품질을 관리해야 한다는 의무를 명시하고 있다. 「국가정보화 기본법」 및 「장애인차별금지 및 권리구제 등에 관한 법률」은 웹 접근성을 법적 의무로 규정한다.
이 맥락에서 AI 진단 결과가 갖는 위치를 냉정하게 정리해야 한다.
AI 분석 결과는 법적 준수를 보증하지 않는다.
ViewCheck의 분석 결과가 "통과"라고 표시되어도, 그것이 법적 의미의 준수를 보증하지 않는다. 진단 도구는 법적 판단을 대신할 수 없다. 법적 분쟁이나 공식 감리에서 "AI 도구가 통과라고 했어요"는 방어 논리로 충분하지 않다. 공식적인 접근성 인증이나 법적 준수 확인은 공인된 전문가의 검토가 필요하다.
행안부 지침에 따르면 공공 웹사이트는 정기 품질 점검을 받도록 되어 있다. ViewCheck는 이 정기 점검을 준비하는 과정에서 어디가 문제인지를 빠르게 파악하고, 개선 우선순위를 정하는 데 도움을 줄 수 있다. 하지만 ViewCheck의 결과 자체가 공식 점검을 대체하지는 않는다.
이 부분을 명확히 하는 이유는 두 가지다. 하나는 사용자가 결과를 과신해서 법적 리스크에 노출되는 일을 막기 위해서다. 다른 하나는, 이 한계를 명확히 해야만 도구가 제 역할을 할 수 있기 때문이다. "다 해결해 줄게"라는 도구는 결국 신뢰를 잃는다.
공공 영역 자동화의 세계적 흐름과 한국의 맥락
자동화된 공공 서비스 품질 진단이라는 흐름은 한국만의 이야기가 아니다.
영국 GOV.UK Design System은 자동화 테스트와 수동 테스트를 명확히 병행하며, GDS 블로그(2023)는 "수동 테스트 없이 자동화만으로는 약 30%의 이슈밖에 찾지 못한다"는 자체 연구 결론을 공개적으로 공유했다. GOV.UK의 접근성 전략(Accessibility Strategy)은 이를 근거로, 모든 컴포넌트와 패턴에 대해 자동화+수동 병행 테스트를 의무화하는 방향을 택한다.
미국의 USWDS(U.S. Web Design System)도 유사한 방향이다. 자동화는 빠르게 넓게 잡는 첫 번째 방어선이고, 수동 테스트는 그 뒤를 보완하는 두 번째 방어선이라는 인식이 자리잡혀 있다.
한국의 경우, 2025년 KISDI(정보통신정책연구원)의 「한국 AI 정책 현황 및 발전 방안」 보고서는 한국이 AI 관련 법안을 통해 AI의 신뢰 기반을 조성하는 방향을 택하고 있으며, 공정성·안전성·설명 가능성이 AI 서비스 신뢰 확보의 핵심 기준으로 제시된다고 정리한다. 이는 AI 진단 도구에도 그대로 적용된다. 설명 가능성과 신뢰 기반 없이 "AI가 분석했으니 믿어라"는 방식은 시대적으로 맞지 않는 방향이다.
ViewCheck가 RAG 근거를 제공하고, DOM 기반 판정을 AI 추론보다 우선시하며, N/A의 의미를 구분하려는 이유 중 하나가 여기에 있다. 신뢰할 수 있는 AI 진단 도구라는 것은, 결과만 내놓는 도구가 아니라 그 결과를 검증할 수 있게 만드는 도구여야 한다.
장기적으로 신뢰를 쌓는 방법
신뢰의 선을 찾는 일은 도구를 처음 쓰는 날 완성되지 않는다. 시간이 지나면서 쌓이는 과정이다. ViewCheck를 활용하는 조직이 장기적으로 AI 진단 결과에 대한 건강한 신뢰를 형성하는 방법을 제안한다.
첫 번째: 도입 초기에 의도적으로 많이 확인한다
처음에는 도구가 말하는 것을 자주 사람이 직접 확인한다. "AI가 P0 위반이라고 했는데 실제로 그런가?"를 여러 번 확인하다 보면, 이 도구가 어떤 영역에서 신뢰할 만하고 어떤 영역에서 주의가 필요한지를 몸으로 익힌다. 이 과정이 귀찮아 보여도, 나중에 "AI가 그랬으니까"라는 이유로 잘못된 개선을 진행하는 것보다 훨씬 적은 비용이다.
두 번째: 담당자를 위한 '읽기 가이드'를 만든다
ViewCheck 결과를 받았을 때 어떻게 읽어야 하는지를 내부 가이드로 정리해 두면 좋다. "P0 항목은 이렇게 확인한다", "N/A 항목은 이 경우에 수동 확인이 필요하다", "Vision AI 결과는 confidence 0.7 이상만 신뢰한다" 같은 식의 내부 약속이다. 이건 ViewCheck가 대신해줄 수 없는 부분이다. 조직 내부의 경험이 쌓이면서 만들어지는 것이다.
세 번째: 결과를 개선과 연결하고, 개선 후에 재확인한다
AI 진단 → 개선 → AI 재진단의 사이클을 만들면, 자연스럽게 도구의 신뢰도를 테스트하게 된다. "이 항목을 고쳤더니 다음 분석에서 통과로 바뀌었나?" 이 질문 자체가 도구를 실용적으로 검증하는 방식이다. 고쳤는데도 변화가 없다면 — 그게 개선이 덜 됐기 때문인지, 아니면 도구가 변화를 감지 못한 것인지를 추적하는 과정에서 도구에 대한 이해가 깊어진다.
네 번째: 담당자를 교체해도 지식이 남도록 기록한다
공공기관의 특성상 담당자가 자주 바뀐다. 전임자가 "이 도구를 이렇게 써왔다, 이 부분은 주의해야 한다"는 경험을 남기지 않으면, 신임 담당자는 도구를 처음 쓰는 것처럼 시작해야 한다. 신뢰 calibration의 과정을 문서로 남기는 것이 조직의 자산이 된다.
ViewCheck가 스스로 지키는 원칙들
이 편에서 우리는 도구의 한계를 꽤 솔직하게 이야기했다. 그렇다면 ViewCheck를 만드는 우리는 이 한계를 어떻게 대면하는가. 몇 가지 내부 원칙을 공유한다.
"코드 경로만 보고 문제없다고 결론 내리지 않는다."
코드가 맞아 보여도, 실제 프로덕션에서 돌려보고 응답을 눈으로 확인한 뒤에야 "된다"고 말한다. 이 원칙이 없으면, 코드 상으로는 맞는데 실제 배포 후에는 틀린 경우를 발견하지 못한다.
"추측을 사실처럼 말하지 않는다."
"~일 수 있다", "~로 보인다", "아마 ~일 것이다" 같은 추측성 표현을 결론에 섞지 않는다. 확인 안 된 사항은 "확인 안 됨"이라고 명시하고, 확인 방법을 제시한다. 이건 이 시리즈 전체의 톤이기도 하다.
"AI가 DOM을 뒤집지 않는다."
AI는 DOM이 비워둔 자리만 채운다. DOM이 명확히 판정한 결과를, AI가 "나는 다르게 본다"는 이유로 바꾸지 않는다. 이 원칙이 지켜져야 결과가 일관성을 유지한다.
"다중 페이지가 기본이다."
메인 1장을 보고 전체를 판단하지 않는다. 분석은 사이트의 여러 유형의 페이지를 포함해야 진짜 분석이다. 이건 사용자에게 요구하는 것이기도 하고, 우리가 내부 테스트를 할 때 스스로 따르는 기준이기도 하다.
"서브에이전트 보고를 그대로 전달하지 않는다."
내부에서 분석 결과를 보고할 때, 하위 프로세스의 보고를 검토 없이 그대로 올리지 않는다. 핵심 데이터를 직접 읽어서 검증한 뒤 보고한다. 이건 "AI가 그랬어요"를 막기 위한 내부 규율이다.
이 원칙들이 완벽하게 지켜진다고 말할 수는 없다. 하지만 이 원칙들이 있어야, 자동화 편향에 맞서는 도구를 만드는 우리 자신이 자동화 편향에 빠지지 않는다고 믿는다.
N/A를 어떻게 다뤄야 하는가 — 실용적 가이드
ViewCheck를 쓰다 보면, 많은 규칙이 N/A로 나오는 것을 경험하게 된다. 이걸 어떻게 다루면 좋은지를 좀 더 실용적으로 정리해보자.
N/A를 두 가지로 구분하는 습관을 기른다
규칙 설명을 읽어보면 이 N/A가 정당한지 아닌지 감이 온다. 예를 들어 "로그인 폼의 ID/PW 입력 필드 구조" 관련 규칙이 N/A라면, 그 페이지에 로그인 폼이 없어서인지(정당한 N/A), 아니면 로그인 폼이 있는데 인식을 못 한 것인지(분석 한계 N/A)를 확인해 볼 수 있다. 대부분은 개발자 도구로 페이지를 열어보면 금방 알 수 있다.
서비스 패턴(SP) N/A는 주의 깊게 본다
KRDS 846규칙 중 서비스 패턴(SP) 172개는 로그인·검색·신청·정책 같은 서비스 흐름을 다룬다. 이 규칙들이 N/A로 나오는 경우, 해당 서비스 페이지를 크롤링에서 놓쳤을 가능성이 있다. 예를 들어 로그인 페이지가 크롤링 대상에 포함됐는지를 확인하고, 필요하면 직접 해당 페이지 URL을 지정해 분석을 보완하는 방법이 있다.
N/A 항목을 보고서에 표시할 때 설명을 붙인다
보고서나 보고 자료에 N/A 항목을 포함할 때, "이 규칙은 분석 대상 페이지에 해당 컴포넌트가 없어 해당없음으로 처리됐으며, 해당 컴포넌트가 있는 페이지에 대해서는 별도 확인이 필요합니다"라는 식의 설명을 함께 붙이면 훨씬 정직한 보고가 된다. "N/A이니 괜찮다"는 인상을 주지 않는 것이 중요하다.
도구 선택의 기준 — ViewCheck와 함께 쓸 수 있는 것들
ViewCheck를 다른 도구와 배타적 관계로 볼 필요가 없다. 오히려 KRDS 규칙 판정이라는 ViewCheck의 강점과, 다른 도구들의 강점을 조합하면 더 나은 품질 관리가 가능하다.
axe-core와 병행: axe-core는 WCAG 기반 접근성을 광범위하게 커버하는 오픈소스 도구다. ViewCheck는 axe-core를 내부에서 활용하기도 하지만, 별도로 브라우저 확장이나 직접 실행을 통해 결과를 비교해 보는 것도 의미가 있다.
WAVE (WebAIM): 접근성 문제를 시각적으로 오버레이해서 보여주는 브라우저 확장이다. 특정 페이지에서 어떤 요소가 문제인지를 눈으로 확인하는 데 편리하다.
실제 보조기술 테스트: NVDA(Windows용 스크린 리더)나 VoiceOver(macOS/iOS)를 설치해, 주요 서비스 흐름을 직접 보조기술로 탐색해 보는 것이 가장 직접적인 검증 방법이다.
정기 사용자 테스트: 장애가 있는 실제 사용자와 함께 사이트를 사용하는 경험을 관찰하는 것은, 어떤 자동화 도구도 대체할 수 없는 가장 강력한 검증이다. 비용과 자원이 필요하지만, 공공 웹사이트의 의무를 생각하면 중장기적으로는 피할 수 없는 투자다.
이 도구들의 조합은 조직의 리소스와 우선순위에 따라 달라진다. ViewCheck는 이 생태계에서 "KRDS 846규칙 판정과 다중 페이지 자동 분석"이라는 역할을 맡는다. 그 역할 안에서 최대한 신뢰할 수 있는 결과를 내는 것이 우리 목표다.
담당자 유형별로 보는 신뢰의 선
ViewCheck를 쓰는 사람은 다 다르다. 개발자, 기획자, 행정 담당자, 품질 관리자 — 각자가 결과를 보는 눈과 쓰는 방식이 다를 수밖에 없다. 담당자 유형별로 신뢰의 선을 다르게 그어두면 실용적이다.
개발자 관점:
개발자는 DOM 기반 판정 결과를 비교적 직접 검증할 수 있는 위치에 있다. "이 aria-label이 없다고 나왔는데, 코드에서 확인해보자"는 즉각적인 확인이 가능하다. 개발자가 주의해야 할 영역은 오히려 Vision AI 기반 결과다. "이 컴포넌트가 표준이 아닌 방식으로 구현되어 있어서 도구가 잘못 감지했을 수 있다"는 판단을 개발자가 해줘야 할 수 있다.
기획자·UX 담당자 관점:
기획자는 "이 서비스 흐름이 KRDS 서비스 패턴에 맞나"를 판단하는 데 도움을 받을 수 있다. 하지만 UX 라이팅 결과나 사용자 경험 관련 항목은 특히 수동 판단이 많이 필요하다. "이 오류 메시지 텍스트가 충분히 안내적인가"는 사람이 봐야 하는 영역이다.
행정 담당자·보고서 작성자 관점:
행정 담당자가 가장 조심해야 할 함정은 숫자를 맥락 없이 쓰는 것이다. "68점"이라는 숫자를 보고서에 쓸 때, 그것이 846개 규칙 전체에서 나온 것인지, 판정된 N개 규칙에서 나온 것인지, 어떤 페이지를 기준으로 한 것인지를 함께 명시하면 훨씬 정직한 보고가 된다. 숫자만 쓰면 독자가 스스로 맥락을 채운다 — 대개는 "이 사이트는 68점이구나"라고. 그게 항상 맞는 해석이 아닐 수 있다.
품질 관리자·감사 담당자 관점:
품질 관리자는 AI 진단 결과를 공식 품질 점검의 참고 자료로 쓰되, 공식 점검을 대체하는 것으로 쓰면 안 된다는 것을 가장 분명히 인식해야 하는 위치에 있다. AI 진단은 빠른 사전 스크리닝이고, 공식 점검은 그 뒤에 오는 더 엄밀한 과정이다. 이 두 과정을 혼동하지 않는 것이 중요하다.
보고서를 쓸 때 고려해야 할 것들
ViewCheck 결과를 바탕으로 보고서나 개선 계획서를 작성할 때, 몇 가지 실용적인 제안을 드린다.
결과의 스코프를 명확히 한다
"어떤 URL을, 몇 페이지를, 언제 분석한 결과인가"를 명시한다. 같은 사이트도 메인만 분석했을 때와 50페이지를 분석했을 때 결과가 다를 수 있다. 스코프가 없는 결과 숫자는 맥락 없는 주장이 된다.
통과/미통과/해당없음의 차이를 설명한다
보고서 독자가 KRDS에 익숙하지 않을 수 있다. "846개 규칙 중 289개 통과, 228개 미통과, 329개 해당없음"이라는 수치 옆에, "해당없음은 해당 페이지에 관련 컴포넌트가 없거나 분석이 감지하지 못한 경우입니다. 이 중 일부는 추가 수동 확인이 필요할 수 있습니다"라는 설명이 있어야 한다.
AI 분석 기반임을 명시한다
"이 보고서는 ViewCheck AI 자동 분석 결과를 기반으로 합니다. 법적·공식 준수 여부는 전문가 검토 후 확인이 필요합니다"라는 면책 사항을 보고서 상단에 명시하는 것이 정직하고 안전하다.
개선 우선순위를 맥락 있게 제시한다
P0 항목부터 우선 개선하는 것이 일반적이지만, P0라도 실제 서비스에 미치는 영향이 다를 수 있다. 예를 들어 아주 드물게 방문되는 페이지의 P0와, 모든 사용자가 반드시 거치는 신청 폼의 P1 중 어느 것을 먼저 고쳐야 하는가는 맥락적 판단이다. 자동화 우선순위를 그대로 따르지 말고, 서비스 흐름과 사용 빈도를 고려한 우선순위 조정이 필요하다.
신뢰의 선은 고정되지 않는다
이 편의 제목은 "어디까지 믿어야 하나"다. 그 답을 지금까지 여러 각도에서 이야기했다. 그런데 사실 신뢰의 선은 고정된 선이 아니다.
도구가 발전하면 신뢰의 선이 이동한다. 오늘 "이건 수동 확인이 필요하다"고 하는 영역이, 내년에는 도구가 더 잘 커버하게 될 수 있다. N/A를 줄이는 연구, Vision AI의 정확도를 높이는 연구, 동적 상호작용을 포착하는 연구가 진전되면 신뢰의 선이 달라진다.
반대로, 도구가 처리하는 규칙 범위가 넓어질수록 예상치 못한 오판 영역이 생길 수도 있다. 새로운 KRDS 규칙이 추가되거나, 새로운 유형의 컴포넌트가 등장하면 — 도구는 한동안 그것을 잘 처리하지 못할 수 있다.
그래서 신뢰의 선은 "한 번 정하면 끝"이 아니라, 도구를 쓰면서 지속적으로 업데이트하는 것이다. Springer 리뷰(Romeo & Conti, 2025)가 말하듯, AI 리터러시(AI 문해력), 전문성, 인지적 프로파일, 신뢰의 발달적 역학이 자동화 편향에 영향을 미치는 복합적 요인들이다. 도구를 오래 쓰고, 결과를 자주 확인하고, 그 경험을 팀 안에서 공유하면 — 도구에 대한 신뢰가 점점 더 세밀하게 calibrate된다.
ViewCheck 팀도 이 경계를 계속 업데이트한다. 어떤 규칙에서 오탐이 잦은지, 어떤 유형의 페이지에서 N/A가 부당하게 많이 나오는지 — 이 데이터가 쌓일수록 우리도 더 정직한 신뢰의 선을 그을 수 있다. 그리고 그 선을 사용자에게 투명하게 보여주는 것이 우리의 의무라고 생각한다.
마무리 — 신뢰하되, 검증하라
지금까지의 이야기를 한 줄로 압축하면 이렇다. 신뢰하되, 검증하라(Trust, but verify).
ViewCheck가 내놓는 결과는 의미 있다. 846개 규칙을 수십, 수백 페이지에 걸쳐 빠르게 훑고, 근거와 함께 판정을 제시하는 것은 사람이 하기 어려운 일이다. 이 속도와 규모는 자동화만이 줄 수 있는 가치다.
그런데 그 결과가 모두 맞지는 않는다. DOM 기반 판정은 비교적 신뢰할 만하지만, Vision AI 기반 판정은 더 주의가 필요하다. N/A는 "이상 없음"이 아닐 수 있다. alt 품질 같은 '내용적 적절성'은 사람이 봐야 한다. 실제 보조기술 경험은 자동화가 대신하지 못한다. 공식 법적 준수는 전문가 검토가 필요하다.
이 신뢰의 선을 알고 쓰는 것과 모르고 쓰는 것 사이에는 큰 차이가 있다. 자동화 편향이라는 심리적 함정은 우리 모두에게 있다. 그걸 알고 의식적으로 거리를 두는 것이, AI 시대에 도구를 제대로 쓰는 핵심 역량이라고 우리는 생각한다.
ViewCheck는 담당자를 대체하는 도구가 아니다. 담당자가 물리적으로 할 수 없던 일(사이트 전체를 빠짐없이 빠르게 훑기)을 대신하고, 담당자가 판단할 수 있도록 근거를 정리해 건네는 도구다. 최종 판단과 책임은 여전히 사람에게 있다. 그 구도를 우리는 바꾸려 하지 않는다.
이 편이, ViewCheck를 이미 쓰고 있는 분께는 "이렇게 쓰면 더 잘 쓸 수 있다"는 힌트가 되고, 아직 도입 전인 분께는 "이 도구가 어떤 자세로 만들어지고 있는지"를 보여주는 글이 됐으면 한다. 다음 편에서 이어가겠다.
참고문헌
본문에 인용한 출처는 작성 시점에 모두 실재 여부를 WebSearch로 검증했다. 국내 공식 기준 자료와 해외 연구·기관 문서를 함께 실었다.
국내 — 공식 기준 / 정책자료
행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EC%A0%84%EC%9E%90%EC%A0%95%EB%B6%80%20%EC%9B%B9%EC%82%AC%EC%9D%B4%ED%8A%B8%20%ED%92%88%EC%A7%88%EA%B4%80%EB%A6%AC%20%EC%A7%80%EC%B9%A8
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 알림(고시 제2025-46호). 행정안전부 공식 발표. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
정보통신정책연구원(KISDI), 「Perspectives 초점 No.2: 한국 AI 정책 현황 및 발전 방안 — OECD AI 원칙을 중심으로」, September 2025. https://kisdi.re.kr/report/fileView.do?key=m2102058837181&arrMasterId=4334696&id=1875076
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
해외 — 연구·기관 문서
Romeo, G. & Conti, D., "Exploring automation bias in human–AI collaboration: a review and implications for explainable AI", AI & SOCIETY (Springer Nature), 2025. https://link.springer.com/article/10.1007/s00146-025-02422-7
Deque Systems, "Automated Testing Identifies 57% of Digital Accessibility Issues" (The Automated Accessibility Coverage Report), 2021. https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/
GOV.UK Design System, "A new accessibility strategy for the GOV.UK Design System", Accessibility in Government Blog (GDS), 2023. https://accessibility.blog.gov.uk/2023/01/06/a-new-accessibility-strategy-for-the-gov-uk-design-system/
European Data Protection Supervisor (EDPS), "TechDispatch #2/2025 — Human Oversight of Automated Decision-Making", 2025. https://www.edps.europa.eu/data-protection/our-work/publications/techdispatch/2025-09-23-techdispatch-22025-human-oversight-automated-making_en
Informa TechTarget, "What is Automation Bias? How to Avoid its Pitfalls". https://www.techtarget.com/searchitoperations/definition/What-is-automation-bias
IBM, "What is Explainable AI (XAI)?", IBM Think. https://www.ibm.com/think/topics/explainable-ai
Nielsen Norman Group, "Prioritize Smarts over Sentience to Increase Trust with AI". https://www.nngroup.com/articles/smarts-emotion-trust-ai/
Roselli, A., "Comparing Manual and Free Automated WCAG Reviews", adrianroselli.com, 2023. https://adrianroselli.com/2023/01/comparing-manual-and-free-automated-wcag-reviews.html
※ 본문의 GPT-4 환각률(29%), 법률 도메인 모델 환각률(17~33%) 수치는 Maxim AI의 「State of AI Hallucinations in 2025」 리포트 및 관련 학술 인용에 근거한 것이다(https://www.getmaxim.ai/articles/the-state-of-ai-hallucinations-in-2025-challenges-solutions-and-the-maxim-ai-advantage/). 이 수치는 방법론과 대상 모델에 따라 달라질 수 있으므로 정확한 수치보다 '환각이 상당한 비율로 존재한다'는 개념적 이해를 위한 참고로 쓰기를 권한다.
관련 글
ViewCheck LLM 분석 리포트 읽는 법 — 점수·등급·근거·우선순위 해석에서 행동까지
분석이 끝나고 화면에 숫자가 떴다. 종합 74점. KRDS 846규칙 중 289개 통과, 228개 미통과, 329개 해당없음. 접근성 68점. 보안 91점. 위반 매트릭스에는 빨간 칸과 노란 칸이 뒤섞여 있다. 그런데 막상 이 결과를 받아 든 담당자의 표정이 묘하다. 뭔가 많이 나왔는데, 무엇을 먼저 봐야 할지 모르겠다.
분석 → 개선 → 재진단, 공공웹 품질을 '점수로 관리'한다는 것 — ViewCheck LLM 분석 활용
공공 웹사이트 품질 진단을 맡은 실무 담당자들과 이야기하다 보면, 어느 지점에서 공통된 표정이 나온다. "진단은 했어요. 그런데 그다음은 어떻게 해야 하죠?" 도구를 돌리면 문제 목록이 나온다. 때로는 수백 개, 때로는 수십 페이지짜리 보고서가 나온다. 그리고 거기서 멈춘다. 문제를 고쳤는지 어떻게 확인하지? 개선 후에
임원 보고 5분 컷 — ViewCheck LLM 분석이 만들어 주는 것
공공기관 웹사이트 운영을 담당해 본 사람이라면, 이 장면을 알 것이다. 보고 전날 오후 5시. 팀장이 자리로 다가와 말한다. "내일 임원 보고에 우리 사이트 품질 현황도 넣어야 할 것 같은데, 오늘 중으로 한 장 만들어 줄 수 있어요?" 그 말 한 마디가 야근의 시작이다. 사이트 품질 현황이 어디 한 장에 딱 정리되어 있