클라우드플레어가 앤트로픽의 신형 보안 AI 모델 '미토스 프리뷰(Mythos Preview)'를 Project Glasswing 프로젝트로 테스트한 결과를 공개했다. 취약점 발견 능력에서 기존 범용 대규모언어모델(LLM)과 차원이 다르다는 평가다. 다만 모델의 일관성 부족과 오탐(False Positive) 문제는 여전히 해결 과제로 남았다.

클라우드플레어 보안팀은 지난 몇 개월간 자사 인프라 50개 이상의 코드 저장소에 미토스를 적용해 테스트했다. 결과는 예상을 크게 뛰어넘었다. 미토스는 단순히 버그를 식별하는 수준을 넘어 **공격 체인 구성(Exploit Chain Construction)**과 증명 생성(Proof Generation) 두 가지 기능에서 혁신을 보였다.

단순 버그 발견 → 실제 공격까지

기존 AI 취약점 스캐너는 보안 결함을 찾지만, 그것이 실제 악용 가능한 공격으로 이어지는지는 별개의 문제였다. 예를 들어, 메모리 오버플로우 버그를 발견해도 이를 제어 흐름 탈취(Control Flow Hijacking)와 연쇄 조합해 시스템을 완전히 장악할 수 있는지는 검증되지 않았다.

미토스는 이 과정을 자동화한다. 여러 공격 기본 요소(primitives)를 인식하고 이들을 작동 가능한 익스플로잇으로 엮어낸다. 클라우드플레어 보안팀은 "모델이 보여주는 논리적 추론이 시니어 연구원 수준"이라고 평가했다.

증명 생성도 마찬가지다. 미토스는 의심 버그를 트리거하는 코드를 직접 작성하고, 샌드박스 환경에서 컴파일하며, 실행 결과를 확인한다. 예상대로 작동하면 그것이 증명이 되고, 실패하면 모델이 가설을 수정해 재시도한다. 이 반복 루프 자체가 추측이 아닌 검증된 결함을 만든다.

기존 범용 모델들도 같은 작업을 시도했지만 '부분 성공'에 그쳤다. 버그는 찾고 그 위험성도 설명했지만, 최종 익스플로잇 체인 구성 단계에서 멈췄다. 미토스는 저위험 버그들을 체계적으로 결합해 더 높은 심각도의 공격으로 변환하는 데 성공했다.

AI 모델도 "합법 보안 연구 거부"하는 모순

다만 미토스에도 문제가 있었다. Project Glasswing의 미토스는 일반 공개 모델(Opus 4.7, GPT-5.5)에 적용된 추가 안전장치가 없었음에도 불구하고, 때때로 정당한 취약점 연구 요청을 거부했다.

더 문제적인 점은 그 거부가 일관성이 없다는 것이다. 똑같은 작업을 다르게 표현하거나 다른 맥락에 제시하면 정반대 결과가 나왔다. 클라우드플레어는 구체 사례를 제시했다. 처음엔 프로젝트 코드 분석을 거부했던 미토스가, 프로젝트 환경에 무관한 변경이 가해진 후에는 같은 분석을 수행했다. 분석 대상 코드는 전혀 달라지지 않았다.

다른 사례에서 미토스는 심각한 메모리 버그 여러 개를 발견·확인했다가, 익스플로잇 데모 작성을 거부했다. 동일한 요청을 다르게 표현하자 수락했다. 모델의 확률적 특성상 같은 요청도 실행마다 다른 결과를 낼 수 있다.

이는 AI 보안 모델의 근본적 한계를 드러낸다. 모델의 내재된 안전장치(Emergent Guardrails)는 존재하지만 신뢰할 수 없다는 뜻이다. 따라서 향후 사이버 능력을 갖춘 범용 AI 모델이 일반 공개될 때는, 이런 자동 거부 메커니즘 위에 추가적 안전장치를 반드시 탑재해야 한다는 것이 클라우드플레어의 결론이다.

"발견"과 "검증" 사이의 격차

AI 취약점 스캐너 도입의 또 다른 장벽은 오탐 문제다. 수천 건의 버그 보고 중 어느 것이 실제이고, 어느 것이 악용 가능하며, 어느 것부터 즉시 고쳐야 하는지 판단하는 것은 AI 이전 시대에도 어려웠다.

데이터에 따르면 두 가지 요인이 오탐을 주도한다.

첫째, 프로그래밍 언어다. C/C++은 메모리 직접 제어를 허용해 버퍼 오버플로우, 범위 초과 읽기 등 결함이 자주 발생한다. 반면 Rust 같은 메모리 안전 언어는 컴파일 단계에서 이를 원천 차단한다. 클라우드플레어의 테스트에서 메모리 비안전 언어로 작성된 프로젝트에서 거짓 양성이 훨씬 많았다.

둘째, 모델 편향이다. 숙련한 보안 연구원은 발견사항과 자신감 수준을 명시한다. AI 모델은 다르다. "버그를 찾아라"고 지시하면, 존재 여부와 상관없이 버그를 "발견"한다. 결과물은 "아마도", "잠재적으로", "이론상 가능하게" 같은 수식어로 가득하고, 이런 추측성 발견들이 확실한 결함보다 훨씬 많다. 탐색 도구로서는 합리적인 편향이지만, 취약점 우선순위 대기열에서는 재앙이다. 모든 추측성 발견마다 인적 검증과 토큰 비용을 들어야 하기 때문이다.

미토스는 여기서 눈에 띄는 개선을 보였다. 특히 취약점 체인 구성 능력이 뛰어나다. 여러 취약점을 독립적으로 보고하는 대신 작동 가능한 개념 증명(PoC)으로 결합해 제시한다. PoC가 있는 발견은 즉각 대응할 수 있고, "이게 실제 문제인가" 묻고 답하는 시간이 대폭 줄어든다.

범용 AI 에이전트는 코드 저장소에 작동 불가

흥미로운 부분은 "왜 기존 범용 코딩 에이전트는 이 작업을 못했는가"다. 클라우드플레어가 지난해 AI 보조 취약점 연구를 시작했을 때, 첫 시도는 직관적이었다. 범용 코딩 에이전트를 임의 저장소에 투입해 취약점을 자동 발견하도록 하는 것이다.

이 접근은 표면적으로 '작동'했다. 모델이 발견을 내뱉었다. 그러나 질적으로는 형편없었다. 범용 에이전트는 맥락을 모르고, 복잡한 공격 체인을 구성하지 못했으며, 수많은 오탐으로 인한 검증 비용이 엄청났다.

미토스는 보안 특화 훈련을 받은 모델이다. 이 차이가 결국 모든 것을 결정했다.

국내 보안팀에 주는 교훈

한국의 대형 기술 기업과 금융회사들도 최근 AI 기반 취약점 발견 도구 도입을 검토 중이다. 클라우드플레어의 경험은 중요한 선례다. "AI 취약점 스캐너를 도입하면 보안 비용을 크게 줄일 수 있다"는 기대감이 높지만, 현실은 복잡하다.

미토스 같은 특화 모델도 여전히 부분적인 도구일 뿐이다. 오탐이 적더라도 여전히 존재하고, 안전장치가 일관성이 없으며, 모든 취약점을 자동 증명할 수는 없다. 따라서 국내 보안팀은 다음을 고려해야 한다.

1. 범용 LLM보다는 특화 모델을 선택하되, 그것도 보조 도구일 뿐이라는 현실을 직시할 것
2. 다단계 검증 프로세스를 설계해 AI 출력의 오탐을 걸러낼 것
3. 언어 선택이 결과를 좌우한다는 점을 인식하고, Rust 같은 메모리 안전 언어 도입을 병행할 것
4. AI 거부 메커니즘에 맹신하지 말고, 정당한 보안 연구 범주를 명확히 정의할 것

미토스가 보여준 것은 "AI가 사이버 보안을 완전히 자동화할 수 있다"는 환상이 아니라, "특화된 AI는 인간 전문가의 작업을 더 정교하고 빠르게 할 수 있다"는 현실이다. 그것도 맥락과 검증 구조가 뒷받침될 때만.