배포 파이프라인에서 신뢰가 무너지는 세 가지 방식
AI 코딩 도구를 팀 워크플로우에 통합한다는 건, 단순히 '더 빠르게 코드를 짜는 것'이 아니다. 그 도구가 참조하는 패키지, 그 도구가 실행하는 명령, 그 도구가 배포하는 아티팩트—전부 신뢰 체계 위에 올라가 있다. 그리고 최근 세 가지 사건이 그 신뢰 체계의 취약 지점을 각각 다른 층위에서 정확히 찌르고 들어왔다.
사건 1: Anthropic이 자사 도구로 자사 코드를 유출했다
Claude Code의 소스코드 유출은 공격자가 아니라 Anthropic 자신의 배포 파이프라인에서 터졌다. npm 패키지에 소스맵이 포함된 채 배포된 것이 원인이었고, Bun 런타임의 소스맵 버그(oven-sh/bun#28001)가 유력한 원인으로 지목된다. 아이러니한 건, Anthropic이 지난해 Bun을 인수했다는 사실이다. 자사 도구 체인의 버그가 자사 핵심 제품을 유출한 셈이다.
유출된 코드에는 단순한 로직 이상의 것이 담겨 있었다. 모델 모방을 방해하기 위한 가짜 도구 삽입(anti-distillation), AI 정체를 숨기는 undercover 모드, 하루 25만 건의 실패 API 호출을 방치했던 루프 버그, 미완성 자율 에이전트 모드 KAIROS의 구조까지. 경쟁사에 로드맵이 통째로 노출됐다. 코드 자체보다 Feature Flag와 전략 기능이 드러난 게 더 큰 손상이다.
이 사건이 배포 파이프라인 설계자에게 주는 교훈은 명확하다. 프로덕션 빌드에서 소스맵이 포함되지 않는지 검증하는 CI 단계가 있었다면 막을 수 있었다. 써드파티 런타임에 의존하는 빌드라면 더욱 그렇다. 도구를 믿기 전에, 그 도구가 만들어내는 아티팩트를 검증하는 단계를 파이프라인에 박아야 한다.
사건 2: AI 어시스턴트는 npm install이 안전한지 모른다
dev.to에서 공유된 Axios 공급망 공격 분석은 Vibe Coding의 구조적 맹점을 정면으로 드러냈다. 2026년 3월 30일, 주간 1억 다운로드의 Axios 패키지가 약 2시간 동안 RAT(원격 접근 트로이목마)를 심은 악성 버전으로 대체됐다. 공격자는 실제 유지관리자 계정을 탈취해 axios@1.14.1을 게시했고, npm install 실행 후 2초 만에 악성 코드가 실행됐다.
문제는 그 설치를 실행한 것이 AI 어시스턴트였다면, 개발자는 이 과정을 아예 보지 못했다는 점이다. AI는 코드가 '동작하는지'를 최적화할 뿐, 의존성이 '안전한지'는 검증하지 않는다. 패키지가 72시간 이내 게시된 신규 버전인지, 유지관리자 계정이 바뀌었는지, postinstall 스크립트에 무엇이 들어 있는지—AI는 이것들을 묻지 않는다.
같은 달, Trivy/CanisterWorm 공격에서 76개 GitHub Action 태그 중 75개가 블록체인 기반 C&C를 사용하는 악성 코드로 교체됐다. 보안 스캐너 자체가 공격 벡터가 된 것이다. 11일 만에 두 번의 주요 공급망 공격. 이건 트렌드다.
AI-First 팀이 지금 당장 파이프라인에 박아야 할 것들: ^ 와 ~를 제거한 버전 고정, CI에서 npm install 대신 npm ci 사용, --ignore-scripts 플래그로 postinstall 스크립트 차단, 72시간 미만 게시된 버전 설치 차단 정책. 그리고 가장 중요한 것—AI가 제안한 의존성 설치 명령은 반드시 사람이 검토한 뒤 실행해야 한다.
사건 3: gstack이 보여주는 역할 분리의 가치
Y Combinator CEO 가리 탄(Garry Tan)이 공개한 오픈소스 프로젝트 gstack은 앞의 두 사건과는 결이 다른 이야기다. 이건 문제가 아니라 해법의 방향을 보여준다.
gstack은 Claude Code에 역할 기반 아키텍처를 덧씌운다. /gstack:ceo(전략 검토), /gstack:eng-manager(아키텍처 설계), /gstack:engineer(코드 구현), /gstack:qa(테스트), /gstack:devops(배포·인프라), /gstack:release-manager(릴리즈 관리)—실제 소프트웨어 조직의 역할 분리를 AI에 그대로 적용한 구조다.
이 접근이 흥미로운 이유는 단순히 '프롬프트를 분리했다'는 게 아니다. AI에게 일을 시키는 것에서, '누가 이 일을 해야 하는지'를 지정하는 것으로 패러다임을 바꾼다. QA 역할은 코드를 짜지 않고 버그를 찾는다. DevOps 역할은 기능을 추가하지 않고 배포 안정성을 본다. 역할마다 다른 관심사와 제약을 가지도록 설계함으로써, 단일 에이전트가 기능 구현에 집중하다 보안과 품질을 놓치는 문제를 구조적으로 완화한다.
세 사건이 함께 가리키는 것
Claude Code 유출, Axios 공급망 공격, gstack의 역할 분리—이 세 사건을 따로 보면 각각 '빌드 설정 실수', '보안 사고', '새로운 도구 출시'다. 하지만 함께 보면 하나의 메시지를 가리킨다.
AI 코딩 도구를 팀 워크플로우에 통합할 때, 신뢰는 도구의 성능에서 오는 게 아니라 파이프라인 설계에서 온다.
배포 아티팩트에 소스맵이 포함됐는지 검증하는 CI 스텝이 있었다면 유출은 없었다. AI가 실행한 npm install을 파이프라인이 한 번 더 검증했다면 공급망 공격은 차단됐다. 역할을 분리하지 않고 단일 에이전트에게 기능 구현부터 배포까지 맡겼다면 품질과 보안은 그 에이전트의 관심사 밖으로 밀려났다.
내일 당장 파이프라인에 추가해야 할 것들
이론적으로 좋은 얘기 말고, 현장에서 내일 실행할 수 있는 것으로 좁히면 세 가지다.
첫째, 빌드 아티팩트 검증 단계를 CI에 추가하라. 프로덕션 빌드에 소스맵이 포함됐는지, 민감한 주석이나 내부 설정이 번들에 포함됐는지를 자동으로 검사하는 스텝이다. 써드파티 런타임이나 빌드 도구를 믿기 전에, 그 결과물을 검증하는 단계를 파이프라인에 박아야 한다.
둘째, 의존성 설치를 AI의 자율 영역에서 꺼내라. npm ci를 기본으로 쓰고, --ignore-scripts를 CI 환경에 적용하고, 72시간 미만 게시된 패키지 버전을 차단하는 정책을 자동화하라. AI가 생성한 의존성 목록은 반드시 사람이 검토한 뒤 설치 명령이 실행되도록 루프를 설계해야 한다.
셋째, 역할 분리를 에이전트 설계에 적용하라. gstack의 접근처럼, AI 에이전트가 기능 구현에만 집중할 때 보안과 품질 검토는 별도 역할로 분리하라. 단일 에이전트에게 '코드 짜고, 테스트하고, 배포까지 해'라고 시키는 구조는 관심사 충돌을 내장한다.
전망: 도구 신뢰가 아니라 시스템 신뢰
AI 코딩 도구의 성능은 계속 올라간다. Claude Code의 코드 품질, GitHub Copilot의 자동완성 정확도, Cursor의 컨텍스트 이해—이 숫자들은 분기마다 개선된다. 하지만 그 도구들이 만들어내는 배포 파이프라인의 신뢰도는 자동으로 올라가지 않는다.
"AI가 작성한 코드를 배포하다가 AI가 만든 버그로 코드가 새어 나간" Claude Code 유출 사건의 아이러니는, AI-First 개발의 속도가 높아질수록 파이프라인 설계의 빈틈이 더 빠르게 노출된다는 사실을 보여준다. 공급망 공격자들도 이미 이 속도에 올라타고 있다.
신뢰는 도구 선택 시점에 결정되지 않는다. CI 스텝 하나, 의존성 정책 한 줄, 역할 분리 설계 하나—그 축적이 시스템의 신뢰도를 만든다. AI 도구가 팀의 동료가 되는 속도만큼, 그 동료를 검증하는 구조를 설계하는 속도가 따라가야 한다.