경보를 더 많이 읽는 AI보다, 근거를 구분하는 구조가 중요하다

보안 경보가 여러 개 쌓이면 어려운 일은 개별 메시지를 읽는 데서 끝나지 않는다. 같은 원인에서 나온 경보를 연결하고, 실제로 차단이 이뤄졌는지 확인하며, 추가 조사가 필요한 사건을 골라야 한다. Cloudflare가 공개한 Managed Defense의 AI 에이전트 구조는 이 과정에서 증거를 모으고 해석하는 부담을 줄이는 데 초점을 맞춘다.

핵심은 데이터 수집과 조사 범위의 통제를 애플리케이션 코드가 먼저 수행하고, 모델은 그 결과를 해석하도록 역할을 나눈 것이다. Cloudflare Workers와 네트워크 관측 데이터를 활용하며, 전문 에이전트들의 분석을 종합해 Managed Defense 분석가에게 관련 경보, 확보된 증거, 정보 공백, 권고 사항을 제시한다.

개인 개발자나 연구자가 이 발표에서 먼저 볼 부분도 에이전트의 개수보다 이러한 역할 분리다. 자신의 서비스에 곧바로 켤 수 있는 기능인지, 같은 구조를 직접 구현할 때 참고할 설계인지에 따라 활용 방식이 달라진다. 공개된 설명만으로 모든 Cloudflare 계정에서 동일한 기능을 사용할 수 있다고 판단해서는 안 된다.

하나의 에이전트에 조사를 맡겼을 때 생긴 세 가지 문제

Cloudflare는 초기 시제품에서 범용 에이전트 하나에 조사 전체를 맡겼다고 설명한다. 분석 자체는 유용했지만, 증거가 뒷받침하지 않는 주장도 나왔다. 관측 데이터, 탐지기 설명, 정책, 위협 인텔리전스를 하나의 프롬프트에 넣으면서 서로 다른 자료의 역할이 섞인 것이 문제였다.

  • 탐지 가설이 확인된 사실처럼 취급됐다. 탐지 규칙이 발동했다는 사실만으로 공격 성공이나 실제 침해가 입증되는 것은 아니다.
  • 조사 범위가 흔들렸다. 에이전트가 잘못된 계정, 시간 구간, 데이터 출처를 조회할 수 있었다. 프롬프트의 지시만으로 범위를 통제하기 어려웠다.
  • 조회 실패가 결과에서 사라졌다. 조회가 시간 초과로 끝났을 때, 확인하지 못한 상태와 확인했지만 발견하지 못한 상태가 구분되지 않을 수 있었다.

이는 보안 도구를 만드는 개발자에게 구체적인 설계 질문을 던진다. 보고서의 각 문장이 실제 기록에 연결되는지, 조회 대상이 코드에서 제한되는지, 실패한 조회가 최종 결과에 남는지를 확인해야 한다. 답변이 자연스럽다는 이유만으로 조사 품질을 평가하면 이런 차이를 놓치기 쉽다.

모델 호출 전에 조사 자료를 고정하는 이유

새 구조의 앞부분에는 AI 에이전트가 들어가지 않는다. 정해진 코드가 버전이 관리되는 API 호출로 고객 식별 정보, 과거 탐지 기록, 트래픽 기준선, 보안 조치 결과, 네트워크 관측 정보를 수집한다. 각 데이터에는 출처와 버전, 타임스탬프가 함께 저장된다.

여기서 중요한 연결은 요청의 행동과 적용된 보안 조치, 그리고 그 결과다. 의심스러운 요청이 있었다는 설명만으로는 대응 필요성을 판단하기 어렵다. 어떤 제어가 작동했고 결과가 무엇이었는지 함께 확인해야, 이미 처리된 활동과 추가로 살펴볼 활동을 구분하는 데 도움이 된다.

조사 시점의 자료를 고정하면 평가 조건도 명확해진다. 에이전트가 실행할 때마다 직접 데이터를 새로 가져오면 결과 차이가 모델의 해석 때문인지, 입력 데이터가 바뀌었기 때문인지 알기 어렵다. 같은 스냅샷을 다시 사용하면 동일한 증거를 두고 분석 방식의 차이를 비교할 수 있다.

학생이나 연구자가 보안 분석 에이전트를 실험할 때도 참고할 만하다. 같은 경보에 대한 모델별 판단을 비교하려면 입력 자료의 수집 시점과 범위를 먼저 맞춰야 한다. 다만 자료를 고정했다는 사실이 자료의 완전성이나 정확성까지 보장하지는 않는다. 누락된 출처와 수집 실패도 평가 대상에 포함해야 한다.

반복 경보를 거르고, 필요한 사건만 전문 분석으로 보낸다

Cloudflare는 모든 경보를 심층 분석으로 보내지 않는다. Workers AI에서 실행되는 공개 의사결정 모델 Clef가 초기 분석과 점수화를 맡는다. 이전에도 같은 고객에게 관측된 사건인지, 분석가가 과거에 어떤 판단을 내렸는지, 트래픽이 정상적인 사람의 행동과 일치하는지 등을 조사 자료와 함께 살핀다.

오탐 가능성이 높게 평가된 경보는 전문 에이전트 분석을 건너뛴다. 이미 알려진 대량 반복 잡음은 도착 시 정해진 로직으로 활성 분석 대기열에서 제외되는 패시브 상태로 분류한다. 이 정보는 이후 조사의 맥락으로 남지만 당장 분석가가 처리할 활성 대기열에는 들어가지 않는다. 모델을 통한 초기 선별과 알려진 잡음에 대한 코드 기반 처리를 구분해 볼 필요가 있다.

개발자에게 중요한 평가는 줄어든 호출 수만이 아니다. 정상 경보를 얼마나 잘 걸러냈는지와 함께, 중요한 사건이 심층 분석에서 빠지지 않았는지를 확인해야 한다. 자신의 서비스에 비슷한 방식을 적용한다면 선별에서 제외된 사례를 다시 점검할 수 있는지, 과거 판단이 잘못됐을 때 분류 기준을 수정할 수 있는지도 살펴볼 항목이다.

네 전문 에이전트와 종합 에이전트의 역할

더 깊은 검토가 필요한 경보에는 조정 에이전트가 네 종류의 전문 에이전트를 병렬로 실행한다. 각 에이전트가 좁은 범위의 질문을 맡도록 해, 근거 없는 주장을 찾아내고 권고 내용을 검토하기 쉽게 만드는 방식이다.

  • 트래픽 분석: 요청의 행동, 과거와 달라진 패턴, 적용된 보안 조치를 검토한다.
  • 고객 맥락: 이전 경보와 처리 결과, Managed Defense 분석가의 과거 판단을 확인한다.
  • 글로벌 관측: 해당 활동을 개인정보 보호를 고려한 인터넷 전반의 집계 신호와 비교한다.
  • 위협 인텔리전스: 해당 경보나 사건의 조사 자료로 이미 포함된 지표를 확인한다.

종합 에이전트는 정해진 형식의 분석 결과를 하나의 권고로 합친다. 이 단계에서 새로운 증거를 가져올 수 없으며, 사전에 허용된 분류 체계 밖의 판단을 선택할 수도 없다. 최종 문장을 작성하는 모델이 조사 범위까지 임의로 넓히지 못하게 한 것이다.

이 구조를 참고해 구현한다면 역할 이름을 나누는 것만으로는 충분하지 않다. 각 역할이 받을 수 있는 입력, 반환할 결과 형식, 접근 가능한 자료를 실제로 구분해야 한다. 네 에이전트가 같은 근거 없는 가정을 반복할 수도 있으므로, 의견의 일치 여부와 별개로 각 결론이 어떤 증거에 연결되는지 확인하는 편이 타당하다.

글로벌 신호가 더하는 맥락과 데이터 경계

한 서비스 안에서 보이는 활동만으로는 공격의 범위를 판단하기 어렵다. 같은 IP가 특정 사이트만 겨냥하는지, 수많은 사이트를 훑고 있는지, 새롭게 등장한 활동인지에 따라 해석이 달라질 수 있다. Cloudflare는 자사 글로벌 네트워크에서 관측한 패턴을 경보 분석에 활용한다고 설명한다.

원문에 따르면 글로벌 관측 전문 에이전트는 집계 데이터만 사용하고, 다른 고객의 개별 기록이나 신원은 받지 않는다. 분석에는 CDN, WAF, DDoS, Turnstile, Rate Limiting과 Cloudforce One 위협 인텔리전스에서 나온 특성이 활용된다. 종합 과정에서는 글로벌 평판과 해당 고객의 과거 이력을 함께 고려한다.

이 설명을 모든 데이터 처리 조건에 대한 답으로 확대해서는 안 된다. 업무나 연구 자료가 관련된다면 실제 입력 필드, 보존 기간, 처리 위치, 외부 모델에 전달되는 정보, 접근 권한을 해당 서비스의 공식 문서와 계약 조건에서 확인해야 한다. 다른 고객의 정보가 집계된다는 설명과 자신의 데이터가 어떻게 처리되는지는 각각 확인할 문제다.

개인 개발자와 연구자가 비교할 것은 이용 조건과 검토 부담이다

개인 서버와 사이드 프로젝트

경보가 적고 기존 규칙으로 처리할 수 있다면 다중 에이전트 구조를 추가하는 이점이 작을 수 있다. 먼저 반복해서 시간을 쓰는 지점을 찾아야 한다. 과거 경보를 다시 찾는 일인지, 차단 결과를 확인하는 일인지, 여러 로그를 연결하는 일인지에 따라 필요한 구성도 달라진다. 자료 수집을 정형화하는 것만으로 개선될 수 있는 부분도 있다.

학생과 보안 연구자

연구에서는 고정된 조사 자료를 활용한 재현성과 근거 추적이 중요한 비교 기준이 된다. 실제 민감 정보를 넣기 전에 사용 권한이 분명한 자료로 실험하고, 정답을 알고 있는 사건에 대해 근거 없는 주장, 누락된 증거, 실패 상태의 표현을 비교할 수 있다. 문장 품질이나 분류 정확도 하나만으로 평가를 끝내지 않는 것이 좋다.

서비스 보안과 개발 자동화를 맡은 팀

기존 SIEM, 규칙 기반 분류, 사람이 작성하는 조사 보고서와 비교할 때는 분석가의 총 검토 시간을 봐야 한다. 자동 보고서가 빨리 나와도 출처를 다시 찾거나 잘못된 추론을 고치는 시간이 길면 효과가 제한된다. 경보 수집부터 권고 검토까지 실제 작업 흐름에서 어느 단계가 줄어드는지 확인해야 한다.

가격과 제공 범위도 별도의 판단 요소다. 제공된 원문 설명만으로 요금, 무료 제공 여부, 계정별 이용 조건, 독립적인 API나 SDK 제공 여부를 확정할 수는 없다. Managed Defense 이용 조건과 직접 구현에 필요한 Workers·Workers AI 등의 사용 조건을 각각 확인하고, 예상 사용량을 기준으로 기존 방식과 비용을 비교해야 한다.

과거 사건으로 확인할 분석 품질

적용 가능성을 살필 때는 처리 결과가 알려진 소수의 과거 경보를 활용할 수 있다. 정상 트래픽, 반복 잡음, 추가 대응이 필요했던 사례, 일부 자료 조회가 실패한 사례를 포함하면 서로 다른 약점을 확인하기 쉽다. 이는 Cloudflare가 공개한 성능 수치가 아니라, 비슷한 구조를 평가하려는 사용자가 정할 수 있는 검증 기준이다.

  1. 계정과 시간 범위를 고정하고, 수집 자료의 출처와 시각을 남긴다.
  2. 같은 자료로 분석을 반복해 결론과 인용 근거가 얼마나 일관되는지 확인한다.
  3. 자료가 없는 상태와 조회에 실패한 상태가 보고서에서 구분되는지 살핀다.
  4. 심층 분석에서 제외된 경보에 중요한 사건이 섞였는지 검토한다.
  5. 사람이 권고를 확인하고 수정하는 데 든 시간과 전체 처리 비용을 비교한다.

초기 평가에서는 권고 생성과 실제 보안 설정 변경의 연결 여부도 분명히 해야 한다. 이 발표는 분석가에게 근거를 갖춘 분석과 권고를 제공하는 구조를 설명한다. 이를 근거로 모든 대응이 자동 실행되거나 사람의 검토가 필요 없어졌다고 해석할 수는 없다. 자신의 환경에서 변경 실행까지 연결하려면 실행 권한과 복구 절차를 별도로 검토해야 한다.

이 접근의 실용적인 가치는 사람이 확인해야 할 정보를 더 잘 정리하는 데 있다. 확인한 사실과 아직 모르는 부분이 구분되고, 각 권고의 출처를 따라갈 수 있으며, 같은 자료로 결과를 다시 검토할 수 있는지가 선택 기준이다. 이런 조건이 충족될 때 에이전트 분석을 기존 보안 업무에 연결할 근거가 생긴다.

출처와 검증

출처는 2026년 10월 7일 공개된 Cloudflare Blog의 Building an evidence-grounded agentic security operations harness on Cloudflare다. 데이터 수집과 모델 추론의 분리, Clef를 통한 초기 선별, 네 전문 에이전트와 종합 에이전트의 역할은 원문의 설명에 근거했다.

실제 이용 가능 여부, 가격, 계정별 권한, 데이터 보존 조건, 연동 방식은 적용 시점의 공식 제품 문서와 계약 조건으로 확인해야 한다. 본문에서 제안한 비교 항목과 과거 경보 검증 절차는 독자의 환경에서 효과를 판단하기 위한 기준이며, 특정 수준의 탐지 성능이나 비용 절감을 보장하는 수치는 아니다.