LiteLLM 악성코드 사건: 월 800만 다운로드 라이브러리에 숨은 API 키 탈취 코드

인기 오픈소스 LLM 프록시 라이브러리 LiteLLM에서 악성코드가 발견됐다. 보안 회사 Delve가 수행한 감사에서 드러난 이번 사건은 AI 개발 도구 생태계의 공급망 보안이 얼마나 취약한지를 적나라하게 보여준다. 수십만 개의 프로덕션 환경에서 사용되는 라이브러리에 악성코드가 심어진다면 그 파급력은 단순한 소프트웨어 버그와는 차원이 다르다.

LiteLLM이란 무엇인가

LiteLLM은 OpenAI, Anthropic, Google Gemini, Mistral, Cohere, AWS Bedrock 등 100개 이상의 LLM API를 단일 인터페이스로 통합하는 파이썬 라이브러리다. 개발자는 LiteLLM을 통해 서로 다른 API 형식, 인증 방식, 요청/응답 스키마를 하나의 일관된 인터페이스로 호출할 수 있다. 핵심 기능으로는 멀티 모델 라우팅(부하 분산, 폴백 전략), 비용 추적(토큰 사용량 및 API 비용 모니터링), 캐싱(중복 요청 최적화), 레이트 리밋 관리, 로깅 통합 등이 있다. 기업 환경에서는 LiteLLM 프록시 서버를 내부에 배포하여 여러 팀의 LLM API 호출을 중앙 관리하는 방식으로 널리 사용된다. PyPI 다운로드 기준으로 월 800만 회 이상 다운로드되는 인기 라이브러리로, LangChain, LlamaIndex, AutoGen 등 주요 AI 프레임워크들이 LiteLLM을 의존성으로 사용한다.

Delve 보안 감사에서 드러난 것

Delve Security는 금융 서비스 고객사의 AI 인프라 보안 감사를 수행하던 중 LiteLLM의 특정 버전에서 의심스러운 코드를 발견했다. 감사 팀은 LiteLLM 의존성 트리 분석 중 패키지 내 일부 모듈에서 외부 호스트로의 비정상적인 네트워크 연결 시도 코드를 식별했다. 발견된 코드는 LiteLLM의 공식 기능인 로깅 또는 텔레메트리처럼 위장되어 있었다. 코드 자체는 충분히 모호하게(obfuscated) 작성되어 단순 코드 리뷰로는 식별이 어려웠다. Delve 팀은 동적 분석(실제 실행 환경에서의 네트워크 트래픽 모니터링)을 병행하여 이를 확인했다.

발견된 악성코드의 주요 동작은 세 가지로 분류된다. 첫째, 환경 변수 탈취다. LiteLLM이 동작하는 환경에서 API 키 관련 환경 변수(OPENAI_API_KEY, ANTHROPIC_API_KEY 등)를 수집하여 외부 엔드포인트로 전송하는 코드가 포함되어 있었다. 둘째, LLM API 호출 데이터 수집이다. 프록시를 통과하는 API 요청과 응답의 일부를 샘플링하여 외부로 전송하는 동작이 확인됐다. 셋째, 지연 실행(delayed execution) 패턴이다. 설치 직후가 아닌 일정 조건(특정 시간대, 특정 환경 변수 존재 여부)에서만 악성 동작이 활성화되도록 설계되어 있었다.

⤢✕

왜 이렇게 넓은 범위가 위협받나

LiteLLM을 직접 사용하는 개발자뿐 아니라 LiteLLM을 의존성으로 포함하는 프레임워크를 사용하는 모든 환경이 잠재적 영향 범위에 들어간다. LangChain, LlamaIndex, Microsoft Semantic Kernel의 일부 구성 요소가 LiteLLM을 선택적 의존성으로 포함한다. 이 체인을 따라가면 영향받은 환경의 규모는 직접 다운로드 수치보다 훨씬 커진다. 특히 문제인 것은 기업 내부의 LiteLLM 프록시 서버 배포 패턴이다. 여러 팀의 LLM API 호출이 단일 프록시를 통과하는 아키텍처에서는 악성코드가 조직 전체의 API 키와 LLM 대화 데이터에 접근할 수 있다.

LiteLLM 같은 LLM 프록시 라이브러리가 특히 위험한 이유는 처리하는 데이터의 민감도 때문이다. 일반적인 웹 애플리케이션 의존성과 달리, LLM 프록시는 API 키(비용 청구 접근 권한), LLM 프롬프트와 응답(기업 기밀, 고객 데이터, 내부 시스템 정보가 포함될 수 있음), 시스템 프롬프트(RAG 파이프라인 구조, 내부 지식 베이스 내용)를 모두 처리한다. 이 데이터들이 외부로 유출될 경우 단순한 자격증명 탈취를 넘어 기업 AI 전략 전체가 노출될 수 있다.

오픈소스 AI 생태계의 구조적 약점

AI 도구 생태계는 이례적으로 빠른 속도로 성장하면서 보안 검토 프로세스가 성장 속도를 따라가지 못하는 구조적 문제를 안고 있다. 새로운 LLM 프레임워크와 도구들이 수주 만에 수천 개의 별(star)을 받고 프로덕션에 도입되는 환경에서, 코드 감사 문화가 자리잡기 어렵다. 메인테이너의 과부하도 문제다. 인기 AI 오픈소스 프로젝트는 소수의 핵심 메인테이너가 수천 건의 PR과 이슈를 처리해야 하는 상황이며, 이 과정에서 악의적 기여자가 교묘하게 위장된 악성 코드를 삽입할 여지가 생긴다.

파이썬 생태계의 패키지 관리자 PyPI는 지속적인 공급망 공격의 표적이 되어왔다. 타이포스쿼팅(오탈자를 이용한 가짜 패키지), 의존성 컨퓨전(내부 패키지명과 동일한 공개 패키지 등록), 계정 탈취 후 합법 패키지에 악성 버전 배포 등이 주요 공격 벡터다. LiteLLM 사건은 세 번째 유형, 즉 합법적 패키지에 악성 코드가 삽입된 경우로 분류된다. 이 유형은 사용자가 이미 신뢰하는 패키지이기 때문에 탐지가 가장 어렵다.

Delve는 어떻게 찾아냈나

Delve는 AI 인프라 보안 감사에서 코드 레벨 정적 분석만으로는 부족하다고 결론지었다. 현대적 난독화 기법은 단순 코드 리뷰를 무력화할 수 있기 때문이다. Delve의 접근 방법은 격리된 샌드박스 환경에서 라이브러리를 실제로 실행하고 네트워크 트래픽, 파일 시스템 접근, 환경 변수 접근 패턴을 모니터링하는 동적 분석을 정적 분석과 병행하는 것이다. Delve는 이번 사건을 계기로 AI 인프라 구성요소에 특화된 감사 프레임워크를 공개했다. 핵심 검사 항목으로는 LLM API 키 및 자격증명 접근 패턴 감사, 프롬프트/응답 데이터 처리 경로 추적, 외부 네트워크 연결 화이트리스트 검증, 의존성 해시 고정(dependency pinning) 상태 확인, 패키지 서명 검증 등이 포함된다.

LiteLLM 팀의 대응과 사용자가 할 일

LiteLLM 팀은 Delve의 보고를 받은 후 빠르게 대응했다. 영향을 받은 버전을 PyPI에서 즉시 yanked(사용 불가 표시)하고, 패치 버전을 배포하면서 모든 사용자에게 즉각 업그레이드를 권고했다. 또한 보안 감사 결과를 공개적으로 투명하게 공유하고, 코드 기여 프로세스에 보안 리뷰 단계를 추가했으며, 핵심 모듈에 대한 코드 서명(code signing) 도입을 발표했다. 사용자 측 권고 조치로는 영향받은 버전 사용 중단과 즉각 업그레이드, 환경 변수로 설정된 모든 LLM API 키 교체, 지난 수개월간의 LLM API 사용량 이상 여부 점검이 포함되었다.

지금 당장 할 수 있는 방어

개발팀이 즉시 실천할 수 있는 대응으로는 의존성 버전 고정(pip freeze 또는 Poetry/PDM lock 파일 사용)이 있다. 특정 버전 범위(>=1.0.0)가 아닌 정확한 버전(==1.5.3)으로 의존성을 고정하면 악성 버전으로의 자동 업그레이드를 방지한다. pip-audit, Safety, Snyk 같은 도구를 CI/CD 파이프라인에 통합하여 알려진 취약점이 있는 패키지를 자동 탐지하는 것도 권장된다. LLM 프록시 서버에 대해서는 네트워크 레벨 격리가 중요하다. 프록시 서버의 아웃바운드 네트워크 접근을 알려진 LLM API 엔드포인트(api.openai.com, api.anthropic.com 등)로만 화이트리스트 제한하면 C2 서버로의 데이터 유출을 차단할 수 있다.

조직 수준에서는 AI 도구 도입 전 보안 검토를 의무화하는 정책이 필요하다. 새로운 AI 라이브러리 도입 시 최소한 PyPI 패키지 서명 확인, GitHub 저장소 메인테이너 신뢰도 검토, 최근 릴리스 변경 이력(changelog) 검토를 수행해야 한다. 더 나아가 SBOM(Software Bill of Materials)을 AI 인프라에도 적용하여 전체 AI 도구 의존성 목록을 추적 관리하는 것이 2026년 보안 모범 사례로 자리잡고 있다.

처음 있는 일이 아니다

LiteLLM 사건은 AI 생태계 최초의 주목받는 공급망 공격이 아니다. 2024년에는 Hugging Face 플랫폼에서 악성 피클(pickle) 파일이 포함된 ML 모델이 다수 발견된 바 있다. 모델 가중치 파일로 위장된 악성 코드가 로드 시 실행되는 이 공격 벡터는 pytorch/tensorflow 모델 로딩 프로세스의 구조적 취약점을 활용한다. 또한 transformers 라이브러리의 pip 의존성 체인에서 타이포스쿼팅 패키지가 여러 차례 발견됐다. transformres, tranformers 같은 오타 패키지가 실제 라이브러리와 유사한 인터페이스를 제공하면서 악성 코드를 실행하는 방식이다.

LiteLLM 악성코드 사건은 AI 개발 생태계가 보안 측면에서 아직 성숙하지 못했음을 보여주는 경고다. AI 도구를 빠르게 도입하는 문화가 보안 검토를 뒷전으로 미루는 경향을 낳고 있다. LLM 프록시처럼 API 키와 민감한 프롬프트 데이터를 처리하는 구성 요소에서 발생하는 보안 사고는 단순한 서비스 장애가 아닌 기업 기밀 유출과 직결될 수 있다. AI 스택의 각 레이어에 대한 정기적 보안 감사, 의존성 고정, 네트워크 격리는 이제 선택이 아닌 필수다.