Cloudflare가 어제 세션 범위의 봇 탐지 기능을 출시했습니다
2026년 7월 13일, Cloudflare는 방문자가 랜딩하는 순간만이 아니라 세션 전체를 모니터링하는 지속적 행동 기반 봇 탐지 엔진인 Precursor를 출시했습니다. 기존 Turnstile 챌린지는 로그인, 가입, 결제 단계에서 하루에 약 30억 번 실행됩니다. Precursor는 이러한 동일한 클라이언트 측 가시성을 그 사이의 모든 페이지로 확장합니다.
이러한 접근 방식의 변화는 중요합니다. Turnstile은 한 순간에 한 가지 질문만 던졌습니다. 이 방문자가 사람인가? Precursor는 모든 마우스 이동, 키 입력, 스크롤, 포커스 변경에 걸쳐 동일한 질문을 지속적으로 던지며, 그 결과를 세션을 따라다니는 실시간 봇 점수에 반영합니다.
이는 보도 자료에서 설명하는 것보다 더 큰 변화입니다.
이제 세션이 새로운 핑거프린트입니다
수년간 봇 탐지는 일시적인 방식으로 이루어졌습니다. 진입 시점에 한 번 확인한 뒤 일정 시간 방문자를 보증하는 cookie를 발급하는 식이었습니다. 비교적 최신인 유선 레벨 및 header 검사조차 request 단위의 이벤트였습니다. 첫 번째 검증을 통과하면 다음 검증 전까지는 대체로 문제가 없었습니다.
세션 범위의 행동 탐지는 이 패턴을 깨뜨립니다. Cloudflare의 출시 게시물에 따르면, 봇은 JavaScript를 실행하고 완전한 브라우저 환경을 사용하며 의심을 사지 않고 개별 챌린지를 완료할 수 있습니다. 여전히 복제하기 어려운 것은 시간이 지나도 일관되게 유지되는 인간의 행동입니다.
그들은 자동화가 마주치는 장벽으로 인간 입력의 물리적 특성을 꼽습니다. 인간의 마우스 움직임은 손목 축과 팔뚝 회전의 제한을 받는 호 형태를 띱니다. 체크박스를 보고 클릭하기까지 측정 가능한 지연 시간(인지 부하)이 발생합니다. 그리고 안정된 손이라도 생리학적 미세 떨림 주파수로 진동합니다. 반면 봇은 직선과 수학적으로 깔끔한 베지에 곡선을 만들어냅니다. 인간은 결코 도달할 수 없는 정밀도로 클릭합니다.
이러한 신호는 개별적으로 보면 미미하게 감지됩니다. 하지만 5분간의 세션 전체에 걸쳐 누적되면 그 차이는 뚜렷해집니다.
새로고침이 더 이상 해결책이 되지 않는 이유
request 단위 탐지 환경에서의 기존 방식은 단순했습니다. 세션 점수가 올라가면 페이지를 새로고침하고 신원을 교체한 뒤 다시 시작하는 것이었습니다. Precursor는 이 경로를 차단합니다.
Cloudflare는 명확히 밝힙니다. "세션 범위 적용이 중요한 이유는 봇이 페이지를 새로고침하거나 새 챌린지로 다시 시작해도 행동 시그니처를 초기화할 수 없기 때문입니다." 의심스러운 세션은 컨텍스트를 축적합니다. 봇 점수가 방문자를 계속 따라갑니다.
그러나 이 변화는 특정 중간 계층의 스크래퍼에 가장 큰 타격을 줍니다. 완전한 headless 기반의 request별 교체 모델은 이미 표준 검사에 밀리고 있었습니다. 새로운 소식은 아닙니다. 실제 사용자의 방문 시간만큼 단일 브라우저 신원을 유지하며 진정한 세션 인식을 갖춘 운영자들은 대체로 영향이 없습니다. Precursor가 제재하는 대상은 그 중간 영역입니다. 기본 설정의 Puppeteer나 Playwright를 실행하고, 각 URL을 독립적인 작업으로 처리하며, 깨끗해 보이기 위해 크롤링 사이에 새로고침을 수행하는 팀들입니다.
이러한 방식의 스크래핑은 일회성이기 때문에 비용이 적게 듭니다. Precursor는 일회성 방식을 유지하는 비용을 크게 높입니다.
에이전트 기반 스크래퍼에 미치는 영향
Precursor가 탐지하도록 명확히 설계된 두 번째 대상이 있습니다. 바로 에이전트 기반 AI 스크래퍼입니다. Cloudflare는 부제목에서 이를 명시하고 있습니다: 연속적인 클라이언트 측 신호를 통한 에이전트 동작 탐지.
자율 브라우징 에이전트(작업을 계획하고 단계별로 실행하는 LLM 기반 방식)는 짧고 단호하게 급증하는 패턴으로 움직이는 경향이 있습니다. 이동, 추출, 이동, 추출 순입니다. 개별 작업만 보면 실제 방문자가 할 법한 동작처럼 보입니다. 하지만 체류 시간, 읽기 위한 스크롤 패턴, 미세한 보정 동작, 마우스 타깃 오버슛 등이 전혀 없습니다. 세션 전체를 놓고 보면, 이러한 부재는 조작된 마우스 떨림만큼이나 명확히 드러납니다.
따라서 사고와 스크래핑을 동시에 수행하는 에이전트를 구축하고 있다면, 이제 실질적인 리소스 비용 부담이 발생합니다. Cloudflare 블로그는 Precursor가 "전체 세션을 시뮬레이션하도록 요구함으로써 자동화 운영 비용을 높입니다. 이는 구축하기가 훨씬 더 어렵고, 유지 관리 비용이 더 많이 들며, 대규모로 운영할 때 안정성이 훨씬 떨어집니다"라고 언급합니다.
그것이 설계 목표의 전부입니다. 자동화를 불가능하게 만드는 것이 아니라, 경제성을 없애는 것입니다.
데이터 팀에 미치는 영향
세 가지 변화가 발생하며, 어느 것 하나 비용이 적게 들지 않습니다.
첫째, 세션 예산이 request 예산을 대체합니다. Cloudflare로 보호되는 대상을 위한 용량을 계획하고 있다면, 초당 request 수(RPS) 대신 시간당 세션 수로 사고를 전환해야 합니다. 즉, 독립적이고 연속적으로 보이는 사용자 여정을 몇 개나 유지할 수 있는지, 그리고 각 여정의 지속 시간은 얼마인지 고려해야 합니다. 짧게 끊어지는 버스트는 Precursor가 정확히 포착하도록 튜닝된 시그니처입니다. 당사가 5월에 작성했던 proxy 계산 방식에 대한 재고 역시 여기에 적용됩니다. proxy 풀 크기가 한계가 아니라, 세션의 현실성이 한계입니다.
둘째, 자체 구축(build) 대 외부 도입(buy) 계산에서 외부 도입 쪽으로 무게가 더 기울어집니다. request 단위 방어 시스템을 상대로 스크래퍼를 유지 관리하는 것은 일회성 연동과 가끔의 패치로 충분합니다. 하지만 세션 범위의 방어 시스템을 상대로 스크래퍼를 유지 관리하는 것은 지속적인 행동 R&D를 의미합니다. 페이싱 모델, 커서 이동 경로, 체류 시간 분포, 그리고 이 모든 것에 대한 테스트 커버리지를 유지하는 체계가 필요합니다. 웹 데이터 수집 외주화를 고민 중이었다면, 이로 인해 자체 구축에 대한 수지타산은 더 악화됩니다.
셋째, Precursor를 대규모로 먼저 배포하는 곳이 업계의 새로운 탐지 기준을 정립하게 됩니다. Cloudflare는 웹의 약 20%를 보호합니다. 전자상거래 및 금융 고객이 다음 분기에 Precursor를 공격적으로 활성화한다면, 방어 생태계는 효과적인 방식을 주시하고 빠르게 모방하므로 Precursor를 직접 설치하지 않는 사이트를 포함하여 다른 모든 곳의 스크래핑 스택도 그 영향을 받게 됩니다.
아무도 언급하지 않는 타임스케일의 변화
당사는 3개월 전에 행동 기반 탐지로의 전환에 대해 다룬 바 있습니다. Precursor는 이러한 트렌드가 제품화된 형태이며, 측정 윈도우의 기준점을 새롭게 재설정합니다.
과거의 봇 탐지는 단일 request 단위로 이루어졌습니다. 이제는 몇 분, 때로는 그 이상 지속되는 세션 전체에 걸쳐 수행됩니다. 탐지 단위가 단일 호출이던 시절에 작성된 모든 스크래핑 전술은 이 단 하나의 변화로 인해 영향을 받습니다. 5분간의 상호작용 전반에 걸친 행동 일관성이 손실 함수가 된다면, 프록시 교체, header 퍼징, 초 단위 request 조절은 모두 무의미해집니다.
핵심은 봇 탐지가 계속 진화하는지의 여부가 아닙니다. 그것은 기정사실입니다. 방어자가 세션 단위로 사고할 때, 사용자의 데이터 수집 스택이 여전히 request 단위로 사고하고 있는지가 문제입니다.