사람 컨설턴트 vs LLM 분석 — 공공웹 품질 진단, 언제 무엇을 써야 하나

전문가 수동 컨설팅과 AI 자동 진단의 강점·약점을 정직하게, 단정 없이 비교한다

들어가며 — "그래서 AI가 전문가보다 낫다는 건가요?"

이 시리즈를 읽어온 분들 중에 이런 질문을 품은 분이 분명 있을 것이다.

"ViewCheck LLM 분석이 이렇게 좋다고 하면, 컨설팅 회사 부를 필요가 없는 거 아닌가요?"

솔직하게 말하자면 — 아니다. 적어도 지금은 그렇지 않고, 앞으로도 그런 날이 쉽게 오지 않을 것 같다.

AI 자동 분석과 사람 전문가의 수동 진단은 '어느 쪽이 더 낫다'의 문제가 아니라, 서로 잘하는 영역이 다른 문제다. 이걸 혼동하면 두 가지 실수 중 하나를 저지르게 된다. AI 분석을 만능으로 오해해서 전문가를 배제했다가 사각지대를 놓치거나, 반대로 자동화를 아예 불신해서 사람이 감당할 수 없는 양의 작업을 계속 손으로 하거나.

이 글은 그 두 극단 사이 어딘가에 실용적인 균형을 그어보려는 시도다. ViewCheck를 만드는 입장에서 쓰지만, 그렇다고 AI 분석의 우위를 설득하려는 글은 아니다. 오히려 AI 자동 진단이 확실히 못 하는 것들을 먼저, 솔직하게 적을 것이다. 그 위에서 AI가 도움이 되는 국면을 이야기하는 게 훨씬 정직한 순서라고 생각하기 때문이다.

공식 회의 테이블에서 한국인 UX 컨설턴트가 정부 관계자에게 상세한 인쇄 보고서를 발표하는 장면. — 수동 컨설팅의 가장 강력한 자산은 대화다. 문서 뒤에 있는 맥락과 의도를 끌어내는 능력은 자동화가 따라가기 어렵다.

이 비교를 시작하기 전에 하나만 먼저 말해두겠다. 이 글에서 쓰는 수치들 — 자동화 도구의 감지율, 수동 감사 비용, 전문가-AI 일치도 연구 결과 — 는 모두 실재하는 출처에서 가져왔다. 출처를 확인 못 한 숫자는 쓰지 않았다. 공공 영역에서 이런 비교는 근거가 허술하면 오히려 의사결정을 망친다.

먼저, 자동화 감지 도구의 현실 — "30~40%의 벽"

AI 자동화 도구가 얼마나 많은 WCAG 위반을 잡아낼 수 있을까? 이 질문에 대한 답은 업계에서 10년 이상 반복해서 나온 숫자가 있다.

자동화 도구는 WCAG 위반의 약 30~40%를 감지한다. 나머지 60~70%는 자동화로 잡을 수 없다.

이 수치는 Deque, WebAIM, TPGi 같은 웹 접근성 전문 기관들이 오랜 기간 독립적으로 내놓은 연구 결과다(Level Access, "Automated Accessibility Testing: A Practical Guide to WCAG Coverage"). 수치의 출처가 한두 곳이 아니라, 업계에서 반복 검증된 수렴값이라는 점이 중요하다.

왜 이런 한계가 생길까. 자동화가 잘 잡아내는 건 규칙이 명확하고, 기계적으로 판정 가능한 것들이다. 예를 들어 색상 대비값이 기준치를 넘는지 아닌지(WCAG 1.4.3 색상 대비), img 태그에 alt 속성이 있는지 없는지, form 요소에 label이 연결되어 있는지 — 이런 건 DOM 데이터를 읽으면 0/1로 판정된다. 자동화가 강한 영역이다.

반면 자동화가 못 하는 건 맥락과 의미가 필요한 판단이다. alt 속성이 존재하는 것과, 그 alt 텍스트가 실제로 의미 있는 내용을 담고 있는지는 다른 문제다. alt="image1.jpg" 같은 파일명을 그대로 붙인 경우, 자동화 도구는 "alt 있음"으로 통과시킨다. 그게 맥락상 적절한 설명인지는 사람이 봐야 안다. 마찬가지로, 헤딩 구조(H1→H2→H3)가 HTML 상으로 올바르게 중첩되어 있더라도, 그 헤딩이 페이지 내용을 논리적으로 잘 구분하는 의미 있는 구조인지는 또 다른 판단이다.

WebAIM이 2025년 발표한 'WebAIM Million' 리포트에 따르면, 100만 개 홈페이지 분석 결과 94.8%가 기본적인 접근성 요건을 충족하지 못하고 있으며 페이지당 평균 51개의 오류가 탐지됐다. 이 수치는 자동화 도구로 잡을 수 있는 오류 기준이다. 자동화가 검출하지 못하는 부분까지 포함하면 현실은 이보다 더 어둡다(WebAIM Million 2025 보고서).

이 '30~40%의 벽'은 WCAG 기준의 이야기지만, KRDS 846규칙에도 유사한 구도가 적용된다. ViewCheck가 현재 분석 시 도출하는 결과를 실측 기준으로 보면, DS·CP·BP·SP 4개 카테고리에 걸쳐 규칙에 따라 자동 판정 가능한 비율이 다르다. DOM으로 명확히 판정되는 규칙이 있고, "이 컴포넌트가 이 페이지에 존재하는지" 자체를 시각적으로 봐야만 판정할 수 있는 규칙이 있다. 우리도 그 경계와 싸우면서 연구하는 중이다.

사람 전문가가 잘하는 것들 — 자동화가 따라가기 어려운 영역

자동화의 한계를 이야기했으니, 이번엔 사람 전문가의 강점을 정리해 보자. 이게 진짜 핵심이다.

1. 스크린리더 실사용 경험

전문 접근성 컨설턴트 중 상당수는 JAWS, NVDA, VoiceOver 같은 스크린리더를 실제로 사용하며 사이트를 탐색한다. 이건 자동화가 재현할 수 없는 경험이다. 스크린리더가 특정 요소를 어떻게 읽어주는지, 동적으로 업데이트되는 영역(예: 로딩 중 상태 변화, 팝업 열고 닫기)에서 초점이 올바르게 이동하는지, 키보드만으로 모든 기능에 접근할 수 있는지 — 이런 건 실제 보조 기술을 써봐야 확인할 수 있다.

자동화 도구는 코드 구조를 보고 "이 요소에 role=dialog가 있으니 모달로 인식될 것이다"라고 추론할 수 있지만, 실제 스크린리더가 그 모달을 열 때 초점이 모달 안으로 제대로 이동하는지, 닫을 때 원래 위치로 돌아오는지는 직접 실행해봐야 알 수 있다.

2. 사용자 인터뷰와 맥락 파악

전문 컨설턴트는 단순히 화면을 점검하는 것이 아니라, 사이트를 만든 팀과 대화한다. "이 페이지를 누가 쓰는가", "이 버튼이 이렇게 만들어진 이유는 무엇인가", "개편 예산과 일정은 어떻게 되는가" — 이런 맥락은 보고서의 개선 우선순위를 결정하는 데 결정적이다. 자동화 도구는 URL을 받아 데이터를 뽑아낼 뿐, 그 사이트의 조직 맥락을 알지 못한다.

3. 모호한 판단 영역에서의 전문적 해석

WCAG나 KRDS 규칙에는 "적절한", "충분한", "명확한" 같은 형용사가 들어간 기준들이 있다. 예를 들어 WCAG 1.4.4는 "200% 확대해도 콘텐츠를 잃지 않아야 한다"고 하는데, '콘텐츠를 잃지 않는다'의 경계는 해석이 필요하다. 전문 컨설턴트는 이런 회색 지대를 판례와 경험에 근거해 해석한다. AI 자동화는 이 회색 지대에서 틀릴 위험이 높다.

4. 인터랙션 흐름 전체를 따라가는 능력

공공 서비스에서 중요한 흐름 — 예를 들어 복지 급여 신청 절차 — 은 단일 페이지의 문제가 아니다. 로그인 → 신청서 작성 → 첨부파일 업로드 → 검토 → 제출 → 완료 확인으로 이어지는 다단계 흐름 전체를 접근성 관점에서 따라가며 어디서 막히는지를 보는 것, 그게 사용자 여정 관점의 컨설팅이다. 자동화는 페이지별로 데이터를 수집하지만 그 흐름 전체를 '경험'으로 평가하는 것은 다른 차원의 일이다.

5. 정치적·조직적 조율

이 부분을 종종 간과하는데, 공공기관 컨설팅에서 '기술적 개선 제안'보다 훨씬 어려운 건 '조직이 그 개선을 실행하게 만드는 과정'이다. 어떤 부서가 어떤 변경을 할 수 있는지, 담당 개발사와의 계약 구조는 어떻게 되는지, 어떤 표현으로 내부 보고를 해야 승인이 날지 — 이런 맥락을 아는 컨설턴트의 역할은 코드 분석과는 다른 차원의 전문성이다.

AI 자동 분석이 잘하는 것들 — 사람이 물리적으로 못 하는 영역

이제 반대쪽을 보자. 사람 전문가가 확실히 못 하는 것들, 혹은 하기 어려운 것들이 있다.

1. 규모의 문제 — 100페이지를 사람이 볼 수 있는가

공공기관 웹사이트는 대개 수십에서 수백 페이지로 이루어져 있다. 메인 페이지, 민원 신청 페이지, 정책 안내 페이지, 검색 결과 페이지, 게시판 목록과 상세, 로그인 화면, 사이트맵… 이걸 사람이 모두 열어서 846개 규칙 기준으로 일일이 점검하면 얼마나 걸릴까.

현실적인 접근성 컨설팅 관행을 보면, 전문 감사는 페이지당 수 시간을 소요한다(Accessible.org, "Breaking Down the Cost of a Website Accessibility Audit"). 100페이지면 수백 시간이다. 프로젝트 납기가 그걸 허용하지 않기 때문에, 실제 수동 감사에서는 '대표 페이지 샘플링'을 한다. 전체 사이트의 모든 페이지를 사람이 수동으로 보는 건 물리적으로 불가능하다.

자동화는 이 규모 문제를 해결한다. Playwright로 브라우저를 띄워 100개 페이지를 순회하는 데는 기계에게 몇 분~수십 분의 문제다. 물론 자동화가 각 페이지에서 잡아내는 게 사람보다 적지만, 100% 커버리지로 모든 페이지를 본다는 것 자체가 샘플링을 전제한 수동 감사와 근본적으로 다른 출발점이다.

ViewCheck에서 우리가 '다중 페이지 분석을 기본값으로'를 고수하는 이유가 여기에 있다. 메인 한 장만 보면 그 사이트를 '본 것'이 아니다.

2. 일관성 — 페이지마다 기준을 똑같이 적용

사람이 100페이지를 순차적으로 점검하면, 10페이지 즈음부터 집중도가 달라지고, 30페이지에서는 초반에 잡아낸 것들을 놓치기 시작한다. 점검자가 여럿이면 기준 해석이 달라질 수도 있다. 이건 사람의 한계가 아니라, 반복적 수작업의 본질적 특성이다.

자동화 도구는 1번 페이지에 적용한 기준을 100번 페이지에도 동일하게 적용한다. DS-044 규칙을 판정하는 로직이 페이지 1에서 작동한 방식이 페이지 100에서도 똑같이 작동한다. 이 기계적 일관성은 대규모 점검에서 큰 장점이다. '이 사이트의 검색 페이지들 간에 색상 토큰 일관성이 있는가'를 비교할 때, 자동화는 모든 검색 페이지의 데이터를 동일한 기준으로 수집하고 비교할 수 있다.

3. 속도와 빈도 — 배포할 때마다 다시 점검

공공 웹사이트는 한 번 만들고 끝이 아니다. 콘텐츠가 추가되고, 개발사가 기능을 수정하고, 외주 담당이 바뀌면서 이전에 통과했던 항목이 어느 순간 깨질 수 있다. 이걸 발견하려면 정기적인 재점검이 필요하다. 사람 컨설턴트를 분기마다 부를 수 있는 기관은 드물다. 비용도 비용이지만, 컨설팅 계약의 특성상 일회성 프로젝트로 끝나는 경우가 많다.

자동화 도구는 '주 1회 점검', '배포 후 자동 재분석' 같은 주기를 기계적으로 돌릴 수 있다. 변화에 대한 모니터링, 이전 결과 대비 회귀 감지 — 이건 자동화가 사람보다 훨씬 유리한 영역이다.

4. 결과의 구조화와 추적

수동 감사 결과는 대개 PDF 보고서로 나온다. 그 보고서를 받아서 개선 작업을 추적하고, 어느 항목이 해결됐는지를 관리하는 건 또 다른 수작업이다. 자동화 도구가 구조화된 데이터(어떤 URL의 어떤 요소가 어떤 규칙을 위반하는지, 규칙 ID와 근거 포함)를 반환하면, 이걸 티켓 시스템에 연결하거나 개발사에 그대로 전달하는 과정이 훨씬 매끄러워진다.

ViewCheck LLM 분석 인사이트 카드 화면 캡처. 다중 페이지 분석에서 주요 위반 패턴과 사이트 전체 진단 요약이 표시되어 있다. — ViewCheck LLM 분석의 인사이트 카드. 다중 페이지 분석 결과에서 반복적으로 등장하는 위반 패턴과 사이트 전체의 맥락적 진단을 요약해 보여준다. 이 수준의 요약을 사람이 100페이지 데이터를 수동으로 정리해 만들려면 상당한 시간이 필요하다. — 실제 분석 화면

비용과 시간의 현실 — 수동 감사는 얼마나 드나

추상적인 비교를 조금 더 구체화해 보자. 사람 전문가의 수동 접근성 감사에는 실제로 어느 정도의 비용과 시간이 드는가.

영국의 경우, 정부 디지털 서비스(GDS) 공인 접근성 전문 기관인 AbilityNet은 '디지털 접근성 리뷰'를 4,950파운드(VAT 별도)에 제공한다(AccessiblePixels, "Website Accessibility Audit Cost UK – 2026 Pricing Guide"). 이것도 특정 범위 안에서의 감사다. 복잡도에 따라 이 이상도 된다.

미국 시장 기준으로는, 1차 페이지(primary page) 기준으로 페이지당 100~~250달러가 일반적인 접근성 컨설팅 단가다. 간단한 페이지는 페이지당 25~~100달러, 복잡한 페이지는 더 올라간다(Accessible.org, "Breaking Down the Cost of a Website Accessibility Audit"). 100페이지짜리 공공 사이트라면 최소 수천 달러에서 수만 달러 사이가 된다. 시간은 3~6개월 단위 프로젝트가 일반적이다(WCAG compliance cost 분석 결과, TestParty).

이 비용이 '비싸다', '싸다'의 기준은 조직마다 다를 것이다. 그런데 공공기관 입장에서 이 비용이 갖는 의미는 두 가지다. 하나는 예산의 문제이고, 다른 하나는 이 비용을 들여 받은 보고서를 어떻게 활용하느냐의 문제다.

보고서가 나왔다고 일이 끝나는 게 아니다. 실무 담당자가 보고서를 읽고, 개발사에 개선 요청을 하고, 개선 결과를 재확인하는 전체 사이클이 있다. 이 사이클이 1년 주기로 돌아가면, 그 사이에 일어난 수십 건의 콘텐츠 추가와 기능 수정이 새로운 위반을 만들어도 다음 감사 때까지 아무도 모른다.

여기서 자동화의 역할이 시작된다. 사람 컨설턴트가 잡아낸 구조적 문제를 수정하는 큰 작업은 수동 감사 기반으로 가되, 수정 후 상태 유지와 일상적 품질 모니터링은 자동화로 보완하는 것이다. 두 가지가 역할을 나눠 갖는 구도다.

"전문가 vs AI"라는 프레임 자체가 잘못됐다

이쯤에서 원래 질문으로 돌아가자. "AI가 전문가보다 낫다는 건가요?" 이 질문이 잘못된 이유가 무엇인지 이제 조금 더 명확해졌을 것이다.

이건 '자동차가 사람보다 빠른가'와 비슷한 질문이다. 직선 도로에서는 그렇다. 비탈길의 좁은 골목에서는 사람이 낫다. 목적지가 어디냐, 지형이 어떻냐에 따라 적합한 이동 수단이 다르다.

웹 품질 진단도 마찬가지다.

자동화가 확실히 앞서는 국면:

사이트 전체 페이지를 빠짐없이 규칙 기반으로 스캔해야 할 때
이전 분석 대비 새로 생긴 위반을 찾아야 할 때
어느 규칙이 사이트 전체에서 얼마나 많이 위반되는지 통계를 내야 할 때
예산과 일정이 제한적이어서 전문 컨설팅 의뢰 전에 현황부터 파악해야 할 때
개발사에 구체적인 위반 항목 목록을 (규칙 ID와 근거 포함해서) 전달해야 할 때

사람 전문가가 확실히 앞서는 국면:

스크린리더 실사용 테스트가 필요할 때
보조 기술 사용자를 직접 모집해 사용성 연구를 해야 할 때
법적 분쟁이나 민원 대응처럼 책임 있는 판정이 필요할 때
기관의 조직 구조와 예산 사이클을 이해하고 개선 로드맵을 함께 짜야 할 때
규칙의 회색 지대를 해석하고 조직 내부 설득이 필요할 때

두 국면이 겹치는 영역, 즉 '자동화가 찾아낸 목록을 사람이 검토하고 판단한다'는 Human-in-the-Loop 구도가 많은 전문가들이 권고하는 실질적 답이다.

Human-in-the-Loop — 왜 이 개념이 지금 주목받나

'Human-in-the-Loop(HITL)'은 AI 자동화 워크플로우에서 특정 결정 지점에 사람의 판단을 의무적으로 포함시키는 설계 방식이다. 이게 웹 품질 진단에만 해당하는 이야기가 아니라, AI 규제 논의에서 핵심 개념으로 떠오른 이유가 있다.

EU AI Act(2024년 채택, 2026년부터 핵심 조항 시행)는 '고위험' AI 시스템에 대해 인간의 효과적인 감독을 가능하게 하는 인터페이스를 요구한다(EU AI Act Article 14). 규제가 AI의 완전 자율 판단을 전제하지 않고, 사람이 개입·검토·무효화할 수 있는 구조를 만들라고 요구하는 것이다.

이건 신뢰의 문제이기도 하다. AI가 '이 페이지는 접근성 기준을 위반한다'고 판정할 때, 그 판정이 틀릴 가능성은 얼마나 되는가. 그 틀린 판정을 조직이 그대로 따라가면 어떤 결과가 생기는가. 특히 법적 책임이 걸린 영역에서 AI 판정을 검토 없이 그대로 사용하는 건 위험하다.

RadarFirst의 AI 컴플라이언스 연구는 이렇게 정리한다. "AI가 규칙 기반 작업에는 뛰어나지만, 데이터가 의도와 만나는 모호한 영역에서는 어려움을 겪는다. 그래서 감독은 보편적이 아니라 전략적이어야 한다"(RadarFirst, "Human in the Loop is Essential for AI-Driven Compliance", 2025).

이 '전략적 감독'이 실제로 어떻게 작동하는지를 McKinsey의 2024년 조사가 보여준다. Human-in-the-Loop 시스템을 사용하는 조직은 완전 자율 AI 대비 오류를 42% 줄인 것으로 나타났다(McKinsey survey, 2024 — Strata.io, "Human-in-the-Loop: A 2026 Guide"). 사람이 모든 걸 보는 것도 아니고, AI가 모든 걸 결정하는 것도 아닌, 리스크 수준에 따라 사람의 검토를 배분하는 방식이다.

한국인 분석가가 듀얼 모니터 워크스테이션에서 AI 생성 품질 감사 결과를 검토하며 인쇄된 페이지에 펜으로 메모하는 모습. — AI가 찾아낸 목록을 사람이 검토하고 판단하는 구조 — Human-in-the-Loop의 실제 모습은 이런 장면에 가깝다.

LLM 분석의 한계 — 우리 스스로 솔직하게

ViewCheck를 만드는 입장에서, 우리 자신의 한계를 적어야 이 글이 균형을 갖는다.

LLM이 맥락을 모른다. ViewCheck는 URL을 받아 페이지를 분석한다. 그 페이지가 어떤 민원 흐름의 어느 단계인지, 어떤 사용자 유형이 주로 접근하는지, 기관의 사정상 어떤 부분은 당장 바꾸기 어려운지 — 이런 맥락을 LLM은 알지 못한다. 그래서 LLM 분석이 제안하는 개선 우선순위는, 그 기관의 실제 상황과 맞지 않을 수 있다.

환각(Hallucination)은 현실적 위험이다. AI 판정을 RAG(검색 증강 생성)로 근거에 바탕을 두게 만들어도, 완전히 없앨 수는 없다. ViewCheck는 DOM 기반 규칙 판정 결과를 AI가 함부로 뒤집지 않게 설계하지만(DOM이 통과/미통과로 판정한 건 AI가 번복하지 않음), 여전히 AI가 개입하는 영역에서는 오류 가능성이 있다. 우리는 이걸 솔직하게 말한다.

규칙의 해석에는 한계가 있다. WCAG나 KRDS에는 "적절한"이나 "충분한"이 들어간 기준들이 있다. AI는 이런 기준의 회색 지대에서 자신감 있게 틀릴 수 있다. LLM 분석 결과를 볼 때 이 부분은 전문가의 재검토 영역으로 남겨두는 게 안전하다.

법적 책임 판정에는 적합하지 않다. 기관이 법적 소송이나 민원 대응을 위해 "우리 사이트가 법적 기준을 충족한다"는 증거를 필요로 할 때, 자동화 도구의 분석 결과만으로는 부족하다. 이 경우에는 공인된 접근성 전문 기관의 인증이 필요하다. LLM 분석은 그것을 대체할 수 없다.

동적 인터랙션을 완전히 테스트하지 못한다. 메뉴를 펼쳤을 때, 드롭다운에서 선택했을 때, 모달을 열고 닫을 때 — 이런 동적 상태에서의 접근성은 자동화로 잡기 어렵다. Playwright가 실제 브라우저를 띄우기는 하지만, 모든 인터랙션 시나리오를 자동으로 실행해 보는 건 별도의 E2E 테스트 범주이고, 우리가 지금 그 모든 것을 커버한다고 말할 수 없다.

이 다섯 가지를 적어놓고 보면, ViewCheck LLM 분석이 못 하는 게 많다는 느낌이 든다. 그게 맞다. 그래서 우리는 "이 도구 하나면 충분하다"고 말하지 않는다. 도구의 강점이 실제로 발휘되는 국면에서 쓰고, 도구의 한계 영역에서는 전문가를 불러야 한다. 그게 솔직한 답이다.

LLM 분석이 실제로 가치 있는 국면 — 경험에서 말하는 것들

그렇다면 LLM 분석이 '도움이 된다'는 게 구체적으로 어떤 국면인지를 이야기해 보자. 우리가 분석 과정에서 실제로 경험하고, 의미 있다고 느낀 것들이다.

규모 있는 1차 스크리닝. 수십 개 공공 사이트를 대상으로 "전반적인 상태가 어느 수준인가"를 파악해야 할 때, 컨설턴트를 모두 불러 수동 감사를 맡기는 건 현실적으로 불가능하다. 자동화 분석으로 전체 사이트의 큰 그림을 먼저 파악하고, 문제가 심각해 보이는 사이트에 한해 전문 감사를 의뢰하는 것이 현실적이다.

개선 전후 변화 추적. 컨설팅을 통해 개선 권고를 받고 개발사가 수정 작업을 한 뒤, 그 수정이 실제로 효과가 있는지를 빠르게 확인하는 용도로 자동화는 유용하다. 수정 전 결과와 수정 후 결과를 규칙 단위로 비교할 수 있다.

사이트 전체 규칙 위반 분포 파악. "이 사이트에서 CP 카테고리의 버튼 관련 규칙들이 어떤 페이지에서 어떻게 위반되는가"를 파악할 때, 모든 페이지 데이터를 동일한 기준으로 모아 비교할 수 있다. 이건 수동으로는 정리가 사실상 불가능한 수준의 데이터다.

담당자의 내부 보고 지원. "우리 사이트가 어떤 상태"인지를 상사나 외주 개발사에게 설명해야 할 때, 구체적인 규칙 ID와 근거가 붙은 분석 결과는 막연한 "좀 별로예요"보다 훨씬 강력하다. 컨설팅을 불러 보고서를 받기 전에, 담당자가 스스로 현황을 파악하고 정리하는 데도 유용하다.

규칙에 대한 학습과 이해. 공공 웹 담당자가 KRDS 846규칙을 처음부터 외우거나 이해하기는 어렵다. 자동화 분석 결과가 특정 페이지에서 "DS-044 규칙 위반, 이유는 ~"이라고 알려주면, 담당자는 그 결과를 보면서 실제 사례를 통해 규칙을 익히게 된다. 추상적인 가이드라인보다 "우리 사이트의 이 버튼이 이 규칙에서 이렇게 걸렸다"가 훨씬 빠르게 이해된다.

연구가 말하는 것 — LLM 판정과 사람 판정은 얼마나 일치하나

이쯤에서 학술 연구 쪽 이야기도 해보자. LLM이 접근성 판정에서 사람 전문가와 얼마나 일치하는가, 혹은 일치하지 않는가를 실제로 연구한 사례들이 최근 늘고 있다.

2025년 ACM에서 발표된 연구 "An Assessment of LLM-Based Auditing and Validation for Web Accessibility"는 LLM 기반 접근성 감사의 타당성을 평가했다. 이 연구는 웹 접근성 위반을 분류할 때 인간 평가와 GPT-4o 평가 사이에 완전한 합의가 나타나는 경우가 있다고 보고했다(ACM DL, 2025년 ITfSG 컨퍼런스). 다만 이는 특정 분류 작업에서의 결과이며, 모든 판정 유형에 일반화하기는 이른다.

같은 해 arXiv에 게재된 "Towards Scalable Web Accessibility Audit with MLLMs as Copilots" 연구는 멀티모달 LLM(텍스트+이미지를 함께 처리하는 LLM)을 접근성 감사의 '공동 파일럿'으로 활용하는 방법론을 제안했다. 이 연구는 기존 자동화 접근이 텍스트 의미론적 정렬에만 집중하고 접근성 지식에 대한 복잡한 추론을 다루지 못하는 점을 한계로 지적하며, 멀티모달 추론의 가능성을 탐색했다(arXiv, 2511.03471).

한편 "AccessGuru" 연구(arXiv, 2507.19549)는 GPT-4 기반 시스템이 생성한 접근성 수정 코드와 사람 개발자가 작성한 수정 코드 사이의 유사도를 Sentence-BERT 코사인 유사도로 측정했더니 평균 0.77이 나왔다고 보고했다. 이건 '닮았다'는 수준이지 '동일하다'는 건 아니다. 0.77을 어떻게 해석할지 자체가 또 다른 연구 주제다.

LLM-as-a-Judge(LLM을 평가자로 쓰는 방법론)의 전반적인 한계를 정리한 "A Survey on LLM-as-a-Judge"(arXiv, 2411.15594)는 더 냉정하다. 인간 평가자 간 합의도가 높은 영역에서도 최고 성능의 LLM(GPT-4, Llama-3 70B 수준)이 Scott's Pi 기준 약 0.88의 일치도를 보이지만, 인간 간 차이가 최대 5포인트까지 벌어질 수 있다고 지적한다. 즉, LLM이 사람과 '꽤 잘 맞는다'고 할 수 있지만, '항상 맞다'고는 할 수 없다.

이 연구들이 시사하는 바는 이렇다. LLM은 접근성 판정에서 사람과 의미 있는 수준의 일치도를 보이는 영역이 분명 있고, 그 능력은 계속 향상 중이다. 하지만 '판정 완전 대체'와는 거리가 있고, 특히 맥락 의존적 판단이 필요한 영역에서는 더욱 그렇다. 자동화-사람 협업의 구도가 현 단계에서는 가장 현실적인 접근이라는 것이 학계의 암묵적 합의처럼 보인다.

"LLM이 틀릴 때" — 실제로 어떤 상황이 문제인가

연구 이야기를 넘어 실제 분석에서 마주치는 문제를 이야기해 보자.

ViewCheck 분석 중 가장 판정이 어렵고 오류가 생기기 쉬운 영역을 솔직하게 적으면 이렇다.

SP(서비스 패턴) 규칙. 서비스 패턴 규칙은 "이 페이지가 로그인 페이지인가", "이 페이지에 검색 기능이 있는가" 같은 판단에서 출발한다. 그런데 공공 사이트에는 비표준적인 방식으로 구현된 기능이 많다. 표준 HTML form 태그 없이 자바스크립트로 만든 '검색처럼 보이는' UI, 시각적으로는 탭이지만 코드 구조는 다른 방식으로 만든 컴포넌트 — 이런 경우 DOM만 보고 판정하면 "해당 없음(N/A)"으로 빠지거나 잘못된 판정이 나올 수 있다.

비표준 UI 컴포넌트. KRDS가 정의한 컴포넌트들은 표준적인 HTML/ARIA 구조를 전제한다. 그런데 많은 공공 사이트는 표준 방식을 따르지 않고 구현된 경우가 있다. 이미지로 만든 버튼, canvas로 그린 차트, 외부 스크립트로 삽입된 위젯 — 이런 건 DOM 분석으로는 존재 자체를 파악하기 어렵고, 스크린샷을 봐야 비로소 "아, 이게 있었구나"를 알게 된다.

의미 있는 alt 텍스트 판정. alt 속성이 존재하는지는 DOM으로 알 수 있지만, 그 내용이 의미 있는지는 NLP 수준의 판단이 필요하다. "사진" "이미지" "img" 같은 내용 없는 alt 텍스트를 잡아내는 건 어느 정도 가능하지만, 맥락상 적절한 설명인지 아닌지는 훨씬 어렵다.

다국어·특수 폰트. KRDS는 Pretendard GOV 같은 특정 서체를 권장한다. 실제 페이지에서 어떤 폰트가 렌더링되는지를 판정하는 것은 CSS 분석으로 가능하지만, 외부 폰트가 로딩에 실패한 경우나 이미지로 삽입된 텍스트의 폰트는 자동화가 잡기 어렵다.

이런 어려운 영역들을 어떻게 다루는가가 우리의 연구 과제다. ViewCheck에서는 DOM으로 판정 불가한 영역을 KRDScan(Vision AI)이 스크린샷 분석으로 보완하는 구조를 쓰지만, 그것도 완벽하지 않다. "아직 어렵다"가 정직한 답이다.

실용적 권고 — 어떤 조직이 어떻게 조합해야 하나

지금까지의 이야기를 정리해서, 다양한 상황의 공공기관 담당자에게 실용적인 조합을 제안해 보자. 다만 이 제안은 "이렇게 하면 완벽하다"가 아니라, "이런 고려가 현실적이지 않을까"라는 수준이다. 모든 기관의 상황은 다르다.

예산 제약이 크고 처음 현황 파악이 목표인 경우: 자동화 분석으로 전체 사이트 상태를 먼저 파악한다. 어떤 카테고리에서, 어떤 페이지 유형에서 문제가 집중되는지를 데이터로 확인한다. 이 결과를 근거로 "어느 부분에 전문가 컨설팅이 필요한지"를 판단하는 것이 효율적이다. 전문가 컨설팅 비용을 쓰기 전에 문제 지형도를 먼저 그리는 것이다.

전문 컨설팅을 이미 진행했거나 진행할 계획인 경우: 컨설팅 보고서가 나오고 나면, 그 결과를 개발사에 전달하고 개선이 실행된다. 이후 자동화 분석으로 "개선이 실제로 반영됐는지, 새로운 위반이 생기지 않았는지"를 지속 모니터링하는 것이 자연스러운 결합이다. 컨설팅은 일회성 감사이고, 자동화는 그 이후의 유지 관리 역할을 맡는다.

내부 개발팀이 있고 지속적인 품질 관리가 목표인 경우: 자동화 분석을 배포 파이프라인에 통합하는 것이 이상적이다. 코드가 배포될 때마다 자동으로 분석이 돌고, 이전 결과 대비 회귀(기존에 통과하던 규칙이 깨진 경우)를 알려주는 구조다. 이 구조에서 자동화가 일상적 품질 감시를 하고, 주기적(예: 연 1~2회)으로 전문가 감사가 자동화의 사각지대를 보완한다.

법적 컴플라이언스나 인증이 필요한 경우: 이 경우에는 자동화를 보조 참고 자료로만 쓰고, 반드시 공인된 전문 기관의 감사와 인증 절차를 거쳐야 한다. 자동화 결과를 "법적 근거 자료"로 직접 활용하는 건 현재 단계에서는 권장하지 않는다. 이건 ViewCheck뿐 아니라 어떤 자동화 도구에도 해당하는 이야기다.

한국인 정부 공무원 소규모 팀과 컨설턴트가 회의 테이블에 둘러앉아 노트북 대시보드를 보며 종이에 메모하며 협업하는 모습. — 자동화 데이터를 가운데 두고 사람들이 대화하는 구도 — AI 분석의 가치는 그 자체보다 이 대화를 열어주는 데 있다.

공공 디지털 전환 맥락 속의 이 비교 — OECD와 GOV.UK

잠깐 시야를 넓혀보자. 이 자동화 vs 수동 비교는 한국만의 이슈가 아니다.

OECD는 2024년 한국의 디지털 정부를 심층 검토한 보고서를 발표했다. 이 보고서는 한국이 세계적으로 앞서가는 디지털 정부 기반을 갖추고 있으면서도, 서비스 품질의 일관성 확보와 사용자 중심 설계의 내면화가 과제라는 점을 짚었다(OECD, "Digital Government Review of Korea", 2024). '기반'은 강한데 '경험의 일관성'은 아직 개선 여지가 있다는 진단이다.

이 맥락에서 자동화 품질 진단은 의미가 있다. 수백 개 공공기관 사이트 전체를 사람이 수동으로 점검하는 것은 불가능하지만, 자동화 도구를 통해 '전체적인 상태'를 파악하고 개선 우선순위를 세우는 것은 가능하다.

영국 GOV.UK Design System은 이 문제를 디자인 시스템으로 접근했다. GDS는 2018년 GOV.UK Design System을 공식 도입하며 수백 개 정부 서비스의 화면 일관성과 접근성을 한꺼번에 끌어올리는 전략을 택했다(GDS Blog, "Introducing the GOV.UK Design System", 2018). GOV.UK Design System 공식 사이트는 "모든 컴포넌트와 패턴이 가장 널리 쓰이는 보조 기술로 테스트되고 WCAG AA를 충족하도록 만들어졌다"고 명시한다(design-system.service.gov.uk).

이 방식이 흥미로운 건, 시스템 차원에서 접근성을 '기본값'으로 내장함으로써, 수백 개 개별 서비스가 각자 접근성 컨설팅을 받는 비용 없이도 기본 수준을 확보하는 효율을 얻었다는 점이다. KRDS가 그런 역할을 목표로 만들어진 것과 방향이 같다.

문제는 디자인 시스템을 '채택한다'는 것과 '준수한다'는 것이 다르다는 점이다. 시스템이 제공하는 컴포넌트를 쓰지 않고, 비표준 방식으로 화면을 만들면 디자인 시스템의 효과가 사라진다. 그래서 '준수 여부 검증'이 필요하고, 그게 자동화 분석이 담당할 수 있는 역할이다.

비교의 함정 — "어느 쪽이 더 좋은가"보다 중요한 질문

이 글을 여기까지 읽으면서 '결국 어느 쪽이 더 낫냐'는 결론을 기대한 분이 있을지 모른다. 그런 결론을 내리지 않으려는 이유를 한 번 더 말하자.

NN/g(Nielsen Norman Group)은 2025년 생성형 AI와의 대화 유형을 6가지로 분류한 연구에서, 사용자가 AI와 대화하는 방식과 정보 요구가 상황마다 크게 다르며, 그에 맞는 서로 다른 인터페이스와 접근이 필요하다고 결론지었다(NN/g, "The 6 Types of Conversations with Generative AI", 2025). 이 연구의 교훈은 단일 도구·단일 방식이 모든 상황을 커버할 수 없다는 것이다.

웹 품질 진단도 마찬가지다. "어떤 조직이", "어떤 목적으로", "어떤 단계에서" 진단하느냐에 따라 최적의 접근이 달라진다. '자동화 vs 사람'이라는 이분법보다, "이 상황에서 무엇이 더 적합한가"를 구체적으로 따지는 것이 실용적이다.

또 하나의 함정은 기술적 정확도만으로 비교하는 것이다. 사람 전문가가 더 정확한 판정을 내릴 수 있더라도, 그 전문가를 100개 사이트에 각각 보내는 건 현실적으로 불가능하다. 자동화가 30~40% 커버리지에 그치더라도, 그 커버리지를 100개 사이트 전체에 적용할 수 있다면 총 발견 오류 수는 수동 감사의 일부 샘플링보다 많을 수 있다. 정확도와 커버리지, 두 축을 함께 고려해야 한다.

ViewCheck가 AI에게 맡기지 않는 것들

ViewCheck 안에서 우리가 설계 차원에서 "이건 AI에게 맡기지 않겠다"고 정한 것들이 있다. 이걸 공개하는 게 이 비교를 구체화하는 데 도움이 될 것 같다.

DOM이 판정한 것은 AI가 번복하지 않는다. KRDSrule 엔진이 DOM 데이터를 기반으로 "이 규칙은 통과"나 "이 규칙은 미통과"로 판정하면, KRDScan Vision AI는 그 판정을 뒤집지 않는다. AI는 DOM이 "해당없음(N/A)"으로 남긴 영역, 즉 DOM만으로 판정할 수 없는 영역만 독자적으로 채운다. 이 충돌 방지 원칙이 없으면, AI가 DOM의 명확한 판정을 교란할 수 있다.

근거 없는 판정은 내리지 않는다. AI 판정에는 반드시 RAG(Retrieval-Augmented Generation)로 검색한 KRDS 규칙 원문이나 공식 문서가 근거로 붙는다. "AI가 그렇게 판단했다"가 아니라 "이 규칙의 이 항목에 따르면"이라는 형식으로. 근거를 댈 수 없는 판정은 내리지 않는 것이 원칙이다.

최종 판단은 사용자에게 있다. ViewCheck 분석 결과는 "이렇게 수정하세요"라는 명령이 아니라 "이 부분이 이 기준에서 미통과로 판정됐으니 검토해 보세요"라는 형식이다. 그게 진짜인지 아닌지, 개선을 어떻게 할지는 사람이 결정한다. 이 구도를 바꾸려 하지 않는다.

자동화가 가져오는 변화 — 전문가의 역할이 어떻게 바뀌는가

'AI 자동화가 전문가를 대체하는가'라는 질문에 지금까지 "아니다"라고 답했는데, 그렇다고 아무것도 변하지 않는다는 건 아니다.

자동화가 접근성 감사 분야에서 가져오는 변화 중 하나는, 전문가가 집중해야 하는 작업의 성격이 달라진다는 것이다. 모든 페이지를 처음부터 수동으로 훑는 초기 스크리닝 작업은 자동화가 가져갈 수 있다. 전문가는 자동화가 찾아낸 목록 중 "이게 진짜 문제인지 아닌지"를 판단하는 2차 검토, 자동화가 못 잡는 맥락 의존적 영역에 집중, 그리고 조직이 개선을 실행하도록 설득하는 역할에 더 많은 시간을 쓸 수 있다.

이건 접근성 컨설팅만의 이야기가 아니다. 반복적이고 규칙 기반인 작업은 자동화로 넘어가고, 전문가의 판단력이 필요한 부분에 인간의 시간이 집중된다는 패턴은 많은 전문직에서 비슷하게 나타나고 있다.

IT·금융 감사 분야에서도 유사한 변화가 관찰된다. PMC(PubMed Central)에 게재된 연구 "Enhancing audit quality and reducing costs: the impact of AI in banking and financial services"는 AI가 감사 과정에서 데이터 수집과 패턴 인식을 가속화하고, 감사인이 예외 케이스와 해석에 집중할 수 있게 만든다고 분석했다(PMC 12876229). 자동화가 감사를 없애는 게 아니라, 감사 내에서의 역할 분배를 바꾸는 것이다.

담당자 입장에서 생각하기 — 실질적인 진입 지점

지금까지의 이야기를 좀 더 구체적인 담당자 상황으로 가져오자.

공공기관 홈페이지 담당 실무자가 "우리 사이트 품질 점검을 해야 하는데, 어디서 시작하지?"라는 상황이라면, 다음 순서가 현실적이다.

1단계: 현황 파악 (자동화 활용) 전문 컨설팅을 부르기 전에 먼저 자동화 분석으로 전체 사이트의 대략적인 상태를 파악한다. 어느 카테고리에서 문제가 많은지, 어떤 페이지 유형에서 집중되는지를 데이터로 확인한다. 이 단계에서 얻는 건 '완벽한 점검 결과'가 아니라 '어디에 자원을 집중해야 하는지에 대한 지형도'다.

2단계: 우선순위 결정 (사람 판단) 1단계 결과를 바탕으로, 담당자는 "이 중에서 무엇이 우리 기관 사용자에게 진짜 문제인가"를 판단한다. 자동화 분석 결과와 담당자가 아는 기관 맥락(어떤 사용자가, 어떤 목적으로 어떤 페이지를 주로 사용하는지)을 결합한다.

3단계: 전문 감사 (필요한 영역에 한해) 2단계에서 "이건 자동화 판정만으로는 확신이 안 된다" 또는 "스크린리더 테스트가 필요하다"고 판단한 영역에 한해 전문 컨설팅을 의뢰한다. 전체 사이트를 무조건 맡기는 것보다 범위를 좁혀 의뢰하면 비용을 줄이고 집중도를 높일 수 있다.

4단계: 개선 실행 후 재점검 (자동화 활용) 개발사가 개선을 완료하면, 자동화 분석으로 개선이 실제로 반영됐는지를 확인한다. 이 과정을 배포 때마다 반복하면, 큰 비용 없이 품질 유지 모니터링이 가능해진다.

이 4단계가 이상적인 것처럼 써놨지만, 현실에서는 1단계도 제대로 하지 못하는 기관이 대부분이다. 이유는 담당자 공수와 예산의 문제가 아니라, "무엇부터 해야 하는지 모른다"는 정보의 문제인 경우가 많다. 자동화 분석이 그 첫 발걸음을 낮추는 데 도움이 될 수 있다고 생각한다.

"어렵다"를 인정하는 것의 가치

이 글을 통해 하고 싶은 말 중 하나가 이것이다. AI 자동 분석이든 사람 전문가든, "이건 어렵다"를 솔직하게 말하는 것이 신뢰의 출발이다.

"우리 도구가 모든 WCAG 위반을 잡아냅니다"라고 말하는 도구를 보면 의심해야 한다. 자동화 도구가 30~40% 커버리지에 그친다는 건 업계가 10년 이상 반복 확인한 사실이다. 그 한계를 말하지 않으면 사용자가 잘못된 기대를 갖고, 자동화 결과를 맹신해서 진짜 문제를 놓친다.

마찬가지로 "우리 컨설팅이면 완벽하게 해결됩니다"라는 말도 조심해야 한다. 전문가의 수동 감사도 샘플링을 전제하고, 동적 환경에서의 변화나 이후 개선 유지는 감사 범위 밖이다.

두 접근 모두 강점과 한계가 있다. 그 한계를 서로 보완하는 구도가 현재로서는 가장 현실적이다. 그 구도를 설계하는 사람은 담당자 자신이고, 그 설계를 도구가 대신해줄 수는 없다.

ViewCheck LLM 분석이 제공하려는 건 "담당자가 그 설계를 하는 데 필요한 데이터와 근거"다. 많은 담당자들이 "우리 사이트 품질이 어때요?"라는 막연한 질문을 갖고 있다. 자동화 분석이 그 질문에 구체적인 첫 답을 준다면, 그다음 판단은 담당자가 할 수 있다.

미래 방향 — 인간-AI 협업이 어디로 가는가

마지막으로, 이 비교가 앞으로 어떻게 달라질지 짧게 이야기하자.

자동화 도구의 WCAG 커버리지는 계속 올라가고 있다. MLLMs(멀티모달 LLM)의 발전으로 텍스트 기반 분석 한계를 넘어 시각적 판단 영역도 점점 커버되고 있다(arXiv, "Towards Scalable Web Accessibility Audit with MLLMs as Copilots", 2025). 오늘의 30~40%가 몇 년 뒤에는 더 높아질 것이다.

그렇다고 사람 전문가의 역할이 줄어드는 게 아니라, 변화할 것이다. 자동화가 더 많은 영역을 커버할수록, 전문가는 자동화의 사각지대와 회색 지대에 더 집중한다. 전문가의 작업이 줄어드는 게 아니라, 더 어려운 부분으로 이동한다.

EU AI Act의 시행(2026년 8월 2일 주요 조항 발효)은 고위험 AI 시스템에서 인간 감독을 의무화한다. 이 방향은 "AI가 더 강해질수록 인간의 역할이 자동으로 줄어든다"는 단순한 서사보다 복잡하다. AI가 강해질수록, 그 AI를 적절히 감독하고 사용하는 사람의 역할도 더 중요해진다.

ViewCheck가 그리는 그림도 그 방향이다. AI가 더 많은 규칙을 더 정확하게 판정할수록, 담당자가 그 결과를 읽고 판단하고 실행하는 역량이 더 중요해진다. 도구가 강해질수록 사용자의 판단력이 더 필요해지는 구도다.

밝은 오픈 오피스에서 한국인 전문가가 큰 화면의 AI 대시보드 앞에서 표시된 문제들을 바라보며 생각에 잠긴 모습. — AI 대시보드가 찾아낸 것을 앞에 두고, 어떻게 판단할지를 고민하는 사람. 그 순간이 Human-in-the-Loop의 핵심이다.

이 시리즈에서 다룬 것들과 이 편의 위치

G 트랙은 ViewCheck LLM 분석의 '활용'을 다룬다. 38편인 이 글은 그 활용의 맥락을 현실적으로 짚는 편이다. 가장 많이 받는 질문 중 하나가 "그래서 AI 분석이 사람 컨설턴트보다 낫냐"이고, 그 질문에 단순한 답을 주는 대신 두 접근의 강점·약점·적합한 국면을 정직하게 비교했다.

이전 편들(트랙 A·B·C·D·E·F)에서 ViewCheck의 개별 기능과 기술적 접근을 다뤘다면, 이 편은 그것들이 실제 현장에서 어떤 위치에 놓이는지를 이야기한다. "이게 좋습니다"보다 "이게 잘 맞는 상황은 이렇고, 맞지 않는 상황은 이렇습니다"가 더 솔직하고 실용적인 정보라고 판단했다.

다음 편에서는 ViewCheck LLM 분석의 또 다른 활용 방향을 이어간다. 지금 이 편에서 비교의 축을 세웠다면, 다음 편에서는 그 축 위에서 실제 활용 시나리오를 더 구체적으로 다룰 예정이다.

마무리 — 경쟁 구도가 아니라 협력 구도

결론을 하나로 모으면 이렇다.

사람 전문가의 수동 컨설팅과 AI 자동 분석은 경쟁하는 것이 아니라 협력한다. 각자 잘하는 영역이 명확히 다르고, 그 차이를 인정하는 것에서 좋은 활용이 시작된다.

자동화는 규모, 속도, 일관성, 반복에서 사람보다 앞선다. 사람은 맥락, 판단, 경험, 조직 감각, 실제 사용 체험에서 자동화보다 앞선다. 둘 다를 갖추기 어려운 현실에서, 각 조직이 자원을 어디에 배분하느냐는 현황 파악부터 시작한다.

ViewCheck LLM 분석이 제공하는 건 그 현황 파악의 출발점이다. "우리 사이트가 어떤 상태인지, 어디에 문제가 집중되는지"를 빠르게 데이터로 보는 것. 그 데이터를 바탕으로 담당자가 어디에 전문가를 부를지, 어디에 자원을 집중할지를 판단한다. 판단은 사람이 한다.

우리가 도구를 만드는 이유는 그 판단을 돕기 위해서다. 판단을 대신하기 위해서가 아니라.

공공 웹 품질 개선의 궁극적 목적은 결국 그 웹사이트를 쓰는 시민들의 경험이다. 담당자도, 전문가도, AI 도구도, 그 목적을 향해 각자의 방식으로 기여한다. 어느 하나가 '승자'가 되는 이야기가 아니다.

공공 도서관 컴퓨터에서 한국인 시민이 정부 웹사이트를 편안하게 사용하는 넓은 장면. — 모든 진단의 목적지는 이 장면이다 — 시민이 공공 웹사이트를 불편 없이 쓰는 것. 도구든 컨설턴트든 그 목적 앞에서는 수단이다.

참고문헌

본문에 인용한 출처는 작성 시점에 실재 여부를 검증했다. 가짜 출처·없는 인용은 사용하지 않았다. 확인 못 한 수치는 포함하지 않았다.

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

행정안전부, 「전자정부 웹사이트 품질관리 지침」(행정안전부고시 제2025-46호, 2025. 6. 25. 일부개정). 국가법령정보센터. https://www.law.go.kr/행정규칙/전자정부웹사이트품질관리지침
행정안전부, 「전자정부 웹사이트 품질관리 지침」 일부개정 알림. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000016&nttId=118636
KRDS(범정부 UI/UX 디자인시스템) 공식 사이트. 행정안전부·디지털플랫폼정부위원회. https://www.krds.go.kr/
행정안전부, 「2022년 공공웹사이트 품질관리 수준진단 가이드」. https://www.mois.go.kr/frt/bbs/type001/commonSelectBoardArticle.do?bbsId=BBSMSTR_000000000045&nttId=93478

해외 — 디자인 시스템 / UX 연구 / 비용 분석

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/
GOV.UK Design System(공식). Government Digital Service. https://design-system.service.gov.uk/
OECD, "Digital Government Review of Korea", 2024. https://www.oecd.org/en/publications/digital-government-review-of-korea_9defc197-en.html
Nielsen Norman Group, "The 6 Types of Conversations with Generative AI", 2025. https://www.nngroup.com/articles/AI-conversation-types/

자동화 vs 수동 접근성 감사 관련

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/
WebAIM, "WebAIM Million" — 2025 리포트(100만 홈페이지 접근성 분석). https://webaim.org/services/evaluation/
Accessible.org, "Breaking Down the Cost of a Website Accessibility Audit". https://accessible.org/cost-website-accessibility-audit/
AccessiblePixels, "Website Accessibility Audit Cost UK – 2026 Pricing Guide". https://www.accessiblepixels.com/post/how-much-does-a-website-accessibility-audit-cost-in-the-uk
TestParty, "How Much Does WCAG Compliance Cost? Automated vs. Manual". https://testparty.ai/blog/wcag-compliance-cost-automated-vs-manual-audits

LLM 감사 및 Human-in-the-Loop 연구

Brajnik G. et al., "An Assessment of LLM-Based Auditing and Validation for Web Accessibility", Proceedings of the 2025 International Conference on Information Technology for Social Good (ITfSG 2025). ACM DL. https://dl.acm.org/doi/10.1145/3748699.3749805
Guo et al., "Towards Scalable Web Accessibility Audit with MLLMs as Copilots", arXiv:2511.03471, 2025. https://arxiv.org/html/2511.03471v1
"AccessGuru: Leveraging LLMs to Detect and Correct Web Accessibility Violations in HTML Code", arXiv:2507.19549, 2025. https://arxiv.org/html/2507.19549v1
"A Survey on LLM-as-a-Judge", arXiv:2411.15594, 2024. https://arxiv.org/pdf/2411.15594
RadarFirst, "Human in the Loop is Essential for AI-Driven Compliance". https://www.radarfirst.com/blog/why-a-human-in-the-loop-is-essential-for-ai-driven-privacy-compliance/
Strata.io, "Human-in-the-Loop: A 2026 Guide to AI Oversight". https://www.strata.io/blog/agentic-identity/practicing-the-human-in-the-loop/
PMC, "Enhancing audit quality and reducing costs: the impact of AI in banking and financial services", PMC Article 12876229. https://pmc.ncbi.nlm.nih.gov/articles/PMC12876229/