[속보] LiteLLM 파이썬 패키지, 공급망 공격으로 침해돼

한 커뮤니티 멤버가 GitHub 이슈를 등록했다. 이번 보안 침해가 수면 위로 드러난 건 그렇게 시작됐다.

SAST 스캐너가 아니다. 의존성 감사 봇도 아니다. SOC에서 윙윙거리며 돌아가는 ML 기반 이상 탐지기도 아니다. 한 사람이 코드를 읽고, 뭔가 이상한 걸 발견하고, 손을 든 것이다. 이것이 2026년 3월 현재, 파이썬 AI 생태계의 공급망 보안 현주소다.

파이썬 패키지 LiteLLM — 개발자들이 여러 대형 언어 모델 제공업체로 요청을 라우팅할 수 있게 해주는 널리 채택된 프록시 레이어 — 이 공급망 공격을 당했다. 이 공격은 BerriAI/litellm 저장소의 GitHub Issue #24512를 통해 신고되었으며, 수 시간 만에 Hacker News에서 343포인트까지 치솟은 뒤 Google Trends에까지 올랐다. 이 패키지는 수천 개의 AI 애플리케이션에서 핵심 인프라 역할을 하며, 개발자와 OpenAI, Anthropic, Azure 등의 제공업체 사이에 위치한다.

침해 자체도 심각하다. 하지만 이를 통해 드러난 탐지 공백은 더 심각하다.

침해의 내부: 신뢰받는 패키지에 올라탄 악성 코드

커뮤니티 기여자가 등록한 GitHub 이슈에 따르면, LiteLLM의 변조된 버전이 파이썬 패키지 인덱스(PyPI)에 올라왔다. 악성 페이로드는 일상적인 업데이트처럼 보이는 것에 내장되어 있었다. 지난 몇 년간 공급망 공격을 추적해 온 사람이라면, 이 수법은 고통스러울 정도로 익숙하다: 신뢰받는 패키지에 코드를 주입하고, 신뢰 체인을 타고 프로덕션 환경까지 침투하는 것이다.

이 공격이 주목할 만한 이유는 기법이 아니라 대상이다. LiteLLM은 한 달에 다운로드 수가 열두 번 남짓한 무명의 유틸리티 라이브러리가 아니다. AI 개발 스택의 핵심으로, LLM 제공업체 간의 차이를 추상화하는 데 사용된다. GPT-4와 Claude 사이에서 장애 조치를 해야 하거나, 비용에 따라 프롬프트를 다른 모델로 라우팅하는 애플리케이션을 구축하고 있다면, LiteLLM은 아마 후보 목록에 들어 있을 것이다. 이 패키지는 수백만 건의 다운로드를 기록해 왔다.

이는 곧 피해 범위가 단순히 "어떤 개발자의 노트북"에 그치지 않는다는 뜻이다. 프로덕션 AI 시스템이다. 엔터프라이즈 배포 환경이다. 모든 주요 LLM 제공업체의 API 키가, 누군가 방금 변조한 패키지를 통해 흘러가고 있는 것이다.

왜 모든 자동화 스캐너가 이를 놓쳤는가

이것이 보안 팀을 밤잠 못 들게 해야 할 질문이다.

마지막으로 세어보면, 공급망 보안 솔루션을 판매하는 잘 투자받은 회사가 최소 십여 곳은 된다. Sigstore가 있다. pip audit이 있다. GitHub 자체의 의존성 검토 액션이 있다. OpenSSF Scorecards가 있다. 파이썬 생태계는 특히 PyPI의 Trusted Publishers, 증명 워크플로우, 출처 검증에 투자해 왔다.

그런데도.

인간이, 인간이 하는 일을 하면서, 이 시스템들 중 어느 것이 공개적으로 경보를 울리기 전에 문제를 발견했다. 해당 GitHub 이슈를 등록한 커뮤니티 멤버는 훈장을 받아 마땅하다. 하지만 그들은 동시에 시스템적 실패를 상징한다. 핵심 AI 인프라를 보호하는 데 디지털 버전의 동네 자율방범대에 의존해서는 안 된다.

그 이유는 구조적이다. 대부분의 자동화 보안 스캐닝 도구는 이미 알려진 악성 시그니처 기반으로 작동한다. 어제의 공격을 잡는 데는 탁월하다. 하지만 정당한 메인테이너 프로세스를 통해 업로드된, 신뢰받는 패키지 안의 새로운 페이로드는 반드시 그 경보선을 넘지는 않는다. 패키지는 정상으로 보인다. 버전 넘버는 올바르게 증가한다. 메타데이터도 깨끗하다. 누군가가 실제로 diff를 읽고 — 실제로 무엇이 변경되었는지 검사할 때 — 비로소 경보가 울린다.

Hacker News 스레드의 한 댓글러가 표현했듯이, 파이썬 생태계의 보안 모델은 근본적으로 패키지 메인테이너의 선의를 전제한다. 그 전제가 깨지면, 백업 계획은 "누군가 알아차려 주길 바라는 것"이다.

AI 인프라가 이 공격을 유독 위험하게 만드는 이유

AI 도구에 대한 공급망 공격은 전통적인 소프트웨어 침해에는 없는 위험을 수반한다. 일반적인 배포 환경에서 LiteLLM이 다루는 것을 생각해 보라: 여러 LLM 제공업체의 API 키, 민감한 비즈니스 데이터가 포함될 수 있는 프롬프트 내용, 어떤 모델이 어떤 요청을 처리할지 결정하는 라우팅 로직, 그리고 비용 관리 데이터.

변조된 LiteLLM 패키지는 접촉하는 모든 API 키를 유출할 수 있다. 프롬프트를 공격자가 통제하는 엔드포인트로 은밀히 리다이렉트할 수 있다. 응답에 콘텐츠를 주입할 수 있다. 공격 표면은 단순히 서버에서의 코드 실행이 아니라 — AI 추론 파이프라인 전체다.

이것은 보안 업계가 아직 완전히 다루지 못한 위험 범주다. 우리는 수십 년간 데이터베이스, 웹 서버, 인증 시스템을 중심으로 위협 모델을 구축해 왔다. AI 미들웨어 레이어 — LiteLLM, LangChain 등의 패키지 — 는 시크릿 관리, 데이터 처리, 서드파티 API 접근의 교차점에 위치한 새로운 유형의 고가치 표적이다.

아이러니를 놓치기 어렵다: 우리는 위협을 탐지하기 위한 AI 시스템을 구축하고 있으면서, 그 시스템을 구동하는 인프라는 수년 전부터 알려진 기법으로 침해당하고 있다.

반복되는 패턴 — 다만 판돈만 높아지고 있다

파이썬 생태계는 이전에도 이 길을 걸었다. 2022년 ctx 패키지 침해 사건. 2024년 ultralytics 사건. PyPI 운영진이 끊임없이 싸우고 있는 타이포스쿼팅 캠페인들. 매번 커뮤니티의 반응은 같은 궤적을 따른다: 충격, 신속한 복구, 더 나은 도구에 대한 요구, 그리고 다음 사건이 터질 때까지 서서히 일상으로 돌아가는 것.

하지만 LiteLLM 침해는 표적 선정에 있어 한 단계 격상을 의미한다. 이전의 주요 PyPI 공격들은 범용 패키지를 노리거나 이름 혼동에 의존하는 경향이 있었다. 이번 공격은 AI API 오케스트레이션을 전담하는 패키지를 겨냥했다 — 공격자들이 이 특정 인프라를 통해 어떤 시크릿과 데이터가 흐르는지 정확히 이해하고 있었음을 시사한다.

Google에서 "litellm"의 트렌딩은 또 다른 것을 보여준다: 공급망 공격은 더 이상 보안 커뮤니티만의 뉴스가 아니다. 이제 주류다. PyPI 침해가 Google Trends에 오른다는 것은, 보안 영역 바깥의 개발자들도 주목하고 있다는 뜻이다. 올바른 이유로 주목하고 있는지는 별개의 문제다.

모두 실패한 세 겹의 탐지 레이어

정확히 무엇이 고장 났는지 구체적으로 짚어보자. "자동화 도구가 잡지 못했다"는 말은 유용하기엔 너무 모호하다.

탐지 공백은 최소 세 개의 레이어에 걸쳐 있다:

배포 시점 검증. PyPI의 Trusted Publishers 프레임워크는 상당한 개선이지만, 채택이 보편적이지 않고 모든 공격 벡터를 커버하지 않는다. 메인테이너의 자격 증명이 탈취되거나 빌드 파이프라인 자체가 변조되면, 배포된 패키지는 정당해 보이면서도 여전히 악성일 수 있다.

설치 시점 스캐닝. pip audit 같은 도구는 알려진 취약점 데이터베이스를 대조한다. 하지만 제로데이 공급망 공격은, 정의상, 아직 데이터베이스에 없다. 침해와 탐지 사이에 모든 설치가 잠재적으로 위험한 창이 열린다.

런타임 탐지. 대부분의 파이썬 애플리케이션은 설치 후 의존성의 이상 행위를 모니터링하지 않는다. 패키지가 예상치 못한 네트워크 호출을 시작하거나 필요하지 않은 환경 변수에 접근해도, 일반적으로 경보는 없다. 패키지는 애플리케이션이 가진 모든 권한으로 실행된다.

세 레이어를 동시에 폐쇄하는 것은 어렵다. 그중 하나라도 의미 있게 폐쇄하면 진전이다. 현재 파이썬 생태계는 첫 번째 레이어에서 점진적 개선을 하면서 두 번째와 세 번째 레이어는 커뮤니티가 처리해 주길 바라고 있다. LiteLLM 사건은 그 전략이 얼마나 잘 버티는지 정확히 보여준다.

이 탭을 닫기 전에 취해야 할 다섯 가지 조치

나는 이런 글을 쓸 때 구체적인 행동 목록 없이 끝내는 법이 없다. 우선순위 순으로 정리한다:

첫째, 환경을 점검하라. LiteLLM이 설치된 곳이 어디든 있다면, 알려진 정상 해시와 버전을 대조하라. 아직 하지 않았다면 의존성을 고정(pin)하라. 영향받는 버전을 실행 중이라면, LiteLLM이 접근할 수 있었던 모든 API 키를 교체하라. 모든. 단. 하나. 까지. 그래, 고통스럽다. 그래도 하라.

둘째, AI 미들웨어 스택을 감사하라. LiteLLM은 하나의 패키지지만, 이 핵심적인 위치를 차지하는 유일한 패키지는 아니다. LLM API 키를 다루거나 추론 요청을 라우팅하는 모든 패키지는 인증 라이브러리에 부여하는 것과 같은 수준의 면밀한 검토를 받아야 한다.

셋째, 잠금 파일과 해시 검증을 도입하라. 아직 정확한 버전과 해시를 고정하는 잠금 파일 없이 pip install을 실행하고 있다면, 이번 사건이 받아들일 수 없게 만들어야 할 수준의 위험을 감수하고 있는 것이다. Poetry, pip-tools, uv 모두 해시 고정 잠금 파일을 지원한다. 사용하라.

넷째, 비정상적인 아웃바운드 연결을 모니터링하라. AI 추론 서버는 알려진 LLM 제공업체 엔드포인트에만 통신해야 하며, 그 외에는 아무것도 없어야 한다. 패키지가 예상치 못한 IP로 통신을 시작하면, 어제 알았어야 할 일이다.

다섯째, 탐지 생태계에 기여하라. 전문 지식이 있다면, OpenSSF Scorecard, Phylum, Socket 같은 도구들이 이 문제를 해결하려 노력하고 있다. AI 도구 환경을 이해하는 기여자가 필요하다.

인간 의존적 보안에 대한 불편한 진실

10년간 시스템에 침투해 온 경험이 가르쳐 준 한 가지, 결코 변하지 않는 진실이 있다: 보안은 기술이라는 옷을 입은 인간의 문제다. 더 나은 스캐너, 더 나은 증명 프레임워크, 더 나은 출처 검증 도구를 만들 수 있고, 만들어야 한다. 하지만 LiteLLM 침해는 한 사람이 주의를 기울이고 있었기에 발견되었다. 이는 안심이 되면서 동시에 무섭다.

안심되는 이유는, 오픈소스 커뮤니티의 면역 체계가 아직 작동하기 때문이다. 무서운 이유는, 그날 마침 휴가를 갔을 수도 있는 자원봉사자의 노동에 의존하기 때문이다.

파이썬 생태계는 — 그리고 그 위에 구축된 AI 인프라는 — 누군가가 우연히 적절한 시점에 적절한 diff를 읽는 것에 좌우되지 않는 탐지 역량이 필요하다. LiteLLM 사건은 화재 경보다. 문제는 6개월 후에도 그 경보음을 기억할 것인지, 아니면 늘 하던 대로 할 것인지다: 패치하고, 사후 분석하고, 다음 사건을 기다리는 것.

내 돈은 후자에 건다. 틀렸으면 좋겠다.