GitHub 접근성 에이전트 공부 정리 | AI가 WCAG를 어디까지 고칠 수 있을까

GitHub 블로그에서 접근성 에이전트 파일럿 관련 글이 올라왔다. GitHub Copilot이 코드베이스를 훑어 WCAG 이슈를 자동으로 탐지하고 수정 제안을 해준다는 내용이었는데, 어느 범위까지 자동화가 가능한 건지 궁금해서 좀 더 들여다봤다.

단순히 LLM에 “접근성 기준에 맞게 고쳐줘”를 던지는 게 아니라, 에이전트를 역할별로 나눠 설계했다는 점이 읽으면서 눈에 들어왔다.

1️⃣ 이게 뭐냐?

검토자(reviewer)와 구현자(implementer)로 역할을 분리한 2계층 구조다. 검토자는 읽기 전용으로 코드를 훑어 어떤 문제가 있는지 파악하고, 구현자가 실제 코드 수정을 담당한다. GitHub이 직접 수동으로 감사해둔 접근성 이슈 데이터베이스를 학습 자료로 활용했다고 한다.

에이전트가 처리하는 범위는 구체적이다. 대화형 컨트롤에 명확한 이름 붙이기, 비텍스트 콘텐츠에 대체 텍스트 추가하기, DOM 읽기 순서와 시각적 렌더링이 어긋나는 경우 수정하기 같은 것들이다. 글에서 나온 PR 댓글 예시를 보면 “WCAG 1.3.2: flex-direction: row-reverse로 인해 DOM 읽기 순서와 시각적 렌더링이 불일치”처럼 기준까지 명시해서 알려준다고 한다.

꽤 많은 PR을 검토해서 상당 부분을 해결했다고 하는데, 동시에 “약 36%는 자동 감지 자체가 불가능하다”는 것도 명시했다. 드래그앤드롭, 데이터그리드 같은 복잡한 인터랙션 패턴은 “고위험”으로 분류해 에이전트가 자동으로 회피하도록 설계했다고 한다.

2️⃣ 내가 든 생각

디자이너 관점에서 보면, “자동 감지 안 되는 36%”가 오히려 더 눈에 들어왔다. 에이전트가 건드리지 않기로 한 복잡한 인터랙션 패턴들은 사실 접근성 문제가 가장 많이 발생하는 지점이기도 해서다.

alt 텍스트가 있는지, aria-label이 제대로 붙어있는지 같은 건 코드 레벨에서 어느 정도 자동화할 수 있는 영역인 것 같다. 근데 “이 흐름이 키보드만으로 논리적으로 이해되는가”는 결국 사람이 들어가야 하는 부분에 가까운 것 같다. 구조적인 접근성과 경험적인 접근성은 다른 레이어에 있다는 생각이 들었다.

👉🏻 에이전트의 신뢰도를 높이는 방식이 “더 많이 커버하는 것”이 아니라 “명확히 판단하기 어려운 건 건드리지 않는 것”에 있다는 설계가 흥미로웠다. 범위를 의도적으로 좁힌 것이다.

💡 여기서 드는 질문? 접근성을 자동화할 수 있는 범위가 결국 마크업 레이어와 경험 레이어의 경계에 있는 걸까. 디자인 단계에서 “에이전트가 못 보는 것”을 더 의식해서 프로토타입을 만들어야 하는 걸까.

⭐️ 마지막으로, 공부하면서 든 생각

이런 류의 도구를 볼 때 자꾸 같은 질문을 하게 되는 것 같다 — 자동화할 수 있는 것과 사람이 봐야 하는 것의 경계를 어떻게 정하는가. 이번 파일럿은 그 경계를 직접 설명해뒀다는 점에서, 기능 자체보다 판단 기준이 더 공부가 됐다.

---

참고 원문: Building a general-purpose accessibility agent—and what we learned in the process