Project Glasswing과 Mythos Preview 소개
Cloudflare는 최근 몇 달간 자사 인프라에 대해 다양한 보안 특화 LLM(Large Language Model)을 시험해 왔습니다. 이 모델들은 Cloudflare 시스템 내의 잠재적 취약점을 찾아내어 수정에 활용될 뿐만 아니라, 동시에 공격자가 최신 모델을 사용했을 때 어떤 일이 가능해지는지를 미리 보여주는 역할도 합니다. 그 가운데서도 Anthropic이 Project Glasswing을 통해 일부 협력 기업들에게만 제공한 Mythos Preview는 가장 큰 주목을 받았고, Cloudflare는 이 모델을 자사 50여 개 저장소에 직접 겨눠보며 무엇을 발견하고 어떻게 동작하는지를 면밀히 관찰했습니다.
Project Glasswing은 Anthropic이 사이버 보안 영역에 특화된 프론티어 모델(Frontier Model)을 일부 파트너에게 제한적으로 공개해, 실제 운영 환경에서의 활용 가능성과 위험성을 함께 평가하기 위한 프로그램입니다. 일반 공개 모델인 Claude Opus 4.7이나 GPT-5.5와 달리, Mythos Preview는 일반 사용자용 추가 안전장치(safeguard)가 의도적으로 제거된 상태에서 "공격자가 손에 쥐었을 때 무엇이 가능한지" 를 사전에 측정하는 데 초점이 맞춰져 있습니다. 즉, 보안 연구의 적극적인 도구이자, 동시에 공격 능력의 미래에 대한 조기 경보 시스템입니다.
이번 글은 단순한 모델 자랑이 아니라, "왜 일반적인 코딩 에이전트를 저장소에 겨누는 방식은 통하지 않는가" , 그리고 "대규모 코드베이스에 LLM 기반 취약점 탐색을 적용하려면 어떤 에이전트 하니스(Agent Harness)와 파이프라인이 필요한가" 라는, AI 에이전트 시스템을 운영하려는 모든 팀에게 직접적으로 도움이 되는 실전 보고서로 읽을 수 있습니다. Cloudflare는 모델 한 대를 더 똑똑하게 만드는 것보다, 여러 좁은 임무를 병렬로 수행하는 다수 에이전트와 이를 조율하는 파이프라인이 훨씬 더 큰 격차를 만든다는 점을 강조합니다.
Mythos Preview가 바꾼 두 가지 능력
Cloudflare는 Mythos Preview를 "이전 범용 프론티어 모델과의 단순한 정교화가 아니라, 다른 종류의 도구가 다른 종류의 일을 하기 시작한 것" 으로 평가합니다. 따라서 사과 대 사과 식의 벤치마크(Benchmark) 비교보다는, Mythos Preview가 실제로 무엇을 해냈는지를 두 가지 능력으로 정리하는 편이 더 유용합니다.
익스플로잇 체인 구성(Exploit Chain Construction): 실제 공격은 단일 버그로 성공하지 않습니다. 여러 개의 작은 공격 원시(attack primitive)를 연결해 동작하는 공격으로 조립해야 합니다. 예를 들어, use-after-free 버그를 임의 읽기/쓰기 원시로 전환한 뒤, 제어 흐름을 가로채고(control flow hijack) Return-Oriented Programming(ROP) 체인을 사용해 시스템을 장악하는 식입니다. Mythos Preview는 이러한 여러 원시를 가져와 어떻게 결합하면 동작하는 증명이 되는가 를 스스로 추론합니다. 그 과정에서 보여주는 reasoning은 자동화 스캐너의 출력이라기보다 시니어 보안 연구원의 분석 노트 에 더 가깝습니다.
증명 생성(Proof Generation): "버그가 있다" 와 "실제로 익스플로잇 가능하다" 는 전혀 다른 명제입니다. Mythos Preview는 의심되는 버그를 트리거하는 코드를 직접 작성하고, 임시 환경에서 컴파일한 뒤 실행해 봅니다. 프로그램이 예상대로 동작하면 그것이 증명이고, 그렇지 않으면 모델이 실패 메시지를 읽고 가설을 수정한 뒤 다시 시도합니다. 발견된 결함에 동작하는 증명이 없다면 그것은 추측에 불과하다 는 보안 업계의 오래된 격언을, 모델이 스스로 닫아내기 시작했다는 의미입니다.
다른 프론티어 모델들도 동일한 하니스에서 비슷한 버그들을 일정 부분 찾아냈고, 추론 측면에서도 예상보다 멀리 갔습니다. 차이는 조각들을 꿰매는 지점 에서 갈렸습니다. 일반 모델들은 흥미로운 버그를 식별하고 그 의미를 사려 깊게 서술한 뒤 멈춰버려, 실제 익스플로잇 체인은 미완으로 남고 익스플로잇 가능성에 대한 질문도 열린 채 끝났습니다. Mythos Preview는 전통적으로 백로그에 묻혀 보이지 않던 저심각도 버그들을 묶어 하나의 더 심각한 익스플로잇으로 연결해낼 수 있다는 점이 결정적인 변화였습니다.
모델의 자발적 거부와 안전장치의 한계
Project Glasswing을 통해 제공된 Mythos Preview는 일반 공개 모델에 적용되는 추가 안전장치가 없는 상태였습니다. 그럼에도 모델은 특정 요청에 대해 스스로 거부 의사를 표시했습니다. 취약점 탐색에 유용했던 사이버 능력과 마찬가지로, 모델 내부에는 학습 과정에서 생긴 창발적 가드레일(emergent guardrails) 이 존재하며, 이것이 때때로 정당한 보안 연구 요청까지 가로막곤 합니다.
문제는 이러한 자발적 거부가 일관적이지 않다 는 점입니다. Cloudflare가 관찰한 사례 중 하나는 동일한 프로젝트에 대해 처음에는 취약점 연구를 거부했다가, 코드와는 무관한 프로젝트 환경 설정의 사소한 변화 만으로 같은 연구를 수행해주는 경우였습니다. 또 다른 사례에서는 모델이 코드베이스에서 여러 개의 심각한 메모리 버그를 찾아 확인까지 했음에도, 동작하는 시연 익스플로잇 작성은 거부했습니다. 같은 요청이라도 표현 방식만 바꾸면 다른 답을 내놓고, 모델의 확률적 특성(probabilistic nature) 때문에 동일한 요청도 실행할 때마다 결과가 달라질 수 있습니다. 의미상 동등한 작업이 제시 방식에 따라 정반대 결과를 낼 수 있다는 것이 핵심 관찰입니다.
이것이 중요한 이유는, 모델의 자발적 가드레일이 실재하더라도 그 자체만으로는 완전한 안전 경계로 기능하기에 충분하지 않다는 점입니다. 따라서 향후 일반 공개될 모든 강력한 사이버 프론티어 모델 에는 이 기본 행동 위에 추가 안전장치를 반드시 얹어야 한다는 것이 Cloudflare의 결론입니다. Project Glasswing 같은 통제된 연구 맥락에서 벗어나 더 넓은 사용으로 가려면, 사전적 안전장치 설계가 모델 능력 향상만큼이나 중요한 작업이 됩니다.
시그널 대 노이즈 문제
보안 취약점 분류(triage)에서 가장 어려운 부분은, 어떤 버그가 진짜이고 어떤 것이 익스플로잇 가능하며 어떤 것을 지금 고쳐야 하는지를 판단하는 일입니다. 이는 AI 이전 시대에도 어려운 문제였고, AI 기반 취약점 스캐너와 AI 생성 코드는 이 문제를 더 악화시켰습니다. Cloudflare는 이에 대응하기 위해 여러 단계의 사후 검증(post-validation) 절차를 구축해 왔습니다. 노이즈율을 좌우하는 두 가지 큰 요인은 다음과 같습니다.
프로그래밍 언어: C와 C++는 직접적인 메모리 제어를 제공하며, 그 대가로 버퍼 오버플로(Buffer Overflow), 범위 외 읽기/쓰기(Out-of-bounds Read/Write) 같은 버그 클래스를 항상 안고 갑니다. Rust처럼 메모리 안전성을 컴파일 타임에 보장하는 언어에서는 이런 클래스의 버그가 원천적으로 제거됩니다. Cloudflare 역시 메모리 비안전 언어로 작성된 프로젝트에서 일관되게 더 많은 거짓 양성(False Positive)이 발생하는 것을 확인했습니다.
모델 편향(Model Bias): 좋은 인간 연구자는 무엇을 발견했고 그것에 대해 얼마나 확신하는지를 말해줍니다. 모델은 그렇지 않습니다. "버그를 찾아라" 라고 요청하면 모델은 코드에 버그가 있든 없든 어떻게든 무엇을 찾아냅니다. 결과물은 possibly, potentially, could in theory 같은 헷지(hedge) 표현으로 점철되어 있고, 헷지된 발견들은 단단한 발견보다 압도적으로 많습니다. 탐색적 도구에는 합리적인 편향이지만, 분류 큐(triage queue) 에 들어오는 순간 추측성 발견 하나하나가 사람의 주의와 토큰을 소비하게 만들고, 그 비용은 수천 건의 발견 위에서 폭발적으로 누적됩니다.
Mythos Preview는 바로 이 지점에서 명확한 개선 을 보여줍니다. 여러 취약점을 따로따로 보고하는 대신 동작하는 PoC로 결합해주는 능력 덕분에, "이게 진짜인가?" 를 묻는 데 들어가는 시간이 크게 줄어듭니다. Cloudflare의 하니스는 의도적으로 과보고 쪽으로 튜닝되어 있어 더 많이 보고 덜 놓치도록 설계되어 있는데, 그만큼 많은 노이즈도 들어옵니다. 그런 환경에서도 Mythos Preview의 출력은 눈에 띄게 헷지가 적고, 재현 단계가 명확하며, 수정/기각 결정에 도달하기까지의 작업이 적다 는 차이를 보였습니다.
왜 범용 코딩 에이전트를 저장소에 겨누는 방식은 통하지 않는가
Cloudflare가 작년에 AI 보조 취약점 연구를 처음 시작했을 때 가장 먼저 떠올린 방법은 범용 코딩 에이전트를 저장소에 겨눠 취약점을 찾아내라고 시키는 것이었습니다. 이 접근은 결과물을 만들어낸다 는 의미에서는 동작하지만, 실제 코드베이스에 대해 의미 있는 커버리지와 가치 있는 발견 을 만들어내는 데에는 동작하지 않습니다. 그 이유는 크게 두 가지입니다.
컨텍스트(Context): Claude Code나 Cursor, Aider 같은 코딩 에이전트는 기능 구현, 버그 수정, 리팩토링 처럼 단일 작업 흐름에 최적화되어 있습니다. 많은 양의 소스 코드를 한꺼번에 흡수하고, 한 번에 하나의 가설을 들고 거기에 맞춰 반복하도록 튜닝되어 있습니다. 그러나 취약점 연구는 본질적으로 좁고 병렬적인 일입니다. 인간 연구자는 한 가지 구체적인 대상(복잡한 단일 기능, 보안 경계 전환, 명령어 주입(Command Injection) 같은 특정 취약점 클래스)을 골라 철저히 파보고, 그 다음 다시 다른 기능·경계·클래스에 대해 같은 작업을 수천 번 반복합니다. 단일 에이전트 세션은 서브에이전트(subagent)를 동원하더라도, 10만 줄 짜리 저장소의 표면적 중 0.1% 정도만 의미 있게 다루다가 컨텍스트 윈도우(context window)가 가득 차고 컨텍스트 압축(compaction)이 발동되면서 초기 발견들을 버려버릴 수 있습니다.
처리량(Throughput): 단일 스트림 에이전트는 한 번에 한 가지 일을 하지만, 실제 코드베이스는 많은 가설을 많은 컴포넌트에 동시에 던질 수 있어야 하고, 흥미로운 단서가 발견되면 그 위로 더 펼쳐 나갈 수 있어야 합니다. 에이전트 하나를 더 세게 굴릴 수는 있지만, 어느 시점부터는 모델이 아니라 상호작용의 형태 자체 가 병목이 됩니다. 결국 모델을 코딩 에이전트 안에서 직접 쓰는 것은 연구자가 이미 단서를 갖고 있어 추가 검토자가 필요할 때 에는 훌륭하지만, 높은 커버리지 가 목적이라면 잘못된 도구라는 결론에 이르게 됩니다.
이 점을 받아들이고 나서 Cloudflare는 Mythos Preview에 잘못된 일을 시키려는 시도를 멈추고, 대신 그 위에 적절한 형태의 하니스를 짓기 시작했습니다.
하니스가 실제로 고치는 것
대규모로 작업을 돌려보며 도출한 네 가지 교훈은, 모두 하나의 방향을 가리켰습니다. 전체 실행을 관리하는 하니스가 필요하다는 것입니다.
좁은 범위가 더 좋은 발견을 만든다(Narrow scope produces better findings): "이 저장소에서 취약점을 찾아라" 라는 지시는 모델을 방황하게 만듭니다. "이 특정 함수에서 명령어 주입을 찾되, 위쪽 신뢰 경계는 이렇고, 여기 아키텍처 문서가 있고, 이 영역에 대한 이전 커버리지는 이렇다" 라고 말하는 쪽이 실제 연구자가 하는 일에 훨씬 가까운 결과를 만듭니다.
적대적 리뷰가 노이즈를 줄인다(Adversarial review reduces noise): 초기 발견과 큐 사이에, 다른 프롬프트, 다른 모델, 그리고 자체적으로 새로운 발견을 만들 능력이 없는 두 번째 에이전트를 끼워 넣으면, 첫 번째 에이전트가 자기 결과를 점검할 때 놓치는 노이즈를 상당량 잡아냅니다. 한 에이전트에게 조심하라 고 말하는 것보다, 두 에이전트를 의도적인 의견 충돌 상태에 두는 편이 훨씬 효과적입니다.
체인을 여러 에이전트로 쪼개면 추론이 좋아진다(Splitting the chain across agents produces better reasoning): "이 코드에 버그가 있는가?" 와 "외부에서 공격자가 실제로 이 버그에 도달할 수 있는가?" 는 서로 다른 질문이고, 모델은 두 질문을 따로 받을 때 각각에 대해 더 잘 답합니다. 각 질문이 묶었을 때보다 더 좁기 때문입니다.
병렬의 좁은 작업이 하나의 망라 에이전트를 이긴다(Parallel narrow tasks beat one exhaustive agent): 좁게 정의된 질문을 다수 에이전트에게 병렬로 던지고 결과를 사후에 중복 제거하는 편이, 한 에이전트에게 모든 것을 빠짐없이 보라 고 시키는 것보다 커버리지가 좋습니다.
이 네 가지 관찰은 모두 모델 행동 에 관한 것이지만, 그것들을 합치면 더 이상 채팅 인터페이스가 아닌 최종 결과를 달성하도록 돕는 하니스 의 모습이 나타납니다. 흥미롭게도 이 하니스의 첫 단계 자체를 Cloudflare는 Mythos Preview에게 도움을 청해 작성했고, 모델의 강점에 맞춰 기존 하니스를 개선해 나갔습니다.
8단계 취약점 발견 하니스
다음은 Cloudflare가 실제 런타임, 엣지 데이터 경로, 프로토콜 스택, 컨트롤 플레인, 그리고 의존하는 오픈소스 프로젝트에 적용한 취약점 발견 하니스의 단계별 구조입니다.
| 단계 | 무엇을 하는가 | 왜 중요한가 |
|---|---|---|
| Recon (정찰) | 한 에이전트가 저장소를 위에서 아래로 읽고, 서브시스템별 서브에이전트로 펼쳐 빌드 명령어·신뢰 경계·진입점·예상 공격 표면을 담은 아키텍처 문서를 만들고, 다음 단계의 초기 작업 큐를 생성 | 모든 하위 에이전트에 공유 컨텍스트를 부여하여 방황 문제 를 줄임 |
| Hunt (탐색) | 각 작업은 공격 클래스 1개 + 범위 힌트. 약 50개의 헌터가 동시에 실행되며 각 헌터는 다시 소규모의 탐색 서브에이전트로 펼쳐짐. 각 헌터는 작업별 임시 디렉터리에서 PoC 코드를 컴파일·실행할 수 있는 도구 보유 | 망라 에이전트 하나가 아닌, 좁은 작업의 대규모 병렬화 가 일어나는 핵심 단계 |
| Validate (검증) | 독립된 에이전트가 코드를 다시 읽고 원래 발견을 반증 하려 시도. 다른 프롬프트를 쓰고 자체 발견을 낼 수 없음 | 헌터가 자기 결과를 점검할 때 놓치는 노이즈를 상당량 포착 |
| Gapfill (간극 메우기) | 헌터가 건드렸지만 충분히 다루지 못한 영역을 표시하면, 그 영역이 다시 큐로 재투입 | 모델이 이미 성공한 공격 클래스로 쏠리는 경향을 상쇄 |
| Dedupe (중복 제거) | 동일 원인 근거를 공유하는 발견들을 하나의 레코드로 병합 | 변종 분석(variant analysis) 을 기능으로 살리되 중복으로 큐를 부풀리지 않음 |
| Trace (도달성 추적) | 공유 라이브러리에서 확인된 발견 각각에 대해, 소비자 저장소(consumer repository) 1개당 1개의 트레이서 에이전트가 펼쳐져 크로스 레포 심볼 인덱스를 활용해 공격자 입력이 외부에서 실제로 그 버그에 도달 하는지 판정 | "결함이 있다" 를 "도달 가능한 취약점이 있다" 로 바꾸는, 가장 중요한 단계 |
| Feedback (피드백) | 도달 가능한 추적 결과가, 실제로 노출된 소비자 저장소 에 새로운 헌트 작업으로 환원 | 파이프라인이 돌수록 스스로 더 좋아지는 피드백 루프 형성 |
| Report (보고) | 한 에이전트가 사전 정의된 스키마에 맞춰 구조화된 보고서를 작성하고, 스키마 검증 오류는 스스로 수정한 뒤 ingest API 에 제출 | 출력은 자유 서술이 아니라 질의 가능한 데이터(queryable data) 가 됨 |
이 구조의 본질은 "모델을 똑똑하게 만들기" 가 아니라 "좁은 일을 잘하도록 사람이 모델을 둘러싸 주기" 입니다. 보안 연구뿐만 아니라, 코드 리뷰, 대규모 정적 분석(Static Analysis), 또는 SBOM(Software Bill of Materials) 기반 의존성 감사처럼 넓고 좁은 질문이 동시에 필요한 모든 영역에 일반화될 수 있는 패턴입니다.
보안 팀이 받아들여야 할 새로운 질문
Cloudflare에 따르면, 다른 보안 리더들이 Mythos Preview에 대해 가장 강하게 보인 반응은 속도 였다고 합니다. 더 빠르게 스캔하고, 더 빠르게 패치하고, 대응 사이클을 압축하자 는 것입니다. 일부 팀은 이미 CVE 공개부터 프로덕션 패치까지 두 시간 SLA 로 운영한다고 합니다. 공격자 타임라인이 짧아지면 방어자 타임라인도 짧아져야 한다는 본능적 반응이고, Cloudflare는 그것만으로는 충분하지 않을 것 이라고 단언합니다.
핵심은 패치를 더 빠르게 한다고 해서 패치를 만드는 파이프라인의 형태 가 바뀌지는 않는다는 점입니다. 회귀 테스트(regression testing)에 하루가 걸린다면 그것을 건너뛰지 않고서는 두 시간 SLA에 도달할 수 없고, 회귀 테스트를 건너뛰고 배포한 패치는 원래 버그보다 더 나쁜 버그를 낳는 경향 이 있습니다. Cloudflare는 모델에게 자체 패치를 작성하게 했다가, 원래 버그는 고쳤지만 그 코드가 의존하던 다른 무언가를 조용히 깨뜨린 패치가 나간 경험을 통해 이 교훈을 얻었다고 밝혔습니다.
"패치를 더 빠르게 만드는 것이 아니라, 취약점 주변의 아키텍처 가 어떤 모습이어야 하는지가 더 어려운 질문이다."
이 원칙은 버그가 존재하더라도 공격자가 그것을 익스플로잇하기 더 어렵게 만드는 것이고, 그 결과 공개와 패치 사이의 간극이 덜 중요해지도록 만드는 것입니다. 구체적으로는, 애플리케이션 앞단에 위치해 버그에 도달하는 것 자체를 차단하는 방어막, 코드 한 부분의 결함이 다른 부분으로 권한을 확장하지 못하도록 하는 최소 권한(Least Privilege) 기반 격리, 그리고 코드가 동작하는 모든 위치에 동시에 수정을 배포할 수 있는 일괄 배포 체계가 함께 갖춰져야 합니다. 이는 Cloudflare Workers나 Cloudflare One, WAF(Web Application Firewall) 같은 자사 제품군이 지향해온 방향 과 정확히 일치한다고 Cloudflare는 강조합니다.
양날의 검: 동일 능력의 공격 측 가속
Cloudflare는 이 주제가 양날의 검 임을 분명히 합니다. 자사 코드의 버그를 찾는 데 도움이 된 동일한 능력이, 잘못된 손에 들어가면 인터넷상의 모든 애플리케이션을 대상으로 한 공격 을 가속할 수 있습니다. Cloudflare는 수백만 개의 그러한 애플리케이션 앞에 위치하고 있으며, 위에서 설명한 아키텍처 원칙들은 자사 제품이 고객을 대신해 적용하도록 설계된 바로 그 원칙들입니다.
이 글이 시사하는 더 큰 그림은, AI 에이전트가 공격과 방어 양쪽 모두의 비용 곡선을 동시에 끌어내린다는 것입니다. 비용 곡선이 평행 이동하는 동안 상대적 비대칭성 은 그대로 유지되거나 오히려 공격자에게 유리해질 수 있습니다. 방어자가 모델 한 대를 더 빠르게 만드는 데 시간을 쓰는 동안, 공격자는 같은 모델을 수십, 수백 개의 좁은 임무로 병렬화 하는 하니스를 만들어 낼 수 있습니다. 따라서 모델의 성능 이 아닌 모델을 둘러싼 시스템 설계 가, 가까운 미래의 사이버 보안 경쟁력을 좌우하는 핵심 변수가 될 가능성이 높습니다.
AI 에이전트 시스템을 운영하려는 팀을 위한 시사점
이 보고서가 보안 영역 바깥에서도 의미를 갖는 이유는, 대규모 코드베이스에 LLM 기반 에이전트를 적용해 본 매우 드문 1차 자료 라는 점에 있습니다. 보안 도메인이 아니더라도 다음과 같은 시사점은 광범위하게 적용됩니다.
- 단일 거대 에이전트보다 다수의 좁은 에이전트가 낫다: 컨텍스트 윈도우와 추론 일관성의 현실적 한계는 모델 크기가 아닌 작업 분할 로 우회해야 합니다.
- 저자와 비판자를 분리하라: 같은 모델이 자기 결과를 검증하는 것은 거의 항상 불충분하며, 서로 다른 프롬프트와 가능하면 다른 모델로 구성된 적대적 리뷰어 가 노이즈를 크게 줄입니다.
- 출력을 자유 서술이 아닌 스키마 기반 데이터로 강제하라: 모델이 스스로 스키마 검증 오류를 수정하도록 시키면, 다운스트림 시스템이 질의 가능한 결과를 받습니다.
- 하니스 자체를 모델과 함께 진화시켜라: Cloudflare는 하니스의 일부를 Mythos Preview 자신에게 작성하게 했습니다. 모델의 강점에 하니스를 맞추는 메타 루프가 결정적입니다.
- 속도가 아니라 아키텍처를 사라: 패치 속도 경쟁은 한계가 명확하며, 버그가 있어도 도달할 수 없게 만드는 구조적 방어가 장기적으로 더 큰 가치를 만듭니다.
Project Glasswing: what Mythos showed us 소개 블로그
Anthropic Project Glasswing 소개
이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. 
파이토치 한국 사용자 모임
이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일
로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 