호텔 예약 퍼널의 중간 단계가 사라졌어요. 2026년 1분기, Google은 AI Mode에 에이전트형 호텔 예약을 도입했고, Perplexity는 자율 여행 예약 에이전트를 출시했습니다. 두 시스템 모두 여행자의 자연어 요청을 받아서 수십 가지 기준으로 숙소를 평가하고, 사용자가 예약 페이지를 열거나, 검색 결과를 클릭하거나, 선택지를 수동으로 비교하는 일 없이 예약을 완료할 수 있어요.
IDC의 2026년 호스피탈리티 예측은 직접적으로 말했습니다: "에이전트형 AI가 2026년에 여행과 호스피탈리티를 재정의할 것이다." Hilton CEO는 2025년 4분기 실적 발표에서 이 변화를 확인했어요. Phocuswright의 소비자 조사에 따르면 여행자의 89%가 여행 계획과 예약에서 AI의 도움을 원한다고 했습니다.
호텔 운영자와 호스피탈리티 기술 팀에게 미치는 영향은 즉각적이에요. 사람이 Booking.com을 탐색할 때, 여러분 숙소는 사진, 가격, 리뷰 점수로 경쟁합니다. AI 에이전트가 숙소를 평가할 때는 구조화된 데이터로 경쟁해요. 구체적으로, 대부분의 숙소가 한 번도 공개하지 않은 기계 가독성 위치 속성으로요. 교통 접근성, 도보 점수, 인근 POI 목록, 주차 데이터: 이것들이 에이전트가 여러분 숙소를 후보 목록에 넣을지, 아니면 완전히 건너뛸지를 결정하는 신호입니다.
에이전트형 호텔 예약의 작동 방식: 의사결정 루프
AI 예약 에이전트 내부에서 무슨 일이 일어나는지 이해하면 위치 데이터가 왜 이렇게 중요한지 명확해집니다.
여행자가 입력합니다: "바르셀로나에서 해변 근처, 레스토랑까지 도보 거리, 주차 가능, 1박 200유로 이하 호텔 예약해줘." 전통적인 흐름에서는 Booking.com을 열고, 필터를 설정하고, 결과를 스크롤하고, 리뷰를 읽고, "예약하기"를 클릭할 거예요. AI 에이전트는 이걸 하나의 자동화된 루프로 압축합니다.
1단계: 쿼리 분해. 에이전트는 요청을 구조화된 제약으로 분해해요: 도시(바르셀로나), 근접 요건(해변 근처), 도보 요건(레스토랑 도보 거리), 시설 요건(주차), 가격 상한(200EUR/박).
2단계: 후보 검색. 에이전트는 통합 플랫폼의 가용 재고를 조회하여 하드 제약(도시, 가격, 날짜)을 충족하는 숙소를 가져옵니다.
3단계: 위치 속성 평가. 대부분의 숙소가 여기서 실패해요. 에이전트는 각 후보를 위치별 요구사항에 대해 평가합니다. "해변 근처"에는 에이전트가 해안선 데이터와 매칭할 수 있는 구조화된 거리 속성이나 좌표가 필요합니다. "레스토랑 도보 거리"에는 도보 점수나 도보 반경 내 레스토랑 수를 보여주는 구조화된 POI 목록이 필요해요. "주차 가능"에는 기계 가독성 주차 속성이 필요합니다.
4단계: 랭킹과 선택. 모든 체크를 통과한 숙소는 리뷰 감성, 가격 경쟁력, 데이터 완전성의 조합으로 순위가 매겨집니다. 에이전트는 최상위 옵션을 선택하거나 2~3개의 후보 목록을 제시해요.
5단계: 예약 실행. 에이전트는 통합 예약 API를 통해 예약을 완료해요. 여행자가 전통적인 listing 페이지를 전혀 보지 못하는 경우도 많습니다.
핵심: 3단계와 4단계는 완전히 프로그래밍 방식이에요. 아무도 여러분 사진을 스캔하거나 설명을 읽지 않아요. 에이전트는 구조화된 데이터 필드를 파싱하고 있습니다. 그 필드들이 비어 있으면, 여러분 숙소는 랭킹 단계에 도달하기 전에 제거됩니다.
예약 에이전트를 도입한 플랫폼들
에이전트형 예약 환경은 2026년 1분기에 빠르게 확장됐어요.
Google AI Mode는 호텔 예약을 첫 번째 에이전트형 커머스 수직 중 하나로 추가했어요. 사용자가 AI Mode에서 호텔을 검색하면, Google의 에이전트는 Booking.com, Expedia, Marriott, IHG, Wyndham과의 직접 연동을 통해 숙소를 평가할 수 있습니다. 에이전트는 전체 루프를 처리해요: 검색, 평가, 비교, 예약. Google은 2026년 3월 제품 이벤트에서 이를 확인하며 "Search가 여러분을 위해 일을 하는 다음 단계"라고 불렀습니다.
Perplexity는 수개월의 베타 테스트 끝에 2026년 초에 여행 예약 에이전트를 출시했어요. 에이전트는 여러 호텔 재고 소스와 통합되고 Perplexity 인터페이스 내에서 예약을 완료할 수 있습니다. Google의 접근 방식과 달리, Perplexity의 에이전트는 소스 투명성을 강조하여 어떤 데이터 포인트가 추천에 영향을 미쳤는지 보여줍니다.
Booking.com의 AI Trip Planner는 대화형 검색 도구에서 예약 에이전트로 발전했어요. 이제 자율적인 호텔 선택과 예약을 포함한 다구간 여행 계획을 처리합니다. 시스템은 Booking.com의 내부 구조화 데이터를 사용하는데, 이는 엑스트라넷에 더 풍부한 데이터를 가진 숙소가 상당한 이점을 갖는다는 의미예요.
Expedia의 Romie 에이전트는 Expedia 앱 내에서 호텔 예약을 포함한 엔드투엔드 여행 계획을 처리합니다. Romie는 Expedia의 재고 데이터와 호텔 웹사이트의 공개적으로 이용 가능한 구조화 데이터를 사용해요.
공통점: 이 에이전트들은 모두 구조화된 기계 가독성 데이터를 기반으로 결정을 내립니다. 사람이 읽을 수 있는 설명문, 사진, 별점 평가만 있는 숙소는 데이터 싸움에 브로셔를 들고 가는 거예요.
AI 예약 에이전트가 평가하는 데이터 신호들
Google AI Mode, Perplexity, Booking.com의 AI Trip Planner 테스트를 통해, 에이전트가 호텔 숙소를 평가하는 방식에서 명확한 데이터 신호 계층이 드러났습니다.
티어 1: 하드 필터 (통과/실패). 도시, 날짜, 가격대, 별점 등급, 기본 시설 체크리스트(수영장, WiFi, 조식). OTA 플랫폼이 이러한 필드를 표준화했기 때문에 거의 모든 숙소가 이 티어를 통과해요. 이 티어는 차별화를 만들지 않습니다.
티어 2: 위치 속성 (차별화 요소). 80%의 숙소가 여기서 실패해요. 에이전트가 평가하는 항목:
- 쿼리에서 언급된 위치까지의 거리 (해변, 시내 중심, 컨벤션 센터, 공항)
- 교통 접근성 (지하철/버스 거리, 공항 셔틀 가용 여부)
- 식당, 쇼핑, 서비스까지의 도보 접근성
- 주차장 가용 여부, 유형, 비용
- 동네 특성 (비즈니스 지구, 역사 중심지, 해변가, 주거 지역)
티어 3: 평판 신호. 리뷰 점수, 리뷰 수, 최신성, 특정 주제(청결도, 위치 정확성, 소음 수준)에 대한 감성. 기존 OTA 인프라에 의해 잘 커버됩니다.
티어 4: 강화 데이터. 지속가능성 인증, 접근성 기능, 상세한 객실 수준 속성. 특정 쿼리에는 중요하지만 총 예약량의 더 적은 비율에 영향을 미칩니다.
호텔의 구조적 문제: 티어 1과 3은 기존 OTA 플랫폼에 의해 잘 처리됩니다. 티어 2, 위치 속성 레이어는 대부분의 숙소 listing에서 거의 완전히 빠져있어요. 그리고 티어 2가 정확히 위치별 예약 쿼리의 대부분에서 에이전트 선택을 결정하는 요소입니다.
에이전트 선택을 결정하는 6가지 위치 속성
에이전트형 예약 플랫폼의 쿼리 분석을 통해, 여섯 가지 위치 속성이 에이전트의 평가 로직에서 가장 자주 등장합니다.
1. 대중교통 접근성
가장 가까운 지하철역이나 버스 정류장이 얼마나 멀리 있나요? 공항 셔틀이 있나요? 공항까지 택시나 라이드셰어로 얼마나 걸리나요? 에이전트는 설명에 "대중교통 이용 편리"라고 적힌 문장이 아니라 구조화된 데이터에서 이를 해결합니다. 데이터는 구체적이어야 해요: "지하철 L3 Diagonal역, 도보 280미터."
2. 식당과 서비스까지 도보 접근성
10분 도보 거리에 레스토랑이 몇 개 있나요? 근처에 마트가 있나요? 약국은요? 이 질문들은 예약 쿼리의 많은 부분에서 등장해요. 종종 암묵적으로요. "로마에서 가족 호텔"이라는 쿼리는 에이전트가 가족에게는 근처에 서비스가 필요하다고 추론하기 때문에 도보 접근성 평가를 촉발합니다. 구조화된 POI 목록(레스토랑 수, 카테고리, 거리)을 가진 숙소는 더 높은 점수를 받아요.
3. 주요 명소와의 근접성
"콜로세움 근처 호텔", "컨벤션 센터 가까운 호텔", "구시가지 도보 거리 호텔." 이런 쿼리는 에이전트가 숙소에서 이름 있는 명소까지의 거리를 계산해야 합니다. 숙소 측에 지리 좌표가 없으면 에이전트는 이 계산을 신뢰할 수 있게 수행하지 못해요. 거리가 포함된 인근 명소의 구조화된 목록이 없으면, 에이전트는 숙소를 근접성 쿼리와 능동적으로 매칭할 수 없습니다.
4. 주차 가용 여부
주차는 호텔 데이터에서 가장 구조화가 부족한 속성이에요. 대부분의 OTA는 "주차 가능" 이진 플래그만 있습니다. 에이전트는 주차 유형(온사이트 주차장, 발레파킹, 노상 주차), 예약 필요 여부, 비용을 점점 더 많이 평가하고 있어요. 이 데이터를 완전히 구조화한 숙소는 자가용 여행의 성장하는 세그먼트를 잡을 수 있습니다.
5. 동네 특성
"관광 지역에서 떨어진 조용한 호텔", "나이트라이프 지구 호텔", "비즈니스 센터 호텔." 에이전트는 숙소의 동네를 분류해야 합니다. 이 데이터는 구조화된 형태로 거의 존재하지 않아요. 주거 지역의 숙소는 "중심지" 쿼리에서 관광 지역 숙소에 예약을 빼앗기고, 반대도 마찬가지예요. 단지 에이전트가 이용 가능한 listing 데이터에서 동네 특성을 파악할 수 없기 때문입니다.
6. 검증된 지리 좌표
이것이 모든 것의 기반이에요. 위의 모든 위치 속성은 에이전트가 숙소가 정확히 어디에 있는지 알고 있다는 것에 의존합니다. 주소 문자열은 모호해요. 소수점 4자리 이상의 지리 좌표는 그렇지 않습니다. 그러나 놀라울 정도로 많은 호텔 숙소가, 특히 독립 호텔과 소규모 체인이 OTA 플랫폼 외부의 구조화된 데이터에 검증된 지리 좌표를 갖추지 못하고 있어요.
지금 당장 예약 에이전트에게 보이지 않는 80%의 숙소들
수학은 간단해요. 주요 OTA의 대부분 호텔은 티어 1 데이터가 커버됩니다: 이름, 주소, 가격, 별점, 기본 시설, 사진. 사람이 브라우징할 때는 그 데이터로 충분했어요. 하지만 티어 2 위치 속성 레이어, 위의 여섯 가지 속성은 없거나 숙소 설명의 비구조화 텍스트로만 존재합니다.
전형적인 호텔 listing이 구조화된 데이터에서 어떻게 보이는지 생각해봐요:
{
"@type": "Hotel",
"name": "Hotel Marítim Barcelona",
"address": "Passeig de Joan de Borbó 64, Barcelona",
"starRating": 4,
"priceRange": "€€",
"amenityFeature": ["WiFi", "Pool", "Breakfast"]
}
에이전트가 이 데이터로 답할 수 있는 것: "바르셀로나에 있나요? 네. 4성급인가요? 네. 수영장이 있나요? 네." 하지만 답할 수 없는 것: "해변에 가까운가요? 모름. 도보 거리에 지하철이 있나요? 모름. 근처에 레스토랑이 몇 개 있나요? 모름. 주차장이 있고 어떤 유형인가요? 모름."
"바르셀로나 해변 근처, 주차 가능, 레스토랑 도보 거리의 4성급 호텔"이라는 쿼리에 대해, 이 숙소는 에이전트의 의사결정 루프 3단계에서 실패합니다. 필터링됩니다. 여행자는 절대 보지 못해요.
이제 같은 숙소에 풍부한 위치 데이터를 추가했을 때:
{
"@type": "Hotel",
"name": "Hotel Marítim Barcelona",
"address": "Passeig de Joan de Borbó 64, Barcelona",
"geo": {
"@type": "GeoCoordinates",
"latitude": 41.3758,
"longitude": 2.1894
},
"starRating": 4,
"priceRange": "€€",
"amenityFeature": ["WiFi", "Pool", "Breakfast", "On-site parking garage"],
"tourismNearby": [
{ "name": "Barceloneta Beach", "distance": "150m" },
{ "name": "La Barceloneta Metro (L4)", "distance": "200m" },
{ "name": "Maremagnum Shopping Centre", "distance": "600m" }
],
"walkabilityContext": {
"restaurants_within_500m": 47,
"grocery_stores_within_500m": 3,
"pharmacy_within_500m": 2
}
}
이 숙소는 쿼리의 모든 제약 조건을 통과합니다. 에이전트는 후보 목록에 포함시켜요. 차이는 숙소 자체에 있지 않아요. 숙소를 설명하는 데이터에 있습니다.
구현 가이드: MapAtlas GeoEnrich API로 숙소 강화하기
에이전트에게 보이지 않는 listing과 보이는 listing의 차이는 데이터 강화 단계예요. MapAtlas GeoEnrich API는 단 하나의 입력(숙소의 지리 좌표)에서 완전한 위치 속성 레이어를 생성합니다.
1단계: 숙소 지오코딩
데이터베이스에 주소는 있지만 좌표가 없다면, 지오코딩부터 시작하세요. MapAtlas Geocoding API는 주소를 정밀한 위도/경도 쌍으로 변환해요. 호텔 포트폴리오의 경우, 배치 지오코딩으로 단일 API 호출에서 수천 개의 숙소를 처리할 수 있습니다.
curl -X POST https://api.mapatlas.com/v1/geocode \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{"address": "Passeig de Joan de Borbó 64, Barcelona, Spain"}'
2단계: 위치 속성으로 강화
좌표를 GeoEnrich API에 전달하세요. 단일 호출로 교통 접근성, 카테고리별 인근 POI, 도보 가능 지표, 동네 분류가 반환됩니다.
curl -X POST https://api.mapatlas.com/v1/geoenrich \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{"lat": 41.3758, "lng": 2.1894, "radius": 1000, "categories": ["transit", "dining", "grocery", "attractions", "parking"]}'
응답에는 Schema.org JSON-LD, OTA 엑스트라넷 설명, 숙소 관리 시스템 데이터 필드에 직접 삽입할 수 있는 구조화된 데이터가 포함됩니다.
3단계: 구조화된 데이터에 삽입
강화된 위치 속성을 숙소의 JSON-LD 마크업에 추가하세요. OTA에 등록된 숙소의 경우, 구체적인 거리와 POI 이름을 OTA 플랫폼이 제공하는 구조화된 필드에 통합하세요.
4단계: 구체적인 데이터로 OTA 설명 업데이트
OTA 설명의 일반적인 위치 언어를 강화 응답의 구체적인 데이터 포인트로 교체하세요. "해변 근처 좋은 위치"가 "Barceloneta 해변에서 150미터, La Barceloneta 지하철(L4)에서 200미터, 도보 5분 내 레스토랑 47개"가 됩니다.
포트폴리오 전체로 확장
수백, 수천 개의 숙소를 운영하는 호텔 체인, 관리 회사, 호스피탈리티 플랫폼의 경우 GeoEnrich API가 배치 강화를 처리해요. 숙소 좌표의 CSV를 전달하면 모든 숙소의 완전한 위치 속성 세트가 반환됩니다. 숙소 관리 시스템이나 배포 파이프라인에 직접 통합하기 적합한 형식으로요.
에이전트 기반 검색에서 가시성 모니터링
데이터 강화는 1단계예요. 에이전트가 실제로 숙소를 추천하는지 모니터링하는 것이 2단계입니다.
에이전트를 직접 테스트하세요. Google AI Mode와 Perplexity에서 숙소 프로필에 맞는 예약 쿼리를 실행해 보세요. "[내 도시]에서 [가장 가까운 랜드마크] 근처, [주요 시설] 있는 4성급 호텔." 숙소가 나타나지 않으면 데이터 격차가 여전히 존재하는 거예요.
MapAtlas AEO Checker를 사용하세요. mapatlas.eu/aeo-checker의 무료 AEO Checker는 AI 에이전트가 사용하는 기준에 대해 숙소의 구조화된 데이터를 평가해요. 어떤 위치 속성이 있고, 어떤 것이 없으며, 어떤 것이 에이전트가 파싱할 수 없는 형식인지 식별합니다.
에이전트 추천 트래픽을 추적하세요. 애널리틱스에서 AI 관련 리퍼러의 트래픽을 세분화하세요: Google AI Mode 추천, Perplexity 추천, ChatGPT 추천. 이것들은 숙소가 에이전트 고려 세트에 들어가고 있는지의 초기 지표예요.
예약 소스 분포를 모니터링하세요. 에이전트형 예약이 성장하면서, 에이전트 중개 검색에서 발생하는 예약 비율이 증가할 거예요. 에이전트에게 보이는 숙소는 예약 소스 믹스에서 이를 확인할 수 있어요. 그렇지 않은 숙소는 여행자들이 에이전트 지원 예약으로 전환하면서 오가닉 발견이 점진적으로 감소하는 것을 보게 됩니다.
기회의 창
에이전트형 예약 전환은 초기 단계예요. Google AI Mode는 점진적으로 출시되고 있어요. Perplexity의 여행 에이전트는 사용자를 얻고 있지만 아직 주류 채택에는 도달하지 못했습니다. 대부분의 호텔 운영자들은 에이전트형 예약을 들어본 적도 없고, 당연히 최적화도 하지 않았어요.
이게 바로 기회의 창입니다. 지금 위치 데이터를 강화하는 숙소는 경쟁이 가장 낮은 기간에 에이전트 추천 이력을 쌓을 거예요. 2015년 Google Hotel Ads, 2010년 OTA SEO, 2017년 모바일 예약 최적화에서도 같은 다이내믹이 펼쳐졌습니다. 새로운 평가 기준을 이해한 얼리 어답터들은 늦은 채택자들이 따라잡는 데 수년이 걸리는 이점을 확보했어요.
에이전트는 지금 이 순간 여러분 숙소를 평가하고 있어요. 교통 데이터, 도보 접근성 맥락, 여행자가 요청한 명소와의 근접성을 확인하고 있습니다. 그 데이터 필드들이 비어 있으면, 에이전트는 밀리초 만에 다음으로 넘어가요.
질문은 에이전트형 예약이 숙소에 영향을 미칠지가 아니에요. 질문은 그것이 일어났을 때 위치 데이터가 준비되어 있을지입니다.
관련 글:
자주 묻는 질문
AI 예약 에이전트가 뭐고, 호텔에 어떤 영향을 주나요?
AI 예약 에이전트는 Google AI Mode, Perplexity 같은 플랫폼에 내장된 자율 시스템이에요. 사용자가 예약 페이지를 한 번도 방문하지 않아도 호텔을 검색하고, 평가하고, 예약까지 완료할 수 있습니다. 구조화된 데이터, 위치 속성, 리뷰 신호를 기반으로 숙소를 프로그래밍 방식으로 평가해요. 기계가 읽을 수 있는 지리 데이터가 없는 숙소는 여행자가 결과를 보기도 전에 필터링됩니다.
2026년에 AI 호텔 예약 에이전트를 출시한 플랫폼은 어디인가요?
Google AI Mode가 Booking.com, Expedia, Marriott, IHG, Wyndham 같은 대형 체인과 연동된 에이전트형 호텔 예약을 출시했어요. Perplexity는 2026년 초에 여행 예약 에이전트를 내놨습니다. Booking.com의 AI Trip Planner와 Expedia의 Romie 에이전트도 각자 플랫폼 내에서 자율적으로 동작합니다.
AI 예약 에이전트가 호텔을 추천하려면 어떤 위치 데이터가 필요한가요?
AI 예약 에이전트는 여섯 가지 핵심 위치 속성을 평가해요: 대중교통 접근성(지하철, 버스, 공항 셔틀까지 거리), 도보 맥락(걸어갈 수 있는 레스토랑, 상점, 서비스), 주차 가능 여부와 유형, 주요 관광지와의 거리, 동네 안전성과 특성 신호, 그리고 검증된 지리 좌표입니다. 이 중 하나라도 없으면 에이전트 추천에서 제외될 수 있어요.
호텔이 AI 예약 에이전트에 보이려면 어떻게 해야 하나요?
호텔은 기계가 읽을 수 있는 위치 속성으로 listing 데이터를 보강해야 합니다: 정밀한 좌표, 거리가 포함된 인근 POI 구조화 목록, 교통 접근 세부 사항, 도보 점수, 주차 정보 등이요. MapAtlas GeoEnrich API는 좌표 한 쌍만으로 이 모든 속성을 생성해서, Schema.org JSON-LD에 바로 삽입하거나 OTA 플랫폼에 배포할 수 있는 형식으로 제공합니다.
현재 AI 예약 에이전트에 보이는 호텔 비율은 얼마나 되나요?
주요 예약 플랫폼의 구조화 데이터 감사 결과, 호텔의 약 80%가 AI 예약 에이전트가 신뢰할 만한 추천을 하기 위해 필요한 기계 가독성 위치 속성을 갖추지 못하고 있어요. 이 숙소들은 기본 listing 데이터(이름, 주소, 사진, 가격)는 있지만, 에이전트가 위치 기반 쿼리에 쓰는 교통, 도보, 근접성 구조화 데이터가 없습니다.
