와일드베리와 오존의 파싱 트래픽 제한: 하룻밤 사이에 월간 프록시 패키지를 낭비하지 않는 방법

판매자가 경쟁자의 가격 파서를 밤새 실행하고 아침에 알림을 받습니다: 트래픽이 소진되었고, 패키지가 90% 소진되었습니다. 익숙한 상황인가요? 대부분의 경우 문제는 파서 자체가 아니라 프록시 및 스크립트 수준에서 한도가 없기 때문입니다. 이 기사에서는 트래픽이 어떻게 "유출"되는지와 월간 레지던트 또는 모바일 프록시 패키지가 계산된 기간 동안 충분히 유지되도록 보호 장치를 설정하는 방법을 살펴보겠습니다.

트래픽이 하룻밤에 소진되는 이유

Wildberries, Ozon 또는 Avito의 파싱은 간단한 작업처럼 보입니다: 요청을 보내면 가격이 포함된 JSON을 받습니다. 그러나 실제로는 유용한 데이터 외에도 트래픽이 소모됩니다. 주요 과소비 원인은 다음과 같습니다:

• 이미지 및 미디어 로드. 파서가 브라우저를 통해 상품 페이지를 전체적으로 열면 (API에 직접 요청하지 않고) 자동으로 이미지, 비디오, 배너를 로드하게 되며, 이는 한 카드당 수십 메가바이트가 됩니다.
• 캡차 및 차단으로 인한 반복 요청. 마켓플레이스가 봇을 인식하면 캡차를 표시하거나 IP에 대한 임시 차단을 하며, 스크립트가 반복 요청을 하게 되어 트래픽이 낭비되고 데이터는 오지 않습니다.
• 요청 캐싱 부족. "이미 이 시간에 파싱됨 - 반복하지 않음"이라는 로직이 없으면 스크립트는 같은 카드를 밤새 여러 번 요청할 수 있습니다.
• 제한 없는 병렬 스트림. 50-100개의 스트림을 동시에 실행하면 작업 속도가 빨라지는 것처럼 보이지만, 이로 인해 트래픽이 계획보다 훨씬 더 빨리 소모되며 일부 요청이 차단됩니다.
• 프록시 유형의 잘못된 선택. 레지던트 및 모바일 프록시는 일반적으로 트래픽 양에 따라 요금이 부과되며 (GB), 데이터 센터 프록시는 IP 수나 임대 시간에 따라 요금이 부과됩니다. 프록시 풀에 대한 제어 없이 레지던트 프록시가 설정되면 한도가 빠르게 소진됩니다.

이러한 요인의 조합으로 인해 한 달 작업을 위해 설계된 스크립트가 10-20,000개의 상품 카드를 파싱하는 한 번의 야간 세션에서 트래픽 패키지를 소진하게 됩니다.

다양한 유형의 프록시에서 트래픽 계산 방법

한도를 설정하기 전에, 무엇에 대해 비용을 지불하는지 이해하는 것이 중요합니다. 다양한 유형의 프록시는 소비를 다르게 계산하며, 이는 절약 전략에 직접적인 영향을 미칩니다.

프록시 유형	요금 부과 방식	과소비 위험	언제 적용할지
레지던트 프록시	트래픽 양에 따라 (GB)	제한이 없을 경우 높음	마켓플레이스의 안티봇 보호를 우회하는 파싱
모바일 프록시	트래픽 양 또는 시간에 따라	높음, 트래픽이 더 비쌈	모바일 버전 웹사이트 파싱, 강력한 차단 우회
데이터 센터 프록시	IP 수 / 임대 시간에 따라	낮음, 트래픽은 일반적으로 무제한	엄격한 안티봇 보호가 없는 대량 파싱

Wildberries 또는 Ozon을 파싱하는 경우, 봇 보호가 적극적으로 작동하므로 레지던트 또는 모바일 IP가 거의 항상 필요합니다. 데이터 센터 주소는 빠르게 차단됩니다. 그러나 트래픽 요금 부과 방식 때문에 여기서는 미리 한도를 설정하는 것이 특히 중요합니다.

파싱에 실제로 필요한 트래픽 양

적절한 한도를 설정하기 위해서는 실제 숫자를 기준으로 삼아야 하며, 감에 의존해서는 안 됩니다. 실제 비용 예시는 다음과 같습니다:

• 상품 카드 API 요청 (JSON, 이미지 없음): 카드당 5-30 KB. 10,000개의 카드에 대해 약 50-300 MB.
• 이미지가 포함된 헤드리스 브라우저를 통한 상품 페이지 로드: 카드당 1-3 MB. 같은 10,000개의 카드에 대해 10-30 GB.
• 1000 SKU에 대한 시간당 가격 모니터링: 간소화된 요청의 경우 하루 약 1-5 GB, 전체 페이지 로드 시 하루 50-100 GB.

"가벼운" 파싱과 "무거운" 파싱 간의 차이는 수십 배입니다. 따라서 트래픽 절약의 첫 번째 단계는 가능한 경우 이미지, 비디오 및 외부 스크립트 로드를 비활성화하고, 마켓플레이스 API 또는 데스크톱 버전보다 용량이 적은 모바일 버전 웹사이트와 직접 작업하는 것입니다.

안티탐지 브라우저 및 프록시 관리자에서의 한도 설정

안티탐지 브라우저(예: Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) 또는 자체 프록시 관리자를 통해 파싱하는 경우, 소비를 제한하는 가장 간단한 방법은 프록시 공급자의 프로필 및 계정 수준에서 한도를 설정하는 것입니다.

1. 프록시 공급자의 개인 계정에 로그인하고 서브 사용자/포트에 대한 트래픽 또는 한도 관리 섹션을 찾습니다.
2. 파싱을 위한 별도의 서브 계정 또는 포트를 생성합니다 — Instagram 또는 TikTok의 계정 농사와 같은 동일한 프록시 풀을 사용하지 마십시오. 작업별로 분리하면 트래픽이 어디로 가는지 즉시 확인할 수 있습니다.
3. 이 서브 계정에 대한 일일 또는 시간당 트래픽 한도를 설정합니다 — 예를 들어, 한 세션에서 전체 월간 패키지를 소진하는 대신 하루에 5 GB로 설정합니다.
4. 안티탐지 브라우저에서 이미지 자동 로드를 비활성화합니다 데이터 수집을 위해 사용되는 프로필에 대해 페이지를 시각적으로 보는 것이 아니라.
5. 프로필 실행 일정을 설정합니다 파싱이 긴 세션이 아니라 짧은 간격으로 진행되도록 하여 차단 위험을 줄이고 실행 간 트래픽 소비를 추적할 시간을 제공합니다.

이러한 접근 방식은 여러 마켓플레이스를 동시에 파싱하는 에이전시 및 프리랜서에게 특히 중요합니다. 서브 계정으로 분리하지 않으면 어떤 프로젝트가 트래픽을 "소비"했는지 이해하기 어렵습니다.

스크립트 및 API 수준에서의 트래픽 제한

파서가 Python 또는 Node.js로 직접 작성된 경우, 한도를 코드에 직접 통합할 수 있으며, 이는 프록시 공급자 인터페이스 설정보다 더 정확한 제어를 제공합니다.

requests를 사용한 Python의 간단한 트래픽 카운터 예시:

import requests

MAX_BYTES_PER_DAY = 5 * 1024 * 1024 * 1024  # 하루 5 GB 한도
used_bytes = 0

proxies = {
    "http": "http://user:pass@proxy_host:port",
    "https": "http://user:pass@proxy_host:port",
}

def safe_get(url):
    global used_bytes
    if used_bytes >= MAX_BYTES_PER_DAY:
        raise RuntimeError("일일 트래픽 한도가 소진되었습니다, 파싱이 중단되었습니다.")

    response = requests.get(url, proxies=proxies, timeout=10)
    used_bytes += len(response.content)
    return response

# 호출 예시
resp = safe_get("https://card.wb.ru/cards/detail?nm=123456")
print("사용된 트래픽:", round(used_bytes / 1024 / 1024, 2), "MB")

로직은 간단합니다: 스크립트는 각 응답의 바이트 양을 계산하고 설정된 한도에 도달하면 중단됩니다. 이는 루프 오류나 무한 요청 반복으로 인해 스크립트가 몇 시간 만에 월간 트래픽 패키지를 "소비"하는 상황을 방지합니다.

추가로 다음을 추가하는 것이 좋습니다:

• 오류 발생 시 지수 지연 (retry with backoff) — 캡차나 차단 시 즉시 요청을 반복하는 대신, 스크립트는 증가하는 간격(5초, 15초, 60초)을 기다리며, 이는 불필요한 요청 수를 줄입니다.
• 병렬 스트림 수 제한 — 예를 들어, 프록시 풀을 통해 동시에 10-20개의 연결을 초과하지 않도록 하여 차단을 유발하지 않고 트래픽을 낭비하지 않도록 합니다.
• 헤드리스 브라우저에서 리소스 로드 비활성화 — Selenium 또는 Puppeteer를 통해 파싱하는 경우, 브라우저 설정에서 이미지, 글꼴 및 CSS의 로드를 차단하고 HTML/JSON 응답만 남기는 것이 가능합니다.

실시간 소비 모니터링

모니터링 없는 한도는 더 잘 작동하지 않으며, 문제를 스크립트가 중단된 후에야 알게 됩니다. 소비를 실시간으로 제어하기 위해:

• 프록시 공급자의 개인 계정에서 월간 트래픽 패키지의 50%, 80% 및 100% 도달 시 알림을 활성화합니다 — 대부분의 서비스는 이메일 또는 Telegram을 통한 이러한 알림을 지원합니다.
• 스크립트 내에서 간단한 로그를 유지합니다: 파일이나 데이터베이스에 시간별 트래픽 양을 기록하여 소비 피크를 확인하고 문제의 출처를 빠르게 찾습니다.
• 작업별로 트래픽을 분리하여 별도의 서브 계정 또는 태그를 사용합니다 — Wildberries 파싱용, Ozon용, Avito용으로 각각. 이는 어떤 프로젝트가 가장 많은 소비를 하는지 분석하는 데 용이합니다.
• 소비를 예상 데이터 양과 비교합니다: 10,000개의 카드에 20 GB가 소모되었다면, 예상 300 MB 대신 불필요한 리소스가 로드되거나 반복 요청이 발생하고 있다는 의미입니다.

트래픽 예산 관리 체크리스트

초보자의 흔한 실수

실제로 대부분의 "소진된" 트래픽 패키지는 몇 가지 전형적인 실수로 설명됩니다:

• 한도 없이 "감시 없이 밤새 파싱" 실행. 스크립트가 8-10시간 동안 중단 없이 작동하며, 어딘가에서 반복 요청 루프가 발생하면 트래픽이 아침까지 연속적으로 소모됩니다.
• 모든 작업에 대한 하나의 공용 프록시 풀. Instagram의 계정 농사, Facebook Ads에서의 광고 테스트 및 Ozon 파싱이 동일한 트래픽을 사용하므로 무엇이 소모되고 있는지 이해할 수 없습니다.
• 캡차 무시. 캡차의 첫 징후가 나타날 때 요청 빈도를 줄이는 대신, 스크립트는 동일한 강도로 사이트를 계속 요청하여 오류 코드가 포함된 무의미한 응답에 트래픽을 소모합니다.
• 데이터 센터 프록시로 충분한 곳에서 레지던트 프록시 선택. 마켓플레이스가 데이터 센터 IP를 강하게 차단하지 않는 경우, 레지던트 풀의 트래픽에 대한 추가 비용은 정당화되지 않습니다 — 덜 보호된 목적에는 데이터 센터 프록시가 다른 요금 모델로 적합합니다.
• 테스트 실행 부족. 수천 개의 카드에 대한 전체 파싱을 시작하기 전에, 50-100개의 카드에서 스크립트를 실행하고 실제 트래픽 소비를 측정하여 전체 양에 대해 추정해야 합니다.

결론

파싱을 위한 트래픽은 데이터 양이 아니라 제어 부족으로 "소진"됩니다: 불필요한 이미지, 차단 시 반복 요청, 제한 없는 병렬 스트림 및 모든 작업에 대한 공용 프록시 풀. 해결책은 프로젝트별로 트래픽을 분리하고, 프록시 계정 수준에서 일일 한도를 설정하며, 스크립트에 소비 카운터를 통합하고, 패키지가 실제로 소진되기 전에 알림과 함께 모니터링을 설정하는 것입니다.

Wildberries 또는 Ozon과 같은 봇 보호가 활성화된 마켓플레이스를 파싱하는 경우, 차단을 우회하기 위해 레지던트 프록시를 사용하는 것이 좋으며, 가장 민감한 안티봇 보호 시나리오에는 모바일 IP를 추가로 사용하십시오 — 그러나 두 경우 모두 월간 패키지가 한 번의 야간 세션에서 소진되지 않도록 미리 트래픽 한도를 설정하는 것이 필수적입니다.