접근성: GitHub, 지속적인 AI로 피드백을 포용으로 전환

접근성 혁신: GitHub의 지속적인 AI 접근 방식

수년 동안 GitHub는 흔하지만 중요한 과제에 직면했습니다. 바로 접근성 피드백을 효과적으로 관리하는 것이었습니다. 일반적인 제품 문제와 달리, 접근성 문제는 광범위하게 퍼져 있으며 종종 여러 팀과 시스템에 걸쳐 있습니다. 스크린 리더 사용자의 단일 보고서가 내비게이션, 인증, 설정 등 여러 부분을 건드릴 수 있어 전통적인 사일로화된 피드백 프로세스는 비효과적이었습니다. 이는 흩어진 보고서, 해결되지 않은 버그, 그리고 거의 실현되지 않는 전설적인 "2단계"에 문제들이 머물러 있는 사용자들의 좌절로 이어졌습니다.

근본적인 변화의 필요성을 인식한 GitHub는 피드백을 중앙 집중화하고, 표준화된 템플릿을 만들며, 상당한 백로그를 정리하기 위한 여정을 시작했습니다. 이러한 강력한 기반을 구축한 후에야 "AI가 이 프로세스를 어떻게 더 발전시킬 수 있을까?"라는 질문이 떠올랐습니다. 그 해답은 GitHub Actions, GitHub Copilot, GitHub Models로 구동되는 혁신적인 내부 워크플로우에 있습니다. 이 워크플로우는 모든 사용자 피드백을 추적되고, 우선순위가 지정되며, 실행 가능한 문제로 지속적으로 전환하도록 설계되었습니다. 이러한 접근 방식은 AI가 인간의 판단을 향상시키고, 반복적인 작업을 간소화하며, 전문가들이 포용적인 소프트웨어 제공에 집중할 수 있도록 보장합니다.

지속적인 AI: 포용을 위한 살아있는 시스템

GitHub의 "접근성을 위한 지속적인 AI"는 단순한 도구를 넘어섭니다. 이는 자동화, 인공지능, 인간 전문성을 통합하여 포용성을 소프트웨어 개발의 핵심에 직접적으로 심어주는 살아있는 방법론입니다. 이러한 철학은 2025년 세계 접근성 인식의 날(GAAD) 서약에 대한 GitHub의 약속을 뒷받침하며, 사용자 피드백을 의미 있는 플랫폼 개선으로 효과적으로 연결하고 변환함으로써 오픈소스 생태계 전반의 접근성을 강화하는 것을 목표로 합니다.

가장 영향력 있는 혁신은 실제 사람들의 목소리에 귀 기울이는 것에서 비롯된다는 핵심적인 깨달음이 있었지만, 대규모로 경청하는 것은 상당한 어려움을 수반합니다. 이를 극복하기 위해 GitHub는 정적인 티켓팅 시스템이 아닌 동적인 엔진으로 작동하는 피드백 워크플로우를 구축했습니다. GitHub는 자체 제품을 활용하여 사용자 및 고객 피드백을 명확히 하고, 구조화하며, 추적하여 구현 준비가 된 솔루션으로 전환합니다.

기술 솔루션에 뛰어들기 전에, GitHub는 사람 중심의 디자인 접근 방식을 채택하여 시스템이 서비스해야 할 주요 페르소나를 식별했습니다.

문제 제출자: 깊은 접근성 전문 지식이 없더라도 문제를 효과적으로 보고하기 위한 지침이 필요한 커뮤니티 관리자, 지원 담당자 및 영업 담당자.
접근성 및 서비스 팀: 재현 단계, WCAG 매핑, 심각도 점수와 같은 구조화되고 실행 가능한 데이터가 필요한 엔지니어 및 디자이너가 문제를 효율적으로 해결합니다.
프로그램 및 제품 관리자: 전략적 자원 할당 결정을 내리기 위해 문제점, 추세 및 진행 상황에 대한 명확한 가시성이 필요한 리더십.

이러한 기본적인 이해를 통해 GitHub는 피드백을 잘 정의된 파이프라인을 통해 흐르는 데이터로 처리하고, 필요에 따라 진화할 수 있는 시스템을 설계할 수 있었습니다.

접근성 피드백 파이프라인 자동화

GitHub는 각 단계가 GitHub Action을 트리거하여 후속 작업을 조율하고, 출처에 관계없이 피드백을 일관되게 처리하도록 보장하는 이벤트 기반 패턴을 중심으로 새로운 아키텍처를 구축했습니다. 2024년 중반에 처음 수동으로 구축되었지만, 이제는 에이전트 워크플로우와 같은 도구를 사용하여 훨씬 더 빠르게 개발될 수 있습니다. 이 도구는 자연어를 통해 GitHub Actions를 생성할 수 있게 해줍니다.

워크플로우는 주요 이벤트에 반응합니다. 문제 생성은 GitHub Models API를 통해 GitHub Copilot 분석을 시작하고, 상태 변경은 팀 인계를 트리거하며, 문제 해결은 원래 제출자와의 후속 조치를 유도합니다. 자동화는 일반적인 경로를 다루지만, 인간은 모든 Action을 수동으로 트리거하거나 다시 실행하여 감독 및 유연성을 유지할 수 있습니다.

7단계 피드백 워크플로우:

접수: 피드백은 GitHub 접근성 토론 게시판(보고서의 90%를 차지), 지원 티켓, 소셜 미디어, 이메일과 같은 다양한 출처에서 들어옵니다. 모든 피드백은 5영업일 이내에 확인됩니다. 조치 가능한 항목의 경우, 팀원은 필수적인 맥락을 포착하는 맞춤형 접근성 피드백 템플릿을 사용하여 수동으로 추적 문제를 생성합니다. 이 생성 이벤트는 GitHub Copilot을 활용하고 문제를 중앙 집중식 프로젝트 보드에 추가하기 위한 GitHub Action을 트리거합니다.
Copilot 분석: GitHub Action은 GitHub Models API를 호출하여 새로 생성된 문제를 분석합니다.
제출자 검토: 초기 제출자는 Copilot의 분석을 검토하고 정확성을 확인하거나 조정을 수행합니다.
접근성 팀 검토: 전문 접근성 팀이 심층 검토를 수행하고 해결책을 전략화합니다.
감사 링크: 관련 감사 또는 외부 자료가 맥락 및 규정 준수를 위해 연결됩니다.
루프 종료: 문제가 해결되면 공식적으로 종료되며, 원래 사용자 또는 고객에게 통보됩니다.
개선: Copilot의 분석을 포함한 시스템 성능에 대한 피드백은 지속적인 업데이트 및 개선에 활용됩니다.

이 지속적인 흐름은 피드백 라이프사이클의 모든 단계에서 가시성, 구조 및 실행 가능성을 보장합니다.

GitHub Copilot의 지능적인 접근성 분류

이 자동화 시스템의 핵심은 GitHub Copilot의 지능적인 분석입니다. 추적 문제가 생성되면, GitHub Action 워크플로우는 GitHub Models API를 프로그래밍 방식으로 호출하여 보고서를 분석합니다. GitHub는 모델 미세 조정 대신 저장된 프롬프트(맞춤형 지침)를 사용하는 전략적 선택을 했습니다. 이를 통해 모든 팀원은 간단한 풀 리퀘스트를 통해 AI의 동작을 업데이트할 수 있으며, 복잡한 재훈련 파이프라인이나 전문적인 머신러닝 지식이 필요 없습니다. 접근성 표준이 발전하면 팀은 마크다운 및 지침 파일을 업데이트하고, AI의 동작은 다음 실행 시 적응합니다.

GitHub Copilot은 접근성 전문가가 개발한 맞춤형 지침으로 구성됩니다. 이 지침은 두 가지 중요한 역할을 합니다.

분류 분석: WCAG 위반, 심각도(sev1-sev4) 및 영향을 받는 사용자 그룹별로 문제를 분류합니다.
접근성 코칭: 팀이 접근 가능한 코드를 작성하고 검토하도록 안내합니다.

지침 파일은 GitHub의 접근성 정책, 구성 요소 라이브러리 및 내부 문서를 참조하여 Copilot이 WCAG 성공 기준을 해석하고 적용하는 방법에 대한 포괄적인 이해를 제공합니다.

자동화는 두 가지 주요 단계로 진행됩니다.

첫 번째 Action: 문제 생성 시, Copilot은 보고서를 분석하여 문제 메타데이터의 약 80%를 자동으로 채웁니다. 여기에는 문제 유형, 사용자 세그먼트, 원본 소스, 영향을 받는 구성 요소 및 사용자 경험 요약과 같은 40개 이상의 데이터 포인트가 포함됩니다. 그런 다음 Copilot은 문제에 대한 댓글을 게시하며, 여기에는 문제 요약, 제안된 WCAG 기준, 심각도 수준, 영향을 받는 사용자 그룹, 권장 팀 할당, 그리고 검증을 위한 체크리스트가 포함됩니다.
두 번째 Action: 이 후속 Action은 Copilot의 댓글을 파싱하고, 할당된 심각도를 기반으로 레이블을 적용하며, 프로젝트 보드에서 문제의 상태를 업데이트하고, 제출자에게 검토를 위해 할당합니다.

중요하게도, Copilot의 분석이 정확하지 않은 경우, 누구나 불일치를 설명하는 문제를 열어 이를 표시할 수 있으며, 이는 GitHub의 AI 지속적인 개선 프로세스에 직접적인 피드백으로 작용합니다.

인간의 감독과 반복적인 접근성 개선

워크플로우는 인간의 감독과 협업을 강조합니다. Copilot의 자동화된 분석 후, "제출자 검토" 단계(3단계)는 인간 제출자가 AI의 발견 사항을 확인할 수 있도록 합니다. 이러한 '인간 참여' 접근 방식은 정확성을 보장하고, Copilot의 지속적인 개선 프로세스를 위한 수동 수정 또는 표시를 허용합니다. 이어지는 단계들—접근성 팀 검토, 감사 링크, 루프 종료—은 인간 전문성을 더욱 통합하여 복잡한 문제가 전문가에 의해 해결되고 사용자가 시기적절하고 효과적인 해결책을 받을 수 있도록 보장합니다.

이 동적인 시스템은 GitHub에게 중요한 변화를 의미합니다. AI를 활용하여 피드백 관리의 반복적이고 데이터 집약적인 측면을 처리함으로써, 그들은 혼란스럽고 종종 정체되었던 프로세스를 포용을 위한 지속적이고 능동적인 엔진으로 전환했습니다. 이는 모든 접근성 피드백이 이제 신뢰할 수 있게 추적되고, 우선순위가 지정되며, 조치된다는 것을 의미하며, "2단계" 약속을 넘어 모든 사용자에게 즉각적이고 실질적인 개선을 제공합니다. 궁극적인 목표는 인간의 판단을 대체하는 것이 아니라, 이를 강화하여 귀중한 시간과 전문 지식을 전략적 수정에 집중하고 진정으로 접근 가능한 소프트웨어 경험을 육성하는 것입니다.

원본 출처

https://github.blog/ai-and-ml/github-copilot/continuous-ai-for-accessibility-how-github-transforms-feedback-into-inclusion/

자주 묻는 질문

What challenges did GitHub face with accessibility feedback before implementing its Continuous AI system?

Prior to the new system, GitHub struggled with a decentralized and inconsistent approach to accessibility feedback. Issues were often scattered across various backlogs, lacked clear ownership, and improvements were frequently postponed. This disorganization led to a lack of follow-through, leaving users with unaddressed concerns and creating a barrier to truly inclusive software development. The cross-cutting nature of accessibility issues, touching multiple teams, exacerbated these coordination challenges, making it difficult to establish a single point of responsibility or a coherent workflow for resolution.

What defines 'Continuous AI for accessibility' and how does it enhance traditional accessibility efforts?

Continuous AI for accessibility is a dynamic methodology that integrates automation, artificial intelligence, and human expertise into the software development lifecycle. Unlike static audits or one-time fixes, it's a living system designed to continuously process and act on user feedback. It goes beyond simple code scanners by actively listening to real people and using AI, particularly GitHub Copilot and GitHub Actions, to clarify, structure, and prioritize that feedback. This ensures that inclusion is woven into the very fabric of development, transforming scattered reports into implementation-ready solutions and fostering ongoing improvement.

How does GitHub Copilot specifically contribute to the efficiency and effectiveness of the accessibility feedback workflow?

GitHub Copilot plays a crucial role by providing intelligent triage and analysis of accessibility reports. Upon issue creation, Copilot, guided by custom instructions from accessibility subject matter experts, programmatically analyzes the report. It automatically populates approximately 80% of an issue's metadata, including WCAG violation classifications, severity levels, affected user groups, and recommended team assignments. This automated analysis significantly reduces manual effort, standardizes issue categorization, and provides immediate, actionable insights, allowing human teams to focus on problem-solving rather-than repetitive data entry and initial assessment.

What are GitHub's 'custom instructions' for Copilot, and why were they chosen over model fine-tuning for this system?

GitHub utilizes 'custom instructions' for Copilot, developed by their accessibility subject matter experts, to guide its behavior for triage analysis and accessibility coaching. These instructions are stored prompts that point to GitHub’s accessibility policies, component library, and internal documentation, detailing how WCAG success criteria are interpreted and applied. This approach was chosen over model fine-tuning because it allows for rapid iteration and team-wide updates. Any team member can update the AI's behavior by modifying markdown and instruction files via a pull request, eliminating the need for complex retraining pipelines or specialized ML knowledge, ensuring the AI's behavior evolves as standards do.

How does GitHub ensure that human judgment and oversight remain central to the accessibility process despite the extensive use of AI automation?

GitHub deliberately designed its system so that AI automates repetitive tasks while humans retain critical judgment and oversight. For example, after GitHub Copilot's initial analysis, a 'submitter review' step ensures a human verifies Copilot's findings. If Copilot's analysis is incorrect, humans can flag it, providing direct feedback for continuous improvement of the AI. Furthermore, every GitHub Action in the workflow can be manually triggered or re-run, ensuring that humans can intervene at any point. The goal is to offload mundane work to AI, empowering humans to focus on complex problem-solving, collaboration, and making informed decisions about software fixes.

Who are the primary beneficiaries of GitHub's enhanced accessibility feedback system, and how does it cater to their specific needs?

The system serves three primary groups. Issue submitters (community managers, support agents, sales reps) benefit from a guided system that standardizes feedback collection and educates them on accessibility concepts. Accessibility and service teams (engineers, designers) receive structured, actionable data including reproducible steps, WCAG mapping, and clear ownership, streamlining their remediation efforts. Program and product managers gain visibility into pain points, trends, and progress, enabling strategic resource allocation. Ultimately, the biggest beneficiaries are the users and customers with disabilities whose feedback is now consistently tracked, prioritized, and acted upon, leading to a more inclusive GitHub experience.

How does GitHub integrate user feedback from external sources into its internal accessibility process, ensuring consistency and actionability?

GitHub acknowledges that accessibility feedback can originate from diverse external sources, including support tickets, social media, email, and direct outreach, with the GitHub accessibility discussion board being a primary channel. Regardless of the source, every piece of feedback is acknowledged within five business days. When external feedback requires action, a team member manually creates an internal tracking issue using a custom accessibility feedback template. This template standardizes the collected information, preventing data loss. This new issue then triggers an automated GitHub Action, engaging GitHub Copilot for analysis and adding it to a centralized project board, ensuring consistent processing and action regardless of its origin.