들어가며
2026년 3월 26일, Anthropic의 CMS 설정 오류로 약 3,000개의 미공개 문서가 잠시 노출됐고, 그중 "Capybara"라는 코드네임의 차세대 모델 드래프트 블로그 포스트가 발견됐다. 4월 7–8일, Anthropic은 이 모델을 Claude Mythos Preview라는 공식 명칭으로 세상에 공개했다.
그런데 공개와 동시에 회사가 내놓은 선언이 더 흥미로웠다. 요약하면 "만들었지만 여러분에게는 주지 않겠다" 였다. 대신 Anthropic은 AWS, Apple, Google, Microsoft, NVIDIA, JPMorgan Chase, Linux Foundation을 포함한 12개 창립 파트너와 40여 개의 중요 인프라 유지관리 조직에만 제한적으로 제공하는 Project Glasswing이라는 프레임워크를 발표했다.
4월 16일에는 Opus 4.7이 별도로 출시됐는데, 시장은 이를 "Mythos의 능력 중 안전하게 공개 가능한 부분만 떼어낸 버전"으로 읽고 있다.
이 글은 두 가지를 다룬다. 첫째, Mythos는 언제, 어떤 경로로 일반 사용자에게 오는가. 둘째, 그 과정에서 오픈소스 생태계는 어떤 압력을 받고 어떻게 재편될 것인가.
1. 지금까지 확정된 사실들
1.1 모델의 실체
- 코드네임: Capybara
- 공식 명칭: Claude Mythos Preview
- 모델 티어: Opus 상위의 새로운 티어 (기존 Haiku → Sonnet → Opus 라인업을 넘어서는 새 계층)
- 컨텍스트 윈도우: 1M 토큰, 최대 출력 128K
- 지식 컷오프: 2025년 12월
- SWE-bench Verified: 93.9% (Opus 4.6의 80.8%, 비교 기준 시점의 프론티어를 압도)
- USAMO: 97.6%
- 배포 채널: Claude API, Amazon Bedrock, Google Vertex AI, Microsoft Foundry (모두 gated preview)
1.2 Anthropic의 공식 입장
Anthropic은 공식 블로그에서 "Claude Mythos Preview를 일반 공개할 계획이 없다" 고 명시했다. 이 선언은 전례가 드물다. 역사적으로 AI 랩은 모델을 만들면 어떻게든 수익화하려는 유인이 강했는데, 여기서는 정반대 방향을 택했다.
다만 "Mythos-class 모델" — 즉 같은 계열의 후속 모델 — 은 언젠가 일반 공개를 지향한다고 밝혔다. 시점은 명시하지 않았다. 업계 관찰자들은 과거 gated preview가 일반 공개로 넘어간 패턴(3–6개월)을 참고해 연말에서 2027년 초를 추정하지만, Anthropic 자체가 어떤 약속도 하지 않았다는 점이 핵심이다.
1.3 왜 이런 결정이 내려졌나
Anthropic의 논리는 대략 이렇게 구성된다.
첫째, Mythos의 사이버 능력이 "대단히 숙련된 인간 연구자 수준을 넘어선다"고 내부 평가됐다. 실제로 Anthropic Red Team 테스트에서 Mythos는 OpenBSD의 27년 묵은 버그, FFmpeg의 16년 묵은 결함, Linux 커널의 chained exploit을 스스로 발견해냈다. 특히 FFmpeg 버그는 수백만 회의 자동화 테스트로도 발견되지 않던 것을 코드 추론만으로 찾아냈다는 점이 충격적이었다.
둘째, 샌드박스 탈출 사례가 보고됐다. 사이버보안 테스트 중 모델이 샌드박스를 벗어나 공개 채널에 무단 게시물을 올린 일이 확인됐다.
셋째, 발견과 악용 사이의 시간차가 붕괴된다는 인식이다. CrowdStrike CTO Elia Zaitsev는 공식 성명에서 과거 수개월 걸리던 발견-악용 간극이 AI 시대에는 수 분 단위로 좁혀진다고 경고했다.
이 세 가지가 합쳐져 "그냥 풀면 공격자에게도 같은 무기를 주는 셈"이라는 결론에 도달했고, 그 해답이 Glasswing이었다.
2. Glasswing이라는 새로운 배포 아키텍처
2.1 3단 구조
Glasswing은 단순한 파트너 프로그램이 아니라 새로운 AI 배포 거버넌스 모델의 실험이다. 구조는 3단으로 짜여 있다.
- 12개 창립 파트너: AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, Anthropic. 자사 제품과 인프라 보안 강화용으로 Mythos를 사용.
- 40여 개 중요 인프라 유지관리 조직: OS, 브라우저, 커널, 핵심 오픈소스 라이브러리 메인테이너들. 직접 코드베이스 스캔 권한.
- 오픈소스 메인테이너: Claude for Open Source 프로그램을 통한 신청 기반 접근. Anthropic이 Linux Foundation의 Alpha-Omega/OpenSSF에 $2.5M, Apache Software Foundation에 $1.5M을 별도 기부했고, 총 $100M의 모델 사용 크레딧을 연합 전체에 배정했다.
Glasswing 크레딧 소진 후 실제 가격은 $25 / $125 per million input/output tokens로 책정됐다. Opus 4.7의 $5/$25 대비 5배 비싼 가격이다. "접근 가능하지만 아무나 쓸 수는 없는" 이중 장벽 구조다.
2.2 90일 공개 보고
Anthropic은 90일 내에 Glasswing이 찾고 수정한 취약점에 대한 공개 보고서를 내겠다고 약속했다. 또한 SHA-3 커밋먼트 방식을 통해 이미 발견한 취약점과 익스플로잇의 해시를 먼저 공개하고, responsible disclosure 완료 후(최대 90+45일) 상세 내용을 풀겠다는 프로토콜을 명시했다. 조작 불가능한 시간 선언 이다.
이 부분이 흥미롭다. 전통적인 coordinated disclosure는 "발견자와 벤더 사이의 암묵적 신뢰"에 의존했는데, Mythos 규모에서는 그게 불가능하니 암호학적 커밋먼트로 외부 감사 가능성을 확보하겠다는 것이다.
3. 오픈소스 생태계가 마주한 세 가지 긴장
여기서부터가 본격적인 고찰 영역이다. Glasswing이 오픈소스에 "선물"인지 "재앙"인지는 간단한 질문이 아니다. 구체적 긴장 세 가지를 풀어본다.
3.1 긴장 ① — 메인테이너 워크로드의 비대칭 폭증
cURL 프로젝트의 Daniel Stenberg는 이미 AI slop 리포트 때문에 버그 바운티 정책을 중단해야 했다. 최근 들어 AI 리포트 품질이 올라가긴 했지만, 문제는 "좋은 AI 리포트도 메인테이너 시간을 잡아먹는다" 는 점이다.
Glasswing은 품질은 좋을 것이다 — Mythos가 찾는 건 진짜 취약점이다. 하지만 "수천 개의 진짜 취약점 리포트"가 평일 저녁 두 명이 유지하던 라이브러리에 쏟아진다면? 이것이 Chainguard CEO Dan Lorenc와 Linux Foundation David Wheeler가 공통으로 지적한 지점이다.
이 비대칭은 구조적이다.
- 연합 파트너(Microsoft, Apple, Google): 전담 보안팀이 있어서 대량 디스클로저를 흡수 가능.
- 중간 계층(독립 오픈소스 프로젝트): 아무리 중요한 소프트웨어라도 풀타임 보안 인력이 없으면 쓰나미를 막을 수 없음.
- 하위 의존성(트랜지티브 패키지): 자기가 공격 표면에 들어있다는 사실조차 모르는 수천 개 작은 프로젝트.
Preset의 분석이 이를 잘 표현한다: "좋은 의도가 나쁜 결과를 만들 수 있다(Good intentions can still create bad outcomes)."
3.2 긴장 ② — Disclosure 인프라의 근본 가정 붕괴
지난 20년간의 coordinated disclosure 체계는 암묵적으로 "발견량은 유한하다" 는 가정 위에 서 있었다. 연구자 한 명이 몇 달에 걸쳐 찾아내는 취약점 수십 개가 벤더 보안팀이 처리할 수 있는 분량과 맞물려 돌아갔다.
Mythos는 이 가정을 깨뜨린다. 수일 내에 수천 개의 zero-day를 발견할 수 있다면, CVE 발급 시스템, 패치 배포 파이프라인, 소비자 업데이트 주기 — 이 모든 레이어의 처리 한계가 병목이 된다.
실무자 입장에서 이게 무슨 뜻이냐:
- "unpatched 상태로 흘러다니는 시간"이 구조적으로 길어진다. SHA-3 커밋먼트로 해시는 먼저 공개되는데, 패치는 줄 서서 기다려야 하기 때문.
- patch window가 hours 단위로 내려간다. 발표 즉시 공격자가 동일 취약점을 역산할 수 있는 시대.
- 자동 패칭 체계 구축이 더 이상 선택이 아니게 된다. 수동 업데이트에 의존하는 조직은 구조적으로 노출.
Anthropic이 별도로 공개 가이드라인에 취약점 공개 프로세스, SDLC 관행, 패치 자동화, triage 스케일링을 다루겠다고 명시한 것은 이 가정 붕괴를 인정한 결과다.
3.3 긴장 ③ — 접근 비대칭과 플랫폼 락인
Glasswing의 가장 날카로운 비판은 "이게 공공재 모델인가, 아니면 Anthropic이 디스클로저 규범을 정의할 수 있는 governance bid(거버넌스 선점 시도)인가"라는 질문이다.
Linux Foundation의 David Wheeler는 공식 지지 입장에서도 lock-in에 대한 우려를 분명히 표명했다. 대안으로 AIxCC에서 나온 OSS-CRS(Open Source Software Cyber Reasoning System) 같은 오픈 오케스트레이션 프레임워크를 언급했다. OSS-CRS는 LLM 기반 자동 버그 발견 시스템을 특정 모델에 묶이지 않고 구축·실행할 수 있게 해주는 추상화 레이어다.
이게 왜 중요하냐면 — 만약 메인테이너들이 Mythos에만 의존하기 시작하면, 나중에 Mythos-class 모델의 일반 가격이 $25/$125 수준으로 올라갔을 때 오픈소스 생태계 전체가 비용 협상력 없는 소비자로 전락할 수 있다. 지금의 무료 크레딧은 유인이지만 동시에 함정이기도 하다.
대응책은 두 가지 방향으로 논의 중이다.
- 모델 추상화 계층: OSS-CRS 같은 오케스트레이션 표준을 먼저 정착시켜 어느 모델이든 꽂아 쓸 수 있게.
- 다중 프로바이더 정책: 오픈소스 재단 차원에서 최소 2개 이상의 AI 벤더를 동시 활용하도록 규범화.
4. 그럼에도 기회가 될 수 있는 이유
비판 일변도로만 보면 균형이 맞지 않는다. Glasswing이 오픈소스에 기회인 지점도 분명하다.
첫째, "오픈소스는 공공재인데 메인테이너는 자원봉사" 문제가 처음으로 대기업 머니와 붙었다. Anthropic의 $4M 기부는 규모 자체는 작지만, AI 인프라가 오픈소스 위에서 동작한다는 사실을 가치 추출자가 투자 의무를 가진다는 담론으로 전환시키는 선례다. 후속 AI 랩들이 유사한 기부 관행을 따라야 하는 비교 기준이 생긴 것이다.
둘째, 보안 부채 청산 기회. 많은 오픈소스 프로젝트는 수년간 누적된 보안 부채를 안고 있는데, 이를 정리할 인적 자원이 없었다. Mythos 같은 도구에 선제적으로 접근할 수 있는 메인테이너는 "방어 우위"를 먼저 확보할 수 있다. 늦게 움직이는 프로젝트와 격차가 벌어질 것이다.
셋째, AI 거버넌스 논의에 오픈소스 진영의 발언권이 생겼다. 그간 AI 정책 테이블에서 오픈소스는 방청석이었다. 지금은 Linux Foundation과 ASF가 Glasswing의 핵심 파트너로 들어가 있다. 이 위치가 앞으로의 AI 규제 설계에 영향을 줄 것이다.
5. 한국 개발자·조직 입장에서 준비할 것들
글로벌 서사를 한국 맥락으로 가져오면 몇 가지가 보인다.
5.1 이커머스·핀테크 백엔드 관점
대부분의 국내 이커머스·핀테크 스택은 오픈소스 의존성 수백 개 위에 올라가 있다. Spring Boot 하나만 해도 트랜지티브 디펜던시가 수천 개다. Glasswing이 90일 내 공개 보고로 wave를 일으키면, Dependabot, Renovate, Trivy 같은 자동 의존성 업데이트 체계가 이미 구축되어 있지 않은 팀은 대응 속도에서 구조적으로 뒤처진다.
준비 항목:
- SBOM(Software Bill of Materials) 생성 자동화 — CycloneDX 또는 SPDX
- CVE 모니터링 파이프라인 — OSV-Scanner, GitHub Dependabot alerts
- 컨테이너 이미지 스캐닝 상시화 — Trivy, Grype
- 의존성 업데이트 PR을 자동 승인까지 연결하는 정책 (테스트 커버리지가 허락하는 범위에서)
5.2 Spring AI 기반 RAG/에이전트 프로젝트 관점
Spring AI로 RAG 파이프라인이나 에이전틱 워크플로우를 만드는 입장에서 중요한 시사점은 "내 시스템이 소비하는 오픈소스도 공격 대상이고, 내 시스템이 생성하는 코드도 검증 대상" 이라는 이중 노출이다.
AI 에이전트가 만든 코드에 기존보다 더 엄격한 정적 분석·SAST 계층이 필요해진다. Glasswing이 만들 "AI가 만든 코드가 AI가 스캔하는 코드를 불러오는" 구조에서는 CI 파이프라인에 Semgrep, SonarQube, Snyk Code 중 하나는 반드시 있어야 한다.
5.3 정보관리기술사/거버넌스 관점
Glasswing이 90일 내에 내놓을 공개 가이드라인은 차세대 보안 표준의 초안이 될 가능성이 높다. 취약점 디스클로저, 패치 자동화, SDLC 통합, triage 스케일링 — 이 네 축이 한국 규제 환경(K-ISMS, 개인정보보호법 개정, 금감원 전자금융감독규정)과 어떻게 맞물릴지가 2026년 하반기 거버넌스 이슈가 될 것이다.
6. 공개 시점에 대한 개인적 전망
공식 로드맵은 없다. 그래도 단서 몇 개를 조합하면 추정은 가능하다.
- Anthropic은 90일 공개 보고를 약속했다. 그 시점이 2026년 7월 초.
- 90일 보고서에서 "주요 취약점이 대부분 패치됐다"고 발표할 수 있으면, Mythos-class의 일반 공개 논의가 시작될 명분이 생긴다.
- Opus 4.7이 "Mythos의 민간 공개 가능 부분"이라는 해석이 맞다면, 그 다음 단계는 Opus 5.x 혹은 별도 Sonnet/Opus 계통의 "Mythos-capability 통합 버전"이다.
- 경쟁사(특히 OpenAI의 Trusted Access for Cyber)가 유사 프로그램을 내놓으면 속도가 강제로 붙는다.
개인적 추정: 2026년 4분기 말 ~ 2027년 1분기에 Mythos-class 일반 공개 모델이 나올 가능성이 가장 높다고 본다. 단, "Mythos Preview 그 자체"는 끝까지 일반 공개되지 않을 것이다. 공격 능력이 너무 선명하게 드러난 모델이라 Anthropic이 되돌리기 어려운 이미지가 됐다.
7. 마무리 — "기다림"이 아니라 "대비"의 시간
Mythos는 지금 평범한 한국 개발자가 만질 수 있는 모델이 아니다. 그러나 Mythos가 만들 파장은 이미 모든 오픈소스 의존 스택에 밀려오고 있다. 90일 뒤 공개 보고서가 나오면 수천 개의 실제 취약점 디스클로저가 시작된다. 그 wave를 맞을 준비가 되어 있는 조직과 그렇지 못한 조직의 격차는, Mythos를 손에 쥔 조직과 그렇지 못한 조직의 격차보다 훨씬 현실적이다.
Claude Opus 4.7이 한 달 전 출시됐을 때 우리가 본 것은 "같은 가격에 더 좋은 모델"이라는 익숙한 업그레이드였다. Mythos가 우리에게 보여주는 것은 그보다 불편한 질문이다 — "어떤 AI는 풀리지 않는 게 더 안전하다" 는 명제가 처음으로 AI 랩 스스로의 입에서 나왔다는 것. 이 문장이 기술 블로그의 소재를 넘어 산업 전체의 작동 방식에 어떻게 스며들지가, 2026년 하반기를 통과하는 모든 개발자가 함께 관찰해야 할 실험이다.
참고 자료
- Anthropic — Project Glasswing 공식 페이지
- Anthropic Red Team — Claude Mythos Preview 기술 분석
- Linux Foundation — Project Glasswing 지지 포스트
- The Register — "Project Glasswing and open source: The good, bad, and ugly"
- The New Stack — "Anthropic's Claude Mythos is now available, but not for you"
- Bloo — Glasswing Disclosure Architecture 분석
- Preset — "Project Glasswing and the ASF: Open Source's Chance to Win the AI Era"
- Pluralsight — "What is Claude Mythos?"
'Software > Maker(Spring & Python & node)' 카테고리의 다른 글
| Spring AI 1.0과 2.0 — 2년의 여정, 그리고 Java AI 스택의 재편 (0) | 2026.04.23 |
|---|---|
| 분산 시스템 기반 대규모 트래픽 처리(wil. 7week) (0) | 2026.04.23 |
| Claude Opus 4.7, 4.6과 무엇이 달라졌나 — 실사용자 관점 마이그레이션 노트 (0) | 2026.04.23 |
| 정산 시스템 아키텍처 설계 경험 — 데이터 정합성과 장애 복구를 중심으로 (0) | 2026.04.22 |
| 정산 시스템 기술 스택의 진화 — 왜 Java/Spring은 여전히 살아남고, AI 시대에도 바뀌지 않는 핵심 문제들 (0) | 2026.04.22 |