1만 개 취약점 뒤의 병목, Mythos가 바꾼 패치 속도

AI 요약

• 무슨 일: Anthropic이 Project Glasswing 첫 업데이트에서 1만 개 이상 high/critical 취약점 발견을 공개했습니다.
  • 약 50개 파트너가 Claude Mythos Preview를 방어용으로 쓰고 있으며, 모델은 아직 일반 공개되지 않았습니다.
• 핵심 병목: 취약점 발견보다 검증, 조율 공개, 패치 작성, 배포가 더 느린 단계가 됐습니다.
  • 오픈소스 스캔에서는 530개 high/critical 보고 중 75개만 패치됐고, 평균 패치 기간은 약 2주로 제시됐습니다.
• 개발자 영향: AI 보안 도구 도입은 스캐너 추가가 아니라 triage queue와 릴리스 운영 재설계 문제입니다.
• 주의점: Anthropic의 수치는 1차 발표 기준이며, 세부 취약점은 90일 공개 관행 때문에 아직 제한적으로만 공개됩니다.

Anthropic이 2026년 5월 22일 Project Glasswing의 첫 공개 업데이트를 냈습니다. 숫자는 큽니다. Anthropic과 약 50개 파트너가 Claude Mythos Preview를 사용해 한 달 동안 1만 개가 넘는 high 또는 critical severity 취약점을 찾았다고 밝혔습니다. Cloudflare는 critical-path system에서 2,000개 버그를 찾았고, 그중 400개를 high 또는 critical로 분류했다고 인용됐습니다. Mozilla는 앞서 Firefox 150에 Mythos Preview로 식별한 271개 취약점 수정을 포함했다고 공개했습니다.

하지만 이 글의 핵심은 "AI가 해킹을 잘한다"가 아닙니다. 더 중요한 변화는 병목의 이동입니다. 지금까지 보안은 대체로 취약점을 찾는 사람, 도구, 시간의 부족에 묶여 있었습니다. Mythos-class 모델이 그 비용을 크게 낮추면 다음 병목은 발견 이후로 이동합니다. 발견된 항목이 실제 취약점인지 재현하고, 심각도를 다시 매기고, 유지보수자에게 보고하고, 패치를 설계하고, 사용자에게 충분히 배포될 때까지 기다리는 일입니다. Anthropic도 같은 결론을 냈습니다. 소프트웨어 보안의 제약은 "얼마나 빨리 찾느냐"에서 "AI가 찾아낸 대량의 취약점을 얼마나 빨리 검증, 공개, 패치하느냐"로 옮겨갔다는 것입니다.

Glasswing은 무엇을 바꿨나

Project Glasswing은 2026년 4월 7일 발표된 제한 공개 방어 프로젝트입니다. Anthropic은 이 프로젝트를 "AI 시대의 핵심 소프트웨어를 보호하기 위한 이니셔티브"로 설명합니다. 초기 파트너에는 Amazon Web Services, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks가 포함됐습니다. 여기에 40개 이상의 추가 조직이 더해져, 5월 업데이트 기준으로는 약 50개 파트너가 참여하는 형태가 됐습니다.

여기서 중요한 점은 Mythos Preview가 일반 모델 릴리스가 아니라는 점입니다. Anthropic은 이 모델을 "coding and agentic tasks"에 가장 강한 frontier model이라고 설명하면서도, cybersecurity 능력 때문에 일반 공개하지 않았습니다. 공식 프로젝트 페이지에 따르면 Project Glasswing 참가자는 Claude API, Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry를 통해 접근할 수 있고, 가격은 입력 100만 토큰당 25달러, 출력 100만 토큰당 125달러로 제시됐습니다. 동시에 Anthropic은 이 연구 preview에 1억 달러 규모 사용 크레딧을 약속했습니다.

이 구조는 모델 출시와 다릅니다. 보통 새 모델은 성능표와 API 공개가 중심입니다. Glasswing은 반대로 강한 능력을 먼저 방어자에게 제한적으로 나눠주고, 발견된 취약점이 공격자에게 바로 노출되지 않도록 공개를 늦춥니다. Anthropic은 coordinated vulnerability disclosure 관행을 언급하며, 취약점은 보통 발견 90일 뒤, 또는 패치가 먼저 만들어졌다면 패치 제공 약 45일 뒤 공개된다고 설명했습니다. 그래서 이번 업데이트는 개별 취약점 세부정보보다 aggregate statistic과 일부 사례 중심으로 구성됐습니다.

발견 속도보다 패치 큐가 먼저 보입니다

가장 흥미로운 부분은 오픈소스 스캔 결과입니다. Anthropic은 지난 몇 달 동안 Mythos Preview로 1,000개 이상의 오픈소스 프로젝트를 스캔했다고 밝혔습니다. 이 프로젝트들은 인터넷과 Anthropic 자체 인프라의 밑바탕을 이루는 코드라고 설명했습니다. 그 결과 모델은 총 23,019개 취약점을 추정했고, 이 중 6,202개를 high 또는 critical severity로 봤습니다.

물론 모델이 취약점이라고 말한 것이 모두 실제 취약점은 아닙니다. 그래서 Anthropic은 1,752개 high/critical 추정 항목을 독립 보안 리서치 회사 여섯 곳 또는 Anthropic 내부 검토로 평가했습니다. 결과는 꽤 강합니다. 90.6%인 1,587개가 valid true positive였고, 62.4%인 1,094개가 high 또는 critical로 확인됐습니다. Anthropic은 현재 post-triage true-positive rate를 적용하면 Mythos Preview가 오픈소스 코드에서 거의 3,900개 high/critical 취약점을 표면화할 전망이라고 설명했습니다.

하지만 바로 다음 숫자가 더 중요합니다. Anthropic은 지금까지 high/critical 취약점 530개를 유지보수자에게 보고했고, 추가 827개 확인 취약점을 가능한 빨리 공개하려 한다고 밝혔습니다. 보고된 530개 중 패치된 것은 75개이고, 이 중 65개에는 public advisory가 붙었습니다. 이 숫자를 "낮다"고만 볼 수는 없습니다. 취약점 공개에는 이용자 업데이트 시간을 보장하는 90일/45일 관행이 있고, 일부 패치는 advisory 없이 들어갈 수도 있습니다. 그래도 큰 구조는 선명합니다. AI가 찾는 속도는 이미 유지보수 생태계가 처리하는 속도를 앞지르고 있습니다.

Anthropic은 high 또는 critical severity 버그 하나가 평균적으로 약 2주 걸려 패치된다고 썼습니다. 이것은 빠른 편이기도 하지만, 발견량이 수천 개 단위가 되면 전혀 충분하지 않습니다. 특히 오픈소스 프로젝트에서는 유지보수자가 보안팀을 따로 둔 기업이 아니라 본업 사이에 프로젝트를 돌보는 개인 또는 작은 팀인 경우가 많습니다. 이미 AI 생성 저품질 bug report가 쏟아지는 상황에서, 실제 취약점까지 대량으로 들어오면 triage는 더 어려워집니다.

Firefox 150의 271개 버그가 보여준 것

Mozilla 사례는 Glasswing 논의가 추상적 공포가 아니라 실제 릴리스 운영의 문제임을 보여줍니다. Mozilla의 Bobby Holley는 2026년 4월 21일 "The zero-days are numbered"라는 글에서 Firefox 팀이 2월부터 frontier AI 모델로 잠재 보안 취약점을 찾고 고치는 작업을 해왔다고 설명했습니다. Opus 4.6과의 협업으로 Firefox 148에서 22개 security-sensitive bug를 고쳤고, 이후 Mythos Preview 초기 버전을 Firefox에 적용해 Firefox 150에 271개 취약점 수정이 포함됐다고 밝혔습니다.

이 사례가 중요한 이유는 두 가지입니다. 첫째, AI 취약점 발견이 단순 데모가 아니라 릴리스에 들어간 패치로 이어졌습니다. 둘째, Mozilla처럼 보안에 진지한 팀도 처음 발견량을 봤을 때 "따라갈 수 있는가"라는 문제를 마주했습니다. Holley는 방어자가 마침내 이길 수 있는 기회를 얻었다고 낙관적으로 표현했지만, 그 낙관은 자동으로 주어지는 승리가 아니라 "다른 우선순위를 내려놓고 집요하게 처리해야 하는" 운영 작업 위에 있습니다.

커뮤니티 반응도 이 지점에 집중됐습니다. Reddit r/cybersecurity 토론에서는 "271개가 실제로 패치에 포함됐다는 점은 의미 있다"는 반응과 함께, 모델 주장의 과장 가능성을 경계하는 목소리도 있었습니다. 특히 한 긴 댓글은 보안의 병목이 취약점 지식 자체보다 고칠 시간, 레거시 시스템 교체 여력, 조직의 보안 인센티브, 피싱 같은 사람 중심 공격에 있다고 지적했습니다. 이 반응은 Glasswing을 이해하는 데 유용합니다. Mythos가 취약점을 더 잘 찾는다고 해서 보안 부채가 자동으로 사라지지는 않습니다. 오히려 숨겨져 있던 부채가 더 빠르게 재무제표 위로 올라옵니다.

공개 정책도 압박을 받습니다

취약점 공개에는 오래된 균형이 있습니다. 방어자와 유지보수자는 패치를 만들 시간이 필요하고, 사용자는 업데이트할 시간이 필요합니다. 공격자는 공개된 세부정보를 역이용할 수 있습니다. 그래서 coordinated vulnerability disclosure는 시간을 둡니다. Anthropic이 이번 글에서 개별 세부정보를 제한한 것도 이 때문입니다.

문제는 Mythos-class 모델이 이 균형을 압박한다는 점입니다. 과거에는 취약점 발견이 어렵고 비쌌기 때문에, 공개 지연이 방어자에게 시간을 벌어주는 효과가 컸습니다. 그러나 비슷한 모델이 더 넓게 퍼져 공격자도 저렴하게 취약점을 찾을 수 있다면, "아직 공개하지 않았다"는 사실만으로는 충분하지 않습니다. 공개 전에도 같은 취약점을 다른 모델이 독립적으로 찾을 수 있기 때문입니다.

Anthropic은 이 대목에서 꽤 직설적입니다. Mythos Preview와 비슷한 cybersecurity skill을 가진 모델이 곧 여러 AI 회사에서 개발될 것이며, 현재 어떤 회사도 이런 모델의 오용을 막을 만큼 강한 safeguard를 갖추지 못했다고 씁니다. 그래서 Mythos-class 모델을 아직 공개하지 않았고, 동시에 Project Glasswing으로 핵심 방어자에게 먼저 비대칭 이점을 주려 한다는 논리입니다.

이 논리는 설득력과 위험을 동시에 갖습니다. 방어자가 먼저 준비해야 한다는 주장은 타당합니다. 하지만 강한 모델 접근권이 대기업, 클라우드, 보안 벤더, 정부 중심으로 배분되면 작은 오픈소스 프로젝트와 중소기업은 더 늦게 보호받을 수 있습니다. Linux Foundation CEO Jim Zemlin의 프로젝트 페이지 인용도 바로 이 문제를 겨냥합니다. 오픈소스 유지보수자는 세계 핵심 인프라를 떠받치지만, 대형 보안팀을 둘 여력이 없었습니다. Glasswing이 정말 방어자 우선 전략이라면, 다음 관건은 모델 접근권보다도 검증·패치 인력과 유지보수자 지원을 어디까지 넓히느냐입니다.

개발팀에게는 스캐너가 아니라 운영체계 문제입니다

개발팀 입장에서 이번 뉴스는 "Claude Security를 켜야 하나"보다 넓은 질문을 던집니다. AI 보안 도구는 더 많은 결과를 가져옵니다. 더 많은 결과는 더 많은 의사결정을 요구합니다. 이 흐름을 받으려면 보안 리포트를 처리하는 내부 큐, severity 재분류 기준, false positive 처리, 소유자 지정, 릴리스 차단 기준, 고객 공지 기준이 먼저 있어야 합니다.

예를 들어 AI가 코드베이스에서 high severity 후보 300개를 찾았다고 해봅시다. 팀은 이것을 전부 바로 고칠 수 없습니다. 어떤 항목이 인터넷에 노출된 경로에 있는지, exploit 가능성이 있는지, feature flag 뒤에 있는지, 내부망 전제인지, 사용 중인 버전인지, 이미 다른 mitigation이 있는지 판단해야 합니다. 이 판단이 없으면 AI 스캐너는 생산성 도구가 아니라 알림 폭탄이 됩니다.

또 하나는 패치 배포입니다. 취약점을 고쳤다는 pull request가 merge됐다고 끝이 아닙니다. 라이브러리라면 release, advisory, downstream update가 필요합니다. 제품이라면 staged rollout, rollback plan, 고객 업데이트, 로그 모니터링이 필요합니다. 에이전트 시대의 보안은 "코드를 고치는 모델"보다 "고친 코드가 실제 위험을 줄였는지 확인하는 운영 루프"가 더 중요해집니다.

공개 모델과 제한 모델 사이의 회색지대

Anthropic은 방어 도구를 일반 모델에도 일부 내리고 있습니다. 글에 따르면 Claude Security public beta가 Claude Enterprise 고객에게 제공되고 있고, 3주 동안 Claude Opus 4.7이 2,100개 이상의 취약점을 패치하는 데 쓰였습니다. 또 Cyber Verification Program을 시작해 합법적인 취약점 연구, 침투 테스트, red-team 작업을 하는 보안 전문가에게 일부 cyber safeguard 제한을 덜 적용하는 길을 열었습니다. Mythos Preview에서 쓰던 skills, codebase mapping harness, scanning subagents, threat model builder도 자격 있는 고객 보안팀에 요청 기반으로 제공한다고 밝혔습니다.

이것은 AI 보안 제품의 방향을 보여줍니다. 모델 하나가 아니라 작업 하네스가 상품이 됩니다. 코드베이스를 지도처럼 만들고, 위협 모델을 만들고, 여러 subagent가 후보를 찾고, 보고서와 패치 초안을 만들고, 사람이 triage합니다. 코딩 에이전트가 IDE 안의 자동완성에서 repo-level 작업자로 바뀐 것처럼, 보안 에이전트도 SAST 결과 요약기를 넘어 disclosure workflow 안으로 들어가고 있습니다.

하지만 회색지대도 커집니다. 어떤 요청은 방어 연구이고 어떤 요청은 공격 준비일까요. 같은 exploit reproduction 능력은 양쪽 모두에 쓰입니다. Anthropic은 safeguard가 충분하지 않다고 인정했지만, 동시에 제한 접근 모델과 verified researcher program을 운영합니다. 이는 단기적으로는 현실적인 절충입니다. 장기적으로는 보안 연구자의 접근권, 감사 가능성, 국가별 규제, 클라우드별 모델 제공 방식이 더 큰 쟁점이 될 가능성이 큽니다.

이번 발표의 진짜 신호

Glasswing 업데이트는 AI 보안의 기준선을 올렸습니다. 이제 "AI가 취약점을 찾을 수 있는가"는 좋은 질문이 아닙니다. 적어도 일부 frontier model은 이미 찾고, 재현하고, 패치 후보를 만드는 단계에 들어섰습니다. 좋은 질문은 그 다음입니다. 누가 결과를 검증합니까. 누가 유지보수자에게 보고합니까. 누가 패치를 배포합니까. 누가 advisory를 씁니까. 누가 사용자 업데이트율을 확인합니까.

개발 조직이 여기서 배울 점은 차분합니다. 첫째, 코드 소유권과 보안 소유권을 명확히 해야 합니다. AI가 finding을 늘리면 애매한 ownership은 곧 방치된 critical queue가 됩니다. 둘째, 취약점 대응 SLA를 모델 능력에 맞춰 다시 봐야 합니다. AI가 발견한 high severity 후보가 많아지는 상황에서 모든 것을 같은 방식으로 처리할 수는 없습니다. 셋째, 오픈소스 의존성에 대한 태도가 바뀌어야 합니다. public code는 방어자뿐 아니라 공격자 모델도 읽을 수 있습니다. SBOM, dependency freshness, patched version rollout은 더 이상 컴플라이언스 체크박스가 아니라 agentic exploit 시대의 기본 운영 지표가 됩니다.

Anthropic이 제시한 숫자는 1차 소스 기준이며, 세부 취약점 대부분은 아직 공개되지 않았습니다. 따라서 이번 발표를 모든 회사가 당장 같은 성능을 재현할 수 있다는 뜻으로 읽으면 곤란합니다. 그러나 방향은 분명합니다. 취약점 발견의 희소성이 낮아질수록 보안의 가치는 더 아래쪽 운영 레이어로 이동합니다. AI가 제로데이를 더 빨리 찾는 시대에, 승부는 모델 성능표가 아니라 패치 큐의 처리량에서 갈릴 가능성이 큽니다.