핵심 변화: 봇과 사람을 구분하는 방식이 달라진다

Cloudflare가 제시한 핵심은 단순히 “봇은 차단하고 사람은 허용한다”는 이분법에서 벗어나는 것이다. 검색 엔진, 모니터링 도구, 자동화 에이전트처럼 사이트 운영에 도움이 되는 봇이 있는 반면, 사람도 사기나 악용 행위를 할 수 있다. 여기에 사용자가 직접 탐색하다가 구매나 예약 같은 일부 과정을 에이전트에게 넘기는 혼합형 세션까지 등장하면서, 접속 주체의 정체만으로 트래픽을 판단하기가 어려워졌다.

따라서 개발자가 확인해야 할 대상은 “사람인가, 봇인가”만이 아니다. 해당 방문자가 자신의 정체와 목적을 투명하게 밝히는지, 세션 도중 어떤 행동을 하는지, 이미 얻은 신뢰를 악용하지 않는지를 함께 봐야 한다. Cloudflare는 이를 일회성 위험 평가에서 지속적인 신뢰 평가로의 전환으로 설명한다.

위험과 신뢰는 같은 축의 반대말이 아니다

Cloudflare의 설명에서 위험과 신뢰는 서로 독립적이지만 상호 보완적인 값이다. 위험은 특정 요청이나 행동이 해로울 가능성을 뜻하며, 순간적인 상황에 따라 크게 달라질 수 있다. 반면 신뢰는 과거와 현재의 행동, 평판, 투명성을 바탕으로 시간에 걸쳐 축적된다.

예를 들어 늦은 밤 누군가가 초인종을 여러 번 누르는 행동만 보면 위험 신호로 볼 수 있다. 하지만 문 앞에 있는 사람이 오랫동안 알고 지낸 이웃이라면 대응은 달라진다. 웹 트래픽도 마찬가지다. “짧은 시간에 요청을 몇 번 보냈는가”라는 규칙만으로는 요청의 맥락과 관계를 충분히 설명할 수 없다.

이 관점은 보안 정책을 작성하는 방식에도 영향을 준다. 고정 임계치를 넘은 요청을 일괄 차단하는 규칙은 여전히 필요할 수 있지만, 그것만으로 정상 자동화와 악성 자동화를 안정적으로 구분하기는 어렵다. 앞으로는 요청 한 건의 점수뿐 아니라 세션 전체의 변화, 알려진 운영자 정보, 이전 행동과의 일관성을 함께 검토해야 한다.

좋은 에이전트의 기준은 투명성과 일관성

Cloudflare는 BotBase에서 확인할 수 있는 검증된 봇과 에이전트를 좋은 행동의 대표 사례로 제시한다. 여기서 검증의 기준은 크게 두 가지다. 운영자가 자신이 누구인지 정직하게 선언하고, 그렇게 얻은 신뢰를 악용하지 않아야 한다.

투명한 선언은 사이트 운영자와 자동화 도구 운영자 사이의 마찰을 줄일 수 있다. 사이트는 허용할 자동화 행위와 데이터 이용 목적을 구분할 수 있고, 봇 운영자는 자신의 목적에 맞는 접근을 더 명확하게 요청할 수 있다. 중요한 점은 한 번 검증되었다는 사실이 영구적인 면허가 아니라는 것이다. 선언한 목적과 실제 행동이 달라지거나 신뢰를 남용하면 검증 상태가 유지되지 않을 수 있다.

BotBase는 기존의 Bots Directory보다 범위가 넓다. 기존 디렉터리가 알려진 좋은 봇을 중심으로 제공됐다면, BotBase는 알려진 봇과 에이전트에 관한 사실을 정리하는 디렉터리를 지향하며 기대에 미치지 못하는 행위자도 추적할 수 있다. 사이트 운영자는 단순한 허용 목록보다 해당 자동화 주체가 무엇을 선언했고 실제로 어떻게 행동하는지를 함께 살펴볼 필요가 있다.

Precursor가 보는 것은 세션 전체의 행동이다

Precursor는 네트워크 신호만으로 놓치기 쉬운 비인간적 행동을 클라이언트 측에서 지속적으로 탐지하기 위한 Cloudflare의 시스템이다. 고객이 이를 활성화하면 JavaScript 기반 탐지가 CDN을 통해 삽입되며, 개별 애플리케이션 화면마다 같은 탐지 코드를 다시 배치하는 부담을 줄이는 방향으로 설계됐다.

핵심 차이는 검사 시점이다. CAPTCHA나 한 번만 통과하면 되는 검사는 특정 순간의 위험을 판단하는 데 유용하지만, 이후 행동이 바뀌는 상황에는 충분한 맥락을 제공하지 못한다. Precursor는 세션이 이어지는 동안 행동을 계속 평가해 처음에는 정상적으로 보였지만 중간부터 자동화나 악용 행위로 전환되는 패턴을 찾는 데 초점을 둔다.

Cloudflare는 글 작성 시점을 기준으로 24시간 동안 7만3438개 존에서 2억600만 건의 Precursor 평가 이벤트를 관찰했다고 밝혔다. 이 수치는 제품의 고정 성능이나 모든 고객에게 적용되는 처리량이 아니라 특정 24시간 관찰 구간의 규모다. 실제 적용 여부를 판단할 때는 이 숫자만 인용하기보다 자신의 서비스 트래픽, 오탐 허용 범위, 수집되는 신호와 운영 조건을 별도로 확인해야 한다.

Cloudflare가 강조하는 관찰 결과는 의심스러운 행동이 세션 중간에 나타날 수 있다는 점이다. 이는 로그인 직전이나 첫 페이지 요청에서 한 번만 검사를 수행하는 구조가 충분하지 않을 수 있음을 의미한다. 또한 사람과 에이전트가 번갈아 작업하는 세션에서는 행동 변화 자체가 반드시 악성이라는 뜻도 아니다. 탐지 결과를 즉시 차단으로 연결하기 전에 서비스의 정상적인 사용자 흐름과 대조해야 한다.

개발자가 우선 확인할 적용 기준

항목 확인할 질문 판단 기준
적용 범위 어떤 사이트, 애플리케이션, API 경로와 계정 유형에서 사용할 수 있는가? 보호하려는 실제 경로에 적용할 수 있고 기존 요청 흐름을 방해하지 않아야 한다.
수집 신호 클라이언트에서 어떤 행동 정보가 평가되며 보존·처리 조건은 무엇인가? 개인정보 처리방침, 연구윤리, 조직의 데이터 정책과 충돌하지 않아야 한다.
대응 방식 평가 결과가 기록, 추가 검증, 속도 제한, 차단 중 어디에 연결되는가? 초기에는 관찰 중심으로 시작하고 오탐을 확인한 뒤 강한 조치로 전환할 수 있어야 한다.
혼합형 세션 사용자가 작업 일부를 자동화 에이전트에 넘기는 정상 흐름이 있는가? 사람과 에이전트의 전환을 무조건 공격으로 분류하지 않도록 정상 시나리오를 마련해야 한다.
비용과 플랜 기능 사용에 필요한 계약, 플랜, 사용량 조건은 무엇인가? 공식 가격표와 계정 화면에서 현재 조건을 확인한 뒤 기존 대안과 총비용을 비교해야 한다.
롤백 오탐이나 성능 문제가 발생했을 때 즉시 비활성화할 수 있는가? 설정 복구 절차와 담당자, 확인할 로그가 준비되어 있어야 한다.

개인 사용자와 학생·연구자가 볼 부분

개인 사이트나 소규모 프로젝트에서는 기능의 규모보다 운영 복잡성이 더 중요한 판단 기준이다. 자동화 요청이 많지 않은 사이트라면 기존 속도 제한, 접근 제어, 로그 분석만으로도 목적을 달성할 수 있다. 반대로 공개 데이터, 검색 기능, 폼이나 로그인처럼 자동화 남용의 영향을 크게 받는 기능이 있다면 세션 단위의 행동 평가를 검토할 이유가 생긴다.

학생과 연구자는 브라우저 행동 신호가 연구 참여자나 서비스 이용자에게 어떤 의미를 갖는지 먼저 확인해야 한다. 탐지 기능을 켤 수 있다는 사실이 곧 연구 데이터에 적용해도 된다는 뜻은 아니다. 수집 항목, 처리 위치, 보존 기간, 참여자 고지와 동의 필요성을 소속 기관의 기준과 함께 검토해야 한다.

또한 Cloudflare가 제공하는 커서 움직임 시뮬레이션은 자신의 입력이 사람 또는 봇처럼 어떻게 평가될 수 있는지 살펴보는 체험 수단이다. 이 결과를 개별 사용자의 정체를 확정하는 판정으로 해석해서는 안 된다. 실제 운영에서는 커서 움직임 하나가 아니라 세션 맥락과 여러 행동 신호를 종합하는지가 중요하다.

팀과 서비스 운영자를 위한 도입 순서

  1. 정상 세션을 먼저 정의한다. 사람이 전 과정을 수행하는 흐름뿐 아니라 자동 완성, 접근성 도구, 테스트 자동화, 구매 보조 에이전트가 참여하는 흐름도 포함한다.
  2. 작은 경로에서 관찰한다. 전체 서비스에 곧바로 차단 정책을 적용하지 말고 위험이 제한된 경로에서 평가 결과와 실제 로그를 비교한다.
  3. 오탐과 미탐을 나눠 기록한다. 정상 사용자가 의심 행동으로 분류된 사례와 실제 자동화가 통과한 사례를 각각 수집해야 정책의 편향을 확인할 수 있다.
  4. 행동별 대응 단계를 만든다. 낮은 신뢰를 곧바로 영구 차단으로 연결하지 말고 기록, 추가 인증, 속도 제한, 제한적 차단처럼 서비스 위험에 맞는 단계를 정한다.
  5. 기존 보안 수단과의 관계를 확인한다. WAF 규칙, 봇 관리, 로그인 보호, API 속도 제한, CAPTCHA와 역할이 겹치는지 살피고 중복 검사가 사용자 경험을 해치지 않는지 측정한다.
  6. 되돌리기 조건을 정한다. 전환율 저하, 접근성 문제, 지연 증가, 정상 자동화 차단 등 어떤 신호가 나타나면 설정을 원복할지 미리 합의한다.

기존 도구와 비교할 때 놓치기 쉬운 점

이번 변화의 가치는 새로운 탐지 기능이라는 이름보다 반복 운영을 얼마나 줄이고 판단 맥락을 얼마나 늘리는지에 달려 있다. 이미 사용하는 봇 관리 도구가 세션 단위 신호와 검증된 봇 정보를 제공한다면 전환 이점이 크지 않을 수 있다. 반대로 현재 구조가 요청 한 건의 IP, 사용자 에이전트, CAPTCHA 통과 여부에 지나치게 의존한다면 지속 평가가 보완책이 될 수 있다.

  • 같은 트래픽 샘플에서 기존 방식과 새 방식의 판단 차이를 비교한다.
  • 탐지율만 보지 말고 정상 사용자 이탈, 페이지 지연, 고객 문의 증가도 함께 측정한다.
  • CI/CD 테스트, 모니터링 봇, 검색 크롤러처럼 반드시 허용해야 하는 자동화를 목록화한다.
  • 검증된 에이전트라도 선언한 목적과 다른 경로에 접근할 때 어떻게 처리할지 정한다.
  • 평가 결과를 사람이 검토할 수 있는 로그와 설명 정보가 제공되는지 확인한다.

가격, 계정별 제공 범위, 지역별 조건과 구체적인 설정 권한은 제공된 발표 내용만으로 확정하기 어렵다. 실제 적용 전에는 현재 계정의 관리 화면, 계약 조건, 공식 제품 문서를 기준으로 확인해야 한다. 특히 업무 자료나 연구 데이터가 포함된다면 데이터 처리 조건을 확인하기 전까지 운영 트래픽에 바로 적용하지 않는 편이 안전하다.

출처와 검증

주요 개념과 공개 수치는 Cloudflare의 공식 발표를 기준으로 재구성했다. 관찰 수치는 글 작성 당시의 24시간 구간을 나타내므로 현재 제공 범위나 성능을 보장하는 값으로 해석해서는 안 된다. 실제 도입 시점의 플랜, 권한, 데이터 처리 조건과 기능 제공 여부는 최신 공식 문서와 계정 설정에서 다시 확인해야 한다.

Cloudflare Blog — Unveiling good and bad behaviors on the Agentic Internet