Anthropic이 Project Glasswing과 Claude Mythos Preview를 공개했다.
2026년 4월 발표 기준으로 Mythos Preview는 일반 공개 모델이 아니다.
그리고 이 글도 “어떻게 취약점을 찾아서 악용하나”를 설명하는 글이 아니다.
그건 TECHTAEK에서도 안 한다.
여기서 다룰 질문은 이거다.
AI가 취약점을 더 빠르게 찾는 시대에, 평범한 개발팀의 보안 루틴은 무엇부터 바뀌어야 하나?
공식 발표를 보면 이 주제는 단순한 모델 뉴스가 아니다.
Anthropic은 Project Glasswing을 통해 AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks 같은 파트너들과 중요 소프트웨어 보안을 강화하겠다고 밝혔다.
Claude Mythos Preview는 이 프로젝트에서 방어 목적의 취약점 탐지에 쓰이는 비공개 frontier model이다.
이 말은 멋있다.
근데 개발팀 관점에서는 살짝 등줄기가 곧게 펴지는 말이기도 하다.
취약점 발견 비용이 내려가면 방어자도 빨라져야 하고, 공격자도 언젠가 빨라질 수 있기 때문이다.
보안은 원래도 귀찮았는데 이제 귀찮음에 터보가 붙었다.
먼저 결론
Claude Mythos Preview 자체를 대부분의 개발팀이 바로 쓸 수 있는 것은 아니다.
Anthropic도 Mythos Preview를 일반 공개할 계획이 없다고 밝혔다.
그래서 지금 해야 할 일은 “이 모델을 어떻게 써볼까?”가 아니다.
지금 해야 할 일은 AI가 취약점 탐지와 exploit 개발의 시간을 줄이는 환경에 맞춰 우리 팀의 보안 루틴을 재설계하는 것이다.
핵심은 다섯 가지다.
- 취약점 triage 시간을 줄인다.
- 패치 적용 SLA를 짧게 잡는다.
- 재현 가능한 보안 테스트 harness를 만든다.
- AI 도구 권한을 sandbox와 scope로 묶는다.
- disclosure와 maintainer 대응 프로세스를 문서화한다.
모델 이름은 바뀔 수 있다.
하지만 이 다섯 가지는 AI 보안 시대의 기본 체력이 될 가능성이 크다.
공식 발표에서 확인한 것
Anthropic의 Project Glasswing 발표는 Claude Mythos Preview를 일반-purpose unreleased frontier model로 설명한다.
공식 발표에 따르면 Mythos Preview는 every major operating system과 every major web browser에서 high-severity vulnerabilities를 발견했다고 한다.
또 Anthropic은 이 모델을 일반 공개하지 않고, 방어 목적의 파트너십 안에서 사용한다고 설명했다.
Project Glasswing에는 핵심 기술 기업과 보안 기업, 오픈소스 관련 조직이 참여한다.
Anthropic은 Mythos Preview usage credits와 오픈소스 보안 조직에 대한 직접 지원도 언급했다.
Red Team 블로그는 더 기술적인 내용을 다룬다.
다만 이 글에서는 구체적인 exploit 절차나 재현 방법은 다루지 않는다.
우리에게 필요한 건 공격 레시피가 아니라 방어 운영표다.
부엌칼이 위험하다고 해서 요리 블로그에 칼 던지는 법을 적을 필요는 없다.
왜 이 발표가 개발팀에 중요하나
많은 개발팀은 보안을 릴리즈 마지막 체크로 둔다.
기능 만들고, 테스트 돌리고, 배포 직전에 SAST 한번 돌리고, 의존성 경고가 뜨면 “이거 다음 스프린트에 보자”라고 한다.
이 방식은 이미 불안했다.
AI가 취약점 탐지 시간을 줄이면 더 불안해진다.
취약점이 발견되는 속도, 재현되는 속도, 패치가 분석되는 속도, N-day가 exploit으로 바뀌는 속도가 모두 빨라질 수 있기 때문이다.
Anthropic Red Team 글도 known vulnerability를 exploit으로 전환하는 능력, zero-day 발견, scaffold 기반 대량 탐색 같은 흐름을 설명한다.
이걸 개발팀 언어로 바꾸면 이렇다.
패치가 공개된 뒤 “언젠가 올리자”는 말의 수명이 더 짧아진다.
예전에는 공격자가 패치를 분석하고 exploit을 만드는 데 시간이 걸렸다면, AI 지원 도구가 그 시간을 줄일 수 있다.
그럼 방어자는 패치 대기열, 오픈 이슈, 보안 경고, 취약 dependency를 더 빨리 소화해야 한다.
일반 개발팀이 지금 바꿔야 할 것
아래 표가 핵심이다.
| 영역 | 예전 루틴 | AI 취약점 탐지 시대 루틴 |
|---|---|---|
| Dependency update | 월 1회 몰아서 처리 | critical/high는 24~72시간 SLA로 분리 |
| Security triage | 담당자 여유 있을 때 확인 | severity, exploitability, exposure 기준 자동 라우팅 |
| 테스트 | unit/integration 중심 | fuzzing, sanitizer, regression PoC 재현 harness 추가 |
| 코드 리뷰 | 기능 변경 위주 | auth, parser, deserialization, file/network boundary 체크 |
| 배포 | release 전 보안 스캔 | merge 전 baseline + release 전 재스캔 |
| incident 준비 | 장애 대응 중심 | 취약점 disclosure와 hotfix runbook 분리 |
이 표에서 중요한 건 도구 이름이 아니다.
보안 이슈를 일반 버그 대기열에 섞어두지 않는 것이다.
보안 이슈는 속도가 다르다.
일반 버그가 지각생이라면, critical 취약점은 초인종 누르고 들어오는 손님이다.
대충 거실에 앉혀두면 안 된다.
AI-ready security harness가 필요하다
Anthropic Red Team 글에서 흥미로운 부분은 단순히 “모델이 똑똑하다”가 아니다.
그들은 isolated container, project source, 실행 환경, agentic scaffold, 검증 단계, human triage를 함께 설명한다.
이 말은 중요하다.
모델만 강해져서 되는 게 아니라 모델이 실험할 수 있는 안전한 작업장이 필요하다는 뜻이다.
일반 개발팀도 이 방향을 따라갈 수 있다.
물론 Mythos Preview가 없어도 된다.
현재 쓰는 Claude Code, Codex, 정적 분석, fuzzing, dependency scanner, 테스트 자동화만으로도 아래 구조는 만들 수 있다.
| 구성 요소 | 필요한 이유 |
|---|---|
| isolated dev container | 실험이 로컬/운영 환경을 건드리지 않게 함 |
| reproducible build | 취약점 재현과 패치 검증을 반복 가능하게 함 |
| sanitizer/fuzzer config | memory, parser, input boundary를 자동으로 흔듦 |
| security test corpus | 깨지면 안 되는 입력과 과거 취약 케이스를 보존 |
| dependency exposure map | 취약 dependency가 실제 외부 입력 경로에 닿는지 판단 |
| human triage queue | AI가 찾은 후보를 바로 CVE급 사실로 착각하지 않게 함 |
| disclosure runbook | 외부 보고, maintainer 연락, 패치 일정, 공개 범위 결정 |
이게 바로 AI-ready security harness다.
거창한 플랫폼부터 만들 필요는 없다.
처음에는 security-smoke 명령 하나, 취약 dependency 대시보드 하나, 재현 로그 템플릿 하나면 된다.
작게 시작해도 반복 가능한 구조가 있으면 AI 도구를 붙이기 쉬워진다.
Claude Code 같은 개발 에이전트에 붙일 때의 경계
많은 팀은 이 발표를 보고 바로 이런 생각을 할 수 있다.
그럼 Claude Code나 다른 코딩 에이전트에게 우리 코드베이스를 보안 관점으로 훑게 하면 되나?
부분적으로는 맞다.
하지만 조건이 있다.
첫째, 권한을 제한해야 한다.
보안 테스트는 파일 읽기, 테스트 실행, 정적 분석, 컨테이너 안에서의 재현 정도로 시작하는 편이 안전하다.
운영 credential, 실제 고객 데이터, 내부 네트워크, 배포 권한은 처음부터 열면 안 된다.
둘째, 출력 형태를 bug report로 제한해야 한다.
AI에게 “취약점을 찾아라”라고만 하면 필요 이상으로 공격적인 산출물이 나올 수 있다.
대신 이렇게 시켜야 한다.
Find potential security weaknesses in this authorized repository.
Do not produce exploit code.
Return only:
- affected file and function,
- risk category,
- why it may be exploitable,
- safe reproduction idea at a high level,
- recommended fix,
- test to prevent regression.
셋째, human triage를 통과해야 한다.
AI가 말한 취약점 후보는 바로 보안 공지가 아니다.
false positive도 있고, 심각도 착각도 있고, 실제 exposure가 없는 경우도 있다.
넷째, 로그를 남겨야 한다.
누가 요청했고, 어떤 scope였고, 어떤 파일을 봤고, 어떤 결과를 냈고, 누가 triage했는지 남겨야 한다.
나중에 문제가 생겼을 때 “AI가 그랬어요”는 운영 보고서에서 그다지 든든한 문장이 아니다.
하지 말아야 할 것
이 주제는 선을 잘 그어야 한다.
아래는 하지 않는 편이 좋다.
| 하지 말 것 | 이유 |
|---|---|
| 운영 코드 전체를 승인 없는 외부 모델에 넣기 | 데이터·비밀키·계약 리스크 |
| “exploit 만들어줘” 식의 요청 | 방어 목적을 벗어나고 위험 산출물 가능 |
| AI 보고서를 곧바로 CVE급 사실로 공개 | false positive와 책임 문제 |
| 패치 없이 취약점만 backlog에 쌓기 | 발견 속도만 빨라지고 방어는 그대로 |
| 보안 권한을 일반 개발 에이전트 권한과 섞기 | least privilege가 무너짐 |
| dependency alert를 전부 같은 우선순위로 처리 | critical/high가 묻힘 |
특히 취약점 탐지 자동화는 발견보다 처리 체계가 먼저다.
발견만 빨라지고 triage와 patch가 느리면 보안팀은 대시보드만 더 빨갛게 보는 사람이 된다.
빨간 대시보드는 사람 마음을 참 기묘하게 때린다.
할 일은 많은데 색깔이 너무 성실하다.
팀 규모별 시작점
팀 규모에 따라 시작점은 달라야 한다.
혼자 개발하는 프로젝트라면 처음부터 거대한 보안 플랫폼을 만들 필요는 없다.
하지만 최소 루틴은 있어야 한다.
| 팀 규모 | 지금 시작할 것 |
|---|---|
| 1인 프로젝트 | dependency alert 주 2회 확인, critical patch 72시간 규칙, secret scan |
| 2~5명 스타트업 | security-smoke script, release 전 SAST/dependency scan, admin/auth 경로 체크리스트 |
| 6~30명 개발팀 | triage owner, vulnerability SLA, containerized repro harness, security regression test |
| 30명 이상 조직 | disclosure process, vuln intake queue, SBOM, fuzzing pipeline, AI-assisted review policy |
여기서 제일 중요한 건 누가 봐도 실행 가능한 규칙이다.
“보안 신경 쓰자”는 말은 약하다.
“critical dependency는 72시간 안에 patch PR을 열고, 예외는 CTO 승인으로 남긴다”는 말은 강하다.
AI 보안 시대에는 강한 문장이 필요하다.
Secure SDLC에 추가할 체크포인트
Project Glasswing 발표를 보고 개발팀이 secure SDLC에 추가할 수 있는 체크포인트는 아래와 같다.
| 단계 | 체크포인트 |
|---|---|
| 설계 | 외부 입력, 인증, 권한 상승, 파일/네트워크 경계 표시 |
| 구현 | parser, deserialization, command execution, unsafe code 리뷰 |
| PR | AI-assisted security review는 read-only 권한으로 시작 |
| 테스트 | fuzzing, sanitizer, regression corpus, dependency scan |
| 배포 | public exposure가 있는 변경은 보안 smoke test 필수 |
| 운영 | CVE alert와 실제 exposure 매핑 |
| 사후 | 패치 지연 이유와 재발 방지 test 저장 |
이 정도만 해도 팀의 보안 대화가 바뀐다.
예전에는 “이거 위험해 보여요”였다면, 이제는 “이 경로는 외부 입력을 받아 parser를 타고, sanitizer test가 없고, dependency alert가 high라서 오늘 triage해야 해요”가 된다.
두 번째 문장은 조금 딱딱하지만 일을 앞으로 밀어낸다.
보안은 감정이 아니라 workflow가 이긴다.
AI 보안 리뷰 프롬프트 예시
공격적인 exploit 산출물이 아니라 방어적 리뷰를 원한다면 프롬프트도 그렇게 묶어야 한다.
아래는 안전한 시작점이다.
You are reviewing this authorized codebase for defensive security.
Do not write exploit code.
Do not provide step-by-step abuse instructions.
Focus on:
- risky input boundaries,
- authentication and authorization gaps,
- dependency exposure,
- unsafe parsing or deserialization,
- missing tests,
- recommended patches.
Return findings as:
1. title
2. affected path
3. risk level
4. why this matters
5. safe verification approach
6. suggested fix
7. regression test idea
이런 형식이면 개발팀이 실제 PR로 옮기기 쉽다.
그리고 위험한 세부 exploit을 피하면서도 방어적 가치를 얻을 수 있다.
이런 게 좋은 자동화다.
손에 잡히고, 범위가 좁고, 기록이 남는다.
한 장 운영표
마지막으로 Project Glasswing 이후 개발팀이 볼 운영표를 남긴다.
| 질문 | 답 |
|---|---|
| Mythos Preview를 바로 써야 하나? | 일반 공개 모델이 아니므로 대부분 팀의 질문은 “어떻게 쓸까”가 아니라 “어떻게 대비할까”다 |
| AI 보안 리뷰를 도입해도 되나? | authorized repo, read-only, sandbox, no exploit output 조건이면 시작 가능 |
| 가장 먼저 바꿀 루틴은? | critical/high 취약점 triage와 patch SLA |
| 가장 위험한 착각은? | AI가 찾았으니 곧바로 사실이라고 믿는 것 |
| 가장 필요한 산출물은? | 재현 가능한 report, patch, regression test |
| 보안팀이 없어도 가능한가? | 가능하지만 최소 owner와 escalation rule은 필요 |
결론은 간단하다.
AI가 취약점을 더 잘 찾는 시대에는 우리도 취약점을 더 빨리 처리해야 한다.
발견 속도만 빨라지고 패치 속도가 그대로면 방어가 아니라 알림 폭탄이다.
Project Glasswing은 거대한 모델 발표이기도 하지만, 평범한 개발팀에게는 보안 루틴을 더 짧고, 반복 가능하고, 기록 가능한 형태로 바꾸라는 신호다.
모델은 화려하다.
근데 팀을 지키는 건 결국 runbook, test, patch, triage, 로그다.
멋은 발표장에서 나오고, 신뢰는 체크리스트에서 나온다.
함께 보면 좋은 글
- Claude Advisor Strategy는 언제 써야 하나 2026 — Sonnet·Haiku executor와 Opus advisor 비용·권한 경계표
- Google Cloud AI 에이전트 거버넌스 5계층 2026 Agent Identity·Registry·Gateway·Model Armor 운영 체크리스트
- Claude Code MCP vs script 2026 – when a custom tool is too much and when shell is enough
FAQ
Claude Mythos Preview는 지금 일반 사용자가 쓸 수 있나?
아니다.
Anthropic은 Mythos Preview를 일반 공개할 계획이 없다고 밝혔다.
Project Glasswing 파트너와 일부 중요한 소프트웨어 인프라 유지 조직이 방어 목적 연구 preview 안에서 접근하는 구조다.
이 발표는 개발팀에게 당장 어떤 의미가 있나?
AI가 취약점 탐지와 exploit 개발의 시간을 줄일 수 있다는 신호다.
대부분 팀은 모델 접근보다 보안 triage, patch SLA, dependency update, secure SDLC, AI 보안 리뷰 권한 경계를 먼저 정비해야 한다.
AI에게 우리 코드 보안 리뷰를 맡겨도 되나?
허가된 코드베이스, read-only 권한, sandbox, 비밀정보 제거, no exploit output 조건이면 방어적 리뷰로 시작할 수 있다.
다만 AI 결과는 후보일 뿐이고, human triage와 재현 가능한 테스트가 필요하다.
AI 보안 리뷰에서 금지해야 할 출력은?
실제 악용을 쉽게 하는 단계별 exploit 지침, 운영 시스템 공격 절차, 인증 우회 실행 방법, 무단 접근을 전제로 한 명령은 금지해야 한다.
대신 위험 설명, 안전한 검증 아이디어, 패치 방향, regression test를 요구하는 편이 낫다.
가장 먼저 만들 runbook은 무엇인가?
critical/high 취약점 처리 runbook이다.
누가 triage하는지, 몇 시간 안에 PR을 여는지, 예외 승인은 누가 하는지, 어떤 테스트를 붙여야 닫을 수 있는지부터 정해야 한다.