우리는 7월 한 달 동안 AI 어시스턴트가 암스테르담 레스토랑의 테이블을 얼마나 잘 예약할 수 있는지 측정했습니다. 200개의 장소, 하나의 브라우저 에이전트(browser agent), 하나의 작업: 레스토랑을 찾고, 이해하고, 실제 날짜와 인원수에 대한 예약 가능 여부를 확인한 뒤, 최종 예약 단계에 도달하는 것입니다. 우리는 실제로 예약을 제출하지는 않았습니다.

연구를 통해 수치를 발표했습니다. 이 포스트에서는 우리가 그 어떤 것보다 더 많이 목격한 실패 모드(failure mode)에 대해 이야기하고자 합니다. 왜냐하면 이는 해결 가능한 문제이며, 어시스턴트를 구축하는 대부분의 사람들이 결국 마주하게 될 문제이기 때문입니다.

실패 모드: 예약 위젯(booking widget).

예약 제품에 비용을 지불하는 대부분의 레스토랑은 이를 iframe으로 삽입합니다. 사람이 페이지를 방문하여 '예약하기(Reserve)'라고 표시된 버튼을 보고 클릭하면, 달력과 시간 선택기가 포함된 모달(modal)이 열리고, 인원수, 이름, 전화번호를 입력한 뒤 확인을 받습니다. 이 흐름은 사람이 그것을 보고, 인식하고, 해석할 수 있기 때문에 작동합니다.

실제 브라우저를 구동하는 에이전트는 다른 것을 봅니다.

에이전트가 얻는 것

부모 페이지(parent page)에는 버튼이 포함되어 있으며, 예약에 관한 다른 정보는 없는 경우가 많습니다. 버튼의 onclick 핸들러는 다른 오리진(origin)의 iframe을 엽니다. 해당 iframe 내부에서는 다음과 같은 상황이 발생합니다:

• 동일 출처 정책(same-origin policy)에 따라 부모 페이지에서 DOM에 접근할 수 없습니다.
• 필드들은 종종 네트워크 라운드 트립(network round-trip) 이후 마운트(mount)되는 클라이언트 사이드 앱(client-side app)에 의해 렌더링됩니다.
• 예약 가능 여부는 위젯이 마운트된 후 호출하는 내부 API에 존재하며, 이 URL에 대해 에이전트는 액세스 토큰(access token)을 가지고 있지 않습니다.
• 확인 단계는 iframe 내부의 텍스트로 표시되거나, 부모 페이지가 절대 볼 수 없는 리다이렉트(redirect)로 처리됩니다.

부모 페이지를 읽는 에이전트는 버튼 너머에 예약 흐름이 존재하는지조차 알 수 없습니다. 버튼을 클릭하는 에이전트는 부모 수준에서 조사(introspect)할 수 없는 새로운 브라우징 컨텍스트(browsing context)를 얻게 됩니다. 프레임에 대한 전체 접근 권한을 가진 에이전트는 요소가 안정적이고, 포커스(focus)가 올바르게 처리되며, 캡차(captcha)가 발생하지 않고, 위젯이 자동화를 감지하여 거부하지 않는다면 클릭과 타이핑을 시뮬레이션하여 위젯을 구동할 수도 있습니다. 하지만 단 한 번의 예약을 위해 고려해야 할 "만약(if)"의 조건이 너무나 많습니다.

대부분의 사이트가 대신 게시하는 것

암스테르담 샘플 조사 대상인 163개의 작동 중인 사이트 전반에 걸쳐, 우리는 식당과 그 예약에 대한 기계 판독 가능(machine-readable) 설명을 확인했습니다. 9곳이 이를 갖추고 있었습니다. 9곳 모두 SEO 플러그인에 의해 생성된 Restaurant 또는 LocalBusiness 스키마(schema)였습니다. 이들은 장소의 이름, 주소, 영업시간, 요리 유형, 가격대, 리뷰 수와 같은 장소 정보를 설명합니다.

하지만 예약 방법을 설명하지는 않습니다.

Schema.org에는 Reservation 및 ReserveAction 타입이 있습니다. 이들은 존재합니다. 하지만 널리 사용되지는 않습니다. 그리고 이들이 나타나는 곳에서도, 일반적으로 완료된 예약을 설명할 뿐, 예약을 생성하기 위한 호출 가능한 인터페이스(callable interface)를 설명하지는 않습니다.

액션(Action)은 에이전트가 구성할 수 있는 형태(shape)를 갖추어 POST 요청을 보낼 수 있는 URL입니다. 반면 설명(Description)은 에이전트가 당신에게 다시 인용할 수 있는 문단입니다. 우리가 확인한 모든 사이트는 설명을 게시했습니다. 하지만 액션을 게시한 곳은 단 한 곳도 없었습니다.

ChatGPT 모먼트

하네스(harness)를 구축하는 과정 중 한 순간이 이를 요약해 줍니다. 우리는 데모 인스턴스에 작은 예약 API를 배치하고, 그 뒤에 엔드포인트(endpoint), 필수 필드, 응답 형태(response shape)를 산문 형식으로 설명하는 평범한 HTML 페이지를 두었습니다. 위젯이 아니라, 단지 페이지일 뿐이었습니다.

우리는 ChatGPT에게 이를 통해 예약을 진행해 달라고 요청했습니다. ChatGPT는 페이지를 읽고, API를 이해했으며, 필수 필드를 나열한 뒤, 자신의 웹 도구로는 POST 요청을 보낼 수 없다고 정중하게 보고했습니다. 행동할 수 없었던 것입니다. 페이지는 인간을 위한 것이었고, API는 에이전트를 위한 것이었으며, 어시스턴트는 그 사이에 앉아 어느 쪽도 연결하지 못한 채 머물러 있었습니다.

어시스턴트는 페이지가 아니라 도구(tools)를 통해 행동합니다. 그들은 페이지를 읽을 뿐, 버튼을 누르지 않습니다.

에이전트 준비가 된(agent-ready) 상태란 실제로 어떤 모습일까

실질적으로 변화를 만들어내는 순서대로 나열하면 다음과 같습니다:

1. 호출 가능한 예약 엔드포인트(endpoint). HTTP, JSON, 버전 관리 포함. 가용성 조회, 슬롯 생성, 취소 기능. 업체가 교체할 수 있는 API 키를 통한 인증. 이것이 바로 에이전트의 도구가 가리키게 될 대상입니다.
2. 이를 선언하십시오. .well-known URL, 또는 schema.org의 ReserveAction 블록, 또는 Model Context Protocol 서버, 혹은 이 세 가지 모두를 활용하십시오. 액션이 존재하기만 한다면 발견(discovery)은 쉬운 일입니다.
3. 시각적 위젯을 유지하고 싶다면 유지하십시오. 두 경로 모두 결국 동일한 테이블(데이터)에 도달하게 됩니다.

이 모든 과정에서 웹사이트를 재설계할 필요는 없습니다. 위젯은 그대로 유지됩니다. 다만 에이전트에게 유리창 뒤에 가려져 있지 않은 문을 열어주는 것뿐입니다.

Model Context Protocol (MCP)에 관한 참고 사항

MCP는 제가 이 프로젝트를 마친 후 도달하게 된 지점입니다. 이는 어시스턴트가 호출할 수 있는 도구(tools)를 노출하기 위한 프로토콜이며, "내 어시스턴트가 어떻게 이 특정 동작을 수행하는가"라는 질문에 대해 오늘날 가장 널리 지원되는 답변에 가장 가까운 기술입니다. OpenAI, Anthropic, Google, 그리고 Perplexity 모두 어떤 형태로든 이를 사용하고 있습니다. MCP 클라이언트(client)를 갖춘 어시스턴트라면 페이지를 직접 보지 않고도 사용 가능한 도구 목록을 나열하고, 입력값을 이해하며, 이를 호출할 수 있습니다.

예약을 위해 우리가 구축한 MCP 서버에 대해서는 다음 포스트에서 작성하겠습니다. 이번 글은 문제 자체에 초점을 맞추었습니다. 왜냐하면 문제는 대부분의 빌더들이 하나의 iframe을 하나씩 다루며 고생 끝에 깨닫게 되는 부분이기 때문입니다.

만약 여러분이 현실 세계의 동작을 완료해야 하는 어시스턴트를 구축하고 있다면, 어떤 부분에서 문제가 발생하는지 진심으로 듣고 싶습니다.

전체 현장 연구, 방법론 및 종합 데이터: https://g-lab.studio/research/amsterdam-restaurants-2026