차단당하지 않고 대규모로 웹 데이터를 수집하는 방법

소개

스크레이퍼는 수백 개의 페이지에서는 잘 작동합니다. 하지만 수십만 개의 페이지를 대상으로 하면 요청의 절반이 403 오류, CAPTCHA, 또는 빈 페이지로 돌아옵니다. 파서가 실패한 것이 아닙니다. 대상 사이트가 여러분의 트래픽이 사람의 행동 패턴과 다르다는 것을 감지하고 대응하기 시작한 것입니다.

대규모 스크래핑은 주로 눈에 띄지 않는 것이 관건입니다. 스크래핑할 가치가 있는 사이트라면 어떤 형태로든 봇 탐지 기능을 운영하고 있으며, 요청이 하나 더 늘어날 때마다 차단될 가능성이 높아집니다. 이를 극복하려면 기본을 철저히 지켜야 합니다. 적절한 웹 스크래핑 프록시, 합리적인 요청 속도 조절, 실제 브라우저로 위장한 요청, 그리고 사이트가 대응해 올 때를 대비한 계획이 필요합니다. 이 글에서는 차단이 실제로 어떻게 발생하는지, 그리고 모든 경보를 울리지 않으면서 지속적으로 데이터를 수집할 수 있는 파이프라인을 구축하는 방법을 설명합니다.

사이트가 자동화된 데이터 수집을 차단하는 이유

웹사이트들이 스크레이퍼를 차단하는 것은 단순히 까다롭게 굴기 위해서가 아닙니다. 여러분의 트래픽이 그들에게 비용을 발생시키고, 그들이 숨기고 싶어 하는 데이터를 유출시키기 때문입니다. 공격적인 스크레이퍼 한 대는 분당 수천 건의 요청을 보내 서버에 부담을 주고 분석 데이터를 왜곡할 수 있습니다. 가격, 상품 목록, 리뷰는 경쟁사가 가장 원하는 정보이므로, 해당 데이터를 보유한 웹사이트들은 이를 가장 강력하게 방어합니다. 대상 사이트가 이미 여러분과 같은 사용자를 대비해 계획을 세워 놓았다고 가정하십시오.

차단 시스템의 판단 방식

차단은 거의 단일 규칙으로 이루어지지 않습니다. 대부분의 방어 시스템은 각 방문자에 대해 누적 점수를 관리하며, 허용 한도를 넘으면 CAPTCHA가 표시되거나 접근이 차단됩니다. 이 점수는 세 가지 질문에 대한 답을 제공합니다: 당신이 누구인지, 얼마나 빠르게 움직이는지, 그리고 자세히 보면 어떤 모습인지입니다.

‘누구인지’는 IP 평판입니다. 알려진 데이터센터 범위이거나 이전에 문제가 있었던 주소라면 처음부터 불이익을 받게 됩니다. ‘얼마나 빠르게 움직이는지’는 요청 빈도입니다. ‘가까이서 보면 어떤 모습인지’는 지문, 즉 전송하는 헤더와 TLS 핸드셰이크로, 실제 브라우저인지 단순한 스크립트인지 드러냅니다.

Cloudflare와 Akamai는 이 세 가지 요소를 모두 통합하여 요청당 실시간 점수를 산출합니다. 이것이 바로 동일한 코드를 실행하더라도, 한 스크레이퍼는 소규모 사이트에서는 매끄럽게 통과하는 반면, 보안이 강화된 사이트에서는 벽에 부딪히는 이유입니다.

확장을 위한 프록시 풀 구축

단일 IP로는 대규모 작업을 감당할 수 없으므로, 자신의 상황을 먼저 파악해야 합니다. 하나의 주소에서 10만 건의 요청을 보내면 평판 검사에서 금방 걸리게 됩니다. 풀을 활용하면 부하를 여러 IP에 분산시켜 어느 하나도 눈에 띄지 않게 할 수 있으며, 이는 모든 대규모 데이터 수집 환경의 기반이 됩니다. 여기서 선택하는 웹 스크래핑 프록시는 하류 모든 과정의 상한선을 결정합니다.

보호가 취약하거나 아예 없는 사이트에서는 데이터센터 IP가 주된 역할을 담당합니다. 저렴하고 빠르며 대량으로 확보할 수 있기 때문입니다. 대량 작업의 경우, 하루 만에 소진되는 소수의 공유 주소보다는 대용량 데이터 수집을 위해 설계된 데이터센터 IP를 사용해야 합니다. 단점은 쉽게 탐지된다는 점입니다. TorchProxies(2026)에 따르면, 데이터센터 프록시는 보호되지 않은 대상에서는 60~90%의 성공률을 보이지만, Cloudflare나 Akamai의 봇 관리 시스템이 적용된 곳에서는 20~40%로 떨어집니다.

규모 산정은 간단한 산술 문제입니다. 사이트가 IP당 분당 약 10건의 요청을 허용하고 6,000건이 필요하다면, 최소 600개의 정상 IP가 필요하며, 여기에 차단될 수 있는 IP를 대비한 여유분도 고려해야 합니다.

요청 페이싱 및 로테이션 로직

다음은 처리 속도입니다. 로테이션은 각 요청을 처리할 IP를 결정하고, 페이싱은 요청 간의 간격을 결정합니다.

요청별 로테이션은 모든 호출에 새로운 IP를 할당하므로, 개별 상품 페이지와 같은 상태 비저장 작업에 적합합니다. 스티키 세션은 관련 요청이 이어지는 동안 하나의 IP를 유지하며, 결제 과정처럼 사이트에서 세션을 추적할 때 필요합니다.

요청 간격 조절은 크롤링 시 차단 상황을 피할 수 있는지, 아니면 곧바로 차단에 걸리게 될지를 결정합니다. 요청 간 지연 시간을 무작위로 설정하세요. 일정한 200ms 간격 자체만으로도 봇 신호로 인식될 수 있기 때문입니다. IP당 요청 속도를 제한하고 지수적 백오프(exponential backoff)를 적용하여, 오류 발생 시 강행하기보다는 속도를 늦추도록 하세요. 위 차트는 그 이유를 보여줍니다: 차단률은 대상의 허용 한도를 넘을 때까지 0에 가깝게 유지되다가, 그 이후 급격히 치솟습니다. Ranktracker의 SEO 도구를 위한 웹 스크래핑 가이드에서는 동일한 페이싱 방식이 순위 추적기의 정확성을 유지하는 방법을 설명합니다.

헤더와 지문

마지막으로 고려해야 할 점은 요청의 외관입니다. 깨끗한 IP를 사용하고 요청 속도를 적절히 조절하더라도, 요청 자체가 스크립트임을 드러내면 여전히 탐지될 수 있습니다. 모든 요청에는 헤더와 TLS 지문이 포함되며, 탐지 시스템은 이 두 가지를 실제 브라우저와 비교합니다.

User-Agent부터 시작하되, 거기서 멈추지 마세요. 실제 브라우저는 Accept, Accept-Language, Accept-Encoding 헤더를 일관된 순서로 일치하는 세트로 전송하며, 이를 생략하거나 순서를 뒤섞은 요청은 눈에 띕니다. 그 밑에는 JA3 지문으로 요약되는 TLS 핸드셰이크가 자리 잡고 있습니다. Python 클라이언트와 Chrome은 표시되는 헤더가 일치하더라도 핸드셰이크 방식이 다르기 때문에, 강력한 봇 방지 시스템은 핸드셰이크를 분석하여 표면적으로만 위장한 스크레이퍼를 잡아냅니다. 각 요청이 처음부터 끝까지 브라우저처럼 보이도록 만들어야 합니다.

CAPTCHA 및 소프트 차단 처리

모든 차단이 깃발을 흔드는 것은 아닙니다. 하드 차단은 CAPTCHA 화면이나 403 오류처럼 명백합니다. 소프트 차단은 숨어 있습니다. 사이트는 200 응답을 반환하지만, 본문은 제한되거나 내용이 얇아지거나, 사용자에게 알리지 않고 데이터셋을 훼손하기 위한 잘못된 데이터가 섞여 있습니다.

탐지가 최우선 과제입니다. 의심스러울 정도로 용량이 작거나, 서로 달라야 할 페이지 간에 동일한 응답은 플래그를 지정하고, 상태 코드가 성공으로 표시되더라도 실패로 처리하십시오. 잘못된 입력은 이를 기반으로 구축된 모든 것을 훼손하므로, 데이터 품질 검사는 접근 권한만큼이나 중요합니다. 정확한 순위 추적을 위한 Ranktracker의 가이드에서는 잡음이 많은 입력이 보고하는 수치를 어떻게 망가뜨리는지 보여줍니다.

CAPTCHA가 나타날 때 이를 해결해 주는 서비스가 존재하지만, 더 저렴한 해결책은 상류 단계에서 찾을 수 있습니다. 요청 속도를 늦추고, 더 자주 로테이션을 적용하며, 지문을 정리하면 CAPTCHA 도전을 받지 않게 됩니다.

언제 주거용(Residential)으로 전환해야 하는가

때로는 IP 계층 자체가 한계가 되기도 합니다. 트래픽의 속도를 얼마나 잘 조절하고 위장하든 봇 관리 시스템이 데이터센터 풀을 계속 차단한다면, 이는 상위 계층으로 이동해야 한다는 신호입니다.

주거용 IP는 실제 가정용 기기에서 제공되므로, 데이터센터 IP 범위에서는 결코 얻을 수 없는 신뢰도를 지닙니다. 해결하기 까다로운 대상의 경우, 순환형 주거용 IP로 전환하면 일반 가정용 사용자로 인식되는 트래픽을 생성하여, 데이터센터 주소를 즉시 차단하는 필터를 우회할 수 있습니다.

대가는 속도와 비용입니다. ProxyWing에 따르면, 데이터센터 프록시는 주거용 프록시보다 3~10배 더 빠르며, 데이터센터 프록시는 대략 200ms 미만인 반면 주거용 프록시는 500ms에서 2초가 소요됩니다. 수백만 건의 요청에 이르면 그 차이가 누적되므로 계층을 구분해 사용하세요. 데이터센터를 기본값으로 유지하고 차단된 요청만 주거용으로 라우팅하십시오.

검색 결과가 대표적인 사례입니다. Ranktracker의 SERP Checker와 같은 도구에 데이터를 공급하기 위해 SERP를 스크래핑할 때, 차단이 가장 심한 페이지들은 종종 주거용 IP로 연결되도록 유도합니다.

확장하기 전에 하나의 대상 사이트에서 테스트하세요

스크레이퍼를 전체 대상 목록에 적용하기 전에, 보호된 사이트 한 곳을 대상으로 테스트를 실행하고 응답 코드를 확인하세요. 소규모 데이터센터 풀로 시작하여 보수적인 속도로 진행한 다음, 차단이 발생할 때까지 속도를 점차 높였다가 마지막으로 차단되지 않았던 수준으로 되돌리세요. 이 수치가 IP당 상한선이 되며, 전체 작업에 필요한 풀의 규모를 결정합니다. 한 사이트에서 웹 스크래핑 프록시와 속도 조절을 제대로 설정하면, 동일한 설정을 나머지 사이트에도 확장 적용할 수 있습니다.

자주 묻는 질문

대규모 스크래핑을 하려면 프록시가 몇 개나 필요합니까?

대상 사이트의 허용 범위와 여러분의 처리량에 따라 다릅니다. 한 IP가 차단되기 전에 분당 몇 건의 요청을 견딜 수 있는지 파악하고, 목표 요청 속도를 그 수치로 나눈 뒤 여유분을 더하세요. IP당 10건을 허용하는 사이트에 분당 6,000건을 처리해야 한다면? 이는 소수의 IP를 과도하게 사용하는 것이 아니라 600개 이상의 정상적인 IP가 필요합니다.

웹 스크래핑에는 데이터센터 프록시와 주거용 프록시 중 어느 것이 더 좋을까요?

어느 쪽도 단연 우월하다고 할 수는 없습니다. 데이터센터 프록시는 더 빠르고 저렴하며, 보안이 취약한 사이트를 문제없이 처리합니다. 주거용 프록시는 속도가 느리고 비용은 더 비싸지만, 엄격한 봇 관리 정책에서도 잘 버텨냅니다. 대부분의 스크래핑 파이프라인은 두 가지 모두를 사용하며, 기본적으로 데이터센터 프록시를 사용하고 차단으로 인해 어쩔 수 없는 경우에만 주거용 프록시로 전환합니다.

프록시를 사용해도 왜 계속 차단되나요?

대개는 IP가 아니라 속도 제한이나 지문 인식 때문입니다. 대규모 프록시 풀을 순환시키더라도 기본 헤더를 사용해 기계 속도로 요청을 보내면 패턴이 여전히 드러납니다. 속도를 늦추고, 무작위화를 적용하며, 우선 브라우저처럼 보이도록 해야 합니다.

공개 데이터 스크래핑은 허용되나요?

이는 관할권과 사이트의 서비스 약관에 따라 달라지는 법적 회색 지대입니다. 공개적으로 볼 수 있는 데이터에만 국한하고, 가능한 경우 robots.txt를 준수하며, 개인 정보는 건드리지 말고, 대규모 상업적 데이터 수집을 진행하기 전에 법률 자문을 구하십시오.