범용 접근성 에이전트 구축과 그 과정에서 얻은 교훈
GitHub는 개발자가 접근성 질문에 즉시 답을 얻고, 배포 전 단순하고 객관적인 접근성 문제를 자동 수정하도록 실험적인 범용 접근성 에이전트를 운영하고 있습니다. 이 에이전트는 3,535개의 풀 리퀘스트를 검토해 68%의 해결률을 기록했지만, 접근성을 자동으로 “해결”하는 만능 도구가 아니라 기존 엔지니어링 노력을 보완하는 역할로 설계되었습니다. 특히 조직이 축적한 구조화된 접근성 이슈와 수정 사례가 에이전트의 정확도와 실용성을 높이는 핵심 자산이 되었습니다. ## 접근성 에이전트의 목표와 성과 - GitHub Copilot CLI와 VS Code 통합 환경에서 접근성 관련 질문에 신뢰할 수 있는 답변을 제공합니다. - 프런트엔드 코드가 변경된 풀 리퀘스트를 자동으로 검사합니다. - 단순하고 판단 기준이 명확한 접근성 문제는 코드 제안 형태로 자동 수정할 수 있습니다. - 현재까지 3,535개의 풀 리퀘스트를 검토했으며, 68%의 해결률을 기록했습니다. - 가장 많이 발견된 문제는 다음과 같습니다. - 구조와 관계를 보조공학 기술이 명확히 이해하도록 표현하지 못한 문제 - 대화형 컨트롤의 이름이 불명확한 문제 - 중요한 상태 변화나 공지를 사용자에게 전달하지 못한 문제 - 이미지 등 비텍스트 콘텐츠에 텍스트 대안이 없는 문제 - 키보드 포커스 이동 순서가 논리적이지 않은 문제 예를 들어 시각적 배치와 DOM·스크린 리더 읽기 순서가 서로 다른 경우, 에이전트는 `row-reverse` 대신 DOM 요소 순서를 바꾸고 일반적인 `flex-direction: row`를 사용하라고 제안할 수 있습니다. ## 접근성을 바라보는 관점 - 사회적 장애 모델에 따르면 장애와 사용 장벽은 개인뿐 아니라 환경의 설계 방식에서도 발생합니다. - 디지털 서비스에서도 잘못 구성된 UI가 보조공학 사용자에게 장벽을 만들 수 있습니다. - 따라서 에이전트의 목표는 접근성을 독립적으로 완성하는 것이 아니라, 동료 개발자가 장벽을 더 빠르게 발견하고 제거하도록 돕는 것입니다. - 모든 상황을 자동으로 처리할 수 있는 “실버 불릿”으로 에이전트를 홍보하지 않았습니다. - 에이전트의 책임 범위를 현실적으로 정의한 덕분에 실험을 빠르게 시작하고 조직 내 동의를 얻을 수 있었습니다. ## 규제와 사전 투자 - 유럽 접근성법(EAA)이 시행되었고, 미국 장애인법(ADA) Title II도 2027년 4월부터 WCAG 2.1 AA 준수를 법적 완료 기준으로 삼을 예정입니다. - LLM 기반 에이전트는 접근성 트리를 읽고 이를 바탕으로 UI를 분석하거나 조작할 수 있습니다. - 조직이 아직 수동으로 접근성 문제를 식별하고 수정하는 체계를 마련하지 않았다면, 향후 에이전트를 구축할 때도 불리해집니다. - 자동화는 기존의 접근성 품질 관리 체계를 대체하는 것이 아니라, 이미 검증된 문제와 해결 방식을 활용해 확장하는 방식으로 효과를 냅니다. ## 구조화된 이슈 데이터의 가치 GitHub는 에이전트 도입 이전부터 접근성 문제를 일관되게 기록하고 검증하는 시스템을 운영했습니다. - 문제 신고용 구조화된 템플릿 - 재현 절차 - 심각도, 담당 서비스 영역, 적용 가능한 WCAG 성공 기준 등의 메타데이터 - 문제를 해결한 풀 리퀘스트와의 연결 - 수정 완료를 판단하는 명확한 수용 기준 - 모든 접근성 이슈를 하나의 저장소에 중앙화 이처럼 일관된 형식으로 축적된 이슈와 코드 변경 내역은 에이전트가 참고할 수 있는 고품질 학습·검색 자료가 되었습니다. LLM의 비결정적이고 유연한 매칭 능력도 비슷한 코드와 문구를 찾아내는 데에는 장점으로 작용했습니다. ## 일반적인 지침만으로는 부족한 이유 - 전문 영역에서 “접근성 모범 사례를 따르라”는 식의 짧고 추상적인 지침만으로는 충분하지 않습니다. - 주요 LLM은 접근성이 부족한 코드가 포함된 수십 년간의 자료로 학습되었기 때문에, 접근성 안티패턴을 생성하는 편향을 보일 수 있습니다. - 따라서 에이전트가 실제 조직의 코드 스타일과 문제 해결 관례를 반영한 구체적인 사례를 참고해야 합니다. - 수동으로 접근성 문제를 분류하고 수정한 기록은 다음 요소를 함께 포함합니다. - 실제 제품 맥락 - 조직의 코딩·문서화 규칙 - 적용된 WCAG 기준 - 문제를 해결한 코드 - 수정 여부를 검증하는 조건 - 이런 사례 기반 자료는 단순한 체크리스트보다 에이전트의 판단과 코드 제안에 훨씬 강력한 기반이 됩니다. ## 실용적인 결론 접근성 에이전트를 도입하려면 먼저 사람이 접근성 문제를 일관되게 기록하고, 재현 절차와 WCAG 기준, 실제 수정 사례를 축적하는 것이 좋습니다. 에이전트는 전문가의 판단을 대체하기보다 반복적이고 객관적인 문제를 빠르게 발견·수정하는 보조 수단으로 운영해야 하며, 그 한계를 명확히 정의할수록 조직 내 신뢰와 도입 효과가 커집니다.
원문 읽기(새 탭에서 열림)
