이 글은 Cloudflare가 Anthropic의 Mythos Preview라는 보안 특화 LLM을 활용하여 자체 시스템의 잠재적 취약점을 식별하고 해결하는 과정을 다루고 있습니다. Mythos Preview가 기존 모델과 어떻게 다른지, 특히 취약점 연결 구성 및 증명 생성 능력에서 뛰어난 점을 설명하며, 모델의 자발적 거부 문제와 오탐(False Positive) 관리의 어려움을 언급합니다. 궁극적으로 Cloudflare는 효과적인 취약점 탐지를 위해 LLM 자체를 사용하는 것을 넘어, "하네스(Harness)"라는 체계적인 프레임워크가 필수적임을 강조하며, 이를 통해 대규모 코드베이스에서 의미 있는 보안 취약점을 발견하고 관리하는 방법에 대한 통찰력을 제공합니다.

1. Mythos Preview, 보안 LLM의 새로운 지평을 열다 ✨

Cloudflare는 지난 몇 달간 자체 인프라에서 다양한 보안 특화 LLM을 테스트하며 시스템의 잠재적 취약점을 찾아내고 수정해왔습니다. 이 과정에서 가장 주목받았던 모델은 바로 Anthropic의 Mythos Preview인데요. 몇 주 전, Cloudflare는 Project Glasswing의 일환으로 Mythos Preview를 사용해 50개 이상의 자체 저장소에 적용해보고 그 성능과 작동 방식을 면밀히 관찰했습니다.

Mythos Preview는 기존의 일반적인 최첨단 모델들과는 차원이 다른 도구로, 단순히 개선된 수준을 넘어섰다고 평가됩니다. 이전 모델들이 할 수 없었던, 훨씬 정교한 작업을 수행한다는 것이죠. 특히 두 가지 기능이 인상 깊었습니다.

• 공격 체인 구성 (Exploit chain construction): 실제 공격은 단 하나의 버그를 이용하기보다는 여러 작은 공격 원시 요소를 연결하여 작동하는 익스플로잇을 만듭니다. 예를 들어, use-after-free 버그를 임의 읽기/쓰기 원시 요소로 바꾸고, 제어 흐름을 하이재킹하여 ROP(Return-Oriented Programming) 체인을 사용해 시스템을 완전히 제어하는 식이죠. Mythos Preview는 이러한 여러 원시 요소를 조합하여 작동하는 증명을 만들어낼 수 있으며, 그 과정에서 보여주는 추론 능력은 자동화된 스캐너가 아니라 숙련된 연구원의 작업처럼 보였습니다.

• 증명 생성 (Proof generation): 버그를 찾는 것과 그것이 실제로 악용 가능한지 증명하는 것은 별개의 문제입니다. Mythos Preview는 이 두 가지를 모두 해냅니다! 😲 모델은 의심되는 버그를 트리거할 코드를 작성하고, 스크래치 환경에서 컴파일한 다음 실행합니다. 프로그램이 모델이 예상한 대로 작동하면 그것이 바로 증명이 되는 거죠. 만약 작동하지 않으면, 모델은 실패를 읽고 가설을 조정한 후 다시 시도합니다. 이 반복 과정은 모델이 발견하는 버그만큼이나 중요합니다. 왜냐하면 작동하는 증명이 없는 의심스러운 결함은 단순한 추측에 불과하지만, Mythos Preview는 이 간극을 스스로 메워주기 때문입니다.

물론 다른 최첨단 모델들도 같은 테스트를 거치면서 상당수의 버그를 찾아냈고, 일부는 추론 측면에서도 예상보다 좋은 성과를 보였습니다. 하지만 이들 모델은 발견된 조각들을 하나로 엮는 데 어려움을 겪었습니다. 흥미로운 버그를 식별하고 그 중요성에 대해 사려 깊은 설명을 작성했지만, 실제 공격 체인을 완성하지 못하고 악용 가능성 여부를 열어둔 채 멈춰버린 것이죠. Mythos Preview가 달라진 점은 바로 여기에 있습니다. 이 모델은 전통적으로 백로그에 잠자고 있던 낮은 심각도의 버그들을 묶어 하나의 더 심각한 익스플로잇 체인으로 만들 수 있게 되었습니다.

2. 합법적인 취약점 연구 중 발생한 모델의 거부 반응 🤯

Project Glasswing의 일환으로 제공된 Mythos Preview 모델은 일반적으로 사용 가능한 모델(예: Opus 4.7 또는 GPT-5.5)에 적용되는 추가적인 안전장치 없이 제공되었습니다. 그럼에도 불구하고, 모델은 특정 요청에 대해 자발적으로 거부 반응을 보이기도 했습니다. 이는 취약점 탐지에 유용했던 사이버 기능처럼 모델 자체의 내재된 안전장치(emergent guardrails)가 작동하여 합법적인 보안 연구 요청을 때때로 거부하는 상황을 초래했습니다.

하지만 이러한 자발적 거부가 항상 일관적인 것은 아니었습니다. 동일한 작업이라도 다르게 구성하거나 다른 맥락에서 제시하면 완전히 다른 결과를 낳을 수 있다는 점이 발견되었습니다.

"예를 들어, 모델은 처음에는 특정 프로젝트에 대한 취약점 연구를 거부했지만, 프로젝트 환경에 무관한 변경이 있은 후에는 동일한 코드에 대해 동일한 연구를 수행하는 데 동의했습니다. 분석 대상 코드에는 아무런 변화가 없었습니다."

또 다른 경우에는 모델이 코드베이스에서 여러 심각한 메모리 버그를 찾아내고 확인했지만, 시연용 익스플로잇을 작성하는 것을 거부하기도 했습니다. 그러나 같은 요청이라도 다르게 구성하면 다른 답변을 얻을 수 있었고, 모델의 확률적 특성 때문에 동일한 요청조차도 실행할 때마다 다른 결과를 낳을 수 있었습니다. 의미론적으로 동일한 작업이라도 모델에 제시되는 방식과 시점에 따라 정반대의 결과를 초래할 수 있다는 것이죠.

이러한 문제는 중요합니다. 모델의 자발적 거부/안전장치가 실제로 존재하더라도, 그것만으로는 완벽한 안전 경계 역할을 하기에는 충분히 일관적이지 않기 때문입니다. 바로 이러한 이유로 미래에 일반적으로 사용될 수 있는 모든 유능한 사이버 최첨단 모델은 Project Glasswing과 같은 통제된 연구 환경 밖에서도 더 광범위하게 사용될 수 있도록, 이러한 기본 행동 위에 추가적인 안전장치를 포함해야만 합니다.

3. 신호 대 잡음 문제 해결하기 📡

보안 취약점을 분류하는 데 있어 가장 어려운 부분 중 하나는 어떤 버그가 실제이고, 악용 가능한지, 그리고 지금 당장 수정해야 하는지 결정하는 것입니다. 이는 AI 시대 이전에도 어려운 문제였고, AI 기반 취약점 스캐너와 AI 생성 코드는 이 문제를 더욱 복잡하게 만들었습니다. Cloudflare는 이 문제를 해결하기 위해 여러 후속 검증 단계를 구축했습니다.

잡음 비율에 영향을 미치는 두 가지 주요 요인은 다음과 같습니다.

• 프로그래밍 언어: C와 C++와 같이 직접적인 메모리 제어를 허용하는 언어는 버퍼 오버플로, 범위 외 읽기 및 쓰기와 같은 버그 클래스를 발생시킵니다. 반면 Rust와 같은 메모리 안전 언어는 컴파일 시간에 이러한 버그를 제거합니다. 따라서 메모리 비안전 언어로 작성된 프로젝트에서 일관되게 더 많은 오탐(False Positive)이 발생했습니다.
• 모델 편향: 유능한 인간 연구원은 자신이 무엇을 발견했고 얼마나 확신하는지 알려줍니다. 하지만 모델은 그렇지 않습니다. 버그를 찾아달라고 요청하면, 코드에 버그가 있든 없든 모델은 버그를 찾아냅니다. 그 결과는 "어쩌면", "잠재적으로", "이론적으로 가능할 수도 있다"와 같은 애매한 표현으로 가득하며, 이러한 애매모호한 결과가 확실한 결과보다 훨씬 많습니다. 탐색 도구로서는 합리적인 편향일 수 있지만, 분류 대기열에서는 치명적인 문제입니다. 왜냐하면 모든 추측성 발견은 이를 기각하기 위해 인간의 관심과 토큰을 소모하며, 이러한 비용은 수천 개의 발견에서 복합적으로 증가하기 때문입니다.

Mythos Preview는 특히 여러 취약점을 조합하여 작동하는 개념 증명(PoC)을 생성하는 능력에서 상당한 개선을 보였습니다. PoC와 함께 제시되는 발견은 즉시 조치할 수 있는 발견이며, "이것이 정말 실재하는가?"라는 질문에 시간을 낭비할 필요가 없다는 의미입니다.

Cloudflare의 시스템은 의도적으로 많은 것을 보고하도록 조정되어 더 많은(그리고 놓치는 것은 더 적은) 것을 발견하지만, 이는 동시에 많은 잡음을 유발합니다. 그러나 분류 시점에서 Mythos Preview의 출력은 확실히 더 높은 품질을 보여주었습니다. 즉, 애매모호한 발견이 줄어들고, 재현 단계가 더 명확하며, 수정 또는 기각 결정을 내리는 데 드는 노력이 훨씬 줄어든 것입니다.

4. 일반적인 코딩 에이전트가 저장소 분석에 부적합한 이유 😥

작년에 AI를 활용한 취약점 연구를 처음 시작했을 때, Cloudflare는 일반적인 코딩 에이전트를 임의의 저장소에 투입하고 취약점을 발견하도록 요청하는 가장 직관적인 방법을 시도했습니다. 이 접근 방식은 모델이 결과를 생성한다는 점에서는 작동했지만, 실제 코드베이스를 의미 있게 커버하고 가치 있는 발견을 식별하는 데는 효과적이지 않았습니다. 여기에는 크게 두 가지 이유가 있습니다.

• 맥락 (Context): 코딩 에이전트는 기능 구축, 버그 수정, 리팩토링 등 특정 작업 흐름에 맞춰져 있습니다. 많은 소스 코드를 흡수하고, 한 번에 하나의 가설을 유지하며, 이에 대해 반복합니다. 하지만 이는 취약점 연구에는 부적합한 방식입니다. 취약점 연구는 본질적으로 좁고 병렬적이기 때문입니다. 인간 연구원은 특정 대상을 하나 선택하여 철저히 조사합니다. 그 대상은 복잡한 기능 하나일 수도 있고, 보안 경계를 넘나드는 전환일 수도 있으며, 명령 주입(command injection)과 같은 특정 취약점 클래스일 수도 있습니다. 그리고 코드베이스 전체에 걸쳐 수천 번 다른 기능, 보안 경계 또는 취약점 클래스에 대해 동일한 작업을 반복합니다. 수십만 줄의 저장소에 대한 단일 에이전트 세션(하위 에이전트 포함)은 모델의 컨텍스트 창이 가득 차고 압축이 시작되기 전에 표면의 0.1% 정도만 유용하게 다룰 수 있으며, 이 과정에서 중요했을 초기 발견들이 버려질 수 있습니다.

• 처리량 (Throughput): 단일 스트림 에이전트는 한 번에 한 가지 작업만 수행합니다. 하지만 실제 코드베이스는 동시에 여러 구성 요소에 대해 많은 가설을 필요로 하며, 흥미로운 것이 발견되면 추가적으로 작업을 확장할 수 있어야 합니다. 단일 에이전트를 더 강하게 구동할 수도 있지만, 어느 시점에는 모델 자체보다는 상호작용의 형태에 의해 제한을 받게 됩니다. 코딩 에이전트에서 모델을 직접 사용하는 것은 연구원이 이미 단서를 가지고 있고 두 번째 의견을 원할 때 수동 조사에는 적합하지만, 높은 커버리지를 달성하기에는 적절한 도구가 아닙니다. 이 사실을 인정한 후, Cloudflare는 Mythos Preview에게 부적절한 작업을 시키는 것을 멈추고 대신 "하네스(Harness)"를 구축하기 시작했습니다.

5. 하네스가 문제점을 해결하는 방법 🛠️

대규모 작업을 수행하면서 네 가지 중요한 교훈을 얻었고, 이 모든 교훈은 전반적인 실행을 관리할 "하네스"의 필요성을 시사했습니다.

• 좁은 범위가 더 나은 결과를 낳는다: 모델에게 "이 저장소에서 취약점을 찾아라"고 지시하면 모델은 방황합니다. 하지만 "이 특정 함수에서 명령 주입을 찾아라. 위에 이런 신뢰 경계가 있고, 여기 아키텍처 문서가 있으며, 이 영역에 대한 이전 커버리지가 있다"고 지시하면, 연구원이 실제로 할 일에 훨씬 가까운 작업을 수행합니다. 범위를 좁히는 것이 핵심이라는 거죠! 🎯

• 적대적 검토가 잡음을 줄인다: 초기 발견과 대기열 사이에 두 번째 에이전트(다른 프롬프트, 다른 모델, 그리고 자체적인 새로운 발견을 생성할 능력이 없는)를 추가하면, 첫 번째 에이전트가 자신의 작업을 검토할 때 놓쳤을 많은 잡음을 잡아낼 수 있습니다. 두 에이전트를 의도적으로 불일치하게 두는 것이 단순히 한 에이전트에게 조심하라고 지시하는 것보다 훨씬 효과적입니다.

• 체인을 여러 에이전트로 분할하는 것이 더 나은 추론을 낳는다: "이 코드가 버그가 있습니까?"와 "공격자가 시스템 외부에서 이 버그에 실제로 도달할 수 있습니까?"는 두 가지 다른 질문입니다. 그리고 각 질문이 결합된 버전보다 좁기 때문에, 각각의 질문을 별도로 물어볼 때 모델이 더 잘합니다. 복잡한 문제를 분해하여 각 부분을 전문적으로 처리하게 하는 것이 좋습니다.

• 병렬적인 좁은 작업이 하나의 포괄적인 에이전트보다 낫다: 많은 에이전트가 좁게 범위가 지정된 질문에 대해 작업하고 나중에 결과를 중복 제거할 때 커버리지가 향상됩니다. 하나의 에이전트에게 모든 것을 포괄적으로 찾으라고 요청하는 것보다 훨씬 효과적입니다.

이러한 관찰들은 모두 모델의 행동에 관한 것이며, 이를 종합해보면 더 이상 채팅 인터페이스가 아닌 최종 결과를 달성하는 데 도움이 되는 하네스가 필요하다는 것을 알 수 있습니다. 하네스를 구축하는 첫 단계는 간단하며, Cloudflare는 Mythos Preview를 사용하여 기존 하네스를 모델의 강점에 맞춰 구축하고 개선했습니다.

5.1. Cloudflare의 취약점 발견 하네스 🛡️

Cloudflare가 런타임, 엣지 데이터 경로, 프로토콜 스택, 제어 평면 및 의존하는 오픈소스 프로젝트 전반의 실제 코드를 스캔하는 데 사용한 취약점 발견 하네스의 단계별 모습은 다음과 같습니다.

단계	역할	중요성
Recon	에이전트가 저장소를 위에서 아래로 읽고, 각 서브시스템을 담당하는 하위 에이전트로 작업을 분산한 후, 빌드 명령, 신뢰 경계, 진입점 및 예상 공격 표면을 포함하는 아키텍처 문서를 생성합니다. 또한 다음 단계를 위한 초기 작업 대기열을 생성합니다.	모든 하위 에이전트에게 공유된 맥락을 제공하여 방황 문제를 줄입니다.
Hunt	각 작업은 하나의 공격 클래스와 범위 힌트의 조합입니다. 헌터(버그를 찾는 에이전트)는 동시(일반적으로 약 50개)에 실행되며, 각각 소수의 탐색 하위 에이전트로 작업을 분산합니다. 각 헌터는 작업별 스크래치 디렉토리에서 PoC 코드를 컴파일하고 실행하는 도구에 접근할 수 있습니다.	대부분의 작업이 이곳에서 이루어집니다. 하나의 포괄적인 에이전트가 아니라, 많은 좁은 작업을 병렬로 처리합니다.
Validate	독립적인 에이전트가 코드를 다시 읽고 원래 발견을 반증하려고 시도합니다. 이 에이전트는 다른 프롬프트를 사용하며, 자체적인 새로운 발견을 생성할 능력은 없습니다.	헌터가 자신의 작업을 검토할 때 놓쳤을 상당량의 잡음을 잡아냅니다.
Gapfill	헌터는 자신이 다루었지만 철저히 커버하지 못한 영역을 표시합니다. 이 영역은 다른 패스를 위해 다시 대기열에 추가됩니다.	모델이 이미 성공한 공격 클래스 쪽으로 표류하는 경향을 상쇄합니다.
Dedupe	동일한 근본 원인을 공유하는 발견은 단일 기록으로 통합됩니다.	변형 분석은 중복으로 대기열을 부풀리는 방식이 아니라 기능입니다.
Trace	공유 라이브러리에서 확인된 각 발견에 대해 추적 에이전트는 (소비자 저장소당 하나의 인스턴스) 작업을 분산하고, 교차 저장소 심볼 인덱스를 사용하여 공격자가 제어하는 입력이 시스템 외부에서 버그에 실제로 도달하는지 여부를 결정합니다.	"결함이 있다"를 "도달 가능한 취약점이 있다"로 바꿉니다. 이 단계가 가장 중요합니다.
Feedback	도달 가능한 추적은 버그가 실제로 노출되는 소비자 저장소에서 새로운 헌트 작업이 됩니다.	루프를 닫습니다. 파이프라인은 실행될수록 개선됩니다.
Report	에이전트는 미리 정의된 스키마에 따라 구조화된 보고서를 작성하고, 해당 스키마에 대한 유효성 검사 오류를 스스로 수정하며, 보고서를 수집 API에 제출합니다.	출력은 자유 형식의 산문이 아니라 쿼리 가능한 데이터입니다.

6. 보안 팀에게 주는 시사점 💡

Mythos Preview에 대한 다른 보안 리더들의 가장 큰 반응은 속도에 대한 것이었습니다. 즉, 더 빠르게 스캔하고, 더 빠르게 패치하며, 응답 주기를 단축해야 한다는 것이죠. Cloudflare가 대화했던 여러 팀은 이제 CVE 공개부터 프로덕션 패치까지 2시간 SLA(Service Level Agreement)를 운영하고 있습니다. 공격자의 타임라인이 짧아지면 방어자의 타임라인도 그에 맞춰 짧아져야 한다는 생각은 이해할 만합니다. 하지만 더 빠른 것만으로는 충분하지 않을 것이며, 많은 팀이 이 사실을 어렵게 배우는 데 많은 시간과 노력, 비용을 들이게 될 것이라고 Cloudflare는 생각합니다.

더 빠르게 패치한다고 해서 패치를 생성하는 파이프라인의 형태가 바뀌는 것은 아닙니다. 회귀 테스트(regression testing)에 하루가 걸린다면, 이를 건너뛰지 않고 2시간 SLA를 달성할 수는 없습니다. 그리고 회귀 테스트를 건너뛰면 발생하는 버그는 원래 패치하려던 버그보다 더 나쁜 경향이 있습니다. Cloudflare는 모델이 자체 패치를 작성하도록 허용했을 때 이와 비슷한 경험을 했습니다. 몇몇 패치가 원래 버그는 수정했지만, 코드가 의존하는 다른 무언가를 조용히 망가뜨리는 것을 목격했죠.

더 어려운 질문은 취약점 주변의 아키텍처가 어떤 모습이어야 하는가입니다. 원칙은 버그가 존재하더라도 공격자가 악용하기 어렵게 만드는 것입니다. 그래서 취약점이 공개되는 시점과 패치되는 시점 사이의 간극이 덜 중요하도록 만드는 것이죠. 이는 애플리케이션 앞에 위치하여 버그에 도달하는 것을 차단하는 방어 체계를 의미합니다. 또한, 코드의 한 부분의 결함이 공격자에게 다른 부분에 대한 접근 권한을 주지 않도록 애플리케이션을 설계하는 것을 의미합니다. 그리고 개별 팀이 배포하기를 기다리는 대신, 코드가 실행되는 모든 곳에 동시에 수정 사항을 배포할 수 있는 능력을 의미합니다.

이 주제는 양면성을 가집니다. Cloudflare가 자체 코드에서 버그를 찾는 데 도움이 된 동일한 기능은 잘못된 손에 들어가면 인터넷상의 모든 애플리케이션에 대한 공격 측면을 가속화할 것입니다. Cloudflare는 수백만 개의 애플리케이션 앞에 위치하며, 위에서 설명한 아키텍처 원칙들은 Cloudflare의 제품이 고객을 대신하여 적용하도록 구축된 바로 그 원칙들입니다. Cloudflare는 향후 몇 주 내로 고객에게 이것이 무엇을 의미하는지 더 자세히 공유할 예정입니다.

마치며 ✨

Cloudflare는 Project Glasswing을 통해 Anthropic의 Mythos Preview가 보안 취약점 발견에 있어 단순한 도구를 넘어, 숙련된 연구원과 같은 복잡한 추론과 증명 생성 능력을 보여주었음을 확인했습니다. 하지만 동시에 모델의 일관성 없는 자발적 거부 반응이나 잡음 문제 등 여전히 해결해야 할 과제들도 분명히 존재합니다.

궁극적으로 Cloudflare는 AI 모델 자체의 성능을 넘어, '하네스'라는 체계적인 프레임워크가 대규모 코드베이스에서 의미 있는 취약점을 효과적으로 탐지하고 관리하는 데 필수적임을 강조합니다. 이 하네스는 Recon, Hunt, Validate, Gapfill, Dedupe, Trace, Feedback, Report의 8가지 단계로 이루어져 있으며, 각 단계는 모델의 강점을 극대화하고 약점을 보완하여 전체적인 보안 효율성을 높이도록 설계되었습니다.

이번 경험은 보안 팀이 단순히 더 빠르게 패치하는 것을 넘어, 취약점 발생 시에도 공격을 어렵게 만드는 아키텍처적 방어에 집중해야 함을 시사합니다. AI 기술이 공격과 방어 모두를 가속화하는 만큼, 보안 팀은 새로운 시대에 맞춰 방어 전략을 재고하고 혁신해야 할 것입니다. Cloudflare는 이러한 경험을 바탕으로 고객들을 위한 더욱 강력한 보안 솔루션을 제공하는 데 힘쓸 것이며, 이 분야에 대한 지속적인 연구와 공유를 통해 더 안전한 디지털 환경을 만들어갈 것입니다. 🚀