여행 앱은 어떻게 AI에게 호출될까

여행 앱은 어떻게 AI에게 호출될까

검색 앱에서 호출 가능한 여행 실행 플랫폼으로

핵심 요약

  • AI 에이전트 시대의 여행 OTA는 단순 검색 결과보다 조건 해석과 실행 가능한 선택지 제안이 중요해질 수 있다.
  • App Intents는 iOS 앱 기능을 Siri·Apple Intelligence에 연결하는 접점이 될 수 있고, MCP는 외부 AI 에이전트가 OTA 데이터·기능을 호출하는 접점이 될 수 있다.
  • OTA는 실시간 재고·가격·취소 정책·쿠폰·멤버십·예약 상태 같은 권위 데이터를 구조화해야 한다.
  • 결제·예약 변경·취소 같은 고위험 작업은 명시적 사용자 확인과 감사 로그가 필요하다.

여행 OTA의 경쟁력은 오랫동안 “얼마나 많은 선택지를 빠르게 보여주는가”에 가까웠다. 사용자는 앱을 열고, 목적지와 날짜를 넣고, 가격·위치·평점·쿠폰·멤버십 조건을 비교했다. 항공권, 숙소, 패키지, 레저·티켓, 렌터카, 보험, 고객지원은 같은 앱 안에 있어도 대체로 별도 화면과 별도 흐름으로 움직였다. 사용자가 직접 맥락을 이어 붙이는 구조였다.

AI 에이전트 시대의 변화는 여기서 시작된다. 사용자는 더 이상 “제주 숙소 검색”만 입력하지 않을 수 있다. “아이와 함께 갈 수 있고, 비 오는 날 일정도 고려해서, 예산 안에서 취소가 유연한 며칠간의 여행을 짜줘”라고 요청할 수 있다. 이 요청은 단일 검색어가 아니라 여러 작업의 묶음이다. 항공권 검색, 숙소 재고 확인, 객실 조건 비교, 쿠폰 적용 가능성 확인, 일정 후보 생성, 취소 정책 검토, 가족 동반 조건 확인, 예약 전 확인 메시지 생성까지 이어진다.

핵심은 AI가 여행을 “말로 설명하는 것”이 아니라 OTA의 실제 기능을 “호출하는 것”이다. Apple의 App Intents는 앱의 동작과 데이터를 시스템 경험에 노출해 Siri, Shortcuts, Spotlight, Apple Intelligence 같은 접점에서 앱 기능을 사용할 수 있게 하는 프레임워크다. MCP는 대규모 언어모델 애플리케이션이 외부 데이터 소스와 도구를 연동할 수 있도록 설계된 개방형 프로토콜이다. 두 기술은 영역이 다르지만, OTA 입장에서는 같은 질문으로 수렴한다. “우리 서비스의 어떤 기능을 AI가 안전하게 부를 수 있는 작업 단위로 만들 것인가?” 출처: App Intents | Apple Developer Documentation, Specification – Model Context Protocol

이 글은 App Intents API나 MCP 서버 구축 코드를 설명하지 않는다. 대신 OTA 서비스가 AI 에이전트에게 호출되기 위해 갖춰야 할 제품 구조, 데이터 구조, 권한 구조, 운영 구조를 다룬다. NOL, 여기어때, 마이리얼트립, 트립닷컴 같은 특정 기업의 전략을 평가하려는 글도 아니다. 여행 플랫폼이라는 서비스 유형이 AI 호출 인터페이스를 만나면 어떤 설계 과제를 갖게 되는지 분석하는 실무형 가이드다.

왜 여행 OTA는 AI 호출에 적합하면서도 위험한가

여행은 AI가 좋아하는 영역처럼 보인다. 사용자의 조건은 자연어에 가깝고, 선택지는 복잡하며, 비교 기준은 개인적이다. “아이와 함께”, “부모님이 걷기 편하게”, “밤 도착이라 체크인이 쉬운 곳”, “비싸도 취소가 유연한 항공권” 같은 조건은 기존 필터만으로 표현하기 어렵다. AI는 이런 모호한 조건을 해석해 후보를 좁히고, 빠뜨린 조건을 되묻고, 여러 상품군을 조합하는 데 강점을 가질 수 있다.

하지만 여행은 정적 콘텐츠 추천보다 훨씬 위험도가 높다. 호텔 소개 글이 맞아도 오늘 재고가 없으면 의미가 없다. 항공권 가격은 요청 시점에 달라질 수 있다. 취소 수수료는 요금제, 공급사, 체크인까지 남은 시간, 프로모션 조건에 따라 달라진다. 쿠폰은 특정 결제수단, 회원 등급, 최소 결제금액, 중복 적용 여부에 영향을 받는다. AI가 “좋아 보이는 여행”을 말하는 것과 “지금 예약 가능한 여행”을 제안하는 것은 전혀 다른 문제다.

그래서 OTA의 AI 전환은 챗봇을 붙이는 문제가 아니다. AI가 참조할 수 있는 최신 데이터, 호출할 수 있는 작업 단위, 중간 결과를 검증하는 정책, 사용자의 명시적 동의를 받는 승인 흐름을 갖추는 문제다. 서울관광재단의 공공 관광 MCP 추진 사례는 관광 정보가 AI 에이전트가 호출 가능한 데이터·도구 형태로 정리될 수 있음을 보여주는 참고 사례다. 다만 OTA는 여기에 실시간 재고, 가격, 결제, 취소·환불 책임까지 결합된다는 점에서 더 높은 수준의 데이터 정확성과 실행 통제가 필요하다. 관광 정보에서는 축제, 명소, 맛집, 전시, 체험 프로그램 같은 콘텐츠뿐 아니라 영업시간, 휴무일, 예약 방식, 결제 수단 같은 세부 데이터의 정확성이 여행 만족도에 직접 영향을 준다. OTA는 이보다 더 높은 실시간성과 거래 책임을 가진다. 출처: 서울관광재단·나무기술, 공공 관광 분야 첫 MCP 도입 추진 – 천지일보

App Intents와 MCP는 같은 문제가 아니다

App Intents와 MCP를 한 묶음으로만 보면 설계가 흐려진다. 둘 다 “AI가 무언가를 호출한다”는 점에서는 비슷하지만, 실제 적용 지점은 다르다.

구분 App Intents MCP
주요 접점 iOS, Siri, Shortcuts, Spotlight, Apple Intelligence 등 Apple 시스템 경험 ChatGPT류 대화형 AI, 업무용 에이전트, 외부 LLM 애플리케이션
중심 질문 앱 안의 어떤 동작과 데이터를 OS가 이해하게 할 것인가 외부 AI가 어떤 데이터와 도구를 안전하게 호출하게 할 것인가
OTA 예시 예약 상세 보기, 체크인 정보 열기, 저장한 여행 일정 검색, 쿠폰함 열기, 특정 예약 취소 규정 조회 숙소 후보 검색, 실시간 가격 조회, 쿠폰 적용 가능성 계산, 예약 변경 가능 여부 확인, 고객지원 티켓 생성
강점 사용자의 기기 맥락, 앱 설치 상태, 시스템 경험과 결합 여러 서비스와 데이터 소스를 넘나드는 에이전트 흐름
설계 초점 App Intent, AppEntity, App Shortcuts, Spotlight 노출 Tools, 리소스, 권한, 감사 로그, 사용자 동의, 서버 측 정책

Apple 문서에서 App Intents는 앱의 기능을 시스템에 표현하는 방식으로 설명된다. App Intent는 앱이 수행할 동작을 나타내고, AppEntity는 앱 고유의 개념이나 타입을 Siri와 Shortcuts 같은 시스템 경험에 노출하는 인터페이스다. App Shortcuts는 앱의 intents와 entities를 Shortcuts, Siri, Spotlight, 지원 기기의 Action button 등과 통합하는 접점이다. OTA라면 “예약”, “숙소”, “항공권”, “여행 일정”, “쿠폰”, “고객 문의” 같은 도메인 객체가 AppEntity 후보가 될 수 있다. 출처: App intents | Apple Developer Documentation, AppEntity | Apple Developer Documentation, App Shortcuts | Apple Developer Documentation

반면 MCP는 특정 운영체제의 사용자 경험보다 LLM 애플리케이션과 외부 시스템의 연결에 가깝다. MCP 명세는 LLM 애플리케이션이 외부 데이터 소스와 도구에 통합될 수 있도록 하는 개방형 프로토콜로 설명된다. MCP의 Tools는 모델이 외부 시스템에서 동작을 수행하도록 서버가 노출하는 기능 단위다. OTA 맥락에서는 “검색 결과를 반환하는 API”보다 “사용자 조건을 받아 예약 가능한 후보를 찾는 도구”, “예약 변경 가능 여부를 검토하는 도구”, “환불 예상 조건을 계산하는 도구”처럼 AI가 계획에 넣을 수 있는 작업 단위를 의미한다. 출처: Specification – Model Context Protocol, Tools – Model Context Protocol

따라서 App Intents는 “내 앱이 사용자의 기기 안에서 AI와 시스템 기능에 어떻게 발견되고 실행될 것인가”의 문제에 가깝고, MCP는 “외부 AI 에이전트가 내 서비스의 데이터와 작업을 어떤 계약으로 호출할 것인가”의 문제에 가깝다. 둘 중 하나만 고르면 되는 문제가 아니다. 모바일 앱 중심 OTA는 App Intents로 사용자 기기 안의 빠른 동작과 개인 맥락을 열고, MCP로 외부 에이전트와 파트너 시스템이 서버 측 여행 기능을 안전하게 호출하는 구조를 병행할 수 있다.

OTA 기능은 화면이 아니라 작업 단위로 분해해야 한다

AI가 호출하는 서비스는 화면 구조와 다르게 설계되어야 한다. 기존 앱에서 “숙소 상세 화면”은 이미지, 평점, 객실, 위치, 리뷰, 쿠폰, 취소 규정, 결제 버튼을 한 화면에 담는다. 하지만 AI에게는 이 화면 전체가 너무 크고 모호하다. AI가 필요한 것은 화면이 아니라 목적이 분명한 작업이다.

OTA는 먼저 기능을 다음처럼 작업 단위로 나눠야 한다.

작업 단위 입력 출력 위험도 주의점
숙소 후보 검색 목적지, 날짜, 인원, 예산, 선호 조건 후보 목록, 가격 범위, 재고 상태 낮음 가격·재고 기준 시점 표시
객실 가능 여부 확인 숙소 ID, 날짜, 인원, 객실 조건 예약 가능 객실, 요금제, 취소 조건 중간 공급사 응답 지연·품절 처리
항공권 후보 검색 출발지, 도착지, 일정, 인원 항공편 후보, 운임 조건 낮음 수하물·환불 조건 분리
쿠폰 적용 가능성 확인 사용자 ID, 상품, 결제수단, 금액 적용 가능 쿠폰, 할인 예상액 중간 실제 결제 전 재검증 필요
예약 상세 조회 예약 ID, 사용자 권한 예약 상태, 일정, 결제, 취소 조건 중간 개인정보 접근 통제
예약 확정 상품, 사용자, 결제수단, 동의 내역 예약 번호, 결제 결과 높음 명시적 확인과 재확인 필요
예약 변경 가능 여부 확인 예약 ID, 변경 조건 가능 여부, 차액, 수수료 중간 공급사 정책 반영
예약 취소 요청 예약 ID, 취소 사유, 동의 취소 결과, 환불 예상 높음 되돌리기 어려운 손실 가능
고객지원 문의 생성 예약 ID, 문제 유형, 설명 티켓 번호, 예상 처리 흐름 중간 상담원 인계 기준 필요

이 분해의 목적은 API 목록을 늘리는 것이 아니다. AI가 계획을 세울 수 있는 명확한 단위를 만드는 것이다. “아이와 함께 갈 수 있는 며칠간의 여행”이라는 요청이 들어오면 AI는 숙소 검색, 객실 가능 여부 확인, 항공권 검색, 쿠폰 확인, 취소 정책 비교, 일정 생성 순서로 도구를 호출할 수 있어야 한다. 각 작업은 입력과 출력이 명확해야 하고, 실패했을 때의 대체 경로도 있어야 한다.

예를 들어 “숙소 검색” 도구가 단순히 100개의 숙소를 반환하면 AI는 다시 랭킹과 필터를 스스로 추론해야 한다. 반대로 도구가 “가족 동반 적합성”, “취소 유연성”, “이동 편의성”, “총 예상 비용”, “재고 확실성” 같은 구조화된 평가 필드를 함께 반환하면 AI는 사용자에게 설명 가능한 후보를 만들 수 있다. 이때 평가 필드는 생성형 문장이 아니라 근거 데이터와 연결되어야 한다. 리뷰 요약만으로 “아이와 가기 좋다”고 말하기보다, 객실 최대 인원, 침대 구성, 조식 아동 요금, 주차 가능 여부, 체크인 시간, 주변 이동 수단 같은 검증 가능한 데이터가 필요하다.

App Intents 관점에서는 이런 작업 단위가 App Intent와 AppEntity 설계로 이어질 수 있다. 예를 들어 “예약 상세 보기”는 예약 AppEntity를 조회하는 intent가 될 수 있고, “다가오는 여행 일정 열기”는 사용자의 예약 데이터를 Spotlight나 Siri에서 발견 가능하게 만드는 흐름이 될 수 있다. Apple 문서는 App Intents의 구성 요소로 intents, entities, queries를 설명하며, 앱의 동작과 데이터를 시스템에 표현하는 것이 핵심임을 강조한다. 출처: Get to know App Intents – WWDC25 – Videos, Making actions and content discoverable and widely available | Apple Developer Documentation

실시간 재고·가격·정책 데이터가 AI 추천의 하한선을 정한다

여행 OTA에서 AI 추천 품질은 모델 크기보다 데이터 신뢰성에 더 크게 좌우될 수 있다. AI가 아무리 자연스럽게 설명해도, 실제 예약 가능 여부와 가격이 틀리면 서비스 신뢰가 무너진다. 특히 OTA는 공급사가 많고 상품 구조가 복잡하다. 호텔 직접 계약, 글로벌 공급사, 항공 GDS 또는 제휴 API, 티켓 공급사, 현지 투어 운영사, 쿠폰·멤버십 시스템, 결제 시스템, 고객지원 시스템이 서로 다른 속도로 변한다.

AI 호출을 전제로 하면 OTA 데이터는 최소한 네 층으로 정리되어야 한다.

첫째, 상품 정체성 데이터다. 숙소 ID, 객실 타입, 항공편, 티켓 상품, 패키지 구성, 위치, 시설, 포함·불포함 항목, 공급사, 판매 채널 같은 기본 식별 정보다. 이 층이 흔들리면 AI는 같은 상품을 다른 상품처럼 비교하거나, 다른 조건의 객실을 같은 객실처럼 설명할 수 있다.

둘째, 실시간 거래 데이터다. 재고, 가격, 세금·수수료, 운임 조건, 예약 가능 여부, 좌석 또는 객실 수량, 판매 마감 시간, 체크인·체크아웃 가능 시간 등이 여기에 속한다. 이 데이터는 캐시가 필요하지만, 사용자가 결제나 예약 확정에 가까워질수록 반드시 재검증되어야 한다.

셋째, 정책 데이터다. 취소·환불 규정, 변경 가능 여부, 노쇼 정책, 아동 동반 조건, 반려동물 정책, 신분증 요구, 보증금, 현장 결제 비용, 쿠폰 적용 조건, 멤버십 혜택, 결제수단 제한이 여기에 포함된다. AI는 정책을 요약할 수 있지만, 정책 자체를 꾸며내서는 안 된다. 원문 정책과 요약 결과를 함께 관리해야 한다.

넷째, 사용자 맥락 데이터다. 과거 예약 이력, 선호 지역, 동행 유형, 예산 범위, 멤버십 등급, 보유 쿠폰, 알림 선호, 접근성 요구, 고객지원 이력 등이 여기에 들어간다. 이 데이터는 추천 품질을 높이지만 프라이버시 리스크도 크다.

이 네 층을 분리해야 하는 이유는 업데이트 주기와 권한이 다르기 때문이다. 상품 설명은 비교적 느리게 바뀌지만 가격은 빠르게 바뀐다. 취소 정책은 상품별로 다르고 법적·계약적 책임이 따른다. 사용자 맥락은 동의와 접근 범위가 필요하다. AI에게 한 덩어리 텍스트로 넘기면 설명은 쉬워지지만 통제는 어려워진다.

실무적으로는 “AI가 읽는 설명 데이터”와 “예약 판단에 쓰는 권위 데이터”를 구분해야 한다. 예를 들어 AI가 숙소 설명을 생성할 때는 요약 인덱스를 사용할 수 있지만, 예약 가능 여부와 최종 가격은 실시간 조회 도구에서만 가져와야 한다. 취소 수수료는 자연어 설명으로 캐시하지 말고, 예약 ID와 시점 기준으로 계산하거나 공급사 정책을 다시 확인해야 한다. MCP의 Tools 개념은 이런 권위 있는 서버 측 작업을 AI가 호출하도록 만드는 데 적합하다. 출처: Tools – Model Context Protocol

위험도별 액션 설계: AI가 할 수 있는 일과 멈춰야 하는 일

OTA에서 모든 액션을 같은 권한으로 열면 안 된다. AI가 후보를 찾는 것과 예약을 취소하는 것은 완전히 다른 위험을 갖는다. 실무자는 액션을 최소 네 단계로 나눠야 한다.

단계 액션 유형 예시 승인 방식
1단계 공개·저위험 조회 여행지 검색, 일반 상품 검색, 공개 리뷰 요약 사용자 확인 없이 가능
2단계 개인화 조회 내 쿠폰 확인, 내 예약 조회, 멤버십 혜택 확인 로그인·권한 확인 필요
3단계 변경 전 검토 예약 변경 가능 여부, 취소 수수료 계산, 환불 예상액 조회 결과 표시 후 사용자 확인
4단계 되돌리기 어려운 실행 결제, 예약 확정, 취소 접수, 환불 요청, 일정 변경 확정 명시적 동의, 재확인, 감사 로그 필수

AI 에이전트의 설계 원칙은 단순하다. 낮은 위험의 조회는 빠르게, 높은 위험의 실행은 느리게 해야 한다. 사용자가 “가장 저렴한 숙소로 예약해줘”라고 말해도, 시스템은 곧바로 결제하면 안 된다. 최소한 최종 가격, 취소 조건, 체크인 조건, 결제수단, 쿠폰 적용 결과, 환불 불가 여부, 사용자 동의 문구를 다시 보여줘야 한다.

특히 취소와 변경은 UX에서 조심해야 한다. 사용자는 “취소하면 얼마 돌려받아?”라고 물었는데 AI가 “취소 요청”까지 진행하면 심각한 문제가 된다. 따라서 “조회”, “시뮬레이션”, “실행”을 도구 수준에서 분리해야 한다. `cancelPolicyCheck`와 `submitCancellation`은 같은 도구가 되어서는 안 된다. 전자는 예상 수수료를 반환하고, 후자는 사용자의 명시적 확인 이후에만 호출되어야 한다.

MCP Tools 문서는 도구 호출이 사용자 상호작용 모델과 연결된다는 점을 다룬다. OTA는 이를 제품 정책으로 번역해야 한다. 어떤 도구가 사용자 확인 없이 실행 가능한지, 어떤 도구가 민감 데이터 접근을 요구하는지, 어떤 도구가 금전적 손실을 유발할 수 있는지를 명시해야 한다. 도구 명세는 개발 편의 문서가 아니라 리스크 통제 문서가 되어야 한다. 출처: Tools – Model Context Protocol

“아이와 며칠간” 요청은 어떻게 실행 흐름이 되는가

실제 시나리오로 보자. 사용자가 AI에게 이렇게 요청한다.

“초등학생 아이와 함께 며칠간 갈 수 있는 여행을 추천해줘. 너무 빡빡하지 않았으면 좋겠고, 예산은 항공과 숙소 합쳐서 무리 없는 선이면 좋겠어. 취소가 너무 어려운 상품은 피하고 싶어.”

좋은 OTA 호출 구조라면 AI는 다음 순서로 움직일 수 있다.

  1. 조건 정리

여행 기간, 동행 유형, 예산 범위, 선호 이동 강도, 취소 유연성 같은 조건을 구조화한다. 예산이 모호하면 “대략 1인 기준인지, 가족 전체 기준인지”를 되묻는다.

  1. 목적지 후보 생성

항공 접근성, 계절성, 가족 동반 콘텐츠, 이동 부담을 기준으로 목적지 후보를 좁힌다. 이 단계는 정적 콘텐츠와 과거 인기 데이터를 활용할 수 있다.

  1. 항공권 후보 조회

날짜 범위와 인원 조건으로 항공편 후보를 조회한다. 운임 조건, 수하물, 환불 가능 여부, 출도착 시간대를 구조화해 반환한다.

  1. 숙소 후보 조회

목적지별 가족 동반 가능 숙소, 객실 최대 인원, 조식, 위치, 취소 정책, 재고, 총액을 확인한다. “아이 동반 적합”은 리뷰 감성만으로 판단하지 않고 객실·시설·정책 데이터와 연결한다.

  1. 쿠폰·멤버십 적용 가능성 확인

사용자 동의와 로그인 상태가 있으면 보유 쿠폰, 멤버십 혜택, 결제수단 조건을 계산한다. 실제 결제 단계에서는 다시 검증한다.

  1. 일정 초안 생성

항공 시간, 숙소 위치, 아이 동반 이동 부담, 실내 대안, 휴무일을 고려해 느슨한 일정을 만든다. 관광지·체험 데이터는 최신 영업시간과 예약 조건을 확인해야 한다.

  1. 취소·변경 리스크 설명

후보별로 “가격은 낮지만 환불 제한이 큼”, “가격은 높지만 취소 유연성이 좋음” 같은 판단 근거를 제시한다.

  1. 사용자 승인 대기

예약 확정, 결제, 취소 불가 조건 동의는 사용자가 직접 확인해야 한다.

사용상황 입력 실행흐름 출력 주의점
가족 여행 후보 찾기 동행자, 날짜 범위, 예산, 이동 강도 목적지 후보 → 항공·숙소 조회 → 가족 조건 검증 후보별 총액, 이동 부담, 취소 유연성 “아이 동반 적합”은 리뷰 감성만으로 판단하지 않음
비 오는 날 대안 일정 목적지, 여행일, 실내 선호 날씨·운영시간 확인 → 실내 장소 후보 → 이동 동선 구성 오전·오후 대안 일정 영업시간·휴무일·예약 필요 여부 재확인
쿠폰 반영 최저가 비교 사용자 동의, 상품 후보, 결제수단 쿠폰·멤버십 조회 → 적용 가능성 계산 → 결제 직전 재검증 예상 할인액과 최종 결제 전 확인 항목 실제 결제 금액은 결제 직전 권위 데이터로 재검증
취소 위험 낮은 상품 찾기 후보 상품, 취소 선호 정책 원문 조회 → 수수료 조건 비교 → 위험도 라벨링 환불 제한, 변경 가능성, 주의 문구 예상 안내와 확정 실행 분리
예약 후 고객지원 문의 예약 ID, 문제 설명 예약 상태 조회 → 정책 확인 → 문의 유형 분류 → 상담원 인계 요약 티켓 번호, 필요 증빙, 처리 흐름 보상·예외 승인은 자동 확정하지 않음

이 흐름에서 AI의 역할은 “가장 그럴듯한 문장 생성”이 아니다. 여러 도구 호출 결과를 종합하고, 사용자가 놓치기 쉬운 조건을 드러내며, 결제 전 판단을 돕는 것이다.

이때 App Intents는 사용자 기기 안의 빠른 진입점으로 의미가 있다. 예를 들어 사용자는 Siri나 Spotlight에서 “다가오는 제주 예약 보여줘”, “오늘 체크인 정보 열어줘”, “예약 취소 규정 확인해줘” 같은 동작을 실행할 수 있다. Apple 문서는 앱의 actions와 content를 시스템 기능과 넓게 통합할 수 있도록 App Intents를 제공한다고 설명한다. 출처: Making actions and content discoverable and widely available, Making app entities available in Spotlight – Apple Developer

개인화는 추천 품질을 높이지만, 권한 설계 없이는 부채가 된다

여행 추천은 개인화될수록 좋아진다. 아이 동반 여부, 과거 선호 지역, 주말 여행 빈도, 멤버십 등급, 보유 쿠폰, 선호 숙소 등급, 항공 시간대 선호, 이동 방식, 접근성 요구는 추천 품질을 크게 바꿀 수 있다. 같은 “부산 여행”이라도 혼자 가는 출장, 부모님과 가는 가족 여행, 아이와 가는 휴가, 친구와 가는 공연 여행은 완전히 다른 후보를 요구한다.

하지만 개인화는 곧 민감 데이터 접근이다. 여행 이력은 사용자의 생활 패턴과 관계망을 드러낼 수 있다. 가족 구성, 아이 동반 여부, 위치, 결제수단, 멤버십 등급, 고객지원 이력은 모두 조심스럽게 다뤄야 한다. AI 호출 구조에서는 “AI가 알면 좋은 정보”와 “AI에게 항상 줘도 되는 정보”를 분리해야 한다.

실무적으로는 세 가지 원칙이 필요하다.

첫째, 목적 제한이다. “아이 동반 숙소 추천”에는 아이 동반 여부와 객실 조건이 필요할 수 있지만, 과거 모든 여행 이력이 필요한 것은 아니다. 도구별로 필요한 최소 데이터만 넘겨야 한다.

둘째, 단계별 동의다. 공개 상품 검색은 익명으로 가능할 수 있다. 하지만 내 쿠폰, 멤버십, 예약 이력, 결제수단을 활용하려면 사용자의 로그인과 명시적 권한이 필요하다. “보유 쿠폰까지 반영해 볼까요?”처럼 데이터 사용 목적을 분리해 물어야 한다.

셋째, 설명 가능한 개인화다. AI가 “이 숙소를 추천합니다”라고만 말하면 사용자는 왜 개인화됐는지 알 수 없다. “이전 가족 여행에서 조식 포함 숙소를 선택했고, 이번 조건에서도 아동 조식 정책이 명확하며, 취소 가능 요금제가 남아 있기 때문”처럼 근거를 제공해야 한다. 단, 민감한 과거 이력을 불필요하게 노출하지 않도록 표현 수준을 조절해야 한다.

개인화 AI 서비스가 여러 맥락 데이터를 사용자의 동의 아래 활용하려는 흐름은 OTA에도 시사점을 준다. OTA도 개인화의 이점을 얻을 수 있지만, 여행 데이터는 일정·위치·동행자·결제 맥락을 포함할 수 있으므로 동의, 최소 수집, 목적 제한, 로그 관리가 제품 설계의 일부가 되어야 한다. 출처: “매일 아침 나를 위한 스토리 생성”… 구글, 맞춤형 AI 브리핑 ‘드림빈즈’ 공개

고객지원 자동화는 답변보다 책임 경계가 중요하다

OTA의 AI 활용은 검색과 예약에서 끝나지 않는다. 실제 운영 비용과 사용자 불만은 예약 이후에 많이 발생한다. 체크인 문제, 예약 누락, 숙소 현장 결제 분쟁, 항공편 지연, 취소 수수료 문의, 환불 지연, 쿠폰 미적용, 이름 오기재, 일정 변경 같은 이슈가 고객지원으로 들어온다.

AI 에이전트는 고객지원에서 큰 역할을 할 수 있다. 예약 상세를 조회하고, 정책을 확인하고, 사용자의 문의를 유형화하고, 필요한 증빙을 안내하고, 상담원에게 넘길 요약을 생성할 수 있다. 하지만 고객지원 자동화는 잘못하면 “빠른 오답”을 대량 생산한다. OTA에서 잘못된 환불 안내나 취소 가능 안내는 금전 손실과 법적 분쟁으로 이어질 수 있다.

따라서 고객지원 AI는 다음처럼 역할을 나눠야 한다.

역할 AI 자동화 가능성 조건
문의 분류 높음 예약 ID, 문제 유형, 긴급도 구조화
정책 조회 중간 원문 정책과 기준 시점 표시
환불 예상 안내 중간 “예상”과 “확정” 구분, 실행 전 재확인
증빙 요청 높음 유형별 체크리스트 제공
상담원 인계 요약 높음 사용자 발화, 예약 상태, 도구 호출 로그 포함
보상·예외 승인 낮음 내부 정책과 권한자 승인 필요

운영 로그는 필수다. 어떤 사용자 요청이 들어왔고, 어떤 도구가 호출됐고, 어떤 데이터 기준 시점으로 답변했으며, 사용자가 어떤 확인을 눌렀는지 남겨야 한다. 에이전트 운영을 API와 마이크로서비스처럼 추적하려는 컨트롤 플레인 접근이 주목받는 이유도 여기에 있다. 에이전트 실행을 워크플로우로 추적하고, 정책에 따라 호출 허용·거부를 결정하며, 감사 기록을 남기는 구조는 OTA 고객지원에도 필요한 사고방식이다. 출처: AgentField: AI 에이전트를 API와 마이크로서비스처럼 운영하기 위한 오픈소스 컨트롤 플레인

OTA의 내부 아키텍처는 “AI용 API”보다 “정책 있는 도구 계층”이 필요하다

많은 조직이 AI 연동을 시작할 때 기존 API를 그대로 열려고 한다. 하지만 기존 API는 보통 화면 렌더링이나 내부 서비스 간 통신에 맞춰져 있다. AI가 호출하기에는 입력이 너무 세부적이거나, 출력이 너무 방대하거나, 권한 경계가 불분명할 수 있다.

OTA에 필요한 것은 기존 API 위에 놓이는 도구 계층이다. 이 계층은 다음 책임을 가져야 한다.

  • 작업 목적을 명확히 표현한다. 예: “숙소 검색”이 아니라 “가족 동반 조건을 반영한 예약 가능 숙소 후보 조회”.
  • 입력 스키마를 제한한다. 날짜, 인원, 지역, 예산, 사용자 선호 같은 필드를 명확히 정의한다.
  • 출력 스키마를 설명 가능하게 만든다. 가격, 재고, 정책, 근거, 기준 시점, 불확실성을 분리한다.
  • 권한을 내장한다. 사용자 데이터 접근, 예약 조회, 결제, 취소는 각각 다른 권한을 요구한다.
  • 감사 로그를 남긴다. 호출 주체, 사용자 동의, 입력, 출력 요약, 정책 판단, 실패 사유를 기록한다.
  • 실패를 제품적으로 처리한다. 재고 없음, 가격 변경, 공급사 오류, 정책 불명확, 권한 부족을 AI가 사용자에게 설명할 수 있는 형태로 반환한다.

MCP는 이런 도구 계층을 외부 AI와 연결하는 표준화된 접점으로 활용될 수 있다. 다만 MCP 서버를 세우는 것만으로 제품이 준비되는 것은 아니다. 서버가 노출하는 도구가 잘못 설계되면 AI는 부정확한 결과를 더 빠르게 호출할 뿐이다. 도구 명세는 서비스 정책, 법무·보안 기준, 운영 인계 기준과 함께 설계되어야 한다. 출처: Specification – Model Context Protocol, Tools – Model Context Protocol

App Intents는 “앱을 열게 하는 기술”이 아니라 “앱의 능력을 드러내는 기술”이다

모바일 OTA 입장에서 App Intents의 의미는 단순한 음성 명령 추가가 아니다. 사용자가 앱 화면을 깊게 탐색하지 않아도, 시스템 수준에서 앱의 특정 기능과 콘텐츠를 발견하고 실행할 수 있게 하는 것이다.

예를 들어 여행 앱은 다음과 같은 App Intents 후보를 가질 수 있다.

  • 다가오는 예약 보기
  • 오늘 체크인 정보 열기
  • 특정 예약의 취소 규정 확인
  • 저장한 숙소 목록 열기
  • 보유 쿠폰 확인
  • 여행 일정에 예약 추가
  • 고객지원 문의 상태 확인

그리고 AppEntity 후보는 다음처럼 잡을 수 있다.

  • 예약
  • 숙소
  • 항공편
  • 여행 일정
  • 쿠폰
  • 고객지원 문의
  • 멤버십 혜택

중요한 것은 App Intent가 화면 바로가기만 되어서는 안 된다는 점이다. “예약 상세 화면 열기”보다 “예약의 체크인 정보를 보여주기”, “취소 규정을 확인하기”, “숙소 주소를 지도에 전달하기”처럼 사용자의 의도를 반영한 작업이 더 가치 있다. Apple 문서는 App Intents를 통해 앱의 actions와 data를 시스템 기능과 통합하고, AppEntity를 통해 앱 고유 개념을 시스템 경험에 노출할 수 있다고 설명한다. 출처: Integrating actions with Siri and Apple Intelligence | Apple Developer Documentation, AppEntity | Apple Developer Documentation

다만 App Intents는 지원되는 환경과 플랫폼 정책 안에서 작동한다. 모든 사용자가 같은 AI 경험을 즉시 쓰게 된다고 단정해서는 안 된다. OTA는 App Intents를 “iOS 사용자 경험의 한 접점”으로 보고, 앱 내부 검색·알림·위젯·고객지원·외부 AI 연동과 함께 설계해야 한다.

AI가 읽는 콘텐츠도 바뀐다: 사람용 상세페이지와 에이전트용 설명

앞으로 OTA의 상품 상세페이지는 사람만 읽는 문서가 아닐 수 있다. AI 에이전트가 사용자를 대신해 상품을 비교하고 추천할 가능성이 커질수록, 서비스는 에이전트가 정확히 해석할 수 있는 구조화된 설명을 제공해야 한다.

사람용 상세페이지는 이미지, 감성 문구, 후기, 프로모션 배너가 중요하다. 반면 에이전트용 설명은 다음 요소가 중요하다.

  • 상품의 고유 식별자
  • 가격과 재고의 기준 시점
  • 포함·불포함 항목
  • 취소·환불 정책 원문과 요약
  • 가족·아동·반려동물·접근성 조건
  • 체크인·체크아웃, 운영 시간, 휴무일
  • 쿠폰·멤버십 적용 가능 여부
  • 추천 근거와 제한 사항
  • 데이터 신뢰도와 갱신 시점

이 관점은 콘텐츠 산업에서도 나타난다. AI가 사람을 대신해 콘텐츠를 읽고 추천 여부를 결정하는 상황에서는, 사람에게만 매력적인 페이지가 아니라 AI가 올바르게 해석할 수 있는 구조가 중요해진다. OTA에서는 이 문제가 더 실무적이다. AI가 숙소를 잘못 추천하면 사용자의 여행 일정과 비용에 직접 영향을 준다. 출처: 공존의 시대, 인공지능과의 협업 지능은 끝났는가

실무자가 지금 점검해야 할 준비 목록

OTA 조직이 지금 할 일은 거창한 AI 비전을 발표하는 것이 아니라 호출 가능한 서비스 구조를 점검하는 것이다. 다음 질문에 답할 수 있어야 한다.

첫째, 우리 서비스의 핵심 작업 단위가 정의되어 있는가. 숙소 검색, 객실 확인, 항공권 검색, 쿠폰 적용, 예약 조회, 변경 가능 여부 확인, 취소 수수료 계산, 고객지원 문의 생성이 각각 독립 도구로 설명 가능한가.

둘째, 각 작업의 입력과 출력이 안정적인가. AI가 자연어를 구조화했을 때 넣을 수 있는 필드가 명확한가. 출력은 후보 목록만이 아니라 기준 시점, 가격 구성, 재고 상태, 정책 근거, 불확실성을 포함하는가.

셋째, 위험도별 권한과 승인 흐름이 있는가. 조회, 개인화 조회, 시뮬레이션, 실행이 분리되어 있는가. 결제·예약 확정·취소·환불 요청에는 명시적 사용자 확인이 들어가는가.

넷째, 실시간 데이터와 설명 데이터가 분리되어 있는가. AI가 참고하는 요약과 실제 예약 판단에 쓰는 권위 데이터가 섞여 있지 않은가. 최종 가격과 취소 정책은 예약 직전 재검증되는가.

다섯째, 개인화 데이터 사용 목적이 분리되어 있는가. 사용자 이력, 쿠폰, 멤버십, 결제수단, 가족 구성 정보를 어떤 도구가 어떤 목적에서 쓰는지 설명할 수 있는가.

여섯째, 고객지원 인계 기준과 로그가 있는가. AI가 해결할 수 있는 문의와 상담원에게 넘겨야 하는 문의가 구분되어 있는가. 도구 호출 로그와 사용자 동의 기록이 남는가.

일곱째, App Intents와 MCP의 역할이 혼동되지 않는가. iOS 시스템 경험에 드러낼 앱 기능과 외부 AI가 호출할 서버 측 도구를 별도 설계하고 있는가.

체크리스트로 정리하면 다음과 같다.

  • 핵심 OTA 작업 단위가 화면이 아니라 도구 단위로 정의되어 있다.
  • 각 도구의 입력·출력·실패 응답·기준 시점이 문서화되어 있다.
  • 공개 조회, 개인화 조회, 시뮬레이션, 실행 권한이 분리되어 있다.
  • 결제·예약 확정·취소·환불 요청에는 명시적 재확인 흐름이 있다.
  • 가격·재고·취소 정책은 예약 직전 권위 데이터로 재검증된다.
  • 개인화 데이터는 목적별 동의와 최소 접근 원칙을 따른다.
  • AI 답변에는 근거 데이터, 기준 시점, 불확실성이 함께 표시된다.
  • 고객지원 자동화는 상담원 인계 기준과 감사 로그를 포함한다.
  • App Intents는 기기 안의 빠른 동작과 콘텐츠 발견에, MCP는 외부 AI의 서버 측 도구 호출에 쓰도록 역할이 구분되어 있다.

결론: OTA의 다음 경쟁력은 “많이 보여주기”보다 “안전하게 실행하기”

AI 에이전트 시대의 여행 OTA는 검색 결과를 많이 보여주는 앱에서, 사용자의 조건을 해석하고 예약 가능한 선택지를 안전하게 호출하는 여행 실행 플랫폼으로 확장될 수 있다. 이 변화는 한 번의 챗봇 도입으로 완성되지 않는다. 상품 데이터, 실시간 가격, 정책 데이터, 사용자 권한, 승인 흐름, 고객지원 운영이 함께 바뀌어야 한다.

App Intents는 앱의 기능과 데이터를 Apple 시스템 경험 안에서 발견되고 실행되게 만드는 접점이 될 수 있다. MCP는 외부 AI 에이전트가 OTA의 데이터와 작업을 표준화된 방식으로 호출하는 접점이 될 수 있다. 하지만 두 기술 모두 목적이 아니라 수단이다. 진짜 과제는 “AI에게 무엇을 맡길 것인가”, “어디서 멈추게 할 것인가”, “어떤 데이터만 믿게 할 것인가”, “사용자에게 어떤 순간 다시 확인받을 것인가”를 정하는 일이다.

여행은 사용자의 시간, 돈, 이동, 가족 계획이 얽힌 서비스다. 그래서 AI 자동화의 가치는 속도보다 신뢰에서 나온다. 좋은 OTA는 AI가 마음대로 예약하게 만드는 서비스가 아니라, AI가 복잡한 조건을 정리하고, 최신 재고와 정책을 확인하고, 사용자가 되돌리기 어려운 결정을 하기 전 정확한 판단 근거를 제시하게 만드는 서비스가 될 가능성이 크다.

참고 출처