자동화된 접근성 스캐너가 문제의 30%만 잡아내는 이유 (그리고 그에 대한 대처 방법)

자동화된 접근성 스캔을 실행하고, 대시보드가 초록색으로 돌아오면 안도의 한숨을 내쉰다. 하지만 불편한 진실이 있다. 그 깔끔한 보고서가 실제로는 사이트의 진짜 접근성 장벽 대부분을 숨기고 있을 수 있다는 점이다. 연구와 독립적인 조사에 따르면, 자동화 스캐너는 실제 WCAG 위반 사항의 약 30%에서 57%만을 탐지하는 것으로 일관되게 나타난다. 이는 곧, 장애가 있는 사용자가 매일 마주치는 문제의 절반에서 3분의 2는 대부분의 팀이 의존하는 도구로는 완전히 보이지 않는다는 뜻이다.

자동화된 접근성 테스트의 현주소

자동화된 접근성 테스트는 폭발적으로 인기를 얻고 있으며, 그럴 만한 이유가 있다. 더 많은 팀이 접근성 이슈를 선별하기 위해 자동화를 활용하고 있다. 2024년 한 설문조사에서 응답자의 50%가 잠재적인 문제를 식별하기 위해 자동화된 접근성 도구를 사용한다고 답했는데, 이는 2023년의 40%에서 증가한 수치다. 매력은 분명하다. 스캐너는 빠르고, 비교적 저렴하며, CI/CD 파이프라인에 직접 통합할 수 있다. 누락된 alt 속성, 레이블이 없는 폼 입력, 비어 있는 접근 가능한 이름을 가진 버튼처럼, 명확하고 반복 가능하며 규칙 기반인 위반 사항을 대규모로 잡아낸다.

하지만 커버리지 상한선은 어떤 스캐너 벤더도 뚫지 못한 고질적인 문제다. Deque에 따르면, "평균적으로 WCAG 이슈의 57%를 자동으로 찾을 수 있다"고 하며, 그마저도 도구는 수동 검토가 필요한 구성 요소를 불완전한 상태로 반환한다. 이 57%라는 수치는, 실용적이고 현실적인 측정 방법론을 사용해 시장에서 가장 성숙하고 널리 신뢰받는 접근성 엔진 중 하나가 달성한, 스펙트럼의 낙관적인 끝단을 나타낸다. 다른 추정치는 상당히 낮다. 자동화 도구는 WCAG 위반의 약 30–40%를 포착하며, 나머지 60–70%는 수동 테스트가 필요하다.

30%와 57%의 차이는 분모를 어떻게 정의하느냐에 달려 있다. Deque는 이 57%라는 수치를 이론적인 접근이 아니라 실용적이고 현실적인 접근을 통해 도출했다. 많은 사이트를 샘플링하고, 실제로 문서화된 접근성 결함 중 얼마나 많은 것이 axe-core를 사용해 탐지될 수 있었는지를 측정한 것이다. 연구자들이 대신 모든 WCAG 성공 기준을 하나의 이론적 집합으로 보고 커버리지를 측정하면, 숫자는 급격히 떨어진다. 이 글을 쓰는 시점 기준으로, WCAG 2.2 A 및 AA 레벨에 대해 승인된 자동화 테스트 규칙만 필터링하면, 55개 성공 기준 중 단 17개에 대해서만 부분 또는 전체 커버리지가 있는 것으로 나타난다. 어느 쪽으로 보더라도, 자동화 테스트는 상당한 — 그리고 법적으로 위험한 — 공백을 남긴다.

문제는 이 공백을 외부에서 파악하기가 매우 어렵다는 점으로 인해 더욱 심각해진다. 통과한 스캔은 안전하다는 신호를 적극적으로 보내며, 바로 그때 팀은 가장 쉽게 검토를 멈춘다. 대시보드는 초록색이다. 배포는 진행된다. 실제 장애가 있는 사용자는 실제 장벽에 부딪힌다.

스캐너가 실제로 잘하는 일

커버리지 격차를 파고들기 전에, 자동화 도구가 진정으로 잘하는 일이 무엇인지 분명히 해둘 가치가 있다. 이 도구들은 DOM을 읽는 것만으로 판단할 수 있는 항목을 빠르고, 일관되며, 지치지 않고 검사한다. 접근성 자동화는 누락된 대체 텍스트, 비어 있는 링크, 부적절한 폼 레이블, 낮은 색 대비 비율과 같은 일반적인 WCAG 위반을 신뢰성 있게 포착할 수 있다. 이는 구조적이고 이진적인 검사다. 속성이 있거나 없거나, 대비 비율이 4.5:1을 통과하거나 실패하거나 둘 중 하나다.

매년 상위 백만 개 홈페이지를 분석하는 WebAIM Million 보고서는, 이렇게 탐지 가능한 오류가 얼마나 널리 퍼져 있는지 생생하게 보여준다. 95.9%의 홈페이지에서 WCAG 2 실패가 탐지되었다. 가장 흔한 여섯 가지 범주 — 낮은 대비 텍스트, 누락된 대체 텍스트, 누락된 폼 레이블, 비어 있는 링크, 비어 있는 버튼, 누락된 문서 언어 — 는 탐지된 모든 오류의 96%를 차지하며, 이 가장 흔한 오류들은 지난 7년 동안 변하지 않았다. 자동화 도구는 이러한 고빈도·저복잡도 위반 사항을 대규모로 드러내는 데 실제로 도움이 된다. 문제는 이 이슈들만 고쳐서는 사이트의 실제 장벽 대부분이 여전히 그대로 남는다는 점이다.

왜 격차가 존재하는가: 스캐너가 평가할 수 없는 것들

커버리지 상한선은 엔지니어링의 실패가 아니라, 인간의 판단 없이 기계가 평가할 수 있는 것의 근본적인 한계다. 이 격차는 기계가 맥락, 사용자 의도, 제목 계층 구조가 의미가 있는지, 대체 텍스트가 정확한지와 같은 주관적인 문제를 이해할 수 없기 때문에 존재한다. 스캐너는 이미지에 alt 속성이 있는지 확인할 수 있다. 하지만 그 속성이 "photo-123-final-v2.jpg"라고 적혀 있는지, 실제로 유용한 설명인지 구분할 수 없다. 도구는 이미지에 대체 텍스트가 있다는 사실을 표시할 수 있지만, 그 텍스트가 실제로 이미지를 잘 설명하는지는 사람만 판단할 수 있다.

다음은 자동화 탐지를 꾸준히 피해 가는 주요 이슈 범주들이다.

• 스크린 리더 경험: 자동화 도구는 스크린 리더가 콘텐츠를 어떻게 읽어주는지 들을 수 없다. ARIA 속성의 유효성은 검사할 수 있지만, 그 결과로 나오는 안내가 사용자에게 의미가 있는지는 판단할 수 없다. 폼 필드에 기술적으로 유효한 aria-label이 있을 수 있지만, 실제 NVDA나 JAWS 사용자에게는 혼란스러운 문자열로 읽힐 수 있다.
• 논리적인 읽기 및 포커스 순서: 실제로는, 시각적으로는 완벽히 자연스럽게 보이는 정보라도 스크린 리더 사용자가 접근할 때 읽기 순서가 전혀 말이 안 되는 경우가 자주 있다. 컬럼 레이아웃에서는 스크린 리더가 1열의 첫 줄을 읽고, 그다음 2열을 읽어 혼란을 야기한다. 스캐너는 DOM 순서를 맥락 없이 분석하며, 시각적 레이아웃이 시각 사용자에게 그 순서를 어떻게 변형하는지는 고려하지 않는다.
• 맥락 속에서 의미 있는 링크 및 버튼 텍스트: 자동화 도구는 링크가 존재하는지, 텍스트를 포함하는지 확인할 수 있지만, 그 링크의 목적이 명확한지는 항상 판단할 수 없다. 같은 페이지에 "자세히 보기" 링크가 다섯 개 있어도 자동화 검사에서는 모두 통과하지만, 각각이 어디로 이어지는지 이해해야 하는 실제 사용자에게는 모두 실패다.
• 동적 콘텐츠와 라이브 영역: 자동화 도구는 동적으로 로드되는 콘텐츠의 문제를 포착할 수 없다. 동적 업데이트가 추가된 후 다시 테스트를 실행해야 한다. 하지만 그마저도, 스크린 리더가 그것을 읽을지 여부는 도구가 말해줄 수 없다.
• 인지적 접근성과 쉬운 언어: 자동화는 제목 순서나 레이블 존재 여부 같은 구조적 이슈는 탐지할 수 있지만, 가독성, 명료성, 지침이 따라가기 쉬운지 여부는 평가할 수 없다. 복잡한 다단계 결제 과정에 혼란스러운 오류 메시지가 있으면, 구조적으로는 "깨끗해" 보이더라도 인지적 장애가 있는 사용자에게는 심각하게 접근 불가능할 수 있다.
• 복잡한 상호작용에서의 키보드 내비게이션: 자동화는 기본적인 키보드 포커스와 조작 가능성은 테스트할 수 있지만, 복잡한 다단계 상호작용, 커스텀 제스처, 대체 입력 장치까지 완전히 검증할 수는 없다. 커스텀 날짜 선택 위젯은 이론상 키보드로 완전히 조작 가능할 수 있지만, 실제로는 완전한 함정이 될 수 있다.
• 겹치는 시각 요소와 그라디언트 대비: 자동화 도구는 대비 비율을 평가할 수 있지만, 겹치는 요소, 텍스트 뒤의 이미지, 가독성을 방해하는 동적으로 변하는 콘텐츠까지 항상 고려하지는 않는다.

깔끔한 자동화 스캔 결과는 자동화로 포착 가능한 30–40%의 이슈를 해결했다는 뜻이다. 나머지 60–70%는 테스트되지 않은 상태다. 자동화 테스트만으로 WCAG 준수를 주장해서는 안 된다.

특히 눈에 띄는 증거가 하나 있다. 영국의 정부 접근성 옹호자들이 의도적으로 142개의 접근성 장벽을 가진 웹페이지를 만든 뒤, 13개의 자동화 접근성 도구로 이 페이지를 분석한 연구가 있다. 성능이 가장 좋았던 도구조차 장벽의 40%만 식별할 수 있었고, 가장 성능이 낮았던 도구는 겨우 13%만 찾아냈다. 알려진, 문서화된 이슈가 있는 통제된 페이지를 사용해 도구에 유리한 환경을 조성했음에도 결과는 냉정했다. 그리고 도구를 여러 개 조합해도 문제는 완전히 해결되지 않는다. 여섯 개의 도구를 병렬로 사용하더라도, WCAG 2 성공 기준의 절반은 커버되지 않고, 위반 사항 10개 중 6개는 놓친다.

자동화에 과도하게 의존하는 것의 법적 위험

이는 단지 사용자 경험에 대한 이론적인 우려가 아니다. 접근성 미준수에 대한 법적 위험은 급격히 높아지고 있으며, 자동화 스캔 통과는 소송에서 거의 아무런 보호도 제공하지 못한다. 2024년에는 웹사이트나 모바일 접근성 장벽을 주장하는 소송이 미국 법원에 4,000건 이상 제기되었다. 2025년 상반기에만 ADA 웹사이트 소송이 2,014건 제기되었는데, 이는 2024년 대비 37% 증가한 수치다.

법정 밖 합의금은 평균 $30,000, 법원 판결은 평균 $85,000 수준이며, 여기에 방어 측 변호사 비용 $30,000–$175,000가 모든 사례에 추가된다. 더 나쁜 점은, 한 번 합의했다고 해서 안전이 보장되는 것도 아니라는 것이다. 2025년 연방 디지털 접근성 소송의 45–46%는 이미 한 번 이상 소송을 당한 기업을 다시 겨냥했다. 소송을 당한 뒤 자동화 도구가 표시한 것만 땜질하고, 더 넓은 구조적 격차를 해결하지 않으면, 다음 원고에게 표적이 될 뿐이다.

접근성 위젯과 오버레이를 준수의 지름길로 보는 흔한 오해도 짚고 넘어갈 가치가 있다. 2025년 데이터에 따르면, 456건의 ADA 소송이 접근성 위젯을 설치한 웹사이트를 대상으로 제기되었으며, 이는 전체 소송의 22.64%를 차지한다. 이는 단순히 접근성 위젯을 추가하는 것만으로는 포괄적인 해결책이 될 수 없음을 보여준다. 자동화 도구는 WCAG 이슈의 30%만 탐지할 수 있다. 즉, 순수하게 자동 탐지에만 의존하는 어떤 도구나 위젯도, 정의상 대다수의 이슈를 방치하게 된다. Accsible과 같이 진정으로 가치 있는 접근성 SDK를, 법적·규제적 반발을 겪어온 오버레이 제품과 구분 짓는 것은, 자동화된 수정 기능과 더불어 거짓된 보장이 아닌 정직하고 다층적인 준수 전략에 대한 약속이다.

실제로 효과가 있는 다층 테스트 전략

커버리지 격차에 대한 해답은 자동화 스캐너를 버리는 것이 아니라, 그것을 올바르게 사용하는 것이다. 즉, 포괄적인 전략의 마지막 단계가 아니라 첫 번째 층으로 사용하는 것이다. 86개의 WCAG 2.2 성공 기준 중 70%는, 자동화 접근성 기술의 범위를 넘어서는 회색 지대에 기준을 해석하고 적용하기 위해 인간의 검토가 필요하다. 이는 인간의 판단이 선택 사항이 아니라, 표준 자체에 의해 구조적으로 요구된다는 뜻이다.

견고한 접근성 테스트 프로그램은 일반적으로 세 개의 층으로 작동한다.

1. 자동화 스캐닝(지속적): axe-core 같은 스캐너를 CI/CD 파이프라인에 통합해 모든 빌드마다 실행한다. 구조적이고 이진적인 위반 사항을 프로덕션에 도달하기 전에 잡는다. 임계값을 설정하고, 새로운 치명적 위반이 발생하면 빌드를 실패하게 한다. 이것이 명백한 이슈를 위한 안전망이다. 빠르고, 확장 가능하며, 비용이 적게 든다. 개발 초기에, 그리고 자주 자동화 도구를 실행하라. axe나 WAVE를 CI/CD 파이프라인에 통합해, 이슈가 QA에 도달하기 전에 포착되도록 하라. 이는 접근성 테스트를 왼쪽으로 이동시켜, 가장 저렴한 시점에 문제를 잡게 한다.
2. 전문가 수동 감사(주기적): 깊은 접근성 지식을 가진 사람이 전체 WCAG 체크리스트를 기준으로 구조화된 수동 감사를 수행한다. 수동 접근성 테스트는 스크린 리더, 키보드 내비게이션, 확대 소프트웨어 같은 보조 기술을 실제로 사용하는 훈련된 전문가가 수행한다. 이들은 논리적인 포커스 순서와 직관적인 내비게이션 감각, 폼과 오류 메시지의 명료성, 복잡한 콘텐츠 내의 가독성 등 맥락과 사용자 경험을 평가한다. 수동 감사는 일반적으로 분기별로, 또는 주요 기능이 출시될 때 수행되며, 트래픽이 가장 많은 사용자 여정을 엔드 투 엔드로 다뤄야 한다. 완전 수동과 완전 자동 사이에 위치한 가이드형 수동 접근성 감사는 커버리지 격차를 좁히며, 이 접근법으로 커버리지가 최대 80%에 달한다는 추정도 있다.
3. 보조 기술 및 사용자 테스트(지속적): 사이트의 접근성 문제를 파악하는 데 자동화 도구만을 의존할 수는 없다. 모든 웹사이트 프로젝트에는 사용자 테스트 전략이 필요하며, 스크린 리더 사용자, 키보드만 사용하는 사용자, 청각 장애 사용자, 이동 장애 사용자 등 접근성 사용자 그룹을 포함하는 것이 강력히 권장된다. 실제 장애가 있는 사용자는 어떤 체크리스트도 예상하지 못한 이슈를 발견한다. Windows에서는 NVDA와 JAWS, macOS와 iOS에서는 VoiceOver, Android에서는 TalkBack으로 테스트하라. 키보드만 사용해 전체 결제 또는 가입 흐름을 탐색해 보라. 콘텐츠가 소리 내어 읽힐 때 어떻게 들리는지 실제로 들어보라.

팀이 이 세 층을 모두 구현하면, 결합된 커버리지는 실제 이슈의 80–90%에 근접할 수 있다. 이는 자동화만으로는 30–57%에 그치는 것과 비교해 극적인 개선이다. 목표는 첫날부터 완벽해지는 것이 아니라, 진정한 성의 있는 노력을 보여주고 격차를 지속적으로 줄여 나가는 체계적이고 문서화된 프로세스를 갖추는 것이다.

개발 워크플로에 접근성을 통합하기

가장 중요한 문화적 전환은 접근성을 출시 전 체크리스트에서 지속적인 실천으로 옮기는 것이다. 많은 조직이 접근성을, 소송이 두려워졌을 때 한 번 의뢰하는 일회성 감사로 취급하는 실수를 저지른다. 하지만 감사가 프로덕션 시스템의 문제를 드러낼 때쯤이면, 그것을 고치는 비용은 설계 단계에서 고쳤을 때보다 5~10배 더 든다.

우선 접근성 기준을 완료 정의의 일부로 만드는 것부터 시작하라. 개발자가 새 컴포넌트를 배포할 때, 간단한 자동화 검사가 자동으로 실행되어야 한다. 디자이너가 새로운 패턴을 만들 때는, 디자인이 전달되기 전부터 색 대비와 포커스 상태를 검토해야 한다. 콘텐츠 편집자가 새 이미지를 추가할 때는, 단지 대체 텍스트가 필요하다는 사실이 아니라, 의미 있는 대체 텍스트가 어떤 모습인지 명확히 이해하고 있어야 한다.

컴플라이언스 담당자에게 실질적인 함의는 문서화다. 일부 팀은 자동화 테스트를 실행하지만, 결과를 전혀 처리하지 않는다. 이는 아무런 가치를 제공하지 못할 뿐 아니라, 문제를 알고도 고치지 않았다는 문서를 남겨 법적 상황에서 문제가 된다. 접근성 프로그램은, 정기적인 스캔, 문서화된 발견 사항, 개선 로드맵, 그리고 배운 것을 실제로 실행하고 있다는 증거를 통해 합리적이고 성의 있는 지속적 개선 프로세스를 보여줄 수 있을 때에만 방어 가능하다. WCAG 준수는 한 번 달성하고 끝나는 이진적인 상태가 아니라, 지속적으로 유지해야 하는 태도다.

Accsible 같은 도구는 이런 다층 접근을 지원하기 위해 존재한다. 접근성 개선을 사용자 경험에 직접 내장하는 SDK를 제공하고, 실시간 이슈를 표면화하며, 수동 감사 프로세스를 대체하려 하기보다는 보완한다. 올바른 오버레이나 SDK는 소송에 대한 마법 방패가 아니라, 자동화가 할 수 있는 것과 할 수 없는 것을 인정하는 신중한 프로그램의 한 구성 요소다.

핵심 요약

• 자동화 스캐너는 출발점이지, 결승선이 아니다. 최고의 도구조차 실제 WCAG 위반의 30%에서 57%만 탐지한다. 깔끔한 스캔 보고서는 사이트가 접근 가능하다는 뜻이 아니라, 탐지 가능한 하위 집합의 이슈가 해결되었다는 뜻이다.
• 대부분의 WCAG 성공 기준은 인간의 판단을 요구한다. 스크린 리더 경험, 논리적인 읽기 순서, 맥락 속에서 의미 있는 링크 텍스트, 인지적 명료성, 복잡한 키보드 상호작용은 모두 자동화가 구조적으로 신뢰할 만한 답을 줄 수 없는 영역이다.
• 법적 환경은 안일함에 적대적이다. 2025년에만 5,100건이 넘는 연방 ADA 웹사이트 소송이 제기되었고, 합의금은 통상 $30,000–$85,000에 방어 비용이 추가된다. 피고의 거의 절반은 이미 한 번 소송을 당한 적이 있어, 피상적인 수정만으로는 충분하지 않음을 시사한다.
• 자동화 스캐닝, 전문가 수동 감사, 실제 보조 기술 테스트라는 3층 전략은 커버리지를 80–90% 수준까지 끌어올릴 수 있으며, 법원과 규제 기관이 기대하는 문서화된 성의 있는 준수 태도를 제공한다.
• 접근성을 왼쪽으로 이동시켜라. 설계 및 개발 단계에서 이슈를 잡는 비용은 출시 후 수정 비용의 일부에 불과하다. 자동화 검사를 CI/CD에 통합하고, 접근성을 완료 정의의 일부로 만들며, 트래픽이 가장 많은 사용자 여정에 대해 정기적으로 수동 감사를 수행하라.