공개된 페이지에서 잘 작동하는 스크레이퍼(Scraper)로 시작합니다. 그러다 누군가 에이전트(Agent)에게 로그인을 하고, 대시보드를 열고, 양식을 제출한 뒤, AJAX 업데이트 이후의 결과를 추출하라고 요청합니다. 갑자기 프록시 로테이션(Proxy rotation) 설정이 이상한 방식으로 실패하기 시작합니다. /login으로 다시 리다이렉트되거나, 두 번째 페이지 이후 403 에러가 발생하거나, 유효하지 않은 CSRF 토큰이 나타나거나, 로컬에서는 작동하지만 프로덕션(Production) 환경에서는 끊기는 세션이 발생합니다.

문제는 대개 프록시 자체에 있는 것이 아닙니다. 현대의 인증된 사이트들은 상태(State)를 쿠키(Cookie) 이상의 요소와 결합하기 때문입니다. 사이트들은 IP 주소, 브라우저 핑거프린트(Browser fingerprint), 시간대(Timezone), 로캘(Locale), localStorage, sessionStorage, 그리고 탐색 기록(Navigation history)을 연관 지을 수 있습니다. 모든 요청마다 IP를 로테이션하면, 한 가지 문제를 해결하는 대신 또 다른 문제를 만들게 됩니다.

프록시 로테이션과 브라우저 세션은 서로 다른 문제를 해결합니다

Oxylabs 및 Bright Data와 같이 프록시 중심적인 도구들은 대규모로 공개 페이지를 가져와야 할 때 적합합니다. 제품 목록, 공개 디렉토리, 뉴스 아카이브, SERP(검색 엔진 결과 페이지), 그리고 지역 제한이 걸린 정적 콘텐츠가 일반적인 예시입니다. 주거용 IP(Residential IPs)를 로테이션하면 트래픽을 분산하고 속도 제한(Rate limits)을 피하는 데 도움이 됩니다.

하지만 워크플로우가 연속성(Continuity)에 의존할 때는 해당 모델이 까다로워집니다.

단순화된 프록시 로테이션 스크레이핑은 다음과 같습니다:

const urls = [
  'https://example.com/account',
  'https://example.com/account/billing',
...

이는 첫 번째 요청이 성공하더라도 실패할 수 있습니다. 두 번째 요청은 일치하는 브라우저 컨텍스트(Browser context)가 없는 다른 IP에서 올 수 있기 때문입니다. 사이트는 한 세션의 쿠키, 다른 세션의 IP, 그리고 어느 쪽과도 일치하지 않을 수 있는 핑거프린트를 보게 됩니다. 흔한 증상으로는 401 Unauthorized, 403 Forbidden, 로그인 페이지로의 리다이렉트, 또는 페이지는 렌더링되지만 사용자 특정 데이터가 포함되지 않는 현상 등이 있습니다.

브라우저 네이티브(Browser-native) 플랫폼은 정반대의 접근 방식을 취합니다. 이들은 쿠키, localStorage, 헤더(Headers), 뷰포트(Viewport), 그리고 종종 시간대나 로캘을 포함하여 브라우저 컨텍스트를 활성 상태로 유지합니다. Browserbase, Browserless, Steel, Firecrawl 및 유사한 도구들이 이 범주에 속하며, 다만 이들은 서로 다른 수준의 제어권을 제공합니다.

Wire는 이러한 트레이드오프(tradeoff)에서 브라우저 세션(browser-session) 측면의 한 예시로, 인증된 추출(authenticated extraction)이 URL당 하나의 격리된 프록시 요청(proxy request)이 아닌 지속적인 세션(persistent sessions)과 작업 상태(job state)를 중심으로 모델링됩니다.

결정 기준은 벤더 카테고리가 아니라 상태(state)입니다

대부분의 경우 다음과 같은 간단한 규칙이 적용됩니다:

• 대상 데이터가 공개되어 있고 각 URL을 독립적으로 가져올 수 있다면 프록시 로테이션(proxy rotation)을 사용하세요.
• 워크플로우가 로그인을 수행하고, 양식을 제출하며, 다중 페이지 상태(multi-page state)를 따르거나, JavaScript로 렌더링된 데이터에 의존한다면 브라우저 세션(browser sessions)을 사용하세요.

비싼 실수는 세션 문제를 해결하기 위해 더 큰 프록시 풀(proxy pool)을 구매하는 것입니다. 사이트가 5단계에 걸쳐 동일한 브라우저 식별 정보(browser identity)를 기대한다면, 더 많은 IP는 도움이 되지 않습니다.

브라우저 세션 워크플로우의 형태는 다음과 같습니다:

import { chromium } from 'playwright'

const browser = await chromium.launch()
...

중요한 부분은 Playwright 자체가 아닙니다. 바로 지속된 컨텍스트(persisted context)입니다. 다음 실행 시 session.json을 로드하면 로그인 과정을 완전히 건너뛸 수 있는 경우가 많습니다:

const context = await browser.newContext({
  storageState: 'session.json',
  locale: 'en-US',
...

이 패턴에는 한계가 있습니다. 세션은 만료됩니다. 비밀번호 변경은 저장된 상태를 무효화합니다. 일부 사이트는 IP가 변경될 때마다 MFA(다요소 인증)를 요구합니다. 장시간 실행되는 브라우저 세션은 일반적인 HTTP 요청보다 더 많은 메모리를 소비하고 비용이 더 많이 듭니다. 수백 개의 세션을 동시에 실행하려면 큐잉(queueing), 타임아웃(timeouts), 정리(cleanup) 및 재시도 로직(retry logic)이 필요합니다.

비동기 작업 API는 블로킹 요청보다 브라우저 작업에 더 적합합니다

브라우저 작업은 HTML을 가져오는 것에 비해 느립니다. 페이지가 로드되고, JavaScript를 실행하며, 봇 체크(bot checks)를 통과하고, 데이터를 렌더링하는 데 5초에서 30초가 소요될 수 있습니다. 만약 API가 모든 작업이 완료될 때까지 블로킹(blocking)된다면, 워커(workers)는 대부분의 시간을 대기하는 데 소비하게 됩니다.

더 나은 패턴은 제출(submit), 폴링(poll), 결과 가져오기(fetch result)입니다:

async function submitJob(url: string) {
  const res = await fetch('https://scraper.example/jobs', {
    method: 'POST',
...

이를 통해 애플리케이션은 페이지 로드당 하나의 프로세스를 점유하지 않고도 많은 브라우저 작업(browser tasks)을 제출할 수 있습니다. 또한 captcha_required, login_expired, timeout 또는 blocked와 같은 실패 상태(failure states)를 처리할 수 있는 명확한 지점을 제공합니다.

Wire는 브라우저 기반 추출을 위해 이러한 작업 중심 모델(job-oriented model)을 사용하며, 이는 여러 개의 인증된 스크래핑 작업(scraping tasks)을 병렬로 실행하고 실패를 깔끔하게 보고해야 할 때 중요합니다.

일반적인 옵션들의 비교

IP 다양성이 주요 요구 사항일 때는 Oxylabs와 Bright Data가 적합합니다. Oxylabs는 대역폭 계층에 따라 주거용 프록시(residential proxy) 가격을 책정하며, 일부 플랜의 경우 50GB에 월 $300와 같은 예시가 있습니다. 이는 대량의 정적 스크래핑(static scraping)에는 합리적일 수 있지만, 임의의 브라우저 단계 전반에 걸쳐 로그인 상태를 유지하도록 설계되지는 않았습니다.

Browserbase는 관리형 Chromium 인프라에 더 가깝습니다. 이는 자체 브라우저 플릿(browser fleet)을 운영하지 않고도 Playwright 또는 Puppeteer 제어권을 원하는 팀에 적합합니다. 여전히 세션 저장소(session storage), 동시성(concurrency), 브라우저 분당 비용을 고려해야 합니다.

Firecrawl은 렌더링된 페이지로부터 깨끗한 마크다운(Markdown) 또는 구조화된 텍스트를 출력물로 얻고자 할 때 유용합니다. 이는 인증된 애플리케이션 상태를 클릭하며 통과해야 하는 워크플로우보다는 RAG 인입(ingestion)에 더 적합합니다.

Browserless는 자체 쿼리 계층과 브라우저 API를 갖춘 호스팅 브라우저 자동화(hosted browser automation)를 제공합니다. Steel은 오픈 소스 기반의 자체 호스팅 가능한 브라우저 인프라를 원하고 이를 운영할 수 있는 운영(ops) 역량이 있는 경우 흥미로운 선택지입니다.

이 카테고리 중 어느 하나가 보편적으로 더 나은 것은 아닙니다. 정적 스크래핑은 처리량(throughput)과 페이지당 낮은 비용을 원합니다. 인증된 에이전트 워크플로우(authenticated agent workflows)는 연속성(continuity)과 디버깅 가능한 상태(debuggable state)를 원합니다.

실질적인 선택 방법

가격 페이지를 비교하기 전에, 실제 워크플로우 하나를 분류해 보세요:

1. 모든 URL이 독립적으로 존재하나요, 아니면 3페이지가 1페이지의 상태(state)에 의존하나요?
2. 사이트가 로그인 정보를 IP, 기기, 로캘(locale), 또는 MFA(다요소 인증)와 결합하나요?
3. 로우 브라우저 제어(raw browser control)가 필요한가요, 아니면 추출된 텍스트와 필드만 있으면 되나요?
4. 허용 가능한 실패 모드(failure mode)는 무엇인가요: 재시도(retry), 수동 재인증(manual re-auth), 부분적 결과, 또는 완전한 실패(hard fail)?
5. 실제로 필요한 동시 브라우저 세션(concurrent browser sessions)은 몇 개인가요?

그런 다음, 동일한 워크플로우를 세 가지 방식(일반 HTTP, 회전 프록시(rotating proxies)를 통한 HTTP, 그리고 지속적인 브라우저 컨텍스트(persistent browser context))으로 실행하는 작은 테스트를 구축하세요. 상태 코드(status codes), 리다이렉트(redirects), 최종 URL, 추출된 필드 수, 실행 시간, 그리고 성공적인 결과당 비용을 기록하세요.

일반 HTTP가 작동한다면 그대로 유지하세요. 프록시 회전(proxy rotation)이 작동한다면 그것을 사용하세요. 만약 로그인 후 어느 방식이든 실패한다면, 프록시 설정을 조정하는 것을 멈추고 대신 지속적인 브라우저 세션(persistent browser sessions)을 테스트하세요.