믿었던 AI 도구가 백도어가 되는 순간 - LiteLLM 공급망 공격 사건으로 본 오픈소스의 이중성

25년간 금융권에서 시스템을 개발해오면서, 보안 사고는 늘 "설마 우리가?"라는 생각으로 시작된다는 걸 수없이 봐왔습니다. 그런데 최근 Mercor라는 AI 채용 스타트업이 당한 사이버 공격은 정말 소름 돋았어요. 왜냐하면 이들은 직접 뚫린 게 아니라, 믿고 사용하던 오픈소스 라이브러리 LiteLLM을 통해 감염됐거든요.

이 사건을 보면서 제가 느낀 건, AI 시대의 보안 위협이 완전히 새로운 차원으로 진화했다는 점입니다. 예전에는 우리 시스템만 잘 지키면 됐는데, 이제는 우리가 의존하는 모든 도구들이 잠재적 위험 요소가 될 수 있어요. 특히 AI 개발에 필수적인 오픈소스 라이브러리들까지 공격 대상이 되는 현실을 보니, 개발자들이 얼마나 방어적으로 사고해야 하는지 새삼 깨닫게 됩니다.

공급망 공격, 이제는 AI 도구까지 노린다

공급망 공격(Supply Chain Attack)이라는 개념 자체는 새로울 게 없어요. 2020년 SolarWinds 해킹 사건 때부터 보안 업계에서는 이미 경고해왔거든요. 하지만 이번 LiteLLM 사건은 AI 생태계 특유의 취약성을 보여준다는 점에서 더욱 심각합니다.

LiteLLM이 뭔지 모르는 분들을 위해 설명드리자면, 이건 GPT-4, Claude, Gemini 같은 여러 AI 모델을 하나의 통합된 인터페이스로 사용할 수 있게 해주는 라이브러리예요. AI 개발자 입장에서는 정말 유용한 도구죠. 각 AI 모델마다 다른 API 형식을 일일이 구현할 필요 없이, LiteLLM 하나면 모든 걸 해결할 수 있거든요.

문제는 이런 편의성이 바로 약점이 된다는 겁니다. 전 세계 수천 개의 AI 스타트업들이 LiteLLM에 의존하고 있다 보니, 공격자 입장에서는 이 라이브러리 하나만 오염시키면 엄청나게 많은 타겟을 동시에 공격할 수 있어요. 마치 댐 하나를 터뜨려서 하류의 모든 마을을 침수시키는 것과 같죠.

제가 금융권에서 일하면서 비슷한 상황을 겪어본 적이 있어요. 한때 널리 쓰이던 특정 암호화 라이브러리에서 취약점이 발견됐는데, 그때 얼마나 많은 시스템들이 일제히 패치 작업에 들어갔는지 아직도 기억나네요. AI 생태계는 오픈소스 의존도가 훨씬 높다 보니, 이런 위험이 더 클 수밖에 없습니다.

개발자의 딜레마: 편의성 vs 보안성

이번 사건을 보면서 가장 안타까운 건, Mercor의 개발팀이 잘못한 게 거의 없다는 점입니다. 그들은 검증된 오픈소스 라이브러리를 사용했고, 일반적인 보안 수칙도 잘 따랐을 거예요. 하지만 신뢰했던 도구 자체가 오염됐으니 어쩔 수 없죠.

이게 바로 현대 개발자들이 직면한 근본적인 딜레마예요. 오픈소스를 쓰지 않고서는 경쟁력 있는 소프트웨어를 만들기 어려운 시대인데, 오픈소스를 쓸수록 보안 위험은 커지거든요. 특히 AI 개발 분야는 변화 속도가 워낙 빨라서 검증이 덜 된 라이브러리들도 많이 사용하게 되죠.

저희 금융권에서는 예전부터 "Known Good Configuration"이라는 개념을 중요하게 여겨왔어요. 검증된 버전, 검증된 설정, 검증된 환경만 사용한다는 원칙이죠. 하지만 AI 스타트업들은 시장 진입 속도가 생명이다 보니, 이런 보수적인 접근법을 취하기 어려워요.

결국 개발자 개인이 더 많은 책임을 져야 하는 상황이 온 거 같아요. 라이브러리 하나를 선택할 때도 기능성뿐만 아니라 보안 이력, 관리 상태, 커뮤니티 활성도까지 종합적으로 평가해야 하죠. 20년 전에는 상상도 못했던 복잡성입니다.

실무에서 써먹을 수 있는 방어 전략

이론적인 얘기는 여기까지 하고, 실제로 어떻게 대응해야 하는지 제 경험을 바탕으로 말씀드려볼게요. 먼저 버전 고정은 정말 기본 중의 기본입니다. requirements.txt에 "litellm>=1.28.0" 이런 식으로 쓰지 마시고, "litellm==1.28.14" 처럼 정확한 버전을 명시하세요.

저는 새로운 라이브러리를 도입할 때마다 "버전 이력서"라는 걸 만들어서 관리해요. 언제 어떤 버전을 왜 사용하기 시작했는지, 업데이트할 때마다 무엇을 확인했는지 기록해두는 거죠. 나중에 문제가 생겼을 때 추적하기도 쉽고, 팀원들과 공유하기도 좋더라고요.

GitHub의 Dependabot이나 보안 알림 기능도 적극 활용하시길 권해요. 무료인데다 정말 유용합니다. 다만 알림만 받고 끝나면 안 되고, 실제로 취약점 내용을 읽어보고 우리 시스템에 미치는 영향을 분석해야 해요. 때로는 패치보다는 해당 라이브러리를 아예 다른 걸로 교체하는 게 나을 수도 있거든요.

권한 최소화는 아무리 강조해도 지나치지 않아요. LiteLLM 같은 라이브러리에는 정말 AI 모델 호출에 필요한 API 키만 주세요. 데이터베이스 접근 권한이나 결제 관련 토큰은 완전히 분리된 환경에 두는 게 좋습니다. 저는 환경변수를 여러 레벨로 나누어서, 각 레벨마다 접근 가능한 자원을 제한하는 방식을 사용해요.

AI 시대의 새로운 보안 패러다임

이번 LiteLLM 사건을 통해 느낀 건, AI 시대의 보안은 기존과는 완전히 다른 접근법이 필요하다는 점입니다. 전통적인 보안 모델은 경계 방어(Perimeter Defense)에 초점을 맞췄다면, 이제는 내부의 모든 구성 요소를 신뢰하지 않는 제로 트러스트 모델로 가야 해요.

특히 AI 라이브러리들은 일반적인 소프트웨어 라이브러리보다 더 많은 권한을 요구하는 경우가 많아요. 모델을 다운로드받고, 임시 파일을 생성하고, 네트워크를 통해 API를 호출하죠. 이런 행동들이 모두 정상적인 작동의 일부이기 때문에, 악의적인 활동과 구별하기가 더욱 어려워집니다.

앞으로는 AI 개발팀에도 전담 보안 담당자가 필요할 것 같아요. 단순히 방화벽이나 백신을 관리하는 게 아니라, 사용하는 AI 라이브러리들의 보안 상태를 지속적으로 모니터링하고, 새로운 위협에 대응하는 역할 말이에요.

또한 공급망 공격에 대비한 "재해 복구 계획"도 필요합니다. 만약 우리가 사용하는 핵심 라이브러리가 오염됐다면 어떻게 대응할지, 대체재는 있는지, 데이터 손실을 최소화하려면 어떤 절차를 밟아야 하는지 미리 준비해둬야 해요.

---

결국 이번 사건이 우리에게 던지는 메시지는 명확합니다. AI 시대의 편의성과 효율성은 분명 매력적이지만, 그만큼 새로운 위험도 따라온다는 것이죠. 개발자 한 명 한 명이 보안 전문가 수준의 경각심을 가져야 하는 시대가 온 것 같습니다.

저처럼 전통적인 금융IT 환경에서 일하던 사람들도 이제는 AI 도구들을 피할 수 없게 됐어요. 하지만 조급해하지 말고, 검증된 방식으로 천천히 도입하면서 보안 수준을 높여나가는 게 중요합니다. 혁신과 보안, 둘 다 잡을 수 있는 방법이 분명 있을 거예요.

— JINNUS.AI, 53세. 금융권 전산 25년차.