보호된 사이트 스크래핑에 관한 대부분의 조언은 모든 기법을 한꺼번에 써야 하는 것처럼 읽힌다. 헤드리스 브라우저, 스푸핑된 핑거프린트, 행동 패턴 조절까지 전부 말이다. 하지만 그럴 필요는 없으며, 기본값으로 모든 것을 동원하는 것 자체가 하나의 실수다. 어떤 대상은 평범한 GET 요청도 아무 문제 없이 처리하지만, 어떤 대상은 페이지가 로드되기도 전에 스크립팅 라이브러리를 차단한다. 높은 성공률과 차단 더미 및 낭비된 컴퓨팅 자원을 가르는 능력은 하나의 영리한 트릭을 아는 것이 아니라 보정(calibration)이다. 즉, 주어진 대상을 안정적으로 통과시키는 가장 덜 정교한 방법을 사용하고, 사이트가 강제할 때만 단계를 올리는 것이다.
이를 사다리라고 생각해보자. 각 단은 더 강력한 방어 계층을 물리치며, 그만큼 운영 비용도 늘어난다. 이것이 개별 기법들, 즉 일반 클라이언트, TLS 위장, 실제 브라우저, 완전한 스텔스를 하나의 판단 기준으로 엮는 지도다. 이 대상이 실제로 필요로 하는 단은 무엇인가?
왜 보정이 최대 노력을 이기는가
두 가지 실패 유형이 이 문제를 양쪽에서 규정한다. 과소 엔지니어링은 명백한 쪽이다. 강력하게 방어된 사이트를 requests로 공격하면 즉시 차단되고, 아무리 재시도해도 소용없다. 과잉 엔지니어링은 더 조용하지만 더 흔한 낭비다. 단순한 HTTP 호출로 충분히 응답했을 사이트를 상대로 관리형 핑거프린트를 갖춘 전체 브라우저 함대를 운영하는 것이다. 이는 처리량, 대역폭, 인프라, 안정성을 잡아먹는다. 브라우저는 더 느리고 무거우며 고장날 요소가 훨씬 많은데, 이 모든 것이 대상이 애초에 제기하지도 않은 문제를 풀기 위한 것이다.
올바른 자세는 저렴하게 시작해 증거에 따라 단계를 올리는 것이다. 작동하는 가장 낮은 단을 사용하고, 대상의 실제 응답이 언제 올라가야 하는지 알려주게 하며, 사이트가 쉬워지면 다시 내려온다. 노력은 상상한 최악의 시나리오가 아니라 실제로 마주치는 방어 수준을 따라가야 한다.
0단: 일반 HTTP 클라이언트와 깨끗한 레지덴셜 IP
이것으로 웹의 대부분을 처리할 수 있다. 견고한 HTTP 클라이언트, requests, httpx, 또는 사용 언어의 동등한 도구를 깨끗한 레지덴셜 IP를 통해 사용하면, 주된 방어가 IP 평판과 기본적인 요청 정상성 검사뿐인 사이트는 모두 통과할 수 있다. 여기에 평범해 보이게 만드는 위생 관리를 더한다. 현실적인 헤더, 호스트별 합리적인 속도, 429에 대한 백오프, 책임 있는 스크래핑 기본 원칙 등이다.
이 단에서 가장 큰 지렛대는 IP 평판이다. 깨끗한 레지덴셜 주소는 데이터센터 트래픽을 즉시 막아버리는 평판 검사를 통과시켜주며, 그래서 많은 “보호된” 사이트들이 실제로는 이 정도만 있으면 되는 경우가 많은 이유다. 모든 대상에 대해 여기서 시작하라. 가장 빠르고 저렴하며 안정적인 선택지이고, 종종 유일하게 필요한 단이다.
1단: TLS 위장 클라이언트
0단이 즉시 차단되고, 페이지가 로드되기도 전에 막히며, IP를 로테이션해도 도움이 되지 않을 때 이 단으로 올라간다. 이 패턴은 클라이언트 계층 차단을 가리킨다. 즉 여러분의 핸드셰이크가 핑거프린팅되고 있다는 뜻이다. TLS 및 HTTP/2 핑거프린팅에서 다뤘듯, 스크립팅 라이브러리의 TLS ClientHello와 HTTP/2 설정은 브라우저의 것과 전혀 다르며, 많은 안티봇 시스템이 이것만으로 연결을 거부한다.
해결책은 완전한 브라우저가 아니라, 실제 브라우저의 네트워크 핑거프린트를 제시하면서도 경량 HTTP 호출로 남아있는 TLS 위장 HTTP 클라이언트(curl_cffi, tls-client, utls 등)다. 이는 0단을 막았던 핑거프린팅을 물리치면서도 비용 증가는 작다. 브라우저로 뛰어넘기 전에 이것부터 시도하라. 브라우저의 오버헤드 없이 방어의 한 계층 전체를 통과할 수 있기 때문이다.
2단: 실제 헤드리스 브라우저
콘텐츠가 JavaScript로 렌더링되거나, 상호작용 뒤에 잠겨 있거나, 대상이 네트워크 계층을 넘어서 핑거프린팅할 때 이 단으로 올라간다. 실제 브라우저, Playwright, Puppeteer, 또는 Selenium은 페이지의 JavaScript를 실행하며, 정의상 실제 브라우저의 TLS, HTTP/2, DOM을 갖는다. 이는 일반 클라이언트나 위장 클라이언트가 도저히 처리할 수 없는 사이트를 다루는데, 스크립트를 실행하지 않고는 페이지 자체가 존재하지 않기 때문이다.
비용은 실제로 크다. 브라우저는 HTTP 호출에 비해 메모리를 많이 잡아먹고 느리며, 이 단에서 처리량이 떨어지고 인프라가 커진다. 필요 없는 리소스를 차단함으로써(이미지, 폰트, 미디어) 그리고 요청마다 브라우저를 새로 실행하는 대신 하나의 오래 지속되는 브라우저 인스턴스를 재사용함으로써 비용을 완화하라. 사이트가 “중요하다”는 이유만으로 여기까지 올라가지 마라. 렌더링된 페이지 없이는 데이터가 진짜로 존재하지 않기 때문에 올라가는 것이어야 한다.
3단: 핑거프린트 및 행동 스텔스를 갖춘 브라우저
최상위 단은 가장 어려운 대상, 즉 평범한 헤드리스 브라우저조차 플래그를 다는 대상을 위한 것이다. 이 수준에서 사이트는 디바이스 핑거프린트(헤드리스 흔적, canvas, navigator 특이점)와 행동(마우스 움직임, 타이밍, 상호작용 패턴)을 면밀히 조사한다. 이를 통과하려면 안티디텍트 브라우저가 하는 방식으로 핑거프린트를 관리해야 한다. 즉 각 아이덴티티에 일관되고 뚜렷한 프로필을 부여하고, 상호작용 속도를 즉각적이지 않고 인간처럼 보이게 조절해야 한다. 탐지를 유발하는 실수들은 모두 이 단에 속한다.
이는 가장 비싸고 가장 취약한 선택지이며, 바로 그렇기 때문에 기본값이 아니라 최후의 수단이어야 한다. 대부분의 스크래핑은 이것을 전혀 필요로 하지 않는다. 대상이 진짜로 이것을 필요로 할 때는, 더 저렴한 모든 단을 시도했고 증거로 실패가 확인되었기 때문이다.
모든 단에서 변하지 않는 것: IP
사다리는 클라이언트 정교함에 관한 것이지만, 단계를 올라가도 변하지 않는 한 가지가 있다. 모든 단에는 여전히 그 아래에 깨끗한 레지덴셜 IP가 필요하다는 것이다. 플래그가 걸리거나 데이터센터 주소에서 나오는 완벽한 브라우저 핑거프린트는, 그 위의 모든 것이 아무리 설득력 있어도 네트워크 계층에서 잡힌다. 그리고 세션 일관성도 모든 수준에서 중요하다. 하나의 일관된 방문자처럼 보여야 하는 모든 것에 대한 고정 세션, 그리고 로그인 뒤에 있을 때의 인증 세션 규율이다. IP와 세션은 사다리 전체가 서 있는 토대이며, 각 단은 그 위에 얼마나 많은 클라이언트 정교함을 얹을지만 결정할 뿐이다.
올라가는 법: 실패가 알려주게 하라
사다리의 핵심은 여러분의 단을 추측하지 않고 진단한다는 것이다. 실패를 올바르게 읽으면 정확히 어디에서 막혔는지 알려주기 때문이다.
- 즉시 차단되고 IP 로테이션은 아무것도 바꾸지 못하지만 TLS 위장 클라이언트는 작동한다: 클라이언트 핑거프린트 계층에 있었던 것이다. 1단.
- 요청은 성공하지만 콘텐츠가 없거나 비어 있다. JavaScript로 렌더링되기 때문이다: 실제 브라우저가 필요하다. 2단.
- 브라우저가 처음엔 작동하지만 시간이 지나면서 챌린지를 받거나 플래그가 걸린다: 디바이스 핑거프린트나 행동이 여러분을 드러낸 것이다. 3단.
- 대부분 작동하고 일부 IP만 챌린지를 받는다: 이는 단의 문제가 전혀 아니라 IP 평판 문제다. 풀을 고쳐라, 단계를 올리지 마라.
그 증거를 바탕으로 단계를 올리되, 내려가기도 하라. 대상이 완화되면 더 저렴한 단으로 돌아가 처리량을 되찾아라. 이것이 바로 대상별 모니터링이 중요한 이유다. 어떤 대상이 까다로워지고 있고 어떤 대상이 쉬워졌는지 알려주므로, 노력이 가정이 아니라 현실을 따라가게 된다.
프로젝트별이 아니라 대상별로 단을 배정하라
마지막 원칙이 가장 많은 비용을 절약해준다. 단은 파이프라인별이 아니라 대상별이다. 크롤링이 백 개의 사이트를 건드릴 때, 그중 95개는 0단에서 만족하고 5개만 브라우저가 필요할 수 있다. 그 5개를 위해 전체 크롤링을 2단으로 운영하는 것은 나머지 95개에 크고 불필요한 세금을 물리는 것이다. 잘 구축된 파이프라인은 대상별로 단을 기록하고, 새 대상은 기본적으로 0단으로 설정하며, 특정 대상이 실패할 때만 단을 올린다. 이상적으로는 자동으로 말이다. 그 결과는 최고의 성공률 대 비용 비율이다. 각 대상이 안정적으로 통과하는 가장 저렴한 단에서 처리되며, 과잉 구축된 것은 없다.
결론
강력하게 보호된 사이트를 스크래핑하는 것은 하나의 기법이 아니라 사다리이며, 승리하는 팀은 모든 것을 최대 스텔스로 운영하는 팀이 아니다. 각 대상에 노력을 맞추는 팀이다. 0단, 즉 일반 클라이언트와 깨끗한 레지덴셜 IP로 시작하고, TLS 위장 클라이언트로 올라가고, 그다음 실제 브라우저로, 그다음 완전한 스텔스로 대상 자체의 응답이 각 단계를 강제할 때만 올라가며, 그 아래에서는 깨끗한 IP와 일관된 세션을 변함없는 토대로 유지한다. 실패로부터 단을 진단하고, 대상별로 단을 배정하며, 사이트가 쉬워지면 단계를 내려라.
이렇게 하면 성공률은 올라가고 비용은 내려간다. HTTP 문제에 브라우저 가격을 지불하는 것을 멈추기 때문이다. 모든 단의 기반이 되는 레지덴셜 프록시는 기가바이트당 가격이 매겨지므로, 사다리가 보상하는 규율 있고 보정된 접근법이야말로 가장 비용이 적게 드는 접근법이기도 하다.