이 글은 AI 에이전트가 항공편을 자율적으로 검색, 예약, 변경 및 취소할 수 있게 해주는 에이전트 기반 여행 스택인 [ucp.travel] 구축에 관한 지속적인 시리즈의 일부입니다. Almin Zolotic이 Zologic에서 제작했습니다.

지난번에는 AI 에이전트를 이용해 항공편을 자율적으로 예약하는 과정(검색, 재확인, 결제, 확정)에 대해 작성한 적이 있습니다. 그 부분이 흥미로운 부분이었죠.

이번 주는 덜 화려하지만 논란의 여지 없이 더 중요한 부분, 즉 '예약 이후'에 무슨 일이 일어나는지에 대한 내용입니다.

여행 관련 서비스를 구축해 본 사람이라면 누구나 예약은 시작일 뿐이라는 것을 알고 있습니다. 진정한 복잡성은 그 이후에 나타납니다. 여행자가 항공편을 변경하고 싶어 합니다. 항공사가 대신 변경합니다. 여행자가 취소하고 싶어 합니다. 날짜는 바뀌고, 가격은 재조정되며, 확정 기간이 만료됩니다. 실제 여행 플랫폼은 이 모든 것을 무너지지 않게 처리해야 하며 — 여행자가 마치 아무것도 모르는 것처럼 느끼지 않도록 해야 합니다.

우리가 이번 주에 구축한 것이 바로 그것입니다.

예약 이후 중요한 세 가지 순간

여행 플랫폼이 제품처럼 느껴질지 프로토타입처럼 느껴질지를 결정하는 세 가지 사후 예약 시나리오가 있습니다.

자발적 취소(Voluntary cancellation) — 여행자가 취소를 결정하고, 확정하기 전에 그 결과를 이해해야 합니다.

항공사 주도 변경(Airline-initiated change) — 항공사가 여정을 재조정하거나 변경하며, 플랫폼은 예약이 여전히 변경되지 않은 것처럼 가장하는 대신 이를 명확하게 반영해야 합니다.

자발적 변경(Voluntary change) — 여행자가 다른 항공편을 원하고, 시스템은 무엇이 최종이고 무엇이 아닌지에 대한 모호함 없이 미리 보기, 확정 단계, 그리고 필요한 추가 결제까지 안내해야 합니다.

세 가지 모두 다단계 흐름입니다. 어느 것도 단일 호출로 발생해서는 안 됩니다. 그리고 여행자가 자신이 정확히 무엇을 확정하는지 알지 못한 채 완료되어서도 안 됩니다.

되돌릴 수 없는 행동을 안전하게 느끼게 만들기

우리가 계속 돌아갔던 원칙은 간단했습니다. 돌이킬 수 없는 모든 행동 앞에는 미리 보기가 있어야 한다는 것입니다.

여행자는 무슨 일이 일어날지 보고, 멈출 기회를 갖고, 그 후에만 확정해야 합니다. 만약 미리 보기 기간이 끝나기 전에 행동하지 않으면, 시스템은 이를 감지하고 오래된 정보로 진행하는 대신 다시 시작하도록 요청해야 합니다.

이는 당연하게 들리지만, 올바르게 구현하는 것은 상당한 규율을 요구합니다. 시스템이 미리 보기를 건너뛰거나, 자동 확정하거나, 또는 확정 창이 닫혔다는 것을 전달하지 못하는 곳이 놀라울 정도로 많습니다. 저희는 이러한 허점을 메우고 여러 계층에 가드(guard)를 추가하여, 하나의 검사가 우회되더라도 다음 검사에서 이를 포착하도록 했습니다.

같은 원칙은 시스템이 요금 조건에 대해 이야기하는 방식에도 적용됩니다. '환불 가능(refundable)'으로 표시된 요금은 정책 진술일 뿐이며, 현재 시스템이 환불을 실행할 수 있다는 보장은 아닙니다. 저희는 플랫폼을 변경하여 변경 또는 취소가 가능하다는 약속을 하기 전에 실시간 예약 상태를 확인하도록 했습니다. 만약 현재 인터페이스를 통해 예약을 처리할 수 없다면, 여행자는 나중에 혼란스러운 오류 메시지를 받는 대신 명확하게 이를 듣게 됩니다.

항공사 주도 변경이 가장 어려웠던 부분

가장 많은 주의를 기울여야 했던 시나리오는 항공사 주도 변경(airline-initiated change)이었습니다.

항공사가 여정을 변경할 때, 플랫폼은 이벤트를 받고 무엇을 해야 할지 결정해야 합니다. 잘못된 대처는 이를 조용히 처리하는 것입니다. 항공사 변경에는 새로운 비행 시간, 다른 항공기, 또는 때로는 다른 경로가 포함될 수 있으며, 여행자는 그 어느 것에도 동의한 바 없습니다.

올바른 대처는 변경 사항을 명확하게 제시하고, 원래 예약된 내용과 현재 제안되는 내용을 보여주며, 어떤 것이든 수락하거나 거부하기 전에 여행자에게 검토하도록 요청하는 것입니다.

저희는 이러한 에스컬레이션 경로(escalation path)를 제대로 구축했으며, 변경 사항을 제시하기 전에 플랫폼이 신선한 예약 상태를 다시 가져오도록 하고, 실제 제공업체의 동작에 맞춰 전체 흐름을 끝에서 끝까지 검증했습니다.

정산의 투명성도 중요합니다

매우 중요했던 작은 변화 중 하나는 취소 환불이 어떻게 전달되는 방식이었습니다.

많은 여행 상품에서 취소 관련 문구는 여행객이 단순히 카드에 돈을 돌려받게 될 것이라는 점을 암시합니다. 하지만 저희 모델에서는 상업적 현실이 다릅니다. 정산은 운영사(operators)와 플랫폼 간의 청구(billing) 방식에 따라 이루어지기 때문입니다.

이 두 가지는 같지 않으며, 이를 혼동하는 것은 오해를 불러일으킬 수 있습니다.

따라서 플랫폼은 이제 취소 관련 내용을 서비스 상태(service status) 측면에서 전달합니다. 즉, 예약이 취소되었고, 적용 가능한 크레딧이나 조정 금액은 청구 방식에 따라 처리된다는 것입니다. 더 이상 실제로 상업적으로 올바른 해석이 아닐 때 여행객에게 직접 환불되는 것처럼 암시하지 않습니다.

사소한 문구 변경이지만 신뢰도에 큰 영향을 미칩니다.

실제 작동하는지 확인하는 방법

이번 주 제가 가장 만족스러운 부분은 단순히 기능 목록 자체가 아닙니다.

저희는 '로컬에서 작동한다'는 수준에서 멈추지 않았습니다.

예약, 변경, 취소, 그리고 항공사 주도 변경 처리 등 전체 예약 수명 주기(booking lifecycle)를 실제 제공업체 응답에 대해 단계별로 검증했습니다. 그 결과 모든 시나리오에 대한 확정된 결과를 얻을 수 있었습니다.

이는 프로젝트의 초점을 '이것이 작동할 것이라고 생각한다'에서 '핵심 흐름이 이렇게 작동한다는 것을 안다'로 전환시켰습니다.

코드가 올바르게 보이는 것과 실제 조건에서 올바르게 작동하는 것으로 입증된 시스템 사이에는 의미 있는 차이가 있습니다. 이번 주에 저희는 서비스 레이어(servicing layer)에서 그 경계를 넘었습니다.

다음 단계는 무엇인가요

당장의 다음 목표는 운영사 도구(operator tooling)입니다. 여행 프로그램을 운영하는 사람들이 예약 정산, 청구 데이터에 대한 가시성을 확보하고, 자신감을 가지고 여행객의 예약을 관리할 수 있도록 하는 것입니다.

AI 에이전트 레이어(AI agent layer)는 현재 건강한 상태에 접어들었습니다.

이제 작업은 이 기반을 그 위에서 운영하는 인간들을 위한 완전한 제품으로 전환하는 것입니다.

곧 더 많은 내용을 알려드리겠습니다.

Almin Zolotic은 Zologic의 설립자이며, AI 에이전트가 항공편을 자율적으로 검색, 예약, 변경 및 취소할 수 있게 하는 에이전틱 여행 스택(agentic travel stack)인 ucp.travel을 구축하고 있습니다. dev.to에서 빌드 과정을 팔로우하세요.