MYTHOS 이후의 보안 현실, 너무 겁먹고 있는 건 아닐까?


들어가며

최근 Project Glasswing와 Claude Mythos Preview 기술 글이 나오면서, 보안 쪽에서는 분위기가 꽤 빠르게 달아오른 것 같습니다. "이제 진짜 AI가 사람보다 먼저 제로데이를 찾는 시대가 온 건가?" 싶은 느낌도 들고, 한편으로는 "이거 공격자 손에 들어가면 너무 위험한 거 아닌가?" 하는 막연한 두려움도 자연스럽게 따라왔습니다.

저도 처음에는 꽤 위협적으로 느꼈습니다. 예전에 Security Brief 글에서 LLM 이후에는 취약점이 더 빨리 드러나는 환경으로 가는 것 같다고 적은 적이 있었는데, MYTHOS는 그 흐름을 더 강하게 밀어붙이는 사례처럼 보였기 때문입니다.

그런데 공개된 글들을 조금 차분하게 다시 읽어보면, 지금 우리가 MYTHOS를 만능 공격 열쇠처럼 상상하고 있는 건 아닌가 싶은 부분도 있습니다. MYTHOS가 인상적인 건 맞지만, 그렇다고 "MYTHOS가 없으면 이제 아무 것도 못 한다"까지 바로 가는 건 아직은 조금 이르지 않나 싶었습니다.

이번 글에서는 그 이유를 간단하게 정리해보고, 그렇다면 MYTHOS를 직접 쓸 수 없는 현재 시점에서 우리는 어떤 식으로 접근하면 좋을지 같이 적어보겠습니다. 다만 저는 MYTHOS를 직접 돌려본 것은 아니기 때문에, 아래 내용은 어디까지나 공개된 자료를 읽고 정리한 관점이라는 점은 먼저 적어두겠습니다.

MYTHOS 공포는 왜 이렇게 빨리 커졌을까?

이유는 어렵지 않은 것 같습니다. Anthropic은 공식 발표에서 MYTHOS가 모든 주요 운영체제와 웹 브라우저에서 수천 개의 zero-day를 찾았다고 설명했고, 기술 글에서는 OpenBSD 27년 된 버그, FreeBSD 원격 코드 실행, 브라우저 샌드박스 탈출 체인 같은 사례를 함께 제시했습니다.

게다가 기술 글을 보면 Anthropic은 단순히 "버그를 의심했다" 수준이 아니라, 실제 실행과 검증, exploit 작성, triage까지 이어지는 흐름을 꽤 적극적으로 강조하고 있습니다. 그러니 이 발표를 본 사람들이 "이제 게임이 끝난 건가?" 하는 반응을 보이는 것도 이상한 일은 아니었습니다.

다만 저는 이 지점에서 한 번쯤 속도를 늦추고, 공개된 근거가 정확히 무엇을 말하고 있는지와 우리가 거기서 무엇을 과하게 상상하고 있는지를 나눠서 보는 게 좋다고 생각합니다.

공개 자료만 놓고 보면 조금 다르게 읽힌다

1. Firefox 150 숫자는 생각보다 단순하지 않다

이 부분에서 꽤 인상적으로 읽혔던 글이 A quick look at Mythos run on Firefox: too much hype?였습니다. 이 글은 Firefox 150 관련 공개 자료를 따라가 보면서, 사람들이 많이 인용하는 숫자들이 생각보다 깔끔하게 떨어지지 않는다고 짚습니다.

예를 들어 같은 글은 많이 회자된 "under $20,000" 문구를 "MYTHOS가 가볍게 한 번 돌고 치명적 버그 하나를 뽑아냈다"는 의미로 읽기 어렵다고 설명합니다. 작성자 정리에 따르면 Anthropic이 공개한 서술은 대략 천 회 수준의 scaffolded run과 수십 개 결과가 섞인 대규모 탐색 과정에 더 가깝게 읽힙니다. 이 차이는 꽤 중요하고, 바로 그 지점을 이 글 초반부에서 가장 먼저 짚고 있습니다.

또 Firefox 150에서 언급된 271개 취약점 숫자 역시, 이 글의 분석을 보면 Bugzilla bug ID, advisory CVE, Firefox 본체, ESR, Thunderbird가 한데 섞여 있어서 외부인이 바로 "이게 전부 MYTHOS가 찾아낸 Firefox 150 고위험 exploitable 버그 목록이다"라고 읽기에는 무리가 있어 보입니다.

물론 그렇다고 가치가 없다는 뜻은 아닙니다. 오히려 이건 대규모 코드베이스에서 위험한 패턴과 취약 지점을 폭넓게 끌어올리고, 이를 바탕으로 보안 품질을 끌어올리는 작업이 실제로 의미 있다는 쪽에 더 가까워 보입니다. 다만 이 숫자만 보고 곧바로 "공격자 우위가 완전히 뒤집혔다"까지 점프하는 건 아직 공개 근거가 충분하지 않다는 쪽이 더 정확해 보였습니다.

2. MYTHOS가 잘하는 것과 아직 입증되지 않은 것

위 글에서 개인적으로 가장 동의가 갔던 지점은, MYTHOS가 대규모로 의심스러운 패턴을 잘 끌어올리는 건 꽤 그럴듯해 보이지만, 그게 곧바로 공격적으로 가장 가치 있는 exploit chain 구성 능력까지 공개적으로 입증되었다고 보기는 어렵다는 구분입니다.

같은 글은 Firefox 패치 묶음 안에 lifecycle 정리, cleanup 수정, race 조건 보완, bounds check 강화, serialization 안전화 같은 패턴이 많이 보인다고 설명합니다. 이런 수정은 분명 중요합니다. 다만 보안 연구자가 실제 공격 관점에서 관심을 두는 건, 결국 메모리 제어권, 타입 혼동, 권한 경계 돌파, 샌드박스 탈출 같은 실제 공격 체인으로 이어질 수 있는 버그냐는 문제입니다. 이 글 중반부와 결론도 바로 이 구분을 계속 강조합니다.

정리하면 MYTHOS는 분명 강해 보입니다. 다만 공개 자료만으로는 아직 "방어자에게 유용한 대규모 보조 도구"와 "공격자 우위를 단숨에 재편하는 결정적 무기" 사이의 어느 지점에 있는지 완전히 분리해서 말하기가 어렵습니다. 그래서 저는 지금 단계에서 MYTHOS를 지나치게 절대화해서 볼 필요는 없다고 느꼈습니다.

모델보다 시스템이 더 중요하다는 이야기

1. Anthropic이 공개한 scaffold

흥미로운 건 Anthropic이 공개한 자료를 자세히 보면, MYTHOS의 힘이 단순히 "모델 이름" 하나에서만 나오지 않는다는 점입니다. Anthropic 기술 글의 scaffold 설명을 보면 대략 이런 흐름입니다.

  • 인터넷과 다른 시스템에서 격리된 컨테이너를 띄운다
  • 프로젝트 소스와 실행 환경을 같이 넣고 보게 한다
  • 각 에이전트가 다른 파일에 집중하도록 나눠 병렬 탐색한다
  • 모델이 가설을 세우면 직접 실행하고 디버깅해서 확인한다
  • 마지막에는 별도 에이전트가 bug report가 실제로 의미 있는지 다시 검증한다

즉, 이건 그냥 "좋은 모델에 코드베이스를 던졌다"가 아닙니다. 파일 우선순위 선정, 병렬 분산, 실행 검증, 최종 triage가 다 들어간 꽤 전형적인 agentic harness입니다. 이 구조를 보면 MYTHOS의 위력은 인정하더라도, 동시에 "아, 결국 중요한 건 이런 운영 구조까지 포함한 전체 시스템이구나"라는 생각도 들게 됩니다.

2. AISLE이 말하는 jagged frontier

이 점을 더 직접적으로 짚는 글이 AISLE의 AI Cybersecurity After Mythos: The Jagged Frontier입니다. 이 글은 아예 처음부터 "moat(쉽게 말해 쉽게 따라 하기 어려운 경쟁 우위)는 모델이 아니라 시스템"이라고 못 박고 들어갑니다.

AISLE은 Anthropic이 showcase로 내세운 취약점 분석을 작고 저렴한 오픈웨이트 모델들로 다시 시험해 봤고, 그 결과 여러 모델이 생각보다 많은 부분을 재현했다고 설명합니다. 특히 같은 글 초반부와 실험 요약을 보면, 작은 모델이 FreeBSD 쪽 분석을 잡아내거나, 5.1B active 모델이 OpenBSD SACK 취약점의 핵심 논리를 재현하는 등 모델이 더 크고 더 비싸다고 해서 결과가 꼭 더 좋아지는 건 아니라는 점을 보여줍니다.

이 글이 말하는 핵심은 꽤 명확합니다. 같은 글의 pipeline 분해 섹션을 보면 AI 보안은 codebase navigation, vulnerability detection, triage, patch generation, exploit construction처럼 여러 단계로 나뉘고, 각 단계는 모델 크기와 가격에 대해 같은 방식으로 반응하지 않습니다. 그래서 어떤 한 모델이 모든 구간에서 압도적일 거라고 생각하는 건 현실을 너무 단순하게 보는 셈일 수 있습니다.

저는 이 지점이 꽤 중요하다고 생각합니다. 지금 우리가 무서워해야 하는 건 "MYTHOS라는 이름의 단일 모델"이라기보다, 좋은 모델과 괜찮은 harness, 그리고 검증 가능한 실행 환경이 결합된 운영 체계 쪽에 더 가깝기 때문입니다.

3. harness를 바꾸면 성능이 꽤 달라진다

이런 흐름은 최근 공개된 Synthesizing Multi-Agent Harnesses for Vulnerability Discovery 논문에서도 다시 확인할 수 있습니다. 논문 요약을 보면, 같은 모델을 고정해 두더라도 agent 역할 분담, 프롬프트, 툴 조합, 통신 구조, 재시도 방식 같은 harness 설계만 바꿔도 성능 차이가 여러 배까지 날 수 있다고 설명합니다.

이건 결국 지금 우리가 집중해야 할 포인트가 꽤 분명하다는 뜻이기도 합니다. 당장 MYTHOS급 전용 접근권이 없더라도, 탐색 구조를 잘 나누고, 검증 루프를 붙이고, 실패 원인을 다시 피드백하는 시스템을 만들면 현재 공개된 모델들로도 꽤 많은 걸 해볼 수 있다는 이야기이기 때문입니다.

그럼 지금 우리는 어떻게 접근하면 될까?

제 생각에는 답이 아주 멀리 있지는 않습니다. MYTHOS가 없어도, Anthropic이 공개한 scaffold와 AISLE이 설명한 운영 방식에서 지금 당장 가져올 수 있는 부분이 꽤 많습니다.

1. 로컬에서도 작은 재현은 이미 가능하다

이 부분에서 이번에 같이 읽어본 LLM 기반 취약점 자동 분석 도구 구현 글도 꽤 흥미로웠습니다. 이 글은 Mythos나 Big Sleep 같은 흐름을 그대로 복제하겠다는 접근이라기보다, 로컬 환경에서 agentic 취약점 분석 파이프라인을 직접 구성해보는 연습에 더 가깝습니다.

글 내용을 보면 분석 방식을 one-shot 프롬프트, agentic/tool-calling, RAG 기반으로 나눠 설명한 뒤, 실제 구현은 Ollama + Qwen 3B급 로컬 모델 + pyghidra-mcp + Ghidra Headless 조합으로 잡습니다. 다시 말해 "좋은 모델 하나"보다 도구를 호출할 수 있는 구조, 디컴파일 결과를 다시 읽고 판단하는 루프, 결과를 누적해 리포트로 만드는 흐름에 초점을 맞춘 셈입니다.

물론 이런 구성이 바로 MYTHOS급 성능을 낸다는 뜻은 아닙니다. 같은 글도 그 점은 꽤 솔직하게 적고 있습니다. 다만 중요한 건, 이미 이런 식으로 로컬 모델을 분석 워크플로우 안에 넣어보고, 직접 harness와 프롬프트를 짜보는 시도가 충분히 현실적인 프로젝트가 되었다는 점입니다. 이건 "MYTHOS가 없으면 아무 것도 못 한다"는 결론과는 꽤 거리가 있습니다.

오히려 저는 이런 실험이 더 중요하다고 생각합니다. 나중에 더 강한 모델이 열리면 바꿔 끼우면 되지만, 도구 호출 구조, 우선순위 선정, 검증 루프, 보고 체계는 하루아침에 생기지 않기 때문입니다. 그러니 지금 단계에서는 최고 성능 모델의 유무보다 "우리도 이런 분석 파이프라인을 직접 굴려볼 수 있느냐"가 더 실질적인 질문에 가깝다고 봅니다.

지금 가능한 접근 왜 이게 중요한가
작은 모델로 넓게 훑기 AISLE 분석처럼 값싼 모델을 넓게 배치하면 coverage를 크게 늘릴 수 있음
파일/모듈 우선순위 매기기 Anthropic scaffold도 먼저 공격 표면이 큰 파일부터 정렬함
ASan, UBSan, sanitizer 기반 검증 붙이기 모델의 가설을 실행 결과로 걸러내야 hallucination을 줄일 수 있음
triage 전용 에이전트 두기 "버그가 있다"와 "실제로 중요한 버그다"는 다른 문제이기 때문
비싼 모델은 좁고 깊게 쓰기 광범위 탐색은 저렴한 모델, 어려운 확인은 강한 모델로 나누는 편이 현실적임
모델 교체가 쉬운 구조로 만들기 나중에 더 좋은 모델이 열리면 harness는 유지한 채 엔진만 바꿔치기 가능

저는 특히 마지막 줄이 중요하다고 생각합니다. 지금은 MYTHOS를 못 쓰더라도, 모델 독립적인 harness를 먼저 만들어 두면 나중에 더 좋은 모델이 공개되었을 때 그대로 얹어서 성능을 끌어올릴 수 있습니다. 반대로 지금 아무 구조도 없이 "좋은 모델만 나오면 되겠지" 하고 기다리면, 정작 모델이 열렸을 때도 운영 체계가 없어서 제대로 활용하기 어렵습니다.

대략적인 흐름은 아래처럼 잡을 수 있을 것 같습니다. 

1. 코드베이스/타겟을 준비한다
2. 위험도가 높은 파일과 경로를 먼저 추린다
3. 저렴한 모델 여러 개로 병렬 탐색한다
4. sanitizer, 테스트, 재현 스크립트로 결과를 검증한다
5. 별도 triage 단계에서 false positive와 중요도를 다시 가른다
6. 필요한 경우에만 더 강한 모델로 exploitability나 patch 방향을 깊게 본다
7. 보고서와 재현 절차를 남기고 다음 루프로 넘긴다

물론 이 방식은 MYTHOS 하나로 해결되는 그림보다 분명 손이 더 갑니다. harness를 짜야 하고, 실행 환경을 붙여야 하고, validation도 직접 돌려야 합니다. 하지만 그 수고를 들이면 현재 우리가 가진 모델들로도 꽤 괜찮은 효과를 낼 여지는 있어 보입니다. AISLE 글과 AgentFlow 논문은 적어도 그 방향성이 허황된 이야기는 아니라는 근거 정도는 제공해 주는 것 같습니다.

그리고 실제 구현 감각을 더 따라가 보고 싶다면, LLM 기반 취약점 자동 분석 도구 구현 글을 읽어보면 좋을 것 같습니다. 특히 로컬 LLM, Ghidra Headless, MCP 서버를 엮어서 실제로 어떻게 분석 루프를 만들 수 있는지 감을 잡는 데 도움이 됩니다.

마무리

정리하면 MYTHOS는 분명 가볍게 볼 대상은 아닙니다. Anthropic의 공식 기술 글만 봐도 이미 상당히 공격적인 수준의 보안 작업을 수행할 수 있다는 메시지는 분명합니다. 다만 공개된 자료를 기준으로 보면, 지금 우리가 느끼는 공포 중 일부는 MYTHOS라는 이름 하나에 너무 많은 의미를 실어 읽고 있는 데서 오는 면도 있어 보입니다.

xarkes의 분석은 Firefox 수치와 공개 근거를 조금 더 보수적으로 읽어야 한다고 말하고, AISLE의 글은 결국 쉽게 따라 하기 어려운 경쟁 우위를 만드는 건 모델 하나가 아니라 시스템이라고 주장합니다. 그리고 최근 harness 최적화 논문까지 같이 놓고 보면, 지금 우리가 집중해야 할 건 "MYTHOS를 못 쓰니 끝났다"가 아니라 현재 모델들로도 굴릴 수 있는 좋은 탐색 구조와 검증 루프를 먼저 만드는 것 쪽에 더 가까워 보입니다.

오히려 그런 구조를 먼저 만들어 둔다면, 나중에 더 좋은 모델이 열렸을 때 제일 먼저 이득을 보는 쪽도 결국 우리일 수 있습니다. 그러니 지금 단계에서는 MYTHOS를 과하게 신격화하거나 과하게 공포화하기보다, "저 정도 시스템이 공개 모델 생태계에서도 어느 정도까지 재현될까?"를 차분하게 실험해보는 편이 더 생산적이지 않을까 싶습니다.