뉴욕의 인기 식당 예약을 잡으려던 이용자가 AI 에이전트에 일을 맡겼다. 이용자가 원하는 것은 간단했다. 빈자리가 열리면 찾아서 예약해 달라는 것이었다. 에이전트도 그 목표를 향해 움직였다. 그런데 결과는 예약 성공이 아니라 예약 플랫폼의 계정 차단이었다.

2026년 9월 보도된 사례에서 벤처투자자 J.C. Bahr-de Stefano는 개인용 AI 비서 Instinct를 이용해 뉴욕의 4 Charles Prime Rib 예약을 시도했다. 에이전트는 예약 가능 여부를 반복 확인하며 시간당 약 200회의 요청을 보냈고, Resy는 비정상적 활동을 이유로 계정을 비활성화했다. 계정은 이후 복구된 것으로 보도됐다.[^1][^2]

이 사건이 보여주는 것은 AI가 예약을 못 했다는 사실보다 사용자가 허락한 행동과 플랫폼이 허용하는 행동이 서로 다를 수 있다는 점이다. 이제 AI는 질문에 답하는 도구를 넘어 실제 계정으로 사이트를 방문하고 요청을 전송하는 실행 주체가 되고 있다. 그때의 실패는 대화창 안에서 끝나지 않는다.

AI 에이전트가 식당 예약을 대신하다 계정이 차단된 문제를 소개하는 표지 삽화. 실제 Resy 화면이 아닌 생성 이미지

이용자는 예약을 원했지, 무제한 호출을 원한 것은 아니다

사람이 사이트를 이용한다면 예약이 없을 때 새로고침을 몇 번 하거나 다음 날 다시 찾을 수 있다. 에이전트는 다르다. 성공 여부를 신속히 확인하고 재시도하는 기능을 가진 만큼, 제한이 없다면 사람보다 훨씬 빠르고 오래 같은 작업을 반복할 수 있다.

이번 사건에서도 문제가 된 것은 'AI를 썼다'는 한 가지 사실로 환원하기 어렵다. 공개 보도에서 확인되는 핵심은 인가되지 않은 에이전트의 반복 접근과 과도한 요청량이다. 언론에 나온 시간당 약 200회는 해당 사례의 보고 수치다. 모든 AI 예약 서비스의 평균 호출량도, 모든 플랫폼의 정해진 차단 임계값도 아니다.[^1]

사용자의 목적을 이루기 위해 '계속 확인해'라는 지시를 따랐더라도, 언제 멈출지와 얼마나 많은 요청이 허용되는지는 별도로 설정돼야 한다. 사용자가 목표를 승인했다는 이유만으로 각각의 외부 시스템 호출까지 승인받은 셈은 아니다.

에이전트의 반복된 예약 시도와 계정 일시 차단을 설명하는 개념도. 여러 레스토랑 화면은 실제 사건 로그가 아닌 설명용 가상 표현

플랫폼이 보호하려는 것은 계정 하나만이 아니다

Resy의 이용약관은 서비스 동작을 방해하거나 접근 제한을 우회하는 행위, 자동화된 수집·크롤링 등을 제한한다. Resy 측 역시 허가받지 않은 제3자 봇이나 AI 에이전트의 독립적인 접근을 허용하지 않는다고 설명했다.[^3][^4]

예약은 수량이 제한된 재화다. 다른 사람보다 훨씬 빠르게 반복 확인하고 예약 가능 시점에 대량 요청을 보내는 자동화가 확산하면, 일반 고객의 접근 기회와 플랫폼의 운영 안정성이 동시에 문제 될 수 있다. 반대로 모든 기계적 접근을 일률적으로 막으면 시각·운동 장애가 있는 사용자나 공식 보조도구를 이용하려는 사람에게도 새로운 장벽이 생길 수 있다.

따라서 실질적 질문은 'AI 예약을 허용할 것인가, 금지할 것인가'라는 이분법보다 더 어렵다. 누가 누구를 대신하는지, 어떤 속도와 범위에서 접근하는지, 플랫폼이 그 접근을 어떻게 식별하고 허가하는지가 필요하다. 일부 서비스가 공식 파트너십이나 정해진 API를 제공한다면 그 경로는 무단 자동화와 구별해야 한다.

예약 플랫폼이 봇·자동화 차단, 레스토랑 보호, 공정한 접근 기회, 서비스 안정성을 이유로 비정상 패턴을 탐지한다는 일반론 도표

로그인 권한과 행동 권한은 다르다

에이전트가 사용자 계정으로 로그인할 수 있다는 것은 그 계정과 연결된 모든 행동을 얼마든지 수행해도 된다는 뜻이 아니다. 파일을 읽을 권한, 이메일을 전송할 권한, 결제할 권한, 예약을 취소할 권한은 같은 범주가 아니다. 같은 예약 업무 안에서도 식당 탐색과 최종 예약 확정은 위험이 다르다.

10월 17일 공개된 AI Engineer의 에이전트 권한 논의에서 Keycard·JPMorgan Chase·AAuth 관계자들은 전통적인 OAuth 범위가 에이전트의 개별 업무를 통제하기엔 지나치게 거칠 수 있다고 지적했다. 그래서 이용자가 맡긴 미션, 조직과 서비스의 정책, 현재 작업의 실행 맥락을 함께 반영하는 런타임 권한 확인을 논의했다.[^5]

여기서 중요한 구분이 생긴다. '토요일 저녁 식당을 찾아줘'는 탐색 목적이고, '후보가 있으면 내 카드로 취소 수수료가 걸린 예약을 확정해'는 금전적 결과가 있는 승인이다. 후자는 예약 시간과 인원, 수수료 한도, 선호 식당, 재시도 범위를 구체적으로 요구한다. 기존 권한 모델이 전자를 허용한다고 후자까지 자동 허용해선 안 된다.

사고가 났을 때 법적 책임이 반드시 사용자 한 사람에게 모두 귀속된다는 뜻은 아니다. 계약 조건, 에이전트 제공사의 설계, 사용자의 지시, 플랫폼의 통제가 함께 검토될 수 있다. 그러나 계정 차단과 취소 수수료처럼 직접적인 운영상 결과는 사용자가 먼저 마주칠 수 있다는 것은 분명하다.

AI 에이전트의 시간 절약·선택지 확대·자동화 편의와 함께 사용자 계정과 평판에 대한 책임이 커진다는 설명 카드

좋은 실행 에이전트는 얼마나 많이 하는지가 아니라 언제 멈추는지 안다

실제 제품을 설계한다면, '예약을 찾는 도구'에는 목표만큼 경계가 중요하다. 몇 가지는 모델이 매번 알아서 판단하도록 맡기기보다 시스템이 확정적으로 집행하는 편이 낫다.

첫째, 대상 범위다. 사용자로부터 승인받은 식당·날짜·인원·예약 플랫폼 외에는 탐색을 확장하지 않는다. 둘째, 호출 예산이다. 분당·시간당 호출 제한과 작업 전체 요청량, 동작 종료 시한을 설정한다. 응답이 없으면 곧바로 재시도하기보다 실패와 결과 미확인을 구분해야 한다.

셋째, 행동별 승인이다. 읽기와 조회는 비교적 낮은 위험이지만, 예약 확정·취소·결제·계정 설정 변경은 별도의 승인 지점으로 나눈다. 넷째, 감사 가능성이다. 누가 어떤 목적을 지시했고 에이전트가 언제 어느 도구를 호출했는지, 플랫폼이 무엇을 돌려줬는지를 사후 확인할 수 있어야 한다.

이 구분은 에이전트의 성능을 떨어뜨리기 위한 규칙이 아니다. 실패했을 때 같은 일을 무한 반복하지 않고, 필요한 순간에 사람의 승인을 받으며, 허용된 범위 안에서 끝까지 업무를 수행하게 하는 설계다. 앞선 패널은 실행에 소모할 수 있는 자원을 토큰과 시간에 함께 묶는 '예산' 방식과 모델의 판단부와 실제 자격 증명·실행부를 분리하는 아키텍처를 소개했다.[^5]

권한 범위 설정, 사용량 모니터링, 서비스 약관 확인, 사용자 책임을 정리한 AI 에이전트 이용자 점검표

경쟁력이 될 것은 더 강한 에이전트만이 아니다

예약 플랫폼 입장에서도 모든 AI 트래픽을 인간과 구별할 수 없는 봇으로 취급하는 데 한계가 있을 수 있다. 신뢰할 수 있는 에이전트 ID, 공식적인 접근 경로, 할당량, 작업 목적을 공유할 수 있다면 자동화를 쓰는 사용자와 그렇지 않은 사용자를 더 일관되게 보호할 여지가 있다. 다만 개별 기업이 어떤 연동을 실제 제공하는지와 그 조건은 별도로 확인해야 한다.

에이전트 개발자에게는 화면을 잘 조작하는 능력만큼 중요한 제품 지표가 생긴다. 사용자가 맡긴 일을 성공적으로 수행했는가뿐 아니라, 얼마나 많은 외부 요청을 보냈는가, 몇 번 예외가 발생했는가, 승인받지 않은 영역에 접근하지 않았는가, 사고 시 행동을 재구성할 수 있는가를 함께 측정해야 한다.

이용자에게도 사용법의 기준이 달라진다. 처음 연결할 때 로그인만 허용하고 잊는 대신 작업 목표, 중지 시각, 재시도 횟수, 결제·취소 권한을 설정하고 중간 활동 내역을 볼 수 있어야 한다.

AI가 대신 행동하는 시대에 좋은 자동화의 기준은 '얼마나 끈질기게 일하는가'가 아니다. 목표를 달성하려는 능력과 허용된 경계를 지키는 능력이 동시에 작동하는가다. 식당 예약 계정 하나가 막힌 사건은 작지만, 같은 문제가 쇼핑·금융·업무 도구로 넓어질 때 그 비용은 작지 않을 수 있다.

사용자·AI 개발자·플랫폼이 각각 권한 설정, 속도 제한, 명확한 정책으로 안전한 에이전트 환경을 만들어야 한다는 결론 카드

출처

[^1]: CNN, “Now AI is trying to gobble up dinner reservations,” 2026-09-23. https://kesq.com/money/cnn-business-consumer/2026/09/23/now-ai-is-trying-to-gobble-up-dinner-reservations/ [^2]: Business Insider, “This VC used AI to try to snag a restaurant reservation. Resy wasn't having it,” 2026-09. https://www.businessinsider.com/resy-suspends-vcs-account-ai-agent-reservation-attempt-2026-9 [^3]: Resy, Terms of Service (조회 시점 2026-10-23). https://resy.com/terms [^4]: Bon Appétit, “Are AI-Made Reservations Fair?”, 2026. https://www.bonappetit.com/story/are-ai-made-reservations-fair [^5]: AI Engineer, “An AI Agent Got Its User Banned From Resy — Keycard, JPMorgan Chase & AAuth”, 2026-10-17. https://www.youtube.com/watch?v=IavxrdVnwXM