GitHub AI 에이전트, PR 3,500개 접근성 자동 검토

AI 에이전트가 접근성 장벽을 허문다

GitHub이 실험적으로 운영 중인 범용 접근성(Accessibility) 에이전트가 주목받고 있습니다. 2026년 5월 공개된 사례 보고에 따르면, 이 에이전트는 지금까지 3,535개의 풀 리퀘스트(PR)를 검토하고 그 중 68%의 접근성 문제를 해결했습니다. 단순한 실험을 넘어, AI 에이전트 설계의 실질적인 교훈을 담고 있어 개발을 배우는 학생들에게도 중요한 참고 사례가 됩니다.

무엇을 자동으로 잡아냈나

이 에이전트가 가장 많이 발견한 접근성 문제 5가지는 다음과 같습니다.

1. 구조와 관계(Info and Relationships) — 스크린 리더 등 보조 기술이 페이지 구조를 이해하지 못하는 경우
2. 컨트롤 이름 불명확 — 버튼·링크 등 인터랙티브 요소에 명확한 레이블이 없는 경우
3. 상태 메시지 누락 — 사용자가 중요한 알림을 인지하지 못하는 경우
4. 비텍스트 콘텐츠 대체 텍스트 부재 — 이미지에 alt 텍스트가 없는 경우
5. 키보드 포커스 순서 오류 — 논리적이지 않은 탭 순서

이 다섯 가지는 WCAG(Web Content Accessibility Guidelines, 웹 콘텐츠 접근성 지침) 2.2 기준에 근거한 항목들입니다. 유럽 접근성법(EAA)은 이미 발효됐고, 미국 ADA(Americans with Disabilities Act) Title II는 2027년 4월부터 WCAG 2.1 AA를 법적 준수 기준으로 삼습니다. 접근성은 더 이상 선택이 아닙니다.

에이전트 설계의 핵심 교훈

1. 단일 에이전트의 한계 — 서브에이전트 구조로 전환

처음에는 하나의 모놀리식 에이전트로 시작했지만 금세 한계에 부딪혔습니다. GitHub은 두 개의 전문 서브에이전트로 구조를 재편했습니다.

• 리뷰어 에이전트: 수동 검토자·조사자 역할. 문제를 찾고 인간 개입이 필요한 지점을 에스컬레이션
• 구현자 에이전트: 실제 코드 수정 담당

두 서브에이전트는 직접 통신하지 않습니다. 대신 구조화된 템플릿 스키마를 생성해 부모 에이전트가 중재합니다. 이렇게 하면 감사 추적(audit trail)이 가능하고, 에이전트가 잘못된 방향으로 작업하는 것을 방지할 수 있습니다.

2. 선형(Linear) 실행 순서 고수

병렬 처리가 항상 유리한 건 아닙니다. 접근성 검토처럼 맥락 의존도가 높은 작업은 순차적 실행이 정확도를 높입니다. 에이전트에게 정해진 순서로 페이즈를 실행하도록 강제한 것이 핵심 설계 결정이었습니다.

3. LLM의 편향 인식 — 기존 코드베이스 데이터로 보완

현재 존재하는 모든 주요 LLM은 수십 년간 축적된 접근성을 고려하지 않은 코드로 학습되었습니다. 따라서 기본 상태에서 LLM은 접근성 안티패턴을 생성하는 편향이 있습니다. GitHub은 자체적으로 수동 감사·수정한 접근성 이슈와 PR 데이터를 에이전트의 참조 자료로 제공해 이 편향을 상쇄했습니다.

4. 한계 인정 — 고위험 패턴과 복잡도 기반 제어

AI가 만능이라는 착각은 금물입니다. GitHub 에이전트는 다음 상황에서 코드 생성을 자동으로 중단합니다.

• 코드 복잡도가 임계값을 초과할 때
• 드래그 앤 드롭, 토스트 알림, 리치 텍스트 에디터, 트리뷰, 데이터 그리드 등 고위험 패턴이 감지될 때

이 경우 에이전트는 사람에게 접근성 팀과 상담하도록 안내합니다. LLM이 억지로 결과를 생성하려는 경향("bias to action")을 막기 위한 '안티게이밍(anti-gaming)' 지시도 포함됐습니다.

WCAG 자동화의 한계: 36%는 여전히 사람이 필요

WCAG Level A·AA 성공 기준 55개 중 35개만 자동 도구로 감지 가능합니다. 나머지 약 36%는 자동화로 발견할 수 없습니다. LLM 기반 에이전트가 이 격차를 좁히고 있지만, 디자인·프로토타이핑 단계에서의 인간 검토는 여전히 필수입니다.

학생·개발자에게 주는 시사점

이번 사례는 단순한 GitHub 내부 이야기가 아닙니다. AI 에이전트를 설계할 때 '하나의 거대한 에이전트'보다 역할이 분리된 서브에이전트 구조가 더 효과적일 수 있음을 보여줍니다. 또한 LLM은 학습 데이터의 편향을 그대로 반영하기 때문에, 도메인 특화 데이터로 보완하는 RAG(검색 증강 생성) 또는 fine-tuning(미세 조정) 전략이 실무에서 얼마나 중요한지도 확인할 수 있습니다.

학생 활용법: GitHub Copilot의 접근성 검토 기능을 직접 써보며 자신의 프로젝트에 alt 텍스트, ARIA(Accessible Rich Internet Applications) 레이블 등 기본 접근성 요소를 적용해보세요. 접근성은 취업 포트폴리오에서도 점점 더 중요한 평가 기준이 되고 있습니다.