속도와 접근성은 트레이드오프가 아니다
AI 코딩 도구가 프로토타이핑 속도를 끌어올리면서 '일단 돌아가게 만들고 나중에 다듬자'는 사고방식이 팀 안에 슬며시 자리를 잡고 있다. 그런데 '나중에 다듬을 것들' 목록에 접근성이 끼어드는 순간, 이건 기술 부채가 아니라 사용자 배제로 이어진다. 스크린리더를 쓰는 사용자, 키보드만으로 탐색하는 사용자, 저시력 사용자—이들에게 접근성 없는 폼은 '불편한 UI'가 아니라 '사용 불가능한 제품'이다.
Codex로 하루 만에 앱을 만든다는 것의 의미
dev.to에 공개된 Captrix AI 개발기는 OpenAI Codex를 1차 코딩 에이전트로 삼아 Next.js + TypeScript + Tailwind CSS 기반의 브라우저 캡션 스튜디오를 단기간에 완성한 사례다. 영상 업로드 → 음성 인식 → 캡션 편집 → 스타일 적용 → 플랫폼별 포맷 미리보기 → 내보내기까지 이어지는 전체 워크플로우를 하나의 앱 안에 구현했다. 여기서 주목할 건 결과물이 아니라 프로세스다. 개발자는 기능을 완성한 뒤 테스트하는 대신 '빌드 → 타입 체크 → Vercel 배포 → TestSprite CLI 테스트 → 수정 → 기록'이라는 루프를 반복했다. 작은 단위로 만들고, 바로 검증하고, 실패를 기록하는 방식이다. 이 루프가 없었다면 캡션이 침묵 구간에도 남아 있거나, 타임라인 콘텐츠가 인스펙터 아래로 잘리는 문제를 출시 후에야 발견했을 것이다.
그런데 AI는 접근성을 '알아서' 챙겨주지 않는다
문제는 여기서 시작된다. Codex든 Claude든 GitHub Copilot이든, AI가 생성하는 폼 코드를 그대로 쓰면 십중팔구 접근성 마크업이 빠져 있다. placeholder만 있고 <label>이 없는 입력 필드, aria-label 없이 아이콘만 있는 버튼, fieldset과 legend 없이 나열된 라디오 버튼—이것들은 시각적으로는 멀쩡해 보이지만 스크린리더 앞에서는 무너진다. dev.to의 접근성 폼 라벨 가이드가 짚는 핵심이 정확히 이 지점이다. 라벨은 단순한 UI 요소가 아니다. 입력 필드가 무엇을 요구하는지 보조 기술이 '읽을 수 있게' 연결하는 코드 수준의 계약이다.
폼 라벨, 실수가 반복되는 세 지점
접근성 가이드가 반복해서 강조하는 실수 패턴은 놀랍도록 일관적이다. 첫째, placeholder를 라벨 대신 쓰는 것. 타이핑을 시작하는 순간 사라지고, 스크린리더가 라벨로 인식하지 않으며, 명도 대비가 WCAG 기준을 거의 항상 미달한다. placeholder는 형식 힌트(예: MM/DD/YYYY)로만 써야 하고, 라벨은 반드시 별도로 존재해야 한다. 둘째, 필수 필드를 빨간 별표 하나로만 표시하는 것. 색상 단독으로는 의미를 전달할 수 없다. required 속성과 시각적 텍스트("필수")를 함께 써야 하며, 별표를 쓴다면 aria-hidden="true"로 스크린리더가 건너뛰게 하고 폼 상단에 범례를 명시해야 한다. 셋째, 라디오 버튼이나 체크박스 그룹에서 <fieldset>과 <legend>를 생략하는 것. 그룹 컨텍스트 없이 "이메일, 라디오 버튼"만 들리는 스크린리더 사용자는 무엇을 선택하는지 알 수 없다.
AI 워크플로우에 접근성 체크를 '루프 안으로' 넣어라
Captrix 개발기가 보여준 '빌드 → 검증 → 수정' 루프의 진짜 가치는 테스트를 마지막 단계가 아닌 개발 흐름의 일부로 만든 것이다. 접근성도 똑같이 적용할 수 있다. AI가 폼 컴포넌트 코드를 생성하면, 그 즉시 axe DevTools나 Lighthouse 접근성 감사를 돌리고, <label>-for-id 연결이 올바른지, aria-label이 의미 있는 문자열인지, fieldset이 빠진 그룹은 없는지 확인하는 것이다. 이걸 PR 체크리스트나 CI 파이프라인에 넣으면 AI가 생성한 코드가 아무리 빠르게 쌓여도 접근성 구멍이 누적되지 않는다. 검증 루프가 속도를 잡아먹는 게 아니라, 검증 루프가 없는 속도가 나중에 더 큰 비용을 만든다.
시사점: AI 프롬프트에 접근성 컨텍스트를 심어라
실용적인 접근은 AI에게 코드를 요청할 때부터 접근성 요구사항을 컨텍스트로 제공하는 것이다. "Next.js에서 이메일 입력 폼 만들어줘"가 아니라 "Next.js에서 WCAG 2.1 AA를 준수하는 이메일 입력 폼을 만들어줘. <label>과 for-id 연결 필수, placeholder는 형식 힌트로만, 필수 필드는 required 속성과 시각적 텍스트 병기"처럼 요청하면 AI 출력의 품질이 달라진다. 완벽하지 않을 수 있지만, 수정 범위가 현저히 줄어든다. 프롬프트가 팀의 접근성 표준을 담는 그릇이 되는 셈이다.
전망: 접근성은 'AI 이후'에도 사람이 책임지는 영역
AI 도구가 아무리 발전해도 접근성 판단의 최종 책임은 개발자에게 있다. 자동화 도구가 잡아낼 수 있는 접근성 이슈는 전체의 30~40%에 불과하다는 것이 업계의 일반적인 추정이다. 나머지는 실제 보조 기술로 직접 확인해야 한다. Captrix가 테스트 루프로 런타임 버그를 잡아낸 것처럼, 접근성도 '릴리즈 전 한 번 검토'가 아니라 개발 흐름 전반에 걸쳐 검증하는 구조를 설계해야 한다. AI가 속도를 주는 시대일수록, 그 속도로 만들어진 제품이 더 많은 사람에게 닿을 수 있도록 접근성을 루프 안에 단단히 묶어두는 것—그게 지금 프론트엔드 개발자가 설계해야 할 진짜 워크플로우다.