접근성을 위한 지속적인 AI: GitHub이 피드백을 포용으로 전환하는 방법

GitHub는 접근성 피드백이 여러 팀과 채널에 흩어져 처리되지 못하던 문제를 해결하기 위해, 피드백을 지속적으로 수집·분류·추적하는 AI 기반 워크플로를 구축했다. GitHub Actions, GitHub Copilot, GitHub Models를 결합해 반복적인 분석과 라우팅은 자동화하되, 우선순위와 해결 판단은 사람이 맡는다. 그 결과 접근성 문제를 일회성 감사가 아니라 지속적으로 개선되는 운영 시스템으로 전환했다.

접근성 피드백이 기존 방식에서 겪은 문제

• 접근성 문제는 내비게이션, 인증, 설정, 공통 컴포넌트 등 여러 영역에 걸쳐 발생해 단일 팀이 소유하기 어렵다.
• 피드백이 여러 백로그와 버그 목록에 분산되면서 담당자가 정해지지 않거나 장기간 방치됐다.
• 사용자가 반복해서 진행 상황을 문의해야 했고, 개선 사항이 막연한 “2단계 작업”으로 미뤄지는 경우가 많았다.
• 따라서 단순한 버그 관리가 아니라, 접수부터 해결과 후속 안내까지 연결하는 조정 체계가 필요했다.

Continuous AI: 접근성을 살아 있는 시스템으로 관리

• GitHub가 말하는 Continuous AI는 단일 제품이나 일회성 자동 검사 도구가 아니다.
• 자동화, 인공지능, 사람의 전문성을 결합해 소프트웨어 개발 과정에 접근성을 지속적으로 포함시키는 방법론이다.
• 코드 스캐너만으로는 실제 사용자가 겪는 장벽을 충분히 발견하기 어렵기 때문에, 사용자와 고객의 경험을 중심 데이터로 삼는다.
• 피드백을 명확한 구조의 데이터로 바꾸고, 적절한 팀에 전달하며, 구현 가능한 이슈로 발전시키는 것이 핵심이다.
• 이는 2025년 GAAD pledge의 방향인 오픈소스 생태계 전반의 접근성 개선과도 연결된다.

사용자와 조직 구성원을 위한 설계

시스템은 세 가지 주요 사용자를 기준으로 설계됐다.

• 이슈 제출자
  • 커뮤니티 관리자, 지원 담당자, 영업 담당자가 사용자를 대신해 문제를 등록한다.
  • 이들이 반드시 접근성 전문가일 필요는 없으므로, 입력 과정에서 접근성 개념과 필요한 정보를 안내해야 한다.
• 접근성·서비스 팀
  • 엔지니어와 디자이너가 재현 단계, WCAG 기준, 심각도, 담당 팀 등 실행 가능한 정보를 받아야 한다.
• 프로그램·제품 관리자
  • 문제 유형별 현황, 반복되는 추세, 해결 진행률을 파악해 리소스와 우선순위를 결정해야 한다.
• 이를 위해 피드백을 단순 티켓이 아니라 파이프라인을 따라 흐르는 데이터로 취급하고, 변화에 맞춰 확장 가능한 구조를 선택했다.

이벤트 기반 피드백 워크플로

• 각 단계가 GitHub Action을 실행하는 이벤트 기반 구조로 설계됐다.
• 이슈가 생성되면 GitHub Models API를 통해 GitHub Copilot이 피드백을 분석한다.
• 상태가 변경되면 다음 담당 팀으로 자동 인계된다.
• 문제가 해결되면 최초 제출자에게 후속 안내를 보내 사용자와의 소통을 마무리한다.
• 모든 Action은 수동 실행하거나 재실행할 수 있어, 자동화가 처리하지 못하는 경우 사람이 언제든 개입할 수 있다.
• 전체 흐름은 다음 일곱 단계로 구성된다.
  • 접수(Actioning intake)
  • Copilot 분석
  • 제출자 검토
  • 접근성 팀 검토
  • 링크 감사
  • 사용자와의 마무리 소통
  • 개선 및 프롬프트 업데이트
• 제출자 검토에서 Copilot 분석을 다시 실행하거나, 마무리 단계에서 접근성 팀 검토로 되돌아가는 식의 피드백 루프도 포함된다.
• 2024년 중반에는 이 시스템을 주로 직접 구축했지만, 현재는 자연어로 GitHub Actions를 생성할 수 있는 Agentic Workflows를 이용하면 유사한 시스템을 더 빠르게 만들 수 있다.

다양한 채널에서의 접수와 표준화

• 접근성 피드백은 지원 티켓, 소셜 미디어, 이메일, 직접 연락 등 다양한 경로에서 들어온다.
• 현재 약 90%는 GitHub 접근성 Discussion 게시판을 통해 접수된다.
• 공개 게시판에서는 다른 사용자가 문제를 확인하거나 추가 맥락과 우회 방법을 제공할 수 있어, 일반 지원 티켓보다 풍부한 정보가 모이는 장점이 있다.
• 모든 피드백에는 영업일 기준 5일 이내에 응답한다.
• 즉시 조치할 수 없는 내용도 관련 자료나 도움을 받을 수 있는 경로를 안내해 응답이 끊기지 않도록 한다.
• 내부 팀의 조치가 필요한 경우 담당자가 사용자 보고 내용, 출처, 관련 컴포넌트를 담은 전용 접근성 피드백 이슈 템플릿으로 추적 이슈를 만든다.
• 이슈 템플릿은 접수 정보를 표준화해 초기 맥락이 트리아지 과정에서 사라지는 것을 방지한다.

운영 방식에서 얻는 시사점

• AI는 접근성 문제의 최종 판단자라기보다 반복적인 분류·요약·전달을 담당하는 보조 수단으로 사용된다.
• 실제 해결 여부, 우선순위, 담당 지정에는 사람의 전문성과 판단이 계속 필요하다.
• 효과적인 자동화의 전제는 AI 모델 자체가 아니라, 먼저 피드백 채널을 정리하고 입력 형식을 표준화하는 일이다.
• 접근성 문제를 개별 팀의 선택적 업무가 아니라 지속적으로 측정하고 개선해야 하는 제품 운영 데이터로 다뤄야 한다.

실무적으로는 먼저 접근성 피드백을 한곳으로 모으고, 재현 단계·영향 범위·WCAG 기준·심각도·소유 팀을 포함한 템플릿을 마련하는 것이 좋다. 그 기반 위에서 AI와 워크플로 자동화를 도입해야 자동 분류가 실제 해결과 사용자 후속 안내로 이어질 수 있다.