포스트

Claude Mythos는 무엇인가 — 개발자 관점에서 정리

Anthropic이 일반 공개 없이 풀어낸 신모델, Project Glasswing, 그리고 우리가 알아둬야 할 것들

Claude Mythos는 무엇인가 — 개발자 관점에서 정리

Claude Mythos는 무엇인가 — 개발자 관점에서 정리

4월 7일 Anthropic이 공개한 새 모델 “Claude Mythos Preview”가 며칠째 보안 업계를 흔들고 있다. 일반 공개도 안 했고, 평소 같은 베타 프로그램 형태도 아니다. 정리할 만한 가치가 있다 싶어 한 번 짚어둔다.

발단 — 유출이 먼저였다

이상한 순서로 알려진 모델이다. 3월 26일, Anthropic 사이트의 CMS 설정이 잠깐 잘못된 사이에 “Mythos”라는 이름의 미공개 블로그 초안이 외부에 노출됐다. 보도가 떴고, Fortune이 “step change in capabilities” 라는 표현을 인용해서 기사를 냈다. Anthropic은 그 시점엔 모델 존재 자체를 부인하지 않으면서 “내부 테스트 중”이라고만 답했다.

그리고 약 2주 뒤인 4월 7일, Claude Mythos Preview라는 이름으로 정식 발표가 이뤄졌다. 다만 우리가 평소에 기대하는 형태의 “발표”는 아니었다. API 키 발급 페이지가 열린 게 아니라, Project Glasswing이라는 제한된 파트너 프로그램이 함께 공개됐다.

Mythos가 무엇이고, Opus와 뭐가 다른가

Anthropic의 공식 설명을 정리하면 이렇다.

  • 범용 언어 모델이다. 코드, 추론, 도구 사용 전반에서 Claude Opus 4.6보다 의미 있게 좋다.
  • 하지만 특히 컴퓨터 보안 작업에서의 능력이 전 세대와 차원이 다르다. Anthropic 표현으로는 “substantially beyond those of any model they have previously trained”.
  • 이 능력은 명시적으로 보안 작업에 맞춰 학습시킨 결과가 아니다. 코드 이해, 추론, 에이전트적 자율성이 전반적으로 좋아진 결과로 자연스럽게 따라온 부산물이라는 것.

마지막 항목이 개발자 입장에서 가장 신경 쓰이는 부분이다. 보안 능력을 의도해서 키운 게 아니라 “코드 잘 짜고, 추론 잘하고, 멀티스텝 자율성이 좋아지면 자연스럽게 익스플로잇도 잘 만든다”는 뜻이기 때문이다. 패칭 능력과 익스플로잇 능력이 같은 축에 있다는 얘기다.

벤치마크가 말하는 차이

Anthropic 레드팀은 자체 벤치마크 결과를 공개했다. OSS-Fuzz 코퍼스의 약 1000개 오픈소스 프로젝트, 약 7000개 진입점에 대해 한 번씩 모델을 돌리고 가장 심각한 크래시를 5단계로 채점한 결과다.

모델 Tier 1~2 (단순 크래시) Tier 3~4 (메모리 손상) Tier 5 (제어 흐름 탈취)
Sonnet 4.6 약 250건 1건 0건
Opus 4.6 약 270건 1건 0건
Mythos Preview 595건 수 건 10건

Tier 5는 이미 패치된 타깃에서도 풀 컨트롤 플로우 하이재킹을 자동으로 만들어냈다는 의미다. 모델이 자율적으로 익스플로잇 체인을 구성하는 단계까지 갔다는 뜻이고, 직전 세대인 Opus 4.6에서는 본 적 없는 결과다.

또 다른 비교 — Firefox 147의 자바스크립트 엔진 취약점들을 셸 익스플로잇으로 변환하는 작업이 있다. Opus 4.6은 수백 번 시도 중 2번 성공했다. 같은 실험에서 Mythos Preview는 181번 성공했고, 추가로 29번은 레지스터 제어까지 갔다. 두 자릿수 배가 아니라 거의 두 자릿수 배 그 이상이다.

실제로 찾아낸 것들 — 굵직한 것 두 개

레드팀 글에서 공개한 실례 중 인상적인 두 가지다.

27년 묵은 OpenBSD TCP SACK 버그. 1998년 OpenBSD가 SACK(Selective ACK)을 도입한 이래 누구도 못 본 버그다. 두 개의 결함이 겹쳐야 트리거된다. 첫째, SACK 블록의 끝은 윈도우 안에 있는지 확인하지만 시작은 확인하지 않는다. 둘째, 단일 SACK 블록이 마지막 hole을 삭제하면서 동시에 새 hole을 append하는 경로가 있는데, 이건 정상적으론 도달 불가능한 코드 경로다 — 한 숫자가 hole의 시작보다 작으면서 동시에 가장 높은 ack보다 클 수는 없으니까. 그런데 32비트 시퀀스 번호 비교에 부호 있는 정수 오버플로가 끼어드는 순간 그 모순이 성립한다. 모델이 그 트릭을 스스로 찾아냈다. 결과는 NULL 포인터 라이트 → 커널 크래시. 원격에서 OpenBSD 호스트를 임의로 죽일 수 있는 DoS다. “보안성으로 정평 난 OS가 27년간 못 잡은 버그”가 LLM 1000회 자동 실행 ($20,000 비용)으로 발견됐다.

16년 묵은 FFmpeg H.264 디코더 버그. 거의 모든 비디오 처리 서비스가 의존하는 라이브러리다. 퍼징으로 학계 논문이 여러 편 나올 정도로 두들겨 맞은 코드베이스다. 그런데 H.264 슬라이스 경계와 deblocking filter 사이의 미묘한 인덱싱 결함이 16년간 살아남아 있었고, Mythos가 자동 발견했다.

이 외에도 공식 글에 따르면, 한 케이스에서는 취약점 4개를 체이닝한 브라우저 익스플로잇을 모델이 직접 작성했다. JIT heap spray로 렌더러 샌드박스와 OS 샌드박스를 모두 탈출. 또 다른 케이스에서는 FreeBSD NFS 서버 RCE — 20개짜리 ROP 체인을 여러 패킷에 분할해서 전송하는 익스플로잇이다. 무인증 사용자가 root을 얻는다. 이 전부 사람의 개입 없이 모델 단독으로 만든 결과다.

그래서 왜 일반 공개를 안 하는가 — Project Glasswing

여기서 Anthropic의 선택이 흥미롭다. 보통 신모델은 공개와 동시에 API 키만 있으면 누구나 쓸 수 있게 푼다. Mythos는 그렇게 안 했다. 대신 Project Glasswing이라는 한정된 파트너 프로그램으로만 접근을 제공한다.

공개된 파트너는 Apple, Google, Microsoft, Cisco, Amazon, JPMorgan Chase, Nvidia, CrowdStrike 등 — 핵심 인프라/플랫폼/보안 사업자들이다. 의도는 분명하다. 공격자보다 방어자가 먼저 이 능력을 갖게 하자는 것.

Anthropic의 논리는 이렇다. 역사적으로 보안 도구는 결국 방어자에게 더 큰 이득을 줬다. AFL 같은 퍼저가 처음 나왔을 때도 공격자에게 유리할 거라는 우려가 있었지만, OSS-Fuzz를 거쳐 지금은 방어 인프라의 핵심이다. LLM도 장기적으로는 방어자에게 더 유리할 거라는 게 그들의 베팅이다. 다만 전환기에는 공격자에게 일시적으로 유리할 수 있고, 그 격차를 줄이기 위해 일반 공개 대신 방어자 우선 배포를 택한다는 것.

설득력은 있다. 다만 풀리지 않은 의문도 분명하다.

  1. “선택된 critical infrastructure” 의 기준은 누가 정하는가
  2. 파트너에 들지 않은 수많은 오픈소스 메인테이너는 어떻게 보호받나
  3. 공식 발표 이후 보도된 무단 접근 의혹 — 정체 미상의 그룹이 Mythos에 접근하고 있다는 보도가 있었고, Anthropic은 조사 중이라고만 답했다

3번이 특히 중요하다. 가장 강력한 모델일수록 접근 통제 자체가 보안 자산이 되는데, 그 통제가 뚫리면 게이팅 모델 자체의 정당성이 흔들린다.

개발자가 지금 챙겨야 할 것

당장은 우리 손에 직접 들어오는 모델은 아니다. 하지만 방향은 분명하다. Mythos급 능력은 1년 안에 어떤 형태로든 일반 공개될 가능성이 높고, 비슷한 능력의 다른 모델도 따라온다. 그 사이에 정리해둘 것들이 있다.

첫째, 메모리 안전성에 의존하던 시대의 종료를 받아들여야 한다. C/C++ 코드베이스에서 “audit이 충분히 됐으니 큰 버그는 더 없을 것” 이라는 가정은 더 이상 안 통한다. OSS-Fuzz가 수년간 두들긴 FFmpeg에서도 16년 묵은 버그가 나왔다. 새 코드는 가능하면 Rust, Go 같은 메모리 안전 언어로 가고, 기존 C/C++ 코드도 boundary 검사, ASan 빌드 CI 같은 위생 도구를 더 적극적으로 도입해야 한다.

둘째, N-day 패치 속도 자체가 보안 지표가 된다. Mythos는 패치 노트에서 취약점 정보를 역으로 추적해 익스플로잇을 만드는 데 매우 능숙하다. CVE 발표와 패치 적용 사이의 윈도우가 좁아질수록 안전해진다. 사내 패치 SLO를 다시 점검할 시점이다.

셋째, 백엔드 입장에서 가장 위험한 건 “잘 알려진 라이브러리의 안 알려진 버그”다. OpenSSL, FFmpeg, libxml2, glibc, 그리고 OS 커널의 네트워크 스택. 우리가 직접 짠 코드보다 이런 의존성이 먼저 뚫린다. SBOM(Software Bill of Materials)을 진지하게 도입할 시간이다. 어떤 버전의 어떤 라이브러리를 어디 배포에 쓰고 있는지 모르면, CVE가 떴을 때 “우리 영향받나?” 에 답할 수가 없다.

넷째, 모델을 위한 인프라가 새로운 공격 표면이다. Mythos는 격리된 컨테이너 안에서 도구(디버거, 프로젝트 빌드, 자체 테스트)를 자유롭게 쓰며 작업했다. 이런 에이전트가 사내에 도입될 때, 그게 닿을 수 있는 시스템 권한 범위가 곧 새로운 신뢰 경계가 된다. “AI 어시스턴트에게 prod 접근 권한을 줄 것인가” 라는 질문은 더 이상 농담이 아니다.

마치며

LLM의 보안 능력에 대한 논의는 그동안 다소 이론적이었다. “언젠가 모델이 zero-day를 자동으로 찾을지도 모른다” 는 식의. Mythos Preview는 그 “언젠가”가 이미 와 있다는 걸 보여줬다. OpenBSD 27년, FFmpeg 16년 — 사람이 두들겨도 못 잡은 게 한 모델 1000회 실행에 풀렸다.

Anthropic의 Glasswing 전략이 옳은지는 한참 더 두고 봐야 알 수 있다. 다만 한 가지는 분명하다. 백엔드에 발 담그고 있는 사람이라면, 메모리 안전성·패치 속도·SBOM·에이전트 접근 통제 — 이 네 가지를 향후 몇 분기의 우선순위에 올려둬야 한다. 하나는 우리 코드의 문제고, 셋은 우리가 의존하는 것들의 문제다.

다음 글에서는 AISI의 Mythos 평가 보고서를 기준으로 외부 평가가 어떻게 다른지 정리해보려고 한다.


참고 자료

이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.