59.8 MB.

Anthropic(앤스로픽, AI 스타트업)이 실수로 npm(노드 패키지 매니저) 레지스트리에 공개한 소스 맵 파일의 크기입니다. 비유하자면, 정성껏 만든 요리를 손님에게 내놓으면서 주방의 모든 레시피와 내부 설계도가 상세히 적힌 메모지를 접시에 함께 올려 보낸 셈입니다. 그런데 이 황당한 실수 하나가 단순한 해프닝으로 끝나지 않았습니다.

최근 50일 동안 OpenAI, Anthropic, Meta 등 글로벌 AI 거물들이 잇따라 공급망 공격의 희생양이 되었습니다. 흥미로운 점은 공격자들이 AI 모델의 취약점을 파고들어 '탈옥'을 시도하거나 잘못된 답변을 유도한 것이 아니라는 사실입니다. 그들은 모델이 만들어지고 사용자에게 전달되는 '통로', 즉 배포 파이프라인의 헐거운 틈새를 정확히 겨냥했습니다. 모델 안전성을 검증하는 레드팀(보안 취약점을 찾기 위해 공격자 역할을 하는 팀)이 모델의 경계선 안쪽만 살피는 동안, 정작 그 모델을 실어나르는 트럭의 문은 열려 있었던 것입니다.

50일간 4건의 사고, OpenAI부터 Meta까지 휩쓴 공급망 공격

3월 24일부터 27일 사이, 해킹 그룹 TeamPCP가 취약점 스캐너인 Trivy의 자격 증명을 도용하며 공격의 서막을 알렸다. 이들은 이를 통해 LLM 프록시 게이트웨이(여러 AI 모델을 효율적으로 연결하고 관리하는 도구)인 LiteLLM의 파이썬 패키지에 악성 코드를 심었다. 비유하자면 완성된 요리를 공격하는 것이 아니라 식재료를 공급하는 공장에 독을 탄 것과 같다. 이 오염된 패키지는 PyPI(파이썬 패키지 저장소)에 약 40분간 게시되었고, 그 사이 4만 7천 건에 가까운 다운로드가 발생했다. 피해는 여기서 끝나지 않고 AI 데이터 스타트업인 Mercor로 이어졌다. 이 과정에서 4TB에 달하는 방대한 데이터가 유출되었으며, 여기에는 Meta의 독자적인 학습 방법론까지 포함되어 있었다. 단 하나의 오픈소스 의존성 도구가 뚫린 것만으로 업계 전체에 거대한 피해 범위가 형성된 셈이다.

3월 30일에는 OpenAI Codex에서 깃허브 브랜치 이름을 셸 명령어(운영체제에 직접 명령을 내리는 텍스트 기반 인터페이스)로 직접 전달하는 취약점이 발견되었다. 공격자가 브랜치 이름에 세미콜론과 백틱 같은 특수문자를 섞어 넣으면, 시스템이 이를 단순한 이름이 아닌 실행 가능한 명령어로 인식해 피해자의 OAuth 토큰(사용자 인증을 위한 디지털 열쇠)을 그대로 노출했다. 이어 3월 31일에는 Anthropic의 Claude Code 2.1.88 버전에서 59.8 MB 크기의 소스 맵 파일이 유출되는 사고가 났다. 소스 맵은 쉽게 말해 개발자가 코드를 디버깅하기 위해 사용하는 지도 같은 파일이다. 이 파일 하나로 1,906개 파일에 걸친 51만 3천 줄의 TypeScript 소스 코드가 세상에 드러났다. 에이전트 오케스트레이션 로직과 시스템 프롬프트 같은 핵심 설계도가 인증 절차 없이 누구나 다운로드할 수 있는 상태였다. 이는 공격자의 침입이 아니라 .npmignore 파일의 설정 누락이라는 단순한 인적 실수로 발생한 배포 사고였다.

가장 최근인 5월 11일부터 14일 사이에는 Mini Shai-Hulud라는 이름의 웜(스스로 복제하며 퍼지는 악성 프로그램)이 등장했다. 이 웜은 UI 라이브러리인 TanStack을 포함해 160개 이상의 패키지를 순식간에 오염시켰다. 특히 깃허브 액션의 설정 오류와 캐시 오염을 이용해 신뢰받는 배포 경로 자체를 하이재킹했다. 이 과정에서 웜은 claude <[email protected]>라는 가짜 정체성을 만들어 코드 리뷰를 우회하는 치밀함까지 보였다. 결국 이 공격은 OpenAI 직원들의 기기 2대까지 감염시키는 결과로 이어졌다. OpenAI는 이미 이전의 공급망 공격 이후 CI/CD 파이프라인(코드 작성부터 배포까지 자동화하는 경로)을 강화하고 있었지만, 감염된 기기들은 아직 업데이트된 설정이 적용되지 않은 상태였다. 모델의 안전성을 검증하는 레드팀 활동이 모델의 경계선에서 멈추는 동안, 정작 모델을 실어 나르는 배포 경로라는 뒷문은 열려 있었던 셈이다.

'모델 레드팀'이 보지 못한 사각지대: 배포 파이프라인의 작동 원리

Mini Shai-Hulud라는 웜이 단 6분 만에 42개의 npm 패키지에 악성 코드를 심었다. 이 공격은 모델의 취약점이 아니라 배포 자동화 도구의 설정 오류라는 인프라적 틈새를 파고들었다. 구체적으로는 `pull_request_target` 설정의 허점을 이용해 GitHub Actions(깃허브 액션, 소프트웨어 개발 자동화 도구)의 캐시를 오염시키고, 러너 메모리에서 OIDC(OpenID Connect, 신원 확인 표준) 토큰을 추출해냈다. 비유하자면 성벽의 정문은 철저히 지켰지만, 식자재가 들어오는 뒷문 열쇠를 도둑맞은 셈이다. 특히 이번 사례는 소프트웨어 공급망 보안 표준인 SLSA Build Level 3를 통과했음에도 악성 파일이 생성되었다는 점에서 큰 충격을 주었다. 올바른 저장소와 워크플로를 사용하고 정당한 토큰으로 인증했다면 무조건 안전하다고 믿었던 기존 신뢰 모델의 한계가 적나라하게 드러난 지점이다.

인프라의 작은 틈새는 때로 거대한 유출로 이어진다. 앤스로픽(Anthropic)의 경우 외부 공격자가 없었음에도 `.npmignore` 파일에서 단 한 줄의 설정이 누락되어 소스 맵 파일이 그대로 공개되었다. 소스 맵은 기계어로 변환된 코드를 사람이 읽을 수 있게 연결해주는 지도 같은 파일인데, 이 때문에 내부의 핵심 로직과 시스템 프롬프트가 모두 노출되었다. 오픈에이아이(OpenAI)의 코덱스(Codex) 사례는 더 교묘했다. 공격자가 유니코드 문자를 사용해 악성 브랜치 이름을 시각적으로 `main`과 똑같이 만들어 사용자를 속였다. 쉽게 말하면 이름표의 글자 모양만 비슷하게 만들어 가짜를 진짜로 믿게 만든 수법이다. 이처럼 배포 과정의 사소한 설정 누락이나 시각적 착각이 모델 자체의 지능이나 안전성보다 더 치명적인 보안 구멍이 된다.

여기서 우리는 모델 레드팀과 배포 레드팀의 결정적인 차이를 이해해야 한다. 레드팀은 시스템의 약점을 찾기 위해 공격자 입장에서 테스트하는 팀을 말한다. 기존의 모델 레드팀은 주로 인공지능이 금지된 답변을 하도록 유도하는 탈옥이나 오용 가능성을 점검하며 시스템 카드(모델의 성능과 안전성을 기록한 명세서)를 작성했다. 하지만 이번 사고들이 보여주듯, 정작 위험한 곳은 모델 외부의 배포 파이프라인이다. 배포 레드팀은 CI(Continuous Integration, 지속적 통합) 러너의 신뢰 경계나 패키징 게이트(최종 배포 전 검수 단계)를 점검해야 한다. 모델이 아무리 도덕적이고 안전하게 설계되었어도, 그 모델을 사용자에게 전달하는 컨베이어 벨트가 오염되어 있다면 결과물은 결국 독이 든 사과가 될 수밖에 없기 때문이다.

GPT-5.5-Cyber로도 못 막은 '배포의 틈', 실무자가 챙겨야 할 체크리스트

OpenAI는 5월 10일 GPT-5.5와 GPT-5.5-Cyber를 기반으로 한 사이버 보안 이니셔티브 데이브레이크(Daybreak)를 출시했다. 최첨단 AI가 보안 전문가의 역할을 대신해 취약점을 찾고 방어하는 시대가 왔음을 선포한 순간이었다. 하지만 아이러니하게도 바로 다음 날인 5월 11일, 탠스택(TanStack, 오픈소스 UI 라이브러리 제작팀) 웜이라는 악성 코드가 OpenAI 직원들의 기기를 감염시키는 사건이 발생했다. 세계 최고의 보안 AI 모델을 내놓은 지 단 하루 만에 정작 내부 시스템의 배포 경로가 뚫려버린 셈이다.

비유하자면 모델의 안전성(Safety)은 집 안에 들인 최첨단 AI 보안 로봇과 같다. 로봇이 아무리 똑똑해서 침입자의 패턴을 분석하고 경고를 울려도, 정작 집 뒷문이 열려 있거나 열쇠 관리자가 부주의하면 아무 소용이 없다. 여기서 뒷문에 해당하는 것이 바로 CI/CD(지속적 통합 및 배포, 개발자가 짠 코드를 자동으로 검사하고 서비스에 반영하는 과정) 설정이다. 이번 사건은 모델 자체가 뚫린 것이 아니라, 코드가 사용자에게 전달되는 통로인 배포 파이프라인의 틈새를 통해 공격이 들어왔다는 점에서 시사하는 바가 크다.

사건 직후 OpenAI는 macOS 보안 인증서를 폐기하고 2026년 6월 12일까지 모든 데스크톱 사용자의 업데이트를 강제하는 조치를 취했다. 쉽게 말하면 도어락 비밀번호가 유출되었으니 모든 집의 자물쇠를 교체하고 강제로 새 열쇠를 배포하는 상황과 비슷하다. 보안 인증서는 해당 소프트웨어가 믿을 수 있는 곳에서 만들어졌음을 증명하는 일종의 디지털 인감도장인데, 이 도장의 신뢰성이 깨졌기에 전면 교체가 불가피했다. 이는 모델의 지능과는 전혀 무관한, 아주 기초적인 인프라 관리의 영역이다.

실무자들은 이번 사례를 통해 NIST SSDF(미국 국립표준기술연구소의 보안 소프트웨어 개발 프레임워크)의 핵심 항목을 다시 점검해야 한다. 구체적으로는 코드에 대한 무단 접근을 막는 PS.1.1과 릴리스된 결과물이 변조되지 않았는지 검증하는 PS.2.1 준수가 필수적이다. 쉽게 말해 코드를 짜는 공간에 아무나 들어오지 못하게 잠그고, 완성된 제품이 공장을 나갈 때 정품 스티커가 제대로 붙어 있는지 확인하는 절차를 강화하라는 뜻이다. 모델의 성능을 높이는 안전성 투자만큼이나, 배포 경로를 지키는 보안 투자가 시급한 이유다.