목록으로
KRDS · 공공웹 AI 진단연구

사람 감사 vs AI 진단, 얼마나 일치하나 — ViewCheck가 씨름하는 평가자 간 신뢰도의 문제

AI 기반 분석 도구를 처음 접하는 사람이 가장 먼저 던지는 질문이 있다. 이 질문은 단순히 '기능 소개'가 아니라, 도구의 신뢰성에 대한 근본적인 물음이다. 공공 웹 담당자가 ViewCheck의 분석 결과를 가지고 상급자에게 보고하거나, 외주 개발사에 수정을 요청하거나, 심지어 예산을 편성하는 근거로 쓰려면 — "이 결

VViewCheck Insight
·2026.07.20 5분 80
사람 감사 vs AI 진단, 얼마나 일치하나 — ViewCheck가 씨름하는 평가자 간 신뢰도의 문제

전문가가 직접 점검한 결과와 AI가 자동 진단한 결과, 과연 얼마나 같고 얼마나 다른가


들어가며 — "그래서 이 AI 결과, 믿어도 됩니까?"

AI 기반 분석 도구를 처음 접하는 사람이 가장 먼저 던지는 질문이 있다.

"이게 사람이 직접 점검한 것과 얼마나 일치해요?"

이 질문은 단순히 '기능 소개'가 아니라, 도구의 신뢰성에 대한 근본적인 물음이다. 공공 웹 담당자가 ViewCheck의 분석 결과를 가지고 상급자에게 보고하거나, 외주 개발사에 수정을 요청하거나, 심지어 예산을 편성하는 근거로 쓰려면 — "이 결과가 얼마나 믿을 만한가"에 대한 납득 가능한 설명이 필요하다.

이번 편에서 우리는 그 질문을 정면으로 다루려 한다. 사람 전문가가 직접 점검한 결과와 AI 자동 진단 결과가 얼마나 일치하는지, 그것을 측정하는 방법은 무엇인지, 어디서는 잘 일치하고 어디서는 갈라지는지, 그리고 우리는 그 차이를 어떻게 해석하고 시스템 설계에 반영하는지.

솔직하게 미리 말해두겠다. 이 편의 결론은 "ViewCheck가 완벽하게 일치한다"가 아니다. 오히려 "어떤 영역은 꽤 잘 일치하고, 어떤 영역은 솔직히 어렵고, 그 차이를 아는 것 자체가 중요하다"에 가깝다. 그 이야기를 지금부터 차근차근 풀어보겠다.

협업 책상 위에서 사람 감사자와 노트북이 같은 웹페이지를 함께 평가하는 모습, 다큐멘터리 스타일 사진.
사람 전문가와 AI 도구가 같은 페이지를 나란히 점검하는 장면. 두 결과가 일치할 때, 그리고 갈라질 때 — 그 차이를 이해하는 것이 이번 편의 주제다.

'일치도'를 측정한다는 것 — 평가자 간 신뢰도 개념

먼저 개념부터 잡고 가자. "두 평가자의 결과가 얼마나 일치하는가"를 측정하는 것은, 사회과학·의학·심리학에서 오래전부터 연구해온 주제다. 이를 평가자 간 신뢰도(inter-rater reliability, IRR) 또는 평가자 간 일치도(inter-rater agreement) 라고 한다.

가장 널리 쓰이는 측정 지표 중 하나는 코헨의 카파(Cohen's kappa, κ) 다. 1960년 제이컵 코헨이 제안한 이 지표는, 두 평가자가 같은 항목을 분류할 때 "우연히 일치할 확률"을 보정한 뒤에도 실제로 얼마나 일치하는지를 계산한다. 값의 범위는 -1에서 1 사이이며, 0에 가까울수록 우연 수준의 일치, 1에 가까울수록 완벽한 일치를 의미한다. 일반적으로 받아들여지는 해석 기준은 다음과 같다.

κ 값 해석
≤ 0.00 일치 없음 (우연 이하)
0.01 ~ 0.20 매우 약한 일치
0.21 ~ 0.40 보통 일치
0.41 ~ 0.60 중등도 일치
0.61 ~ 0.80 상당한 일치
0.81 ~ 1.00 거의 완벽한 일치

예를 들어 두 전문 감사자가 동일한 웹페이지의 접근성 항목 100개를 각자 독립적으로 점검했을 때, 단순 일치율이 80%여도 그중 상당 부분이 우연에 의한 것이라면 코헨의 카파는 훨씬 낮게 나온다. 그래서 "몇 퍼센트 맞았다"는 단순 정확도보다 카파 값이 신뢰도의 더 정직한 지표로 여겨진다.

단, 코헨의 카파에도 한계가 있다. 특히 평가 결과가 극도로 불균형(예: 대부분 '통과', 소수만 '미통과')할 때, 실제 일치도가 높아도 카파 값이 낮게 나오는 이른바 '카파 역설(kappa paradox)'이 발생한다. 이 때문에 최근 연구에서는 카파 대신 Gwet's AC1 같은 보완 지표도 함께 보고하는 추세다. WCAG 자동화 도구 평가 같은 공공 웹 접근성 연구에서도 이런 점은 중요한 방법론적 고려 사항이 된다.

이 개념들이 ViewCheck와 무슨 관계가 있냐고? 우리가 자동화 도구를 만들 때 스스로에게 묻는 핵심 질문이 바로 이것이기 때문이다. "ViewCheck가 판정한 결과가, 사람 전문가가 같은 페이지를 직접 점검했을 때의 결과와 얼마나 일치하는가?" 그리고 그 일치도를 어떻게 측정하고 해석할 것인가.


자동화 도구끼리도 일치하지 않는다 — 충격적인 선행 연구

이 문제를 들여다보기 전에, 먼저 알아야 할 중요한 사실이 있다. 사람 감사자와 AI를 비교하기에 앞서 — 자동화 도구끼리도 서로 잘 일치하지 않는다는 연구 결과들이다.

2022년 10월, 국제학회 ACM SIGACCESS(컴퓨터 접근성 분야의 대표적 학술대회)에서 발표된 연구가 있다. Eryn Rachael Kelsey-Adkins와 Robert Haven Thompson이 수행한 이 연구는 명령줄 기반의 웹 접근성 평가 도구 4종 — axe-core/cli, IBM Equal Access NPM Accessibility Checker, Pa11y-ci, A11y Machine — 을 동일한 웹페이지에 적용하고 그 결과를 비교했다. 제목은 "Inter-rater Reliability of Command-Line Web Accessibility Evaluation Tools"(명령줄 웹 접근성 평가 도구의 평가자 간 신뢰도)였다(Kelsey-Adkins & Thompson, ACM ASSETS 2022).

결과가 충격적이었다. 초기 카파 값이 -0.05 로 나온 것이다. 사실상 우연에도 못 미치는 일치도였다. 네 가지 자동화 도구가 같은 페이지를 검사해도, 어떤 HTML 요소를 문제로 볼지도 다르고, 같은 요소에 어떤 등급을 부여할지도 달랐다. 연구자들은 "어떤 하나의 CLI 도구로도 WCAG 기준의 완전한 커버리지를 가정해서는 안 된다"고 결론지었다.

이 결과는 중요한 함의를 가진다. 우리가 ViewCheck의 결과를 "자동화 도구가 이렇게 나왔다"고 말할 때, 그 결과는 우리가 사용하는 엔진의 판단 기준, 규칙의 정의 방식, 판정 임계값에 따라 크게 달라진다는 것이다. 다른 자동화 도구를 쓰면 다른 결과가 나올 수 있다. 이건 ViewCheck가 특별히 나쁜 게 아니라, 현재 자동화 접근성 도구 전반의 현실이다.

두 장의 평가 점수표를 조심스러운 손으로 나란히 맞추고 비교하는 모습, 자연광 다큐멘터리 스타일.
두 평가 결과를 나란히 대조하는 장면. 자동화 도구끼리도, 사람 감사자끼리도 결과가 항상 같지 않다.

더 나아가 이 문제는 ViewCheck만의 고민이 아니다. 같은 WCAG 기준을 쓰더라도, 접근성 전문가 두 명이 독립적으로 같은 페이지를 감사하면 결과가 갈리는 경우가 적지 않다. 무엇을 '적절한 대체 텍스트'로 볼 것인지, 어느 정도의 색상 대비가 '충분한지', 버튼의 라벨이 '의미 있는지' — 이런 판단에는 전문가마다 차이가 생긴다. 카파로 표현하면, 경험 있는 접근성 전문가들 사이에서도 WCAG 항목에 따라 일치도가 크게 달라진다.

이것이 이번 편 전체의 출발점이다. "사람 감사 vs AI 진단, 얼마나 일치하나"를 논하려면, 사람 감사 자체도 완벽히 일관된 기준이 아니라는 사실을 먼저 인정해야 한다.


WCAG 자동화의 근본적 한계 — 커버리지 20~57%

자동화 접근성 도구의 일치도 문제를 이야기할 때 빠질 수 없는 숫자가 있다. 자동화 도구는 WCAG 전체 문제의 일부만 잡아낸다는 것이다.

Deque(덱, axe-core의 제작사)는 13,000개 이상의 페이지/상태를 분석하고 약 30만 건에 달하는 접근성 문제를 조사한 대규모 연구를 발표했다. 그 결과에 따르면, 자동화 테스트만으로는 실제 접근성 문제의 57.38% 를 발견할 수 있었다(Deque, "Automated Testing Study Identifies 57% of Digital Accessibility Issues", 2021). 언뜻 보면 꽤 높아 보이지만, 이건 발생 빈도가 높은 '자주 틀리는 유형의 문제'가 자동화 도구로 잡히는 비율이 높기 때문이다.

측정 방식을 바꿔서 WCAG 성공 기준 단위로 커버리지를 보면 숫자는 달라진다. Deque는 WCAG 2.1 AA 기준 50개 성공 기준 중 16개에 대해서만 자동화 이슈를 발견할 수 있었다고 밝혔다. 이는 성공 기준 기준으로는 약 32% 커버리지 수준이다. 다른 연구기관들(WebAIM, Level Access, TPGi 등)이 10년 이상 내놓은 업계 콘센서스도 "자동화 도구만으로는 WCAG 문제의 20~30% 수준만 커버된다"는 선에서 크게 벗어나지 않는다(Level Access, "Automated Accessibility Testing: A Practical Guide to WCAG Coverage").

이 수치가 의미하는 것은 명확하다. 자동화 도구가 "통과"라고 해도, 그건 전체 WCAG 기준의 3분의 2 이상을 아직 보지 않은 상태일 수 있다는 것이다. 그리고 바로 그 '자동화로는 못 보는 영역'에 사람 감사자의 존재 이유가 있다.

ViewCheck 역시 이 한계에서 자유롭지 않다. KRDS 846규칙 중 자동화로 명확히 판정 가능한 것이 있는 반면, DOM을 아무리 들여다봐도 판정할 수 없는 영역이 존재한다. 색상 대비 수치 같은 것은 CSS 값에서 계산할 수 있지만, "이 이미지의 대체 텍스트가 맥락상 적절한가"는 코드만으로는 판단할 수 없는 의미론적 판단이다. 그래서 ViewCheck의 분석 결과 중 일부 항목은 "해당없음(N/A)" 또는 "AI 판정 필요"로 남겨진다. 그 솔직함 자체가, 커버할 수 없는 영역을 커버한 것처럼 보이게 하지 않으려는 선택이다.


사람 전문가도 서로 다르다 — 전문가 간 불일치의 현실

"그렇다면 사람 전문가가 점검하면 완벽하게 정확한가?"라는 질문으로 넘어가 보자. 결론부터 말하면, 전문가도 서로 다르다.

웹 접근성 감사 분야에서 두 명의 숙련된 전문가가 독립적으로 같은 사이트를 점검했을 때, 결과가 100% 일치하는 경우는 드물다. 왜 그럴까? WCAG 성공 기준 자체가 일정 수준의 해석을 요구하기 때문이다. 예를 들어 WCAG 1.1.1(비텍스트 콘텐츠)은 "대체 텍스트를 제공하라"고 명시하지만, '어떤 대체 텍스트가 충분히 의미 있는가'는 전문가의 판단이 개입된다. 1.4.3(색상 대비)은 수치 기준이 있어 비교적 객관적이지만, 복잡한 그라데이션 배경이나 중첩 레이어에서는 전문가마다 측정 방식이 달라질 수 있다.

의료 분야의 유사 연구를 보면 이 문제의 규모를 짐작할 수 있다. 최근 PMC에 게재된 연구는 ChatGPT-4o가 의학 무작위대조시험(RCT)의 비뚤림 위험(risk of bias)을 평가하는 능력을, 인간 전문가들의 평가와 코헨의 카파로 비교했다(PMC, "Using a Large Language Model (ChatGPT-4o) to Assess the Risk of Bias in Randomized Controlled Trials of Medical Interventions: Interrater Agreement With Human Reviewers", 2025). 흥미로운 점은, 이 연구에서 인간 전문가들끼리의 일치도(human-human agreement)가 이미 16%에서 81% 로 넓은 범위를 가진다는 사실을 인용하고 있다는 것이다. 즉, 같은 논문을 같은 기준으로 평가하는 인간 전문가들도 절반 이상은 서로 다른 판정을 내릴 수 있다는 뜻이다.

이 현실은 웹 접근성 감사에도 그대로 적용된다. 전문가 A가 "이 링크 텍스트는 불충분하다"고 판단하고, 전문가 B가 "맥락상 충분하다"고 판단하는 일은 실제로 발생한다. 두 전문가가 다 틀린 게 아니다. 기준이 해석의 여지를 허용하기 때문이다.

그렇다면 AI 자동화 도구는 이 상황에서 어디에 서 있을까? 완벽한 일치도를 기대하는 것은 비현실적이다. 그보다는 "어떤 영역에서, 어느 수준으로, 어떤 조건에서 일치하는가"를 파악하는 게 더 유용한 질문이다.


LLM을 판정에 쓸 때의 일치도 연구들

최근 2~3년 사이에 LLM(대형 언어 모델)을 평가자(judge)로 활용할 때의 인간-AI 일치도를 측정하는 연구가 폭발적으로 늘었다. 우리가 ViewCheck의 LLM 활용 방식을 설계할 때 참고한 연구들을 몇 가지 소개한다.

LLM-as-Judge의 일치도: 평가 척도가 중요하다

Harvard·CMU·Stanford·UC San Diego 연구자들이 2026년 발표한 연구(arXiv 2601.03444)는 LLM 판정의 인간-AI 일치도가 평가 척도에 따라 크게 달라진다는 것을 보여줬다. 6개 벤치마크, 6개 LLM, 12명의 대학원생 평가자를 동원해 분석한 결과, 0~5점 척도에서 인간-LLM 일치도가 가장 높게 나타났다(Weiyue Li et al., "Grading Scale Impact on LLM-as-a-Judge: Human-LLM Alignment Is Highest on 0-5 Grading Scale", arXiv 2601.03444, 2026). 연구자들은 ICC(급내 상관 계수)를 사용해 절대적 일치도를 측정했는데, 척도의 선택이 일치도를 "실질적으로 이동"시킨다는 것을 발견했다.

이 연구가 ViewCheck에 주는 시사점이 있다. ViewCheck의 판정 결과를 단순한 이진 분류(통과/미통과)로만 볼 것인지, 아니면 confidence 점수나 위험 등급을 함께 제시할 것인지가 인간-AI 일치도에 영향을 미친다. 이진 판정은 해석의 여지가 없어 측정은 쉽지만, 정보 손실이 크다. 등급화된 판정은 더 많은 정보를 담지만 척도 설계가 일치도에 크게 영향을 준다.

LLM을 접근성 평가에 직접 적용한 연구

Springer Nature의 Universal Access in the Information Society에 2024년 게재된 연구는 직접적으로 관련이 높다. 스페인 바스크 지방 대학교(University of the Basque Country) 연구팀이 수행한 이 연구는 LLM 기반 접근법으로 WCAG 성공 기준 중 현재 수동 점검이 필요한 3개 항목 — 1.1.1(비텍스트 콘텐츠), 2.4.4(링크 목적), 3.1.2(부분적 언어) — 을 자동화할 수 있는지를 실험했다. 4개 LLM과 39개 테스트 케이스로 구성된 벤치마크를 사용한 이 연구는 "현재 수동 점검이 필요한 영역에 LLM이 어느 정도 기여할 수 있는지"를 탐색했다("Turning manual web accessibility success criteria into automatic: an LLM-based approach", Springer Nature, 2024).

이 연구는 LLM이 완벽한 대안이 아님을 인정하면서도, 기존 자동화 도구가 못 하던 영역에서 LLM이 부분적 기여를 할 수 있는 가능성을 보여줬다. 특히 링크 목적이나 대체 텍스트의 '의미 있음' 판단처럼, 맥락적 이해가 필요한 항목에서 LLM이 rule-based 도구보다 더 나은 성과를 낼 수 있다는 점이 주목할 만하다.


ViewCheck가 일치도를 어떻게 다루는가 — 3계층 설계

이제 이 모든 논의를 ViewCheck의 설계로 연결해 보자. 우리는 사람-AI 일치도 문제를 크게 세 가지 계층으로 나누어 접근한다.

계층 1: DOM 기반 자동 판정 — 일치도가 가장 높은 영역

색상 대비 수치, 이미지에 alt 속성이 있는지, 폼에 label이 연결되어 있는지, ARIA role이 적절히 지정되어 있는지 — 이런 항목들은 DOM을 코드로 분석하면 명확한 수치나 조건으로 판정할 수 있다. "색상 대비가 4.5:1 이상인가"는 CSS 값에서 계산하면 사람이나 코드나 동일한 결과를 낸다. 기준이 수치로 명확하기 때문이다.

ViewCheck의 KRDSrule 엔진이 담당하는 영역이 바로 이 계층이다. KRDS 846규칙 중 DOM 구조와 CSS 값으로 판정 가능한 것들을 if/else 로직으로 빠르고 일관되게 처리한다. 동일한 페이지에 같은 로직을 돌리면 항상 같은 결과가 나온다 — 즉, '재현성(reproducibility)'이 100%다. 전문가 두 명이 손으로 점검하면 판정이 갈릴 수 있는 항목도, DOM 기반 자동화는 기준이 명확하면 항상 같은 답을 낸다. 이 영역에서 자동화의 일관성은 사람보다 오히려 높다.

다만 '일관성'이 곧 '정확성'을 보장하지는 않는다. 규칙이 잘못 정의되어 있거나, 예외 케이스를 처리 못 하는 로직이 있다면, 일관되게 틀릴 수도 있다. 그래서 우리는 주기적으로 실제 사이트 분석 결과를 검토하며 규칙 로직이 의도대로 동작하는지 확인한다.

계층 2: 맥락 의존 판정 — 일치도가 가장 어려운 영역

"이 이미지의 대체 텍스트가 충분히 의미 있는가", "이 링크 텍스트가 맥락상 명확한가", "이 UI 컴포넌트의 역할이 시각적으로 명확한가" — 이런 항목은 맥락과 의미 해석이 필요하다. DOM 코드만 봐서는 판단할 수 없고, 사람이 화면을 보고 내용을 읽어야만 판정할 수 있다.

이 영역이 사람-AI 일치도가 가장 낮게 나오는 곳이기도 하다. 그리고 솔직히, 사람-사람 일치도도 그리 높지 않다. ViewCheck는 이 영역을 KRDScan 엔진의 Vision AI와 LLM 판정으로 보완하려 시도하지만, 아직 연구 중인 부분이 많다. 현재는 이 영역의 많은 항목이 "AI 판정 필요(PENDING_AI)" 또는 "해당없음(N/A)"으로 남겨져 있다. 이를 숨기거나 억지로 채우는 것보다, "아직 자동화로는 판정하기 어렵다"는 사실을 투명하게 드러내는 편이 맞다는 판단에서다.

계층 3: 시각적·런타임 판정 — 도구 간 일치도가 가장 낮은 영역

스크린샷을 봐야만 알 수 있는 디자인 일관성, 사용자가 버튼을 눌러봐야 나타나는 오류 메시지의 적절성, 실제 화면 낭독기(스크린 리더)를 돌려봐야 확인되는 접근성 이슈 — 이 영역은 현재 어떤 자동화 도구도 완전히 다루지 못하는 영역이다.

ViewCheck는 KRDScan 엔진의 Vision AI로 스크린샷 기반 분석을 시도하고, Playwright로 실제 브라우저에서 페이지를 렌더링해 가능한 한 많은 신호를 수집하지만, 이 영역의 커버리지는 제한적이다. 앞서 소개한 Deque의 연구처럼, 자동화+AI 조합으로도 전체 문제의 80% 선에 도달하는 것이 현재 기술의 천장(ceiling)에 가깝고, 나머지 20%는 결국 사람의 눈과 손이 필요하다.


증적 화면으로 보는 일치도의 현실

실제 분석 결과를 보면서 이야기를 이어가자.

ViewCheck LLM 분석 대시보드 실제 캡처 화면. KRDS 846규칙 분석 결과가 DS/CP/BP/SP 카테고리별로 통과·미통과·해당없음으로 구분되어 표시되어 있다.
ViewCheck LLM 분석의 실제 대시보드 화면. 통과/미통과/해당없음 세 가지 판정이 카테고리별로 나뉘어 표시된다. "해당없음"으로 표기된 항목이 자동화의 한계를 솔직하게 보여주는 영역이다. — 실제 분석 화면

이 화면에서 주목할 것이 있다. 카테고리마다 "해당없음(N/A)" 비율이 다르다는 점이다. DS(디자인 스타일)와 SP(서비스 패턴)는 판정 가능한 항목 비율이 높은 반면, CP(컴포넌트)는 해당없음이 많다. 왜일까?

CP는 특정 컴포넌트(예: 모달, 탭, 아코디언)가 그 페이지에 존재해야만 판정할 수 있는 규칙이 많다. 메인 페이지에 모달이 없다면, 모달 관련 규칙은 정당하게 N/A가 된다. 반면 DS는 색상·타이포·간격처럼 모든 페이지에 공통으로 적용되는 요소들이라 판정 가능한 비율이 높다.

이게 '일치도' 이야기와 어떻게 연결되냐면 — 사람 전문가가 같은 페이지를 점검할 때도, 어떤 컴포넌트가 존재하는지에 따라 적용 가능한 항목이 달라진다. 자동화 도구와 사람 전문가가 "이 규칙은 해당없음"이라는 같은 판정을 내렸을 때, 그건 '일치'로 봐야 할까 아닐까? 이런 판단 자체도 연구에서 다뤄야 할 복잡한 문제다.

우리가 화면에서 '해당없음'을 명시적으로 분리해서 보여주는 이유가 여기에 있다. 통과와 미통과만 보여주면, 판정하지 않은 항목이 마치 통과한 것처럼 보일 수 있다. 전체 846개 규칙 중 몇 개는 판정했고, 몇 개는 해당없음으로 빠졌고, 몇 개는 아직 AI 판정을 기다리는지 — 이 전체를 투명하게 보여주는 것이 우리가 생각하는 솔직한 진단이다.


어디서 잘 일치하고 어디서 갈리는가 — 영역별 분석

지금까지의 논의를 바탕으로, 사람 감사 vs AI 진단의 일치도를 영역별로 정리해 보자.

현대적인 사무실에서 대형 모니터에 표시된 색상 비교 차트를 검토하는 연구자의 모습.
비교 분석 차트를 들여다보는 연구자. 어떤 영역이 일치하고 어떤 영역이 갈리는지를 파악하는 일 자체가 하나의 연구 과제다.

잘 일치하는 영역:

  • 구조적 요소의 존재 여부: 이미지에 alt 속성이 있는가, input에 label이 연결되어 있는가, 헤딩 구조가 H1→H2→H3 순서를 지키는가. 이런 항목은 코드로 보나 사람이 보나 답이 같다. 기준이 수치나 존재 여부로 명확하기 때문이다.

  • 색상 대비 수치 계산: WCAG에서 정하는 색상 대비 비율(일반 텍스트 4.5:1, 큰 텍스트 3:1)은 수학적으로 계산되므로, 자동화 도구와 사람이 같은 픽셀 값을 보면 같은 결론이 나온다. 다만 그라데이션 배경이나 이미지 위 텍스트처럼 복잡한 경우는 측정 방식에 따라 차이가 생긴다.

  • 명백한 코드 오류: 폼에 submit 버튼이 없는 경우, ARIA role 값이 유효하지 않은 경우, 페이지에 H1이 여러 개인 경우처럼 구조적으로 잘못된 것들. 사람이 코드를 봐도, 자동화가 코드를 봐도 "이건 아니다"는 결론이 같다.

갈리는 영역:

  • 대체 텍스트의 '충분함': 이미지에 alt 속성이 있는지는 자동화로 잡을 수 있지만, 그 내용이 충분히 의미 있는지는 맥락 이해가 필요하다. "img.jpg"라는 파일명을 그대로 쓴 alt는 누가 봐도 불충분하지만, "정부청사 전경"이 실제 이미지를 잘 설명하는지는 사람이 이미지를 봐야 판단된다. 전문가끼리도 의견이 갈릴 수 있는 영역이다.

  • 키보드 내비게이션: 페이지를 Tab 키로 순서대로 이동할 때 흐름이 논리적인지는, 실제로 키보드만으로 페이지를 써봐야 느낄 수 있다. 코드상에는 tabindex 속성이 있어도, 사용자가 경험하는 실제 흐름은 런타임에서만 알 수 있다. 자동화가 잡기 어려운 대표적인 영역이다.

  • 언어 이해가 필요한 판단: 오류 메시지가 사용자에게 충분히 명확한 안내를 주는지, 버튼 라벨이 행동을 명확히 설명하는지, 페이지 제목이 내용을 잘 요약하는지 — 이런 '의미론적' 판단은 LLM이 최근 가장 큰 가능성을 보이는 영역이기도 하지만, 동시에 할루시네이션의 위험도 가장 큰 영역이다.

  • 시각적 디자인 일관성: 같은 역할을 하는 UI 요소가 페이지마다 일관된 색상·크기·위치로 표현되는지 — 이건 코드가 아니라 화면을 눈으로 여러 페이지를 비교해봐야 알 수 있다. ViewCheck가 다중 페이지 분석을 기본값으로 채택한 이유 중 하나다.


LLM 판정의 함정 — 자신감과 오류가 함께 온다

LLM을 판정에 활용할 때 특히 주의해야 할 점이 있다. LLM은 틀릴 때도 자신 있게 말한다는 것이다.

연구들이 보고하는 LLM 할루시네이션 비율은 충격적이다. GPT-3.5는 참고문헌의 39.6%를 지어냈고, Bard는 의학 체계적 문헌 고찰에서 91.4%의 참고문헌을 잘못 제시했으며, GPT-4도 28.6%의 할루시네이션이 보고됐다는 연구 결과들이 있다. 모델이 발전하면서 이 비율은 낮아지고 있지만, 완전히 사라진 것은 아니다.

접근성 평가 맥락에서 이 문제는 특히 민감하다. LLM이 "이 이미지의 대체 텍스트는 충분히 의미 있다"고 자신 있게 말했는데, 실제로는 그냥 파일명을 반복한 것에 불과했다면? 또는 "이 폼은 WCAG 1.3.1을 준수한다"고 판정했는데, 실제로는 필수 label 연결이 빠져 있었다면? 이런 오류는 단순히 점수를 잘못 계산하는 것보다 훨씬 해롭다. 사용자가 그 판정을 신뢰하고 "통과"로 결론 내릴 수 있기 때문이다.

그래서 ViewCheck는 LLM에 접근성 판정을 전적으로 맡기지 않는다. DOM 기반 if/else 로직이 명확히 판정할 수 있는 항목은 LLM을 개입시키지 않는다. LLM은 DOM이 "알 수 없음"이라고 남겨둔 영역에서만 보조적으로 쓰인다. 그리고 LLM이 판정한 항목에는 RAG(검색 증강 생성)를 통해 근거 문서를 함께 제시하도록 설계했다. "LLM이 그렇게 판단했다"는 것만으로는 부족하고, "KRDS 어떤 항목, 어떤 공식 문서의 어떤 내용에 근거했다"는 추적 가능한 근거가 있어야 한다.

이 설계를 한마디로 표현하면: AI를 믿지 않고, 근거를 요구한다.


하이브리드 접근 — 자동화 + 사람이 더 나은 이유

선행 연구들이 공통적으로 제안하는 답이 있다. 자동화 단독도 아니고, 사람 단독도 아니고 — 두 가지의 조합이 가장 효과적이라는 것이다.

Deque의 연구에서 자동화 단독으로는 전체 접근성 문제의 57%를 잡았지만, 자동화에 '지능형 가이드 테스트(Intelligent Guided Testing, IGT)'를 더했을 때 커버리지가 80% 로 올랐다. 나머지 20%는 사람이 화면 낭독기나 키보드로 직접 테스트해야 한다. 이 마지막 20%가 포함하는 영역들 — 키보드 내비게이션의 논리적 흐름, 스크린 리더와의 실제 호환성, 인지 접근성 판단 — 은 현재 기술 수준에서 어떤 자동화 도구도 완전히 대체하지 못한다.

감사자들과 노트북이 같은 웹사이트를 함께 검토하는 소규모 워크숍 장면.
감사자들과 노트북이 함께 같은 사이트를 검토하는 워크숍. 자동화와 사람의 협력이 각자보다 더 넓은 커버리지를 만든다.

ViewCheck가 그리는 이상적인 활용 흐름은 이렇다.

  1. ViewCheck 자동화로 1차 스크리닝: 846규칙 중 자동화로 판정 가능한 항목을 빠르게 훑는다. 명확한 코드 오류, 수치 기반 기준 미충족, 구조적 문제들이 이 단계에서 잡힌다. 수십~수백 페이지를 사람이 처음부터 훑는 대신, "여기부터 보면 된다"는 지도를 그려주는 것이다.

  2. 사람 전문가의 2차 심층 점검: 자동화가 "판정 어렵다"거나 "N/A"로 남긴 항목, 높은 심각도로 표시된 미통과 항목을 사람이 직접 확인한다. 실제 화면을 보고, 스크린 리더를 돌려보고, 키보드로 조작해본다. 이 단계는 자동화로 줄인 범위 안에서 집중적으로 이루어진다.

  3. 근거 기반 수정 요청: ViewCheck가 제공하는 RAG 근거와 KRDS 규칙 원문을 개발자에게 그대로 전달한다. "뭔가 이상한 것 같다"가 아니라 "KRDS BP-003 규칙의 이 조건이 충족되지 않았고, 해당 기준은 공식 문서의 여기에 나와 있다"는 구체적이고 추적 가능한 요청이 가능해진다.

이 흐름에서 중요한 것은 ViewCheck가 사람을 대체하는 게 아니라는 점이다. 사람이 해야 하는 일의 범위를 '줄여주고' 방향을 잡아주는 역할이다. 자동화가 할 수 있는 것은 자동화가 하고, 사람의 판단이 필요한 것은 사람에게 남긴다.


"사람 감사도 틀린다"는 사실이 주는 불편한 진실

이제 좀 더 불편한 이야기를 해보자. 사람 전문가의 감사 결과가 항상 정답이고, AI 진단이 그것을 따라가야 한다는 가정 — 이것 자체가 흔들릴 수 있다.

앞서 의료 분야 연구에서 인용했듯, 인간 전문가들끼리의 일치도가 이미 16~81%라는 넓은 범위를 가진다. 이는 웹 접근성 분야에서도 다르지 않다. 특히 WCAG 기준의 해석에 대해 전문가 커뮤니티 내에서 의견이 갈리는 경우가 있다. 예를 들어 특정 동적 콘텐츠에 ARIA live region을 써야 하는지, 그렇다면 어떤 live region type이 적절한지 — 이런 세부 사항에서는 경험 많은 전문가들도 다른 답을 내놓을 수 있다.

이 사실이 중요한 이유가 있다. 어떤 상황에서는 AI 자동화 판정이 더 일관성이 높을 수 있다는 것이다. 같은 코드 조건에 대해 항상 같은 판정을 내리기 때문이다. 전문가 A가 월요일에 점검할 때와 금요일에 점검할 때 다른 결론을 내리는 일은 없다. 또, 다양한 규칙을 100여 페이지에 걸쳐 기억하며 일관되게 적용하는 것도 사람에게는 인지적으로 부담스럽지만 자동화에게는 그렇지 않다.

물론 이게 "자동화가 사람보다 낫다"는 말이 아니다. 자동화는 틀린 규칙을 일관되게 적용할 수도 있다. 잘못 정의된 규칙이 있으면, 수백 페이지에 걸쳐 같은 방식으로 틀린다. 사람은 "어, 이건 좀 이상한데?"라고 직관적으로 문제를 잡아낼 수 있지만, 자동화는 그럴 수 없다.

결론적으로 "사람 vs AI"는 대립 구도가 아니다. 각자가 잘하는 것과 못하는 것이 다르고, 그 상보적인 관계를 이해하는 것이 진짜 일치도 연구의 핵심이다.


우리가 아직 못 하는 것들 — 솔직한 현황

이 시리즈가 R&D 노트인 만큼, 우리가 아직 풀지 못한 문제들도 솔직하게 적어야겠다.

1. 체계적인 사람-AI 일치도 측정 연구를 아직 못 했다.

ViewCheck의 자동화 결과와 사람 전문가의 수동 점검 결과를 체계적으로 비교하는 연구를 우리는 아직 수행하지 못했다. 코헨의 카파 값이 얼마나 나오는지, 어떤 카테고리에서 가장 많이 갈리는지 — 이것을 측정하기 위해서는 전문가 패널을 꾸리고, 동일한 사이트 셋을 독립적으로 점검하는 비교 연구가 필요하다. 이건 우리의 진짜 과제 목록에 있지만, 아직 실행되지 않았다.

2. N/A 비율을 더 낮춰야 한다.

현재 분석 결과에서 CP 카테고리의 N/A 비율이 높은 것은, 많은 컴포넌트 규칙이 해당 컴포넌트가 페이지에 없으면 판정 자체를 하지 않기 때문이다. 이 중 일부는 정당한 N/A지만, 다른 페이지에는 그 컴포넌트가 있는데도 불구하고 "이 페이지에 없으니 N/A"로 처리되는 경우도 있다. 다중 페이지 분석의 장점이 바로 여기에 있다 — 100개 페이지를 보면, 모달이 없는 메인에서 N/A였던 규칙이 마이페이지 화면에서는 판정 가능해진다.

3. LLM 판정 영역의 근거 추적을 더 강화해야 한다.

현재 LLM이 판정에 개입하는 영역에서는 RAG를 통해 근거를 제시하도록 설계했지만, 모든 판정에 대해 사람이 검증할 수 있는 형태의 추적 기록이 충분히 갖춰져 있지는 않다. "어떤 문서의 어떤 내용이 이 판정에 영향을 줬는가"를 더 투명하게 드러내는 작업이 필요하다.

4. 사이트 유형별 일치도 차이를 모른다.

중앙부처 메인 사이트, 기초자치단체 홈페이지, 공공기관 서비스 포털 — 각 유형의 사이트에서 일치도가 어떻게 달라지는지 아직 체계적으로 분석하지 못했다. 직관적으로는 사이트의 복잡도, 컴포넌트 다양성, 동적 기능 수준에 따라 일치도 패턴이 다를 것이라 예상하지만, 이건 실측이 필요하다.


신뢰도를 높이기 위한 ViewCheck의 현재 접근법

이런 한계들을 인정하면서도, 지금 당장 우리가 일치도를 높이기 위해 하고 있는 것들을 정리해 보자.

규칙 로직의 지속적 검증: 실제 사이트 분석 결과를 정기적으로 검토하며, "이 판정이 사람이 보기에도 맞는가"를 확인한다. 규칙 로직에 오류가 발견되면 수정하고, 예외 케이스를 추가한다. 이건 한 번으로 끝나는 작업이 아니라 계속 이어지는 과정이다.

DOM 기반 판정의 우선순위 원칙: DOM이 명확히 통과/미통과로 판정한 항목은 AI가 뒤집지 않는다. AI는 DOM이 "모르겠다"고 한 영역만 채운다. 이 원칙이 흔들리면 결과의 일관성이 무너진다. 판정 주체 간의 충돌을 방지하는 가장 중요한 설계 결정이다.

근거의 추적 가능성: 모든 판정 결과 옆에 해당 규칙의 공식 원문 링크와 설명이 제공된다. 사용자가 "이게 맞나?" 의심할 때, 판정 근거를 직접 확인할 수 있어야 한다. 블랙박스가 되는 순간 신뢰를 잃는다.

'모른다'는 판정의 명시: 판정이 어려운 항목을 억지로 통과나 미통과로 분류하지 않고, "해당없음"이나 "AI 판정 필요"로 남기는 것. 숫자를 그럴듯하게 만들기 위해 모르는 항목을 임의로 채우는 건, 일치도를 높이는 게 아니라 거짓 일치도를 만드는 일이다.


일치도 연구의 현재와 미래 — 해외에서는 어떻게 하나

해외의 연구·실무 흐름을 보면, 자동화 도구와 사람 감사의 일치도를 체계적으로 측정하고 공개하려는 움직임이 늘고 있다.

GOV.UK Design System을 운영하는 영국 GDS는, 정부 서비스의 접근성 감사에 자동화 도구와 수동 점검을 어떻게 조합하는지에 대한 가이드를 공개하고 있다. 각 컴포넌트와 패턴에 대해 "자동화로 테스트 가능한 항목"과 "수동 점검이 필요한 항목"을 구분해 명시함으로써, 개발자가 자동화 결과를 과신하지 않도록 돕는다(GOV.UK Design System, design-system.service.gov.uk).

미국 USWDS(U.S. Web Design System)도 접근성 테스트 가이드에서 유사한 접근법을 취한다. 자동화 도구가 잡아낼 수 있는 것과 없는 것을 명시하고, "자동화는 시작점이지 결론이 아니다"라는 메시지를 일관되게 전한다.

이런 해외 사례들이 주는 공통 메시지는 명확하다. 자동화 도구의 결과를 오픈하고, 한계를 명시하고, 사람의 점검과 조합하라. 이것이 현재 접근성 감사 실무와 연구의 콘센서스다.

ViewCheck가 지향하는 방향도 같다. 결과를 투명하게 열고, 무엇이 자동화로 판정됐고 무엇이 AI의 추정인지 구분하고, 사람의 최종 판단을 지원하는 도구로 위치하는 것.


'N/A를 줄이는 것'과 '일치도를 높이는 것'은 같은 문제다

이 편 전체를 통해 짚은 내용들을 한 줄로 연결하면 이렇다.

자동화 도구의 일치도를 높인다는 것은, 결국 지금 "해당없음"이나 "모르겠음"으로 남겨진 영역들을 더 정확하게 판정할 수 있게 된다는 뜻이다. 그리고 그 판정의 정확성은, 사람 전문가가 같은 항목에 대해 내리는 판정과 얼마나 일치하는가로 측정된다.

따라서 N/A 비율을 낮추는 연구와, 일치도를 높이는 연구는 사실 같은 방향을 보고 있다. ViewCheck가 지금 집중하는 두 방향 — 다중 페이지 분석으로 컴포넌트 커버리지를 높이는 것, 그리고 Vision AI와 LLM으로 DOM이 못 보는 시각적·의미론적 영역을 채우는 것 — 이 모두 궁극적으로는 "사람 전문가가 보는 것과 더 일치하는 결과를 내는 것"을 목표로 한다.

그리고 이 목표는 도달점이라기보다 방향에 가깝다. 100% 일치라는 도달점은 없다. 사람 전문가들끼리도 100%는 없기 때문이다. 다만 계속 더 가까워지는 것, 그리고 얼마나 일치하고 얼마나 다른지를 투명하게 알리는 것 — 이것이 우리가 이 주제를 연구하는 이유다.


공공 웹 맥락에서의 특수성 — 기준이 곧 법이다

공공 웹 접근성 감사의 일치도 문제는, 민간 서비스의 그것과 한 가지 중요한 점에서 다르다. 기준이 법적·행정적 구속력을 갖는다는 것이다.

한국에서 「장애인차별금지 및 권리구제 등에 관한 법률」(장애인차별금지법)과 「국가정보화 기본법」에 의거해, 공공기관의 웹사이트는 KWCAG(한국형 웹 콘텐츠 접근성 지침)를 준수해야 한다. 이 기준에 미달하면 법적 문제가 될 수 있다. 동시에 행안부의 「전자정부 웹사이트 품질관리 지침」(고시 제2025-46호, 2025. 6. 25. 시행)도 공공기관이 따라야 하는 기준이다(행정안전부).

이런 맥락에서 "AI 도구가 통과라고 했다"는 것이 곧 법적 준수의 근거가 될 수 없다는 점은 명확하다. ViewCheck의 분석 결과는 점검의 출발점이자 보조 도구이지, 최종 판정자가 아니다. 공식적인 준수 여부 확인은 여전히 전문가의 수동 점검과 인증 기관의 심사가 필요하다.

이 구분을 ViewCheck 사용자들이 명확히 이해하도록 안내하는 것도 우리의 역할이다. "ViewCheck 통과 = 법적 준수 완료"가 아니라, "ViewCheck 통과 = 자동화 가능한 영역에서 기준을 충족함, 수동 점검으로 나머지 영역 확인 필요"가 올바른 해석이다.


왜 이 문제를 공개적으로 이야기하는가

마지막으로, 왜 우리가 이런 이야기를 블로그에 공개하는지에 대해 잠깐 적고 싶다.

자동화 도구를 파는 입장에서 보면, "우리 도구와 사람 전문가의 일치도가 낮을 수 있다", "우리도 아직 못 하는 부분이 많다"고 쓰는 건 영업에 도움이 안 되는 것처럼 보일 수 있다. 하지만 우리는 반대로 생각한다.

공공 웹 접근성 진단을 실제로 해본 사람들은 이 어려움을 이미 알고 있다. 사람 전문가들끼리도 결과가 갈리고, 자동화 도구마다 다른 결과가 나오는 현실을. "우리 도구가 완벽하다"고 말하면, 그걸 아는 사람들에게는 신뢰를 잃는다.

반면 "이 영역에서는 잘 작동하고, 이 영역에서는 아직 한계가 있으며, 우리는 이 차이를 줄이기 위해 이런 방식으로 연구한다"고 말하는 것 — 이게 실제로 이 문제를 다뤄본 사람들에게 훨씬 더 신뢰가 가는 이야기다.

ViewCheck가 이 시리즈 전체에서 'R&D 여정'이라는 톤을 유지하는 이유가 여기에 있다. 우리는 답을 다 가진 척 하지 않는다. 다만 어떤 문제를 어떻게 접근하고 있는지는 최대한 솔직하게 보여주려 한다.

테이블 위에 일치하는 점수 카드 두 장을 나란히 맞추어 놓는 손 두 개.
일치하는 카드를 나란히 맞추는 손. 사람 감사와 AI 진단의 일치도를 높이는 일은, 이 작업처럼 하나하나 비교하고 정렬해 가는 과정이다.

마무리 — 일치도는 과정이지 종착점이 아니다

이번 편에서 우리가 다룬 것들을 정리해 보자.

사람 전문가 감사와 AI 자동 진단의 일치도 문제는, "얼마나 일치하는가"를 측정하는 방법론(코헨의 카파, 평가자 간 신뢰도)에서 시작해, 자동화 도구끼리도 일치하지 않는다는 선행 연구의 충격, 자동화가 커버할 수 있는 WCAG 문제의 범위가 제한적이라는 사실, 사람 전문가끼리도 결과가 갈린다는 불편한 진실, 그리고 LLM을 판정에 쓸 때의 가능성과 위험을 거쳐, ViewCheck가 이 문제를 어떻게 접근하는지까지 이어졌다.

핵심 메시지는 세 가지다.

첫째, 자동화와 사람의 일치도는 영역마다 다르다. DOM 기반 구조 판정에서는 자동화가 높은 일관성을 낼 수 있지만, 의미론적·시각적·런타임 판정에서는 사람의 개입이 필요하다.

둘째, "일치하지 않는다"는 게 약점이 아니다. 사람 전문가들끼리도 일치하지 않는다. 중요한 것은 일치하지 않는 영역을 투명하게 드러내고, 그 이유를 이해하며, 두 접근의 강점을 조합하는 것이다.

셋째, 일치도를 높이는 연구는 끝이 없다. 기준이 바뀌고, 도구가 발전하고, 새로운 UI 패턴이 등장하는 한, 이 연구는 계속된다. ViewCheck는 이 여정에서 지금 어디에 있는지를 솔직하게 공개하며, 다음 걸음을 내딛는다.

다음 편에서는 이 일치도 문제의 또 다른 면 — "KRDS 규칙 846개, N/A를 어떻게 줄이는가" — 로 넘어간다. 어떤 규칙이 왜 N/A가 되고, 그것을 더 많이 판정 가능하게 만들기 위해 어떤 기술적 시도를 하는지를 다룰 예정이다. 관심 있는 분들은 다음 편도 이어서 봐주시길.


참고문헌

본문에 인용한 출처는 모두 작성 시점에 실재 여부를 검증했다. 공식 기준, 학술 연구, 업계 보고서를 함께 수록했다.

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

  1. 행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정 시행). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
  2. KRDS(범정부 UI/UX 디자인시스템) 공식 사이트 — 디지털 정부서비스 UI/UX 가이드라인. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
  3. 한국정보화진흥원(NIA), 한국형 웹 콘텐츠 접근성 지침(KWCAG 2.1). 과학기술정보통신부·한국정보화진흥원.

해외 — 학술 연구 / 기관 보고서

  1. Kelsey-Adkins, E. R., & Thompson, R. H. (2022). "Inter-rater Reliability of Command-Line Web Accessibility Evaluation Tools." In Proceedings of the 24th International ACM SIGACCESS Conference on Computers and Accessibility (ASSETS 2022). ACM. https://dl.acm.org/doi/abs/10.1145/3517428.3550395
  2. Deque Systems, "Deque Study Shows Its Automated Testing Identifies 57 Percent of Digital Accessibility Issues, Surpassing Accepted Industry Benchmarks." Business Wire, 2021. https://www.businesswire.com/news/home/20210310005156/en/Deque-Study-Shows-Its-Automated-Testing-Identifies-57-Percent-of-Digital-Accessibility-Issues-Surpassing-Accepted-Industry-Benchmarks
  3. Deque Systems, "Automated Accessibility Coverage Report." https://www.deque.com/automated-accessibility-coverage-report/
  4. Ferreiro Losada, A. et al. (2024). "Turning manual web accessibility success criteria into automatic: an LLM-based approach." Universal Access in the Information Society, Springer Nature. https://link.springer.com/article/10.1007/s10209-024-01108-z
  5. Li, W. et al. (2026). "Grading Scale Impact on LLM-as-a-Judge: Human-LLM Alignment Is Highest on 0-5 Grading Scale." arXiv:2601.03444. Harvard University, CMU, Stanford University, UC San Diego. https://arxiv.org/abs/2601.03444
  6. PMC / JMIR, "Using a Large Language Model (ChatGPT‐4o) to Assess the Risk of Bias in Randomized Controlled Trials of Medical Interventions: Interrater Agreement With Human Reviewers." (2025). PMC12442625. https://pmc.ncbi.nlm.nih.gov/articles/PMC12442625/
  7. Level Access, "Automated Accessibility Testing: A Practical Guide to WCAG Coverage." https://www.levelaccess.com/blog/automated-accessibility-testing-a-practical-guide-to-wcag-coverage/
  8. Government Digital Service (GDS), "Introducing the GOV.UK Design System." GDS Blog, 2018. https://gds.blog.gov.uk/2018/06/22/introducing-the-gov-uk-design-system/
  9. GOV.UK Design System (공식). Government Digital Service. https://design-system.service.gov.uk/

#신뢰도#검증#웹접근성#연구#KRDS#공공웹#AI진단#ViewCheck

관련 글

KRDS · 공공웹 AI 진단연구

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

분석이 끝나고 화면에 숫자가 떴다. 종합 74점. KRDS 846규칙 중 289개 통과, 228개 미통과, 329개 해당없음. 접근성 68점. 보안 91점. 위반 매트릭스에는 빨간 칸과 노란 칸이 뒤섞여 있다. 그런데 막상 이 결과를 받아 든 담당자의 표정이 묘하다. 뭔가 많이 나왔는데, 무엇을 먼저 봐야 할지 모르겠다.

ViewCheck Insight·2026.07.20
KRDS · 공공웹 AI 진단연구

AI 진단, 어디까지 믿어야 하나 — ViewCheck를 활용하는 사람을 위한 정직한 가이드

2026년 어느 날, 공공기관의 웹 담당자 한 명이 AI 분석 결과를 출력해 상사에게 내밀었다고 상상해 보자. "AI가 분석했더니 우리 사이트 KRDS 준수율이 68점입니다." 상사는 고개를 끄덕이며 "그럼 개선 계획 짜세요"라고 했다. 담당자는 돌아가 개발사에 수정 목록을 전달했다. 문제는, 그 68점이 무엇을 근거로

ViewCheck Insight·2026.07.20
KRDS · 공공웹 AI 진단연구

분석 → 개선 → 재진단, 공공웹 품질을 '점수로 관리'한다는 것 — ViewCheck LLM 분석 활용

공공 웹사이트 품질 진단을 맡은 실무 담당자들과 이야기하다 보면, 어느 지점에서 공통된 표정이 나온다. "진단은 했어요. 그런데 그다음은 어떻게 해야 하죠?" 도구를 돌리면 문제 목록이 나온다. 때로는 수백 개, 때로는 수십 페이지짜리 보고서가 나온다. 그리고 거기서 멈춘다. 문제를 고쳤는지 어떻게 확인하지? 개선 후에

ViewCheck Insight·2026.07.20