당신의 예약 흐름은 Google의 첫 페이지에 나타납니다. 스키마 마크업 (Schema markup)은 깔끔합니다. 코어 웹 바이탈 (Core Web Vitals)은 모든 항목에서 녹색을 나타냅니다. 하지만 당신의 사이트에서 방을 예약하려는 AI 에이전트는 여전히 작업을 완료하지 못합니다.

이것은 모순이 아닙니다. 두 개의 서로 다른 시스템이 서로 다른 것을 읽고 있는 것입니다.

크롤러는 읽고, 에이전트는 작동합니다.

검색 엔진 크롤러 (Crawlers)와 AI 에이전트 (Agents)는 종종 같은 종류의 방문자로 이야기되지만, 이들은 근본적으로 다른 일을 수행합니다. 크롤러는 당신의 HTML을 읽고, 링크를 따라가며, 콘텐츠를 인덱싱 (indexing) 합니다. 크롤러는 날짜 선택기를 클릭하거나, 양식을 채우거나, 유효성 검사 오류 (validation error)를 처리할 필요가 전혀 없습니다. 크롤러는 독자입니다.

예약을 완료하려는 에이전트는 이 모든 것을 수행해야 합니다. 체크인 필드를 찾아야 하고, 달력을 열고, 날짜를 선택하고, 양식을 제출하며, 제출이 성공했는지 실패했는지를 이해해야 합니다. 에이전트는 당신의 페이지를 읽는 것이 아니라, 당신의 인터페이스를 작동시키는 것입니다. 그리고 인터페이스를 작동시키려면 읽기 작업에서는 전혀 건드리지 않는 구조, 즉 접근성 트리 (accessibility tree)가 필요합니다.

동일한 픽셀, 다른 머신 인터페이스

배경 아이콘이 있는 클릭 가능한 div로 구축된 "지금 예약하기" 버튼을 예로 들어보겠습니다:

<div class="book-btn" onclick="submitBooking()">
  <img src="calendar-icon.svg" alt="calendar icon">
</div>

시각적으로 이것은 버튼입니다. 구조적으로, 픽셀을 보고 있지 않은 모든 것에게 이것은 이미지 안에 이미지가 들어있는 빈 컨테이너일 뿐입니다. 역할 (role)도 없고, 접근 가능한 이름 (accessible name)도 없으며, 상호작용했을 때 어떤 일이 일어나는지 알 수 있는 방법도 없습니다.

이제 올바르게 구축된 동일한 버튼을 보겠습니다:

<button onclick="submitBooking()">
  <img src="calendar-icon.svg" alt="">
  Book now
...

실제 버튼은 역할이 button이고, 접근 가능한 이름이 "Book now"이며, 네이티브 키보드 작동성 (keyboard operability)을 갖춘 상태로 트리에 안착합니다. alt가 빈 문자열인 것은 아이콘을 장식용으로 표시하여 이름이 오염되지 않도록 합니다. 화면상의 픽셀은 동일합니다. 하지만 머신을 향한 인터페이스는 완전히 다릅니다.

이제 날짜 선택기 (date picker)를 보겠습니다:

<div
  className="date-picker-trigger"
  onMouseEnter={() => setOpen(true)}
...

마우스를 올리면 열리고, 마우스가 벗어나면 닫히며, 모든 상호작용이 포인터(pointer)를 전제로 합니다. 접근성 트리(accessibility tree)에는 '호버(hover)'라는 개념이 없습니다. 에이전트(agent)에게는 키보드 사용자나 스크린 리더(screen-reader) 사용자에게와 마찬가지로, 이 위젯에 진입할 수 있는 진입점(entry point)이 없습니다. 작업이 에러와 함께 실패하는 것이 아닙니다. 그저 갈 곳이 없을 뿐입니다.

이것은 반드시 내재화해야 할 패턴입니다. 눈과 마우스를 전제로 하는 모든 상호작용은 구조적으로 작동하는 그 어떤 것에게도 존재하지 않는 상호작용입니다. 스크린 리더 사용자들은 수년 동안 이러한 벽에 부딪혀 왔습니다. 에이전트 역시 동일한 이유로 동일한 벽에 부딪힙니다. 그들 또한 동일한 트리를 읽기 때문입니다.

하지만 우리는 접근성 스캔을 통과합니다

아마 사실일 것이고, 아마도 무관할 것입니다. 정적 스캐너(Static scanners)는 DOM 스냅샷을 WCAG 규칙에 따라 평가할 뿐, 여러분의 날짜 선택기(date picker)를 열거나, 양식(form)을 제출하거나, 에러 상태(error state)가 렌더링될 때까지 기다려주지 않습니다. 저는 이 간극에 대해 이 시리즈의 이전 글인 Why Static Accessibility Scanners Miss What AI Agents Hit에서 자세히 다룬 바 있습니다. 페이지가 스캔을 통과하더라도, 무언가를 완료해야 하는 존재에게는 여전히 막다른 길일 수 있습니다.

중요한 질문은 "이것이 통과하는가?"가 아닙니다. 질문은 이것이어야 합니다: 화면을 볼 수 없는 존재가 랜딩(landing) 단계에서 확인(confirmation) 단계까지 도달할 수 있는가?

10분 만에 자신의 사이트 감사하기

에이전트가 사이트를 보는 방식을 확인하기 위해 별도의 도구가 필요하지는 않습니다. 여러분의 브라우저에 이미 포함되어 있습니다.

첫째, Chrome이나 Edge에서 DevTools를 열고, Elements 탭의 Accessibility 패널을 통해 예약 또는 결제 흐름을 노드(node) 단위로 따라가 보십시오. 모든 컨트롤은 역할(role)과 접근 가능한 이름(accessible name)을 가지고 있어야 합니다. 클릭 핸들러(click handler)가 있는 div는 에이전트가 보게 될 '아무것도 없음'을 정확히 보여줄 것입니다.

둘째, 마우스를 뽑으십시오. 전체 흐름을 Tab 키로 이동해 보십시오. 여러분이 막히는 곳이라면, 에이전트도 막힙니다.

셋째, 양식의 에러 상태(error state)를 발생시키고, 메시지가 트리(tree)에 나타나는지, 역할(role)이 alert 또는 라이브 영역(live region)인지, 아니면 단지 픽셀(pixels)로만 존재하는지 확인하십시오.

만약 당신의 흐름(flow)이 이 세 가지를 모두 통과한다면, 당신은 우리가 감사(audit)하는 대부분의 프로덕션 사이트(production sites)보다 더 나은 상태에 있는 것입니다. 만약 통과하지 못한다면, 해결 방법은 세상에서 가장 매력적이지 않은 엔지니어링 작업들입니다. 즉, 실제 버튼(real buttons), 실제 레이블(real labels), 키보드 경로(keyboard paths), 그리고 공표되는 상태 변화(announced state changes)를 구현하는 것입니다. 그리고 이 작업들은 이제 두 배의 보상을 가져다줍니다. 이들은 지난 20년 동안 보조 기술(assistive-tech) 사용자들의 접근을 막아왔던 장애물을 제거해 왔으며, 이제는 당신의 인터페이스를 사용하는 가장 최신의 운영자(operators)들의 접근을 무료로 해제해 줍니다.

이 중 그 어떤 것도 새로운 표준이나 "AI 준비성(AI-readiness)" 프레임워크를 요구하지 않습니다. 웹은 이미 그 메커니즘을 갖추고 있습니다. 접근성 트리(accessibility tree)는 언제나 당신의 UI를 위한 기계 판독 가능 인터페이스(machine-readable interface)였습니다. 유일하게 변한 것은 그것을 읽는 기계의 수가 얼마나 많아졌는가 하는 점뿐입니다.