Mythos 공포 이전에, 우리는 Opus는 쓰고 있는가?
닫힌 모델에 대한 공포보다, 열린 모델의 미사용이 더 큰 보안 부채다.
들어가며
지난 4월 7일, Anthropic은 Claude Mythos Preview를 공개했다. 정확히 말하면 공개하지 않겠다고 공개했다. 244페이지짜리 System Card는 발표했지만, 일반 가용은 하지 않는다. 대신 Project Glasswing이라는 이름으로 12개 launch partners — Apple, AWS, Google, Microsoft, JPMorgan Chase, Cisco, CrowdStrike, NVIDIA, Palo Alto Networks, Broadcom, Linux Foundation, 그리고 Anthropic 자신 — 에게 우선 제공한다. 여기에 critical software infrastructure를 빌드하거나 메인테인하는 40여 개의 추가 조직에도 접근이 확장됐다. 합쳐도 약 50개 수준이다. 1억 달러 규모의 사용 크레딧, 4백만 달러의 오픈소스 보안 단체 기부(Alpha-Omega/OpenSSF $2.5M, Apache Software Foundation $1.5M)가 묶여 있다. 참여자는 Claude API, AWS Bedrock, Google Vertex AI, Microsoft Foundry를 통해 접근한다.
발표 이후 며칠간 보안 업계 타임라인은 한 단어로 정리된다. 공포.
- 17년 묵은 FreeBSD NFS 원격 코드 실행 취약점(CVE-2026-4747)을 사람 개입 없이 발견·익스플로잇
- 27년 묵은 OpenBSD 버그, 16년 묵은 FFmpeg 버그
- 모든 주요 OS와 모든 주요 브라우저에서 수천 건의 제로데이
- Firefox 147 벤치마크에서 Opus 4.6은 익스플로잇 2개, Mythos는 181개 — 90배 차이
- 발표 시점에 99% 이상이 미패치 상태
영국 영란은행, FCA, 재무부가 NCSC와 비상 협의에 들어갔고, 미국 NSA에도 접근권이 부여됐다. UK AISI는 “처음으로 풀 네트워크 장악 시뮬레이션을 통과한 모델”이라 평가했다.
이 정도면 공포가 정당하다. 그런데도 나는 지금 우리에게 더 시급한 질문은 다른 곳에 있다고 본다.
Mythos는 글로벌 엔터프라이즈 거의 전부가 만질 수 없는 모델이다. 접근 권한은 약 50개 조직에 한정돼 있고, 그마저도 critical software 빌더/메인테이너에 집중돼 있다. 그렇다면 그 바깥에 있는 우리 조직이 지금 손에 쥐고 있는 Opus 4.6, Sonnet 4.6, Claude Code는 보안 개선에 얼마나 쓰이고 있는가?
이 질문에 자신 있게 답할 수 있는 조직이 얼마나 될까. 내 경험상, 거의 없다.
그래서 이 글의 주장은 단순하다.
공포 마케팅에 마비되기 전에, 이미 우리 손에 들어와 있는 도구부터 제대로 쓰자.
1. 공포 마케팅의 비대칭성
이번 사이클에서 우리가 놓치고 있는 비대칭이 있다.
- 닫힌 모델(Mythos)에 대한 공포는 모든 매체에서 회자된다.
- 열린 모델(Opus/Sonnet)의 미사용은 어디에서도 회자되지 않는다.
전자는 자극적이라 클릭이 잘 된다. 후자는 자기 조직의 게으름과 정치를 들춰야 하니 모두가 불편하다. 그래서 담론이 한쪽으로만 쏠린다.
그런데 보안 부채(security debt) 관점에서 보면 후자가 훨씬 더 가까운 위험이다. Mythos가 풀려서 위협이 일반화되는 시점이 왔을 때, 갑자기 잘 쓰는 조직은 없다. AI 보조 보안 워크플로우를 지금 굴려보지 않은 조직은 그때도 못 굴린다. 도구가 더 강해질수록 격차는 더 벌어진다.
심지어 Anthropic도 이 점을 명시했다. “Mythos급 모델을 안전하게 대규모 배포할 수 있도록 다음 Opus 모델에서 가드레일을 다듬을 계획”이라고 못 박았다. 즉 우리가 익숙해질 다음 모델은 Opus 계열이다. 지금 Opus를 못 쓰면 그때도 못 쓴다.
2. 지금 당장 Opus / Sonnet으로 할 수 있는 보안 작업들
추상론은 그만하고, 구체적으로 들어가자. 아래는 모두 별도의 보안 전문 모델 없이, 일반 Opus 4.6 / Sonnet 4.6 API와 Claude Code만으로 오늘 시작 가능한 항목들이다.
2.1 코드 변경 시점의 보안 보조 리뷰
- GitHub Actions / GitLab CI 단계에서 PR diff에 LLM 보안 리뷰 레이어를 박는다.
- Semgrep, CodeQL 같은 룰셋 기반 SAST가 잘 못 잡는 logic-level 결함 — 인가 경계 우회, IDOR 패턴, 신뢰 경계 입력 검증 누락, 시크릿 하드코딩 — 이 LLM이 강한 영역이다.
- 룰: PR 전체가 아닌 변경된 부분만 리뷰한다. 비용·노이즈 모두 줄어든다.
- 출력 포맷을 강제한다.
severity / file / line / 설명 / 권장 조치JSON. 자유 텍스트로 받으면 운영이 안 된다.
2.2 IaC 변경의 폭발 반경(Blast Radius) 평가
- Terraform plan / AWS CDK synth 출력에 LLM 분석 레이어를 더한다.
- 이 변경이 IAM 폭발 반경, 네트워크 노출, 데이터 경로, 비용에 미치는 영향을 자연어 요약.
- Checkov / tfsec / cfn-nag 결과의 우선순위화. 단순한 룰 위반 50개 중 진짜 위험한 3개를 골라주는 게 LLM의 강점이다.
- 부록: PR 코멘트로 자동 게시. 리뷰어가 보지 않으면 무용지물이다.
2.3 위협 모델링 가속
- 신규 서비스 ADR(Architecture Decision Record) 또는 PRD에서 STRIDE 초안 자동 생성.
- Mermaid 시퀀스 다이어그램을 입력으로 받아 신뢰 경계, 자산, 위협, 통제를 매핑.
- 완성품을 기대하지 말고 초안을 기대한다. 보안 아키텍트의 빈 종이 공포를 줄이는 것만으로 효과가 크다.
2.4 로그/이벤트 트리아지
- CloudTrail, GuardDuty, Security Hub, AgentCore Observability 알람을 자연어 요약 + 1차 분류.
- 정상 패턴 vs 이상 패턴 분리.
- SOAR 플레이북 실행 결정의 보조. 단, 자동 실행은 위험도 낮은 액션에만.
- 프롬프트 인젝션에 주의한다. 로그 본문에 공격자 페이로드가 섞여 들어올 수 있고, 이게 그대로 LLM 컨텍스트에 들어가면 새 공격면이 된다. 입력 마스킹·태깅을 먼저 정립한다.
2.5 컴플라이언스 가속 — 적정기술 기반의 컴플라이언스
- 사내 정책 문서, 통제 항목(ISMS-P, PIPA, GDPR, SOC 2 등)을 RAG로 묶어 챗봇화.
- 변경 사항(Jira 티켓, PR 설명) → 통제 항목 영향 분석 자동화.
- 증적(evidence) 수집 자동화: CloudTrail에서 특정 통제 충족 증거를 자동 추출.
- 컴플라이언스 팀이 문서를 검색하지 않고 문서에 질문하게 만든다. 이것만으로도 통제 운영 비용이 절반 난다.
2.6 컨테이너 / 공급망 보안
- SBOM(CycloneDX, SPDX) → 자연어 위험 요약, EOL 컴포넌트 탐지.
- Distroless / Chainguard 마이그레이션 영향 분석. 어떤 패키지가 빠지고 어떤 운영 절차가 영향받는지.
- 라이선스 호환성 매트릭스(GPL/AGPL/MIT/Apache/MPL) 검토 보조.
- ECR pull-through cache 정책 검토.
2.7 AI/Agent 자체의 보안
이건 우리 같은 사람들이 가장 게을리하기 쉬운 영역이다. 우리가 만든 AI 에이전트(MCP 도구 호출, AgentCore Memory 등)에 대해 LLM이 자기 자신을 점검하게 하는 것.
- 사내 MCP 서버가 과도한 도구 권한을 노출하지 않는지 정기 점검.
- AgentCore Memory의 메모리 포이즈닝 패턴 검색.
- 프롬프트에 시크릿이 들어가는 경로(에이전트 컨텍스트, 시스템 프롬프트) 감사.
- “Prompt Injection은 SQL Injection의 환생”이라는 관점을 내재화한다. 입력 신뢰 경계와 출력 검증을 그대로 적용한다.
2.8 Claude Code로 보안 자동화 스크립트
API 호출보다 한 단계 더 손에 가까운 영역이다.
- 멀티클라우드 IMDS 노출/hop limit 감사 스크립트
- IAM 사용 빈도 분석 → 미사용 권한 회수 제안
- KMS 키 사용 매핑 → 미사용 키 식별
- Terraform state 노출 검사
- EKS 워크로드의 IRSA / Pod Identity 일관성 점검
이 모든 게 며칠 단위 작업으로 가능하다. 그런데 안 한다.
3. 그런데 왜 안 쓰는가 — 진짜 장벽
기술 부족이 문제였다면 진작에 풀렸을 것이다. 진짜 장벽은 다른 곳에 있다.
(1) 데이터 거버넌스 미정립
사내 코드, 로그, 인프라 구성을 외부 LLM에 보낼 수 있는가에 대한 의사결정이 미뤄진다. ZDR(Zero Data Retention) 옵션, AWS Bedrock/Vertex 같은 클라우드 내 호스팅, 자체 호스팅 LLM의 트레이드오프가 정리돼 있어야 한다. 이 결정을 보안팀이 단독으로 내려주길 기대해선 안 된다. 법무·개인정보보호·인프라가 같이 앉아야 한다.
(2) 비용 통제 모델 부재
LLM 호출이 운영 비용으로 들어오면 갑자기 예측 불가능한 OpEx가 된다. 토큰 단가, 호출 빈도, 캐싱, 모델 라우팅(쉬운 건 Sonnet, 어려운 건 Opus) 같은 운영 패턴이 잡혀 있어야 도입이 굴러간다.
(3) 결과 검증 체계 부재
LLM이 잘못된 권고를 했을 때 누가 책임지는가. human-in-the-loop 지점이 명확해야 도입이 가능하다. “LLM이 통과시켰으니 통과”는 컴플라이언스로도 안 된다.
(4) 리더십의 짧은 ROI 인내심
첫 달에 화려한 KPI를 요구하는 리더십은 LLM 보안 도입을 죽인다. 측정 가능한 리딩 지표(MTTD 단축, 리뷰 순환 시간, 오탐률) 부터 정의해야 한다.
(5) “보안팀 도구”라는 좁은 시각
이게 가장 크다. AI 보조 보안 도구는 DevOps 손에 들어가야 한다. 보안 엔지니어 5명이 쓰는 것보다, DevOps 500명이 매일 PR을 올릴 때 한 번씩 거치는 게 훨씬 더 큰 변화를 만든다. 보안팀이 도구를 독점하려는 순간 그 도구는 죽는다.
4. 작게, 그러나 매일
큰 그림은 사람을 마비시킨다. 작은 실행이 근육을 만든다.
- POC는 하나의 워크로드, 하나의 파이프라인에서 시작한다. 전사 적용은 그다음이다.
- 측정 가능한 지표를 먼저 정한다. MTTD, FP율, 리뷰 시간, 알람 노이즈 감소율.
- 가드레일이 먼저다. 입력 마스킹(시크릿/PII), 출력 스키마 강제, 호출 한도, 로깅·감사.
- 결과를 공개한다. 잘된 것도, 망한 것도. 사내에 공유 안 하면 다른 팀이 같은 시행착오를 반복한다.
- 분기마다 한 항목씩 늘린다. 욕심부리지 않는다.
이게 적정기술 기반의 컴플라이언스다. 거대한 플랫폼을 사들이고 1년 후에 평가받는 게 아니라, 이번 주에 한 파이프라인이 더 안전해졌는지를 본다.
5. Mythos가 풀리는 날
Mythos가 어떤 형태로든 일반 가용으로 풀리는 날은 온다. Anthropic이 명시했다. 다음 Opus에서 가드레일을 다듬어 “Mythos급 모델을 안전하게 대규모 배포”하는 게 목표라고. 경쟁사도 이미 비슷한 노선이다. OpenAI는 발표 일주일 만에 자사 보안 특화 모델의 제한적 롤아웃을 공지했다.
그날이 왔을 때 두 종류의 조직이 있을 것이다.
- A형: Opus와 Sonnet으로 이미 보안 워크플로우를 굴려본 조직. 새 모델로 바로 갈아끼우면 된다. 가드레일, 데이터 거버넌스, 비용 모델, 검증 체계가 이미 있다.
- B형: Mythos 발표를 보고 공포 회의만 했던 조직. 도구가 더 강해진 그날, 갑자기 도입에 들어가지만 인프라도 거버넌스도 없다. 시간은 더 짧아졌고 적은 더 빠르다.
A와 B의 격차는 모델 성능 격차가 아니라 근육의 격차다. 그리고 근육은 오늘부터 만들 수 있다.
마치며
Security that can’t be executed isn’t security.
내가 늘 하는 말이다. 그리고 이번처럼 와닿는 시기가 없다.
Mythos는 기사 헤드라인에 사는 모델이다. Opus와 Sonnet은 우리 콘솔에 사는 모델이다. 둘 중 어느 쪽이 오늘의 보안 자세를 결정하는지는 자명하다.
Mythos에 대한 공포는 이해한다. 그 공포가 지금 할 수 있는 일을 가리지만 않으면 된다. 우리가 두려워해야 하는 건 강한 모델이 아니라, 손에 쥔 도구를 못 쓰는 조직 문화다.
공포는 머리에서 일어나지만, 보안은 손에서 만들어진다.
Mythos가 어떤 모습으로 오든, 그 전에 해야 할 일은 이미 우리 앞에 와 있다.
손이 닿는 것부터 시작하자.
