LiteLLM 패키지가 공급망 공격에 뚫렸습니다 — 내 프로젝트는 괜찮을까?

무슨 일이 있었나요?

LLM(대규모 언어 모델) 프록시 도구로 많이 쓰이는 Python 패키지 LiteLLM이 공급망 공격(supply-chain attack)에 노출된 사실이 확인됐어요. 공급망 공격이 뭐냐면, 우리가 평소에 pip install로 설치하는 패키지 자체에 악성 코드가 심어지는 공격이에요. 개발자 입장에선 평소처럼 패키지를 설치했을 뿐인데, 그 안에 나쁜 코드가 숨어 있는 거죠.

LiteLLM은 OpenAI, Anthropic, Cohere, Azure 등 다양한 LLM API를 하나의 통합 인터페이스로 호출할 수 있게 해주는 라이브러리인데요. AI 서비스를 운영하는 스타트업이나 사이드 프로젝트에서 꽤 많이 쓰이고 있어서, 이번 사건의 영향 범위가 적지 않을 수 있어요.

구체적으로 어떤 일이 벌어졌나

GitHub 이슈에 보고된 내용에 따르면, PyPI(Python Package Index)에 올라간 LiteLLM 패키지의 특정 버전에 원래 소스 코드에는 없는 악성 코드가 포함되어 배포됐어요. 이게 뭘 의미하냐면, GitHub에 있는 공식 소스 코드와 실제로 PyPI를 통해 배포된 패키지의 내용이 달랐다는 거예요.

공급망 공격은 보통 이런 식으로 일어나요. 패키지 메인테이너의 PyPI 계정이 탈취되거나, CI/CD 빌드 파이프라인이 침해되거나, 아니면 의존성 중 하나가 오염되는 경우인데요. 이번 LiteLLM 건에서는 패키지 배포 과정 어딘가에서 코드가 변조된 것으로 보여요.

특히 위험한 점은, LiteLLM이 API 키를 다루는 라이브러리라는 거예요. OpenAI API 키, Azure 키, AWS 자격증명 같은 민감한 정보가 이 라이브러리를 통해 흐르거든요. 만약 악성 코드가 이런 자격증명을 외부로 유출하도록 설계됐다면, 상당한 보안 사고로 이어질 수 있어요.

공급망 공격, 왜 이렇게 무서운 건가요

공급망 공격이 일반적인 해킹과 다른 점은 신뢰의 사슬을 공격한다는 거예요. 우리가 pip install litellm을 실행할 때, "이 패키지는 공식 저장소에서 배포됐으니 안전하겠지"라고 암묵적으로 신뢰하잖아요. 공급망 공격은 바로 그 신뢰를 악용하는 거예요.

최근 몇 년간 이런 공격이 크게 늘었어요. 2024년의 xz-utils 백도어 사건이 대표적인데, 리눅스 배포판 대부분에 포함된 압축 유틸리티에 백도어가 심어졌던 적이 있어요. Node.js 생태계에서는 event-stream 사건이 유명하고요. Python 생태계에서도 typosquatting(이름을 비슷하게 만든 가짜 패키지)이나 메인테이너 계정 탈취 등이 지속적으로 발생하고 있어요.

LiteLLM 같은 AI 관련 패키지가 타겟이 된 건 시사하는 바가 커요. 요즘 AI 서비스를 만드는 팀이 폭발적으로 늘면서, 이런 AI 도구 체인이 새로운 공격 표면(attack surface)이 되고 있는 거거든요.

경쟁 도구와 비교

LLM 통합 라이브러리는 LiteLLM 말고도 여러 가지가 있어요. LangChain에도 LLM 호출 기능이 있고, OpenRouter는 API 게이트웨이 방식으로 비슷한 기능을 제공해요. Portkey나 Helicone 같은 LLM 프록시 서비스도 있고요.

다만 LiteLLM의 장점은 셀프호스팅이 가능한 경량 프록시라는 점이었어요. 외부 서비스에 의존하지 않고 직접 운영할 수 있으니 보안 면에서 오히려 낫다고 생각했던 팀도 많았을 텐데, 이번에 패키지 자체가 공격당하면서 그 전제가 흔들린 거예요.

이 사건은 오픈소스 패키지의 보안 검증이 얼마나 중요한지를 다시 한번 보여줘요. 코드가 공개되어 있다는 것과 배포된 바이너리/패키지가 안전하다는 건 다른 문제거든요.

한국 개발자가 지금 당장 확인할 것들

첫째, 자신의 프로젝트에서 LiteLLM을 쓰고 있는지 확인하세요. pip list | grep litellm이나 requirements.txt, pyproject.toml을 확인하면 돼요. 직접 설치하지 않았더라도 다른 패키지의 의존성으로 들어왔을 수 있어요.

둘째, 설치된 버전을 확인하고 GitHub 이슈에서 영향받는 버전 정보를 체크하세요. 해당 버전이라면 즉시 안전한 버전으로 업데이트하거나, 임시로 제거하는 게 좋아요.

셋째, 더 근본적으로는 패키지 관리 보안 습관을 점검해볼 때예요. pip install로 아무 패키지나 바로 프로덕션에 넣지 말고, 버전을 고정(pinning)하고, 가능하면 해시 검증을 사용하고, Dependabot이나 Snyk 같은 보안 스캔 도구를 CI에 달아두는 게 좋아요.

그리고 AI 서비스를 운영 중이라면, API 키 로테이션도 고려해보세요. 혹시 유출됐을 수 있는 키가 있다면 새로 발급받는 게 안전해요.