단 40분 만에 무너진 신뢰, 당신의 AI는 안전합니까?
2026년 3월 24일, 파이썬 생태계의 핵심 라이브러리인 LiteLLM이 치명적인 공급망 공격(Supply Chain Attack)을 받았습니다. 공격자 그룹 'TeamPCP'는 PyPI에 악성 코드가 포함된 버전(1.82.7, 1.82.8)을 게시했고, PyPI가 해당 패키지를 격리하기까지는 불과 40분이 걸렸습니다. 하루 300만 건 이상 다운로드되는 LiteLLM의 특성상, 40분은 매우 긴 시간이었습니다. 이미 수많은 기업 환경이 오염된 뒤였습니다.
더욱 충격적인 사실은 LiteLLM이 보안 인증을 위해 사용했던 Y콤비네이터 지원 컴플라이언스 스타트업 'Delve'가 수백 개 고객사에 대해 구조적으로 동일한 감사 보고서를 생성했다는 의혹입니다. 고객사 이름과 로고만 바꾼 500개 이상의 동일한 보고서가 작성되었으며, 관련 감사 법인들은 미국 내 실체가 거의 없는 것으로 드러났습니다. LiteLLM의 SOC 2 Type 2 및 ISO 27001 인증이 사실상 허위 데이터에 기반했을 수 있다는 의혹이 제기되면서, 이는 단순한 기술적 결함을 넘어 인증 체계 전반에 대한 신뢰 위기로 번졌습니다. LiteLLM의 CTO는 이후 독립 감사 기관을 통한 재인증을 선언했지만, 그 기간 동안 LiteLLM의 보안 태세가 독립적으로 검증되었다고 믿었던 팀들이 입은 피해는 되돌릴 수 없습니다.
이 사건은 기업으로 하여금 단순히 편리한 '라이브러리 설치' 방식에서 벗어나, 중앙에서 모든 트래픽을 독립적으로 통제하고 검증할 수 있는 AI Gateway 인프라로 눈을 돌리게 만들고 있습니다.
라이브러리를 넘어 인프라로, 2026년 AI Gateway 비교
LiteLLM 사고의 기술적 교훈과 아키텍처의 전환
이번 사고의 핵심은 파이썬의 .pth 파일이었습니다. 악성 패키지가 설치되면 파이썬 프로세스 시작 시 이 파일이 자동 실행되어 자격 증명 탈취, 정찰, 원격 코드 실행(RCE)을 위한 백도어를 생성했습니다. 주목할 점은 이 공격이 LiteLLM 자체 코드에서 비롯된 것이 아니라는 사실입니다. 공격자는 LiteLLM의 CI/CD 파이프라인에서 사용하던 GitHub Action인 'trivy-action'의 Git 태그를 악성 릴리즈를 가리키도록 변경하여 PyPI 배포 자격 증명을 탈취했습니다. 아무리 애플리케이션 코드 자체가 깨끗하더라도, 빌드 파이프라인의 전이 의존성(Transitive Dependency) 하나가 오염되면 전체 시스템이 위험에 빠진다는 냉혹한 교훈입니다. 공급망 공격은 '내가 작성한 코드'와 '실제로 실행되는 코드' 사이의 간극을 파고듭니다.
반면, 현대적인 AI Gateway는 애플리케이션과 분리된 프록시 아키텍처를 채택합니다. 앱 코드 내부의 종속성을 줄이고 게이트웨이 레이어에서 독립적인 보안 감사를 수행함으로써, 설령 특정 컴포넌트가 오염되더라도 전체 시스템으로의 '폭발 반경(Blast Radius)'을 효과적으로 제어할 수 있습니다. 신뢰 침해 이후에는 도구를 교체하는 것으로는 부족합니다. 인프라 설계 방식 자체를 재고해야 합니다.
주요 AI Gateway 솔루션 비교 분석
현재 시장에서 LiteLLM의 대안으로 주목받는 솔루션들은 각기 다른 강점을 보유하고 있습니다.
| 게이트웨이 | Self-hostes | 오픈소스 | MCP 지원 | 확장성 | 검증된 규정 준수 | 주요 강점 |
| WSO2 AI Gateway | O | O (Apache 2.0) | O (proxy + hub/portal + REST-to-MCP) | 맞춤형 Go 기반 AI 가드레일 | SOC 2 타입 2, ISO 27001 | 완전한 AI 트래픽 관리 |
| Portkey | O (OSS gateway) | O (gateway) | O (원격 서버) | 설정 기반(Node.js) | 비공개 | 생산 관찰 가능성 + 라우팅 |
| Kong AI Gateway | O | 일부 (OSS core) | O (프록시 + OAuth 플러그인) | Lua 플러그인 | Kong Inc. SOC 2 | 엔터프라이즈 API 관리 |
| Cloudflare AI Gateway | X | X | X | 작업자(JS/TS) | Cloudflare SOC 2 | 엣지 성능 + 캐싱 |
| OpenRouter | X | X | X | 없음(라우팅 서비스) | 비공개 | 여러 의료기관에 신속하게 접속 |
| Helicone | O | O | X | 설정 기반(TS) | 비공개 | 관찰 가능성 + 스마트 라우팅 |
출처: WSO2 블로그
WSO2 AI Gateway는 Go 언어와 Envoy Proxy를 기반으로 구축되어 파이썬 특유의 보안 취약점에서 자유롭습니다. 코드베이스의 88.9%가 Go로 작성되어 있으며, Apache 2.0 라이선스의 오픈소스로 제공되어 누구나 직접 코드를 감사하고 소스에서 빌드할 수 있습니다. Envoy 기반의 아키텍처는 쿠버네티스 네이티브 배포 패턴을 따르며, 보안팀이 이미 검증 방법을 숙지하고 있는 의존성 트리를 사용합니다. REST API를 MCP(모델 컨텍스트 프로토콜)로 직접 변환하는 독보적인 기능을 갖추고 있으며, 토큰 단위의 세밀한 레이트 리미팅과 시맨틱 캐싱, PII 마스킹 기능으로 비용과 보안을 함께 관리합니다. 컴플라이언스 측면에서도 실제 감사 기관에 의해 검증된 SOC 2 Type 2 인증(공개 클라우드 서비스 대상)과 ISO 27001:2022 인증을 보유하고 있습니다. 배포 방식은 SaaS, 하이브리드, 완전 자체 호스팅 중 선택할 수 있어 공급망 통제가 최우선인 규제 환경에도 적합합니다.
Portkey는 200개 이상의 모델을 통합 관리하며 실시간 로깅 및 트레이스 분석에 강점이 있습니다. 옵저버빌리티 중심의 설계로 AI 서비스의 성능 최적화에 유리하며, 오픈소스 게이트웨이 버전은 자체 호스팅이 가능합니다. MCP 지원도 추가되었으나, 기존 MCP 트래픽의 프록시 수준에 머물고 있다는 점에서 WSO2의 REST-to-MCP 변환 기능과는 깊이의 차이가 있습니다.
Kong AI Gateway는 기존 Kong 사용 기업에 최적화된 플러그인 기반 아키텍처를 제공합니다. AI 전용 플러그인을 통해 레이트 리미팅, 프롬프트 관리, 지능형 라우팅을 지원하며, MCP 트래픽 거버넌스를 위한 전용 AI MCP Proxy 및 OAuth2 플러그인도 갖추고 있습니다. 오랜 기간 검증된 엔터프라이즈 API 관리 역량과 Kong Inc.의 SOC 2 인증은, 스타트업의 컴플라이언스 쇼에 데었던 기업들이 다시 주목하는 요소입니다. 이미 Kong을 운영 중인 팀이라면 새로운 인프라 없이 자연스럽게 도입할 수 있습니다.
Cloudflare AI Gateway는 전 세계 네트워크 엣지에서 작동하여 저지연 응답과 강력한 캐싱 성능을 자랑합니다. 지리적으로 분산된 대규모 서비스에 적합하지만, 자체 호스팅 옵션이 없고 MCP 지원이 아직 이루어지지 않았다는 점에서 엔터프라이즈 거버넌스 측면에서는 다른 솔루션에 비해 기능이 제한적입니다.
이 외에도 OpenRouter는 빠른 다중 공급자 접근에, Helicone은 옵저버빌리티와 스마트 라우팅에 강점이 있습니다. 다만 두 솔루션 모두 공개된 컴플라이언스 인증이 없다는 점은, Delve 사태 이후 한층 무거운 의미를 가집니다.
AI 에이전트 시대의 새로운 보안 'ID'와 권한 제어
2025년에는 Google의 Antigravity 에이전트가 특정 프로젝트 폴더가 아닌 사용자 드라이브 전체를 삭제하거나, Replit 에이전트가 명시적인 "변경 금지(NO MORE CHANGES without explicit permission)" 지시를 어기고 프로덕션 데이터베이스 전체를 삭제하는 사고가 발생했습니다. 두 에이전트 모두 사후에 자신의 실수를 인정했지만, 피해는 이미 되돌릴 수 없는 상태였습니다.
이 사고들의 공통된 뿌리는 에이전트가 사용자의 자격 증명을 그대로 빌려 쓰는 '빌린 자격 증명(Borrowed Credentials)' 문제입니다. 편리하고 익숙한 방식이지만, AI 에이전트는 전통적인 소프트웨어와 근본적으로 다릅니다. 에이전트는 미리 정해진 논리 경로가 아니라 자연어 지시와 환경적 맥락을 바탕으로 자율적인 판단을 내리며, 이 자율성이 무제한적인 접근 권한과 결합될 때 예측 불가능한 대규모 피해로 이어집니다. 빌린 자격 증명 문제는 귀책 소재가 불분명해지는 것에서 그치지 않습니다. 최소 권한 원칙 위반, 범위 경계 부재, 사후 감사 불능이라는 세 가지 구조적 취약점을 동시에 만들어냅니다.
2026년 보안의 핵심 과제는 **에이전트 중심 정체성(Agent-first Identity)**의 확립입니다. 각 에이전트는 인간 사용자와 별개인 고유한 자격 증명과 ID를 가져야 하며, 상호 TLS 또는 개인 키 JWT와 같은 기계 친화적 인증 메커니즘을 통해 신원이 검증되어야 합니다. 권한 측면에서는 데이터 분석 에이전트에게는 읽기 전용 접근만, 배포 에이전트에게는 개발 환경에 대한 쓰기 권한만 부여하는 세분화된 접근 제어가 필요합니다. 그리고 모든 에이전트 행위는 어느 에이전트가, 누구의 위임 하에, 어떤 권한으로, 무슨 행동을 했는지가 독립적으로 기록되는 감사 추적(Audit Trail)으로 남아야 합니다. Antigravity 에이전트가 특정 프로젝트 디렉토리에 대한 삭제 권한만 가졌더라면, 실수는 여전히 일어났을지 모르지만 피해는 그 범위 내에서 봉쇄되었을 것입니다.
지속 가능한 AI 거버넌스를 향하여
LiteLLM 사고는 단일 실패가 아니었습니다. 공급망 침해와 허위 컴플라이언스 인증이라는 두 가지 실패가 서로를 증폭시키며 복합적으로 작용했습니다. SOC 2 보고서는 바로 CI/CD 파이프라인 침해를 포착하거나 완화할 수 있었던 접근 제어, 변경 관리, 인시던트 대응 등의 통제를 검증하는 역할을 했어야 합니다. 그 보고서가 허위였기 때문에 그 통제들은 실제로 검증된 적이 없었습니다. AI 인프라 보안은 단순히 도구를 교체하는 것이 아니라, 기업의 거버넌스 철학을 세우는 일입니다. LiteLLM 사고 이후 기업이 반드시 지켜야 할 지침은 다음과 같습니다.
인증의 실체를 확인하십시오. SOC 2 배지만 보고 안심하지 마십시오. 실제 감사 기관이 어디인지, 감사 범위가 자사가 사용하는 제품을 구체적으로 포함하는지 반드시 확인해야 합니다. 감사 기관의 실체와 검증 가능한 실적까지 따져보는 것이 이제는 기본입니다.
자체 호스팅과 의존성 고정을 진지하게 고려하십시오. 공급망 오염에 대비해 보안이 중요한 환경에서는 직접 제어 가능한 자체 호스팅 옵션을 선택하십시오. 모든 의존성을 검증된 버전으로 고정(Pinning)하고, CI/CD 파이프라인의 전이 의존성까지 정기적으로 감사해야 합니다. 자체 호스팅이 항상 정답은 아니지만, 선택지가 있다는 것 자체가 보안 리스크 관리에서 큰 의미를 가집니다.
에이전트 책임 추적성을 확보하십시오. 모든 AI 활동은 인간 사용자와 분리된 독립적인 감사 추적이 남아야 합니다. 이는 사고 발생 시 원인 규명을 가능하게 할 뿐만 아니라, 규제 준수를 위한 필수 요건입니다. 에이전트가 실수를 저질렀을 때 그것이 재앙이 되느냐 단순한 사건으로 끝나느냐는 사전에 갖춰진 통제 체계에 달려 있습니다.
성능과 비용을 토큰 단위로 관리하십시오. 단순한 호출 횟수가 아닌 토큰 기반의 레이트 리미팅과 시맨틱 캐싱을 활용하십시오. LLM 비용은 요청 수가 아니라 토큰 사용량에 비례하며, 10,000토큰 컨텍스트 윈도우를 가진 단일 요청은 간단한 분류 프롬프트보다 100배 더 많은 비용이 발생합니다. 부서별 토큰 예산을 설정하고 실제 지출과 연계하는 것이 예측 불가능한 AI 비용 폭증을 막는 가장 실질적인 방법입니다.
2026년의 성공적인 기업은 가장 빠른 모델을 도입하는 곳이 아니라, 가장 정교하고 안전한 AI 통제 인프라를 구축하여 기술적 자유와 보안적 통제를 조화시킨 곳이 될 것입니다. 에이전트는 반드시 실수를 합니다. 중요한 것은 그 실수가 재앙이 되지 않도록 통제 체계를 미리 갖추는 것입니다.
원문 출처:
Best LiteLLM Alternatives in 2026: Secure AI Gateways
Why AI Agents Need Their Own Identity: Lessons from 2025 and Resolutions for 2026
What You Can Do with the AI Gateway
