플레이라이터 vs 퍼피티어 vs 요청: 1000 페이지의 트래픽

만약 당신이 GB 단위로 프록시 트래픽에 대해 비용을 지불한다면, 헤드리스 브라우저와 일반 HTTP 클라이언트 간의 차이는 동일한 1000 페이지 데이터셋에서 15-20배 더 많은 비용을 초래할 수 있습니다. 이 기사에서는 Playwright, Puppeteer 및 Python 라이브러리 requests의 실제 트래픽 소비 측정값, 테스트를 위한 코드 및 콘텐츠 손실 없이 데이터 양을 줄이는 방법을 다룹니다.

트래픽 소비가 파싱에 중요한 이유

대부분의 프록시 제공업체는 주거용 및 모바일 풀을 포함하여 트래픽을 GB 단위로 청구하며, 요청 수가 아닙니다. 이는 웹사이트를 파싱하는 도구가 프로젝트 예산에 직접적인 영향을 미친다는 것을 의미합니다. 헤드리스 브라우저는 HTML, CSS, JavaScript, 이미지, 글꼴, 분석 스크립트, 광고 배너 및 추적기를 포함하여 페이지를 전체적으로 로드합니다. requests와 같은 HTTP 클라이언트는 명시적으로 요청한 것만 다운로드합니다. 일반적으로 이는 순수 HTML 문서입니다.

차이는 특히 규모에서 두드러집니다. Wildberries 또는 Ozon에서 상품 카드를 파싱하거나 경쟁자의 가격을 수집하거나 Google 검색 결과를 모니터링하는 경우, 1000 페이지는 하나의 스크립트에 대한 전형적인 일일 할당량입니다. 매달 수십만 페이지를 처리할 때, 트래픽 절약은 특히 주거용 프록시를 사용할 경우, 비용의 중요한 항목이 됩니다.

추가적인 복잡성은 현대 웹사이트가 봇으로부터 적극적으로 보호되고 있다는 것입니다: JavaScript 렌더링, 마우스 행동, 캔버스 핑거프린트를 확인합니다. 이는 개발자들이 간단한 HTTP 요청에서 Playwright나 Puppeteer와 같은 완전한 브라우저로 전환하게 만듭니다. 이러한 도구는 트래픽에서 훨씬 더 많은 양을 차지합니다. 정확한 수치를 이해하면 프록시 예산을 미리 계산하고 특정 작업에 적합한 도구를 선택하는 데 도움이 됩니다.

트래픽 측정 방법론

공정한 비교를 위해, 저는 동일한 1000 URL 목록을 사용했습니다. 중간 복잡도의 상품 카드로, 이미지, 분석 스크립트 및 여러 외부 위젯이 포함되어 있습니다(전자상거래 사이트의 전형적인 구조). 트래픽 측정은 시스템 네트워크 모니터와 각 도구의 내장 요청 로깅 도구를 통해 수행되었습니다.

실험의 중요한 조건:

브라우저 캐시가 비활성화되어 있습니다 — 각 페이지는 "제로"에서 로드되며, 이는 다양한 IP로 프록시를 회전할 때 발생하는 방식입니다.
모든 브라우저 테스트에서 헤드리스 모드가 활성화되어 있습니다 — 이는 대부분의 프로덕션 스크립트에서 작동하는 방식입니다.
기본 시나리오에서 리소스 차단 없이 — 최적화 없이 "순수" 소비를 보여주기 위해서입니다.
모든 세 도구에 대해 동일한 네트워크와 동일한 페이지 세트를 사용했습니다.

이러한 접근 방식은 귀하의 특정 사례에 적용할 수 있는 비교 가능한 수치를 제공합니다. 프로젝트의 페이지 수에 곱하고 프록시 요금의 양으로 나누면 됩니다.

requests: 최소 트래픽 소비

Python의 requests 라이브러리는 HTTP 응답의 본체만 다운로드합니다 — 명시적으로 요청한 것만. JavaScript, 이미지, CDN에 대한 추가 요청은 없습니다. 제 테스트에서 전자상거래 카드의 평균 HTML 페이지 무게는 약 180-250 KB의 압축되지 않은 HTML로 나타났습니다.

import requests

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

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}

total_bytes = 0
urls = load_urls_from_file("urls.txt")  # 1000 링크 목록

for url in urls:
    response = requests.get(url, headers=headers, proxies=proxies, timeout=15)
    total_bytes += len(response.content)

print(f"총 다운로드: {total_bytes / 1024 / 1024:.2f} MB")

1000 페이지에서 최종 소비는 190-230 MB로, 즉 0.25 GB 미만입니다. 이는 가장 경제적인 옵션이지만, 중요한 제한이 있습니다: 사이트가 JavaScript를 통해 콘텐츠를 렌더링하는 경우(React, Vue, 동적 가격 로딩), requests는 필요한 데이터가 없는 빈 페이지의 골격만을 받게 됩니다. 정적 HTML 또는 SSR이 있는 사이트에는 트래픽과 결과의 비율이 이상적인 선택입니다.

Puppeteer: 헤드리스 Chrome의 무게

Puppeteer는 실제 Chromium 엔진을 제어하므로 페이지를 전체적으로 로드합니다: HTML, CSS, 글꼴, 이미지, 추적 스크립트, 광고 iframe. 헤드리스 모드에서도 브라우저는 일반 사용자가 Chrome에서 수행하는 모든 네트워크 요청을 수행합니다.

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch({
    headless: 'new',
    args: ['--proxy-server=http://proxy_host:port']
  });

  const page = await browser.newPage();
  await page.authenticate({ username: 'user', password: 'pass' });

  let totalBytes = 0;
  page.on('response', async (response) => {
    try {
      const buffer = await response.buffer();
      totalBytes += buffer.length;
    } catch (e) {}
  });

  const urls = require('./urls.json'); // 1000 링크

  for (const url of urls) {
    await page.goto(url, { waitUntil: 'networkidle2', timeout: 30000 });
  }

  console.log(`총 트래픽: ${(totalBytes / 1024 / 1024).toFixed(2)} MB`);
  await browser.close();
})();

제 테스트에서 Puppeteer를 통한 한 페이지의 평균 무게는 이미지와 외부 스크립트의 수에 따라 2.8-4.5 MB로 나타났습니다. 1000 페이지에서 이 결과는 3.1-4.2 GB로, requests보다 15-18배 더 많습니다. 트래픽의 주요 부분은 이미지(일반적으로 페이지 무게의 40-55%)와 외부 분석, 광고 및 채팅 위젯 스크립트(20-30%)가 차지합니다.

Playwright: 다양한 브라우저에서의 트래픽

Playwright는 비슷한 방식으로 작동하지만 세 가지 엔진을 지원합니다 — Chromium, Firefox 및 WebKit. 이들 간의 트래픽 소비는 다릅니다: WebKit은 헤드리스 모드에서 미디어 콘텐츠 처리 방식이 다르기 때문에 전통적으로 약간 더 경제적이며, Firefox는 요청 간 리소스 캐싱의 차이로 인해 때때로 더 많은 데이터를 로드합니다.

from playwright.sync_api import sync_playwright

total_bytes = 0

def handle_response(response):
    global total_bytes
    try:
        body = response.body()
        total_bytes += len(body)
    except Exception:
        pass

with sync_playwright() as p:
    browser = p.chromium.launch(
        headless=True,
        proxy={"server": "http://proxy_host:port", "username": "user", "password": "pass"}
    )
    page = browser.new_page()
    page.on("response", handle_response)

    urls = load_urls_from_file("urls.txt")
    for url in urls:
        page.goto(url, wait_until="networkidle", timeout=30000)

    print(f"총 트래픽: {total_bytes / 1024 / 1024:.2f} MB")
    browser.close()

Chromium을 통한 Playwright의 결과는 Puppeteer와 유사하게 나타났습니다 — 2.9-4.3 GB로 1000 페이지에서, 이는 두 도구가 동일한 엔진을 사용하기 때문에 논리적입니다. WebKit에서의 소비는 10-15% 낮아 약 2.6-3.7 GB, Firefox에서는 약간 더 높아 3.3-4.6 GB로 나타났습니다. 차이는 각 브라우저 엔진의 글꼴 처리, 이미지 디코딩 및 네트워크 스택 동작의 차이로 설명됩니다.

비교 표: 1000 페이지당 GB

아래는 모든 테스트된 옵션에 대한 요약 표로, 실용적인 범위로 반올림되었습니다. 수치는 이미지와 일반적인 외부 스크립트 세트를 가진 평균 전자상거래 페이지에 해당합니다 — 뉴스 사이트나 비디오가 포함된 랜딩 페이지에서는 소비가 더 높을 것입니다.

도구	1000 페이지당 트래픽	JS 렌더링	봇 탐지 우회
requests (Python)	0.19-0.23 GB	없음	약함
Playwright (WebKit)	2.6-3.7 GB	있음	중간
Puppeteer (Chromium)	3.1-4.2 GB	있음	중간
Playwright (Chromium)	2.9-4.3 GB	있음	좋음
Playwright (Firefox)	3.3-4.6 GB	있음	중간

주요 결론: 사이트가 필요한 데이터를 얻기 위해 JavaScript 렌더링을 요구하지 않는다면, requests는 어떤 브라우저 솔루션보다 15-20배 더 많은 트래픽을 절약합니다. 그러나 콘텐츠가 동적으로 로드되거나 사이트가 브라우저 행동을 적극적으로 확인하는 경우, 브라우저 렌더링 트래픽에 대한 비용을 지불해야 합니다.

트래픽 소비를 5-10배 줄이는 방법

완전한 브라우저가 필요하더라도, 필요한 데이터를 잃지 않고 트래픽 소비를 급격히 줄일 수 있습니다. 다음은 제가 1000 페이지 세트에서 확인한 작업 방법입니다.

1. 이미지, 글꼴 및 미디어 차단. 이미지는 일반적으로 페이지 무게의 절반 이상을 차지하며, 텍스트 데이터를 파싱하는 데는 필요하지 않습니다.

await page.route('**/*', (route) => {
  const type = route.request().resourceType();
  if (['image', 'font', 'media'].includes(type)) {
    route.abort();
  } else {
    route.continue();
  }
});

이 방법은 Playwright와 Puppeteer 모두에서 동일하게 작동하며, HTML 및 텍스트 데이터 손실 없이 트래픽을 40-60% 줄입니다.

2. 외부 도메인 차단. 광고 네트워크, 분석, 채팅 위젯은 필요 없는 자체 스크립트와 이미지를 로드합니다. 도메인별로 요청을 필터링하여 기본 리소스와 CDN만 남길 수 있습니다.

3. "networkidle" 대신 "domcontentloaded" 사용. 전체 네트워크 로드를 기다리면 브라우저는 분석 및 지연 로드를 포함한 모든 백그라운드 요청을 기다리게 됩니다. 데이터가 DOM에 더 빨리 나타나면, 더 이른 이벤트로 전환하면 파싱 속도가 빨라지고 불필요한 추가 로드를 줄일 수 있습니다.

4. 요청 간 정적 리소스 캐싱. 사이트가 모든 페이지에서 동일한 CSS/JS 파일을 사용하는 경우, 브라우저 캐시가 활성화되면(우리 테스트 조건과는 다르게) 동일한 도메인의 많은 URL을 순차적으로 탐색할 때 상당한 양을 절약합니다.

5. 하이브리드 접근법. 많은 팀이 먼저 requests를 시도하고, 데이터가 부족할 경우에만 Playwright 또는 Puppeteer를 통해 특정 페이지로 전환합니다. 이는 낮은 기본 트래픽 소비와 렌더링이 정말 필요한 곳에서의 가능성을 결합합니다.

리소스를 효과적으로 차단하면 Puppeteer와 Playwright의 트래픽 소비가 3-4 GB에서 1000 페이지당 0.6-1.2 GB로 줄어들어 requests와 비교할 때 차이가 눈에 띄게 줄어들며, JS 렌더링 및 안티봇 보호와 함께 작업할 수 있는 가능성을 유지합니다.

트래픽 양에 맞는 프록시 선택 방법

트래픽 계산은 프록시 유형 선택에 직접적인 영향을 미칩니다. 정적 사이트에서 requests를 통한 가벼운 HTTP 요청에는 데이터 센터 프록시가 잘 맞습니다 — 빠르고, 트래픽 비용이 저렴하며, 사이트가 행동 신호를 확인하지 않는 경우 충분합니다.

Playwright 또는 Puppeteer를 통한 완전한 렌더링이 필요한 경우, 예를 들어 마켓플레이스에서 가격 수집이나 검색 결과 모니터링 시에는 주거용 프록시를 사용하는 것이 더 합리적입니다. 이들은 IP 평판으로 차단되는 일이 적어, 각 요청이 몇 메가바이트의 비용을 초래하고 차단으로 인해 데이터를 다시 가져오는 것이 비쌀 때 중요합니다.

사이트가 IP와 사용자 에이전트의 일치를 특히 엄격하게 확인하는 경우(은행 서비스, 모바일 인증이 있는 애플리케이션) 모바일 프록시를 고려해야 합니다 — 트래픽 비용이 더 높더라도, IP 주소의 신뢰성을 극대화하고 차단으로 인한 재요청 수를 최소화합니다.

실용적인 기준: "페이지 하나의 무게 × 페이지 수 × 오류 및 차단으로 인한 재요청 계수" 공식을 사용하여 트래픽 양을 계산하고 최종 GB를 제공업체의 요금과 비교합니다. 위에서 설명한 리소스 최적화는 일반적으로 더 저렴한 프록시 유형 선택보다 더 많은 절약을 제공합니다 — 하지만 올바른 도구와 올바른 프록시의 조합이 최대 효과를 제공합니다.

결론

requests는 여전히 트래픽 측면에서 가장 경제적인 도구로, 1000 페이지당 약 0.2 GB입니다. 그러나 동적 콘텐츠가 있는 사이트에는 적합하지 않습니다. Puppeteer와 Playwright는 완전한 렌더링과 더 나은 보호 우회를 제공하지만, 동일한 1000 페이지에서 트래픽 소비가 3-4.5 GB로 증가합니다. 이미지, 글꼴 및 외부 도메인 차단은 필요한 데이터를 유지하면서 이 격차를 3-5배 줄입니다.

대규모 파싱을 시작하기 전에 선택한 도구를 고려하여 예상되는 트래픽 양을 계산하고 이를 프록시 예산에 포함시키십시오. JavaScript 렌더링과 안티봇 시스템에 대한 내성이 필요한 경우, 주거용 프록시를 통해 소규모 페이지 세트에서 테스트 실행을 시작하십시오 — 이는 전체 데이터 세트에 대한 실제 GB 소비를 정확하게 평가할 수 있게 해줍니다.