여행은 정확하게 수집하기가 가장 어려운 가격 정보 분야이며, 그 차이는 크다. 소매 상품 페이지의 가격은 어느 정도 사실에 가깝다. 특정 시장 내에서는 누구에게나 동일하며 변화도 느리다. 항공권 요금은 이와 다르다. 같은 항공편의 같은 좌석이라도 어디서 검색하는지, 어떤 화폐를 사용하는지, 이전에 검색한 적이 있는지, 그리고 항공사의 수익 관리 시스템이 몇 분 전에 무엇을 결정했는지에 따라 다른 가격이 제시될 수 있다. 호텔 요금도 비슷하게 작동한다.
요금 집계 또는 여행 인텔리전스 팀에게는 이것이 한 문장으로 요약되는 문제다: 여행자가 보는 요금은 제공업체가 그 사람을 누구로, 어디에 있다고 판단하는지에 따라 달라진다. 단일 사무실 IP로 이 데이터를 수집하면 단지 불완전한 그림을 얻는 것이 아니라 잘못된 요금을 얻게 된다. 즉, 실제로 있지 않은 시장을 대상으로 제시된 요금을 수집하게 되는 것이다. 이 글은 여행 요금 집계에 프록시가 필요한 이유에서 다룬 내용을 더 깊이 다루며, 항공 및 호텔 데이터에 레지덴셜 프록시가 올바른 접근 계층인 이유가 되는 메커니즘에 초점을 맞춘다.
무엇을 수집하는가
여행 데이터 수집은 서로 연관된 몇 가지 영역에 걸쳐 있다:
- 항공 요금 — 노선, 날짜, 좌석 등급, 요금 클래스별 가격, 그리고 항공사와 이를 재판매하는 OTA 및 메타서치 엔진 전반에 걸친 이용 가능 여부, 요금 규정, 부가서비스(수하물, 좌석).
- 호텔 요금 — 숙소, 날짜, 객실 유형, 인원수별 1박 요금, 그리고 이용 가능 여부 및 취소 조건.
- 렌터카 및 패키지 — 위치와 날짜별로 가격이 책정되는 동일한 형태.
이들 모두의 공통점은 각각이 특정 시점에 특정 시장에 있는 특정 여행자에게 제시된다는 것이며, 이것이 바로 이것이 접근 문제인 이유다.
여행이 독특하게 프록시 문제인 이유
소매 스크래핑은 지리적 차원이 하나뿐이다. 여행은 서로 복합적으로 작용하는 네 가지 특성을 가지며, 이 네 가지 모두가 프록시 계층에 영향을 미친다.
1. 요금은 판매 시점(point-of-sale) 기준으로 가격이 책정된다. 이것이 결정적인 특징이다. 항공사와 OTA는 여행자가 예약하는 시장, 즉 판매 시점에 따라 동일한 여정에 다른 가격을 책정한다. 뉴욕에서 런던 왕복 항공권은 미국 판매 시점(POS)에서 예약할 때와 영국 또는 인도 판매 시점에서 예약할 때 다른 화폐로 다른 요금이 책정될 수 있다. 이것은 예외적인 경우가 아니라 이 비즈니스의 핵심이며, 시장 간 요금 비교가 존재하는 이유이기도 하다. 특정 시장의 여행자가 실제로 보는 요금을 파악하려면 그 시장에 있는 것처럼 보여야 하며, 이는 그 지역의 레지덴셜 IP가 필요하다는 뜻이다(국가 및 도시 타겟팅).
2. 요금은 세션 기반이다. 요금 검색은 단일 요청이 아니라 하나의 흐름이다: 검색, 결과, 여정 선택, 가격 확인. 제공업체는 이 세션 내에서 가격을 제시하고 유지하며, 흐름 중간에 신원이 바뀌면 실제 여행자처럼 보이지 않는다. 이것이 다른 분야에서는 단순히 편리한 수준인 지속 세션이 여행에서는 선택 사항이 아닌 이유다(고정 세션과 로테이팅의 차이): 전체 요금 흐름이 하나의 일관된 신원에서 나와야 한다.
3. 요금은 소멸성이 있다. 수익 관리 시스템은 끊임없이 가격을 재조정하며 이용 가능 여부는 실시간이므로, 한 시간 전에 수집한 요금은 이미 잘못된 것일 수 있다. 신선도는 필수 요건이며, 이는 주기적인 수집이 아니라 지속적이고 대량의 수집이 필요하다는 뜻이다.
4. 여행 업계는 적극적으로 방어한다. 항공사는 “검색 대 예약” 비율, 즉 실제 예약당 검색 횟수를 감시하며, 전환되지 않는 대량 검색 트래픽을 비용이자 위협으로 간주한다. GDS 시스템, OTA, 메타서치 엔진은 모두 강력한 봇 방지 체계를 운영한다. 데이터센터 IP는 빠르게 탐지되어 CAPTCHA, 차단, 혹은 최악의 경우 다른 요금을 받게 되어 실제 여행자라면 결코 제시받지 않을 가격을 기록하게 된다(스크래퍼가 차단되는 이유).
종합하면: 여행 데이터를 정확하게 수집하려면 올바른 시장에서, 일관된 세션을 유지하며, 대규모로, 지속적으로, 실제 여행자처럼 보여야 한다. 이것이 바로 레지덴셜 프록시가 필요한 문제다.
레지덴셜 프록시가 적합한 이유
레지덴셜 프록시는 요청을 실제 소비자 IP를 통해 라우팅하므로, 여행 제공업체는 실제 현지 여행자에게 하듯 요금을 제시한다. 구체적으로:
실제 판매 시점 요금. 필요한 국가로 지오 타겟팅을 하면, 실제로 그 판매 시점(POS)에서 예약하는 여행자로서 요금을 수집할 수 있다. 미국 요금은 미국에서, 독일 요금은 독일에서, 각각 시장별로 표시된다. 이렇게 하면 시장 간 비교가 마침내 하나의 위치에서 추정한 값이 아니라 실제 POS별 가격에 기반하게 된다.
봇 버전이 아닌 실제 요금. 레지덴셜 IP는 실제 사용자 신뢰도를 갖고 있으므로, 의심스러운 트래픽에 제공되는 저품질, 차단, CAPTCHA 응답이 아니라 실제로 제시된 가격과 이용 가능 여부를 수집할 수 있다. “봇 요금”이 실제로 다른 숫자일 수 있는 여행 분야에서는 이것이 사용 가능한 데이터와 잡음의 차이를 만든다.
세션 일관성을 유지한 수집. 요금 흐름의 전 과정 동안 고정 세션을 유지하여 검색, 선택, 가격 확인이 모두 하나의 신원에서 이루어지도록 한다. 이는 제공업체가 기대하는 방식이자 제시된 가격을 일관되게 유지하는 방법이기도 하다. 검색 간에는 새로운 신원으로 로테이션하고, 하나의 검색 흐름 내에서는 로테이션하지 않는다.
완전하고 신선한 커버리지. 대규모 로테이팅 풀을 사용하면 소수의 IP가 속도 제한에 걸리지 않으면서 여러 노선, 날짜, 시장을 지속적으로 처리할 수 있으며, 이것이 소멸성이 있는 요금 데이터를 오래되지 않게 유지하는 방법이다(데이터 수집 품질에 대한 원칙은 데이터 수집을 위한 레지덴셜 프록시와 동일하다).
작동 방식
Shifter 게이트웨이에서는 프록시 사용자명에 국가를 인코딩하여 판매 시점을 타겟팅하며, 하나의 엔드포인트로 IP 목록이 필요 없다:
# 미국에서 예약하는 여행자로서 요금 수집curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://fare-source.example
# 동일한 노선, 영국 판매 시점에서 가격 책정curl -x customer-USERNAME-country-gb:PASSWORD@p.shifter.io:443 https://fare-source.example메커니즘보다 더 중요한 두 가지 여행 특화 실무 지침이 있다. 첫째, 지역 설정과 화폐를 판매 시점에 맞춰라. 영국 POS 요청이 미국 지역 설정을 보내거나 USD를 요청하면 이는 불일치를 일으켜 잘못되거나 차단된 결과를 낳는다. Accept-Language와 사이트의 화폐 선택을 해당 시장에 맞춰야 한다. 둘째, 요금 흐름 전체에서 고정 세션을 유지하라. 사용자명에 -sid-<id>-ttl-<seconds>를 추가하여 다단계 검색이 하나의 IP에서 유지되도록 한다. 간헐적이 아닌 지속적인 차단은 IP 품질이나 요청 행동을 가리키며, 이는 차단을 피하는 방법에서 다루고 있으며, 풀 품질이 제시되는 요금에 영향을 미친다(IP 신뢰도).
우선 승인된 소스를 고려하고, 책임감 있게 수집하라
여행 분야에서 특히 강조할 두 가지가 있다.
적합한 경우 공식 채널을 사용하라. 많은 항공사, 호텔 체인, OTA가 API, 제휴 피드, 또는 GDS 접근을 제공한다. 승인된 피드가 필요를 충족하는 경우, 이것이 더 나은 첫 번째 선택이다. 안정적이고 구조화되어 있으며 허용된 방식이다. 프록시는 이러한 채널 밖의 공개 요금 데이터, 또는 단일 피드로는 얻을 수 없는 여러 시장과 제공업체에 걸친 폭넓은 수집을 위한 것이다. 적합한 경우 API부터 시작하는 것이 단순히 더 나은 방식이다.
검색 대 예약 비율에 주의하라. 여행 제공업체는 각 검색이 실질적인 비용을 유발하기 때문에 전환되지 않는 검색량에 유난히 민감하다. 합리적인 속도로 수집하고, 제공업체에 과도한 부담을 주지 말고, 약관과 속도 제한을 준수하며, 인증이 필요한 부분이 아닌 공개 요금 데이터를 수집하라. 이는 모범적인 태도이자 자기 보호이기도 하다. 공격적인 수집은 소스가 방어 체계를 강화하도록 만드는 정확한 원인이다. 개인 데이터는 완전히 피하고, 불확실한 사항에 대해서는 법률 자문을 받아라(웹 스크래핑은 합법인가). 프록시는 요청이 어느 IP에서 오는지를 바꿀 뿐, 그 요청을 해야 하는지 여부를 바꾸지는 않는다. Shifter에서 허용되는 사항에 대한 최종 기준은 사용 정책이다.
FAQ
항공 및 호텔 데이터에 왜 프록시가 필요한가? 요금이 판매 시점 기준으로 책정되기 때문이다. 동일한 여정이라도 예약하는 시장에 따라 다른 금액이 책정되며, 제공업체는 자동화된 접근을 강하게 방어한다. 한 위치에서만 접근하면 한 시장의 요금, 종종 봇 버전만 보게 된다. 레지덴셜 프록시를 사용하면 각 시장의 여행자가 실제로 제시받는 요금을 수집할 수 있다.
판매 시점 가격 책정이란 무엇인가? 항공사와 OTA는 여행자가 예약하는 시장, 즉 판매 시점에 따라 동일한 항공편에 다른 가격을 책정한다. 이것이 같은 좌석이 미국과 영국에서 (그리고 다른 화폐로) 다른 금액이 될 수 있는 이유이며, 정확한 요금 데이터는 시장별로 수집되어야 하는 이유다.
여행 데이터에 고정 세션이 필요한가? 대부분의 경우 그렇다. 요금 검색은 다단계 흐름(검색, 선택, 가격 확인)이며 제공업체는 세션 내에서 가격을 제시하므로, 흐름은 하나의 일관된 IP에서 이루어져야 한다. 흐름 동안 고정 세션을 사용하고, 검색 간에는 로테이션하되 하나의 검색 내에서는 로테이션하지 마라.
항공사나 OTA API를 대신 사용해야 하는가? 승인된 API, 제휴 피드, 또는 GDS 접근이 필요를 충족한다면 그렇다. 안정적이고 허용된 방식이다. 프록시는 이러한 채널 밖의 공개 요금 데이터나 단일 피드로는 제공되지 않는 시장 간 폭넓은 수집을 위한 것이다. 적합한 경우 API부터 시작하라.
여행 요금에는 레지덴셜 프록시와 데이터센터 프록시 중 무엇을 사용해야 하는가? 레지덴셜이다. 여행 제공업체는 데이터센터 IP를 적극적으로 탐지하고 차단하며 다른 요금을 제공할 수 있으므로, 데이터센터를 사용하면 잘못되거나 차단된 결과를 얻게 된다. 레지덴셜 IP는 실제 여행자가 보게 될 정확한 판매 시점 요금을 볼 수 있다.
결론
여행 요금 데이터는 판매 시점 기준으로 가격이 책정되고, 세션 기반이며, 소멸성이 있고, 강하게 방어되는 특성을 동시에 지니고 있어 독특하게 어렵다. 요금 집계 제품의 정확도는 각 시장의 요금을 그 시장에서 예약하는 실제 여행자처럼 수집하고, 일관된 세션을 유지하며, 데이터가 요구하는 신선도로 수집하는 데 전적으로 달려 있다. 적합한 경우 승인된 피드를 사용하고, 나머지는 판매 시점에 맞춘 레지덴셜 IP를 통해 라우팅하며, 지역 설정과 화폐를 맞추고 각 요금 흐름 전체에서 고정 세션을 유지하라.
이를 제대로 하면 실제 예약을 반영하지 않는 혼합된 숫자가 아니라, 시장별로 여행자가 실제로 제시받는 요금을 얻을 수 있다. 양질의 레지덴셜 프록시 네트워크가 이러한 수집을 판매 시점 기준으로 정확하고 완전하게 만들어주며, 가격 페이지에서 제품이 의존하는 노선, 숙소, 시장을 대상으로 시험해볼 수 있는 GB당 요금제를 확인할 수 있다.