몇 년 전, 한 도시의 지하철 공사 현장에서 일어난 사고가 있었다. 공사가 한창이던 터널이 갑자기 무너져내렸고, 조사 결과 부실 자재가 원인으로 밝혀졌다. 문제는 그 자재가 하청업체를 거쳐 하청업체의 하청업체에서 납품된 것이었다. 최종 책임자는 누구였을까? 건설사는 물론이고, 감리 업체도, 심지어 발주처까지 모두가 ‘알 수 없는 어딘가’에서 발생한 문제를 떠안아야 했다. 소프트웨어 개발에서도 비슷한 일이 벌어지고 있다. 이번에 LiteLLM 패키지 침해 사건은 그런 불안한 현실을 다시 한번 상기시킨다.
공급망 공격(supply chain attack)이라는 단어는 이제 낯설지 않다. 하지만 이번 사건은 그 무게감을 새삼 느끼게 한다. LiteLLM은 대규모 언어 모델(LLM)을 통합하는 데 널리 사용되는 파이썬 패키지다. 개발자들은 이 라이브러리를 통해 다양한 LLM API를 일관된 인터페이스로 사용할 수 있다. 그런데 누군가가 그 패키지에 악성 코드를 심었고, 그 결과 AWS 자격 증명, 암호화폐 지갑 키, 환경 변수 등 민감한 정보가 유출될 뻔했다. 문제는 이 패키지가 PyPI에 올라와 있었다는 점이다. PyPI는 파이썬 생태계의 핵심 인프라 중 하나로, 매일 수만 명의 개발자가 이곳에서 패키지를 내려받는다. 그 중 일부는 CI/CD 파이프라인에 자동으로 통합되어, 마치 도시의 혈관처럼 소프트웨어의 전신에 퍼져나간다.
이번 사건에서 주목할 점은 공격의 정교함이다. LiteLLM의 특정 버전(1.82.7, 1.82.8)에만 악성 코드가 삽입되었고, 그 코드는 설치 시점에만 동작하도록 설계되었다. 이는 공격자가 단순히 무차별적으로 해를 입히려는 것이 아니라, 특정 환경에서만 은밀하게 작동하도록 세심하게 계획했음을 보여준다. 또한, 공격자는 패키지의 메타데이터를 조작해 정상적인 버전으로 위장했다. 개발자들이 버전 번호만 보고 안심하고 패키지를 설치했을 때, 그 이면에서는 이미 정보가 새어나가고 있었을지도 모른다. 이런 방식은 마치 은행 강도가 은행원으로 위장해 금고를 여는 것과 다르지 않다.
소프트웨어 개발에서 의존성은 양날의 검이다. 생산성을 높여주지만, 동시에 보이지 않는 위험을 끌어안게 만든다.
이 사건은 개발자들에게 몇 가지 중요한 질문을 던진다. 첫째, 우리는 얼마나 많은 패키지에 ‘맹목적으로’ 의존하고 있는가? 현대 소프트웨어 개발에서 서드파티 라이브러리는 필수불가결하다. 하지만 그 라이브러리들이 어디서 왔는지, 누가 만들었는지, 얼마나 안전한지는 종종 간과된다. npm, PyPI, Maven 같은 패키지 저장소는 그 자체로 거대한 생태계지만, 동시에 공격자에게는 매력적인 표적이기도 하다. 둘째, 보안 검증 프로세스는 얼마나 엄격한가? 많은 조직이 CI/CD 파이프라인에 보안 검사를 통합하고 있지만, 그 검사가 정말로 효과적인지는 의문이다. 이번 사건에서처럼 악성 코드가 특정 버전에만 숨겨져 있다면, 일반적인 정적 분석으로는 발견하기 어렵다. 마지막으로, 우리는 이런 공격에 얼마나 준비되어 있는가? LiteLLM 사건은 다행히 빠르게 발견되어 피해가 최소화되었지만, 다음 공격은 더 은밀하고 치명적일 수 있다.
이 문제를 해결하기 위한 노력은 이미 진행되고 있다. Sigstore 프로젝트처럼 패키지의 출처와 무결성을 검증하는 도구가 등장했고, SBOM(Software Bill of Materials)처럼 소프트웨어 구성 요소를 투명하게 관리하려는 시도도 있다. 하지만 이런 기술적 해결책만으로는 부족하다. 근본적으로는 개발 문화의 변화가 필요하다. ‘빨리빨리’ 개발하는 문화에서 벗어나, 의존성의 위험을 인식하고 신중하게 선택하는 태도가 필요하다. 또한, 오픈소스 생태계의 지속 가능성도 고민해야 한다. 많은 핵심 패키지가 소수의 개발자에 의해 유지되고 있는데, 그들의 노력에 대한 지원과 보상이 부족하다. LiteLLM 사건은 그런 취약한 지점을 공격한 사례다.
이번 사건은 단순한 해킹 사고가 아니다. 그것은 현대 소프트웨어 개발의 구조적 취약성을 드러내는 상징적인 사건이다. 우리는 이제 ‘의존성’이라는 이름으로 수많은 위험을 끌어안고 살아간다. 그 위험을 외면하지 않고, 어떻게 안전하게 관리할 것인지는 앞으로도 계속된 숙제가 될 것이다. 마치 도시의 지하철이 안전하게 운행되기 위해선 보이지 않는 곳까지 철저히 관리해야 하듯이, 소프트웨어 생태계도 그늘진 곳까지 신경 써야 한다. 그렇지 않으면, 어느 날 갑자기 터널이 무너져내리는 것처럼, 우리의 시스템도 예기치 못한 곳에서 붕괴할지 모른다.
이번 사건에 대한 자세한 내용은 BleepingComputer의 원문에서 확인할 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
