최전선 사이버 모델 방어: 고객 제로인 Cloudflare 아키텍처

출처: Cloudflare Blog

2026-06-09

8분 읽기

몇 주 전, 우리는 Project Glasswing에 대해 썼습니다 그리고 사이버 프론티어 모델을 우리 자체 코드에 적용했을 때 관찰한 내용을 공유했습니다. 그 이후로 가장 크게 공감을 얻은 부분은 패치 속도보다 취약점 주변의 아키텍처가 더 중요하다는 주장이라는 점을 확인했습니다.

CISO와 보안 팀과 나눈 대화에서 일관되게 등장한 질문은 다음과 같습니다. 우리의 아키텍처는 실제로 어떻게 생겼는가, 무엇을 모니터링해야 하는가, 어디서 시작해야 하는가, 그리고 Cloudflare가 어떻게 도울 수 있는가?

세부 사항에 들어가기 전에: 아래 아키텍처는 거의 전부가 Cloudflare 자체 제품으로 구성됩니다. 이는 우리가 구축하는 보안 제품에 대해 고객 제로(customer zero) 입장을 취하고 있기 때문입니다. Cloudflare 스택은 이미 우리 코드, 직원, 그리고 고객이 이용하는 애플리케이션 앞에 존재합니다. 여러분이 Cloudflare 고객이라면 아래 모든 레이어를 오늘 바로 이용할 수 있습니다. 고객이 아니더라도, 여기서 제시하는 원칙은 여러분이 구축한 어떤 스택에도 적용됩니다.

사이버 프론티어 모델이 실제로 바꾸는 것

이전 글(사이버 프론티어 모델)에서 우리는 Mythos와 같은 사이버 프론티어 모델이 공격자의 타임라인을 어떻게 바꾸는지 보여주었습니다. 이 모델은 취약점을 찾고, 익스플로잇 체인을 추론하며, 작동 가능한 증명을 이전 모델보다 빠르게 생성합니다. Mythos와 같은 모델이 침투 과정 자체(정찰, 초기 접근, 횡 이동, 지속성, 데이터 유출)를 바꾸지는 않지만, 속도와 규모에서 차이를 만듭니다. 공개 웹을 대상으로 할 때 모델은 저-hanging fruit를 빠르게 찾아내고 공격할 수 있습니다. 방어가 강화된 대상에 대해서는 여전히 탐색하고 적응해야 하며, 종종 신중한 인간 운영자보다 더 많은 잡음을 발생시킵니다.

과거에는 탐색, 익스플로잇 체인 구성, 그리고 PoC(Proof‑of‑Concept) 생성이 실질적인 공격을 만들기 위한 주요 제약이었습니다. 프론티어 모델은 이 세 가지를 극히 짧은 시간에 처리합니다. 느리고 체계적이던 작업이 이제는 빠르고 무차별적으로 변했습니다.

AI가 Cloudflare와 많은 기업의 개발 팀이 코드를 배포하는 속도를 가속화하고 있는 반면, 보안 팀의 작업은 같은 방식으로 압축되지 못하고 있습니다. 공격자는 한 번의 구멍만 열면 침투가 가능하지만, 보안 팀은 모든 구멍을 찾아서 닫아야 합니다. 패치를 작성하고, 회귀 테스트를 거쳐, 주변 코드를 깨뜨리지 않으면서 배포하는 과정에는 AI가 없애지 못하는 제약이 존재합니다. 우리는 이전 글(사이버 프론티어 모델) 말미에서 AI 코딩 어시스턴트가 우리 자체 버그에 대해 스스로 패치를 작성하도록 허용했을 때 겪은 어려움을 통해 이를 뼈저리게 배웠습니다. 일부 패치는 원래 버그를 수정했지만, 동시에 코드가 의존하고 있던 다른 부분을 은밀히 깨뜨렸습니다.

이러한 모델이 점점 더 능숙하고 강력해짐에 따라, 위협 관점에서 우리가 집중해야 할 세 가지가 등장합니다. 각각은 아래에서 다룰 아키텍처를 형성합니다.

• 첫 번째는 탐색 속도입니다. 프론티어 모델은 방대한 공개 코드(오픈소스 라이브러리 포함)를 손쉽게 검색할 수 있게 해줍니다. 이는 모든 라이브러리 버그가 exploitable(악용 가능)하다는 뜻이 아니며, 라이브러리 버그가 대부분의 취약점을 차지한다는 의미도 아닙니다. 악용 가능성은 여전히 코드 사용 방식, 공격자 제어 입력이 취약 경로에 도달할 수 있는지, 그리고 주변 보호 메커니즘에 달려 있습니다. 하지만 널리 사용되는 오픈소스 라이브러리와 프레임워크는 공격자에게 공유된 공격 표면을 제공해 대규모로 연구할 수 있게 합니다. 실제로 도달 가능한 취약점이 존재한다면, 모델은 이를 찾아내고 가능한 익스플로잇 경로를 추론하며, 방어자가 모든 downstream 사용 사례를 검토하기 전에 PoC 변형을 빠르게 생성할 수 있습니다. 공격자가 취약점을 발견하는 시점과 방어자가 이를 인지하는 시점 사이의 격차가 우리가 가장 우려하는 부분입니다. 여러분이 자체 코드에 대해 이러한 모델을 실행하고 있지 않다면, 누군가가 실행하고 있다고 가정하는 것이 안전합니다.

• 두 번째는 익스플로잇 볼륨 및 적응력입니다. 모델은 하나의 익스플로잇에 대해 수천 가지 변형을 만들고, 같은 규모로 정찰을 수행할 수 있습니다. 이 볼륨은 공격자에게 이점을 주지만, 반드시 시그니처 기반 탐지를 우회한다는 뜻은 아닙니다. 많은 변형이 동일한 기본 시그니처를 공유하므로, 첫 번째 변형을 차단하는 규칙이 나머지도 차단합니다. 적응은 시그니처 기반 탐지를 우회하는 방법입니다. 모델에게 SQL 인젝션을 보여 달라고 하면 교과서적인 예시를 반환합니다. 거기에 WAF가 존재한다는 정보를 주면, 모델은 차단되는 부분을 탐색하고, 차단되는 payload를 학습한 뒤, 규칙을 피할 수 있을 때까지 페이로드를 재작성합니다.

• 세 번째는 취약점이 결국 악용될 때의 영향입니다. 어떤 아키텍처도 모든 것을 잡아낼 수는 없습니다. 취약점이 악용된 뒤, 우리는 스스로에게 묻습니다: “공격자는 하나의 아이덴티티, 하나의 경로, 하나의 자격 증명으로 어디까지 갈 수 있을까? 다른 무언가가 그들을 멈추기 전까지.” 만약 답이 “원하는 어디든”이라면, 문제는 취약점 자체가 아니라 그 취약점을 둘러싼 아키텍처였습니다.

Cloudflare의 강점: 가시성

우리는 전 세계 웹 트래픽의 약 20%를 관찰합니다. 이 트래픽은 실시간으로 어떤 페이로드가 변형되고 있는지, 어떤 패턴이 떠오르고 있는지, 공격자 도구가 다음에 어디로 움직이는지를 알려줍니다. 두 팀이 이 가시성을 방어로 전환합니다.

첫 번째는 Cloudforce One 입니다. 이는 위협 인텔리전스·연구·운영 팀으로, Cloudflare 보안 조직 내에 있습니다. 네트워크 전반에서 관찰한 정보를 추적된 적, 신흥 캠페인, 침해 지표(IOC) 등으로 가공해 스택 전체가 활용할 수 있게 합니다. 이 작업에서 가장 어려운 부분은 “무엇이 악의적인가”를 아는 것이 아니라 완화까지의 지연이었습니다. 새로운 위협에 대한 정보는 보통 위협 보고서 → 피드 → 기업 방어 체계 순으로 전달돼야 차단에 활용될 수 있습니다. 공격자는 이미 그보다 빠르게 움직이고 있습니다. 우리의 네트워크는 이 격차를 메웁니다: Cloudflare 고객은 이제 Cloudforce One 위협 인텔리전스를 WAF 내부에서 직접 활용해 고위험 트래픽을 차단할 수 있습니다(실시간 위협 인텔리전스 WAF 규칙).

두 번째는 WAF 엔진을 담당하는 팀입니다. 이 팀은 우리 자체 자산 앞에서 실행되는 관리형 규칙세트, WAF Attack Score 뒤의 머신러닝, 그리고 때때로 CVE가 공개되기 전에 규칙을 배포할 수 있게 하는 관계망을 관리합니다. 팀은 전 세계에 분산돼 있으며, PoC가 알려지면 몇 시간 안에 규칙을 출시합니다. 탐지가 배포되면 30초 이내에 전체 네트워크와 모든 Cloudflare 고객에게 전파됩니다. 최근 사례인 React2Shell 은 관리형 WAF 규칙이 우리 자체 자산과 Cloudflare 전체 고객을 보호했으며, 공식 권고가 발표되기 몇 시간 전에 이미 차단을 수행했습니다(React 취약점과 WAF 규칙).

점수 레이어, 애플리케이션 앞에 배치된 방어, 그리고 취약점 주변의 격리 모두 이 두 팀이 보는 것을 기반으로 구축됩니다.

시그니처보다 점수

시그니처 기반 방어는 새로운 익스플로잇이 드물고 변형이 몇 주에 걸쳐 나타나는 시절을 위해 설계되었습니다. Cloudflare의 전통적인 SLA는 **새로운 PoC가 확인된 순간부터 실서비스에 배