몇 주 전, 우리는 Project Glasswing과 사이버 프런티어 모델을 우리 코드에 적용했을 때 관찰한 결과를 소개했습니다. 그 이후 가장 큰 공감을 얻은 부분은 취약점 자체보다 취약점을 둘러싼 아키텍처가 패치 속도보다 더 중요하다는 주장이라는 점을 확인했습니다.
그 이후 CISO 및 보안 팀과 나눈 대화에서 가장 많이 받은 질문은 일관되었습니다. 실제로 우리의 아키텍처는 어떤 모습인지, 무엇을 모니터링해야 하는지, 어디서부터 시작해야 하는지, 그리고 Cloudflare가 어떤 도움을 줄 수 있는지였습니다.
자세한 내용을 살펴보기 전에 먼저 말씀드리겠습니다. 아래에서 소개하는 아키텍처는 거의 전적으로 Cloudflare의 자체 제품으로 구축되어 있습니다. 우리가 개발하는 보안 제품의 customer zero는 바로 Cloudflare이기 때문입니다. Cloudflare의 보안 스택은 이미 우리 코드, 직원, 고객 대상 애플리케이션 앞단에서 운영되고 있습니다. Cloudflare 고객이라면 아래에서 설명하는 모든 계층을 지금 바로 사용할 수 있습니다. Cloudflare 고객이 아니더라도, 여기서 설명하는 원칙은 여러분이 구축한 어떤 스택에도 동일하게 적용됩니다.
이전 글에서는 Mythos와 같은 사이버 프런티어 모델이 공격자의 타임라인을 어떻게 바꾸는지 설명했습니다. 이러한 모델은 취약점을 찾아내고, 익스플로잇 체인을 추론하며, 실제로 동작하는 PoC를 이전 모델보다 훨씬 빠르게 생성할 수 있습니다. Mythos와 같은 모델이 침해의 전체 과정 자체를 바꾸는 것은 아닙니다. 정찰, 초기 액세스, 내부망 이동, 지속성 확보, 데이터 유출이라는 단계는 여전히 그대로입니다. 달라진 점은 속도와 규모입니다. 인터넷에 공개된 대상을 상대로 할 경우 모델은 손쉬운 공격 대상을 매우 빠르게 찾아 공격할 수 있습니다. 반면 방어가 잘 갖춰진 대상이라면 계속 탐색하고 적응해야 하며, 신중한 인간 공격자보다 더 많은 흔적과 노이즈를 남기는 경우도 많습니다.
과거에는 취약점 발견, 익스플로잇 체인 구성, PoC 생성이 실제 공격을 완성하는 데 가장 큰 제약 요소였습니다. 이제 프런티어 모델은 이 세 가지 작업을 매우 짧은 시간 안에 수행합니다. 예전에는 느리고 체계적으로 진행되던 작업이 이제는 빠르고 무차별적으로 이루어집니다.
AI는 Cloudflare를 비롯한 많은 기업의 개발 팀이 코드를 더 빠르게 배포하도록 돕고 있지만, 보안 팀의 업무는 같은 속도로 단축되지 않았습니다. 공격자는 단 하나의 허점만 찾으면 되지만, 보안 팀은 모든 허점을 찾아 막아야 합니다. 수정 코드를 작성하고, 회귀 테스트를 수행하며, 주변 코드를 손상시키지 않고 배포하는 과정에는 AI로도 해결되지 않는 제약이 존재합니다. 이전 글 마지막에서 소개했듯이, 우리는 AI 코딩 어시스턴트에게 우리 코드의 버그를 직접 수정하도록 했고 이를 통해 이 사실을 뼈저리게 배웠습니다. 일부 패치는 원래 버그는 해결했지만, 동시에 해당 코드가 의존하던 다른 기능을 조용히 망가뜨렸습니다.
이러한 모델이 점점 더 뛰어난 성능과 능력을 갖추게 되면서, 위협 관점에서 우리의 핵심 관심사는 세 가지로 압축됩니다. 그리고 이 세 가지가 이 글에서 설명하는 아키텍처의 기반이 됩니다.
첫 번째는 취약점 발견 속도입니다.프런티어 모델은 대규모 공개 코드베이스를 훨씬 쉽게 검색할 수 있으며, 많은 기업이 사용하는 오픈소스 라이브러리도 여기에 포함됩니다. 그렇다고 모든 라이브러리 버그가 익스플로잇 가능한 것은 아니며, 대부분의 취약점이 라이브러리에 존재하는 것도 아닙니다. 실제 익스플로잇 가능 여부는 코드가 어떻게 사용되는지, 공격자가 제어하는 입력이 취약한 코드 경로까지 도달할 수 있는지, 그리고 이를 둘러싼 보호 장치가 무엇인지에 따라 달라집니다. 하지만 널리 사용되는 오픈소스 라이브러리와 프레임워크는 공격자에게 대규모로 연구할 수 있는 공통의 공격 표면을 제공합니다. 실제로 도달 가능한 취약점이 존재한다면, 모델은 이를 더 빨리 찾아내고, 가능한 익스플로잇 경로를 추론하며, 다양한 PoC 변형을 생성할 수 있습니다. 그 속도는 유지관리자와 방어자가 모든 하위 사용 사례를 검토하는 속도를 앞설 수 있습니다. 우리가 가장 우려하는 것은 공격자가 취약점을 발견하는 시점과 방어자가 그 존재를 인지하는 시점 사이의 격차입니다. 여러분이 이러한 모델을 자신의 코드에 적용하고 있지 않다면, 누군가는 이미 그렇게 하고 있다고 가정하는 것이 안전합니다.
두 번째는 익스플로잇의 규모와 적응 능력입니다. 모델은 하나의 익스플로잇을 수천 가지 형태로 변형할 수 있으며, 같은 규모로 정찰도 수행할 수 있습니다. 이러한 대규모 시도는 공격자에게 유리하지만, 그렇다고 시그니처 기반 탐지를 자동으로 우회하는 것은 아닙니다. 많은 변형은 동일한 근본 시그니처를 공유하기 때문에 첫 번째 공격을 탐지하는 규칙이 나머지도 함께 탐지할 수 있습니다. 공격자가 시그니처 기반 탐지를 우회하는 핵심은 적응입니다. 모델에게 SQL 삽입 공격을 보여 달라고 하면 교과서적인 예제를 생성합니다. 하지만 중간에 WAF가 있다고 알려주면 차단되는 패턴을 탐색하고 학습한 뒤, 차단 규칙을 우회할 수 있을 때까지 페이로드를 계속 수정합니다.
세 번째는 취약점이 결국 악용되었을 때의 영향 범위입니다.모든 것을 완벽하게 막는 아키텍처는 없습니다. 취약점이 악용된 이후 우리가 스스로에게 던지는 질문은 이것입니다. 단 하나의 ID, 단 하나의 경로, 또는 단 하나의 자격 증명만으로 공격자가 어디까지 도달할 수 있는가? 다른 방어 장치가 공격을 멈추기 전까지 말입니다. 만약 답이 "원하는 곳 어디든"이라면, 진짜 문제는 취약점이 아니었습니다. 취약점을 둘러싼 아키텍처가 문제였던 것입니다.
Cloudflare는 웹 트래픽의 약 5분의 1을 처리합니다. 이를 통해 어떤 페이로드가 변형되고 있는지, 어떤 공격 패턴이 확산되고 있는지, 공격 도구가 다음에는 어디로 이동하는지를 실시간으로 파악할 수 있습니다. 그리고 두 개의 팀이 이러한 가시성을 실제 방어 역량으로 전환합니다.
첫 번째는 Cloudflare 보안 조직에 속한 위협 인텔리전스·연구·운영 팀인 Cloudforce One입니다. 이 팀은 네트워크 전반에서 관찰한 정보를 바탕으로 스택 전체에서 활용할 수 있는 인사이트를 제공합니다. 여기에는 추적 중인 공격자, 새롭게 등장하는 공격 캠페인, 침해 지표(IOC)가 포함됩니다. 이들의 업무에서 가장 어려운 점은 악성 활동을 식별하는 것이 아니라 대응이 지연되는 문제였습니다. 일반적으로 새로운 위협에 대한 정보는 위협 보고서에서 피드로, 다시 기업의 방어 체계로 전달되어야 비로소 차단에 활용할 수 있습니다. 공격자는 이미 이보다 더 빠르게 움직이는 법을 익혔습니다. Cloudflare 네트워크는 이러한 격차를 줄여줍니다. 이제 Cloudflare 고객은 WAF에서 Cloudforce One의 위협 인텔리전스를 직접 활용해 위험도가 높은 트래픽을 차단할 수 있습니다.
두 번째는 실제 탐지를 담당하는 WAF 엔진 개발 팀입니다. 이 팀은 Cloudflare 자체 서비스 앞단에서 운영되며 모든 Cloudflare 고객에게 제공되는 관리형 규칙 세트, WAF Attack Score를 지원하는 머신러닝 모델, 그리고 경우에 따라 CVE가 공개되기 전에 규칙을 배포할 수 있도록 하는 다양한 협력 관계를 담당합니다. 전 세계에 분산된 이 팀은 매우 빠르게 움직이며, 공격 PoC가 알려진 후 몇 시간 안에 새로운 규칙을 배포합니다. 탐지 규칙이 배포되면 30초 이내에 Cloudflare 전체 네트워크와 모든 Cloudflare 고객에게 적용됩니다. 최근의 React2Shell 사례가 대표적입니다. 공식 권고문이 발표되기 몇 시간 전부터 관리형 WAF 규칙이 Cloudflare 자체 서비스와 모든 Cloudflare 고객을 보호하고 있었습니다.
애플리케이션 앞단에 배치하는 점수 기반 탐지 계층, 다양한 방어 기능, 그리고 취약점을 둘러싼 격리 구조는 모두 이 두 팀이 확보한 가시성을 기반으로 구축됩니다.
시그니처 기반 방어는 새로운 익스플로잇이 드물고, 변형이 나타나는 데 몇 주씩 걸리던 시대를 위해 설계되었습니다. Cloudflare는 새로운 PoC가 등장한 후 실제 탐지 규칙을 배포하기까지 전통적으로 12시간의 SLA를 유지해 왔습니다. 하지만 프런티어 모델이 등장한 지금은 이것만으로는 충분하지 않습니다. 탐지 기능은 CVE가 발견되기 전부터 준비되어 있어야 합니다. 그래서 Cloudflare는 기존 시그니처 기반 WAF 앞단에 머신러닝 기반 탐지 계층을 추가했습니다.
이 모델은 방대한 과거 공격 트래픽을 학습했으며, 공개되기 전의 새로운 취약점 변형도 탐지할 수 있습니다. 새로운 SQL 삽입이나 원격 코드 실행(RCE) 공격 체인도 대부분은 모델이 이미 학습한 공격 형태를 재조합한 것이기 때문입니다. 구체적인 익스플로잇은 처음 등장한 것이라도 마찬가지입니다. Cloudflare는 모든 요청에 대해 모델을 실행하고, 알려진 악성 시그니처 목록과 비교하는 대신 기존 공격 형태와 얼마나 유사한지를 기준으로 1~99 사이의 WAF Attack Score를 부여합니다. 점수가 낮을수록 해당 요청을 더 공격적으로 처리합니다. 이 점수에 따라 요청을 허용할지 여부를 결정합니다. Cloudflare는 AI Security for Apps에도 동일한 점수 기반 접근 방식을 적용합니다. 알려진 악성 프롬프트 목록과 일일이 비교하는 대신, 해당 프롬프트가 실제 공격과 얼마나 유사한지를 평가해 점수를 부여합니다.
이러한 기능은 애플리케이션 앞단에 계층적으로 배치될 때 비로소 의미를 갖습니다. Cloudflare의 심층 방어 전략에서 첫 번째 계층은 WAF입니다. 알려진 악성 패턴과 일치하는 모든 요청은 애플리케이션에 도달하기 전에 차단됩니다. 이를 통해 명백한 공격 트래픽 대부분을 먼저 걸러내고, 그 아래의 보다 전문화된 방어 계층은 남은 트래픽에 집중할 수 있습니다.
API 영역에서는 API Shield를 통해 긍정적 보안 모델을 적용합니다. 모든 악성 요청을 예측하려는 대신, 각 API에 대한 정상 요청의 형태를 API 자체 정의나 실제 트래픽을 통해 학습하여 규정합니다. 그리고 그 기준에 맞지 않는 요청은 통과하지 못합니다. 이를 통해 프런티어 AI 모델의 장점을 무력화합니다. 검증된 트래픽만 허용하기 때문에 수천 가지 새로운 공격 변형을 생성하더라도 시스템을 우회할 수 없습니다.
Cloudflare의 계층형 아키텍처
Bot Management는 프런티어 모델이 공격 대상을 파악하기 위한 지도를 만들기 전에 네트워크에서 탐색 트래픽을 탐지합니다. 모든 요청에 대해 자동화된 요청일 가능성을 점수화하며, 네트워크 전반에서 동일한 신호를 활용합니다. 클라이언트의 동작 방식, 실제 브라우저처럼 보이는지 여부, 연결이 알려진 악성 패턴과 일치하는지 등을 종합적으로 평가합니다. 공격은 결국 취약한 지점을 찾아야만 성공할 수 있습니다.
모든 내부 애플리케이션에는 Zero Trust Network Access를 적용합니다. 네트워크 내부라는 이유만으로 부여되던 암묵적인 신뢰를 없애고, 모든 직원이 모든 도구에 액세스할 때마다 요청 단위의 명시적인 ID 검증과 정책 평가를 수행합니다. 이 접근 방식의 가치는 한 엔지니어가 잘못 구성된 도구를 배포했을 때 분명하게 드러났습니다. 평면 네트워크였다면 동일한 네트워크 세그먼트의 모든 시스템이 노출됐겠지만, Cloudflare 환경에서는 노출 범위가 해당 도구 자체로 제한되었습니다. 이후에는 액세스 정책이 적용되기 전에 새로 배포되거나 잘못 구성된 애플리케이션이 외부에서 접근되지 않도록 Require Access Protection도 구축했습니다.
IdP Federation은 이러한 기본적으로 안전한 구성을 모든 Cloudflare 계정에서 일관되게 유지하도록 지원합니다. 특히 더 많은 사람들이 내부 도구를 빠르게 배포하는 환경에서는 이러한 기능이 더욱 중요합니다. 각 팀이 개별적으로 SSO를 구성하는 대신, 조직의 ID 공급자(IdP)를 한 번만 설정하면 조직 전체에서 공유할 수 있습니다. 새 계정에는 SSO가 자동으로 적용되고, 수신 측 IdP 연결은 읽기 전용으로 유지되며, 각 계정의 Access 정책은 일반적인 요청 처리 과정에서 해당 ID 정보를 계속 평가합니다.
MCP Server Portal은 AI 에이전트가 엔터프라이즈 시스템에 안전하게 연결될 수 있도록 통제된 방식을 제공합니다. AI 에이전트는 단일 포털에서 중앙 관리되는 MCP 서버에 액세스하며, 모든 작업이 기록됩니다. 이를 통해 AI 에이전트가 사용자를 대신해 작업할 경우 무엇을 수행했고, 어떤 리소스를 사용했으며, 해당 작업이 허용되어야 했는지를 모두 확인할 수 있습니다. Cloudflare가 이를 어떻게 구축했는지는 엔터프라이즈 MCP 관련 게시물에서 자세히 소개했습니다.
AI Gateway는 고객 대상 AI 기능 앞단에서 AI Security for Apps가 동작하는 것과 동일한 방식으로 내부 AI 도구 앞단에서 실행되며, 동일한 점수 기반 평가와 동일한 가시성을 제공합니다. 사내 환경에서는 차단 기능보다 가시성이 더 중요했습니다. 의미 있는 정책을 수립하기 전에 엔지니어들이 실제로 어떤 AI 기능을 개발하고 있는지 먼저 파악해야 했기 때문입니다.
프런티어 모델은 공격자가 취약점을 더 빨리 찾고, 페이로드를 변형하며, 공격 속도를 높이는 데 도움을 줄 수 있습니다. 하지만 공격은 여전히 애플리케이션 앞단에 구축된 계층형 방어를 통과해야 합니다. 따라서 팀은 다음과 같은 사항부터 시작해야 합니다.
공개 애플리케이션 앞단에 검사 계층을 배치하세요.
정상적인 API 트래픽의 기준을 정의하세요.
봇 탐지를 활용해 자동화된 탐색을 제한하세요.
내부 도구에는 액세스 정책과 ID 검증이 적용되기 전까지 접근할 수 없도록 하세요.
AI 및 에이전트 시스템의 경우에는 다음을 권장합니다.
목표는 하나의 계층이 공격을 놓치더라도, 다음 계층이 공격자가 무엇을 볼 수 있고, 어디까지 접근할 수 있으며, 무엇을 변경할 수 있는지를 제한하는 것입니다.
이것이 바로 취약점을 둘러싼 아키텍처의 핵심입니다. 공격 범위를 제한하는 것입니다. 공격은 취약점에서 시작될 수 있지만, 얼마나 멀리 확산되는지는 아키텍처가 결정합니다.
이 접근 방식이 효과적이라는 것을 어떻게 확인할 수 있을까요?
많은 보안 아키텍처는 설계도에서는 완벽해 보이지만 실제 환경에서는 쉽게 무너집니다. 그래서 Cloudflare는 경계와 내부 환경 모두에서 레드팀을 참여시켜 지속적으로 테스트합니다.
경계 환경에서는 프런티어 모델을 적응형 공격자로 활용해 애플리케이션 보안 스택을 테스트합니다. 이러한 모델은 레드팀과 별개로 동작하는 것이 아니라, 수동 테스트, 위협 인텔리전스, 실제 트래픽 패턴 분석, PoC 분석, 그리고 Cloudflare 자체 네트워크에서 수집한 신호와 함께 활용됩니다. 이러한 입력 정보를 종합해 새로 출시된 제품, 최근 변경된 공격 표면, 공격자가 가장 먼저 탐색할 가능성이 높은 경로 등 테스트 우선순위를 결정합니다. 가장 중요한 것은 그 이후의 절차입니다. 무언가가 방어를 통과하면, 원인을 분석하고 적절한 도구를 활용해 문제를 이해한 뒤 탐지 규칙이나 대응책을 작성하여 배포하고, 동일한 시나리오를 다시 테스트해 문제가 실제로 해결되었는지 확인합니다.
내부 환경에서는 레드팀이 경계 방어는 이미 실패했다는 가정에서 출발합니다. 무엇이 변경되었는지, 어떤 민감한 시스템이 위험을 안고 있는지, 그리고 하나의 계정, 하나의 경로 또는 하나의 자격 증명이 허용 범위를 넘어 더 많은 시스템에 접근할 수 있는지를 점검합니다. 이러한 결과를 바탕으로 아키텍처를 수정하면, 레드팀은 새로운 환경에서 동일한 공격 시나리오를 다시 수행해 취약점이 실제로 제거되었는지 확인합니다.
Cloudflare는 개별 방어 계층이 완벽하다고 가정하지 않습니다. 대신 장애 상황에서도 아키텍처가 어떻게 동작하는지를 지속적으로 검증함으로써 이 아키텍처가 효과적으로 작동하고 있음을 확인합니다.
동일한 문제를 해결하고 있는 팀이라면 경험을 공유해 주세요. security-ai-research@cloudflare.com으로 연락 주시기 바랍니다.