2026년 공급망 공격 총정리: Claude Code 유출과 axios 악성 패키지 사건 분석

어떻게 단 한 번의 패키지 업데이트가 전 세계 AI 개발자들의 생태계를 위험에 빠뜨렸을까요? 2026년 3월 31일, “늘 하던 대로” 실행한 의존성 업데이트가 AI 도구 체인 전체를 감염시킬 수 있는 길이 될 뻔했습니다. 이 사건은 supply chain attack이 더 이상 일부 기업의 보안 이슈가 아니라, 오픈소스와 AI 배포 구조가 맞물린 순간 산업 전반의 시스템 리스크로 폭발할 수 있음을 보여줍니다.

axios 악성 배포가 보여준 supply chain attack의 파급력

2026년 3월 31일 00:21–03:29 UTC, 공격자는 전 세계적으로 널리 쓰이는 JavaScript HTTP 클라이언트인 axios의 악성 버전(1.14.1, 0.30.4)을 npm 레지스트리에 배포했습니다. 문제는 axios가 단순 라이브러리가 아니라 수많은 서비스의 네트워크 요청 경로 한가운데에 있다는 점입니다. HTTP 클라이언트가 오염되면 다음과 같은 시나리오가 현실이 됩니다.

API 키, 토큰, 세션 등 민감 정보 탈취
호출 대상 URL 변조, 트래픽 가로채기 등 요청 흐름 조작
개발/운영 환경으로 침투하는 Remote Access Trojan(RAT) 실행

게다가 악성 버전은 plain-crypto-js 같은 의심스러운 의존성을 포함해, 표면적으로는 “암호화 관련 유틸 추가”처럼 보이게 위장할 여지를 만들었습니다. 이처럼 supply chain attack은 변경 사항의 의미를 정상 기능처럼 꾸미고, 리뷰와 자동 검증의 틈을 노립니다.

사회공학 + 코드 유출이 결합된 supply chain attack의 정교함

이 사건이 더 위협적인 이유는 “기술”만이 아니라 “사람”도 함께 공격했다는 데 있습니다. 공격자는 가짜 Slack 워크스페이스를 만들고 기업 브랜딩까지 모방하는 방식으로 신뢰를 훼손했습니다. 즉, 패키지 배포 채널뿐 아니라 커뮤니케이션 채널까지 공격 표면이 된 것입니다.

여기에 같은 날 발생한 Claude Code 소스 유출이 겹치며 위험은 한 단계 더 커졌습니다. 유출된 코드에는 인터페이스 계약의 정확한 입출력 형태와 헤더 검증 로직이 포함되어, 공격자가 정상 MCP 서버처럼 동작하는 정교한 위장 엔드포인트를 만드는 데 필요한 정보가 제공될 수 있었습니다. 결과적으로 supply chain attack은 “악성 패키지 설치”에서 끝나지 않고, 정상 서비스로 위장한 외부 연결 지점까지 만들어내는 공격으로 확장됩니다.

AI 생태계가 특히 취약해지는 이유: 패키지 공급망과 배포 파이프라인의 결합

전통적인 소프트웨어 공급망 공격이 “라이브러리 감염”에 머물렀다면, 2026년 사건은 AI 시대의 특성을 드러냈습니다. AI 도구는 로컬 라이브러리와 원격 모델/도구 서버, 프롬프트/컨텍스트 전송, 토큰 기반 인증이 촘촘히 연결돼 있어 한 군데만 뚫려도 연쇄 침해로 번지기 쉽습니다.

같은 시기 litellm 1.82.8이 PyPI에서 공격을 받은 정황까지 나오며, 이는 단발 사건이 아니라 “AI 개발 커뮤니티 전체”가 표적이 될 수 있음을 시사했습니다. 결론적으로 2026년 supply chain attack은 업계에 이렇게 경고합니다.

“패키지 업데이트”는 유지보수가 아니라 보안 이벤트가 될 수 있다.
오픈소스 생태계와 AI 배포 구조가 결합하면, 공격의 반경은 개별 프로젝트가 아니라 산업 표준이 된다.
검증되지 않은 신뢰(패키지, 커뮤니티, 브랜딩)는 공격자가 가장 좋아하는 지름길이다.

supply chain attack 공격의 정체: 악성 Axios 패키지와 가짜 Slack 워크스페이스의 함정

왜 하필 Axios였을까요? 결론부터 말하면, Axios는 “대다수가 이미 설치했고, 누구도 의심하지 않는” 위치에 있는 라이브러리입니다. 프런트엔드와 백엔드(Node.js) 전반에서 광범위하게 쓰이고, 수많은 프로젝트의 의존성 트리에 자연스럽게 포함됩니다. 공격자 입장에서는 특정 기업 하나를 노리는 것보다, 패키지 레지스트리 한 번의 오염으로 전 세계 개발 환경을 동시에 감염시킬 수 있는 전형적인 supply chain attack의 최적 표적이 됩니다.

무엇이 악성이었나: 정상 업데이트처럼 보이게 만든 두 개의 트로이 목마 버전

2026년 3월 31일(UTC) 짧은 시간 동안 npm 레지스트리에 배포된 axios 악성 버전(1.14.1, 0.30.4)은 겉보기에는 “그냥 새 릴리스”처럼 보이도록 설계되었습니다. 하지만 내부에는 RAT(Remote Access Trojan)가 포함되어 있었고, 특히 의심스러운 plain-crypto-js 의존성을 통해 추가 페이로드 또는 우회 로직을 불러올 수 있게 구성된 정황이 포착됐습니다.

기술적으로 이 유형의 공격이 위험한 이유는 다음과 같습니다.

의존성의 전파력: 개발자가 axios를 직접 설치하지 않았더라도, 다른 패키지가 axios를 참조하는 순간 간접 설치가 발생할 수 있습니다. 즉, 피해 범위는 “사용자 수”가 아니라 “의존성 그래프의 폭”에 의해 폭발합니다.
업데이트 신뢰 악용: 많은 CI/CD 파이프라인이 패치/마이너 업데이트를 자동 반영합니다. 공격자는 이 관성을 이용해, 리뷰나 검증이 느슨한 구간을 통과합니다.
RAT의 목표: 단순한 데이터 탈취를 넘어 개발 머신, 빌드 서버, 배포 자격증명(토큰/키) 등 2차 침해의 발판을 마련합니다. 한 번 뚫리면 “사용자 단말 감염”이 아니라 “배포 체인 장악”으로 번질 수 있습니다.

결정적 한 방: “가짜 Slack 워크스페이스”로 보안을 무너뜨린 사회공학

이번 사건이 더 섬뜩했던 이유는, 악성 코드만 잘 심은 것이 아니라 사람의 판단 체계를 정교하게 공략했기 때문입니다. 공격자는 가짜 Slack 워크스페이스를 개설하고, 실제 회사 브랜딩을 모방해 “내부 커뮤니케이션 채널”처럼 보이게 만들었습니다. 이런 방식은 단순 피싱을 넘어, 다음과 같은 보안 허점을 노립니다.

개발자 신뢰 경로의 하이재킹: 개발자는 이슈 트래커나 이메일보다 Slack/DM에서 더 빠르게 반응합니다. “지금 긴급 패치가 필요하다”, “이 버전으로 올려야 한다” 같은 메시지는 검증 절차를 건너뛰게 만듭니다.
정당성의 연출: 로고, 역할(관리자/유지보수자), 채널 구조까지 흉내 내면, 링크 하나와 안내 문구만으로도 패키지 업데이트를 유도할 수 있습니다.
검증 단서의 제거: 공격자는 사용자가 “공식 공지”를 확인하기 전에 행동하도록 시간을 압축합니다. 결과적으로 레지스트리에 올라간 악성 버전이 짧은 시간만 노출되어도 충분한 피해가 발생합니다.

한 문장으로 정리하면: 코드가 아니라 ‘신뢰’가 공격 표면이 됐다

Axios 같은 핵심 라이브러리를 노린 supply chain attack은 단지 npm 패키지 하나를 바꾼 사건이 아닙니다. 레지스트리(배포 채널) + 의존성(전파 구조) + 커뮤니케이션(Slack 신뢰)를 한 번에 묶어 공격한, 현대 개발 생태계의 약점을 정확히 찌른 사례였습니다. 이때부터 보안의 핵심 질문은 “코드가 안전한가?”를 넘어, “이 업데이트를 믿게 만든 경로는 안전한가?”로 바뀌기 시작했습니다.

supply chain attack: Claude Code 유출과 공급망 공격의 숨겨진 연결고리

512,000줄에 달하는 소스 코드 유출은 단순 사고가 아니었습니다. 핵심은 “코드가 공개됐다”가 아니라, 공개된 코드가 공격자의 위장(impersonation) 비용을 거의 0에 가깝게 낮췄다는 데 있습니다. 특히 Claude Code에서 유출된 내용에는 인터페이스 계약(interface contract)의 정확한 입출력 형태와 헤더 검증 로직처럼, 정상 서버와 클라이언트가 서로를 신뢰하도록 만드는 ‘규칙’이 담겨 있었습니다. 이 규칙이 노출되는 순간, 공격자는 정상 동작을 그대로 흉내 내는 악성 서버를 만들 수 있습니다.

유출된 “인터페이스 계약”이 악성 서버를 완성시키는 방식

인터페이스 계약은 단순한 API 문서가 아닙니다. 보안 관점에서는 다음을 포함하는 정밀한 청사진에 가깝습니다.

요청/응답 스키마의 정확한 형태: 어떤 필드가 필수인지, 실패 시 어떤 에러 구조를 반환하는지까지 드러납니다.
헤더 검증 규칙: 어떤 헤더가 있어야 통과하는지, 어떤 값 패턴이 정상으로 간주되는지, 검증 순서나 예외 처리까지 노출될 수 있습니다.
클라이언트의 기대 동작: 클라이언트가 어떤 응답을 받으면 다음 단계로 진행하는지(리다이렉트, 재시도, 토큰 갱신 등)도 코드에서 역으로 읽힙니다.

이 정보가 있으면 공격자는 “대충 비슷한 서버”가 아니라, 클라이언트가 정상 서버라고 확신하도록 만드는 서버를 제작할 수 있습니다. 결과적으로 사용자는 눈치채지 못한 채 연결되고, 악성 서버는 정상적인 프로토콜 흐름 속에서 토큰, 설정, 실행 명령 같은 민감 정보를 탈취하거나 오염된 응답을 주입할 여지가 커집니다.

supply chain attack이 ‘패키지 감염’에서 ‘엔드포인트 위장’으로 확장되는 지점

전통적인 공급망 공격은 주로 패키지(의존성) 자체에 악성 코드를 심어 배포하는 방식이 중심이었습니다. 그런데 이번처럼 정상 서비스의 통신 규약과 검증 로직이 유출되면, 공격 표면이 한 단계 넓어집니다.

악성 패키지 배포(침투 경로 확보)
예를 들어 npm에 악성 버전이 배포되면 개발 환경이나 CI가 이를 설치하면서 감염이 시작됩니다.
정상 서비스로 위장한 악성 엔드포인트 준비(위장 정교화)
유출된 인터페이스 계약과 헤더 검증 로직을 기반으로, 클라이언트가 의심하지 않는 수준의 “정상처럼 보이는” 서버가 가능합니다.
클라이언트-서버 신뢰 체인 악용(지속성/확장성 확보)
패키지가 단순히 정보를 훔치는 데 그치지 않고, 정상 워크플로 속에서 계속 통신을 유지하며 더 큰 권한이나 더 많은 데이터를 노립니다.

즉, supply chain attack이 더 이상 “라이브러리 하나가 감염됐다”에서 끝나지 않고, 프로토콜 수준의 신뢰를 모방해 생태계 전체를 속이는 공격으로 진화할 수 있음을 보여줍니다.

왜 이 조합이 특히 AI 도구에서 치명적인가

AI 개발 도구는 대체로 다음 특징을 가집니다.

플러그인/확장/도구 호출 등으로 외부 엔드포인트와의 연결이 빈번합니다.
개발자 로컬, CI, 에이전트 런타임 등 실행 지점이 다양합니다.
설정 파일, 토큰, 모델 호출 로그 등 고가치 데이터가 주변에 밀집해 있습니다.

따라서 “악성 패키지 설치”와 “정상 서버 위장”이 결합하면, 단일 침투로도 조직 단위의 광범위한 정보 노출로 이어질 수 있습니다. 유출된 코드가 제공한 것은 단순한 구현 세부가 아니라, 공격자가 이 신뢰 관계를 복제하는 데 필요한 정확한 설계도였다는 점이 가장 위험합니다.

supply chain attack 관점에서 본 AI 도구 배포와 오픈소스 생태계의 위험한 결합

전통적인 오픈소스 패키지 배포 방식과 AI 도구의 결합은, 단순히 “설치가 편해졌다”는 수준을 넘어 공격 표면을 폭발적으로 확장시켰습니다. npm·PyPI 같은 패키지 레지스트리는 원래도 대규모 전파가 가능한 채널이지만, AI 도구가 여기에 얹히는 순간 개발 환경(로컬)–CI/CD–운영 인프라–외부 모델/도구 호출이 하나의 흐름으로 연결됩니다. 이 연결성이 바로 supply chain attack이 노리는 지점입니다.

패키지 관리자가 AI 개발 파이프라인의 “고속도로”가 되는 이유

오픈소스 생태계는 의존성 그래프가 깊고 넓습니다. 특히 AI 개발에서는 다음 구성요소가 동시에 섞입니다.

SDK/클라이언트 라이브러리(예: HTTP 클라이언트, 인증, 로깅)
에이전트/툴 실행 프레임워크(도구 호출, 플러그인 로딩)
배포 자동화(CI에서 설치 → 빌드 → 테스트 → 배포)
모델 컨텍스트/툴 프로토콜(MCP 같은 외부 엔드포인트 연동)

이 환경에서 패키지 하나가 오염되면, 감염 지점은 단일 앱이 아니라 해당 패키지를 설치하는 모든 개발자·빌드 서버·운영 워크로드가 됩니다. 2026년 axios 사건처럼 널리 쓰이는 패키지에 악성 버전이 올라가면, 설치 순간부터 공격은 “대량 유통”됩니다.

“악성 코드 삽입”을 넘어: 정상 서비스로 위장하는 악성 엔드포인트의 등장

기존 공급망 공격은 주로 악성 코드(RAT, 백도어) 삽입으로 요약되곤 했습니다. 하지만 AI 도구가 결합되면 위협은 한 단계 진화합니다. 이유는 AI 도구가 외부 시스템과 상호작용하는 방식이 더 복잡하고, 더 자동화되어 있기 때문입니다.

에이전트/CLI는 종종 외부 서버(MCP 서버 등)와 통신하며, 도구 목록·스키마·권한을 받아 동적으로 동작합니다.
인터페이스 계약(입출력 형태), 헤더 검증 로직 같은 세부가 노출되면 공격자는 정상 서버와 구분하기 어려운 악성 서버를 만들 수 있습니다.
결과적으로 “패키지 감염 → 악성 엔드포인트 연결 → 데이터/권한 탈취”가 자연스러운 흐름으로 이어집니다.

즉, 공격의 목표가 단순 실행 권한 확보에서 끝나지 않고, AI 도구 생태계 자체(프로토콜·툴체인·엔드포인트 신뢰)를 복제해 신뢰를 탈취하는 형태로 확장됩니다.

왜 AI 도구는 supply chain attack에 더 취약해 보이는가

AI 개발 도구는 편의성을 위해 권한과 자동화를 과감히 사용합니다. 이 특성이 공격자에게는 “넓은 권한을 가진 자동 실행기”로 보입니다.

설치 후 즉시 실행되는 워크플로
설치(의존성 해결) 직후 테스트·빌드·코드 생성·포맷팅이 자동으로 수행되며, 이 과정에서 네트워크 접근과 파일 시스템 접근이 동반됩니다.
환경 변수와 비밀정보의 밀집
API 키, 토큰, 레지스트리 자격증명, 클라우드 크리덴셜이 개발 환경과 CI에 자연스럽게 존재합니다. 악성 패키지는 이를 수집해 외부로 유출할 유인이 큽니다.
동적 로딩/플러그인 구조
“도구를 더 붙이면 더 똑똑해진다”는 구조는, 반대로 말하면 외부 코드·외부 엔드포인트를 더 쉽게 신뢰하게 만든다는 뜻입니다.

결론: 오픈소스 유통망에 올라탄 AI 도구는 “침해의 증폭기”가 된다

오픈소스 패키지 레지스트리는 빠른 확산을 돕는 유통망이고, AI 도구는 자동 실행과 외부 연동을 통해 그 유통망의 효과를 극대화합니다. 이 조합은 supply chain attack을 더 넓게 퍼뜨리고, 더 깊게 침투시키며, 더 정교하게 위장하게 만듭니다. 이제 공급망 보안은 “악성 패키지 탐지”만으로는 부족하며, 도구가 신뢰하는 엔드포인트와 프로토콜 레벨의 위장 가능성까지 함께 보아야 합니다.

supply chain attack 시대의 방어 혁신: 평판 기반 시스템과 네이티브 인스톨러의 등장

공격을 막기 위해 업계는 어떤 혁신적 변화를 시도하고 있을까요? 최근 사건들이 보여준 결론은 명확합니다. 공격자는 코드 한 줄이 아니라 “유통 경로”와 “신뢰 구조”를 노린다는 것. 그래서 방어도 단순한 취약점 패치가 아니라, 협업 방식과 배포 방식 자체를 재설계하는 방향으로 빠르게 이동하고 있습니다.

supply chain attack를 키우는 PR 협업의 구조적 한계

오픈소스 생태계의 표준에 가까운 Pull Request(PR) 기반 협업은 투명성과 속도를 제공하지만, 공급망 관점에서는 치명적 약점을 내포합니다.

검토 부담의 비대화: 의존성, 빌드 스크립트, CI 설정, 난독화된 변경까지 모두 사람이 읽고 판단해야 합니다. 프로젝트가 커질수록 “정상으로 보이는 악성 변경”이 섞여 들어갈 가능성이 커집니다.
신뢰가 계정과 절차에 묶임: PR 절차를 통과했다는 사실이 곧 신뢰를 의미하지 않습니다. 계정 탈취, 소셜 엔지니어링, 리뷰 피로도를 악용하면 PR은 “보안 장치”가 아니라 “통과 의식”이 될 수 있습니다.
의존성 연쇄 폭발: 한 패키지의 작은 변화가 수많은 하위 프로젝트로 전파됩니다. 즉, PR에서 놓친 1개의 변경이 곧 대규모 supply chain attack의 기폭제가 됩니다.

이 한계를 체감한 업계가 꺼내 든 카드가 바로 평판 기반 시스템(reputation-based system) 입니다.

supply chain attack 방어를 위한 평판 기반 시스템: “코드”가 아니라 “신뢰”를 관리한다

평판 기반 시스템의 핵심은 단순합니다. 기여자의 신뢰도를 정량화하고, 그 신뢰도에 따라 변경 권한과 검증 강도를 차등 적용하는 것입니다. PR이라는 단일 통로에 모든 판단을 몰아넣는 대신, “누가 무엇을 얼마나 자주, 어떤 품질로 해왔는가”를 신뢰의 축으로 삼습니다.

기술적으로는 다음과 같은 형태로 구현됩니다.

기여 이력 기반 신뢰 점수: 과거 커밋의 안정성, 보안 사고 이력, 롤백 빈도, 리뷰 통과 패턴 등을 종합해 평판 점수를 산정합니다.
정책 기반 게이팅(policy gating): 평판이 낮거나 신규 기여자의 변경은 자동으로 더 강한 검증(추가 리뷰, 샌드박스 실행, 보안 스캔, 서명 요구)을 거치게 합니다. 반대로 신뢰가 검증된 기여자는 제한적 자동 병합 범위를 부여할 수 있습니다.
위험도 기반 검증 강화: 코드 라인 수가 아니라 “영향 범위”에 따라 검증을 강화합니다. 예를 들어 배포 스크립트, 네트워크 요청 로직, 암호화/인증 관련 변경은 평판이 높아도 별도의 보안 게이트를 거치게 설계할 수 있습니다.

이 접근의 장점은 “악성 변경이 PR에 숨어드는 문제”를 절차로만 잡지 않고, 신뢰의 흐름 자체를 관리한다는 점입니다. 결과적으로 공급망 공격자가 가장 좋아하는 구간—리뷰 피로, 권한 남용, 신규 기여 위장—을 정면으로 압박할 수 있습니다.

supply chain attack 표면을 줄이는 네이티브 인스톨러 전환: 배포 채널을 재설계하다

협업 구조가 “코드가 들어오는 길”을 바꾸는 전략이라면, 네이티브 인스톨러 전환은 “사용자에게 전달되는 길”을 바꾸는 전략입니다. 일부 기업이 패키지 레지스트리 중심 배포에서 벗어나 네이티브 인스톨러로 이동하는 이유는 분명합니다.

레지스트리 의존 위험 감소: npm/PyPI 같은 공개 레지스트리는 생태계 확장에 유리하지만, 그만큼 공격자에게도 “대규모 유통망”이 됩니다. 네이티브 인스톨러는 이 거대한 유통망을 우회해 공격면을 축소합니다.
서명과 무결성 검증의 표준화: 운영체제 레벨의 코드 서명, notarization, 설치 패키지 무결성 검증을 결합하면 “누가 배포했는지”와 “중간에 바뀌지 않았는지”를 더 강하게 증명할 수 있습니다.
업데이트 채널 통제 강화: 자동 업데이트를 하더라도, 업데이트 서버·서명키·배포 정책을 공급자가 더 엄격히 통제할 수 있어 supply chain attack 확산 속도를 낮출 수 있습니다.

물론 네이티브 인스톨러가 만능은 아닙니다. 인스톨러 자체의 업데이트 인프라가 공격받을 수 있고, 서명키 탈취 리스크도 존재합니다. 하지만 핵심은 “패키지 레지스트리 단일 경로”에 걸린 의존도를 분산시키고, 배포의 신뢰 체인을 더 강한 암호학적 증명으로 묶는 것입니다.

supply chain attack 이후의 표준: “검토”에서 “구조”로, “패치”에서 “생태계 설계”로

이제 방어의 무게중심은 이동하고 있습니다. 더 많이 리뷰하고 더 많은 체크리스트를 추가하는 방식만으로는, 고도화된 사회공학과 대규모 유통 채널을 결합한 공격을 따라잡기 어렵습니다. 그래서 업계는 다음의 방향으로 수렴합니다.

협업 구조는 평판과 정책으로 자동화·차등화
배포 구조는 서명과 통제 가능한 채널로 재편
신뢰는 “사람의 선의”가 아니라 “검증 가능한 체계”로 전환

공급망 공격이 “현대 소프트웨어의 기본 리스크”가 된 지금, 미래를 지키는 힘은 개별 취약점 대응이 아니라 신뢰와 유통을 설계하는 능력에서 나옵니다.