스크래핑을 위한 프록시 선택은 사실 프록시에 관한 문제가 아니라 대상에 관한 문제입니다. 방어 수단이 없는 사이트와 DataDome 뒤에 있는 사이트는 완전히 다른 설정이 필요하며, 전자에 레지덴셜 요금을 지불하는 것은 돈을 낭비하는 것이고 후자에 데이터센터 IP를 사용하는 것은 시간을 낭비하는 것입니다.
이 가이드는 어떤 프록시 유형이 어떤 스크래핑 작업에 적합한지, 차단되지 않고 프록시를 운영하는 방법, 그리고 스크래핑 API가 원시 프록시보다 더 나은 답이 되는 경우를 다룹니다.
The Four Types, for Scraping
| Type | IP source | Speed | Block rate | Cost | Best-fit scraping job |
|---|---|---|---|---|---|
| Datacenter | 호스팅 제공업체 | 가장 높음 | 방어된 사이트에서 높음 | 가장 낮음 | 보호되지 않은 사이트, API, 대량 수집 |
| Residential | 일반 ISP, 실제 가정 | 보통 | 낮음 | 중간, GB당 | 리테일, 여행, 검색, 방어되는 모든 대상 |
| ISP | 일반 ISP, 데이터센터에서 호스팅 | 높음 | 낮음에서 보통 | IP당 월 단위 | 로그인 세션, 장기 실행 작업 |
| Mobile | 이동통신사 | 보통에서 낮음 | 가장 낮음 | 가장 높음 | 가장 어려운 대상, 앱 API |
짚어둘 만한 정정 사항이 있습니다. 반대되는 내용이 널리 알려져 있고 이 글도 이전에는 이를 그대로 반복했기 때문입니다: 데이터센터 IP는 ISP를 통해 전달되지 않습니다. 이들은 호스팅 및 클라우드 제공업체에 등록되어 있으며, 일반 인터넷 제공업체를 전혀 거치지 않습니다. 바로 이 때문에 식별이 가능합니다: 해당 대역이 공개되어 있어 사이트가 즉시 분류할 수 있습니다.
ISP 프록시와 모바일 프록시는 둘 다 스크래핑에서 중요하지만, 이런 비교에서는 보통 제외됩니다. ISP 프록시는 스크래핑 대상에 로그인이 필요한 경우 정답이 됩니다. 주소가 그대로 유지되기 때문입니다. 모바일 프록시는 다른 모든 방법이 실패하는 대상에 대한 최후의 수단입니다.
Rotation and Session Handling
차단을 피하는 데는 프록시 유형보다 로테이션 전략이 더 중요합니다.
요청별 로테이션은 매 요청마다 새로운 IP를 제공합니다. 상품 목록, 검색 결과, 디렉터리 항목처럼 독립적인 페이지를 수집할 때 기본으로 사용하기 적합한 방식입니다. 단일 주소가 의심스러운 패턴을 축적하지 않습니다.
스티키 세션은 보통 1분에서 30분 사이의 정해진 기간 동안 하나의 IP를 유지합니다. 요청들이 서로 의존하는 경우, 즉 커서를 유지하는 페이지네이션, 로그인 이후의 모든 작업, 다단계 결제 흐름 등에 사용합니다. 세션 중간에 IP가 바뀌면 계정 도용처럼 보여 챌린지를 받게 됩니다.
실용적인 규칙은 다음과 같습니다: 흐름상 연속성이 필요하지 않다면 요청마다 로테이션하고, 필요하다면 그것을 충족하는 가장 짧은 스티키 윈도우를 유지하십시오.
Request Rate and Concurrency
대부분의 차단은 프록시 유형이 아니라 속도 때문에 발생합니다. 초당 20번씩 사이트에 요청하는 레지덴셜 IP는 10초에 한 번 요청하는 데이터센터 IP보다 훨씬 명백하게 자동화된 것으로 보입니다.
- IP당 속도. 방어되는 사이트에서는 각 주소가 대략 2초에서 5초에 한 번 요청하도록 유지하십시오. 보호되지 않은 사이트에서는 훨씬 더 공격적으로 진행할 수 있습니다.
- 동시성. 전체 처리량은 동시에 사용되는 주소 수에 IP당 속도를 곱한 값입니다. 초당 10개의 요청을 안전하게 얻으려면 10개의 주소를 세 배 빠르게 돌리는 것이 아니라 30개에서 50개 정도의 주소를 동시에 사용해야 합니다.
- 무작위화. 고정된 간격은 그 자체로 하나의 시그니처가 됩니다. 지터를 추가해 간격을 변화시키십시오.
- 실패 시 백오프. 오류율이 상승하면 더 강하게 재시도하기보다 속도를 늦추십시오. 차단 상태에서 재시도를 계속하면 소프트 레이트 리밋이 하드 밴으로 바뀌게 됩니다.
Headers and Fingerprints
IP는 문 앞까지 데려다줄 뿐입니다. 문에 도착한 이후에는 요청 자체가 정상적으로 보여야 합니다.
- 완전하고 일관된 헤더 세트를 전송하십시오. 실제 브라우저는
Accept,Accept-Language,Accept-Encoding,User-Agent,Sec-Ch-Ua를 일관된 조합으로 전송합니다. 다른 요소 없이User-Agent만 있는 요청은 강력한 봇 신호입니다. - 헤더 정보를 IP와 일치시키십시오. 독일 IP가
Accept-Language: en-US를 전송하는 것은 지역 타겟팅을 할 때 피해야 할 불일치입니다. - TLS 및 HTTP 동작을 자처하는 클라이언트에 맞추십시오. 고급 시스템은 TLS 핸드셰이크와 HTTP/2 프레임 순서까지 핑거프린팅하므로, Chrome이라고 주장하는 Python 클라이언트는 헤더와 무관하게 탐지될 수 있습니다.
- 페이지가 필요로 할 때는 실제 브라우저를 사용하십시오. JavaScript로 콘텐츠를 렌더링하는 사이트는 헤드리스 브라우저가 필요하며, 헤드리스 브라우저는 그 자체로 관리해야 할 고유한 핑거프린트를 가지고 있습니다.
Modern Anti-Bot Systems
Cloudflare, DataDome, PerimeterX, Akamai는 단순한 IP 차단 목록이 아닙니다. 이들은 주소 신뢰도, 요청 핑거프린트, 행동, JavaScript 챌린지 결과를 조합해 점수를 매깁니다.
여기에는 두 가지 결론이 따릅니다. IP를 로테이션하는 것만으로는 이를 뚫을 수 없습니다. 핑거프린트가 그대로이기 때문입니다. 그리고 레지덴셜 IP는 필요하지만 충분하지 않습니다: 가장 쉬운 신호를 제거할 뿐, 더 어려운 신호들은 그대로 남습니다.
차단에 부딪혔을 때:
- 응답을 제대로 확인하십시오. 챌린지 페이지가 포함된 403은 429 레이트 리밋과는 다르며, 서로 다른 해결책이 필요합니다. 상태 코드만이 아니라 본문 내용을 확인하십시오.
- 먼저 속도를 줄이십시오. 속도는 가장 저렴하게 바꿀 수 있는 요소이며, 실제 원인인 경우가 많습니다.
- 신뢰도 단계를 한 단계 올리십시오. 데이터센터에서 레지덴셜로, 레지덴셜에서 모바일로.
- 챌린지를 렌더링하십시오. 사이트가 JavaScript 실행을 요구한다면, 어떤 IP를 사용하든 일반 HTTP 클라이언트로는 절대 통과할 수 없습니다.
- 접근 방식을 재고하십시오. 대상 사이트에서 재시도에 드는 비용이 데이터의 가치보다 크다면, 계속 맞서기보다 관리형 API를 사용하는 것이 더 저렴합니다.
Cost, Volume and When to Use an API
프로젝트를 추정할 때는 페이지 용량에서 시작합니다. 일반적인 HTML 페이지는 0.5MB에서 2MB이므로, 100,000개 페이지는 대략 50GB에서 200GB에 해당합니다. JavaScript를 렌더링하면 스크립트, 스타일, 이미지까지 함께 가져오기 때문에 이 값이 몇 배로 늘어납니다.
실제로 비용을 결정하는 숫자는 차단율입니다. 요청의 40%가 실패해서 재시도하는 설정은 그 대역폭을 두 번 지불하는 셈입니다. 실패율이 높은 저가 프록시는 성공한 페이지당 비용이 비싼 프록시보다 더 높은 경우가 많습니다.
원시 프록시는 스크래퍼를 직접 제어하고, 대상을 잘 이해하고 있으며, 단위당 비용을 최소화하고 싶을 때 적합한 선택입니다. 관리형 API는 대상이 강하게 저항할 때, 그렇지 않으면 브라우저 핑거프린트와 챌린지 솔버를 직접 유지보수해야 할 때, 또는 자금보다 엔지니어링 시간이 더 부족한 자원일 때 더 나은 선택입니다.
Shifter의 웹 스크래핑 API는 단일 요청 뒤에서 프록시 로테이션, JavaScript 렌더링, 챌린지 처리를 모두 담당하며, SERP API는 검색 결과에 대해 특히 동일한 역할을 합니다. 검색 결과는 그렇지 않으면 유지보수하기 가장 까다로운 대상 중 하나입니다. 원시 프록시의 경우 레지덴셜 프록시와 ISP 프록시가 세션 문제의 양 극단을 다루며, 현재 요금은 가격 페이지에서 확인할 수 있습니다.
A Short Decision Framework
- 대상에 봇 방어가 없고 저렴하게 대량으로 처리해야 하는 경우: 데이터센터 프록시.
- 대상이 레이트 리밋이나 챌린지를 거는 경우, 로그인이 필요 없다면: 로테이팅 레지덴셜 프록시.
- 스크래핑에 로그인 세션이 필요하거나 하나의 신원을 유지해야 하는 경우: ISP 프록시.
- 레지덴셜 프록시로도 대상을 뚫을 수 없거나, 앱 수준의 접근이 필요한 경우: 모바일 프록시.
- 대상 유지보수 비용이 데이터의 가치보다 큰 경우: 스크래핑 API.
실제 대부분의 프로젝트는 이들을 혼합해서 사용합니다. 수집 작업은 로테이팅 레지덴셜로 실행하고, 소수의 인증이 필요한 대시보드는 ISP로 실행하며, 하나의 불가능한 대상은 API를 통해 처리합니다.
Conclusion
스크래핑을 위한 단 하나의 최고의 프록시는 없습니다. 대상이 얼마나 강하게 방어하는지에 맞춰 유형을 선택하고, 요청들이 서로 의존하는지에 맞춰 로테이션 방식을 선택하며, 차단이 발생했을 때 가장 먼저 조정해야 할 요소로 요청 속도를 다루십시오.