우리 AI가 존재하지 않는 호텔을 예약했다 — 그리고 수학은 이미 그럴 줄 알았다
제가 우리 여행 어시스턴트가 존재하지도 않는 호텔을 확정하는 것을 처음 지켜봤을 때, 데모룸에서는 실제로 박수가 터져 나왔습니다.
한 테스터가 코스타리카에서 1박에 $200 미만의 럭셔리 에코 로지를 요청했습니다. 모델은 "Tabacon Springs Eco-Lodge"를 내놓았습니다 — 멋진 문구, 그럴듯한 1박 요금, 확정 화면까지. 읽기에는 아름답습니다. 그런데 그것은 실재하는 두 개의 숙소, Tabacon과 Nayara Springs가 하나의 허구적 장소로 녹아든 것입니다. Tabacon Springs Eco-Lodge라는 곳은 존재하지 않습니다. 만약 어느 가족이 그 화면 반대편에 있었다면, 그들은 코스타리카로 날아가 자신들에 대해 들어본 적도 없는 프런트 데스크에 도착했을 것입니다.
그 순간이 바로 에이전틱 AI 여행 예약이 보기보다 어려운 이유의 전부이며, 우리가 제대로 해내기 전에 무엇을 잘못했는지 짚어보고 싶은 이유이기도 합니다. 짧게 말하면, 여행에서는 유창한 답변과 진실한 답변은 서로 다른 대상이며, 그 둘 사이의 간극은 반복 개선으로 없앨 수 있는 버그가 아닙니다. 그것은 확률적 모델로 결정론적 작업을 수행하는 데서 오는 구조적 속성입니다.
가용성을 추측하는 인간 여행사 직원은 해고됩니다. 추측하는 AI는 그 어조를 칭찬받습니다 — 고객이 공항에 서 있게 되기 전까지는.
이사회는 "AI 전략"을 요구했습니다. 시장은 그들에게 패닉에 빠질 이유를 주었습니다.
제가 상황을 설명해 보겠습니다. 여행 관리 회사나 OTA에서 제품을 담당하고 있다면, 지금 바로 이것을 겪고 있을 테니까요.
2026년 2월과 4월 사이, 여행 업계의 모든 주요 유통 계층이 에이전틱 예약을 출시하거나 발표했습니다. Sabre, PayPal, Mindtrip은 2월 12일 업계 최초의 엔드투엔드 에이전틱 경험을 발표했습니다 — 항공편은 2026년 2분기에 일반 제공되며, 420개가 넘는 항공사와 200만 개의 호텔에 걸친 Sabre의 Mosaic API 위에서 실행되고, 그 위에 Mindtrip의 650만 포인트 지식 기반이 얹힙니다. 그 전날, Marriott의 CEO는 Google의 AI Mode가 OTA 채널을 완전히 건너뛰고 Marriott을 직접 예약하게 될 것이라고 확인했습니다. Amadeus는 Accenture와 함께 구축한 Cytric Easy라는 생성형 어시스턴트를 Microsoft Teams 안에 넣었습니다. Navan은 모든 레거시 TMC를 느려 보이게 만드는 수치를 계속 보고하고 있습니다.
그래서 CFO가 회의실로 걸어 들어와 왜 "Navan처럼 AI 관련 일을 하지" 않느냐고 묻습니다. 그리고 여기 제가 똑똑한 팀들이 빠지는 것을 지켜본 함정이 있습니다: 그들은 그 질문을 챗봇을 빨리 출시하라는 뜻으로 듣습니다. 정작 진짜 질문 — 유일하게 중요한 질문 — 은 Air Canada처럼 데이지 않고 어떻게 이걸 해낼 것인가입니다.
제가 이야기하는 구매자들은 에이전틱 예약을 할지 말지를 묻고 있지 않습니다. 그 논쟁은 끝났습니다. 그들이 묻는 것은 어떻게 하면 단일 플랫폼의 인벤토리에 회사를 걸지 않고, 또 자신 있게 틀린 기계가 자기가 직접 책임져야 할 법적 책임을 만들어내지 않게 하면서 이것을 해낼 수 있는가입니다.
그 법적 책임에는 이미 이름이 있고, 여러분의 법무팀은 그것을 알고 있습니다
여행 업계 법무팀이 왜 긴장하는지 이해하고 싶다면, 단 하나의 사례만 있으면 됩니다.
2024년 2월 14일, 브리티시컬럼비아 민사분쟁해결심판소는 Air Canada의 챗봇이 항공사의 실제 요금 규정과 모순되는 소급 사별 요금 정책을 지어낸 것에 대해, Air Canada가 Jake Moffatt에게 $812.02를 지급하라고 명령했습니다. Air Canada의 항변은 사실상 그 챗봇이 자신의 발언에 스스로 책임을 지는 별개의 법적 주체라는 것이었습니다. 심판소는 이를 명료한 언어로 기각했습니다: 회사는 그 말이 정적인 웹페이지에서 나오든 모델에서 나오든, 자사의 모든 표면에 있는 모든 것에 대해 책임이 있다는 것입니다.
812달러는 반올림 오차에 불과합니다. 그러나 그 판례는 그렇지 않습니다. 그 이후로 작성된 모든 여행 기술 법무 메모는 Moffatt를 인용하며, 더 최근의 한 판결은 배포자들에게 전혀 도움이 되지 않는 방향으로 정반대로 갈렸습니다 — 2026년 1월 항저우의 한 법원은 사용자가 챗봇의 약속을 강제하려 했을 때 LLM 공급업체의 책임을 좁혔습니다. 두 사례를 함께 읽으면, 둘은 똑같이 불편한 방향을 가리킵니다: 주의 의무는 모델 제공자가 아니라 여행 브랜드에 떨어진다는 것입니다. 비난을 OpenAI에 외주로 넘길 수는 없습니다.
그리고 그것은 돈만의 문제가 아닙니다. 2025년, 관광객들은 AI 플래너가 통째로 지어낸 장소인 "우만타이 신성한 협곡(Sacred Canyon of Humantay)"을 찾아 페루 안데스의 4,000미터까지 트레킹했습니다. 말레이시아의 한 커플은 존재하지 않는 "Kuak Skyride"를 타려고 400킬로미터를 운전했습니다. 주민 33명의 태즈메이니아 마을은 한 번도 가진 적 없는 온천에 관한 전화를 받기 시작했습니다. 여행 위험 관리 표준인 ISO 31030은 여행자 안전을 배포자의 의무로 규정합니다 — 그러한 사건들이야말로 그 표준이 존재하는 이유입니다. 이제 대략 관광객의 4분의 1이 여행 계획에 AI를 사용하는 상황에서, 그 폭발 반경은 이미 한참 전에 이론에 그치지 않게 되었습니다.
제가 무엇을 잘못 봤는가: 저는 이것이 프롬프트 문제라고 생각했습니다
여기 제가 자랑스럽지 않은 부분이 있습니다.
솔직히 우리의 첫 번째 빌드는 보기 좋은 래퍼였습니다. 유능한 모델, 잘 설계된 시스템 프롬프트, 호텔 카탈로그에 대한 검색, 깔끔한 채팅 화면. 데모는 잘 되었습니다 — 너무 잘 돼서, 저는 환각이 더 나은 프롬프팅과 더 큰 검색 인덱스로 짜내 없앨 수 있는 엣지 케이스라고 스스로 믿고 있는 걸 깨달았습니다. 그 무렵 한 투자자는 저에게 대충 그냥 GPT를 쓰고 너무 깊이 생각하지 말라고 했습니다. 한 달가량 저는 그를 반쯤 믿었습니다.
Tabacon Springs 순간이 그 믿음을 깨뜨렸지만, 실제로 제 마음을 바꾼 것은 자리에 앉아 제가 피해 왔던 산수를 해본 것이었습니다.
현실적인 항공편 예약은 대략 열 개의 순차적 단계입니다: 의도 파싱, 검색, 필터링, 가격 산정, 홀드, 정책 확인, 승객 정보 수집, 결제 전달, PNR 확정, 발권. 관대하게 가정해서 — 각 단계가 90% 확률로 맞는 확률적 모델 호출이라고 합시다. 엔드투엔드로 성공률은 0.9의 10제곱입니다. 약 34%죠.
복리로 누적되는 확률적 실패에서 프롬프트로 벗어날 수는 없습니다. 단계를 추가할수록 오류는 작아지지 않습니다. 곱해집니다.
그러다 내부 논쟁을 끝낸 수치를 발견했습니다. OSU NLP 그룹의 TravelPlanner 벤치마크는 인기 있는 ReAct 패턴을 사용하는 GPT-4가 현실적인 여러 날짜의 여정을 완성하는 비율을 0.6%로 측정했습니다. 60%가 아닙니다. 0.6입니다. 천 번의 여행 중 여섯 번 성공한 것입니다.
사람들은 같은 벤치마크에서 나온 "97%"라는 수치를 여기저기 들먹이는데, 저는 여기서 정확히 짚고 싶습니다. 그것을 빌려 쓰는 것은 우리를 부정직하거나 순진하게 보이게 만들 테니까요: 그 97%는 코드 기반 솔버가 정적이고 고정된 지식 기반 — OpenFlights와 Yelp 스냅샷 — 에 대해 실행된 것이지, 실시간으로 변하는 인벤토리에 대해 예약하는 모델이 아닙니다. 그것은 프로덕션 예약 수치가 아니며, 그것을 그런 수치로 인용하는 사람은 논문을 읽지 않은 것입니다. 전체 흐름을 구동하는 LLM에 대한 정직한 수치는 그 작은 숫자입니다.
그것이 전환점이었습니다. 문제는 결코 프롬프트가 아니었습니다. 문제는 우리가 애초에 확률적 모델을 제어 흐름 안에 넣었다는 것이었습니다.
존재하지 않는 호텔을 AI가 예약하지 못하게 하려면 어떻게 해야 할까요?
모델을 더 신뢰할 수 있게 만들려는 시도를 멈추고, 반드시 신뢰할 수 있어야 하는 부분에서 모델을 제거하려 하기 시작하자, 아키텍처는 거의 저절로 설계되었습니다.
우리가 정착한 규칙: 언어 모델은 언어를 하고, 그 외에는 아무것도 하지 않습니다. 그것은 여행자가 무엇을 의미하는지 추출하고 결과를 평이한 영어로 요약해 돌려줍니다. GDS를 호출하지 않습니다. 정책을 확인하지 않습니다. 결제에 손대지 않습니다. 이 모든 것은 하드코딩된 결정론적 로직입니다. 우리는 오케스트레이션을 상태 기계로 실행합니다 — LangGraph가 우리의 일반적인 제어 평면이지만, 그것에 교조적이지는 않습니다. 만약 클라이언트가 AWS Bedrock AgentCore나 Vertex AI Agent Builder 위에 서 있다면, 우리는 대신 거기서 구축합니다.
프레임워크보다 더 중요한 세부 사항은 타입이 지정된 상태입니다. 제가 본 대부분의 프로덕션 에이전트 배포는 똑같이 조용한 죽음을 맞습니다: 상태가 단계들 사이에서 소리 없이 표류하고, 아무도 알아차리지 못하며, 에이전트는 손상된 세계상에 대해 자신 있게 행동합니다. 엄격한 Pydantic 타입 상태 스키마 — 모든 필드가 선언되고 각 전이에서 검증되는 — 가 그것을 막는 화려하지 않은 방법입니다. 예약이 여러 번의 커밋에 걸쳐야 할 때는 사가(saga) 패턴이 롤백을 처리합니다: 항공편이 이미 발권된 후 호텔이 실패하면, 그래프는 여행자를 절반만 예약된 상태로 두는 대신 취소하고 되돌리는 방법을 압니다.
우리는 이것을 하나의 제품이 아니라 세 가지 역량으로 구축했습니다. 모든 구매자가 전체를 필요로 하는 것은 아니기 때문입니다. 결정론적 예약 에이전트가 있습니다 — 핵심이죠. 검증-as-a-service가 있습니다. 기존의 어떤 여행 AI 팀이든 호출해 "이 호텔은 실재하는가, 이 가격은 최신인가, 이 PNR은 실제로 확정되었는가?"를 물을 수 있는 독립형 API입니다 — 이미 출시한 래퍼 앞단에 놓이는 가드레일로, 법무팀이 운영위원회에서 Moffatt를 문제 삼을 때 모든 것을 뜯어내는 것보다 훨씬 저렴한 답입니다. 그리고 기업 여행 정책이나 OTA의 요금 규정을 강제되는 제약으로 컴파일하고, ISO 31030 주의 의무를 계측하며, EU AI Act 투명성 요건을 담아내는 정책·컴플라이언스 계층이 있습니다. 우리는 이 세 가지가 어떻게 맞물리는지를 이 작업의 솔루션 페이지에 정리해 두었습니다.
정책 집행은 프롬프트가 아니라 코드여야 합니다. 프롬프트는 모델 버전 사이에서 표류합니다. 비즈니스 규칙은 그래서는 안 됩니다.
아무도 피치 슬라이드에 넣지 않는 숫자
모든 여행 팀이 출시 전에 한 가지를 체득하게 할 수 있다면, 그것은 환각이 아닐 것입니다. 그것은 검색의 경제학일 것입니다.
GDS 제공업체는 예약당 청구하지 않습니다. 그들은 구간 검색당 청구하는데, 보통 $3에서 $3.50에 약 10%의 수수료가 더해지며, 투기적 쇼핑에 대해 페널티를 주는 조회 대 예약 비율(look-to-book)을 강제합니다. Lufthansa 그룹은 2026년 1월 1일부로 Amadeus, Sabre, Travelport에 걸쳐 GDS 예약 수수료를 또다시 인상했습니다. 이제 모델이 철저하기로 마음먹었다는 이유로 대화 한 턴마다 네 번의 탐색적 검색을 "친절하게" 실행하는 에이전트를 상상해 보세요. OTA의 3~5% 판매 마진에서, 그 에이전트는 실제로는 아무것도 예약하지 않는 챗봇에 분기 이익을 몽땅 태워버릴 것입니다.
이것은 제가 지켜본 모든 에이전틱 여행 데모에서 가장 간과되는 항목이며, 바로 그 데모들이 프로덕션과 맞닥뜨리면 살아남지 못하는 이유입니다. 결정론적 에이전트는 검색을 상한선으로 제한하고 캐시합니다. 검색이 그 수수료만큼의 가치가 있는지를 모델의 기분이 아니라 오케스트레이션 계층이 결정하기 때문입니다.
그리고 TMC에게 그 경제학은 CFO가 실제로 쫓고 있는 숫자와 곧바로 연결됩니다. 이 빌드가 움직이는 지표는 무접촉 예약 비율(touchless booking percentage)과 그 뒤에 자리한 오프라인 대기열 처리 시간입니다. 환각이거나 서비스 불가능한 모든 예약은 사람 상담원에게 되돌아가는 티켓입니다 — 회의실에서 누군가 "Navan처럼 AI 관련 일을 하자"고 말할 때 지목되는 바로 그 비용입니다.
왜 그냥 Amadeus API 위에 구축하면 안 되나요?
제가 값비싼 방식으로 배워야 했고, 이제는 아무도 3개월 차에 놀라지 않도록 첫 디스커버리 콜에서 꺼내는 몇 가지 현실이 있습니다.
만약 여러분이 "그냥 Amadeus API 위에 구축"하려는 TMC라면, 어떤 키를 가지고 있는지 확인하세요. Amadeus의 Self-Service Production 등급은 Flight Create Orders 엔드포인트를 특별히 제외합니다 — 그것은 그들 자신의 표현대로, 여행사 인증이 없는 기업을 위해 설계된 것입니다. 실제로 주문을 발행하려면 Enterprise가 필요합니다. 저는 그 한 줄짜리 항목이 로드맵을 한 분기나 되돌리는 것을 지켜봤습니다.
그다음, 모두가 해결된 것으로 취급하지만 그렇지 않은 이음새가 있습니다: NDC 대 GDS. New Distribution Capability는 초기 오퍼와 주문에는 훌륭하지만, 예약 후 서비스 — 변경, 환불, 비정상 운항 재예약 — 는 원래 판매가 NDC였더라도 여전히 GDS 인프라 위에서 돌아갑니다. 프로덕션 에이전트에는 둘 중 하나를 고르는 이분법이 아니라 둘 다의 파이프가 필요합니다. 그리고 NDC 자체도 하나가 아닙니다: Verteil이나 Duffel 같은 애그리게이터를 통한 Level 4 주문 관리는 대부분의 래퍼가 멈추는 Level 3 쇼핑과는 다른 통합입니다. IROPS는 그 간극이 실제로 드러나는 지점입니다 — 단 한 번의 기상 이변이 여행자들을 비행기 단위로 발이 묶이게 할 수 있고, 각 한 명을 재예약하는 데 $500에서 $2,000이 듭니다. 검색은 할 수 있지만 서비스는 할 수 없는 에이전트는 장난감입니다.
그리고 만약 여러분의 설계가 에이전트를 호스트 시스템으로 라우팅하는 대신 직접 티켓을 발행하게 한다면, 여러분은 이제 인증 영역에 들어선 것입니다 — 미국의 ARC는 선행 조건이 충족되면 약 25일이 걸리고, 완전한 IATA 인증은 6개월에서 12개월이 걸릴 수 있습니다. 결제 함정도 있습니다: 채팅 화면이 카드 데이터를 수집하는 순간, 여러분은 전체 스택을 PCI 범위 안으로 끌어들인 것입니다. 오늘날의 에이전틱 커머스는 여전히 실제 승인을 사람의 결제 단계로 넘기며, VGS나 Checkout.com 같은 제공업체를 통한 토큰화로 카드 데이터를 여러분의 환경 밖에 둡니다.
이 중 어느 것도 기조연설에는 없습니다. 그 전부가 프로덕션 인시던트 보고서에는 있습니다.
"그냥 Sabre 것이나 Cytric, 아니면 Navan을 사면 안 되나요?"
사람들은 저에게 이걸 끊임없이 묻는데, 제 정직한 답은 그들을 놀라게 합니다: 때로는 사야 합니다.
만약 여러분이 Sabre의 레일 위에서 Sabre의 인벤토리를 유통하는 데 만족하는 레저 OTA라면, Sabre–PayPal–Mindtrip 스택은 합리적인 구매입니다 — Sabre에 고정된 공급과 기업 정책 계층이나 ISO 31030 계측의 부재를 받아들였다는 전제하에서요. 만약 여러분이 이미 Cytric과 Concur를 쓰는 Microsoft 네이티브 기업이라면, Teams 안의 Cytric Easy가 아마 여러분에게 맞을 것이고, 저는 그걸 직접 말씀드릴 겁니다. 만약 여러분이 TMC를 통째로 뜯어내고 AI 네이티브 플랫폼을 운영하고 싶다면, Navan은 그 수치를 진정으로 얻어냈습니다 — 무접촉 경비 73%, 정책 위반 35%에서 5% 미만으로 감소 — 그리고 저는 우리가 Navan이 되는 일에서 그들을 이긴다고 가장하지 않겠습니다.
우리는 더 좁고 구체적인 경우에 맞습니다: 여러분은 기존 GDS 계약과 TMC 관계를 유지하면서 그 위에 벤더 중립적으로 지능을 더하고 싶고, 에이전트를 사들인 상대가 누구든 그를 위한 유통업체가 되지는 않고 싶어 합니다. 그것이 바로 그 빌드입니다. 그리고 제가 할 수 없는 부분은 소리 내어 말합니다 — 우리는 IATA/ARC 인증을 받은 발권 대리점이 아니므로 발행은 여러분의 호스트를 통해 이루어지고, 우리는 여러분의 GDS 상업 계약을 소유하지 않으며, 모호한 기업 여행 정책을 우리가 고칠 수는 없습니다. 다만 디스커버리 단계에서 그것을 조이도록 도와드리겠습니다. 코드가 아무리 좋아도 모호한 정책은 모호한 에이전트를 만들기 때문입니다.
그 창을 닫는 마감 기한
시간에 관한 것이 하나 더 있습니다. 배포자에 대한 EU AI Act의 투명성 의무는 2026년 8월 2일에 발효되며, 고위험 분류 지침은 2026년 2월 2일에 나왔습니다. 만약 여러분의 에이전트가 EU 소비자와 대화한다면, 고지는 선택 사항이 아니며 "나중에 추가하겠다"는 것은 언젠가 터질 컴플라이언스 지적 사항입니다. 우리는 Article 50 고지 표면과 기록·설명(log-and-explain) 감사 추적을 처음부터 넣어 구축합니다. 블랙박스 래퍼에 투명성을 사후에 덧붙이는 것은 처음부터 그것을 위해 설계하는 것보다 훨씬 고통스럽기 때문입니다.
그래서 이 모든 것을 겪은 후 제가 도달한 지점이 여기입니다. 이제 유창함은 공짜입니다 — 시장의 모든 래퍼는 자신 있게 들리고, 여행자는 그것을 읽어서는 진짜 확정과 환각된 확정을 구별할 수 없습니다. 여행자가 결국 알 수 있는 것은, 도착했을 때 프런트 데스크에 그 방이 있는지 여부입니다. 그 간극 — 진실하게 읽히는 문장과 실제로 진실 인 PNR 사이의 간극 — 은 모델이 더 커졌다고 해서 좁혀지지 않습니다. 그것은 누군가가 출시 전에 모델이 결코 "이것이 진짜인가?"에 답하는 존재가 되지 않게 하겠다고 결정했기 때문에 좁혀집니다. 그것에 답하는 결정론적 계층은 화려하지 않고, 데모도 그만큼 잘 되지 않으며, 그것이 바로 그 일의 전부입니다.
Tabacon Springs Eco-Lodge는 여전히 실재하는 장소가 아닙니다. 중요한 유일한 질문은 여러분의 고객이 로비에 서 있기 전에 여러분의 시스템이 그것을 아는가입니다. 우리가 알도록 우리 것을 어떻게 구축했는지 보고 싶다면, 전체 분석은 여기에 있습니다.
