「코딩 에이전트 (Coding Agent)를 자사 리포지토리 (Repository)로 향하게 하여, 『취약점을 찾아줘』라고 부탁한다」──직관적인 생각입니다. 하지만 이것은 제대로 실패합니다. Cloudflare가 Anthropic의 보안 특화 모델인 Mythos Preview를 사용하여, 자사의 50개 이상의 리포지토리(런타임, 에지 데이터 경로, 프로토콜 스택, 컨트롤 플레인, 의존하고 있는 OSS)를 실제로 스캔한 Project Glasswing의 보고서는, 왜 단순한 방식이 실패하는지, 그리고 대신 무엇이 효과적인지를 명확하게 보여줍니다.

그리고 결론은 지금까지의 기사들과 맥을 같이 합니다──주역은 모델이 아니라 harness입니다. 순서대로 기술적인 내용까지 살펴보겠습니다.

harness 이야기를 하기 전에, 토대가 되는 모델이 무엇을 할 수 있는지 파악해 두겠습니다. Cloudflare는 「이것은 이전 세대의 범용 프론티어 모델 (Frontier Model)의 개량판이 아니라, 다른 종류의 도구가 다른 종류의 일을 하고 있는 것」이라고 단언하며, 특히 두 가지 능력을 꼽습니다.

① 익스플로잇 체인 (Exploit Chain) 구축. 현실의 공격은 단 하나의 버그로 완결되는 경우가 드뭅니다. 작은 「공격 프리미티브 (Attack Primitive)」를 여러 개 연결해야 비로소 작동하는 익스플로잇이 됩니다. 예를 들어, use-after-free (해제 후 사용) 버그를 「임의의 읽기/쓰기」 프리미티브로 바꾸고, 제어 흐름을 탈취하여, ROP (return-oriented programming) 체인으로 시스템을 완전히 장악하는 식입니다. Mythos Preview는 이러한 프리미티브를 여러 개 다루며, 어떻게 조합해야 작동하는 증명이 될지를 추론할 수 있습니다. 그 과정에서의 사고는 자동 스캐너의 출력이라기보다, 시니어 연구자의 작업처럼 보인다고 보고서는 말합니다.

② 증명 (PoC, Proof of Concept) 생성. 버그를 찾는 것과 그것이 정말로 악용 가능한지 증명하는 것은 별개의 문제입니다. Mythos Preview는 두 가지를 모두 수행합니다. 의심스러운 버그를 트리거하는 코드를 작성하고, 일회용 작업 환경에서 컴파일하여 실행합니다. 프로그램이 예상대로 작동하면 그것이 증명입니다. 작동하지 않으면 실패를 읽고 가설을 수정하여 다시 시도합니다. 이 루프 자체가 버그 발견만큼이나 중요하며, 「작동하는 증명이 없는 의심」은 단순한 추측으로 끝나기 쉬운 지점을 Mythos Preview는 스스로 그 간극을 메웁니다.

이 부분이 핵심인데, 동일한 harness에 다른 프론티어 모델을 통과시켜도 많은 근본적인 버그를 찾아낼 수 있었고, 추론 면에서도 기대 이상으로 진전되는 경우도 있었습니다. 차이가 벌어진 것은 「파편을 꿰매는」 단계입니다. 어떤 모델은 흥미로운 버그를 특정하고 왜 중요한지를 정성껏 작성하지만, 거기서 멈춥니다──체인은 미완성인 채로, 악용 가능성은 불투명한 상태로 남습니다. Mythos Preview로 달라진 점은, 기존 방식이라면 백로그 (Backlog)에 묻혀 보이지 않았을 저심각도 버그를 하나의 더 심각한 익스플로잇으로 연쇄시킬 수 있다는 점이었습니다.

즉, 모델은 확실히 진보했습니다. 하지만──라고 보고서는 여기서 다시 harness 이야기로 돌아갑니다.

Cloudflare는 작년에 AI 지원 취약점 연구를 시작했을 때, 가장 단순한 발상을 시도했습니다. 「범용 코딩 에이전트를 적당한 리포지토리로 향하게 하여 취약점을 찾게 한다」는 것입니다. 이것은 「findings(결과물)는 나온다」는 의미에서는 작동합니다. 하지만 실제 코드베이스를 의미 있는 범위로 커버하고 가치 있는 발견을 내놓는다는 의미에서는 작동하지 않습니다. 이유는 두 가지입니다.

① 문맥 (Context). 코딩 에이전트는 「하나의 집중된 작업 흐름」──기능을 만들거나, 버그를 고치거나, 리팩터링(Refactoring)하는 것──에 튜닝되어 있습니다. 대량의 소스를 읽어 들이고, 한 번에 하나의 가설을 유지하며, 그것에 대해 반복합니다. 이는 취약점 연구와는 형태가 완전히 반대입니다. 취약점 연구는 본질적으로 「좁고 병렬적」입니다. 인간 연구자는 어떤 한 지점(하나의 복잡한 기능, 보안 경계를 넘나드는 전이, 혹은 커맨드 인젝션(Command Injection)과 같은 특정 취약점 클래스 = 공격자의 입력이 최종적으로 셸 커맨드로 실행되는 것 등)을 선택하여 철저하게 조사합니다. 그리고 그것을 다른 기능, 경계, 취약점 클래스에 대해 코드베이스 전체에서 수천 번 반복합니다. 10만 행의 리포지토리에 대해 단일 에이전트의 세션은, 서브 에이전트를 사용하더라도 컨텍스트 윈도우 (Context Window)가 가득 차서 컴팩션 (Compaction, 문맥 압축)이 실행되기 전에 공격면의 0.1% 정도밖에 의미 있는 형태로 커버하지 못합니다. 게다가 그 컴팩션이 나중에 효과를 발휘해야 했을 초기 발견을 버려버리는 경우도 있습니다.

② 처리량 (Throughput). 단일 스트림의 에이전트는 한 번에 하나씩밖에 수행할 수 없습니다. 하지만 실제 코드베이스는 "많은 가설 × 많은 컴포넌트"를 동시에 적용해야 하며, 흥미로운 결과가 나오면 더욱 가지를 쳐나가야 합니다. 에이전트를 강력하게 구동할 수는 있어도, 어느 시점부터는,

당신은 모델에 의해 제약받는 것을 멈추고, 상호작용의 "형태" 그 자체에 의해 제약받기 시작합니다.

(at some point you stop being limited by the model and start being limited by the shape of the interaction itself)

모델을 직접 코딩 에이전트로 사용하는 것은, 연구자가 이미 단서를 가지고 있고 "한 쌍의 눈"이 더 필요한 수동 조사에는 적합합니다. 하지만 높은 커버리지 (Coverage)를 달성하기 위한 도구로서는 잘못된 선택입니다. 그것을 받아들인 시점에서, 그들은 Mythos에게 잘못된 일을 시키는 것을 그만두고, 주변에 harness를 구축하기 시작한 것입니다.

취약점 대응에서 가장 어려운 것은, 발견한 버그 중에서 "어떤 것이 진짜이고, 어떤 것이 악용 가능한지, 그리고 어떤 것을 지금 즉시 수정해야 하는지"를 구분하는 것입니다. 이는 AI 이전부터 어려운 문제였습니다. AI 스캐너와 AI 생성 코드가 이를 더욱 악화시키고 있습니다. Cloudflare는 사후 검증 단계를 여러 겹 쌓아 대응해 왔습니다.

보고서에 따르면 노이즈율을 지배하는 요인은 두 가지가 있다고 합니다.

① 프로그래밍 언어. C와 C++은 직접적인 메모리 조작을 허용하며, 그에 따라 버그 클래스──버퍼 오버플로우 (Buffer Overflow), 경계 외 읽기/쓰기──를 생성합니다. 이것들은 Rust와 같은 메모리 안전 언어라면 컴파일 시점에 사라질 종류의 것들입니다. 실제로 메모리 비안전 언어로 작성된 프로젝트에서는 일관되게 가양성 (False Positive)이 많이 발생했습니다.

② 모델의 편향 (Bias). 우수한 인간 연구자는 "무엇을 발견했는지, 그리고 얼마나 확신하는지"를 전달합니다. 모델은 전달하지 않습니다. 모델에게 버그를 찾으라고 하면, 코드에 버그가 있든 없든 찾아냅니다. 돌아오는 결과물(findings)은 "possibly (아마도)", "potentially (잠재적으로)", "could in theory (이론상으로는 가능할 수도 있음)"와 같이 희석되어 있으며, 그 모호한 결과물들이 확실한 것들을 수로 압도합니다. 탐색적인 도구로서는 타당한 편향일지라도, 트리아지 (Triage) 큐에게는 재앙입니다. 투기적인 결과물 하나하나가 기각하기 위해 인간의 주의력과 토큰을 잡아먹으며, 그 비용이 수천 건의 규모로 쌓여갑니다.

Mythos Preview는 이 지점에서 명확하게 개선되었다고 합니다. 특히 프리미티브 (Primitive)를 연쇄시키는 능력──여러 취약점을 개별적으로 보고하는 것이 아니라, 하나의 작동하는 PoC (Proof of Concept)로 통합하는 능력──덕분에, PoC와 함께 전달되는 결과물은 그대로 행동으로 옮길 수 있습니다. "이게 애초에 진짜인가?"에 소비하는 시간이 급격히 줄어듭니다. 참고로 Cloudflare의 harness는 의도적으로 과잉 보고 (Over-report) 쪽에 가깝게 튜닝되어 있습니다. 놓치는 것을 줄이는 만큼 노이즈는 늘어납니다. 하지만 트리아지 시점에서 Mythos의 출력은 분명히 질이 높습니다. 모호함이 줄어들고, 재현 절차가 명확하며, "수정할 것인가, 기각할 것인가"의 판단에 도달하기까지의 수고가 적기 때문입니다.

규모 있게 운용하며 얻은 교훈은 4가지였습니다. 모두 "전체 실행을 관리하는 harness가 필요하다"는 점을 가리키고 있었습니다.

• 좁은 스코프 (Scope)가 더 좋은 발견을 만들어낸다. "이 리포지토리의 취약점을 찾아줘"라고 하면 모델이 방황하게 된다. "이 특정 함수의 커맨드 인젝션 (Command Injection)을, 이 신뢰 경계 (Trust Boundary) 아래에서 찾아줘. 아키텍처 문서는 이것이고, 이 영역의 과거 커버리지 (Coverage)는 이것이야"라고 말하면, 연구자가 실제로 하는 방식에 훨씬 가까워진다. -
• 적대적 리뷰 (Adversarial Review)가 노이즈를 제거한다. 첫 번째 발견 (Finding)과 큐 (Queue) 사이에, 두 번째 에이전트 (별도의 프롬프트, 별도의 모델, 스스로 발견을 낼 권한은 없음)를 배치하면, 첫 번째 에이전트가 자기 리뷰(Self-review)에서는 놓칠 법한 노이즈를 대량으로 잡아낸다. 두 에이전트를 의도적으로 대립시키는 것이, 한 에이전트에게 "조심해"라고 말하는 것보다 훨씬 효과적이다. -
• 체인 (Chain)을 에이전트 간에 나누면 추론 (Reasoning)이 좋아진다. "이 코드에 버그가 있는가?"와 "공격자가 외부에서 그 버그에 실제로 도달할 수 있는가?"는 별개의 질문이며, 나누어 물었을 때 모델이 각각을 더 잘 대답한다. 통합된 버전보다 각 질문이 더 좁기 때문이다. -
• 좁은 병렬 태스크 (Parallel Task)가 포괄성을 노리는 단일 에이전트보다 승리한다. 다수의 에이전트가 엄격하게 스코프가 지정된 질문에 매달리고, 나중에 결과를 중복 제거 (Deduplication)하는 것이, 하나의 에이전트에게 "포괄적으로 수행해"라고 말하는 것보다 커버리지 (Coverage)가 높아진다.

이것들은 모두 "모델의 행동에 대한 관찰"이며, 이를 종합하면 더 이상 채팅 인터페이스가 아닌 무언가──최종 성과를 달성하게 만드는 harness를 그려낸다. 그리고 흥미로운 점은, harness를 만드는 첫걸음은 간단하며, 모델 스스로 돕게 하면 된다는 것이다 (실제로 그렇게 했다). Mythos Preview를 사용하여, 원래의 harness를 Mythos의 강점에 맞춰 개량했다고 한다.

실제 harness는 단계별로 다음과 같이 구성되어 있습니다. 런타임 (Runtime) / 에지 (Edge) 데이터 경로 / 프로토콜 스택 (Protocol Stack) / 컨트롤 플레인 (Control Plane) / 의존 OSS에 대해, 살아있는 코드를 스캔하는 데 사용되었습니다.

이 파이프라인에서 가장 효과적인 것은 Validate 단계, 즉 두 에이전트를 의도적으로 대립시키는 설계입니다. 검증 역할은 "새로운 발견을 만들 권한 없이, 오직 원래의 발견을 무너뜨리기 위해" 존재합니다.

두 에이전트를 의도적으로 대립시키는 것이, 한 에이전트에게 "조심해"라고 말하는 것보다 훨씬 효과적입니다.

(putting two agents in deliberate disagreement is way more effective than just telling one agent to be careful)

그리고 또 하나, 역할을 나누는 이유의 핵심:

모델은 각각을 따로 물었을 때 더 잘합니다. 각 질문이 통합된 버전보다 좁기 때문입니다.

（모델은 각각을 따로 물었을 때 더 잘합니다）

이것은 제가 이전에 썼던 ClickHouse의 「판정의 벽」과 같은 계열의 이야기입니다. 그것은 「빠르고 자동화된 판정」이 거짓말을 하는 에이전트를 신뢰할 수 있는 존재로 바꾸었습니다. 이번 이야기는 「적대적인 두 번째 눈」이 그럴듯하기만 한 오탐(False Positive)을 걸러내는 것에 관한 것입니다. L0–L7의 라더(Ladder)로 비유하자면, 검증역이라는 독립된 관문은 부탁(소프트 채널)이 아니라 구조(하드웨어에 가까운 방식)로 품질을 담보하는 L6적인 거버넌스(Governance)에 해당합니다.

이 부분은 기술과 안전의 경계선에 있어 흥미롭기에 남겨둡니다. Project Glasswing에서 Anthropic이 제공한 Mythos Preview는 일반 제공 버전(Opus 4.7이나 GPT-5.5)에 있는 추가적인 세이프가드(Safeguard)가 없는 상태였습니다.

그럼에도 모델은 자발적으로 일부 요청을 거부합니다. 취약점 헌팅(Vulnerability Hunting)에 도움이 되었던 능력과 마찬가지로, 창발적인 가드레일(Guardrail)을 가지고 있어 정당한 보안 연구 요청조차 밀어낼 때가 있습니다. 다만, 그 자발적인 거부는 일관적이지 않습니다. 보고된 사례가 꽤 유효한 근거가 됩니다. 어떤 프로젝트에서는 처음에는 취약점 연구를 거부했으나, 코드와 무관한 환경 변경 이후에는 완전히 동일한 코드에 대해 동일한 연구 요청에 응했습니다. 다른 사례에서는 심각한 메모리 버그를 여러 개 찾아내고 확인했음에도 불구하고, 데모용 익스플로잇(Exploit)을 작성하는 것은 거부했습니다. 의미론적으로 동일한 태스크라도 언제, 어떻게 제시되느냐에 따라 정반대의 결과가 나올 수 있습니다 (모델이 확률적(Probabilistic)인 이상, 같은 요청이라도 실행할 때마다 다릅니다).

시사하는 바는 무겁습니다. 모델의 자발적인 거부는 실제 현상이지만, 그것 단독으로 완전한 안전 경계로서 신뢰할 수 있을 만큼 일관적이지는 않습니다. 그렇기에 향후 일반 제공될 사이버 능력을 갖춘 프런티어 모델(Frontier Model)은 이 베이스라인 동작 위에 반드시 추가적인 세이프가드를 얹어야 합니다. Project Glasswing과 같은 통제된 연구 환경 밖에서 널리 사용한다면 더욱 그렇습니다.

Mythos Preview에 대한 다른 보안 리더들의 반응 중 가장 컸던 것은 속도였습니다. 빠르게 스캔하고, 빠르게 패치하며, 대응 사이클을 단축하는 것. 여러 팀이 이제 「CVE 공개부터 운영 패치까지 2시간 SLA」로 움직이고 있다고 합니다. 공격 측의 타임라인이 단축된다면 방어 측도 단축해야 한다는 발상은 이해합니다. 하지만 Cloudflare는 주의를 줍니다. 속도만으로는 부족하며, 많은 팀이 이를 뼈아픈 방식으로 배우게 될 것이라고 말입니다.

패치를 빠르게 한다 해도, 패치를 만들어내는 파이프라인(Pipeline)의 "형태"는 변하지 않습니다. 회귀 테스트(Regression Test)에 하루가 걸린다면, 2시간 SLA를 맞추기 위해 이를 건너뛰어야만 할 것입니다. 그리고 회귀 테스트를 건너뛰고 출시한 버그는 대개 고치려 했던 버그보다 질이 더 나쁩니다. 그들 스스로도 모델에게 직접 패치를 작성하게 해보았는데, 원래의 버그는 고치지만 코드가 의존하고 있던 다른 무언가를 조용히 망가뜨리는 패치가 몇 건 발생하는 것을 목격했다고 합니다.

따라서 정말 어려운 질문은 「취약점 주변의 아키텍처를 어떻게 설계할 것인가」로 향합니다. 원칙은 버그가 존재하더라도 공격자가 악용하기 어렵게 만드는 것입니다. 그렇게 하면 취약점이 공개된 시점부터 패치가 적용될 때까지의 간극이 그렇게 치명적이지 않게 됩니다. 구체적으로는, 앱 앞단에 위치하여 버그에 도달하는 것 자체를 차단하는 방어, 코드의 일부 결함이 공격자에게 다른 부분으로의 접근 권한을 주지 않도록 하는 설계, 그리고 개별 팀의 배포를 기다리는 것이 아니라 코드가 돌아가는 모든 지점에 동시에 수정 사항이 전달될 수 있도록 하는 것입니다.

그리고 이 이야기는 양날의 검이라고 솔직하게 적고 있습니다. 자사 코드의 버그 발견을 도운 것과 동일한 능력은 악의적인 손에 넘어갈 경우 인터넷상의 모든 앱에 대한 공격을 가속화할 수 있습니다. Cloudflare는 수백만 개의 앱 "앞단"에 위치하고 있으며, 위의 아키텍처 원칙은 바로 그들의 제품이 고객을 위해 적용하기 위해 만들어진 것이라고 결론짓습니다.

이것이 「harness가 주인공」이라는 주장의 가장 강렬한 실례라고 생각합니다. 저자 스스로 이렇게 단언합니다.

(이러한 관찰들은) 결국 모두 모델의 행동에 관한 이야기다. ... 그것을 최종 성과로 바꾸는 것이 harness다.

흥미로운 점은, 효과를 발휘하는 고안들이 모두 「더 똑똑한 모델을 선택하는 것」이 아니라, 업무를 나누는 방식이라는 점입니다. 좁게 나누기 (Hunt), 대립시키기 (Validate), 도달성으로 걸러내기 (Trace), 루프를 통해 키우기 (Feedback). 기반이 되는 모델은 동일하더라도, 상호작용의 형태를 바꾸는 것만으로도 공격 면(attack surface)의 0.1%밖에 보지 못했던 것이 돌아가기 시작합니다. 게다가 안전(Safety)이라는 영역이기에 더욱, 「속도」가 아니라 「벽」과 「대립」과 「아키텍처」를 통해 확률을 확정으로 끌어올린다는 설계 사상이 와닿습니다──ClickHouse의 운영기(運用記)와 완전히 같은 결론입니다.

유의해야 할 점도 솔직하게 말씀드립니다. Cloudflare는 구체적인 탐지 수, 오탐률(False Positive Rate), 적대적 검증(Adversarial Validation)을 통해 노이즈가 몇 % 감소했는지와 같은 정량적 결과를 공개하지 않았습니다. 효과는 어디까지나 설계에 대한 설명으로서 이야기되고 있습니다. Mythos 또한 Anthropic의 프리뷰(preview) 모델을 사용하여, 일반 제공 버전의 세이프가드(safeguard)를 해제한 상태에서의 검증입니다. 따라서 「이것으로 취약점 헌팅(vulnerability hunting)이 해결되었다」가 아니라, 「단일 에이전트가 아니라, 적대적 검증을 포함한 다중 에이전트 harness로 구축해야 한다」는 설계상의 지침으로 읽는 것이 정확합니다. 그럼에도 불구하고, harness가 어디에서 효과를 발휘하는지를 단계별로 이토록 구체적으로 보여준 보고를 저는 달리 알지 못합니다.

• 1차 (Cloudflare 공식·전문): Project Glasswing: what Mythos showed us
• 관련 (동일한 「harness가 주역」인 계보):

이 기사는 「AI Watch」에도 게재되어 있습니다. 최첨단 AI를 기술의 내용까지 깊이 있게 분석합니다.