7월에 실시된 암스테르담 레스토랑 200곳에 대한 테스트 결과, 현재의 AI 어시스턴트들은 예약 위젯이 iframe 내부에 숨겨져 있어 테이블 예약을 완료하지 못하는 것으로 나타났습니다.

iframe이 에이전트를 차단하는 이유

대부분의 온라인 예약 도구는 임베디드 iframe 형태로 제공됩니다. 방문자가 "Reserve" 버튼을 클릭하면 달력이 나타나고 사용자가 시간대를 선택합니다. 사람에게는 이 과정이 정상적으로 작동하지만, AI 에이전트에게는 진행이 멈춰버립니다.

  • 에이전트는 메인 HTML 페이지를 파싱합니다.
  • 예약 버튼은 다른 도메인의 URL을 가리킵니다.
  • 브라우저는 해당 URL을 iframe 내에 로드하여 부모 페이지로부터 격리합니다.

동일 출처 정책(same-origin policy)으로 인해 부모 페이지의 스크립트가 iframe의 DOM을 읽거나 네트워크 호출을 가로채는 것이 차단되기 때문에, 페이지 콘텐츠를 읽고 HTTP 요청을 보내는 AI 에이전트는 버튼만 볼 수 있습니다. 달력, 시간대 또는 예약 확인 흐름은 전혀 볼 수 없습니다. 설령 버튼을 클릭하더라도 캡차(captcha)를 해결하거나, 레이아웃 변경에 대응하거나, 많은 예약 서비스가 채택하고 있는 자동화 방지 방어 기제를 우회해야 합니다.

누락된 기계 판독 가능 링크

실제 운영 중인 163개의 레스토랑 사이트를 별도로 감사한 결과, 기계 판독이 가능한 예약 데이터를 노출하는 곳은 단 9곳뿐이었습니다. 이 9곳은 schema.org 마크업을 사용하여 이름과 주소 같은 기본 정보를 나열했지만, 에이전트가 호출할 수 있는 예약 액션(reservation actions)을 포함한 곳은 없었습니다. Schema.org는 이를 위해 ReserveAction과 같은 타입을 정의하고 있지만, 대부분의 사이트는 실행 가능한 지침이 아닌 설명적인 메타데이터만 게시하고 있습니다.

실제로 어시스턴트는 단순히 작업이 무엇인지가 아니라, 작업을 어떻게 수행해야 하는지를 알려주는 구조화된 데이터를 찾습니다. ReserveAction이나 그에 상응하는 엔드포인트가 없으면, 에이전트는 앞서 설명한 것처럼 신뢰할 수 없는 방식인 인간의 클릭을 흉내 내는 방식으로 되돌아갈 수밖에 없습니다.

UI를 갈아엎지 않고도 가능한 실질적인 해결책

  1. 예약 API 게시 – 예약 가능 여부 조회 및 예약 생성을 위한 JSON 요청을 수락하는 경량 HTTP 엔드포인트를 만듭니다. API는 날짜, 시간, 인원수, 예약 확인 코드와 같은 필드를 반환합니다. 어떤 에이전트든 페이지를 렌더링하지 않고도 이를 사용할 수 있습니다.
  2. API 발견 가능성 확보 – /.well-known/booking과 같이 잘 알려진 위치에 포인터를 배치하거나, 페이지의 schema.org 마크업에 ReserveAction 항목을 포함합니다. 이를 통해 스크래핑 없이도 에이전트에게 "이곳에는 프로그래밍 방식으로 예약할 수 있는 방법이 있다"는 것을 알려줄 수 있습니다.
  3. Model Context Protocol (MCP) 도입 – MCP를 사용하면 어시스턴트가 입력을 전달하고 구조화된 출력을 받으며 외부 도구를 직접 호출할 수 있습니다. 주요 AI 제공업체들이 이미 MCP를 지원하고 있으므로, MCP 호환 엔드포인트를 구현한 레스토랑은 에이전트가 마치 내장된 함수처럼 호출할 수 있습니다.

이러한 단계들을 통해 인간 사용자를 위한 시각적 iframe은 유지하면서도, 에이전트에게는 동일한 예약 데이터에 접근할 수 있는 깔끔하고 신뢰할 수 있는 경로를 제공할 수 있습니다.

요약

iframe 내에 달력을 임베드하는 것은 인간을 위한 시각적 흐름을 보호하지만 AI 어시스턴트에게는 눈을 가리는 것과 같습니다. 적절하고 문서화가 잘 된 예약 API를 추가하고 이를 표준 메타데이터나 MCP를 통해 알리는 것은 웹사이트를 전면 개편하지 않고도 새로운 예약 채널을 여는 방법입니다. 이러한 노력은 차세대 디지털 어시스턴트에 대한 가시성을 높여주며, 위험 요소는 기존 UI에 이미 사용 중인 것과 동일한 보안 제어를 통해 관리할 수 있습니다.