공격하는 AI, 방어하는 AI — Project Glasswing과 Trivy 공급망 사건이 같은 주에 터진 이유

“같은 주에 Anthropic은 ‘사람 이상의 정확도로 취약점을 찾는 AI’를 발표했고, 개발자들이 방어용으로 설치해두던 Trivy는 클라우드 시크릿을 털렸다. 이 두 사건은 정말 우연일까?”

2026년 4월 7일, Anthropic은 Project Glasswing이라는 이름의 사이버 보안 이니셔티브와 그 핵심 엔진이 될 신규 모델 “Claude Mythos Preview”를 동시에 공개했다. 공식 문구는 거창했다. “세계에서 가장 중요한 소프트웨어를 보호하기 위한 긴급한 노력”, “가장 숙련된 인간 이외에는 찾을 수 없는 수준의 소프트웨어 취약점을 탐지한다”. 하루 뒤인 4월 8일, 전혀 다른 성격의 분석 보고서 한 편이 Hacker News 프런트페이지에 올라왔다. 제목은 How the Trivy supply chain attack harvested credentials from secrets managers — 개발자들이 컨테이너 이미지와 IaC(Infrastructure as Code) 스캐닝을 위해 신뢰하고 사용해온 CNCF 정적 분석 도구 Trivy가 공급망 공격의 통로가 되었고, 손상된 버전이 실행 환경의 AWS Secrets Manager와 HashiCorp Vault를 폴링해 자격 증명을 유출했다는 내용이었다.

두 사건은 동일한 뉴스 사이클 안에서 벌어졌지만, 외견상 연결점이 없어 보인다. 한쪽은 “AI가 보안을 혁신할 것”이라는 마케팅이고, 다른 한쪽은 “보안 도구 자체가 침투되었다”는 실전 보고다. 하지만 이 두 사건을 나란히 놓고 보면 그림이 달라진다. 이 글의 thesis는 간단하다. Glasswing과 Trivy 공급망 사건은 우연히 같은 주에 터진 것이 아니라, 같은 구조적 힘이 만들어낸 쌍둥이 사건이다. AI 코딩과 AI 에이전트의 확산이 공격 면적(attack surface)을 기하급수적으로 넓히고 있고, 동시에 공격자가 사용할 수 있는 자동화 능력도 같은 곡선 위에서 올라가고 있다. Anthropic의 Glasswing은 “방어자가 이 비대칭을 어떻게 따라잡을 것인가”에 대한 한 가지 답이고, Trivy 사건은 “비대칭이 현실에서 어떻게 폭발하는가”에 대한 한 가지 증거다. 한쪽은 “방어가 늦었다”는 자각의 표현이고, 다른 한쪽은 “실제로 얼마나 늦었는지”를 보여주는 거울이다.

1. Project Glasswing은 무엇인가 — Anthropic의 방어 카드

Anthropic이 공개한 정보를 정리해보자. TechCrunch의 4월 7일 보도에 따르면, Project Glasswing은 “소수의 유력 기업들이 방어적 사이버 보안 작업에 활용할” 목적의 프리뷰 프로그램이고, 그 중심에 있는 것이 Claude Mythos Preview라는 새 모델이다. Anthropic은 이 모델을 일반 사용자에게 공개할 계획이 없다고 못박았다. 이유는 단순하다. “안전한 규모 배포가 목표이지만, 먼저 위험한 출력을 안정적으로 차단하는 세이프가드가 필요하다”는 것이다.

GIGAZINE의 4월 8일 해설은 모델의 성능 주장을 좀 더 구체적으로 정리했다. Claude Mythos Preview는 내부 평가에서 Firefox의 기능적 익스플로잇을 생성하는 작업에서 72.4%의 성공률을 기록했다고 한다. 이전 세대 Claude 모델들은 이 작업에서 거의 실패했다. 그리고 “수천 건의 실세계 취약점을 자율적으로 발견했다”는 주장도 따라붙었다. 구체적 사례로 언급된 것이 세 가지다. OpenBSD 커널에서 27년간 누구도 발견하지 못한 크래시 취약점, FFmpeg에서 500만 건 이상의 자동화 스캔이 놓친 16년 묵은 결함, 그리고 Linux 커널에서 여러 개의 취약점을 결합해 완전한 권한 상승 체인을 만드는 시나리오. 이 세 예시의 공통점은 “단일 파일의 표면적 결함”이 아니라는 점이다. 27년이 걸린 이유, 5백만 건의 스캔이 놓친 이유, 그리고 조합이 필요한 이유는 모두 “multi-file reasoning”이라는 한 가지 키워드로 수렴한다. 사람의 작업 기억 용량을 넘어서는 종류의 취약점이다.

수사를 걷어내고 보면 Glasswing의 포지셔닝은 이렇게 요약할 수 있다. “사람이 찾을 수 없는 취약점을 사람 대신 찾아주는 AI를, 우리가 선별한 소수의 파트너에게만 먼저 준다.” 파트너가 누구인지 Anthropic은 명시하지 않았지만, TechCrunch는 “유력 기업들”이라는 표현을 썼고, 업계 관측은 Microsoft와 Apple 같은 대형 플랫폼 사업자, 그리고 주요 인프라 벤더들을 지목하고 있다. 이 선별은 의도적이다. 모델의 능력이 곧바로 공격력으로 전환될 수 있기 때문이다. Anthropic 자신이 이 점을 공식 문서에서 인정하고 있다. GIGAZINE은 Anthropic의 설명을 이렇게 인용한다. “AI의 개발 속도는, 오남용 위험이 높은 모델이 결국에는 광범위하게 이용 가능해진다는 것을 의미한다.” 즉, 방어자에게 먼저 우위를 주지 않으면, 공격자가 먼저 도착할 것이라는 진단이다.

이것이 왜 중요한가. Anthropic이 스스로의 모델을 “위험해서 일반 공개할 수 없다”고 분류했기 때문이다. 이전 세대 모델들에 대해서는 “잠재적 위험”이라는 표현을 썼지만, Mythos에 대해서는 “먼저 세이프가드가 필요하다”는 실질적 제한을 걸었다. 이 차이는 마케팅 문구의 차이가 아니라 분류의 차이다. 사이버 보안이라는 영역이 생성형 AI의 능력 스케일에서 새로운 티어에 진입했다는 내부적 판단이 엿보인다.

2. Trivy 공급망 공격 — 분석 보고서의 핵심

Trivy를 모르는 독자를 위해 간단히 정리한다. Trivy는 CNCF 산하의 오픈소스 정적 분석 스캐너로, 컨테이너 이미지, 파일 시스템, Git 저장소, Kubernetes 매니페스트, Terraform과 CloudFormation 같은 IaC 파일에서 알려진 취약점과 설정 오류를 탐지한다. 현업에서는 CI 파이프라인의 기본 구성 요소에 가깝다. trivy image myapp:latest 한 줄이 수많은 회사의 배포 게이트에 박혀 있다. 개발자들에게 Trivy는 “보안을 내 편으로 만들어주는 도구”라는 심리적 위치를 차지하고 있다.

vaultproof.dev의 분석 보고서가 보여주는 그림은 바로 그 심리적 위치를 역이용한다. 손상된 Trivy 바이너리는 정상적인 스캔 기능을 수행하면서, 동시에 실행 환경에서 접근 가능한 시크릿 저장소를 조용히 폴링한다. CI 러너가 AWS 인증 정보로 가동되고 있다면, 그 자격 증명으로 Secrets Manager의 시크릿들을 열람한다. HashiCorp Vault 토큰이 환경 변수에 있다면, Vault의 KV 엔진을 긁는다. GitHub Actions 러너에서 실행되고 있다면 GITHUB_TOKEN을 빼낸다. 이 모든 동작이 “정적 분석 스캐너가 정상적으로 돌고 있는 것처럼” 이루어진다. 탐지 측면에서 특히 고약한 것은, Trivy가 원래 네트워크로 취약점 데이터베이스를 갱신하는 도구이기 때문에, 외부 통신 자체가 이상 징후로 잡히지 않는다는 점이다. 방화벽과 EDR 입장에서 “Trivy가 인터넷에 나간다”는 것은 당연한 동작이다.

분석 보고서의 핵심은 이 공격이 “단일 레포지토리 피싱”과 구조적으로 다르다는 점이다. 과거의 전형적인 오픈소스 공급망 공격은 npm이나 PyPI에 악성 패키지를 올리고 희생자가 설치하기를 기다리는 방식이었다. 희생자는 “잘 모르는 라이브러리”를 설치한다. 이번에는 반대다. 희생자는 “가장 신뢰해온 보안 도구”를 기존 CI 파이프라인에서 그대로 실행했다. 신뢰의 연쇄가 거꾸로 작용한 것이다. Trivy가 CNCF 프로젝트라는 사실, 수천 개의 프로덕션 파이프라인에서 기본으로 쓰인다는 사실, 공식 Docker Hub 이미지가 서명되어 있다는 사실 — 이 모든 신뢰의 신호가 공격자에게 배포 채널을 열어주는 역할을 했다.

피해 범위의 정확한 숫자는 보고서도 아직 확정하지 못했다. 하지만 시크릿 매니저에서 털린 자격 증명이 어떻게 쓰이는지는 구조적으로 예측 가능하다. 클라우드 관리 API 키 하나가 털리면, 거기서부터는 IAM 정책이 허용한 모든 리소스가 공격자의 손에 들어간다. S3 버킷, RDS 스냅샷, KMS 키, 그리고 다른 시크릿들까지. 오늘날의 프로덕션 환경에서 “하나의 시크릿”은 사실상 존재하지 않는다. 시크릿은 서로를 참조하고, 서로를 복호화하고, 서로에 접근 권한을 부여한다. 첫 번째 시크릿이 뚫리면 그 체인이 전체 환경의 지도 역할을 한다. Trivy 한 줄의 스캐너 명령어가, 이 지도의 첫 페이지를 여는 열쇠가 되었다.

3. 공격자 자동화와 방어자 자동화가 같은 곡선 위에 있다

여기서 첫 번째 결정적 관찰이 나온다. Glasswing이 해결하려는 문제와 Trivy 사건이 보여주는 문제는, 다른 영역의 문제가 아니다. 같은 곡선의 다른 점이다.

이 곡선의 이름을 “자동화 비대칭 곡선”이라고 부르자. X축은 시간, Y축은 “공격 측과 방어 측 각자가 동원할 수 있는 자동화 능력”이다. 2010년대의 보안 업계는 암묵적으로 “방어 측이 약간 앞서 있다”고 가정해왔다. 방어자는 기업의 자원과 전문 인력을 가지고 있었고, 공격자는 스크립트 키디이거나 국가 행위자였다. 중간층의 공격자는 자동화의 한계 때문에 대규모 공격을 수행하기 어려웠다. 이 가정이 무너지고 있다.

무너지는 이유는 두 가지다. 첫째, AI 코딩 도구의 확산이 소프트웨어 생산량을 폭증시켰다. GitHub Copilot, Cursor, Claude Code 같은 도구들이 등장한 이후, 실질적인 코드 생산량은 몇 배로 늘었다. 코드가 늘면 취약점도 늘고, 의존성이 늘고, 공급망의 그래프가 복잡해진다. 공격 면적은 생산량의 함수다. 둘째, 같은 AI 능력이 공격자에게도 주어졌다. Anthropic이 Mythos에 대해 “사람이 찾을 수 없는 취약점을 찾는다”고 주장할 수 있는 것은, 바로 그 동일한 능력이 공격자의 손에 들어갔을 때 무엇을 할 수 있는지도 함께 말하는 것이다. GIGAZINE이 Firefox 익스플로잇 생성 성공률 72.4%라는 숫자를 보도할 때, 그 숫자는 “방어자의 자동 패치 능력”이자 동시에 “공격자의 자동 익스플로잇 능력”이다.

Trivy 사건은 이 곡선의 “공격 측”이 이미 어디까지 올라왔는지 보여준다. 전통적 관점에서 공급망 공격은 노동 집약적이었다. 공격자는 패키지 저장소를 모니터링하고, 유사한 이름의 패키지를 등록하고, 오타 사용자를 기다려야 했다. 이번 공격은 그런 고전적 패턴과 다르다. 공격자는 “가장 널리 쓰이는 보안 도구”를 골라, 그 배포 채널에 침투하고, 실행 환경의 시크릿 체계를 구조적으로 폴링하는 모듈을 내장했다. 이것은 상당한 수준의 정찰과 엔지니어링을 요구한다. 그리고 공격자가 이 수준의 정밀도를 달성할 수 있었던 배경에, 자동화 능력의 상승이 있다는 것은 부인하기 어렵다.

Anthropic이 Glasswing을 “긴급한 노력”이라고 부른 것은 수사가 아니다. 방어자가 같은 곡선 위에서 뒤처지고 있다는 내부 판단의 공개 선언에 가깝다. 모델을 소수의 파트너에게만 제공하기로 한 결정은, “이 능력을 광범위하게 배포하는 것 자체가 비대칭을 더 악화시킬 수 있다”는 이중성의 인식에서 나온 것이다. 흥미로운 것은, Trivy 사건이 “광범위 배포가 항상 좋다”는 직관도 이미 훼손하고 있었다는 사실이다. 가장 널리 쓰이는 보안 도구가 가장 효과적인 공격 벡터가 되었다. 보안 도구의 보급과 보안의 개선은 같은 것이 아니다.

4. “가장 숙련된 인간 이외에는 찾을 수 없는 취약점” — 이 수사의 기술적 의미

Anthropic의 공식 Glasswing 트윗에 나온 “가장 숙련된 인간 이외에는 찾을 수 없는 수준의 소프트웨어 취약점”이라는 표현은, 마케팅 카피 같아 보이지만 기술적으로는 꽤 특정한 주장을 하고 있다. 이 표현이 가리키는 영역을 구체화해보자.

소프트웨어 취약점은 몇 개의 층위로 나눌 수 있다. 가장 얕은 층은 “패턴 매칭으로 잡히는 것”이다. SQL 인젝션의 고전적 문자열 결합, 버퍼 오버플로의 strcpy, 하드코딩된 자격 증명. 이 층은 이미 전통적 정적 분석 도구(Trivy, Semgrep, CodeQL)가 잘 다룬다. 다음 층은 “단일 파일 내의 로직 버그”다. 예를 들어 권한 체크를 빼먹은 API 엔드포인트, 정수 오버플로, race condition의 얕은 사례. 이 층은 LLM 기반 분석이 2024-2025년 사이에 상당히 잘 다루게 되었다. 하지만 그 위의 층이 있다. 여러 파일과 모듈에 걸친 상호작용에서만 발생하는 취약점, 깊은 의존성 체인에서 등장하는 타이밍 이슈, 컴포넌트 경계를 넘는 신뢰 가정의 위반. 이 층은 전통적으로 “숙련된 인간 리서처”의 영역이었다. 사람이 코드를 읽으면서 머릿속에 시스템의 흐름을 구성하고, 그 흐름의 가정에 의문을 품는 방식으로 찾는다.

OpenBSD의 27년 묵은 커널 크래시, FFmpeg의 16년 묵은 결함, 여러 취약점을 결합한 Linux 권한 상승 체인 — GIGAZINE이 정리한 세 사례는 정확히 이 “세 번째 층”에 해당한다. 27년이라는 시간은 “사람이 찾을 수 있는 영역이었지만 아무도 찾지 못했다”는 의미가 아니다. “사람의 작업 기억으로는 전체 구조를 한 번에 잡기 어려웠다”는 의미에 더 가깝다. FFmpeg의 5백만 건 자동 스캔이 놓쳤다는 것도, 전통적 퍼저와 심볼릭 실행 도구의 한계를 정확히 지적한다. 이 도구들은 “코드를 국소적으로 실행”하는 방식이기 때문에, “여러 컴포넌트의 가정이 서로 충돌하는 지점”을 스스로 구성하지 못한다.

LLM 기반 분석이 이 층에서 왜 유리할 수 있는지는 구조적으로 설명 가능하다. 트랜스포머의 attention 메커니즘은 “여러 지점 사이의 관계”를 한 번에 평가할 수 있다. 1M 토큰의 컨텍스트 창은 중대형 코드베이스 전체를 한 모델의 작업 기억에 올려놓는다. 여기에 “가정을 찾아내고 그 가정이 깨지는 시나리오를 구성하라”는 형태의 추론 목표를 결합하면, 원칙적으로는 사람이 수주일 걸려 수행하던 작업을 몇 시간 안에 자동화할 수 있다. 이것이 Anthropic의 주장이다.

다만 이 주장에는 독립 검증이 아직 없다. Mythos Preview가 일반 공개되지 않았기 때문에, 외부 연구자가 동일 벤치마크를 재현할 수 없다. 72.4%라는 Firefox 익스플로잇 성공률은 Anthropic의 내부 평가 숫자이고, 평가 세트의 구성과 난이도 분포는 공개되지 않았다. “27년 묵은 OpenBSD 버그”라는 사례도 — 해당 버그의 CVE 번호와 기술적 디테일을 Anthropic이 공개하지 않았다면 — 마케팅 서사와 구분하기 어렵다. 이 글의 전제는 “Anthropic의 주장을 그대로 믿자”도 아니고 “마케팅이니 무시하자”도 아니다. 주장의 구조와 한계를 같이 읽자는 것이다. 주장의 방향은 기술적으로 설득력이 있다. 주장의 정확한 수치는 독립 검증이 이루어지기 전까지는 참고값이다.

5. 공급망 공격의 새 단계 — 개발 도구 자체가 표적이 된다

Trivy 사건이 공급망 공격의 역사에서 특별한 위치를 차지하는 이유는, 표적이 “애플리케이션의 의존성”이 아니라 “보안 도구 자체”라는 점이다. 이 차이는 단순한 분류 이상의 구조적 의미를 가진다.

2017년 이후의 공급망 공격 계보를 거칠게 정리해보자. event-stream(2018), ua-parser-js(2021), node-ipc(2022), 3CX Desktop App(2023), XZ Utils backdoor(2024). 이 사건들의 공통점은 “정상적인 소프트웨어가 의존하는 라이브러리나 유틸리티”가 침해되었다는 것이다. 이 계보에서 방어의 관점은 “당신이 의존하는 것을 검증하라”였다. SBOM(Software Bill of Materials)을 생성하고, 의존성을 고정하고, 바이너리의 해시를 확인하고, 취약점 스캐너로 주기적으로 검사한다. 그 취약점 스캐너가 바로 Trivy였다.

Trivy 사건은 이 방어 모델의 순환 의존성을 드러낸다. 당신이 의존성을 검증하기 위해 사용하는 도구 자체를, 누가 검증하는가? 순진한 답은 “공식 저장소의 서명된 바이너리를 쓰면 된다”이다. 하지만 공급망 공격의 본질은 정확히 그 “공식 저장소의 서명”이 무너지는 순간에 발생한다. 더 근본적인 답은 “모든 도구에 대해 다층 검증을 한다”이다. 하지만 이 답은 현실의 개발 팀에게 실행 불가능하다. CI 파이프라인의 모든 단계에 대해 다층 검증을 적용하면, 개발 속도가 정지한다.

AI 에이전트 시대는 이 딜레마를 더 극단으로 밀어붙인다. 에이전트는 개발자보다 훨씬 많은 도구를 훨씬 자주 실행한다. Claude Code나 Cursor 같은 에이전트가 “이 프로젝트의 보안 이슈를 점검해줘”라는 지시에 응답할 때, 에이전트는 Trivy를 포함한 여러 스캐너를 자동으로 실행한다. 사람이라면 “잠깐, 이 도구를 실행하기 전에 바이너리 무결성을 확인해야 하나?”라고 멈출 수 있는 순간이, 에이전트의 워크플로우에서는 그냥 지나간다. 에이전트는 보안 도구를 “도구 상자의 한 항목”으로 취급하고, 상자에 손을 넣는 빈도가 사람보다 훨씬 높다. 이것은 개발 생산성의 측면에서 축복이지만, 공급망 공격의 측면에서는 공격자에게 새로운 실행 표면을 제공한다.

정리하면 이렇다. 과거의 공급망 공격은 “당신이 쓰는 라이브러리”를 겨냥했다. 현재의 공급망 공격은 “당신이 쓰는 보안 도구”를 겨냥한다. 그리고 가까운 미래의 공급망 공격은 “당신의 에이전트가 자동으로 실행하는 모든 도구”를 겨냥할 것이다. 각 세대의 표적 면적은 이전 세대의 몇 배로 커진다. 이것이 Trivy 사건이 독립된 사고가 아니라 새로운 단계의 시작이라고 읽어야 하는 이유다.

6. 방어자 딜레마 — Glasswing의 선택과 한계

Anthropic이 Mythos Preview를 오픈하지 않고 소수 파트너에게만 제공하기로 한 결정은, 표면적으로는 안전한 선택이다. “위험한 능력이 광범위하게 배포되기 전에 세이프가드를 먼저 준비한다”는 논리는 이해할 수 있다. 하지만 이 선택 자체가 새로운 딜레마를 만든다는 점도 봐야 한다.

첫째, 선택된 파트너의 편향 문제다. Glasswing이 Microsoft, Apple 같은 대형 플랫폼 사업자와 주요 인프라 벤더를 파트너로 선정한다면, 그들의 제품에 있는 취약점은 빠르게 수정될 것이다. 하지만 이 선택은 동시에 “글로벌 소프트웨어 생태계의 나머지”에게는 비대칭을 강화한다. 중소형 오픈소스 프로젝트, 지역 소프트웨어 벤더, 그리고 특히 긴 꼬리에 있는 비영어권 소프트웨어들은, 이 방어 능력에 접근할 수 없다. 공격자가 Mythos 급의 능력에 언젠가 접근하게 된다면 — Anthropic 자신이 “AI의 개발 속도는 오남용 위험이 높은 모델이 결국 광범위하게 이용 가능해진다는 것을 의미한다”고 인정한 바로 그 시나리오 — 이 비대칭은 정확히 긴 꼬리를 먼저 때릴 것이다.

둘째, 오픈 시큐리티 커뮤니티와의 가치 충돌이다. 취약점 연구의 역사는 “전체 공개(full disclosure)“의 윤리 논쟁으로 가득하다. 1990년대의 Bugtraq 시대에 확립된 관행 중 하나는, 취약점의 존재와 세부사항을 넓은 공동체에 공개해야 방어자들이 대응할 수 있다는 것이다. Glasswing 모델의 “선별된 파트너” 방식은 이 관행과 충돌한다. 취약점 발견 능력 자체가 몇몇 기업에 집중되면, 취약점이 “언제 어떻게 공개되는가”도 집중된 주체의 결정에 달린다. 이것이 꼭 악의라는 뜻은 아니지만, 구조적으로는 취약점 정보의 유통 경로가 좁아진다는 의미다.

셋째, “방어력은 그 자체로 공격력”이라는 이중성이다. Mythos가 72.4% 확률로 Firefox 익스플로잇을 생성할 수 있다면, 같은 모델이 다른 브라우저나 다른 소프트웨어에 대해서도 비슷한 능력을 가질 가능성이 높다. 이 모델을 방어자에게만 제공한다는 것은 “공격자는 같은 능력을 얻지 못한다”는 가정에 의존한다. 그 가정의 유효 기간은 얼마나 되는가? Anthropic은 자체적으로 이 질문에 대해 다소 비관적인 답변을 내놓은 셈이다. “결국 광범위하게 이용 가능해진다”는 것이 그들의 공식 입장이다. 그렇다면 Glasswing의 선제 방어는 시간 벌기라는 뜻이다. 그 시간을 어떻게 쓸 것인가가 진짜 질문이 된다.

같은 주에 OpenAI가 어린이 성적 착취 대응을 위한 새 안전 블루프린트를 발표한 것은 주목할 만한 사이드 맥락이다. Anthropic의 Glasswing과 동일한 주, 동일한 “우리가 얼마나 안전을 진지하게 다루는지” 메시지. 대형 AI 연구소들이 2026년 봄을 “안전 포지셔닝 경쟁”의 무대로 삼고 있다는 신호다. 이것은 공익적 방향이면서 동시에 기업 차별화 전략이다. 두 측면 모두 사실이고, 둘 중 하나만 강조하는 해석은 불완전하다.

7. 질문들 — 당신 팀의 보안은 어느 쪽 곡선 위에 있는가

Glasswing과 Trivy 사건이 같은 주에 터진 것이 우연이 아니라면, 이 두 사건이 던지는 질문은 AI 안전에 관한 것이 아니라 당신의 팀에 관한 것이 된다. 몇 가지 질문으로 정리한다.

당신의 팀이 CI 파이프라인에서 실행하는 보안 도구들의 바이너리 무결성을, 누가 언제 마지막으로 검증했는가. “공식 저장소에서 pull 받으니까 괜찮다”는 답은 2026년 기준으로 충분하지 않다. Trivy는 그 가정이 성립한다고 여겨지던 도구였다.

당신의 AI 에이전트가 자동으로 실행하는 명령어 목록을 관리하는 사람은 누구인가. Cursor나 Claude Code가 “보안 스캔을 해달라”는 지시에 응답할 때, 어떤 도구가 호출되는지, 그 도구들이 어떤 권한으로 실행되는지, 그리고 그 권한이 노출하는 시크릿이 무엇인지 — 이 체인 전체가 누군가의 머릿속에 있어야 한다. 에이전트 시대의 보안은 “개발자의 부주의”가 아니라 “에이전트의 자동성”을 공격 표면으로 봐야 한다.

당신이 사용하는 방어 도구의 능력 곡선이, 공격자가 접근할 수 있는 자동화 능력의 곡선을 따라잡고 있는가. Glasswing 같은 “프런티어 방어 모델”에 접근할 수 없는 대부분의 팀에게, 이 질문은 특히 무겁다. 답이 “아니오”라면, 차선은 무엇인가. 가능한 방향은 몇 가지다. 취약점 공개의 속도를 높이기, SBOM과 프로비넌스 검증을 CI 파이프라인의 기본으로 만들기, 에이전트의 도구 실행을 사람이 승인하는 게이트로 묶기, 시크릿의 scope와 TTL을 극단적으로 줄이기. 하나의 결정적 방어책은 없다. 하지만 “곡선 위의 격차를 인지하는 것” 자체가 첫 걸음이다.

마지막으로 가장 불편한 질문. 당신의 팀은 Anthropic이 “가장 숙련된 인간 이외에는 찾을 수 없는 취약점”이라고 부르는 그 층위의 버그를, 코드베이스에 얼마나 가지고 있을 것 같은가. 솔직한 답은 “모른다”일 것이다. Glasswing은 그 답을 소수의 파트너에게 먼저 알려줄 것이다. Trivy 공급망 공격은 그 답을 모르는 팀들의 시크릿을 이미 털어가고 있다. 두 사건이 같은 주에 터진 것은 우연이 아니다. 두 사건은 하나의 질문을 두 방향에서 던지고 있다. “자동화 비대칭의 곡선 위에서, 당신은 방어자인가 표적인가?”