깃허브, 접근성 문제 자동 감지·수정하는 AI 에이전트 도입…3,535개 PR 검토했다

깃허브가 개발자의 접근성 관련 질문에 실시간 답변을 제공하고, 접근성 결함을 자동으로 감지해 수정하는 AI 에이전트를 파일럿 운영하고 있다. 에릭 베일리(Eric Bailey) 깃허브 엔지니어는 15일 블로그를 통해 이 실험 과정에서 얻은 교훈을 공개했다.

접근성 에이전트의 역할

깃허브의 접근성 에이전트는 두 가지 주요 목표를 추구한다. 첫째, 깃허브 코파일럿 CLI와 VS Code 통합에서 개발자에게 접근성 질문에 대한 신뢰할 만한 실시간 답변을 제공한다. 둘째, 프로덕션 배포 전에 간단하고 객관적인 접근성 문제를 자동으로 감지하고 수정한다.

현재까지 이 에이전트는 3,535개의 풀 리퀘스트를 검토했으며, 68% 해결률을 기록했다. 감지된 주요 문제 유형은 다음과 같다:

• 보조 기술(스크린 리더, 음성 제어 등)을 위한 명확한 구조와 관계 표시
• 인터랙티브 컨트롤의 명확하고 간결한 이름 지정
• 사용자가 중요 공지사항을 인지할 수 있도록 보장
• 텍스트가 아닌 콘텐츠의 텍스트 대안 제공
• 페이지와 뷰를 통한 논리적 키보드 포커스 이동

이러한 자동 감지와 수정은 스크린 리더 등 보조 기술에 의존하는 사용자들이 깃허브를 사용할 때 겪었던 장벽을 제거한다.

핵심 설계 원칙: '강화'가 아닌 '보조'

깃허브가 접근성 에이전트 개발에서 강조하는 철학은 "자동 해결이 아닌 보조"다. 장애의 사회 모델은 접근성 장벽이 환경 설계 방식으로 인해 발생한다고 본다. 깃허브 팀은 에이전트가 동료들의 접근성 노력을 강화하되, 자체적으로 모든 문제를 해결하지는 않는다는 점을 명시했다.

에이전트는 "은탄환"이 아니기에 한계가 명확하다. 이러한 인식은 파일럿의 빠른 출범과 조직 내 협력을 이끌어냈다.

구조화된 데이터의 힘

깃허브의 성공은 과거 10년간 축적한 정형화된 접근성 이슈 데이터베이스에서 비롯됐다. 유럽 접근성법(European Accessibility Act)이 발효되고, 미국 장애인법(ADA) 2조가 2027년 4월 웹접근성 표준(WCAG 2.1 AA)을 법적 준수 기준으로 정하는 상황에서, 깃허브는 체계적으로 분류된 이슈들이 에이전트의 학습 자료가 될 수 있음을 깨달았다.

이슈 로깅 시스템에는 문제 재현 단계, 심각도·서비스 영역·해당 WCAG 성공 기준, 수정 PR 크로스링크 등이 메타데이터로 포함되어 있었다. 정규 표현식이나 추상적인 지침보다는, 실제 코드와 수정 사례의 구체적 맥락이 LLM의 "퍼지 매칭" 능력을 활성화시켰다.

효율성과 정확성의 균형: 다중 에이전트 아키텍처

접근성은 코드, 디자인, 카피라이팅 등 여러 분야에 걸친 전체적 관심사라, 단일 에이전트는 토큰을 과다 소비하며 응답 속도 저하와 비용 증가를 초래했다.

이를 해결하기 위해 깃허브는 2개의 서브 에이전트로 진화시켰다:

• 리뷰어 에이전트: 수동으로 코드를 검토하고 문제점을 보고. 높은 심각도 WCAG 실패나 알려진 난제 패턴을 감지하면 에스컬레이션.
• 구현자 에이전트: 실제 코드 수정 수행.

두 에이전트는 샌드박스 환경에서 직접 통신하지 않는다. 대신 정형화된 템플릿을 거쳐 부모 오케스트레이터 에이전트가 검증하고 라우팅한다. 이 접근법의 이점:

• 에스컬레이션 체크포인트: 인간 개입이 필요한 영역을 미리 식별
• 복잡도 기반 동작: 코드가 너무 복잡하면 "지침만 제공" 모드로 전환
• 필터링: 리뷰어가 모든 발견사항을 보고하면, 부모 에이전트가 관련성을 판단해 구현자의 불필요한 작업 방지
• 감시 추적: 직접 통신을 배제해 의사결정 감시 추적 가능

선형 실행과 스키마의 중요성

접근성 작업은 세부 사항에 주의 깊은 방법론적 접근을 요구한다. 깃허브는 서브 에이전트 지시를 정해진 순서대로 선형으로 실행하도록 강제했다. 각 단계는 관련 리소스와 스킬을 동반한 자식 지시들로 구성되어, 에릭 베일리가 수동으로 감사·수정·보고하는 방식을 반영한다.

또한 2개의 템플릿 스키마를 중심으로 운영:

• 리뷰어 템플릿: 감사 항목과 정보 수집 방법 정의
• 구현자 템플릿: 수정 대상과 수정 방법 정의

스키마 없이는 에이전트들이 임의로 통신하며 토큰 낭비, 부실한 할루시네이션, 불필요한 코드 변경을 야기했을 것이다.

에이전트 한계를 설계에 녹이다

깃허브는 접근성 에이전트가 만능 해결책이 아님을 명시하고, 여러 제한 장치를 설계했다:

1. 코드 복잡도 평가 간단한 셸 스크립트로 대상 코드의 상대적 복잡도를 점수화한 뒤, 임계값을 초과하면 에이전트가 코드 수정을 시도하지 않고 사용자를 접근성 팀으로 안내한다.

2. 고위험 패턴 회피 자동화된 접근성 검사를 통과해도 실제로는 사용 불가능한 코드가 존재한다. 깃허브는 드래그 앤 드롭, 토스트 알림, 리치 텍스트 에디터, 트리 뷰, 데이터 그리드 등 접근성 팀이 식별한 고위험 패턴에 대해 LLM의 코드 생성 기능을 비활성화했다.

3. 행동 편향 감소 LLM들은 콘텐츠 생성에 강한 편향을 보인다. 깃허브는 에이전트가 "코드 생성 금지" 지시를 우회하는 창의적인 방법을 찾지 못하도록 "안티 게이밍" 지침을 추가했다.

4. 자동 감지의 한계 인식 55개의 WCAG 레벨 A와 AA 성공 기준 중 단 35개만이 자동 코드 검사로 감지 가능하다. 약 36%는 수동 검토가 필수다. 이 때문에 설계·프로토타입 단계에서 접근성 팀과 디자인팀의 협업이 필수적이며, 깃허브는 이를 에이전트의 에스컬레이션 로직에 반영했다.

지속적 개선과 개방형 학습

깃허브는 에이전트 출력을 주기적으로 수동 검토하고, PR 리뷰어의 반응(sentiment)을 수집해 에이전트의 지침과 리소스를 개선한다.

흥미롭게도, 깃허브는 이 접근성 에이전트를 오픈소스로 공개할 계획을 밝혔다. 세계적 규모로 오픈소스 소프트웨어의 접근성을 높이려는 약속의 일환이다.

한국의 접근성 규제와 개발자 경험

한국에서도 웹접근성법(한국형 ADA 수준)이 강화되고 있으며, 공공기관·금융기관 웹사이트뿐 아니라 상용 소프트웨어 개발사들도 규제 대응 압박을 받는 중이다. 깃허브의 AI 에이전트 접근법—정형화된 데이터 축적, 다중 에이전트 구조, 한계의 명시—은 한국 개발팀들이 접근성을 비용 효율적으로 확보하는 데 참고할 만한 모델이다.

특히 카카오, 네이버, 당근마켓 등 주요 플랫폼 기업들이 AI 기반 접근성 자동화 도입을 검토한다면, 깃허브의 "강화(augment) 철학"을 우선 고려할 가치가 있다.

결론

깃허브의 접근성 에이전트는 AI 도구가 단순히 문제를 "자동 해결"하려는 것이 아니라, 인간의 전문성을 어떻게 증강할지 설계해야 한다는 교훈을 제시한다. 3,535개 PR의 실증 데이터와 68% 해결률은 규제 강화 시대에 개발 조직이 나아갈 방향을 암시한다.