웹 스크래핑 요금 체계: GB당, 페이지당, 또는 Request당?

웹 스크래핑 요금 부과 단위는 벤더마다 다릅니다

Bright Data는 Web Unlocker 요금을 1,000건의 request 기준으로 책정합니다. Oxylabs는 Web Unblocker 요금을 기가바이트(GB) 단위로 부과합니다. Firecrawl은 페이지당 1 크레딧을 청구합니다. Zyte는 5개 난이도 등급에 따라 1,000건의 성공 response 단위로 요금을 청구합니다. Apify는 1시간 동안 유지되는 1GB RAM 기준인 컴퓨팅 유닛(CU)으로 요금을 계산합니다.

5개 벤더의 단위가 모두 다릅니다. 직접 측정해야 하는 특정 수치 없이는 서로 변환할 수 없으며, 해당 수치는 벤더의 제품이 아닌 사용자의 트래픽 특성에 따르므로 어떤 벤더도 이를 공개하지 않습니다.

2026년 9월 8일 기준으로 5개 벤더의 가격 정책 페이지를 분석했습니다. 각 요금 체계의 내용과 실제 계산 결과를 아래에서 다룹니다.

빠른 비교

이 표에서 두 가지 두드러진 점이 확인됩니다.

Zyte 자체 가격표만으로도 124배 차이가 납니다. 동일한 벤더, 동일한 단위, 동일한 인보이스 항목임에도 HTTP로 가져오는 단순 사이트는 1,000건당 $0.13인 반면, 브라우저에서 렌더링하는 고급 사이트는 $16.08입니다. 단순히 "1,000 request당"을 비교 지표로 언급하는 것은 이처럼 넓은 범위의 한쪽 끝만을 인용하는 것입니다.

또한 Bright Data는 제품군 내에서도 단위를 전환합니다. Web Unlocker는 request당 판매되며, Browser API는 기가바이트(GB) 단위로 판매됩니다. 이는 단순한 실수가 아닙니다. 분명한 이유가 있으며, 이 글의 나머지 부분에서 그 의미를 설명합니다.

1GB로 실제로 처리할 수 있는 양

모든 단위 변환을 결정하는 핵심 수치는 평균 페이지 용량이며, 공개된 데이터는 매우 극단적인 차이를 보여줍니다.

HTTP Archive의 Web Almanac 2025에 따르면, 2025년 7월 크롤링 기준 모바일 홈페이지 용량 중앙값은 전년 대비 8.4% 증가한 2,559KB입니다. 이 중앙값 페이지의 콘텐츠 유형별 용량을 나누어 보면 이미지 911KB, JavaScript 632KB, 폰트 122KB, CSS 77KB입니다.

그리고 HTML은 22KB에 불과합니다.

실제로 파싱하는 부분은 보통 HTML 문서뿐이므로 가장 중요한 것은 마지막 수치입니다. 중앙값 페이지 기준으로 이는 전체 브라우저 렌더링이 다운로드하는 데이터의 0.86%에 불과합니다. 나머지 99%는 전송 비용만 지불하고 버려지는 리소스입니다.

이를 $9.40/GB인 Oxylabs 8GB 플랜에 대입해 계산해 봅니다.

• HTML만 가져오는 경우(페이지당 22KB), 1GB는 약 45,000페이지에 해당합니다. 이는 1,000페이지당 약 $0.21입니다.
• 전체 페이지를 렌더링하는 경우(페이지당 2,559KB), 1GB는 약 390페이지에 불과합니다. 이는 1,000페이지당 약 $24입니다.

동일한 플랜, 동일한 광고 가격임에도 사용자의 코드 설정 하나만으로 116배의 비용 차이가 발생합니다.

이제 Firecrawl과 비교해 보겠습니다. 연간 요금 기준 100,000 크레딧에 $83(페이지당 1크레딧)인 경우, 페이지 용량이 20KB이든 4MB이든 1,000페이지당 $0.83를 지불합니다. HTML 전용 페치와 비교하면 기가바이트당 과금 방식이 약 4배 저렴하지만, 전체 렌더링과 비교하면 약 29배 더 비쌉니다.

손익분기점은 약 100KB 부근입니다

계산해 보면 두 과금 방식이 교차하는 특정 페이지 용량이 나옵니다. Firecrawl의 페이지당 $0.00083를 Oxylabs의 기가바이트당 $9.40로 나누면 88KB가 됩니다. Firecrawl을 연간 결제가 아닌 월간 결제(동일한 100,000 크레딧에 $99.50)로 이용하면 교차점은 106KB로 이동합니다. 이 구간 아래에서는 기가바이트당 과금이 유리합니다. 이 구간을 넘어서면 페이지당 정액 과금이 유리하며, 페이지 용량에는 상한선이 없기 때문에 격차는 빠르게 벌어집니다.

여기서 주목할 만한 점이 있습니다. Oxylabs는 의도하지 않았겠지만 자체적인 변환 기준을 공개하고 있습니다. Web Unblocker 무료 평가판은 "1GB (up to 10k results)"로 설명되어 있습니다. 이는 결과당 100KB에 해당하며, 방금 두 업체의 가격표를 통해 계산한 범위 내에 정확히 들어맞습니다. 그들 자체의 계산법도 갤러리를 렌더링하는 것이 아니라 문서를 가져온다고 가정한 수치입니다.

따라서 바이트 단위 과금을 사용하면서 브라우저를 제어하는 경우, 가장 중요한 요소는 벤더 선택이 아닙니다. 페이지가 로드되기 전에 이미지와 폰트를 차단하는 것입니다. 중앙값 기준 페이지에서 이미지와 폰트가 2,559KB 중 1,033KB를 차지하기 때문입니다. 청구서에 찍힌 로고가 비용을 결정하는 척하는 것보다 이 사실을 솔직하게 알리는 편이 낫습니다.

두 가지 분명한 유의사항이 있습니다. 이 수치들은 웹 전체의 중앙값이며, 실제 대상 페이지는 웹 전체와 다릅니다(쇼핑몰 및 여행 사이트는 더 무겁고, JSON endpoint는 훨씬 가볍습니다). 또한 미디어를 차단한 렌더링 페이지는 중앙값보다 훨씬 가벼워질 수 있으므로, 요금제 변경 없이도 교차점을 유리하게 이동시킬 수 있습니다. 동일한 계산 방식이 LLM 추출 단계의 경제성이 사라지는 시점을 결정합니다. 중요한 것은 단순 단가가 아니라 최종적으로 확보한 레코드당 비용입니다.

과금 기준이 무엇인가가 두 번째 축입니다

과금 단위는 한 가지 문제일 뿐입니다. 무엇이 과금을 트리거하는지는 또 다른 문제이며, 이는 놓치기 더 쉽습니다.

Bright Data는 Web Unlocker에서 "성공 건에 대해서만 지불"을 내세웁니다. Zyte는 "성공한 응답 1,000건당"으로 가격을 책정합니다. Firecrawl은 endpoint별 API request당 1크레딧을 차감합니다. 기가바이트당 과금에서는 성공 조건 자체가 없습니다. 바이트가 전송되었으므로 요금이 청구되며, 버려지는 챌린지 페이지 역시 비용을 지불하고 가져온 페이지가 됩니다.

이것은 생각보다 훨씬 중요합니다. 챌린지나 중간 삽입 페이지(interstitial)가 대부분 HTTP 200 상태 코드로 반환되기 때문입니다. 상태 코드만으로 성공 여부를 정의한다면, 재시도 로직과 인보이스의 수치가 실제 데이터셋과 일치하지 않게 됩니다. 당사는 유효성 검사 규칙이 이제 성공 기준을 결정합니다에서 이러한 괴리를 다룬 바 있으며, 이는 부분적인 차단이 시계열 데이터의 은밀한 누락으로 이어지는 근본적인 원인이기도 합니다.

어떤 과금 단위를 선택해야 하는가

문서를 렌더링하지 않고 단순히 가져오기만 하며 대상이 검색 결과, JSON endpoint, 목록 페이지, sitemap 등 텍스트 중심인 경우 GB당 과금을 선택하십시오. 페이지당 20~50KB 수준이라면 바이트 단위 가격이 시장에서 가장 저렴하며, 다른 어떤 방식도 이에 근접하지 못합니다.

렌더링이 필요하거나 대상에 미디어가 많거나 긴 꼬리(long-tail)에 속하는 다양한 사이트의 페이지 용량을 예측할 수 없다면 페이지당 또는 request당 과금을 선택하십시오. 데이터 크기가 작을 때는 다소 비싸지만 상한선을 확보할 수 있으며, 렌더링 워크로드에서는 이러한 상한선이 매우 큰 가치를 지닙니다.

수집 대상 구성이 안정적이고 각 사이트가 어느 등급에 속하는지 파악하고 있다면 Zyte가 판매하는 방식처럼 티어당 과금을 선택하십시오. 이 모델은 다른 곳에서 대충 평균 내어 숨겨버리는 진실, 즉 수집하기 어려운 사이트일수록 비용이 더 든다는 점을 솔직하게 반영합니다. 다만 수집 대상 목록이 매주 바뀌는 환경에는 적합하지 않습니다.

플랫폼에서 자체 코드로 장시간 크롤링을 실행한다면 컴퓨팅 유닛 단위 과금을 선택하십시오. 이 방식은 데이터가 아닌 머신 사용량을 기준으로 청구되므로, 파서가 빠를수록 유리하고 느릴수록 불리합니다. 코드 최적화의 효과가 인보이스에 직접 반영되는 유일한 모델입니다.

이러한 과금 단위 중 어느 것도 속임수가 아닙니다. 각각은 자사 고객층의 특성을 잘 알고 있는 벤더가 일반적인 트래픽 패턴을 전제로 설계한 방식입니다. 실수는 단위를 잘못 고르는 데서 오지 않습니다. 기준 단위가 전혀 다른 두 견적을 단순 비교하고 더 낮은 숫자를 선택하는 것이 진짜 실수입니다.

가격은 아무도 인상하지 않아도 오른다

당사를 포함해 누구에게서든 견적을 받기 전에, 일주일간의 자체 트래픽에서 두 가지 수치를 먼저 측정하십시오. 바로 fetch당 바이트 수와 실제로 보관할 가치가 있는 데이터를 반환한 fetch의 비율입니다. 이 두 수치만 확보하면 본 글의 모든 견적을 명확하게 환산할 수 있으며, 이 수치 없이는 어떤 견적도 제대로 비교할 수 없습니다.

그런 다음 내년에 어떤 일이 일어나는지 지켜보십시오. 지난 12개월 동안 웹사이트 메인 페이지 용량의 중앙값은 7.8% 증가했으며, 이 수치는 계속 늘어나는 방향으로만 움직입니다. 청구 기준이 바이트 단위라면, 이는 누구도 공지하지 않고 아무도 협상하지 않은 항목에서 매년 가격 인상이 발생하는 셈입니다.

FourA는 각 호출 비용을 response 자체에 포함하여 반환하므로, 월말에 인보이스를 보며 역산할 필요 없이 실시간으로 비용을 확인할 수 있습니다. 이것이 어떤 과금 단위를 사야 하는지 직접 알려주지는 않지만, 실제로 보관한 페이지당 얼마를 쓰고 있는지 알려줍니다. 결국 모든 판단의 핵심은 바로 이 숫자에 달려 있습니다.