GB당 레지덴셜 프록시 요금제에서는 대역폭이 구매 단위이므로, 올바른 요금제를 고르는 문제는 결국 한 가지 질문으로 귀결됩니다. 한 달에 실제로 몇 기가바이트를 사용할 것인가? 너무 낮게 추정하면 월 중간에 초과 사용이나 속도 제한에 부딕히고, 너무 높게 추정하면 결코 쓰지 않을 여유분에 과다 지불하게 됩니다. 좋은 소식은 대역폭은 추정 가능한 값이며, 알 수 없는 신비가 아니라는 점입니다. 하나의 공식, 현실적인 페이지별 크기, 그리고 5분간의 측정만 있으면 자신 있게 요금제를 정할 수 있습니다.
이 가이드는 프록시 사용을 계획하는 팀을 위한 것입니다. 단계별로 추정치를 구축하고, 실제 측정으로 이를 검증하며, 일반적인 워크로드에 대한 실제 예시를 함께 살펴보겠습니다.
공식
모든 것은 다음으로 귀결됩니다:
Monthly GB ≈ (requests per month × avg response size × overhead factor) / bytes per GB입력값은 네 가지이며, 그중 하나가 가장 큰 영향을 미칩니다. 영향력이 큰 순서대로 살펴보겠습니다.
1단계: 평균 응답 크기 (가장 큰 요인)
요청당 얼마나 많은 바이트가 돌아오는지가 추정의 성패를 가르는 요소이며, 어떤 방식으로 가져오는지에 따라 10배 이상 차이가 날 수 있습니다. 일반적인 범위는 다음과 같습니다:
| 가져오는 대상 | 요청당 일반적인 크기 |
|---|---|
| 가벼운 JSON API 응답 | 5 ~ 50 KB |
| HTML 페이지만 (자산 제외) | 100 ~ 500 KB |
| 헤드리스 브라우저에서 전체 페이지 (이미지, CSS, JS, 폰트 포함) | 1 ~ 5 MB 이상 |
청구 금액을 가장 크게 좌우하는 단일 요인은 전체 브라우저를 렌더링하는지, 아니면 HTML/JSON을 직접 가져오는지 여부입니다. 브라우저는 페이지의 모든 것을 다운로드하지만, 일반 HTTP 요청은 그중 일부만 가져옵니다. HTML이나 API에서 데이터를 얻을 수 있다면, 요청당 크기와 대역폭이 자릿수 단위로 줄어듭니다. (이것과 자산 차단이 프록시 대역폭 비용을 줄이는 방법의 핵심입니다.)
측정할 수 있다면 이 값을 추측하지 마십시오. 4단계를 참고하세요.
2단계: 월별 요청 수
이는 보통 페이지(또는 레코드) 수에 빈도를 곱한 값입니다:
requests per month = items × checks per day × 3010,000개 제품을 하루에 한 번 추적하는 가격 모니터는 10,000 × 1 × 30 = 300,000건의 월간 요청입니다. 일회성 데이터셋 구축은 빈도 배수 없이 총 페이지 수만 계산하면 됩니다. 페이지네이션도 포함해야 합니다. 각 “항목”이 결과 3페이지에 걸쳐 있다면 그에 맞게 곱해야 합니다.
3단계: 오버헤드 요인
실제 크롤링은 100% 효율적이지 않습니다. 재시도, 리디렉션, 실패한 시도는 모두 프록시를 거치며 모두 대역폭을 소비합니다. 차단되거나 시간 초과된 요청도 이미 바이트를 소비한 것입니다. 순수한 추정치에 오버헤드 요인을 추가하십시오:
- 쉽고 개방적인 대상: 약 1.1 (10% 오버헤드)
- 일반적인 사이트: 약 1.2 (20%)
- 방어가 강한 대상 (빈번한 차단/재시도): 약 1.3 이상
대상이 어려울수록 재시도가 늘어나고, 그만큼 요인이 높아집니다. 차단율을 줄이면 (더 나은 IP 품질, 적절한 속도 조절) 이 값을 직접 줄일 수 있습니다. 차단을 피하는 방법을 참고하세요.
4단계: 실제 페이지당 크기를 측정하라 (추측하지 마라)
신뢰할 수 있는 추정치에 이르는 가장 빠른 방법은 실제 대상을 대표하는 샘플을 프록시를 통해 가져와 바이트를 측정하는 것입니다. 바이트 단위 응답 크기는 len(response.content)입니다:
import os, requests, statistics
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"proxies = {"http": proxy_url, "https": proxy_url}
sample_urls = [ ... ] # 20-50 representative target URLssizes_kb = []for url in sample_urls: r = requests.get(url, proxies=proxies, timeout=30) sizes_kb.append(len(r.content) / 1024)
avg_kb = statistics.mean(sizes_kb)print(f"avg {avg_kb:.0f} KB/request (n={len(sizes_kb)})")실제 URL 20~50개에 대해 실행하면 추측이 아닌 근거 있는 평균 크기를 얻을 수 있습니다. 이는 실제로 프록시를 통과하는 압축된 바이트를 측정한다는 점에 유의하십시오(Accept-Encoding을 유지하십시오). 이것이 바로 청구 대상입니다. 전체 클라이언트 설정은 Python으로 레지덴셜 프록시 사용하기에 있습니다.
실제 계산 예시
Monthly GB = requests × avg_size × overhead / 1,000,000 (KB를 GB로, 십진 기준)을 사용합니다:
가격 모니터링, HTML만. 10,000개 제품, 매일, 페이지당 약 200 KB, 오버헤드 1.15.
300,000 × 200 KB × 1.15 = 69,000,000 KB ≈ 월 69 GB.
동일한 작업이지만 전체 브라우저 렌더링. 페이지당 200 KB 대신 약 2 MB.
300,000 × 2,000 KB × 1.15 = 690,000,000 KB ≈ 월 690 GB.
동일한 데이터에 대역폭은 10배, 이것이 필요하지 않을 때 렌더링을 하는 대가입니다(렌더링이 꼭 필요하다면 자산을 차단하는 방법은 Playwright 활용을 참고하세요).
검색/순위 모니터링, 가벼운 응답. 500개 쿼리, 하루 4회, 각 약 30 KB, 오버헤드 1.2.
500 × 4 × 30 × 30 KB × 1.2 = 2,160,000 KB ≈ 월 2.2 GB. 작고 저렴합니다.
일회성 데이터셋 구축. 2,000,000페이지, HTML 약 300 KB, 오버헤드 1.2.
2,000,000 × 300 KB × 1.2 = 720,000,000 KB ≈ 720 GB, 이는 월간이 아닌 일회성입니다.
패턴은 명확합니다. 응답 크기와 렌더링 선택이 지배적이며, 요청 수는 선형적으로 증가하고, 오버헤드는 완만한 배수 역할을 합니다.
추정치에서 요금제로
약간의 규율을 더해 수치를 요금제로 전환하십시오:
- 여유분을 추가하십시오. 요금제는 추정치에 20~30%를 더한 값으로 정하여, 월 내 성장과 추정 오차에 대비하십시오. 사이클 중간에 소진되는 것이 약간의 여유분보다 훨씬 큰 문제입니다.
- 초과 사용 조건을 확인하십시오. 제공업체가 초과 사용을 어떻게 처리하는지(GB당 추가 요금, 속도 제한, 강제 중단) 확인하여 바쁜 달에 예상치 못한 상황을 피하십시오.
- 매주 대조하십시오. 사이클 초반에 실제 사용량을 추정치와 비교하고 조정하십시오. 실제 사용량은 어떤 추측보다 빠르게 실제 페이지당 크기와 차단율을 알려줍니다.
- 더 사기 전에 수치를 줄이십시오. 가장 저렴한 기가바이트는 대개 쓰지 않은 기가바이트입니다. 렌더링을 건너뛰고, 자산을 차단하고, 변경되지 않은 페이지를 다시 가져오지 마십시오(프록시 대역폭 비용 절감). 요금제를 늘리기 전에 이를 먼저 시도하십시오. 이것이 효율성이 보상받는 GB당 모델입니다(포트당 시대는 끝났다).
FAQ
작업을 한 번도 실행해본 적이 없다면 대역폭을 어떻게 추정하나요? 대상 페이지의 대표 샘플을 프록시를 통해 측정하여(4단계) 실제 요청당 크기를 얻은 다음, 요청 수와 오버헤드 요인과 함께 공식에 대입하십시오. 측정된 샘플은 어떤 일반적인 추정보다 정확합니다.
대역폭을 가장 많이 소비하는 것은 무엇인가요? 단연 전체 브라우저 렌더링입니다. 모든 이미지, 폰트, 스크립트를 다운로드하기 때문입니다. HTML이나 JSON API를 직접 가져오면 요청당 크기를 10배 줄일 수 있습니다. 렌더링 선택이 청구액에 가장 큰 영향을 미치는 요소입니다.
실패하거나 재시도된 요청도 대역폭에 포함되나요? 네. 프록시를 거치는 모든 요청은 대역폭을 사용하며, 차단, 리디렉션, 재시도도 포함됩니다. 이 때문에 추정치에 오버헤드 요인이 포함되며, 차단율을 줄이면 비용이 낮아지는 이유이기도 합니다.
1 GB는 1,000 MB인가요, 1,024 MB인가요? 이는 제공업체의 청구 정의에 따라 다르며, 십진(1,000) 또는 이진(1,024) 방식입니다. 차이는 약 7%로 추정에는 문제가 없지만, 요금제 한계에 가깝게 산정할 때는 제공업체가 어느 방식을 사용하는지 확인하십시오.
여유분은 얼마나 추가해야 하나요? 추정치에 20~30%를 더해 월 내 성장과 추정 오차를 흡수하도록 계획하십시오. 그런 다음 실제 사용량과 대조하며 조정하고, 처음부터 과도하게 구매하지는 마십시오.
결론
레지덴셜 프록시 대역폭을 추정하는 것은 막연한 추측이 아닙니다. 요청 수에 측정된 평균 응답 크기와 오버헤드 요인을 곱하고, GB로 환산한 뒤 여유분을 더하면 됩니다. 이 수치에 가장 큰 영향을 미치는 두 가지는 가져오는 방식(HTML/JSON이 전체 브라우저보다 약 10배 우수)과 재시도 빈도(더 나은 IP 품질은 낭비되는 바이트를 줄임)입니다. 따라서 확정하기 전에 실제 샘플을 측정하고, 더 사기 전에 수치를 줄이십시오.
추정치가 준비되면 요금 페이지에서 GB당 요금제를 확인하여 수치와 여유분에 맞는 등급을 선택하고, 잘 조정된 스크래퍼를 레지덴셜 게이트웨이에 연결하여 실제 사용량을 계획에 가깝게 유지하십시오.