LiteLLM에 악성코드가 심어졌다 — 한 개발자의 실시간 대응 기록

무슨 일이 있었나요?

LLM 프록시 도구로 널리 쓰이는 오픈소스 프로젝트 LiteLLM에 악성코드가 삽입되는 공급망 공격(supply chain attack)이 발생했어요. LiteLLM이 뭐냐면, OpenAI·Anthropic·Gemini 같은 다양한 LLM API를 하나의 통합 인터페이스로 묶어주는 도구인데요, 스타트업부터 중견 기업까지 꽤 많은 팀이 프로덕션 환경에서 쓰고 있는 프로젝트거든요.

이번 사건을 직접 겪고 분 단위로 대응 과정을 기록한 글이 공개됐는데, 보안 사고가 실제로 터졌을 때 어떻게 움직여야 하는지를 생생하게 보여주고 있어서 같이 살펴보려 해요.

공격은 어떻게 이뤄졌나

공급망 공격이라는 건 쉽게 말하면, 우리가 믿고 설치하는 패키지 자체에 누군가 몰래 나쁜 코드를 끼워 넣는 거예요. 이번 경우엔 LiteLLM의 PyPI 패키지(파이썬 패키지 저장소에 올라가는 배포판)에 악성코드가 포함됐어요. 즉, pip install litellm을 실행하는 순간 악성코드가 함께 설치되는 구조였던 거죠.

이런 공격이 무서운 이유는, 개발자 입장에서는 평소 하던 대로 패키지를 업데이트했을 뿐인데 자기도 모르게 감염된다는 점이에요. 특히 LiteLLM처럼 LLM API 키를 다루는 도구라면, 공격자가 노리는 건 뻔하겠죠 — API 키 탈취예요. OpenAI나 Anthropic API 키가 유출되면 비용 폭탄은 물론이고, 해당 키로 접근 가능한 데이터까지 위험해져요.

분 단위 대응, 어떻게 움직였나

글을 쓴 개발자는 FutureSearch라는 서비스를 운영하고 있었는데, LiteLLM을 프로덕션에서 사용하고 있었어요. 이 분의 대응 타임라인을 보면 몇 가지 핵심 포인트가 눈에 띄어요.

첫째, 이상 징후 감지예요. 모니터링 시스템에서 평소와 다른 네트워크 요청이 감지되면서 조사가 시작됐어요. 여기서 중요한 건, 이런 걸 잡아낼 수 있는 모니터링이 이미 갖춰져 있었다는 점이에요. 아무런 관찰 체계가 없었다면 한참 뒤에야 알아챘을 거예요.

둘째, 빠른 격리 조치예요. 감염이 의심되는 순간 해당 서비스를 즉시 격리하고, 관련된 모든 API 키를 로테이션(재발급)했어요. "일단 확인해보고 조치하자"가 아니라 "일단 막고 보자"로 간 거죠. 보안 사고에서는 이 판단 순서가 정말 중요해요.

셋째, 영향 범위 파악이에요. 어떤 시스템이 해당 패키지에 의존하고 있는지, 어떤 버전이 설치돼 있는지를 빠르게 확인했어요. 의존성 목록을 lock 파일로 관리하고 있었기 때문에 이 과정이 수월했다고 해요.

공급망 공격, 왜 점점 늘어나고 있을까

이번 사건은 단독 사건이 아니에요. 최근 몇 년간 공급망 공격은 눈에 띄게 증가하고 있거든요. 2024년에는 XZ Utils라는 리눅스 핵심 압축 도구에 백도어가 발견돼서 오픈소스 생태계 전체가 충격을 받았고, npm이나 PyPI에서 타이포스쿼팅(비슷한 이름의 악성 패키지 등록) 공격도 매달 발견되고 있어요.

특히 AI/LLM 생태계는 공격자에게 매력적인 타겟이 될 수밖에 없어요. 이유가 몇 가지 있는데요:

• 고가의 API 키: GPT-4나 Claude 같은 모델의 API 키는 곧 돈이에요. 탈취하면 바로 수익화가 가능하죠.
• 빠르게 성장하는 생태계: 새로운 도구가 쏟아져 나오는 만큼, 보안 검증이 충분히 이뤄지지 않은 패키지도 많아요.
• 프로덕션 진입 속도: "일단 돌아가게 하자"는 마인드로 검증 없이 바로 프로덕션에 넣는 경우가 적지 않고요.

비슷한 LLM 프록시 도구로는 OpenRouter, PortKey, Helicone 같은 것들이 있는데, 이 도구들 역시 같은 종류의 위험에 노출될 수 있어요. 중요한 건 특정 도구의 문제가 아니라, 의존성 관리 자체를 어떻게 하느냐의 문제라는 거예요.

한국 개발자가 챙겨야 할 것들

국내에서도 LiteLLM을 쓰는 팀이 꽤 있어요. LLM 기반 서비스를 개발하는 스타트업이나, 사내 AI 도구를 만드는 팀에서 많이 채택하고 있거든요. 당장 확인해볼 것들을 정리하면 이래요.

버전 확인부터 하세요. 현재 설치된 LiteLLM 버전이 영향받는 범위에 포함되는지 확인하고, 영향받는 버전이라면 즉시 업데이트하거나 제거해야 해요. pip show litellm으로 버전을 확인할 수 있어요.

API 키 로테이션은 선택이 아니에요. 조금이라도 의심된다면 OpenAI, Anthropic, Google 등 모든 LLM 서비스의 API 키를 새로 발급받으세요. 기존 키는 즉시 비활성화하고요.

의존성 고정(pinning)을 습관화하세요. requirements.txt에 litellm>=1.0처럼 범위를 넓게 잡으면 자동으로 악성 버전이 설치될 수 있어요. 정확한 버전을 고정하고, 업데이트는 의도적으로 하는 게 안전해요.

모니터링을 붙이세요. 외부로 나가는 네트워크 요청을 관찰할 수 있는 최소한의 장치는 있어야 해요. 이번 사건에서도 결국 이상 네트워크 트래픽을 감지한 게 첫 단서였거든요.

마무리

핵심은 이거예요: 오픈소스를 쓴다는 건 그 프로젝트의 보안 상태까지 함께 가져가는 거예요. 편리함의 이면에는 항상 신뢰 비용이 있고, 그 비용을 관리하는 게 현대 개발자의 필수 역량이 되고 있어요.

여러분 팀에서는 의존성 보안을 어떻게 관리하고 계신가요? lock 파일 관리, 자동 취약점 스캔, 혹은 아예 외부 패키지를 최소화하는 전략 — 어떤 방식을 쓰고 계신지 궁금해요.

---

🔗 출처: Hacker News