---
title: "클라우드플레어가 본 보안 특화 LLM ‘마이토스’: 취약점 찾기를 넘어 익스플로잇 체인까지 간다"
published: 2026-05-18T13:37:11.000Z
canonical: https://jeff.news/article/2864
---
# 클라우드플레어가 본 보안 특화 LLM ‘마이토스’: 취약점 찾기를 넘어 익스플로잇 체인까지 간다

클라우드플레어가 앤트로픽의 보안 특화 모델 마이토스 프리뷰를 자사 코드 50개 이상 저장소에 돌려본 결과를 공개했어. 단일 버그 탐지를 넘어 여러 취약점을 엮어 실제 익스플로잇 가능성을 증명하는 능력이 눈에 띄었지만, 대규모 운영에는 모델 자체보다 좁은 범위의 병렬 하네스와 검증 파이프라인이 핵심이라는 결론이야.

## 마이토스가 다르게 보였던 지점

- 클라우드플레어가 앤트로픽의 보안 특화 LLM인 마이토스 프리뷰(Mythos Preview)를 자사 인프라와 50개가 넘는 저장소에 돌려봄
  - 목적은 두 가지였음: 자기 시스템의 취약점을 찾아 고치는 것, 그리고 최신 모델이 공격자에게 어떤 능력을 줄 수 있는지 보는 것
  - 실험은 프로젝트 글래스윙(Project Glasswing)의 일부로, 클라우드플레어가 자기 코드에 대해 통제된 환경에서 진행함

- 가장 눈에 띈 능력은 익스플로잇 체인 구성임
  - 실제 공격은 보통 버그 하나로 끝나지 않고, 작은 취약점 여러 개를 이어 붙여 작동함
  - 예를 들면 use-after-free를 임의 읽기·쓰기 primitive로 바꾸고, 제어 흐름을 가로챈 뒤, ROP 체인으로 시스템 장악까지 가는 식임
  - 마이토스는 이런 여러 조각을 조합해 실제 공격 가능성을 추론하는 과정이 “자동 스캐너”보다 “시니어 보안 연구자”에 가까웠다고 함

- 두 번째 강점은 PoC 생성과 반복 검증 루프임
  - 버그를 찾는 것과 그 버그가 실제로 악용 가능한지 증명하는 건 완전히 다른 문제임
  - 마이토스는 의심 버그를 트리거하는 코드를 쓰고, scratch 환경에서 컴파일하고, 실행한 뒤, 예상과 다르면 실패 내용을 읽고 가설을 수정해 다시 시도함
  - 클라우드플레어가 중요하게 본 건 “찾았다”가 아니라 “돌려봤고 재현됐다”까지 간다는 점임

> [!IMPORTANT]
> 보안팀 입장에선 PoC가 붙은 취약점과 “가능할 수도 있음” 수준의 리포트는 완전히 다름. 전자는 바로 판단할 수 있지만, 후자는 triage 큐를 태우는 비용이 됨.

```mermaid
sequenceDiagram
    participant 하네스
    participant 탐지모델
    participant 검증모델
    participant 실행환경
    participant 보안팀
    하네스->>탐지모델: 좁은 범위와 취약점 유형 지정
    탐지모델->>실행환경: PoC 작성, 컴파일, 실행
    실행환경-->>탐지모델: 실패 또는 재현 결과 반환
    탐지모델->>검증모델: 취약점 후보와 근거 전달
    검증모델-->>하네스: 노이즈 제거 또는 확인
    하네스->>보안팀: 수정 또는 기각 가능한 결과 전달
```

## 안전장치는 모델 성능만큼 까다로움

- 프로젝트 글래스윙에서 제공된 마이토스 프리뷰는 일반 공개 모델에 들어가는 추가 안전장치가 없는 버전이었다고 함
  - 글에서는 일반 공개 모델 예시로 오퍼스 4.7이나 지피티-5.5 같은 모델을 언급함
  - 그런데도 모델이 일부 요청에는 스스로 거부 반응을 보였다고 함

- 문제는 그 “자연 발생한 거부”가 일관적이지 않았다는 점임
  - 같은 코드에 대한 취약점 연구 요청을 처음엔 거부했다가, 프로젝트 환경에 관련 없는 변화가 생긴 뒤에는 수락한 사례가 있었음
  - 심각한 메모리 버그를 찾고 확인한 뒤, 데모 익스플로잇 작성은 거부한 사례도 있었음
  - 같은 의미의 요청도 표현 방식이나 실행 시점에 따라 반대 결과가 나올 수 있었다고 함

- 그래서 클라우드플레어의 결론은 꽤 명확함: 모델의 내부적인 거부 성향만으로는 안전 경계가 될 수 없음
  - 통제된 연구 환경에서는 쓸 수 있어도, 더 넓게 공개하려면 별도의 안전장치가 추가로 필요함
  - 공격 능력과 방어 능력이 같은 뿌리에서 나오기 때문에, 이 지점은 앞으로 계속 논쟁거리가 될 가능성이 큼

## 왜 그냥 코딩 에이전트 하나로는 안 됐나

- 클라우드플레어도 처음엔 평범한 코딩 에이전트에게 “이 저장소에서 취약점 찾아줘”라고 시키는 접근을 해봤다고 함
  - 결과는 나오지만, 실제 대규모 코드베이스를 의미 있게 커버하진 못했음
  - 원인은 크게 컨텍스트와 처리량 두 가지였음

- 취약점 연구는 본질적으로 좁고 병렬적인 작업임
  - 사람 연구자도 “이 복잡한 기능 하나”, “이 보안 경계 하나”, “command injection 같은 특정 취약점 유형 하나”를 깊게 파고듦
  - 그리고 그 작업을 코드베이스 전체에 대해 수천 번 반복함
  - 반면 단일 에이전트 세션은 한 번에 하나의 가설을 붙잡고 진행하다가 컨텍스트 창이 차고, 압축 과정에서 중요한 단서가 밀려날 수 있음

- 클라우드플레어가 얻은 운영 교훈은 네 가지임
  - 범위가 좁을수록 결과가 좋아짐: “저장소 전체에서 취약점 찾아줘”보다 “이 함수에서 command injection 가능성을 봐줘”가 훨씬 낫다는 것
  - 적대적 리뷰가 노이즈를 줄임: 첫 모델이 낸 결과를 다른 프롬프트와 다른 모델로 검증하게 하면 헛발질을 많이 걸러냄
  - 체인을 단계별로 쪼개면 추론이 좋아짐: “버그가 있나”와 “외부 공격자가 거기까지 닿을 수 있나”는 따로 물어야 함
  - 좁은 병렬 작업이 단일 초대형 작업보다 낫다: 여러 에이전트가 작은 질문을 동시에 처리하고, 나중에 중복 제거하는 구조가 커버리지에 유리함

> [!TIP]
> 팀에서 AI 보안 분석을 붙이려면 “우리 코드 전체 봐줘”부터 시작하면 노이즈가 폭발하기 쉬움. 신뢰 경계, 함수, 취약점 유형, 관련 아키텍처 문서를 같이 주는 식으로 작업 단위를 작게 쪼개는 게 핵심임.

## 빠른 패치만으로는 부족함

- 보안 리더들이 마이토스에 가장 크게 반응한 지점은 속도였다고 함
  - 더 빨리 스캔하고, 더 빨리 패치하고, 대응 주기를 줄이자는 반응임
  - 어떤 팀은 CVE 공개부터 프로덕션 패치까지 2시간 SLA를 목표로 움직이고 있다고 함

- 클라우드플레어는 “빠른 것만으로는 부족하다”고 선을 그음
  - 회귀 테스트가 하루 걸리는 구조라면 2시간 SLA를 맞추려면 테스트를 건너뛰게 됨
  - 그러면 원래 고치려던 버그보다 더 나쁜 장애를 배포할 수 있음
  - 실제로 모델이 직접 패치를 쓰게 했을 때, 원래 버그는 고쳤지만 의존하던 동작을 조용히 깨뜨린 사례가 있었다고 함

- 더 어려운 질문은 취약점 주변 아키텍처를 어떻게 설계하느냐임
  - 버그가 있어도 공격자가 그 버그에 닿기 어렵게 만드는 방어 계층이 필요함
  - 애플리케이션 앞단에서 공격을 차단하고, 한 부분의 결함이 다른 부분의 권한으로 번지지 않게 격리해야 함
  - 코드가 실행되는 모든 위치에 동시에 수정사항을 배포할 수 있는 능력도 중요함

- 이 기술은 방어에도 좋지만 공격에도 그대로 좋음
  - 클라우드플레어는 같은 능력이 잘못된 손에 들어가면 인터넷상의 모든 애플리케이션에 대한 공격 속도를 높일 수 있다고 인정함
  - 그래서 이 글은 모델 자랑이라기보다, 보안 조직의 운영 방식과 아키텍처가 AI 시대에 어떻게 바뀌어야 하는지에 대한 경고에 가까움

---

## 기술 맥락

- 클라우드플레어가 선택한 방향은 모델 하나를 만능 보안 연구자로 쓰는 게 아니라, 모델을 좁은 작업 단위로 많이 돌리는 하네스를 만드는 쪽이에요. 취약점 연구는 코드 전체를 한 번 훑는 일이 아니라, 특정 경계와 특정 버그 클래스를 반복해서 파고드는 일이기 때문이에요.

- 하네스가 필요한 이유는 LLM이 “뭔가 있을 수도 있음” 같은 결과를 너무 많이 만들 수 있기 때문이에요. 보안 triage에서는 추측 하나하나가 사람 시간과 토큰 비용을 먹거든요. 그래서 클라우드플레어는 PoC 실행, 적대적 리뷰, 단계별 검증을 붙여서 바로 고치거나 버릴 수 있는 결과만 남기려 한 거예요.

- 흥미로운 선택은 “버그가 있나”와 “공격자가 실제로 도달할 수 있나”를 분리한 점이에요. 두 질문을 한 번에 던지면 범위가 커져서 모델이 흔들리지만, 나눠서 물으면 각 단계의 추론이 좁아지고 검증도 쉬워져요.

- 마지막으로 이 글은 패치 속도 경쟁만으로는 답이 안 된다고 말해요. 회귀 테스트와 배포 구조가 느린데 SLA만 2시간으로 줄이면, 결국 테스트를 건너뛰게 되고 더 큰 장애를 만들 수 있거든요. 그래서 버그를 빨리 찾는 능력만큼, 공격 경로를 막는 방어 계층과 빠르게 일괄 배포할 수 있는 아키텍처가 중요해져요.

## 핵심 포인트

- 마이토스 프리뷰는 여러 취약점 원시 요소를 조합해 작동하는 익스플로잇 체인을 구성할 수 있었음
- 의심 취약점에 대해 PoC를 작성, 컴파일, 실행하고 실패 결과를 반영해 다시 시도하는 루프가 강점으로 나타남
- 클라우드플레어는 단일 코딩 에이전트보다 좁은 범위의 병렬 작업, 적대적 리뷰, 단계별 역할 분리가 더 효과적이라고 봄
- 빠른 패치만으로는 부족하고, 버그가 있어도 공격자가 닿기 어렵게 만드는 아키텍처 방어가 중요하다고 강조함

## 인사이트

이 글의 핵심은 “AI가 취약점을 잘 찾는다”가 아니라 “보안 업무를 AI에 맞게 다시 쪼개야 한다”는 쪽이야. 앞으로 방어팀도 공격팀도 속도가 올라갈 텐데, 단순 자동화보다 검증·격리·배포 아키텍처가 진짜 차이를 만들 가능성이 큼.