접근성 자동화의 한계 — 기계가 절대로 못 잡는 것들

자동검사가 57%에서 멈추는 이유, 그리고 나머지 43%를 어떻게 다룰 것인가

들어가며 — "자동 검사 돌렸으니까 됐겠지"라는 착각

공공 웹 접근성 점검 현장에서 가장 자주 만나는 오해가 하나 있다. "자동화 도구를 한번 돌렸더니 오류가 안 나왔어요. 그러면 접근성 기준 충족한 거 맞죠?" 이 질문을 처음 들었을 때, 솔직히 당황했다. 그 물음에 "아니요"라고 답하려면, '자동화 검사가 무엇을 잡을 수 있고 무엇을 잡을 수 없는지'라는 꽤 긴 설명이 필요하기 때문이다.

이 편을 쓰는 출발점은 그 질문이다. 우리가 ViewCheck LLM 분석을 만들면서 가장 오래 붙잡고 씨름한 주제 중 하나가 바로 이것이다. 접근성 분야의 자동화 도구는 어디까지 할 수 있고, 어디서부터는 사람이나 AI의 '맥락적 판단'이 반드시 필요한가. 그 경계를 솔직하게 그려보지 않으면, 우리 제품이 "자동 검사 돌렸으니까 됐겠지"와 다를 바가 없어지기 때문이다.

결론부터 말하겠다. 자동 접근성 검사는 강력하지만 불완전하다. 업계에서 가장 많이 인용되는 수치 중 하나는 Deque Systems의 2021년 연구에서 나온 57%다. axe-core 기반 자동 검사가 전체 접근성 문제의 57%를 찾아낼 수 있다는 결과다(Deque, 2021). 뒤집으면 43%는 자동화로 잡을 수 없다는 뜻이다. 영국 정부의 GDS(Government Digital Service)는 더 보수적인 수치를 제시했다. 142개의 실제 알려진 접근성 문제를 대상으로 자동화 도구를 테스트했을 때, 가장 좋은 도구도 30~40%만 발견했다는 것이다(GOV.UK accessibility blog, 2017).

이 숫자들을 처음 접했을 때 우리 팀 안에서도 논의가 많았다. "그러면 나머지를 어떻게 할 것인가?" 수동 전문가 검토를 권장하는 것으로 끝내도 될까? 공공 웹의 규모를 생각하면 그게 현실적인가? LLM이 그 빈틈을 채울 수 있을까, 없을까? 이 편은 그 고민의 기록이다.

한국인 전문가가 돋보기를 들고 자동화 도구가 놓친 웹페이지의 세부 항목을 직접 확인하고 있는 실사 사진. — 기계가 스쳐 지나간 디테일 하나를 돋보기로 들여다보는 전문가. 자동화가 못 잡은 그 하나를 찾는 일이 접근성 전문가의 핵심 역할이다.

숫자로 먼저 이해하는 자동화의 한계

접근성 자동화 도구가 얼마만큼 커버하는지에 대한 수치는 연구마다 조금씩 다르다. 그런데 방향은 일관되게 수렴한다. "상당히 많이 잡는다, 하지만 전부는 절대 아니다."

가장 직접적으로 인용할 수 있는 데이터 몇 가지를 먼저 정리하고 시작하자.

Deque Systems의 2021년 연구 (출처: deque.com, 2021년 3월 10일 발표)

Deque는 2,000개 이상의 감사, 13,000개 이상의 페이지, 거의 300,000개에 달하는 접근성 문제 데이터를 분석했다. 주요 도구는 오픈소스 axe-core 라이브러리. 결론은 이렇다.

"Deque의 자동화 기술이 전체 디지털 접근성 문제의 57%를 식별했으며, 이는 업계에서 일반적으로 받아들여지는 20~30% 커버리지 수치를 크게 상회한다."

그런데 이 연구에는 중요한 맥락이 있다. 57%가 높게 나온 데는 이유가 있다. 색상 대비(color contrast) 문제가 전체 오류의 약 30%를 차지하는데, 이 항목은 자동화 도구가 특히 잘 잡는 영역이다. 색상 대비는 수치로 계산되는 항목(4.5:1 비율 같은 기준)이기 때문에, 기계가 명확하게 통과/실패를 판정할 수 있다. 빈도가 높은 항목이 자동화 도구에 잘 잡히는 항목과 겹치다 보니 전체 커버율이 높아 보이는 것이다.

W3C WAI의 공식 입장 (출처: w3.org/WAI)

국제 웹 표준 기구인 W3C의 웹 접근성 이니셔티브(WAI)는 자동화 도구에 대해 이렇게 공식 입장을 밝히고 있다.

"웹 접근성 평가 도구는 접근성 여부를 결정할 수 없다. 단지 그 과정을 보조할 수 있을 뿐이다(Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so)."

W3C WAI가 정리한 WCAG 성공 기준별 자동화 가능 비율을 보면 현실이 더 선명해진다. Level A 기준의 약 25%, Level AA 기준의 약 17%, Level AAA 기준의 약 23%만이 자동화 도구로 신뢰할 수 있게 평가 가능하다(W3C WAI, 선택 가이드 자료 기반). 이 수치는 "WCAG 기준 항목 중 몇 %를 자동화로 검사할 수 있는가"를 보는 관점인데, Deque의 57%와 다른 이유는 측정 방식이 다르기 때문이다. Deque는 "실제 발생한 문제 건수 중 몇 %를 잡는가"를, W3C는 "성공 기준 항목 수 중 몇 %를 자동화로 판정 가능한가"를 측정했다.

영국 정부 GDS의 실험 (출처: GOV.UK accessibility blog, 2017년 2월 24일)

GDS는 "세상에서 가장 접근성 없는 웹페이지"를 의도적으로 만들고, 다양한 자동화 도구들이 그 페이지의 142개 알려진 문제를 얼마나 잡는지 실험했다.

"가장 좋은 도구도 30~40%만 발견했다."

이 실험의 의의는 단순한 수치 이상이다. 자동화 도구가 잘 못 잡는 문제 유형을 직접 식별하는 계기가 됐다. 그 목록에는 우리가 이 편에서 집중적으로 다룰 내용들이 대부분 들어 있다.

WebAIM Million 2026 보고서 (출처: webaim.org, 2026년)

WebAIM은 매년 상위 100만 개 웹사이트의 홈페이지 접근성을 자동화 도구로 검사해 발표한다. 2026년 보고서의 핵심 수치는 충격적이다.

"100만 개 홈페이지에서 5,611만 4,377개의 고유한 접근성 오류가 감지됐다. 페이지당 평균 56.1개 오류. 95.9%의 홈페이지에서 WCAG 2 위반이 발견됐다."

이 모든 수치가 '자동화 도구로 잡은 것들'이다. 그런데 이것이 전부가 아니라는 점, 오히려 잡히지 않은 것들이 더 중요할 수 있다는 점이 이 편의 핵심이다.

자동화가 잡는 것들 — 기계가 잘하는 영역

한계를 이야기하기 전에, 자동화 도구가 잘하는 영역도 먼저 공정하게 정리해야 한다. 그래야 경계가 명확해진다.

자동화가 신뢰할 수 있게 판정하는 항목들:

첫째, 대체 텍스트의 존재 여부(alt 속성 유무). 이미지에 alt 속성이 있는지 없는지는 기계가 명확하게 판정한다. <img> 태그에 alt="" 또는 alt="..." 속성이 있는가 없는가 — 이건 HTML 구조를 읽으면 즉시 알 수 있다.

둘째, 색상 대비(color contrast). WCAG 기준(일반 텍스트 4.5:1, 큰 텍스트 3:1)과 실제 CSS 색상값을 비교해 통과/실패를 판정한다. 수치 계산이기 때문에 자동화가 매우 정확하다. 앞서 언급했듯 이 항목이 전체 오류의 30%를 차지할 만큼 많이 발생하는 이유가 있다 — 개발자들이 디자이너의 시안 색상을 그대로 쓰다 보니 의도치 않게 대비가 부족해지는 경우가 흔하다.

셋째, ARIA 속성의 유효성. role, aria-label, aria-describedby 같은 ARIA 속성이 올바른 값으로 작성됐는지, 문법적으로 허용되는 조합인지는 규칙 기반으로 판정 가능하다. role="button" 이면서 tabindex="-1"이면 키보드로 접근이 안 된다는 것, 이 정도는 자동화가 잡는다.

넷째, 폼 레이블의 연결. <label for="..."> 와 <input id="..."> 가 제대로 연결됐는지, 또는 aria-labelledby로 대체 연결이 됐는지는 DOM 구조 분석으로 판정된다.

다섯째, 페이지 제목과 언어 속성. <title> 태그가 비어 있는지, <html lang="ko"> 같은 언어 속성이 설정됐는지는 명확한 규칙 기반 판정이다.

여섯째, 헤딩 구조의 위계. H1이 있는지, H2 없이 H3이 나오는 위계 오류가 있는지는 자동화가 잘 잡는다.

이런 항목들은 공통점이 있다. "있다/없다", "값이 맞다/틀리다"처럼 이진(binary) 판정이 가능한 것들이다. 기계는 이런 명확한 규칙 기반 판정에서 사람보다 빠르고 정확하며, 피로하지 않는다. 수백 개의 페이지를 같은 기준으로 일관되게 돌 수 있다는 점에서, 이 영역에서의 자동화는 매우 강력하다.

한국인 전문가와 자동화 설비가 책상 위에서 함께 체크리스트를 처리하는 실사 사진. — 자동화와 사람이 함께 체크리스트를 완성하는 구도. 기계가 빠르게 처리하는 항목과 사람만이 판단할 수 있는 항목이 나뉜다.

자동화가 못 잡는 것들 — 12가지 빈틈

이제 본론이다. 자동화 도구가 구조적으로 판정할 수 없는 영역들. 이것을 이해하는 게, 접근성 검사를 자동화에만 맡겼을 때 왜 위험한지를 이해하는 열쇠다.

1. 대체 텍스트의 '적절성' — 있는 것과 의미 있는 것은 다르다

자동화 도구는 이미지에 alt 속성이 있는지 없는지는 판정한다. 그런데 그 속성의 내용이 의미 있는지는 절대 판정하지 못한다.

예를 들어 보자. 어떤 공공기관 사이트에 정부 청사 사진이 있고, alt 텍스트가 image001.jpg라고 돼 있다. 자동화 도구는? 통과다. alt가 있으니까. 그런데 시각장애인 사용자가 스크린리더로 그 페이지를 탐색할 때, "image001.jpg"라는 안내는 정보가 아니라 쓰레기다.

반대의 경우도 있다. 장식용 이미지(디자인 요소로만 쓰이는 배경 이미지)인데 alt="서울시 대표 이미지, 해질녘 한강과 멀리 보이는 여의도 빌딩숲" 같은 상세한 설명이 붙어 있다면? 자동화 도구는 "alt가 있고, 비어 있지도 않으니 통과"를 줄 것이다. 하지만 접근성 관점에서 장식용 이미지는 alt=""(빈 alt)가 올바른 처리다. 스크린리더가 장식용 이미지를 읽어주지 않아야 탐색 흐름이 깔끔해지기 때문이다.

W3C WAI의 성공 기준 1.1.1 "텍스트 아닌 콘텐츠"는 "텍스트 대안이 동등한 정보를 제공해야 한다"고 규정한다. "동등한"이라는 단어가 기계에게는 판정 불가 영역이다.

Level Access의 자동화 접근성 테스팅 가이드도 이 점을 명확히 정리한다. "도구는 이미지에 alt 텍스트가 있다고 표시할 수 있지만, 그 텍스트가 실제로 이미지를 정확하게 묘사하는지는 오직 사람만이 판단할 수 있다(Level Access, 2023)."

실무에서 이게 얼마나 중요한지를 우리는 공공 웹 분석 과정에서 반복적으로 목격한다. 공공기관 사이트들이 alt를 달았다고는 하는데, 그 내용이 "이미지" "사진" "banner" 같은 무의미한 텍스트로 채워진 경우가 생각보다 훨씬 많다. 자동화 도구는 이런 경우를 전부 통과로 처리한다.

2. 이미지의 '맥락' — 같은 사진이 다른 의미를 가질 수 있다

같은 이미지라도 어느 맥락에 놓이느냐에 따라 alt 텍스트는 달라야 한다. 한 예를 들자.

어떤 사이트의 민원 신청 안내 페이지에 담당 공무원 사진이 있다고 하자. 그 페이지의 목적이 '이 사람이 담당 공무원입니다'를 알리는 것이라면, alt는 "OOO 주무관"이 적절하다. 하지만 같은 사진이 '공공기관 홍보 페이지의 배경 이미지'로 쓰인다면 장식용이므로 alt를 비워야 한다. 기계는 같은 이미지 파일을 두 개의 다른 컨텍스트에서 다르게 처리해야 한다는 것을 알 수 없다. 이미지의 '역할'은 HTML 구조가 아니라 페이지 전체의 맥락과 의도에서 결정되는 것이기 때문이다.

W3C의 "Images Tutorial"(WAI 웹 접근성 튜토리얼)은 이미지를 목적에 따라 7가지 유형(정보형, 장식형, 기능형, 텍스트 이미지, 복잡한 이미지, 그룹 이미지, 이미지맵)으로 분류하고, 각 유형마다 다른 alt 처리를 권장한다. 자동화 도구가 이 7가지 유형을 맥락으로 판단하기는 현재 기술로 매우 어렵다.

3. 키보드 흐름(Focus Order) — "논리적"이라는 기준

WCAG 성공 기준 2.4.3은 "포커스 순서"가 "의미나 작동에 영향을 미칠 때 논리적이고 직관적인 순서로 탐색 순서가 설정돼야 한다"고 요구한다.

자동화 도구는 tabindex 속성을 체크할 수 있고, 포커스 가능한 요소들의 DOM 순서를 읽을 수 있다. 그런데 그 순서가 "논리적"인지는 판정하지 못한다. 논리적이라는 건 결국 '이 페이지를 처음 방문한 사람이 키보드만으로 탐색할 때 자연스럽게 느껴지느냐'의 문제이고, 그건 사람이 실제로 탐색해봐야 안다.

영국 정부 DWP(Department for Work and Pensions)의 접근성 매뉴얼은 이 점을 직접적으로 지적한다. "포커스 순서 테스트는 자동화로 어렵다. 실제 키보드로 탐색해야 의미 있는 검증이 된다(DWP Accessibility Manual, 자동화 테스팅 섹션)." 특히 JavaScript로 동적으로 생성되거나 이동하는 UI 요소들 — 예를 들어 모달 다이얼로그가 열릴 때 포커스가 모달 안으로 이동하는지, 모달이 닫힐 때 트리거 버튼으로 포커스가 돌아오는지 — 이런 동적 포커스 관리는 스크립트를 실제로 실행해보지 않으면, 그리고 화면을 직접 경험해보지 않으면 판정 자체가 어렵다.

4. 키보드 트랩 — 빠져나올 수 없는 함정

키보드 트랩(keyboard trap)은 WCAG 2.1.2 기준이다. 키보드로 어떤 구성요소 안으로 포커스를 이동했을 때, 다시 키보드로 그 구성요소를 벗어날 수 없는 상황을 말한다. 예를 들어 날짜 선택기(datepicker)나 커스텀 드롭다운이 있을 때, 화살표 키나 Esc 키로 제어가 안 되면 트랩이 된다.

자동화 도구는 키보드 트랩의 존재 여부를 정적 HTML만으로 감지하기 매우 어렵다. 트랩이 발생하는 건 런타임 JavaScript 동작 때문이고, 실제로 그 구성요소를 키보드로 조작해봐야만 알 수 있다. Playwright 같은 브라우저 자동화 도구를 이용해 일부 탐지가 가능하지만, 커스텀 위젯의 다양한 구현 방식 때문에 완전한 자동화는 여전히 어렵다.

68%의 스크린리더 사용자가 매달 키보드 트랩이나 접근 불가능한 인터페이스를 경험한다는 조사 결과가 있다(testparty.ai, 2024). 이 수치는 충격적이지만 실감 난다. 자동화가 못 잡기 때문에 고쳐지지 않고, 고쳐지지 않기 때문에 사용자가 계속 겪는 악순환이다.

5. 스크린리더 경험 — 읽힘과 '이해됨'은 다르다

자동화 도구는 스크린리더가 어떤 텍스트를 읽을 수 있는지를 어느 정도 시뮬레이션할 수 있다. 그런데 실제 스크린리더 사용자가 그 텍스트를 들었을 때 의미 있게 이해하는지는 전혀 다른 질문이다.

예를 들어 버튼 레이블이 있다. "클릭"이라고만 돼 있는 버튼이 10개 있다면? ARIA 속성도 없고 aria-label도 없지만, 버튼 텍스트는 있다. 자동화 도구는 버튼에 텍스트가 있으니 통과를 줄 것이다. 하지만 스크린리더 사용자는 10개의 "클릭" 버튼이 각각 무엇을 하는지 알 수 없다. 각각의 버튼이 어떤 맥락에서 무엇을 위한 것인지는 시각적으로 주변 콘텐츠를 보고 판단하는 것인데, 스크린리더 사용자에게는 그 맥락이 전달되지 않기 때문이다.

또 다른 예: "여기를 클릭하세요"라는 링크 텍스트. 링크가 있고, 텍스트가 있으니 자동화 통과. 하지만 스크린리더 사용자는 링크 목록을 탐색할 때 링크 텍스트만 읽는다. "여기를 클릭하세요"가 5개 있으면, 어디로 가는지 전혀 알 수 없다.

이것이 WCAG 2.4.6 "헤딩과 레이블"과 2.4.9 "링크 목적(링크만으로)"이 요구하는 내용이다. "링크만으로 목적을 알 수 있어야 한다"는 기준 — 기계는 그 판단을 하기 어렵다.

6. 오류 메시지의 유용성 — 무엇이 틀렸는지 알려주는가

WCAG 3.3.1은 오류가 감지됐을 때 사용자에게 문자로 알려야 한다고 요구한다. 자동화 도구는 오류 메시지 역할(role="alert")이 설정됐는지, aria-live 속성이 있는지는 체크할 수 있다. 그런데 그 오류 메시지의 내용이 실제로 유용한지는 판정하지 못한다.

"필드가 유효하지 않습니다(Field is invalid)"라는 오류 메시지가 있다. 자동화 도구는 오류 역할이 설정된 텍스트가 있으니 통과다. 하지만 인지적 부하가 있는 사용자나 영어가 모국어가 아닌 사용자에게 "Field invalid"는 무엇이 왜 잘못됐는지 알 수 없는 메시지다. "이메일 주소 형식이 올바르지 않습니다(예: user@example.com)"처럼 구체적인 안내가 필요하다.

이것이 DEV Community의 "자동화 도구가 감지하지 못하는 12가지 접근성 문제" 시리즈에서 지적한 핵심 중 하나다(dev.to/leeannamarshall225, 2024). 오류 메시지의 품질은 텍스트가 있는가 없는가의 문제가 아니라, 텍스트가 충분히 설명적인가의 문제이고, 이건 인간의 언어 이해와 맥락 판단이 필요하다.

한국형 웹 콘텐츠 접근성 지침(KWCAG)과 자동화의 관계

우리나라의 공공 웹 접근성 기준은 KWCAG(한국형 웹 콘텐츠 접근성 지침)다. 현재는 KWCAG 2.2가 기준이며, 4대 원칙 아래 14개 지침, 33개 검사항목으로 구성된다.

한국의 웹 접근성 품질마크 평가 체계를 보면 자동화만으로 충분하지 않다는 것이 제도 설계 단계부터 반영돼 있다. 한국정보접근성인증평가원의 심사 기준은 1차 서면심사, 2차 전문가 심사, 3차 사용자 심사의 3단계로 구성된다. 자동화 도구가 1차에 활용될 수 있지만, 전문가 심사와 장애 유형별 사용자가 직접 과업을 수행하는 사용자 심사가 별도로 있다. 이 두 심사의 평균 점수가 90점 이상일 때 품질마크가 부여된다.

이 구조 자체가 말해준다. 접근성 인증은 자동화만으로 완성되지 않는다. 사람이 실제로 써봐야 하는 영역이 제도적으로도 인정돼 있는 것이다.

KWCAG의 33개 검사항목 중 자동화 도구가 완전히 판정할 수 있는 항목은 제한적이다. 특히 다음 유형의 항목들은 구조적으로 수동 검토가 필요하다.

인식의 용이성 항목들 중:

1.1.1 대체 텍스트: alt 유무는 자동 판정, 적절성은 수동
1.3.2 색에 무관한 인식: 색상만으로 의미를 전달하지 않는가 — 판정에 맥락 이해 필요
1.4.1 명확한 지시 사항: 위치, 모양, 크기, 방향으로만 설명하지 않는가 — 텍스트 내용 이해 필요

운용의 용이성 항목들 중:

2.1.2 초점 이동: 키보드 트랩 없음 — 런타임 테스트 필요
2.4.4 링크 목적: 링크 텍스트가 목적을 설명하는가 — 맥락 이해 필요

이해의 용이성 항목들 중:

3.3.1 오류 정정: 오류 식별 + 정정 제안 — 오류 메시지 품질 판단 필요
3.3.2 레이블 제공: 입력 서식의 레이블이 명확한가 — 적절성 판단 필요

견고성 항목들 중:

4.1.1 마크업 오류: 이건 자동화가 잘 잡는 항목이다

ViewCheck LLM 분석 접근성 탭의 실제 캡처. KWCAG 기반 접근성 항목들의 통과/미통과 결과와 다중 엔진 교차검증 결과가 표시된 화면. — ViewCheck LLM 분석의 접근성(KWCAG) 결과 카드 실제 화면. axe-core, IBM Equal Access, HTML CodeSniffer 등 다중 엔진의 자동화 결과가 KWCAG 33항목과 교차 매핑되어 표시된다. 자동화가 판정한 항목과 LLM이 보완 분석한 항목이 구분돼 나타난다. — 실제 분석 화면

자동화가 절대 못 잡는 영역들 (계속) — 인지·언어·경험

7. 인지적 접근성 — 이해할 수 있는가

WCAG 3.1 "가독성"과 3.1.5 "읽기 수준"은 텍스트의 읽기 난이도가 너무 높지 않아야 한다고 요구한다. 자동화 도구는 텍스트의 존재를 감지하고 레이블이 있는지를 확인할 수 있다. 그런데 그 텍스트가 실제로 이해하기 쉬운지는 전혀 판정하지 못한다.

공공 웹사이트의 공문서 스타일 텍스트를 생각해보자. "전입신고는 이전한 날로부터 14일 이내에 해당 거주지 관할 읍·면·동 주민센터에 방문하여 신고인 본인의 신분증을 지참하여 신청하여야 하며, 세대주 확인서가 필요한 경우 별도 서류를 준비해야 합니다." 접근성 도구는 이 문장에 대해 아무런 오류를 보고하지 않는다. 하지만 저시력 사용자, 인지 장애가 있는 사용자, 한국어가 모국어가 아닌 사용자에게 이 문장은 벽이다.

b13.com의 "자동화 접근성 테스팅이 충분하지 않은 이유"에서는 이 점을 명확히 정리한다. "자동화 도구는 텍스트가 평이한 언어를 사용하는지, 지시사항이 따라가기 쉬운지를 측정할 수 없다(b13.com, 2024)." 인지적 접근성은 자동화의 맹점이다.

8. 색상만으로 전달되는 정보 — "이 색이 무엇을 의미하는가"

자동화 도구는 색상 대비(contrast ratio)를 계산할 수 있다. 그런데 색상이 정보의 유일한 전달 수단으로 쓰이는지는 판정하기 어렵다. 예를 들어 테이블에서 오류 행이 빨간색으로 표시되고, 정상 행은 흰색으로 표시된다고 하자. 대비는 충분할 수 있다. 그런데 색맹 사용자에게 빨간색과 흰색의 의미 차이가 전달되는가? 이미지나 차트에서 다른 색으로만 계열을 구분하는 경우도 마찬가지다.

WCAG 1.4.1 "색 사용"은 색이 정보를 전달하는 유일한 수단이 되지 않아야 한다고 요구한다. 이 기준을 판정하려면 "이 색이 페이지에서 어떤 역할을 하는가"를 이해해야 하는데, 그건 시각적 맥락과 의미 구조를 동시에 파악해야 가능하다.

9. 동영상·오디오의 대체 수단 — 자막과 음성 해설의 품질

WCAG 1.2 계열 기준들은 동영상에 자막(caption)을, 음성 콘텐츠에 전사본(transcript)을, 정보가 담긴 영상에 음성 해설(audio description)을 요구한다. 자동화 도구는 <track> 태그가 있는지, kind="captions" 속성이 있는지를 체크할 수 있다. 그런데 그 자막의 내용이 실제 음성과 일치하는지, 타이밍이 맞는지, 자막 파일이 텅 비어 있는 건 아닌지는 파일을 열어서 내용을 확인해야만 알 수 있다.

공공 기관에서 자동 생성 자막(AI 자막)을 붙이는 경우가 늘고 있다. 자동 생성 자막은 빠르고 편하지만 오류가 많다. 특히 한국어의 경우 전문 용어, 지명, 인명 등에서 오류가 자주 발생한다. 자동화 도구는 자막 파일의 존재는 확인하지만, 그 품질은 확인하지 못한다.

10. 터치 타겟 크기와 간격 — WCAG 2.5 계열

WCAG 2.5.5 "타겟 크기"는 터치나 포인터 입력을 위한 타겟의 크기가 최소 44x44 CSS 픽셀이어야 한다고 권장한다. 자동화 도구는 일부 요소의 크기를 CSS에서 읽을 수 있다. 그런데 실제 렌더링된 화면에서의 크기, 특히 중첩된 CSS나 transform이 적용된 경우의 실제 크기, 그리고 인접 요소와의 간격(spacing)까지 고려한 '유효 터치 영역'은 정적 CSS 분석만으로는 부정확하다. 실제 브라우저에서 렌더링된 DOM의 getBoundingClientRect()를 실행해야 정확한 크기를 알 수 있다.

11. 애니메이션과 자동 움직임 — 사용자를 배려하는가

WCAG 2.2.2 "일시 정지, 중지, 숨김"과 2.3.3 "상호작용에 의한 애니메이션"은 자동으로 움직이거나 반짝이는 콘텐츠에 대한 기준이다. 자동화 도구는 @keyframes나 CSS animation 속성의 존재를 감지할 수 있다. 그런데 그 애니메이션이 사용자 설정을 존중하는지(prefers-reduced-motion 미디어 쿼리를 구현했는지), 얼마나 오래 지속되는지, 사용자가 멈출 수 있는지는 실제 동작을 봐야 판정할 수 있다.

전정 장애(vestibular disorder)가 있는 사용자에게 과도한 움직임은 메스꺼움이나 두통을 유발할 수 있다. 자동화 도구는 이 위험을 감지하는 데 매우 제한적이다.

12. 페이지 재설계나 콘텐츠 변경의 영향

마지막으로, 자동화 도구는 개별 요소를 점검하지 페이지 전체의 '경험'을 평가하지 않는다. 폼 하나를 예로 들자. 각 필드에 레이블이 있고, 오류 메시지 역할이 설정되어 있고, 탭 순서도 합리적이다. 자동화 도구는 모두 통과를 줄 것이다. 그런데 그 폼이 14단계로 이루어져 있고, 각 단계에서 무엇을 입력해야 하는지가 불명확하고, 오류가 났을 때 어느 단계의 어느 필드인지 파악하기 어렵다면? 장애가 있는 사용자, 특히 인지적 부하가 높은 과제에서 어려움을 겪는 사용자에게 그 폼은 실질적인 장벽이다.

자동화 도구가 잡는 '기술적 접근성'과 사용자가 실제로 경험하는 '기능적 접근성'은 겹치는 부분이 많지만 동일하지 않다. 그 차이를 메우는 건 사람의 판단이다.

한국인 감사 전문가가 화이트보드에 자동화 구역과 수동 구역 사이의 경계선을 그리고 있는 실사 사진. — 화이트보드에 자동 검사 영역과 수동 검사 영역의 경계선을 직접 그리는 감사 전문가. 그 선을 어디에 긋느냐가 접근성 검사의 핵심이다.

"자동화만으로 WCAG를 완전히 판정할 수 없다" — 연구들의 공통된 결론

지금까지 나열한 항목들에서 공통 패턴이 보인다. 자동화 도구가 못 잡는 것들은 대부분 '있다/없다'가 아니라 '적절한가', '논리적인가', '이해할 수 있는가'라는 질적 판단이 필요한 영역들이다.

Springer Nature Link에 2025년 게재된 학술 논문 "Coverage of web accessibility guidelines provided by automated checking tools"는 이 주제를 체계적으로 분석했다. 결론은 명확하다. "WCAG 기준의 완전한 자동화는 아직 달성 불가능하다. 특히 콘텐츠의 의미, 맥락, 사용자 경험과 관련된 기준들은 본질적으로 인간의 판단을 요구한다(Universal Access in the Information Society, 2025)."

W3C WAI의 "웹 접근성 평가 도구 선택" 가이드는 이렇게 정리한다. "평가 도구는 접근성 여부를 결정할 수 없다. 단지 과정을 보조할 수 있을 뿐이다. 따라서 도구는 항상 사람이 직접 하는 평가와 함께 사용해야 한다." 이 한 문장이 자동화 도구에 대한 가장 정확한 포지셔닝이라고 생각한다.

그런데 "수동 전문가 검토가 필요하다"는 결론에 우리는 실용적인 질문을 던지게 된다. 공공 웹사이트의 규모를 생각하면, 과연 그게 현실적인가?

규모의 문제 — 공공 웹의 현실

대한민국에는 수천 개의 공공 웹사이트가 있다. 중앙행정기관, 지방자치단체, 공공기관, 소속기관까지 합치면 그 숫자는 수만 개의 웹 페이지 단위로 늘어난다. 각 사이트마다 메인 페이지만 수십~수백 개가 아니라, 서비스 신청, 민원 처리, 정보 조회, 문서 다운로드 등 다양한 목적의 페이지가 존재한다.

이 모든 페이지를 접근성 전문가가 수동으로 검토한다면? 전문가 1명이 페이지 하나를 꼼꼼히 검토하는 데 최소 수십 분에서 수 시간이 걸린다. 단순 계산만으로도 사람의 손으로 전수 검사하는 건 불가능에 가깝다.

그래서 현실에서는 표본 검사가 이루어진다. 대표성 있는 페이지 유형 몇 가지를 골라 검토한다. 이 방식도 의미가 있지만, 메인은 접근성 기준을 충족하면서 내부 신청 페이지는 전혀 못 미치는 상황을 잡아내기 어렵다.

WebAIM Million 2026 보고서는 이 현실의 단면을 보여준다. 조사 대상 100만 개 홈페이지의 95.9%에서 WCAG 2 위반이 발견됐다. 홈페이지만 봐도 이 정도인데, 서비스 내부 페이지들은 어떨까? 우리가 분석한 공공 웹사이트들의 패턴을 보면, 메인과 내부 페이지 사이에 접근성 품질 차이가 큰 경우가 적지 않다.

바로 이 지점에서 '자동화 + 사람' 이분법이 아닌 세 번째 선택지로 LLM(대형 언어 모델)이 등장한다.

LLM은 이 빈틈을 채울 수 있을까? — 가능성과 한계

우리가 ViewCheck LLM 분석을 만들면서 오래 고민한 질문 중 하나가 이것이다. LLM이 자동화 도구가 못 잡는 '맥락적 판단' 영역에서 유의미한 역할을 할 수 있는가?

솔직하게 말하면, 아직 결론이 나지 않았다. 가능성과 한계가 공존한다.

LLM이 도움이 될 수 있는 영역:

첫째, 대체 텍스트 적절성 평가. 이미지와 함께 alt 텍스트를 LLM에 전달하면, "이 alt가 이미지의 맥락과 목적을 충분히 설명하는가"에 대한 의견을 낼 수 있다. 물론 LLM이 이미지를 '보는' 것이 전제되어야 하므로, Vision 기능이 필요하다. 최근 연구들은 LLM이 이미지 alt 텍스트 생성과 적절성 평가에서 의미 있는 결과를 보이기 시작했음을 보고한다(Benchmarking PDF Accessibility Evaluation, arxiv.org, 2025).

둘째, 오류 메시지와 레이블 품질 평가. 폼의 레이블 텍스트, 오류 메시지 텍스트를 LLM에 전달하면 "이 텍스트가 충분히 명확하고 이해하기 쉬운가"에 대한 판단을 받을 수 있다. 이건 단순한 텍스트 분석이라 LLM이 잘 처리한다.

셋째, 링크 목적의 맥락적 평가. "여기를 클릭", "더보기" 같은 링크 텍스트가 주변 콘텐츠와 함께 어떤 맥락에서 쓰이는지, 그 맥락 안에서 링크 목적이 이해되는지를 LLM이 분석할 수 있다.

넷째, WCAG 기준과 실제 구현 간의 갭 설명. "이 구현이 WCAG 1.3.1 '정보와 관계' 기준을 충족하는지"를 판단할 때, 규칙 원문과 구체적인 DOM 구조를 함께 전달하면 LLM이 설명과 함께 판단 의견을 낼 수 있다.

LLM의 한계:

첫째, 환각(hallucination) 위험. LLM이 "이 alt 텍스트는 적절합니다"라고 말해도, 그게 실제로 적절한지는 확인이 필요하다. WCAG 원문을 RAG(Retrieval-Augmented Generation)로 주입해 근거를 대게 하더라도, LLM이 그럴듯하게 틀릴 가능성은 항상 있다.

둘째, 일관성 문제. 같은 페이지를 LLM에 두 번 분석시키면 결과가 달라질 수 있다. 자동화 도구는 같은 입력에 항상 같은 출력을 낸다는 결정론적 장점이 있는데, LLM은 그렇지 않다.

셋째, 비용과 속도. LLM 호출은 DOM 규칙 판정에 비해 비용이 높고 느리다. 100개 페이지의 수백 개 접근성 항목을 전부 LLM으로 판정한다면 실용적이지 않을 수 있다.

넷째, 책임 소재. "LLM이 통과라고 했다"는 근거로 접근성 인증을 신청할 수 있는가? 현재로서는 그 근거의 신뢰성을 보장하기 어렵다.

그래서 우리가 현재 탐색하는 방향은 이렇다. LLM을 자동화의 대체재가 아니라 보조자로 사용한다. DOM 기반 자동화가 명확히 판정하는 항목들은 DOM 규칙이 담당하고(빠르고, 결정론적이고, 신뢰할 수 있다), LLM은 자동화가 "이건 사람이 봐야 한다"고 플래그를 세운 항목들에 대해 추가적인 맥락 분석을 제공한다. 그리고 그 LLM의 분석도 WCAG 규칙 원문과 공식 문서를 RAG로 주입해 근거를 함께 제시하게 만든다. "LLM이 그렇대"가 아니라 "WCAG 1.1.1 원문에 따르면, 이 alt 텍스트는 목적을 충분히 전달하지 않을 가능성이 있다"는 식의 근거 있는 의견을 내는 것이다.

이게 완성됐냐고 물으면, 솔직히 아니다. 우리가 실험하고 있는 영역이다. 특히 LLM의 접근성 판단에서 거짓 음성(false negative, 문제가 있는데 통과로 처리)이 얼마나 발생하는지를 측정하고 줄이는 일이 핵심 숙제다.

ViewCheck의 현재 접근 — 다중 엔진 교차검증

ViewCheck LLM 분석이 접근성 영역에서 현재 어떻게 동작하는지를 있는 그대로 설명하겠다.

4개의 자동화 엔진:

axe-core (Deque) — WCAG 2.1 AA/AAA 자동 검사. 오픈소스, 가장 널리 쓰이는 접근성 엔진. 거짓 양성(false positive)이 없는 것을 철칙으로 삼는 엔진이다(axe-core 공식). 색상 대비, ARIA 문법, 레이블 연결, 헤딩 위계 등을 빠르게 판정한다.
IBM Equal Access — IBM의 접근성 엔진. axe-core와는 규칙 세트가 일부 다르므로 교차검증에 활용한다.
HTML CodeSniffer — WCAG 2 AA 기준의 마크업 레벨 검사.
KWCAG 34항목 커스텀 검증 — 한국형 웹 접근성 지침의 항목을 ViewCheck 내부 규칙으로 구현한 검사. 국내 공공 웹 기준에 특화된 항목들을 다룬다.

KRDS 846규칙 중 접근성 관련 항목:

CP(컴포넌트) 446개 규칙 중 상당수가 ARIA 속성, 포커스, 버튼 레이블 등 접근성과 직결된다. 이 항목들은 DOM 기반 if/else 판정으로 처리한다. axe-core와의 교차검증으로 판정 신뢰도를 높이는 구조이기도 하다.

LLM 개입 영역:

위의 자동화 엔진들이 "해당없음(N/A)" 또는 "판정 보류"로 플래그를 세운 항목들, 특히 alt 텍스트 적절성, 오류 메시지 품질, 링크 목적 등을 LLM이 추가 분석한다. 이때 KWCAG와 WCAG 규칙 원문을 RAG로 주입해 근거를 함께 제시한다.

이 구조에서 중요한 원칙이 하나 있다. DOM 기반 자동화 엔진이 명확히 '미통과'로 판정한 것은 LLM이 뒤집지 않는다. 충돌을 방지하기 위한 것이다. LLM은 자동화가 '해당없음'이나 '불확실'로 남긴 영역만 채운다. AI가 자동화 결과를 임의로 오버라이드하면 결과의 신뢰성이 무너지기 때문이다.

결과적으로 사용자는 ViewCheck의 접근성 탭에서 이런 것을 보게 된다. 자동화 엔진이 판정한 항목들은 통과/미통과가 명확히 표시되고, LLM이 추가 분석한 항목들은 "LLM 분석 결과"라는 구분과 함께 근거가 제시된다. 판정의 출처가 무엇인지를 사용자가 알 수 있게 하는 것이 우리의 목표다.

한국인 검토자가 자동화 스캔이 놓친 접근성 문제를 돋보기로 발견하는 실사 사진. — 자동 스캔이 놓친 미세한 문제를 돋보기로 잡아내는 검토자. ViewCheck에서 LLM이 하려는 역할이 바로 이것이다 — 자동화가 플래그 세운 영역을 더 깊이 들여다보는 것.

자동화가 못 잡는 영역들 (더보기) — 사용 시나리오별 빈틈

이론적인 항목 분류를 넘어서, 실제 공공 웹에서 자주 발생하는 시나리오별로 자동화의 빈틈을 들여다보자.

로그인 페이지 시나리오

어떤 공공기관 사이트의 로그인 페이지를 자동화 도구로 검사한다. 아이디 입력창과 비밀번호 입력창에 각각 레이블이 연결돼 있다. 폼 제출 버튼에 "로그인"이라는 텍스트가 있다. 자동화 도구: 통과.

그런데 실제로 키보드만 써서 로그인을 시도해보자. 아이디 입력 후 Tab을 누르니 포커스가 비밀번호 창이 아니라 도움말 팝업 링크로 간다. 비밀번호를 입력하고 Enter를 누르니 폼이 제출되지 않고 페이지가 새로고침된다. 로그인 실패 시 오류 메시지가 화면 최상단에 나타나는데, 스크린리더는 그 메시지를 읽어주지 않는다(aria-live가 없음). 이 시나리오에서의 문제들은 전부 자동화가 잡지 못한 것들이다.

민원 신청 폼 시나리오

14단계로 이루어진 민원 신청 폼. 자동화 도구는 각 단계의 레이블, ARIA 역할, 색상 대비를 체크하고 통과를 준다. 그런데 실제로 써보면: 3단계에서 입력한 정보가 4단계에서 초기화된다(저장 안 됨). 8단계에서 필수 항목 미입력 오류가 났는데, 어느 필드가 문제인지 오류 메시지가 일반적으로 "필수 항목을 입력해주세요"라고만 뜬다. 12단계로 건너뛸 방법이 없어 처음부터 다시 해야 한다. 이 모든 것이 자동화 사각지대다.

동영상 콘텐츠 시나리오

공공기관의 정책 안내 동영상이 있다. <track kind="captions"> 태그가 있어 자동화 도구는 자막 있음 → 통과. 그런데 그 자막 파일을 열어보면 단 한 줄: "공식 자막 준비 중입니다." 내용이 없다. 또 어떤 동영상은 AI 자동 생성 자막인데, 장관 이름을 잘못 인식해 전혀 다른 이름으로 표기하고 있다. 자동화는 파일의 존재만 확인할 뿐, 내용의 정확성과 품질은 모른다.

공공 웹 접근성의 현실 — 왜 이 빈틈이 중요한가

이런 빈틈들이 왜 중요한지를 맥락으로 설명할 필요가 있다.

2026년 기준, 장애인이 가장 많이 경험하는 공공 서비스 불편 중 상당 부분이 '디지털 접근성'과 연결된다. 공공 행정 서비스의 디지털화가 빠르게 진행되면서, 온라인으로만 신청 가능한 서비스들이 늘고 있다. 그 온라인 채널에서 접근성이 깨지면, 대면 채널 없이는 서비스를 이용하지 못하는 사람들이 생긴다.

한국의 웹 접근성 법적 근거는 「장애인차별금지 및 권리구제 등에 관한 법률」 제21조 및 「장애인·노인·임산부 등의 편의증진 보장에 관한 법률」에 있다. 공공기관 웹사이트는 KWCAG 준수 의무가 있다. 그런데 의무와 현실 사이에는 여전히 간격이 있다.

자동화 도구만으로 접근성 점검을 완료했다고 보고하는 관행, 그 도구가 잡지 못하는 43%가 현장에서 장벽으로 남아 있는 현실 — 이 간격을 줄이려면 자동화의 한계를 명확히 인식하는 것이 첫걸음이다.

GOV.UK와 DWP가 권장하는 접근: 자동화는 출발점일 뿐

영국 정부 DWP(Department for Work and Pensions)의 접근성 매뉴얼은 자동화 테스트에 대해 이렇게 정리한다.

"자동화 접근성 테스팅은 명백한 이점이 있다. 특히 코드와 레이블 문제, 일부 대비 문제를 찾는 데 유용하다. 하지만 수동 테스팅도 반드시 해야 한다. 자동화 테스팅에만 의존하면 안 된다(DWP Accessibility Manual)."

GOV.UK Design System의 접근성 전략은 이렇게 정리한다. 자동화 도구, 수동 전문가 검사, 보조기술 사용자 테스트, 접근성 감사(audit), 그리고 사용자 리서치 — 이 다섯 가지를 조합해야 포괄적인 접근성 평가가 된다는 것이다(GOV.UK Design System, Accessibility Strategy).

이 조합이 맞다고 생각한다. 다만 실용성 문제가 항상 따라붙는다. 수백~수천 개의 공공 웹사이트 각각에 대해 이 다섯 가지를 전부 수행하는 건 인력과 비용 측면에서 현실적 도전이다. 그래서 자동화를 최대한 강화해 확실히 잡을 수 있는 영역을 기계에게 맡기고, 인간의 판단이 반드시 필요한 영역으로 전문가 자원을 집중하는 전략이 현실적이다.

그리고 그 '전문가 자원이 필요한 영역'을 정확히 식별하고 플래그를 세우는 일 — 어떤 페이지의 어떤 항목이 수동 검토를 요하는가 — 에서 LLM이 도울 수 있을지가 우리가 탐색하는 영역이다.

'PENDING_AI'와 'N/A'를 줄이는 연구

ViewCheck 내부에서 우리가 쓰는 용어를 하나 공유하겠다. 자동화가 판정하지 못한 접근성 항목들은 현재 두 가지 상태로 남을 수 있다.

N/A (해당없음): 이 페이지에 해당 컴포넌트나 상황이 존재하지 않아 판정 자체가 의미 없는 경우. 예를 들어 동영상이 없는 페이지에 "자막 제공" 항목은 N/A가 맞다.

PENDING_AI: 컴포넌트나 상황은 존재하는데, DOM 기반 자동화로는 통과/미통과를 판정할 수 없어 LLM 분석을 기다리는 상태.

문제는 정당한 N/A와 "자동화가 못 봐서 N/A"가 섞인다는 것이다. 어떤 페이지에 이미지가 있는데, 그 이미지의 alt 적절성을 자동화가 판정하지 못해 N/A로 처리했다면, 그건 정당한 N/A가 아니라 PENDING_AI다.

우리가 하려는 건 이 두 가지를 명확히 구분하고, PENDING_AI 항목들을 KRDScan 엔진의 Vision AI와 LLM이 채워가는 구조다. KRDScan 엔진은 스크린샷을 보고 이미지 alt 텍스트의 맥락을 판단하거나, DOM 텍스트를 읽고 오류 메시지의 품질을 평가하는 역할을 한다. 이 과정에서 PENDING_AI가 pass 또는 fail로 전환된다.

얼마나 많이 전환할 수 있는가? 솔직히 아직 불확실하다. alt 텍스트 적절성 같은 경우는 Vision AI가 의미 있는 역할을 할 수 있다는 사례들이 쌓이고 있다. 반면 키보드 흐름의 논리성이나 인지적 접근성은 Vision AI와 LLM으로도 여전히 어렵다. 이 영역은 사람의 실제 사용 테스트가 필요하다는 게 현재 우리의 솔직한 평가다.

자동화의 강점과 LLM의 역할 — 실용적인 조합

지금까지의 논의를 정리하면 이렇다.

자동화가 잘하는 것:

색상 대비 수치 계산
ARIA 속성 유무 및 문법 검사
레이블-입력 연결 여부
헤딩 위계 오류
언어 속성 여부
HTML 마크업 유효성
tabindex 존재 여부
이미지 alt 속성 존재 여부

이 항목들은 자동화가 빠르고, 정확하고, 일관되게 처리한다. axe-core 같은 도구가 거짓 양성 없이 판정하는 영역들이다. 이걸 자동화에 맡기는 건 매우 합리적이다.

사람(또는 LLM 보조)이 필요한 것:

alt 텍스트의 적절성과 맥락
포커스 순서의 논리성
키보드 트랩의 실제 발생 여부
오류 메시지의 유용성과 명확성
링크 텍스트의 목적 전달
색이 정보의 유일한 수단인지
인지적 접근성(읽기 수준, 복잡도)
동영상 자막의 품질과 정확성
폼 전체 흐름의 이해 용이성

이 항목들은 '있다/없다'가 아닌 '적절한가'의 판단이 필요하다. 전통적으로는 전문가 수동 검토만이 답이었지만, LLM이 일부 항목에서 유용한 보조 역할을 할 수 있다는 가능성이 열리고 있다.

중요한 것은 솔직함이다. "자동화로 다 됩니다"라고 말하는 도구보다, "자동화가 이만큼 커버하고, 나머지는 이런 방식으로 보완합니다"라고 말하는 도구가 더 신뢰할 수 있다. 우리가 ViewCheck에서 자동화 엔진과 LLM의 역할을 구분해서 표시하려는 이유가 여기에 있다. 어떤 판정이 어디서 왔는지를 사용자가 알 수 있어야 한다.

현장에서 사용할 수 있는 지침 — 자동화와 수동 검토의 결합

이론을 마치고, 현장에서 실제로 적용할 수 있는 지침을 정리해보자.

1단계: 자동화로 빠르게 훑기

axe-core, WAVE, Lighthouse 같은 도구를 CI/CD에 통합하거나, 배포 전 자동 검사로 활용한다. 이 단계에서 잡힌 문제들 — 색상 대비, ARIA 오류, 레이블 누락 등 — 은 즉시 수정한다. 이것만으로도 의미 있는 개선이 된다.

2단계: 유형별 수동 검토 목록 만들기

자동화가 못 잡는 항목들을 체크리스트로 만들어 정기적으로 수동 점검한다. 최소한 다음을 포함시키자.

이미지 alt 텍스트 적절성 (개발자/담당자가 직접 확인)
키보드만으로 전체 사용자 흐름 테스트
주요 폼의 오류 메시지 검토
동영상 자막 내용 확인
고빈도 사용 페이지의 색맹 시뮬레이터 테스트 (Chrome DevTools, Accessibility Insights 등 활용)

3단계: 실사용자(장애인) 테스트

가능하다면, 실제 스크린리더 사용자, 키보드만 사용하는 사용자, 인지 접근성에 어려움이 있는 사용자와 함께 주요 서비스 흐름을 테스트한다. 이것이 가장 강력한 접근성 검증이지만, 가장 많은 시간과 자원이 필요하다.

4단계: AI 보조 분석 활용

ViewCheck 같은 LLM 기반 분석 도구가 자동화 도구의 "불확실" 또는 "해당없음" 항목들에 대해 추가 맥락 분석을 제공할 때, 그 분석 결과를 수동 검토의 '우선순위 선별' 도구로 활용한다. LLM의 분석을 최종 판정으로 쓰는 게 아니라, "이 항목들을 수동으로 더 봐야 할 것 같다"는 가이드로 쓰는 것이다.

우리가 아직 모르는 것들 — R&D 노트의 솔직함

이 시리즈는 "ViewCheck가 다 해결했습니다"가 아니라 "우리가 이렇게 연구하고 있습니다"는 톤으로 쓴다고 처음부터 밝혔다. 접근성 자동화의 한계라는 주제에서도 그 톤을 유지하겠다.

우리가 아직 해결하지 못한 것들:

첫째, LLM의 접근성 판단 신뢰도 측정. LLM이 alt 텍스트를 "적절하다"고 판단했을 때, 접근성 전문가의 판단과 얼마나 일치하는가? 일치율을 체계적으로 측정하는 벤치마크를 구축하는 것이 우리의 목표 중 하나다. 아직 이 측정 자체가 진행 중이다.

둘째, PENDING_AI 전환율의 품질. N/A 상태의 접근성 항목들이 LLM을 통해 pass/fail로 전환될 때, 그 전환의 정확도는? 거짓 음성이 얼마나 발생하는가? 이건 실제 데이터가 쌓여야 알 수 있는 문제다.

셋째, 동적 접근성의 자동화. 사용자 상호작용 후에 발생하는 접근성 문제들 — 모달이 열릴 때 포커스 이동, 에러 메시지 등장 시 스크린리더 알림, 드래그앤드롭 대체 수단 등 — 을 Playwright로 시뮬레이션하는 것이 어느 수준까지 가능한가? 이 영역은 아직 실험적이다.

넷째, 다국어·다문화 맥락. 한국어 공공 웹에서 인지적 접근성은 언어의 평이함, 행정 용어의 친숙도, 한국어 읽기 수준의 다양성과 연결된다. 이 맥락을 고려한 자동화 보완은 해외 연구들의 틀을 그대로 가져오기 어렵고, 한국 공공 웹 특화 연구가 필요하다.

이런 것들을 우리가 지금 알고 있다면, 이 편에 넣었을 것이다. 모르기 때문에 "모른다"고 쓴다. 그리고 알아가는 중이라고 쓴다.

ViewCheck LLM 분석의 접근성 기능 — 실제로 보여주는 것들

마지막으로, ViewCheck LLM 분석이 현재 접근성 관련해서 실제로 어떤 결과를 보여주는지 정리한다.

사용자가 공공기관 URL을 입력하면, 접근성(KWCAG) 카드에는 다음이 나타난다.

1. 다중 엔진 자동화 결과: axe-core, IBM Equal Access, HTML CodeSniffer의 검사 결과가 KWCAG 33항목과 교차 매핑된다. 어떤 도구가 어떤 항목에서 오류를 발견했는지를 볼 수 있다.

2. KRDS 846규칙 중 접근성 관련 항목: CP(컴포넌트) 규칙들 중 ARIA 관련, 포커스 관련, 레이블 관련 항목들의 통과/미통과/해당없음 결과.

3. 다중 페이지 집계: 메인 페이지만이 아니라 검색, 로그인, 신청, 목록, 상세 등 다양한 유형의 페이지를 함께 분석한 집계 결과. 어느 페이지 유형에서 접근성 문제가 집중되는지를 볼 수 있다.

4. 우선순위 표시: P0(즉시 수정)~P3(장기 개선) 우선순위로 정렬된 접근성 문제 목록. 어떤 문제를 먼저 고쳐야 하는지의 가이드.

5. KRDS 공식 문서 참조: 각 접근성 항목이 어떤 KWCAG 지침, 어떤 KRDS 컴포넌트 규칙과 연결되는지 참조패널에서 확인 가능.

현재 LLM이 보완하는 영역: 자동화가 "판단 불가" 또는 "해당없음"으로 표시한 항목들 중 일부에 대해, LLM이 스크린샷과 DOM 텍스트를 참조해 추가 의견을 제공한다. 이 의견은 반드시 KWCAG·WCAG 원문 근거와 함께 제시된다. "이 이미지의 alt 텍스트 'image001.jpg'는 WCAG 1.1.1 기준에 따른 정보 전달 목적을 충족하지 않을 가능성이 있습니다. KWCAG 1.1.1(대체 텍스트 제공) 지침을 참조하세요"와 같은 방식이다.

자동화가 커버하지 못한다고 명시되는 것들: 위에서 나열한 12가지 빈틈 중 ViewCheck가 현재 자동으로 커버하지 못하는 영역들은 별도로 표시된다. "이 항목은 현재 수동 전문가 검토를 권장합니다"라는 안내와 함께. 못 하는 걸 못 한다고 말하는 것이다.

화이트보드에 '기계가 할 수 있는 것'과 '사람이 해야 하는 것' 두 칸이 나뉘어 정리된 화면을 담은 실사 사진. — 기계가 할 수 있는 것과 사람이 해야 하는 것을 두 칸으로 나눈 화이트보드. 이 경계를 명확히 하는 것이 접근성 테스팅 설계의 출발점이다.

마무리 — 57%를 100%로 오해하지 않기

이 편의 핵심을 한 문장으로 정리한다면: 자동화 접근성 검사는 강력하지만 절반 이상의 문제를 잡을 수 없고, 그 '잡지 못하는 절반'이 종종 더 중요한 장벽이다.

Deque의 57%, GDS의 30~40% — 이 숫자들을 어떻게 해석하느냐가 중요하다. "57%나 잡는다니 충분하다"가 아니라, "57% 이후의 43%에는 alt 텍스트 품질, 키보드 흐름, 인지적 접근성, 오류 메시지 유용성 같은 것들이 있다"는 인식이 필요하다.

우리가 ViewCheck를 만들면서 배운 것이 있다면, 자동화의 한계를 솔직하게 인정하는 것이 오히려 신뢰를 만든다는 것이다. "자동화로 다 됩니다"라고 말하는 도구는 결국 "자동화로 57%가 됩니다, 나머지는 이렇게 보완합니다"라고 말하는 도구보다 더 많은 빈틈을 남긴다.

LLM이 그 빈틈을 얼마나 채울 수 있는지는 아직 실험 중이다. 완전한 자동화는 현재로서는 불가능하고, 아마 상당 기간 그럴 것이다. 그렇다면 자동화가 확실히 할 수 있는 영역에서 최대한 정확하게, 그 이후 영역에서는 사람의 판단을 효과적으로 지원하는 방식으로 — 그 조합을 계속 실험하고 있다.

다음 편에서는 접근성과 연결된 또 다른 주제, 반응형 설계와 터치 타겟 크기 검증에서 자동화와 실기기 테스트의 경계를 다룰 예정이다. 기기 다양성이 폭발적으로 늘어난 환경에서 공공 웹의 반응형 품질을 어떻게 측정할 것인가 — 이 주제도 자동화의 한계와 보완이라는 같은 틀에서 볼 수 있는 이야기다.

공공 웹 접근성이 "기계가 통과 줬으니까 됐겠지"로 처리되지 않기를 바란다. 그리고 ViewCheck가 그 '됐겠지'를 막는 데 조금이라도 역할을 하기를 바란다.

참고문헌

본문에 인용한 출처는 작성 시점에 모두 실재 여부를 WebSearch로 검증했다. 국내 공식 기준과 해외 연구·기관 자료를 함께 실었다.

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

한국정보접근성인증평가원, 웹 접근성 품질마크 심사기준 (1차 서면심사 · 2차 전문가심사 · 3차 사용자심사). https://wa.or.kr/m1/sub3.asp
한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2 공식 문서 (4대 원칙, 14개 지침, 33개 검사항목). https://a11ykr.github.io/kwcag22/
행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25.). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침

해외 — 연구 / 기관 / 가이드라인

Deque Systems, "Automated Testing Identifies 57% of Digital Accessibility Issues" (2021년 3월 10일, 2,000개 이상 감사·13,000개 이상 페이지·300,000개 문제 분석, axe-core 기반). https://www.deque.com/blog/automated-testing-study-identifies-57-percent-of-digital-accessibility-issues/
W3C Web Accessibility Initiative (WAI), "Selecting Web Accessibility Evaluation Tools" — "Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so." https://www.w3.org/WAI/test-evaluate/tools/selecting/
GOV.UK Accessibility Blog, "What we found when we tested tools on the world's least-accessible webpage" (2017년 2월 24일, 142개 알려진 접근성 문제 대상, 최고 도구도 30~40%만 발견). https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/
DWP Accessibility Manual (영국 노동연금부), "Automated accessibility testing" — 자동화 도구는 코드·레이블·대비 문제에 유용하나 수동 검토 병행 필수. https://accessibility-manual.dwp.gov.uk/tools-and-resources/automated-accessibility-testing
WebAIM, "The WebAIM Million — The 2026 report on the accessibility of the top 1,000,000 home pages" — 100만 홈페이지 56.1 오류/페이지, 95.9%에서 WCAG 2 위반 발견. https://webaim.org/projects/million/
WebAIM, "Web Accessibility Evaluation Guide" — "All automated tools have limitations — not all conformance failures can be automatically detected." https://webaim.org/articles/evaluationguide/
Level Access, "Automated Accessibility Testing: A Practical Guide to WCAG Coverage" — "Tools can flag that an image has alt text, but only a person can judge if that text actually describes the image well." https://www.levelaccess.com/blog/automated-accessibility-testing-a-practical-guide-to-wcag-coverage/
DEV Community, "12 Accessibility Problems That Automated Tools Fail to Detect" (2024). https://dev.to/leeannamarshall225/12-accessibility-problems-that-automated-tools-fail-to-detect-1gof
Universal Access in the Information Society (Springer Nature Link), "Coverage of web accessibility guidelines provided by automated checking tools" (2025) — WCAG 기준의 완전한 자동화 불가능 결론. https://link.springer.com/article/10.1007/s10209-025-01263-x
b13.com, "Why Automated Accessibility Testing Isn't Enough" (2024) — 인지적 접근성, 평이한 언어는 자동화로 측정 불가. https://b13.com/blog/why-automated-accessibility-testing-isnt-enough
GOV.UK Design System, "Accessibility Strategy" — 5가지 접근성 평가 방법 조합 권장. https://design-system.service.gov.uk/accessibility/accessibility-strategy/