파서를 실행하거나 프록시를 통해 계정을 준비할 때 페이지 크기를 기준으로 소비량을 계산하는데, 예상보다 2-3배 더 높은 청구서를 받게 됩니다. 이는 제공자의 사기 때문이 아닙니다: 트래픽에는 실제로 채널을 통해 전달된 모든 것이 포함됩니다 — 요청 헤더, TLS 핸드셰이크, 연결 재시도 및 제어 패킷. 트래픽 청구서가 어떻게 구성되는지, 그리고 작업 품질을 저하시키지 않고 소비를 줄이는 방법을 분석합니다.
제공자가 실제로 트래픽으로 간주하는 것
소비량을 "눈대중"으로 평가할 때, 일반적으로 머릿속에 있는 공식은 HTML 페이지 크기와 이미지입니다. 그러나 프록시 제공자는 채널의 양방향에서 전달된 데이터의 총량을 계산합니다 — 아웃바운드(요청) 및 인바운드(응답). 이 총량에는 유용한 데이터뿐만 아니라 모든 제어 트래픽도 포함됩니다: 프로토콜 헤더, TLS 메타데이터, TCP ACK 패킷, 타임아웃 시 연결 재시도.
일반 페이지에 대한 단일 요청의 경우 "유용한 데이터"와 "제어 데이터"의 비율은 80/20일 수 있습니다. 그러나 응답이 작은 API(몇 킬로바이트의 JSON)와 헤더 및 핸드셰이크가 많은 경우에는 비율이 쉽게 뒤집힙니다. 이러한 이유로 수십 개의 작은 요청을 광고 API나 마켓플레이스에 보내는 중재자들은 종종 청구서에 놀라게 됩니다: 각 요청은 유용한 데이터의 크기와 관계없이 고정된 "세금"을 부과합니다.
또 하나 중요한 점은 제공자가 트래픽을 프록시 서버 수준에서 계산한다는 것입니다. 즉, IP를 통해 실제로 전달된 모든 트래픽이 포함됩니다 — 실패한 시도, 리디렉션, 페이지에서 리소스(스타일, 스크립트, 트래커)를 자동으로 요청한 경우에도 포함됩니다. 이 경우 텍스트만 필요했더라도 말입니다.
HTTP/HTTPS 헤더: 각 요청의 숨겨진 무게
각 HTTP 요청과 응답은 User-Agent, Cookie, Accept-Language, Referer, Content-Type 등 여러 헤더를 포함합니다. 현대 브라우저와 안티-디텍트 도구(Dolphin Anty, AdsPower, Multilogin)에서는 헤더 세트가 요청당 500바이트에서 2-3KB까지 차지할 수 있습니다 — 특히 쿠키에 수십 개의 값이 쌓인 경우에는 더욱 그렇습니다.
예를 들어, 세션 쿠키가 1.5KB인 마켓플레이스 API에 10,000개의 요청을 보내면, 헤더에만 약 15MB의 트래픽이 소모됩니다 — 응답 본체를 고려하지 않고도 말입니다. 여러 계정과 프로필로 확장할 경우 이 숫자는 선형적으로 증가합니다.
| 헤더 유형 | 평균 크기 | 트래픽에 미치는 영향 |
|---|---|---|
| User-Agent | 100-150 바이트 | 낮음, 그러나 규모에 따라 누적됨 |
| Cookie (세션) | 500-2000 바이트 | 긴 세션에서 높음 |
| Referer / Origin | 50-200 바이트 | 낮음 |
| Accept-* 헤더 | 150-300 바이트 | 낮음 |
| 서버 응답 헤더 | 300-800 바이트 | 중간, 귀하와는 무관함 |
실용적인 결론: Wildberries 또는 Ozon의 가격 모니터링을 위한 스크립트를 작성하는 경우, 사용하지 않는 값의 쿠키를 정리하고 "혹시나" 브라우저 DevTools에서 복사한 불필요한 헤더를 요청에 포함하지 마십시오.
TLS 핸드셰이크: 암호화가 소모하는 트래픽 양
현대 웹의 거의 모든 것이 HTTPS를 통해 작동하므로, 각 새로운 연결은 TLS 핸드셰이크로 시작됩니다 — 인증서, 암호화 키 및 프로토콜 매개변수의 교환. 하나의 전체 TLS 핸드셰이크(TLS 1.2 또는 1.3)는 사이트 인증서의 크기와 사용된 프로토콜 확장에 따라 4KB에서 8KB까지 소모됩니다.
각 요청에 대해 새로운 연결을 열 경우(지속 연결을 사용하지 않는 경우), TLS 핸드셰이크가 매번 반복됩니다. 연결을 재사용하지 않고 10,000개의 요청을 보낼 경우, 암호화에만 추가로 40-80MB의 트래픽이 발생합니다 — 이는 실제 유용한 콘텐츠보다 많을 수 있습니다.
TLS 1.3은 라운드 트립 수가 줄어들어 TLS 1.2보다 약간 가볍지만, 차이는 많은 연결에서만 느껴집니다. 이동통신 프록시의 경우, 운영자의 네트워크가 추가 지연과 세션 재설정을 추가하므로 TLS 오버헤드가 특히 눈에 띄게 나타납니다 — 이는 잦은 짧은 요청이 필요한 작업을 위해 모바일 프록시를 선택할 때 고려해야 할 사항입니다.
재시도: 반복 요청이 소비를 두 배로 늘리는 방법
재시도는 가장 눈에 띄지 않지만 가장 비싼 트래픽 소비 항목입니다. 파서나 스크립트가 타임아웃이나 오류 429/503 시 자동으로 재시도하도록 설정되어 있다면, 각 실패한 요청은 이미 연결 설정, TLS 핸드셰이크 및 헤더에 대한 트래픽을 소모했으며, 이후 이 모든 과정이 다시 반복됩니다.
SMM 자동화 및 마켓플레이스 파싱에서 자주 발생하는 오류는 지수 지연 없이 공격적인 재시도 정책입니다: 스크립트는 IP 차단의 첫 신호가 나타나면 1초 간격으로 5번의 시도를 연속으로 합니다. 결과적으로 하나의 "유용한" 응답을 얻기 위해 다섯 번의 실패한 시도와 마지막 성공적인 요청의 트래픽이 소모됩니다.
이는 Avito와 같은 공격적인 보호가 있는 사이트에서 데이터 센터 프록시를 사용할 때 특히 중요합니다. 이러한 사이트는 "핫" IP에서 대부분의 요청에 대해 CAPTCHA를 반환하거나 차단할 수 있습니다. 이 경우 주거용 프록시를 고려하는 것이 좋습니다 — 이들은 첫 요청에서 차단될 가능성이 적어 재시도 수를 줄이고, 따라서 실제 트래픽 소비를 줄입니다.
Keep-Alive 대 새로운 연결
HTTP Keep-Alive는 여러 요청을 위해 하나의 TCP/TLS 연결을 재사용할 수 있게 해 주며, 반복 핸드셰이크를 피할 수 있습니다. 이는 거의 모든 HTTP 클라이언트와 안티-디텍트 브라우저에서 사용할 수 있는 가장 효과적인 트래픽 최적화 중 하나입니다.
파싱을 위한 라이브러리(requests, httpx, axios)를 사용할 때, 지속적인 연결을 명시적으로 지정하지 않으면 각 요청이 기본적으로 새로운 TCP 연결을 열 수 있습니다. 프록시와 함께 사용할 경우, 이는 프록시 서버까지의 새로운 연결, 목표 사이트까지의 새로운 TLS 연결을 의미하며, 모든 오버헤드가 각 호출마다 반복됩니다.
| 연결 모드 | 1000 요청당 오버헤드 |
|---|---|
| 각 요청마다 새로운 연결 | 4-8MB (TLS만) |
| Keep-Alive, 50 요청당 하나의 세션 | 0.1-0.2MB (그룹당 하나의 핸드셰이크) |
차이는 수배에 이르며 — 이는 요청의 유용한 데이터 변경 없이 순수한 트래픽 절약입니다.
다양한 유형의 프록시가 트래픽을 계산하는 방법
트래픽 청구 모델은 프록시 유형에 따라 다릅니다. 데이터 센터 프록시는 트래픽 양이나 IP/포트 수에 따라 요금이 부과되는 경우가 많습니다 — 인프라가 더 빠르고 라우팅에 대한 최소한의 오버헤드를 추가합니다. 주거용 및 모바일 프록시는 일반적으로 더 엄격하게 요금이 부과됩니다. 실제 사용자 IP는 더 비싸고 제한된 자원이기 때문입니다. 운영자나 가정용 제공자를 통한 경로는 추가 홉을 추가하고, 따라서 약간 더 많은 제어 데이터를 추가합니다.
모바일 프록시는 이 점에서 가장 "비싼" 트래픽을 발생시킵니다: 이동통신 네트워크는 세션 재설정, NAT 변환 및 때때로 운영자 수준에서 트래픽 압축/압축 해제를 추가하여 동일한 요청을 고정 네트워크를 통해 보낼 때보다 전달된 데이터 수를 증가시킵니다.
안정적인 높은 요청량을 최소한의 오버헤드로 처리하는 것이 목표라면(예: Wildberries 또는 Ozon의 대량 가격 파싱), 데이터 센터 프록시가 가장 적합합니다 — 이들은 더 빠르고 유사한 작업에서 트래픽 소비가 예측 가능하기 때문입니다.
실제로 트래픽 소비를 줄이는 방법
파서, 자동화 또는 멀티 계정의 기능을 손상시키지 않으면서 실제 트래픽 소비를 줄이는 구체적인 단계를 살펴보겠습니다.
1. 불필요한 리소스 로드를 비활성화하십시오. 페이지의 텍스트나 API의 JSON 응답만 필요하다면, 안티-디텍트 브라우저 또는 헤드리스 도구의 설정에서 이미지, 글꼴, 분석 스크립트 및 광고 트래커의 로드를 비활성화하십시오. 이는 파싱 작업의 경우 트래픽 소비를 60-80% 줄이는 경우가 많습니다.
2. Keep-Alive 및 연결 풀을 사용하십시오. HTTP 클라이언트를 설정하여 동일한 호스트에 대한 요청 그룹에 대해 세션을 재사용하도록 설정하십시오 — 이는 TLS 핸드셰이크 수를 급격히 줄입니다.
3. 합리적인 재시도 정책을 설정하십시오. 지수 지연(1초 → 2초 → 4초)으로 3회 시도로 제한하여 공격적인 5-10회의 연속 시도 대신 불필요한 요청으로 인한 트래픽을 줄이고 IP 차단의 추가 위험을 줄입니다.
4. 쿠키 및 세션 헤더를 정리하십시오. 사용되지 않는 쿠키 값을 주기적으로 삭제하십시오 — 특히 Instagram 또는 TikTok의 계정을 준비하는 긴 세션에서 더욱 중요합니다.
5. 정적 응답을 캐시하십시오. 데이터(예: 제품 카탈로그)가 매분 변경되지 않는 경우, 모니터링 주기마다 프록시를 통해 반복 요청하는 대신 응답을 로컬로 캐시하십시오.
6. 압축을 사용하십시오. Accept-Encoding: gzip 헤더가 전달되고 서버가 실제로 압축된 응답을 제공하는지 확인하십시오 — 이는 많은 텍스트나 JSON이 포함된 페이지에서 들어오는 트래픽 양을 줄입니다.
트래픽 모니터링 도구
트래픽이 실제로 어디로 가는지 이해하기 위해서는 제공자의 카운터뿐만 아니라 요청의 세부 분류를 보는 것이 유용합니다. 이를 위해 적합한 도구는 다음과 같습니다:
- Charles Proxy / Fiddler — 각 요청 및 응답의 크기를 보여주며, 헤더를 포함하여 "무거운" 쿠키나 불필요한 리소스를 찾는 데 도움이 됩니다.
- Wireshark — 패킷 수준에서 TCP/TLS 오버헤드를 깊이 분석하기 위해, 핸드셰이크의 실제 무게를 평가해야 할 경우 유용합니다.
- 안티-디텍트 브라우저의 내장 트래픽 카운터 (Dolphin Anty, AdsPower, GoLogin) — 많은 경우 각 프로필별 소비를 따로 보여주어 계정 간 예산 분배에 편리합니다.
- HTTP 클라이언트 수준에서의 로깅 — 자체 파싱 스크립트를 작성할 때, 각 호출의 요청/응답 크기를 로깅하여 이상을 찾아내는 것이 유용합니다.
도구의 측정값을 제공자의 프록시 카운터와 비교하면 트래픽이 어디에서 손실되는지 — 재시도, TLS 또는 불필요한 리소스 로드에서 — 빠르게 이해할 수 있습니다.
시작 전 최적화 체크리스트
파서의 대규모 실행, SMM 자동화 또는 광고 계정의 준비를 시작하기 전에 짧은 목록을 확인하십시오:
- 필요하지 않은 곳에서 이미지, 글꼴, 분석의 로드가 비활성화되어 있습니다;
- 동일한 호스트에 대한 일련의 요청을 위해 Keep-Alive / 세션 재사용이 설정되어 있습니다;
- 재시도 정책이 무한 반복이 아닌 2-3회의 지연으로 제한되어 있습니다;
- 세션 쿠키가 주기적으로 사용되지 않는 값에서 정리되고 있습니다;
- 응답 압축이 활성화되어 있습니다 (gzip/deflate/br);
- 반복되는 정적 요청에 대한 로컬 캐시가 있습니다;
- 작업에 적합한 프록시 유형이 선택되었습니다: 속도와 양을 위한 데이터 센터, 차단 우회를 위한 주거용, 소셜 미디어 및 광고 플랫폼을 위한 모바일.
결론
프록시를 통한 트래픽 소비는 페이지의 유용한 데이터뿐만 아니라 모든 제어 오버헤드도 포함됩니다: 헤더, TLS 핸드셰이크, 오류 시 재시도. 이러한 메커니즘을 이해하면 프록시에 대한 예산을 더 정확하게 계획하고, 특히 마켓플레이스 파싱, SMM 자동화 또는 광고 계정 준비 시 불쾌한 놀라움을 피할 수 있습니다.
안정적인 파싱과 예측 가능한 트래픽 소비가 목표라면, 데이터 센터 프록시에 주목하십시오. 소셜 미디어 및 광고 플랫폼에서 차단 빈도가 낮은 것이 중요한 경우, 모바일 프록시가 더 적합합니다. 사이트 보호 우회를 위한 익명성과 안정성 간의 균형이 필요하다면, 주거용 프록시를 고려하십시오. 이들은 차단이 덜 발생하여 재시도 수를 줄입니다.