대규모 스크래핑 시 프록시 대역폭 비용을 줄이는 방법

레지덴셜 프록시는 기가바이트 단위로 요금이 부과되며, 미숙한 스크래퍼는 바이트를 대부분 낭비합니다. 데이터 손실 없이 프록시 대역폭 비용을 줄이는 9가지 실용적인 방법입니다.

레지덴셜 프록시는 기가바이트 단위로 과금되므로, GB당 요금제에서는 대역폭이 곧 청구서입니다. 문제는 대부분의 스크레이퍼가 결제한 바이트의 대부분을 낭비한다는 점입니다. 절대 보지 않을 이미지, 폰트, 동영상, 추적 스크립트를 다운로드하고, 변경되지 않은 페이지를 다시 가져오며, 일반 HTTP 요청으로 충분한 경우에도 풀 브라우저를 렌더링합니다. 좋은 소식은 이러한 낭비의 거의 전부를 쉽게 줄일 수 있다는 것이며, 잘 조정된 스크레이퍼는 동일한 데이터에 대해 조정되지 않은 스크레이퍼의 절반 미만의 대역폭을 사용하는 것이 일반적입니다.

이 글은 바로 그것을 실현하는 실전 가이드입니다. 영향력이 큰 순서로 정리한 9가지 전략을 통해, 레지덴셜 프록시로 동일한 데이터를 수집하면서도 훨씬 적은 바이트 비용만 지불하는 방법을 다룹니다. 이는 bandwidth-priced residential proxies에서 다룬 GB당 과금 전환의 비용 효율성 관련 후속편입니다.

1. 꼭 필요하지 않다면 브라우저를 렌더링하지 마세요

이것이 단연 가장 큰 지렛대입니다. 헤드리스 브라우저는 페이지가 참조하는 모든 것을 다운로드합니다. 이미지, CSS, 웹 폰트, 동영상, 분석 스크립트, 광고 스크립트까지 말이죠. 대부분의 스크레이핑에서는 이 중 어느 것도 필요하지 않습니다. 원하는 데이터가 초기 HTML에 있거나 API(다음 섹션 참조)를 통해 접근 가능하다면, 브라우저를 아예 건너뛰고 일반 HTTP 클라이언트를 사용하세요. requests, httpx, 또는 Scrapy 등이 그것입니다. 단일 HTTP GET은 풀 브라우저 렌더링이 끌어오는 바이트의 극히 일부에 불과할 수 있습니다.

브라우저는 데이터를 생성하는 데 정말로 JavaScript 실행이 필요한 페이지에만 사용하세요. 확신이 서지 않는다면 먼저 원본 HTML을 가져와 원하는 값이 이미 거기에 있는지 확인하세요.

2. HTML이 아니라 JSON API를 호출하세요

많은 사이트가 페이지 로드 후 호출하는 백엔드 JSON 엔드포인트에서 콘텐츠를 렌더링합니다. 전체 HTML 페이지와 그 자산 대신 해당 엔드포인트를 직접 호출하면 바이트 수가 훨씬 적어지고, 파싱 없이 깔끔하고 구조화된 데이터를 얻을 수 있습니다. 브라우저의 네트워크 탭을 열어 데이터를 반환하는 요청(보통 JSON을 반환하는 XHR/fetch)을 찾아 프록시를 통해 직접 호출하세요. 가벼운 JSON 응답 하나가 무거운 페이지와 브라우저 렌더링을 대체할 수 있습니다.

3. 브라우저를 꼭 써야 할 때는 무거운 리소스 유형을 차단하세요

페이지가 정말로 렌더링을 필요로 할 때는, 사용하지 않을 것까지 브라우저가 다운로드하게 두지 마세요. Playwright와 Puppeteer 모두 요청을 가로채서 이미지, 미디어, 폰트, 그리고 종종 스타일시트까지도 프록시에 도달하기 전에 중단시킬 수 있으며, 이는 보통 대역폭을 절반 이상 줄여줍니다. Playwright에서는 다음과 같습니다.

await context.route("**/*", (route) => {
  const type = route.request().resourceType();
  if (["image", "media", "font"].includes(type)) {
    return route.abort();          // never downloaded, never billed
  }
  return route.continue();
});

document, script, xhr, fetch는 유지하고 나머지는 차단하세요. 동일한 패턴과 Chromium 관련 세부 사항은 how to use residential proxies with Playwright에 나와 있습니다.

4. 압축을 유지하세요

텍스트는 대략 5배에서 10배 압축되므로, gzip이나 brotli로 인코딩된 HTML 응답은 원본 크기의 일부에 불과합니다. 대부분의 HTTP 클라이언트는 기본적으로 Accept-Encoding: gzip, deflate, br을 전송하고 투명하게 압축을 해제하지만, 이를 비활성화하지 않았는지 확인하고 절대 해당 헤더를 제거하지 마세요. 헤더를 수동으로 설정하는 경우 이를 포함하세요.

headers = {"Accept-Encoding": "gzip, br", "User-Agent": "..."}

프록시를 통과하는 바이트는 압축된 바이트이므로, 이는 청구되는 양을 직접적으로, 그리고 무료로 줄여줍니다.

5. 조건부 요청을 사용해 변경되지 않은 페이지는 거의 비용이 들지 않게 하세요

반복되는 크롤링에서는 페이지를 무작정 다시 다운로드하지 마세요. HTTP 조건부 요청을 사용하면 서버가 전체 본문을 다시 보내는 대신 “아무것도 변경되지 않았음”을 작은 304 응답으로 알려줍니다. 각 요청에서 받은 ETag 또는 Last-Modified를 저장했다가 다시 보내세요.

# On refetch, send the stored validator
headers = {"If-None-Match": stored_etag}      # or If-Modified-Since
r = client.get(url, headers=headers)
if r.status_code == 304:
    pass   # unchanged: a few bytes instead of the full page

304 응답은 전체 페이지에 비해 거의 비용이 들지 않으며, 대부분의 페이지가 좀처럼 변경되지 않는 모니터링 작업에서는 이것만으로도 대역폭을 크게 줄일 수 있습니다.

6. 변경되지 않은 것은 다시 가져오지 마세요

관련은 있지만 HTTP 검증자보다 더 넓은 범위의 이야기입니다. 이미 수집한 것을 추적해서 건너뛰세요. 사이트맵의 lastmod 타임스탬프를 사용해 변경된 URL을 찾고, 페이지별로 콘텐츠 해시를 보관해 동일한 콘텐츠의 재처리를 건너뛰고, 크롤 프런티어를 중복 제거해서 한 번의 실행에서 같은 URL을 두 번 가져오지 않도록 하세요. 가장 저렴한 기가바이트는 애초에 다운로드하지 않는 기가바이트입니다.

7. 필요한 바이트만 가져오세요

파일의 헤더나 첫 부분만 필요하다면(메타데이터 확인, 콘텐츠 유형 확인) 전체를 다운로드하지 마세요. HEAD 요청은 본문 없이 헤더만 반환하고, 서버가 지원하는 경우 Range 요청은 지정한 바이트만 가져옵니다.

client.head(url)                                   # headers only, no body
client.get(url, headers={"Range": "bytes=0-2047"}) # first 2 KB only

이는 크롤링이 대용량 미디어, PDF, 또는 일부만 필요하거나 메타데이터만 필요한 다운로드를 다룰 때 특히 중요합니다.

8. 재시도와 지역 타겟팅을 효율적으로 만드세요

실패한 시도도 여전히 대역폭을 소모하므로, 낭비되는 재시도는 조용히 청구서를 부풀립니다. 실패하는 URL을 계속 두드리기보다는 백오프하고 재시도 횟수를 제한하세요. 그리고 국가 + 도시 + ASN을 한꺼번에 지정하는 지나치게 엄격한 지역 필터는 일치하는 IP가 없을 때 요청 실패와 재시도를 유발하니, 대신 필터를 완화하세요. 응답이 지연되지 않도록 합리적인 타임아웃을 설정하고, 불필요하게 흐름을 재수립하지 않도록 작업에 맞는 세션 전략을 선택하세요. 효율적인 요청이 저렴한 요청입니다.

9. 레코드당 바이트 수를 측정하세요

측정하지 않는 것은 줄일 수 없습니다. 작업당 대역폭, 더 나아가 성공적으로 추출한 레코드당 바이트 수를 추적하면 낭비가 드러납니다. 행당 메가바이트 단위의 비용이 드는 페이지는 대개 차단할 수 있었던 자산을 끌어오고 있거나 API를 호출할 수 있었는데 렌더링을 하고 있는 경우입니다. 이를 기록하고, 추세를 지켜보며, 가장 문제가 되는 것부터 최적화하세요.

책임감 있게 수행하는 것에 대한 참고 사항

대역폭을 줄이는 것은 여러분에게 비용을 절감해줄 뿐 아니라, 수집 대상 사이트에도 부담을 덜어줍니다. 요청이 더 적고 더 작다는 것은 그들의 서버에 걸리는 부하가 줄어든다는 뜻입니다. 이는 비용 효율성과 좋은 시민 의식을 일치시킵니다. 공개 데이터 수집을 계속하되, 각 사이트의 이용약관과 속도 제한을 준수하고, 효율성이 여러분의 발자국을 줄이도록 하세요. 저희 acceptable use policy가 Shifter에서 허용되는 사항에 대한 공식 기준입니다.

FAQ

프록시를 통한 스크레이핑에서 가장 많은 대역폭을 사용하는 것은 무엇인가요? 단연 풀 브라우저 렌더링입니다. 페이지의 모든 이미지, 폰트, 동영상, 스크립트를 다운로드하기 때문입니다. 렌더링을 줄이는 것(또는 렌더링이 꼭 필요할 때 무거운 리소스 유형을 차단하는 것)이 가장 효과가 큰 변화입니다.

이미지와 폰트를 차단하면 스크레이핑이 망가지나요? 대개는 아닙니다. 데이터 추출에는 거의 필요하지 않습니다. 사이트가 대상 콘텐츠를 이미지 뒤에 지연 로딩하지 않는지 테스트하세요. 대다수 작업에서 이미지, 미디어, 폰트 요청을 차단하는 것은 안전하며 대역폭을 상당히 줄여줍니다.

레지덴셜 프록시는 실패하거나 차단된 요청에도 과금하나요? 프록시를 통과하는 바이트는 과금 대상이므로, 실패한 시도와 재시도도 여전히 대역폭 비용이 듭니다. 그래서 효율적인 재시도, 합리적인 타임아웃, 그리고 (실패를 유발하는) 지나치게 엄격한 지역 필터를 피하는 것이 청구서에 중요합니다.

사이트의 JSON API를 호출하는 것이 허용되나요? 페이지 자체가 사용하는 공개 엔드포인트를 호출하는 것은 흔한 관행이며 훨씬 더 효율적이지만, 사이트의 이용약관과 속도 제한은 여전히 적용됩니다. 책임감 있게 수집하고, 불확실한 사항에 대해서는 법률 자문을 구하세요.

실제로 얼마나 절감할 수 있나요? 대상에 따라 다르지만, 불필요한 렌더링을 건너뛰고, 무거운 리소스를 차단하고, 변경되지 않은 페이지를 다시 가져오지 않는 것만으로도 동일한 추출 데이터에 대해 총 대역폭을 절반 이상 줄이는 경우가 흔합니다.

결론

GB당 요금제에서 대역폭 효율성은 곧 비용 효율성이며, 대부분의 스크레이퍼는 많은 것을 낭비하고 있습니다. 가져올 수 있는데 렌더링하고, 읽지도 않을 자산을 다운로드하고, 변경되지 않은 페이지를 다시 끌어옵니다. 이 목록을 하나씩 실행하세요. 가능하면 브라우저를 건너뛰고, API를 호출하고, 무거운 리소스를 차단하고, 압축을 유지하고, 조건부 요청을 사용하고, 변경되지 않은 페이지는 다시 가져오지 않고, 필요한 것만 가져오고, 재시도를 효율화하고, 측정하세요. 그러면 동일한 데이터를 훨씬 적은 바이트 비용으로 얻을 수 있습니다.

이러한 효율성은 풀(pool)의 품질과 결합될 때 배가됩니다. 깨끗한 IP는 차단과 재시도가 적다는 뜻이고, 이는 곧 낭비되는 바이트가 적다는 뜻입니다. 그러니 클라이언트를 조정하는 것과 함께 스크레이핑에 적합한 프록시 선택하기도 고려할 가치가 있습니다. pricing 페이지에서 GB당 요금제를 확인한 다음, 잘 조정된 스크레이퍼를 레지덴셜 게이트웨이에 연결하고 바이트가 줄어드는 것을 지켜보세요.