소프트웨어 개발자에게 오픈소스는 공기와 같다. 필요할 때 손쉽게 가져다 쓸 수 있지만, 그 안전에 대해서는 거의 생각하지 않는다. 마치 매일 마시는 물이 어디서 왔는지, 어떤 과정을 거쳐 정화되었는지 궁금해하지 않는 것과 비슷하다. LiteLLM의 보안 취약점 공격 사건은 이런 무심함에 대한 경고다. 이 사건이 특별한 이유는 공격자가 시스템을 뚫은 방식이 아니라, 그 과정에서 드러난 개발 생태계의 본질적 취약성에 있다.
공격자는 단순한 사회공학적 기법으로 시작했지만, 그 실체는 훨씬 더 복잡했다. 그들은 PyPI에 악성 패키지를 업로드하고, GitHub의 이슈 트래커를 악용했으며, 심지어 LiteLLM의 CI/CD 파이프라인까지 침투했다. 이 과정에서 주목할 점은 공격자가 직접적인 코드 조작보다 시스템의 신뢰 구조를 악용했다는 사실이다. 개발자들은 서로의 코드를 믿는다. 패키지 관리자는 의존성 트리를 신뢰하고, CI/CD 시스템은 빌드 과정을 신뢰한다. 이 신뢰의 사슬이 한번 깨지면 그 피해는 상상 이상으로 확산된다.
개발자가 코드를 작성하는 시간보다 의존성을 관리하는 시간이 더 많아졌다. 이 의존성들이 어디에서 왔는지, 누가 만들었는지 알 수 있는 방법은 거의 없다.
LiteLLM 사건은 오픈소스 생태계의 딜레마를 여실히 보여준다. 누구나 기여할 수 있다는 개방성은 혁신의 원동력이지만, 동시에 보안의 악몽이기도 하다. 이 사건에서 공격자는 오픈소스의 투명성을 역이용했다. 코드가 공개되어 있으니 취약점을 분석하기 쉽고, 기여 과정이 개방되어 있으니 악성 코드를 주입하기도 용이하다. 문제는 이런 공격이 점점 더 정교해지고 있다는 점이다. 과거에는 단순한 악성 패키지 업로드가 주를 이뤘다면, 이제는 개발 프로세스 전체를 대상으로 하는 공격이 등장하고 있다.
이 사건을 단순히 “또 하나의 해킹 사건”으로 치부하기에는 그 의미가 깊다. 이는 현대 소프트웨어 개발 방식에 대한 근본적 질문을 던진다. 우리는 얼마나 많은 의존성을 사용하고 있으며, 그 각각의 보안 상태를 얼마나 철저히 검증하고 있는가? CI/CD 파이프라인이 얼마나 안전한가? 심지어 우리가 매일 사용하는 개발 도구들의 보안은 어떻게 관리되고 있는가? LiteLLM 사건은 이런 질문들에 대한 답이 아직 없다는 사실을 보여준다.
더욱 우려스러운 점은 이런 공격이 점점 더 흔해지고 있다는 사실이다. 2023년 한 해 동안 PyPI에 등록된 악성 패키지는 11,000개를 넘어섰다. 이 숫자는 매년 기하급수적으로 증가하고 있다. 개발자들은 이런 위협에 대해 알고 있지만, 현실적으로 모든 의존성을 검증하는 것은 불가능에 가깝다. 결국 우리는 신뢰에 기반한 시스템에 의존할 수밖에 없는데, 그 신뢰의 기반이 점점 약해지고 있다.
이 사건은 또한 오픈소스 프로젝트의 유지보수 현실을 적나라하게 드러낸다. LiteLLM과 같은 인기 프로젝트조차도 보안 전문가가 상주하지 않는다. 대부분의 오픈소스 프로젝트는 열정적인 개인 개발자들이 여가 시간에 관리한다. 그들은 코드 리뷰, 보안 패치, 커뮤니티 관리를 모두 혼자서 해야 한다. 이런 상황에서 정교한 공격에 대응하는 것은 거의 불가능하다. 오픈소스의 성공이 오히려 그 취약성을 키우고 있는 셈이다.
그렇다면 해결책은 무엇일까? 이 문제에 대한 완벽한 답은 없다. 다만 몇 가지 방향성은 제시할 수 있다. 첫째, 의존성 관리의 자동화가 필요하다. 현재는 개발자가 수동으로 의존성을 관리하지만, 이는 실수와 누락을 유발한다. 의존성 그래프를 자동으로 분석하고 취약점을 탐지하는 도구가 더 발전해야 한다. 둘째, 오픈소스 프로젝트에 대한 지원이 강화되어야 한다. 기업들은 오픈소스를 무료로 사용하면서도 그에 대한 보상은 거의 하지 않는다. 오픈소스 프로젝트에 대한 재정적, 기술적 지원이 필요하다. 마지막으로, 개발자 교육이 중요하다. 보안은 개발자의 책임이지만, 많은 개발자들이 보안에 대해 충분한 지식을 갖고 있지 않다.
LiteLLM 사건은 단순한 해킹 사건이 아니다. 이는 현대 소프트웨어 개발 방식에 대한 경고이자, 오픈소스 생태계의 근본적 한계를 드러낸 사건이다. 기술이 발전할수록 그 복잡성은 증가하고, 그에 따른 취약점도 늘어난다. 우리는 이 복잡성을 관리하는 방법을 찾아야 한다. 그렇지 않으면 다음 LiteLLM은 우리 자신의 프로젝트가 될지도 모른다.
이 사건의 전말은 여기에서 자세히 확인할 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
