당신의 AI 여행 플래너는 거짓말을 하고 있습니다 — 낯선 곳에 발이 묶이기 전까지는 모릅니다

작년에 한 여성이 스크린샷 한 장과 함께 저희에게 이메일을 보내왔습니다. 그녀는 인기 있는 AI 여행 플래너를 사용해 코스타리카로 가는 가족 여행을 예약했습니다. AI는 "Tabacon Springs Eco-Lodge"와 비슷한 이름의 숙소를 추천했는데, 무성한 묘사와 1박 200달러 미만의 가격, 그리고 딱 들어맞아 보이는 사진들이 있었습니다. 그녀는 네 명분의 항공권을 예약했습니다. 렌터카도 빌렸습니다. 아이들에게는 나무 위 오두막에서 원숭이를 보러 간다고 말했습니다.

그 로지는 존재하지 않았습니다.

"문을 닫았다"거나 "리모델링 중이었다"는 것이 아닙니다. 말 그대로 존재하지 않았습니다. AI는 실제로 존재하는 두세 곳의 코스타리카 리조트에서 세부 정보를 뒤섞었습니다. 한 곳의 이름, 다른 곳의 편의시설, 그리고 근처 호스텔의 가격대를 가져와 결코 지어진 적 없는, 아름답게 묘사된 하나의 숙소로 엮어낸 것입니다. 예약 링크는 그녀의 카드를 결제하고는 아무것도 제공하지 않는 일반적인 결제 페이지로 연결되었습니다.

그 이메일을 읽었을 때 저는 놀라지 않았습니다. 저는 그것을 알아봤습니다. 왜냐하면 Veriprajna의 저희 팀은 바로 이 실패 양상을 몇 달 동안 들여다보며 분석하고, 그것이 왜 아키텍처 수준에서 발생하는지 이해해 왔기 때문입니다. 그리고 그 답은 단순하면서도 여행 분야에서 AI 제품을 만드는 누구에게나 대단히 불편한 것입니다: 업계에서 가장 인기 있는 AI 시스템들은 옳게 만들어지는 것이 아니라 옳게 들리도록 최적화되어 있습니다. 그 구분은 시 생성기에서는 미묘합니다. 하지만 여행 물류에서는 휴가와 재앙 사이의 차이입니다.

왜 당신의 AI는 존재하지도 않는 호텔을 지어낼까요?

대부분의 사람들이 대규모 언어 모델(GPT-4, Claude, Gemini 등 전부)에 대해 이해하지 못하는 점이 여기 있습니다. 이들은 데이터베이스가 무언가를 아는 방식으로 무언가를 "알지" 못합니다. 호텔 예약 시스템은 JW Marriott의 412호가 3월 3일부터 3월 7일까지 예약되어 있다는 것을 압니다. 그것은 하나의 행(row)에 저장되어 조회 가능한 사실입니다.

LLM은 그런 식으로 작동하지 않습니다. 그것은 학습 데이터의 통계적 패턴을 기반으로 시퀀스의 다음 단어를 예측합니다. "200달러 미만의 코스타리카 럭셔리 에코 로지"를 요청하면, 그것은 연상들의 무리를 활성화합니다. "코스타리카"는 "무성한", "열대우림", "에코 로지"를 불러옵니다. 그것은 통계적으로 그 단어들의 뒤를 따를 가능성이 높은 텍스트를 생성하기 시작합니다. 그리고 숙소의 이름을 지어야 할 때는? 뒤섞습니다. 그것은 자신이 본 수천 개의 리뷰에서 조각들을 가져와 그럴듯하게 들리는 무언가로 조합합니다.

창작 글쓰기에서 그 뒤섞음은 상상력이라고 불립니다. 여행에서는 환각(hallucination)이라고 불립니다. 그리고 모델은 그 차이를 구분할 방법이 없습니다.

모델은 정확성이 아니라 일관성을 위해 최적화하고 있습니다. 그것은 실시간 재고에 대해 검증된 유효한 답이 아니라, 유효한 답처럼 보이는 응답을 만들어내도록 설계되어 있습니다.

이를 더 악화시키는 것은 이 모델들이 학습되는 방식입니다. 인간 피드백을 통한 강화 학습(RLHF) 과정에서, 인간 평가자들은 "모르겠습니다"라고 말하는 답보다 포괄적이고 자신감 있는 답을 일관되게 선호합니다. 그래서 모델은 깊은 수준에서, 자신감 있게 추측하는 것은 보상받고 무지를 인정하는 것은 벌받는다는 것을 학습합니다. 예약 가능 여부를 추측하는 인간 여행사 직원은 해고됩니다. 예약 가능 여부를 추측하는 AI는 그 "유창함"으로 칭찬받습니다. 고객이 낯선 나라에 도착해 잠잘 곳이 없을 때까지는요.

유창함이 문제라는 것을 깨달은 그 밤

제가 계속 떠올리는 순간이 있습니다. 저희는 초기 프로토타입을 테스트하고 있었습니다. 출시한 제품이 아니라 LLM이 여행 쿼리를 어떻게 처리하는지 이해하기 위한 내부 실험이었습니다. 저는 뉴욕 패션위크 기간에 센트럴 파크 근처에서 1박 250달러 미만인 호텔을 찾아달라고 요청했습니다.

그것은 세 가지 옵션을 내놓았습니다. 상세한 묘사. 가격. 편의시설. 그중 하나는 공원이 내려다보이는 루프탑 바까지 언급했습니다. 언어가 너무나 세련되고 너무나 구체적이어서, 제 첫 본능은 "예약"을 클릭하는 것이었습니다.

그때 제 엔지니어 중 한 명이(조용하고 매우 체계적인 친구였습니다) 같은 쿼리를 Amadeus 호텔 검색 API에 대해 실행했습니다. 세 호텔 중 두 곳은 존재했지만 패션위크 기간에 예약 가능한 방이 없었습니다. 세 번째 호텔의 이름은 실제 숙소와 비슷했지만 시스템의 어떤 호텔 ID와도 일치하지 않았습니다. 그 루프탑 바는? 여섯 블록 떨어진 완전히 다른 호텔의 것이었습니다.

그날 밤 저는 위험은 명백하게 실패하는 AI가 아니라는 것을 이해했습니다. "질문을 이해하지 못하겠습니다"라고 말하는 챗봇은 답답하지만 무해합니다. 위험한 것은 당신의 질문을 완벽하게 이해하고서 유창하고 설득력 있으며 사실적으로 틀린 정보로 응답하는 AI입니다. 저희는 이것을 신뢰성의 "불쾌한 골짜기(Uncanny Valley)"라고 부르기 시작했습니다. 시스템의 언어적 지능이 너무 높아서 사용자가 사실 검증에 대한 경계를 늦추는 것입니다.

Air Canada 챗봇 사건은 이것을 법적 측면에서 구체화했습니다. 한 챗봇이 환불 정책을 환각으로 지어냈습니다. 법원은 항공사에 책임이 있다고 판결했습니다. AI 벤더도, "베타 도구"로서의 챗봇도 아니었습니다. 그 에이전트를 배포한 회사가 에이전트의 주장에 대해 책임이 있었습니다. 당신의 AI가 200달러에 바다 전망 스위트룸을 약속했는데 GDS에는 400달러짜리 스탠다드 룸만 있다면, 당신은 그 차액에 대해 책임을 져야 할 수 있습니다. 또는 더 나쁘게는, 망친 여행에 대해서요.

LLM을 입이 아니라 뇌로 취급하면 어떻게 될까요?

그 테스트의 밤 이후, 저희 팀은 긴 논쟁을 벌였습니다. 사람들이 화이트보드에 그림을 그리고 서로 말을 가로채는 그런 종류의 논쟁이었죠. 질문은 단순했습니다: LLM을 더 정확하게 만들려고 시도할 것인가, 아니면 아키텍처를 완전히 바꿀 것인가?

한 진영은 더 나은 프롬프트, 더 많은 가드레일, 검색 증강 생성을 원했습니다. 여행 데이터로 모델을 파인튜닝하자는 것이었죠. 다른 진영(제가 결국 속하게 된 쪽)은 문제가 모델의 지식이 아니라고 주장했습니다. 문제는 모델의 역할이었습니다. 저희는 텍스트 생성기에게 재고 관리자의 일을 시키고 있었던 것입니다. 그것은 소설가에게 항공사를 운영하라고 시키는 것과 같습니다. 그들은 비행하는 경험을 아름답게 묘사할 수 있지만, 오전 8시 히스로행 비행기에 좌석이 있는지는 말해줄 수 없습니다.

그래서 저희는 이후에 만든 모든 것을 바꾼 결정을 내렸습니다: LLM은 결코 여행 정보의 출처가 되지 않을 것입니다. 그것은 의도의 라우터가 될 것입니다.

사용자가 "센트럴 파크 근처 호텔을 찾아줘"라고 말합니다. LLM의 역할은 그 의도를 이해하고, 그것을 구조화된 매개변수(위치, 날짜 범위, 예산, 선호도)로 분해한 뒤, 그 매개변수를 실제 재고를 조회하는 도구에 넘기는 것입니다. 그 도구는 실제 데이터를 가지고 돌아옵니다. LLM의 두 번째 역할은 그 데이터를 자연어로 제시하는 것입니다. 하지만 그것은 결코 데이터를 생성하지 않습니다. 그것은 데이터를 번역합니다.

저희는 여행에 대해 이야기하는 AI를 만드는 것을 멈췄습니다. 저희는 여행을 실제로 하는 AI를 만들기 시작했습니다. 실제 시스템을 조회하고, 실제 상태 코드를 해석하며, 검증할 수 있는 것만 확인하는 AI 말입니다.

이것이 업계에서 "LLM 래퍼"라고 부르는 것에서 에이전틱 AI 시스템으로의 전환입니다. 그리고 그 차이는 점진적인 것이 아닙니다. 그것은 종(species)의 변화입니다. 저는 이 아키텍처에 대해 저희 연구의 인터랙티브 버전에서 깊이 있게 다뤘습니다.

오케스트레이터-워커 패턴: 왜 하나의 에이전트로는 충분하지 않은가

초기에 저희는 모든 것을 단일 에이전트로 실행해 보았습니다. 하나의 프롬프트가 항공편, 호텔, 렌터카, 식이 제한, 기업 출장 정책을 모두 처리하는 것이었죠. 그것은 자기 무게에 짓눌려 무너졌습니다. 컨텍스트 윈도우가 가득 찼습니다. 지시가 충돌했습니다. 에이전트는 항공편 날짜를 확정하기도 전에 호텔을 예약했다가 모든 것을 되돌려야 했습니다.

그래서 저희는 저희가 오케스트레이터-워커 패턴이라고 부르는 것을 만들었습니다. 그것을 키보드는 결코 만지지 않으면서, 각자 한 가지 일을 극도로 잘하는 전문가 팀을 관리하는 시니어 여행 컨설턴트라고 생각해 보세요.

오케스트레이터는 고도의 추론 모델(GPT-4o 또는 Claude 3.5 Sonnet)로, 사용자와 대화하고 대화 이력을 유지하며 무엇이 일어나야 하는지 결정합니다. 그것은 GDS를 직접 만지지 않습니다. 그 아래에는 전문화된 워커들이 있습니다: Amadeus Air API를 구사하고 IATA 코드를 이해하는 Flight Worker, Sabre의 숙박용 콘텐츠 서비스(Content Services for Lodging)를 구사하고 보증금(deposit)과 개런티(guarantee)의 차이를 아는 Hotel Worker, 그리고 무엇이든 제시되기 전에 기업 출장 규칙을 확인하는 Policy Worker.

사용자가 "다음 주 화요일에 뉴욕행 항공편과 센트럴 파크 근처 호텔을 예약해줘"라고 말하면, 오케스트레이터는 그것을 두 가지 작업으로 분해하고, 호텔 검색이 항공편의 도착 시간에 의존한다는 것을 파악한 뒤, Flight Worker를 먼저 실행하고 그다음 올바른 날짜로 Hotel Worker를 실행합니다. Hotel Worker가 실패하면, 오케스트레이터는 여전히 항공편 옵션을 제시하고 사용자가 다른 호텔 조건으로 다시 시도하고 싶은지 묻습니다. 아무것도 중단되지 않습니다. 아무것도 환각으로 지어내지 않습니다.

핵심 통찰은 사고하는 것과 행동하는 것을 분리한 것이었습니다. 오케스트레이터는 사고합니다. 워커들은 행동합니다. 그리고 어느 쪽도 다른 쪽인 척하지 않습니다.

왜 "200 OK"가 저희를 거의 속일 뻔했나

아직도 제가 움찔하게 만드는 이야기가 있습니다. 저희는 Sabre의 예약 API와 통합 테스트를 깊이 진행하고 있었습니다. 저희 Hotel Worker는 예약 요청을 보내고 HTTP 200 응답(웹 개발에서는 "성공"을 의미하는)을 받아 그것을 오케스트레이터에게 전달하곤 했습니다. 오케스트레이터는 사용자에게 이렇게 말하곤 했죠: "예약되었습니다!"

그런데 그렇지 않았습니다. 항상 그렇지는 않았죠.

이것을 잡아내는 데 창피할 정도로 오랜 시간이 걸렸습니다. HTTP 응답이 200이었던 것은 메시지가 성공적으로 전달되었기 때문입니다. 하지만 응답 본문 내부에서 GDS 세그먼트 상태 코드는 UC(Unable to Confirm, 확정 불가)였습니다. 호텔이 요청을 거부한 것이었는데, 대개 캐시된 예약 가능 정보가 오래되었기 때문이었습니다. 검색과 예약 시도 사이의 몇 밀리초 사이에 그 방이 팔린 것입니다.

전송 계층(transport layer)과 애플리케이션 계층(application layer) 사이의 단절은 고전적인 함정이며, 저희는 곧장 그 안으로 걸어 들어갔습니다. HTTP 수준의 200 OK는 "당신의 메시지가 도착했습니다"라고 말했습니다. GDS 수준의 UC는 "당신의 예약이 실패했습니다"라고 말했습니다. 저희 시스템은 봉투를 읽으면서 그 안의 편지를 무시하고 있었던 것입니다.

그때가 바로 제가 이제 저희 아키텍처에서 가장 중요한 부분이라고 여기는 것을 구현한 시점입니다: 검증 루프(Verification Loop). 모든 예약 응답은 어떤 확정도 사용자에게 도달하기 전에, 별도의 검증 단계(결정론적 코드 확인 또는 품질 감사자 역할을 하는 전문화된 프롬프트)를 거칩니다. 그 규칙은 절대적입니다:

AI 에이전트는 특정 GDS 세그먼트 상태 코드를 파싱하여 그것이 HK(Holding Confirmed, 확정 보류됨)로 검증되지 않는 한, 결코 확정 메시지를 출력할 수 없습니다. HTTP 헤더가 무엇이라고 말하든, 그 외의 모든 것은 실패입니다.

HK는 재고가 확보되었음을 의미합니다. UC는 호텔이 당신을 거부했음을 의미합니다. NN은 요청이 대기 중임을 의미합니다. 아직 아무것도 약속하지 마세요. NO는 아무 조치도 취해지지 않았음을 의미합니다. 이 코드들은 예약된 방과 발이 묶인 여행자 사이의 차이인데, 대부분의 AI 여행 시스템은 이것들을 파싱조차 하지 않습니다.

저희의 상태 코드 처리 및 검증 아키텍처에 대한 전체 기술적 상세 내용은 저희 연구 논문을 참고하세요.

AI 에이전트는 "방금 그 방이 팔렸어요"를 어떻게 처리할까요?

이것이 바로 에이전틱 시스템이 그 값어치를 하는 지점입니다. "Look-to-Book" 불일치는 여행에서 고질적입니다. 검색하고, 예약 가능한 것을 보고, 예약을 클릭하면 그 방은 사라져 있죠. 성수기에는 끊임없이 일어납니다. 래퍼 기반 AI는 이 상황에 대한 어휘가 없습니다. 그것은 "예약했습니다!"(틀림)라고 하거나 "실패했습니다"(도움이 안 됨)라고 말할 뿐입니다. 그것은 "조금 전까지 있었는데 다른 누군가가 채갔습니다. 여기 다음으로 좋은 옵션이 있습니다"라고 말할 수 없습니다.

저희 에이전트는 할 수 있습니다. 예약이 UC를 반환하면, 시스템은 같은 호텔에 대한 새로운 예약 가능 여부 검색을 자동으로 트리거합니다. 다른 방이나 요금이 이용 가능하면, 그 옵션을 제시합니다: "이전 요금은 매진되었지만, 10달러 더 비싼 비슷한 방을 찾았습니다." 아무것도 이용 가능하지 않으면, 원래 검색 결과에서 다음으로 좋은 호텔을 가져와 대신 제안합니다. 이것은 에이전트가 상태(state)를 유지할 것을 요구합니다. 즉, 이미 무엇을 검색했는지, 사용자가 이미 무엇을 거부했는지, 대안이 무엇이었는지에 대한 기억입니다. 래퍼는 상태가 없습니다(stateless). 그들은 이것을 할 수 없습니다. 그들은 매번 처음부터 시작하거나, 연속성을 환각으로 지어냅니다.

아무도 이야기하지 않는 정규화 문제

저를 놀라게 한(정말로 놀라게 한) 한 가지는 Amadeus와 Sabre 사이의 데이터 구조가 얼마나 다른가 하는 것이었습니다. Amadeus는 가격을 기본 요금, 총액, 세금으로 나누어 엄격한 중첩 JSON으로 반환합니다. Sabre는 요금제에 따라 세금을 묶기도 하고 안 묶기도 합니다. 필드 이름도 다릅니다. 한 시스템에서 amount인 것이 다른 시스템에서는 totalPrice입니다.

양쪽의 원시 응답을 LLM에 넣고 호텔을 비교하라고 하면, 그것은 혼란스러워할 것입니다. 그것은 Amadeus에서 세전 가격을 인용하고 Sabre에서 세후 가격을 인용하여, 실제로는 20달러 더 비싼 Amadeus 호텔이 50달러 더 싸 보이게 만들 수 있습니다. 저희는 테스트에서 이런 일이 일어나는 것을 봤는데, 이것은 사용자가 알아차리기 거의 불가능한 종류의 오류입니다.

그래서 저희는 정규화 워커(Normalization Worker)를 만들었습니다. 이것은 양쪽 시스템에서 나온 서로 다른 JSON을 가져와 단일한 표준화된 스키마로 변환하는 결정론적 코드 계층입니다. 오케스트레이터는 결코 원시 GDS 데이터를 보지 않습니다. 그것은 깨끗하고 일관된 필드를 봅니다: 이름, 세금 포함 총 가격, 별점, 사용자의 관심 지점으로부터의 거리. LLM은 이 정규화된 데이터를 제시합니다. 그것은 원시 API 응답을 해석하지 않습니다. 그것은 선별된 사실을 번역합니다.

"그냥 GPT를 쓰세요" — 그리고 투자자들이 하는 다른 말들

사람들은 왜 저희가 그냥 검색 증강 생성을 사용하지 않는지(호텔 데이터를 벡터 데이터베이스에 넣고 LLM이 그것을 검색하게 하지 않는지) 끊임없이 묻습니다. 아니면 여행 데이터로 모델을 파인튜닝하거나. 아니면 그냥 더 나은 시스템 프롬프트를 추가하거나요.

한 투자자가 저에게 대놓고 이렇게 말했습니다. "그냥 좋은 프롬프트와 함께 GPT를 쓰세요. 모델은 충분히 똑똑합니다." 저는 그 직관을 존중합니다. 그것은 가장 단순한 해결책이고, 단순한 해결책은 보통 옳으니까요. 하지만 여기서는 아닙니다. 실패 양상이 공항에서 잠자는 가족일 때는 아닙니다.

RAG는 정적 지식("태국의 비자 정책이 뭐죠?")에는 도움이 되지만, AA123 항공편에 지금 당장 이용 가능한 좌석이 있는지는 알려줄 수 없습니다. 파인튜닝은 어조와 도메인 어휘에는 도움이 되지만, 모델을 실시간 재고에 연결하지는 않습니다. 더 나은 시스템 프롬프트는 형식화에는 도움이 되지만, 모델이 어떤 GDS에도 존재하지 않는 호텔 이름을 생성하는 것을 막지는 못합니다.

여행에서 환각을 막는 유일한 것은 AI의 출력을 기록 시스템(system of record)의 실시간 검증된 데이터에 접지(grounding)하는 것입니다. 그 시스템이 바로 GDS입니다. 나머지 모든 것은 장식입니다.

제약 없는 창의성은 혼돈입니다. 여행에서 제약은 현실입니다. 존재하거나 존재하지 않는 항공편 좌석, 이용 가능하거나 이용 불가능한 호텔 방. 중간 지대는 없으며, AI는 있는 척하는 것을 멈춰야 합니다.

느린 부분은 어떻게 하나요?

에이전틱 시스템이 빠르다고 하지는 않겠습니다. 단일 사용자 요청이 네 번의 도구 호출(검색, 가격 확인, 정책 확인, 응답 합성)을 트리거할 수 있습니다. 그것은 10~15초가 걸릴 수 있습니다. 이커머스에서는 그것이 영겁의 시간입니다.

저희는 이것을 세 가지 방식으로 처리합니다. 첫째, 저희는 에이전트의 추론을 사용자에게 스트리밍합니다: "Amadeus에서 항공편을 검색 중…" "기업 출장 정책을 확인 중…" 작업을 보여주면 체감 지연이 극적으로 줄어듭니다. 둘째, 저희는 워커들을 병렬로 실행합니다. Flight Worker와 Hotel Worker가 순차적이 아니라 동시에 검색하여, 총 대기 시간을 대략 절반으로 줄입니다. 셋째, 저희는 예약 가능 여부 결과를 Redis에 15분 동안 캐시합니다. 사용자가 "그 두 번째 호텔을 다시 보여줘"라고 말하면, 저희는 GDS를 다시 호출하지 않습니다. 캐시에서 가져옵니다.

그것이 2초 만에 답을 지어내는 래퍼만큼 빠를까요? 아닙니다. 그것이 진짜 답을 원하는 사용자에게 필요한 만큼 빠를까요? 그렇습니다.

저희가 아직 할 수 없는 것을 인정하는 부분

어떤 AI 시스템도 모든 경우를 처리하지는 못합니다. 비자 의존성이 있는 복잡한 다구간 여정, 잘 알려지지 않은 항공사 동맹, 협상된 요금이 필요한 단체 예약 같은 것들은 여전히 시스템을 망가뜨립니다. 저희가 이를 아는 이유는 그것을 감지하는 기능을 만들었기 때문입니다. 에이전트가 해결하지 못하고 반복되거나, 감정 분석이 사용자의 불만을 감지하면, 시스템은 저희가 "코파일럿 모드(Copilot mode)"라고 부르는 것으로 격하됩니다. 그것은 인간 여행사 직원에게 알리고, 대화의 전체 구조화된 컨텍스트를 넘겨주며, 인간이 에이전트가 준비한 도구를 사용하여 예약을 완료합니다.

사람들은 저에게 이것이 실패냐고 묻습니다. 저는 그 반대라고 생각합니다. 가장 위험한 AI는 언제 멈춰야 할지 모르는 AI입니다. 자신의 한계를 알고 우아하게 넘겨주는 것은 버그가 아니라 기능입니다. "전문가에게 연결해 드리겠습니다"라고 말하는 에이전트가 자신 있게 계속 추측하는 에이전트보다 더 신뢰할 만합니다.

이것이 다음으로 향하는 곳

저희가 오늘 만들고 있는 것은 기초이지, 천장이 아닙니다. 저희는 제가 레벨 3 자율성이라고 부를 만한 지점에 있습니다. 에이전트가 특정 작업을 실행하지만, 돈이 움직이기 전에 사용자가 확인하는 것이죠. 앞으로의 길에는 단순히 표시된 가격으로 예약하는 것이 아니라 호텔 API에 대량 할인을 조회하는 협상 에이전트, 항공편과 호텔을 관리되는 마진과 함께 맞춤형 상품으로 묶는 동적 패키징 엔진, 그리고 선제적 혼란 관리(항공편 상태를 24시간 내내 모니터링하다가 취소가 발생하면 여행자가 무언가 잘못되었다는 것을 알기도 전에 이미 다음으로 좋은 옵션의 좌석을 확보하는 에이전트)가 포함됩니다.

그 어느 것도 래퍼에서는 가능하지 않습니다. 시스템이 환각으로 지어낸다면 그 어느 것도 작동하지 않습니다. 그 역량들 하나하나는 저희가 만들어 온 상태를 유지하고, 검증되며, 도구에 접지된 아키텍처를 요구합니다.

여행 업계는 변곡점에 있습니다. AI 도입의 첫 물결(래퍼, 챗봇, "그냥 GPT를 추가하는" 실험)은 매혹적이면서도 위험한 무언가를 만들어냈습니다. 당신이 만나본 최고의 여행사 직원처럼 들리지만 실제로는 방 하나 예약할 수 없는 시스템 말입니다. 다음 물결은 더 어렵고 덜 화려한 질문으로 정의될 것입니다: "AI가 아름다운 여정을 작성할 수 있는가?"가 아니라 "AI가 그 여정의 모든 항목이 지금 당장, 제시한 가격에 실제로 존재한다는 것을 확인할 수 있는가?"입니다.

코스타리카의 그 가족은 아름답게 쓰인 허구보다 더 나은 대우를 받을 자격이 있었습니다. 모든 여행자가 그렇습니다. 추측하는 AI의 시대는 끝났습니다. 다음에 오는 것은 확인하는 AI입니다. 그리고 그것은 아는 것만 말합니다.