접근성 테스트에서 해석 격차 해소하기: 대규모 언어 모델을 통한 공감적이고 법을 인지하는 버그 리포트 생성
Bridging the Interpretation Gap in Accessibility Testing: Empathetic and Legal-Aware Bug Report Generation via Large Language Models
배경 및 소개
모바일 앱은 금융, 의료, 소통, 긴급 서비스까지 일상 전반의 관문이 되었고, 그만큼 접근성 문제는 단순한 품질 이슈가 아니라 권리와 규제의 문제로 이어지고 있습니다. 그런데 자동 접근성 테스트(accessibility testing) 도구가 아무리 많은 위반을 찾아내도, 실제로 수정으로 이어지지 않는 경우가 많다는 점이 이 연구의 출발점입니다. 기존 도구는 화면 요소의 좌표, 뷰 계층, 오류 코드 같은 기술적 로그를 주로 남기는데요. 이는 개발자나 접근성 전문가에게는 유용해도, 제품 관리자나 디자이너처럼 의사결정을 하는 사람들에게는 실제 사용자 피해와 법적 위험이 잘 보이지 않는다는 점에서 한계가 있습니다. 저자들은 이 간극을 해석의 간극(interpretation gap)이라고 부르며, 이를 메우기 위한 보고 방식이 필요하다고 봤습니다. 개인적으로도 이 문제는 “문제를 찾는 기술”과 “고치게 만드는 기술” 사이의 간극을 잘 보여준다는 점에서 의미가 있습니다.
주요 내용
이 논문은 HEAR(Human-centered Accessibility Reporting)라는 프레임워크를 제안하는데요. 핵심은 접근성 위반을 차가운 기술 로그가 아니라, 이해관계자가 공감할 수 있는 서사로 바꿔 주는 데 있습니다. 먼저 기존 도구의 결과와 스크린샷, 뷰 계층을 다시 맞춰서 화면 맥락을 복원하고, 그다음 위반 유형에 따라 적절한 장애 기반 인물상(persona)을 동적으로 넣습니다. 마지막으로 다층 추론을 통해 물리적 장벽, 기능적 막힘, 그리고 지역별 법·규정상 위험까지 설명합니다. 이는 단순히 오류를 “보여주는” 수준을 넘어, 왜 지금 고쳐야 하는지를 설득하는 방향으로 설계되었다는 점에서 흥미롭습니다.
첫 번째 단계인 맥락 복원은 특히 중요합니다. 기존 접근성 도구는 JSON 형태로 결과를 내기 때문에, 요소의 위치나 속성은 알 수 있어도 그것이 화면 안에서 어떤 역할을 하는지 파악하기 어렵습니다. HEAR는 문제 지점의 좌표를 기준으로 해당 화면의 스크린샷과 뷰 계층을 찾아오고, XML 전체를 다 넣는 대신 의미 있는 주변 요소만 잘라내는 의미 슬라이싱(semantic slicing)을 사용합니다. 여기에 화면 일부를 확장해 잘라낸 시각적 근거(visual grounding)를 더하는데요. 이렇게 하면 LLM이 버튼의 생김새와 주변 맥락을 함께 보게 되어, 단순한 좌표가 아니라 실제 인터랙션 상황으로 이해할 수 있습니다. 이는 화면 요소를 고립된 객체가 아니라 사용 흐름 속 구성 요소로 다루게 만든다는 점에서 HCI적으로도 설득력이 있습니다.
두 번째 단계는 동적 인물상 주입입니다. 예를 들어 터치 영역이 너무 작은 문제를 단순히 “작다”고 설명하는 대신, 파킨슨병이나 뇌성마비처럼 정교한 손동작이 어려운 사용자의 상황에 연결해 설명합니다. 저자들은 인물상을 이름, 지역, 질환, 신체 제약, 심리적 특징, 논리적 어려움으로 구성된 형태로 정의했는데요. 이렇게 하면 설명이 추상적인 규칙 위반에서 구체적인 사용자의 실패 경험으로 바뀝니다. 이는 접근성 이슈가 단지 UI 미세 조정이 아니라 실제 업무 중단이나 이탈로 이어질 수 있다는 점을 드러내기 때문에 중요합니다. 더 나아가 이 단계는 개발팀이 “조금 불편한 문제”로 넘기기 쉬운 항목을, 사람 중심의 맥락으로 다시 인식하게 만든다고 볼 수 있습니다.
세 번째 단계에서는 기능적 막힘을 법적·규정적 위험으로까지 확장합니다. HEAR는 사용자의 지역 정보를 바탕으로 JIS X 8341-3이나 일본의 차별 해소 관련 법처럼 해당 지역의 규정을 불러와 비교합니다. 그리고 현재 위반이 어떤 성공 기준을 어기는지, 그것이 어떤 차별이나 비준수 리스크로 이어질 수 있는지를 서술합니다. 실험에서는 Instagram, Wish, Teams, Booking 같은 앱에서 103개의 위반 사례를 수집해 검증했고, Google Accessibility Scanner의 원시 JSON과 비교했습니다. 결과적으로 HEAR는 사실에 근거한 보고를 생성하면서도 공감, 긴급성, 설득력, 법적 위험 인식 측면에서 더 높은 평가를 받았습니다. 특히 비전문가에게 설명하거나 수정 우선순위를 정할 때 매우 유용했는데요. 반면 실제 코드를 찾고 직접 수정하는 작업에서는 원시 로그가 더 낫다는 응답도 있었고, 이는 HEAR가 대체재라기보다 해석과 커뮤니케이션을 돕는 보완층에 가깝다고 볼 수 있습니다.
결론 및 시사점
이 연구의 가장 큰 의의는 접근성 테스트의 결과를 “발견”에서 끝내지 않고 “수정”으로 연결하려 했다는 점입니다. 기술적으로는 LLM을 이용해 화면 맥락을 복원하고, 장애 경험과 법적 위험까지 함께 서술함으로써 이해관계자의 우선순위 판단을 돕습니다. 실험 결과도 이를 뒷받침하는데요. 공감, 긴급성, 설득력, 명확성에서 일관되게 더 좋은 평가를 받았고, 비전문가와의 소통이나 학습 목적에서는 특히 강한 선호를 얻었습니다. 이는 접근성 보고가 단순한 오류 목록이 아니라 의사결정 도구가 될 수 있다는 점에서 의미가 있습니다.
다만 한계도 분명합니다. HEAR는 상위 탐지 도구의 결과를 전제로 하기 때문에, 원래 도구가 잘못 잡은 오류까지 그럴듯하게 설명해 버릴 수 있습니다. 즉, 잘못된 경고를 더 설득력 있게 만드는 증폭 효과가 생길 수 있다는 점이 우려됩니다. 또한 장애 인물을 동적으로 넣는 방식은 공감 유도에는 좋지만, 실제 장애의 복잡성과 교차성을 단순화할 위험도 있습니다. 결국 이 프레임워크는 접근성 문제를 덜 중요해 보이게 만드는 표현상의 장벽을 허무는 데 강점이 있지만, 높은 정확도의 탐지와 더 섬세한 장애 모델링이 함께 가야 효과가 커진다고 볼 수 있습니다. 개인적으로는 이런 해석 계층이 실제 제품 조직에 들어가면 접근성의 우선순위를 끌어올리는 데 꽤 실질적인 역할을 할 수 있을 것으로 보입니다.
💡 HCI 실무에서는 접근성 버그 리포트를 원시 로그와 함께 사용자 서사형 요약으로 병행 제공하면, PM·디자이너의 우선순위 판단에 더 도움이 될 수 있습니다. 연구자라면 탐지 정확도뿐 아니라 보고 형식이 의사결정과 공감 형성에 미치는 효과를 별도로 평가하는 설계를 고려해 볼 만합니다.
뉴스레터 구독
매주 금요일, 주간 HCI 하이라이트를 이메일로 받아보세요.