월간 다운로드 400만 회. 100개 이상의 LLM 프로바이더 지원. 여러분의 애플리케이션과 모든 API 키, 모든 프롬프트, 여러분이 보낸 모든 모델 응답 사이에 놓인 하나의 감염된 패키지.
OpenAI, Anthropic, Cohere 등 수십 개의 프로바이더에 대한 호출을 통합하기 위해 AI 생태계의 절반이 의존하는 Python 프록시 라이브러리, LiteLLM이 공급망 공격을 당했다. 악성 코드는 PyPI에 올라갔고, 커뮤니티가 이를 발견할 무렵에는 이미 실시간 추론 트래픽을 처리하는 프로덕션 파이프라인에 자리 잡은 뒤였다.
이건 또 하나의 left-pad 사건이 아니다. 이건 그보다 심각하다.
실제로 무슨 일이 일어났나
감염된 버전의 litellm이 Python 패키지 인덱스인 PyPI에 등장했다. 백도어는 가볍게 살펴보는 정도로는 발견되지 않을 만큼 교묘했다. BerriAI의 GitHub 리포지토리에 올라온 논의에 따르면, 악성 페이로드는 민감한 데이터 — LLM 프로바이더의 API 키, 전송되는 프롬프트, 그리고 돌아오는 응답까지 — 를 외부로 유출할 수 있었다.
맥락을 짚자면, LiteLLM의 핵심 가치 제안은 여러분의 코드와 LLM API 사이에서 프록시 역할을 한다는 것이다. 미들웨어다. 모든 것을 볼 수 있다. 이 단 하나의 사실이 이번 침해를 일반적인 의존성 탈취보다 훨씬 더 위험하게 만든다.
파장 분석: 개발자와 연구자들의 반응
오픈소스 AI 커뮤니티의 여러 개발자 및 보안 연구자들에게 연락해 이번 사건의 규모와 여파를 파악했다. 다음은 그 결과다.
LiteLLM은 프로덕션 AI 시스템에 얼마나 깊이 들어가 있는가?
YC 출신 스타트업의 시니어 ML 엔지니어(익명 조건): "저희는 세 개의 별도 마이크로서비스에서 LiteLLM을 사용하고 있습니다. GPT-4o와 Claude 간의 폴백 로직을 처리하죠. 침해 소식을 듣고 모든 서비스, 모든 컨테이너 이미지, 캐시된 모든 wheel 파일을 감사해야 했습니다. 이틀이 걸렸어요. 대부분의 팀은 아직 시작도 못 했을 겁니다."
litellm의 PyPI 페이지를 보면 Python 생태계에서 가장 인기 있는 AI 유틸리티 패키지 중 하나로 꼽힌다. 수많은 튜토리얼, 블로그 게시물, 심지어 일부 공식 통합 가이드에서도 기본 추천 패키지다. "여러 LLM 프로바이더를 호출하는 방법"을 검색하면 LiteLLM이 첫 번째 답이다.
공격자가 스택에서 LiteLLM의 위치를 이용해 할 수 있는 일은?
유사 사건을 분석한 경험이 있는 공급망 보안 연구자: "그 라이브러리를 통해 무엇이 오가는지 생각해 보세요. OpenAI, Anthropic, Azure, Bedrock의 API 키. 모든 프롬프트 — 기업 사용자의 경우 독점 데이터, 개인식별정보(PII), 법률 문서가 포함될 수 있습니다. 모든 응답. AI 워크로드를 위한 완벽한 유출 지점을 설계하려 한다면, LiteLLM과 정확히 똑같은 것을 만들게 될 겁니다."
인프라 팀이 밤잠을 설쳐야 할 부분이 바로 이것이다. LiteLLM은 로컬에서 실행하는 개발 도구가 아니다. 프로덕션 서버에 배포되어 실제 고객 데이터를 처리한다. 공격 표면은 개발자의 노트북이 아니라 여러분의 추론 파이프라인이다.
최근 Trivy 공급망 사건과 비교하면 어떤가?
필자의 견해: Trivy 침해도 심각했다 — 보안 도구가 백도어에 당하는 것은 아이러니하면서도 위험하다. 하지만 Trivy는 CI/CD에서 컨테이너를 스캔하며 동작한다. LiteLLM은 추론의 핫 패스에서 실시간 트래픽을 처리하며 동작한다. 감염된 LiteLLM 인스턴스를 통해 흐르는 데이터는 Trivy가 다루는 어떤 것보다도 차원이 다르게 민감하다. 컨테이너 스캔 결과 대 실제 API 키와 사용자 프롬프트? 비교 자체가 안 된다.
왜 아무도 더 빨리 발견하지 못했나?
이 부분이 불편해지는 대목이다.
여러 AI 라이브러리에 기여하는 오픈소스 메인테이너: "AI 툴체인은 제가 20년간 본 어떤 생태계보다 빠르게 성장했습니다. '흥미로운 연구 프로젝트'에서 '프로덕션 인프라'로 가는 데 약 18개월밖에 걸리지 않았죠. 아무도 보안 기반을 구축하려고 멈추지 않았습니다. 주말 해커톤 프로젝트에 적용하던 수준의 엄격함으로 패키지를 운영하고 있는데, 지금은 그 패키지들이 기업 데이터를 다루고 있습니다."
이해가 된다. 나는 초기 LangChain 시절부터 AI Python 생태계를 지켜봐 왔는데, 그 속도는 경이로울 정도다. 매일 새로운 패키지가 등장한다. 의존성 트리는 깊고 대부분 감사되지 않는다. 내가 아는 대부분의 AI 엔지니어는 ML 전문가이지 보안 엔지니어가 아니다. 그들이 패키지를 설치하는 방식은 내가 20대 때 주유소 초밥을 먹던 방식과 같다 — 빠르게, 생각 없이, 그리고 후유증은 나중에 나타난다.
팀이 지금 당장 해야 할 일은?
보안 중심 개발자 여러 명과의 대화에서 도출한 즉각적인 조치 사항:
1. 버전을 고정하라. requirements에 litellm>=1.0으로 쓰고 있다면, 다음에 일어날 일은 자업자득이다. 정확한 버전으로 고정하라. 항상.
2. 설치된 버전을 감사하라. LiteLLM이 배포된 모든 머신, 컨테이너, 환경에서 pip show litellm을 실행하라. 알려진 정상 릴리스의 해시와 비교하라.
3. API 키를 교체하라. 감염된 버전을 실행했을 가능성이 조금이라도 있다면, 키가 유출되었다고 가정하라. 전부 교체하라 — OpenAI, Anthropic, Azure, 전부 다.
4. 로그를 확인하라. LiteLLM을 실행하는 서비스에서 비정상적인 아웃바운드 네트워크 연결이 있었는지 확인하라. 백도어는 데이터를 어딘가로 보내야 했다.
5. 프록시 아키텍처를 재고하라. 어쩌면, 정말 어쩌면, 모든 LLM 트래픽을 소규모 팀이 유지보수하는 서드파티 오픈소스 패키지를 통해 라우팅하는 것이 가장 방어하기 좋은 아키텍처 선택은 아니었을 수 있다.
AI 생태계가 계속 외면하는 의존성 위기
솔직하게 내 의견을 말하겠다: AI 개발 생태계는 JavaScript의 left-pad 시대가 우습게 보일 정도의 의존성 문제를 안고 있다.
2016년, 한 개발자가 11줄짜리 npm 패키지를 비공개로 전환해서 인터넷의 절반을 망가뜨렸다. 2026년, 단 하나의 감염된 AI 미들웨어 패키지가 월 수천 달러 가치의 API 키를 유출하고 추론 파이프라인을 흐르는 독점 데이터를 가로챌 수 있다.
차이점? 폭발 반경이 이제 깨진 빌드가 아니라 달러와 데이터로 측정된다.
나는 15년간 오픈소스 코드를 작성해 왔다. 다른 사람들이 의존하는 패키지를 유지보수해 본 적도 있다. 그 실이 얼마나 가느다란지 안다. 대부분의 핵심 오픈소스 패키지는 한두 명이, 대개 여가 시간에, 대개 번아웃 상태로 유지보수한다. LiteLLM은 뒤에 BerriAI라는 회사가 있어서 대부분보다는 낫다. 그래도 당했다.
AI 생태계의 의존성 그래프는 안 좋은 날을 보내는 누군가가 그린 스파게티 접시처럼 생겼다. LangChain은 모든 것을 끌어들인다. LlamaIndex도 모든 것을 끌어들인다. LiteLLM은 의존성의 의존성의 의존성이다. 자신이 LiteLLM을 실행하고 있는지조차 모를 수 있다.
전조이지 이례적인 사건이 아니다
LiteLLM에 대한 공급망 공격은 일회성이 아니다. 전조다. AI 워크로드가 프로덕션 깊숙이 침투할수록, 추론 경로에 있는 패키지들은 점점 더 매력적인 표적이 된다. 프론티어 모델의 API 키는 가치가 있다. 훈련 데이터와 독점 프롬프트는 가치가 있다. 비즈니스 로직이 담긴 모델 응답은 가치가 있다.
우리는 AI 인프라 의존성을 데이터베이스 드라이버나 인증 라이브러리를 다루듯 — 극도의 주의, 최소한의 신뢰, 그리고 진정한 보안 검토와 함께 — 다루기 시작해야 한다.
아니면 지금 하던 대로 계속할 수도 있다: 인기 있는 패키지를 설치하고, 프로덕션에 배포하고, DMCA 요청에 응하지 않는 관할권의 서버로 향하는 아웃바운드 연결을 아무도 눈치채지 않기를 바라는 것이다.
자신의 노출 여부를 확인하라
Python AI 프로젝트가 있는 디렉토리에서 다음을 실행하라:
bash
pip list | grep litellm
pip show litellm | grep -i version
pip hash litellm
그런 다음 LiteLLM GitHub 리포지토리의 알려진 정상 해시와 비교하라. 일치하지 않는다면, 매우 흥미로운 오후를 보내게 될 것이다.
더불어 이것도 실행하라:
bash
pipdeptree -r -p litellm
이 명령은 여러분의 환경에서 LiteLLM에 의존하는 모든 것을 보여준다. 놀랄 수도 있다.
Cargo(패키지 매니저가 아니라 내 골든 리트리버)가 방금 내가 오버한다는 듯이 쳐다봤다. 아니다. 이것이 새로운 일상이고, 우리가 직접 만든 것이다 — pip install 한 번에 하나씩.