접근성(a11y) 작업을 미루는 데는 공통된 이유가 있다. '기능 먼저, 접근성은 나중에'라는 암묵적 합의다. 그런데 이 순서가 문제다. 키보드 네비게이션이나 포커스 관리 같은 접근성 요구사항은 컴포넌트 구조 깊숙이 연결되어 있어서, 나중에 끼워 넣으려 하면 절반을 뜯어고쳐야 한다. AI 코딩 도구가 널리 쓰이는 지금, 이 문제를 근본에서 바꿀 수 있는 기회가 생겼다.
계획 없이 시작하면, AI도 접근성을 잊는다
dev.to에 올라온 한 글은 이 문제를 정확하게 짚는다. Claude를 활용해 앱을 만들던 개발자가 깨달은 것은 "AI 코드가 나쁜 게 아니라, 내 계획이 엉망이었다"는 점이다. 제대로 된 스펙 없이 작업을 시작하면 AI는 자기 방식대로 데이터 모델과 구조를 결정한다. 그 결과물을 쫓아다니며 수정하는 데 대부분의 시간이 쓰인다.
접근성 컴포넌트는 이 문제가 더 심각하다. 일반적인 기능 스펙에는 '탭 키로 서브메뉴 진입', 'Shift+Tab으로 컴포넌트 이탈', 'aria-disabled 처리'같은 요구사항이 거의 등장하지 않는다. 명시하지 않으면 AI는 당연히 다루지 않는다.
Plan Mode를 접근성 스펙 도구로 쓰기
Claude Code의 Plan Mode(Shift+Tab)는 코드가 한 줄도 없는 빈 폴더에서도 동작한다. 이 모드에서 AI는 파일을 건드리지 않고 구조를 탐색하고 제안하며, 개발자가 놓친 결정을 수면 위로 올린다.
이 워크플로우를 접근성 컴포넌트 설계에 그대로 적용할 수 있다. 네비게이션 컴포넌트를 만든다고 가정하자. Plan Mode에서 대략적인 아이디어를 설명하되, 여기에 접근성 요구사항을 명시적으로 포함시킨다. "WCAG 2.1 기준 키보드 완전 조작 가능", "스크린 리더 사용자와 시각적 키보드 사용자 모두 지원", "포커스 트랩 없이 컴포넌트 진입·이탈 가능" 같은 조건들을 스펙의 첫 페이지에 올려두는 것이다.
그리고 중요한 것은 'what NOT to build'다. 해당 글에서 가장 인상적인 조언 중 하나는 만들지 않을 것을 명시하라는 것이다. 접근성 관점에서 이를 적용하면: "tabindex 값을 임의로 높이지 말 것", "disabled 속성 대신 aria-disabled를 쓸 것", "포커스 이동에 setTimeout을 남용하지 말 것" 같은 가드레일을 스펙에 명시해두는 방식이다. 이 줄들이 없으면 AI는 언젠가 그 방향으로 향한다.
키보드 네비게이션은 인수 기준이 세밀해야 한다
dev.to의 또 다른 시리즈는 React로 완전히 접근 가능한 메인 네비게이션 컴포넌트를 단계별로 구현하는 과정을 상세하게 기록하고 있다. 탭 키 처리만 해도 수용 기준(Acceptance Criteria)이 여덟 개다. 탑 로우의 마지막 링크에서 탭을 누르면 컴포넌트 밖으로 포커스가 나가야 하고, 서브리스트가 열려 있는 상태에서의 버튼 동작은 닫혀 있을 때와 다르게 처리해야 한다.
이 세밀함이 바로 AI에게 전달해야 할 핵심이다. "키보드로 탐색 가능하게 해줘"는 너무 뭉뚱그려진 지시다. 구체적인 인수 기준을 함께 제시해야 AI가 올바른 결정을 내린다. Plan Mode에서 이런 질문을 던져보자: "탑 로우 마지막 아이템에서 Tab을 누르면 어떻게 동작해야 하나?", "서브메뉴가 열린 상태와 닫힌 상태에서 포커스 흐름이 달라지는 경우를 모두 나열해줄 수 있어?"
AI를 치어리더가 아닌 설계 파트너로
Plan Mode 워크플로우에서 핵심 경고가 있다. AI를 자유롭게 브레인스토밍하도록 두면 칭찬과 동의만 돌아온다. 접근성 설계에서도 똑같은 함정이 있다. "이렇게 구현하면 접근성에 문제없지?"라고 물으면 대부분 "네, 좋습니다"가 돌아온다.
대신 이렇게 물어야 한다. "이 구현에서 스크린 리더가 혼란스러울 수 있는 부분은 어디야?", "WCAG 2.1 AA 기준에서 이 컴포넌트가 실패할 수 있는 케이스를 세 가지 들어줘", "tabindex 관리 방식의 대안을 roving tabindex 패턴과 비교해서 설명해줘." AI에게 반론의 규칙을 주어야 제대로 된 설계 파트너가 된다.
그리고 CLAUDE.md(또는 .cursorrules)에 접근성 원칙을 영구 규칙으로 등록해두는 것이 좋다. 매번 프롬프트에 반복하지 않아도 모든 세션에서 그 기준이 살아있게 된다.
접근성은 설계 단계의 문제다
두 흐름이 가리키는 방향은 같다. AI 도구는 코드를 생성하기 전에 '무엇을 만들고 무엇을 만들지 않을 것인지'를 먼저 명확하게 해야 제대로 작동한다. 접근성도 마찬가지다. 포커스 흐름, 키보드 인수 기준, aria 속성 정책, 금지 패턴—이것들은 코드를 다 짜고 나서 QA에서 발견해야 할 체크리스트가 아니라, Plan Mode 첫 화면에 올라와야 할 설계 조건이다.
빠르게 만드는 것과 처음부터 제대로 만드는 것이 더 이상 대립하지 않아도 되는 시대가 왔다. AI와 함께 스펙을 먼저 설계하는 워크플로우가 그 교점을 만든다.