얼마 전 에이전틱 코딩 (Agentic Coding)이라는 토끼굴에 빠졌다가, 이제 그 심연에서 돌아와 제가 기술 분야에서 가장 좋아하는 두 가지 주제인 AI와 웹 접근성 (Web Accessibility)에 대해 긴 휴식 끝에 짧은 글을 쓰려고 합니다.

에이전틱 코딩 (Agentic Coding)이 웹 접근성 (A11Y)에 어떤 영향을 미쳤는지, 왜 우리가 현재와 같은 상황에 처해 있는지, 그리고 우리가 매일 에이전트가 출력하는 코드의 접근성 (A11Y) 수준을 어떻게 개선할 수 있는지 분석해 보겠습니다.

매년 WebAIM은 상위 100만 개의 홈페이지 접근성에 대한 "Million" 보고서를 발표합니다. 이 보고서는 재미있는 사실, 그래프, 그리고 무엇보다 ✨데이터✨를 포함한 믿을 수 없을 정도로 통찰력 있는 심층 분석을 제공합니다. 여기서 언급되는 대부분의 수치는 해당 보고서에서 가져온 것이므로, 꼭 한번 읽어보시길 권합니다. 그럴 가치가 있습니다!

파트 1: 무너진 기반

이 시점에서 우리 모두는 AI 모델이 테라바이트 단위의 방대한 데이터로 학습된다는 점을 폭넓게 이해하고 있습니다. 이 데이터에는 엄청난 양의 공개 코드가 포함되어 있으며, 우리 모두가 알다시피 대부분의 코드는 접근성이 확보되어 있지 않습니다. 업계 데이터는 디지털 제품들이 출시 직후부터 접근성 준수 사항을 심각하게 위반하고 있음을 지속적으로 보여줍니다.

WebAIM은 이를 확인해 줍니다: 분석된 페이지의 95% 이상에서 최소 하나 이상의 감지 가능한 WCAG 2 실패 사례가 발견되었으며, 페이지당 평균 오류 수는 56.1개였습니다.

통찰력 있는 부분은 올해 보고서(2026년)가 지난 수년간 이어온 느린 진전이 역전되었음을 나타내며, 오류가 전년 대비(YoY) 10.1% 증가했음을 보여준다는 점입니다.

이것이 에이전틱 코딩 (Agentic Coding)의 폭발적 증가와 직접적인 연관이 있는 것일까요?

파트 2: 근원에서의 오염

LLM을 통계적으로 흔한 것을 출력하도록 최적화된 _패턴 매칭 엔진 (pattern-matching engines)_이라고 생각하십시오. 즉, LLM은 위에서 언급한 나쁜 습관들을 그대로 모방한다는 의미입니다. 이를 알고 있다면, 우리는 접근성이 없는 코드가 코드베이스에 몰래 스며드는 것을 알아차리지 못할 수도 있으므로, 접근 방식에 있어 **선제적 (proactive)**으로 대응할 책임이 있습니다.

에이전트에게 "코드를 접근 가능하게 만들어줘"라고 요청하는 것만으로는 충분하지 않다는 점을 명심해야 합니다. 현실적으로 모델들은 ARIA 레이블을 여기저기에 남발하며 과잉 보상하는 경향이 있으며, ✨데이터✨가 이를 증명합니다: 평균적으로 ARIA를 사용하는 사이트는 페이지당 59.1개의 오류가 발생한 반면, ARIA를 사용하지 않는 기본적인 사이트는 "단 "42개에 불과했습니다.

엔지니어로서 우리의 가치는 그 어느 때보다 의사결정을 내리고, 회사의 전체적인 맥락을 고려하여 지식을 적용하는 능력에서 나옵니다. 특히 사람들이 UI를 사용하는 방식에 있어서는 맥락 (Context)이 매우 중요합니다.

에이전트는 당신의 UI가 아름답다고 말해주겠지만, (현재로서는) 스크린 리더 (screen reader) 오디오 파이프라인을 네이티브하게 등록하는 것은 여전히 불가능할 것입니다. 따라서 이러한 사용 사례 (use-cases)를 포착하고 스크린 리더가 효율적으로 파싱할 수 있는 코드를 구현하는 것은 여러분의 책임입니다.

이러한 사용 사례를 포착하는 가장 좋은 방법은 수동 테스트 (manual testing)를 거치는 것입니다. 수동 테스트는 실제 인간이 웹사이트를 탐색하는 방식 그대로 웹사이트를 사용하게 해주기 때문입니다.

그렇다면 에이전틱 코딩 (agentic coding) 시대에 우리 코드의 접근성 (A11Y)을 개선하기 위해 어떤 접근 방식을 취해야 할까요?

파트 3: "시프트 레프트 (Shift-Left)" 접근 방식

역사적으로 접근성 (A11Y) 테스트는 항상 사후 고려 사항으로 취급되어 왔습니다. 즉, 애플리케이션이 완전히 구축된 후, 또는 심지어 프로덕션 (production)에 배포된 후에 수행되었습니다. 그리고 우리 모두는 이 단계에서 접근성 문제를 수정하는 것이 믿기 힘들 정도로 비용이 많이 들고 느릴 수 있다는 점을 알고 있습니다.

테스트 타임라인의 변화

전통적 방식:  [ 디자인 ] ──> [ 코드 ] ──> [ QA ] ──> [ 프로덕션 ] ──> ⚠️ [ 접근성 (A11Y) 감사 ]

시프트 레프트: [ 디자인 ] ──> [ 코드 + 접근성 (A11Y) 스캔 ] ──> [ QA ] ──> [ 프로덕션 ]
...

"시프트 레프트 (Shift-Left)" 접근 방식은 이름 그대로입니다. 접근성 감사 (accessibility auditing)를 타임라인의 가능한 한 시작 부분(왼쪽)으로 이동시키는 것입니다. QA 팀이나 최종 사용자가 위반 사항을 발견할 때까지 기다리는 대신, 코드가 활발히 작성되는 동안 접근성 (A11Y) 체크를 실행합니다.

벌써 여러분이 이렇게 말하는 소리가 들리는 것 같네요. "아니 Chris, 우리 플랫폼은 이미 CI 파이프라인에 접근성 (A11Y) 체크를 통합해서 사용자 경험이 저하되지 않도록 관리하고 있고, Lighthouse 점수도 평균 97점이며 WCAG AA를 준수하고 있다고요." 하지만 모든 팀에게 이 방식이 당연한 것은 아닐 수 있습니다. 특히 여러분만큼 접근성을 중요하게 생각하지 않는 팀이라면 더욱 그렇습니다.

이 접근 방식 설정하기

제가 사용하는 설정을 공유해 드릴 테니, 여러분의 상황에 맞게 조정해 보세요.

먼저, Playwright와 axe-core 플러그인을 설치합니다:

npm install -D @playwright/test @axe-core/playwright
npx playwright install --with-deps chromium

다음으로, 주요 경로 (routes)를 스캔할 수 있도록 자동화된 테스트 스위트를 설정합니다:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

...

파트 4: 에이전트에게 규칙 가르치기

테스트를 자동화하는 것은 절반의 성공일 뿐입니다. 에이전틱 코딩 (Agentic Coding) 루프를 실제로 해결하려면, 이 컨텍스트를 에이전트의 두뇌에 직접 주입해야 합니다.

다음으로, 앞서 언급했던 잘못된 ARIA 오버라이드 (overrides)를 기본값으로 사용하지 않고, 테스트 실패를 정확히 처리하도록 AI 에이전트에게 지시하는 SKILL 설정 파일을 생성합니다.

📄 파일: .agents/skills/a11y-shift-left-testing.md

---
name: a11y-shift-left-testing
description: 이 프로젝트의 UI가 구축, 편집 또는 검토될 때, 그리고 접근성이 아직 검증되지 않았을 때마다 사용합니다. UI 컴포넌트, 페이지의 변경 사항이 발생하거나 WCAG 준수 여부를 검토하라는 요청이 있을 때 트리거됩니다. 사소하지 않은 JSX 변경 이후에는 선제적으로 스캔을 제안합니다.
...

이 파일을 주의 깊게 읽으셨다면 (읽으셨겠죠?), 아마 참조 파일 (reference file)이 있다는 것을 눈치채셨을 겁니다. 이 파일의 유일한 목적은 에이전트가 린터 (linter)의 경고를 없애기 위해 모든 곳에 aria-label을 마구잡이로 붙이는 것을 방지하는 것입니다.

📄 파일: .agents/a11y-shift-left-testing/references/common-fixes.md

# 일반적인 axe-core 위반 사항 및 근본 원인 해결 방법

## `button-name` / `link-name`
...

결론: 선순환 구조

우리는 에이전틱 코딩 (Agentic Coding)이 웹 접근성 (Web Accessibility)과 얼마나 깊게 연결되어 있는지 종종 잊곤 합니다. 접근성이 높고 의미론적인 (semantic) 코드는 본질적으로 구조화되어 있고, 결정론적 (deterministic)이며, 깔끔합니다. 이는 LLM이 코드를 파싱 (parse)하고 업데이트하는 것을 훨씬 더 쉽게 만들어 줍니다.

접근 가능한 코드를 작성하는 것은 당신의 AI 에이전트의 생산성과 직접적이고 측정 가능한 상관관계를 가집니다. 그러니 반드시 접근 가능한 코드를 작성하도록 하세요. 전 세계 13억 명의 장애인을 위해서가 아니라, 주주들을 위한 가치를 창출하기 위해서라도 말입니다. :)