Pricing

여행 및 SaaS를 위한 지역 간 가격 모니터링

5 min read Published Updated 896 words

파리의 한 호텔 객실이 Booking.com에 프랑스 IP에서 €200로 표시되지만, 동일한 브라우저가 미국 IP에서 동일한 URL에 접속하면 €260입니다. 이는 통화 변환의 부산물이 아니라 지리적 위치에 기반한 의도적인 동적 가격 책정입니다. SaaS의 경우 Slack이나 Jira의 동일한 시트가 미국과 인도 간에 40%까지 차이가 날 수 있습니다. 이러한 가격 차이를 대규모로 모니터링하려면 항공사와 클라우드 벤더가 스크래퍼에 대해 배포하는 것과 동일한 안티-사기 시스템을 견딜 수 있는 프록시 인프라가 필요합니다.

동일한 SKU가 국가별로 다른 가격을 가지는 이유

지리적 차익 거래 가격 책정을 주도하는 세 가지 메커니즘이 있습니다. 첫째, 숨겨진 마크업이 포함된 통화 변환 — 호텔 예약 엔진은 국가별로 다른 3-5%의 외환 스프레드를 적용합니다. 둘째, 지역 세금 체계: EU의 VAT, 인도의 GST, 미국의 판매세. 셋째, 가장 공격적인 것은 수요 기반 동적 가격 책정입니다. British Airways의 런던-뉴욕 항공편은 요청이 독일 IP보다 영국 IP에서 발생할 때 더 높은 가격을 보여줍니다. 알고리즘이 영국 여행객이 더 높은 지불 의사가 있다고 가정하기 때문입니다. Atlassian 및 Salesforce와 같은 SaaS 벤더는 지역별로 별도의 가격표를 유지하며, 종종 신흥 시장에 대해 30-50% 할인을 제공합니다. 이러한 가격을 프로그래밍 방식으로 캡처하는 유일한 방법은 요청이 각 대상 시장에서 오는 것처럼 보이게 하는 것입니다.

다중 지역 가격 캡처를 위한 프록시 아키텍처

단일 리지덴셜 프록시 풀만으로는 충분하지 않습니다. 국가, 도시, 때로는 통신사(예: 프랑스 모바일 ISP 대 프랑스 리지덴셜 DSL)까지 일치하는 출구 노드 풀이 필요합니다. 표준 접근 방식은 인증된 프록시의 순환 목록을 유지하는 프록시 브로커를 사용하는 것입니다. 아래는 curl 명령어로, 프랑스 프록시에서 호텔 가격을 가져오고 Accept-Language 헤더를 fr-FR로 설정하며 최신 Chrome 빌드의 실제 User-Agent를 전송하는 최소한의 예시입니다:

curl -s -x "http://user:pass@fr-proxy.example.com:3128" \
  -H "Accept-Language: fr-FR,fr;q=0.9" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36" \
  "https://www.booking.com/hotel/fr/paris-ritz.html" | grep -oP '"price":"[^"]+"'

이 단일 명령어는 프록시가 DataDome 또는 Akamai와 같은 봇 탐지 서비스에 알려진 경우 60-80%의 확률로 실패합니다. 실패율은 프록시 회전과 세션 지속성, 그리고 프록시의 실제 ISP와 일치하는 헤더 핑거프린팅을 결합할 때만 낮아집니다.

안티-사기 봇 탐지: 실제 병목 지점

여행 및 SaaS 플랫폼은 봇 탐지에 막대한 투자를 하고 있습니다. IP 평판뿐만 아니라 TLS 핸드셰이크 핑거프린트(JA3), HTTP/2 설정, 타이밍 지터, HTTP 헤더 순서까지 확인합니다. 한 검사를 통과한 프록시가 다른 검사에서는 실패할 수 있습니다. 예를 들어, 깨끗한 IP를 가진 데이터센터 프록시라도 알려진 스크래핑 도구와 일치하는 JA3 서명이 있으면 즉시 차단됩니다. 리지덴셜 프록시도 면역이 아닙니다. 많은 프록시가 감염된 장치에서 수집되어 블랙리스트에 등록됩니다. 가장 효과적인 전략은 대상 사이트의 탐지 스택에 대해 테스트한 전용 프록시 풀을 사용하는 것입니다. 이상적인 조건에서도 프록시당 10-20%의 성공률을 예상하세요. 즉, 5-10초마다 하나의 요청이라는 안정적인 스크래핑 속도를 유지하려면 대상 지역당 최소 5-10개의 프록시가 필요합니다.

여기서 트레이드오프가 발생합니다. 더 높은 프록시 품질(리지덴셜, 고정 IP, 높은 평판)은 데이터센터 프록시보다 10배 더 비싸지만 성공률은 두 배에 불과할 수 있습니다. 시간당 100개의 SKU를 10개 지역에서 모니터링하는 가격 모니터링 작업의 경우 월 프록시 비용이 $2,000를 초과할 수 있습니다. 대안인 무료 공용 프록시 사용은 시작조차 불가능합니다. 해당 IP는 모든 주요 안티-봇 서비스에 이미 플래그되어 있기 때문입니다. 무료 프록시에서의 단일 요청은 CAPTCHA 또는 403 응답을 유발합니다.

실용적인 워크플로우: 속도 제한, IP 쿨다운 및 오류 처리

스크래퍼는 프록시 IP별로 상태 머신을 구현해야 합니다. 성공적인 요청 후 프록시는 쿨다운 기간에 들어갑니다. 호텔 사이트의 경우 30초, SaaS 관리 패널의 경우 60초입니다. 실패(HTTP 403, 429 또는 CAPTCHA 페이지) 후에는 쿨다운이 5분으로 연장되고 프록시는 재평가를 위해 플래그됩니다. 모든 프록시에 걸쳐 초당 2회 요청과 같은 전역 제한을 적용하는 토큰 버킷 속도 제한기를 사용하세요. 다음 Python 스니펫(asyncioaiohttp 사용)은 핵심 루프를 보여줍니다:

import asyncio, aiohttp, random

PROXY_POOL = [{"url": "http://user:pass@fr1:3128", "cooldown_until": 0}]

async def fetch_price(session, proxy, url):
    now = asyncio.get_event_loop().time()
    if now < proxy["cooldown_until"]:
        await asyncio.sleep(proxy["cooldown_until"] - now)
    try:
        async with session.get(url, proxy=proxy["url"],
                               headers={"Accept-Language": "fr-FR"}) as resp:
            if resp.status == 200:
                proxy["cooldown_until"] = now + 30
                return await resp.text()
            else:
                proxy["cooldown_until"] = now + 300
                return None
    except Exception:
        proxy["cooldown_until"] = now + 300
        return None

동일한 프록시에서 연속 실패가 발생하면 지수 백오프를 추가하세요. 세 번의 오류 후에는 해당 IP를 24시간 동안 사용 중지합니다. 성공 응답과 총 시도 횟수의 비율을 모니터링하고, 특정 지역에서 20% 미만으로 떨어지면 해당 국가의 전체 프록시 풀을 교체합니다. 마지막으로, 모든 응답 헤더, 특히 Set-CookieX-Frame-Options을 기록하세요. 이는 사이트가 JavaScript 실행을 필요로 하는 봇 탐지 스크립트를 실행 중인지 여부를 알려주기 때문입니다. 클라이언트 측 렌더링에 의존하는 사이트의 경우 Playwright 또는 Puppeteer와 같은 헤드리스 브라우저로 전환해야 하며, 이는 지연 시간과 프록시 비용에 한 자릿수 증가를 추가합니다. 교차 지역 가격 모니터링은 주말 프로젝트가 아닙니다. 이는 움직이는 표적에 대해 지속적인 조정이 필요한 지속적인 엔지니어링 투자입니다.