AI Gateway를 처음 도입한다면 관리형인 Cloudflare AI Gateway로 관측과 rate limit부터 시작하고, 팀별 예산·가상 키·복잡한 fallback이 필요해질 때 LiteLLM Proxy를 검토하는 편이 현실적이다. Cloudflare는 빠른 도입과 낮은 운영 부담이 강점이고, LiteLLM은 통제 범위가 넓은 대신 데이터베이스·배포·업그레이드 책임이 따라온다. 2026년 8월 21일 공식 문서를 기준으로 두 제품의 차이와 실패 조건을 다시 정리했다.
핵심 요약
- 운영 부담을 줄이고 관측·캐시·rate limit을 빠르게 붙이려면 Cloudflare AI Gateway가 유리하다.
- 세밀한 라우팅, 가상 키, 팀별 예산, 자체 정책과 데이터 통제가 필요하면 LiteLLM Proxy가 맞다.
- 둘은 완전한 대체재가 아니다. Cloudflare를 외곽 관측 계층, LiteLLM을 내부 정책 계층으로 조합할 수도 있다.
- 도입 판단은 기능 수보다 장애 격리, 로그 보존, 키 회전, DB 의존성, 업그레이드 책임을 기준으로 내려야 한다.
AI Gateway가 필요한 시점은 기능 개수가 아니라 운영 경계로 판단한다
앱 한 개가 모델 한 개를 호출하는 단계라면 별도 Gateway가 오히려 장애 지점만 늘릴 수 있다. 반대로 여러 서비스가 같은 제공자 키를 공유하거나, 모델 장애가 곧 전체 장애로 이어지거나, 팀별 비용을 사후 집계하고 있다면 공통 계층을 둘 이유가 생긴다.
| 신호 | 직접 호출 유지 | Gateway 검토 |
|---|---|---|
| 애플리케이션 수 | 1개, 소유 팀이 명확함 | 여러 서비스·에이전트가 공통 모델을 호출함 |
| 모델·제공자 | 단일 제공자에 고정 | 복수 제공자 라우팅·fallback이 필요함 |
| 비용 통제 | 월 청구서 사후 확인으로 충분 | 키·팀·사용자별 예산과 rate limit이 필요함 |
| 장애 대응 | 앱 코드에서 재시도 가능 | 공통 timeout·retry·circuit breaker 정책이 필요함 |
| 보안·감사 | 키 수가 적고 접근 주체가 제한됨 | 키 회전, 감사 로그, 민감정보 정책을 중앙화해야 함 |
핵심은 “Gateway가 있으면 안정적이다”가 아니다. Gateway 자체의 장애와 설정 오류를 감당할 운영 주체가 있는지 먼저 확인해야 한다.
Cloudflare AI Gateway와 LiteLLM 비교표
| 판단 기준 | Cloudflare AI Gateway | LiteLLM Proxy |
|---|---|---|
| 운영 형태 | Cloudflare 관리형 서비스 | 컨테이너·Kubernetes 등에 자체 배포 |
| 빠른 도입 | 기존 호출 URL 변경 중심으로 시작하기 쉬움 | 프록시 배포, 시크릿, 저장소와 모니터링 구성이 필요함 |
| 관측 | 대시보드 분석, 로그, 비용, OpenTelemetry 연동 제공 | 비용 추적, 로그·콜백·메트릭과 관리자 UI를 자체 환경에서 운영 |
| 라우팅 | OpenAI 호환 API와 dynamic routing 제공 | Router 기반 load balancing, retry, provider/model fallback 제공 |
| 예산·키 | spend limit·rate limiting과 BYOK 기능 제공 | virtual key·사용자·팀·에이전트 단위 예산과 TPM/RPM 정책 제공 |
| 캐시 | 동일 요청의 텍스트·이미지 응답 캐시 지원 | 프록시 캐시와 제공자 prompt caching 연계 가능 |
| 데이터 경계 | Cloudflare 서비스 경계를 통과함 | 자체 네트워크와 저장소 정책 안에서 통제 가능 |
| 주요 책임 | Cloudflare 계정·정책·로그 보존 설정 | DB, 고가용성, 버전 고정, 마이그레이션, 보안 패치까지 직접 책임 |
Cloudflare 공식 가격 문서는 현재 핵심 기능인 대시보드 분석·캐시·rate limiting을 무료로 제공한다고 설명한다. 다만 로그 저장 한도는 Workers Free에서 전체 Gateway 합계 10만 건, Workers Paid에서 Gateway당 1천만 건이다. 향후 일부 기능이 유료화될 수 있다는 안내도 있으므로 “영구 무료”로 해석하면 안 된다.
LiteLLM 공식 문서는 100개 이상 LLM을 OpenAI 형식으로 호출하고 Router의 retry·fallback, Proxy의 virtual key·비용 추적·관리자 UI를 제공한다고 밝힌다. GitHub 최신 릴리스는 확인 시점에 v1.97.0(2026년 8월 16일)이었다. 운영 환경에서는 latest 태그를 따라가기보다 버전을 고정하고 변경 내역·DB 마이그레이션을 검토해야 한다.
선택 흐름: 관리형 우선인가, 통제권 우선인가
출처: Cloudflare·LiteLLM 공식 문서 기준 재구성
Cloudflare AI Gateway가 맞는 경우
- 전담 플랫폼 팀 없이 로그·분석·캐시·rate limit을 빠르게 붙여야 한다.
- Cloudflare 계정과 Workers 운영 체계가 이미 있고 관리 지점을 늘리고 싶지 않다.
- 초기에는 단순한 제공자 전환과 관측이 핵심이며 복잡한 조직별 권한 모델은 아직 필요하지 않다.
- Gateway 서버와 DB의 고가용성을 직접 운영할 여력이 없다.
LiteLLM Proxy가 맞는 경우
- 모델별 배포군을 묶어 load balancing하고 오류 유형별 fallback을 세밀하게 제어해야 한다.
- 가상 키를 발급하고 팀·사용자·에이전트별 예산과 TPM/RPM을 중앙에서 강제해야 한다.
- 요청·응답 데이터가 외부 관리형 Gateway를 통과하면 안 되는 보안 요구가 있다.
- PostgreSQL, 시크릿 관리, 모니터링, 무중단 업그레이드를 책임질 운영 역량이 있다.
두 제품을 함께 쓰는 경우
혼합 구조도 가능하다. 예를 들어 외부 트래픽은 Cloudflare에서 인증·DLP·rate limit·관측을 처리하고, 내부에서는 LiteLLM이 모델 배포군과 팀별 예산을 관리할 수 있다. 다만 retry와 rate limit을 양쪽에 중복 적용하면 지연과 증폭 재시도가 생긴다. 각 계층의 책임을 문서로 나누고 timeout 합계가 사용자 요청 제한을 넘지 않게 설계해야 한다.
실무 도입 순서: 한 번에 모든 기능을 켜지 않는다
- 기준선을 측정한다. 현재 모델별 요청 수, p50·p95 지연, 429·5xx 비율, 토큰 비용을 최소 1주 기록한다.
- 관측만 연결한다. 라우팅을 바꾸기 전에 로그 필드, 사용자 식별자, 민감정보 마스킹과 보존 기간을 검증한다.
- rate limit을 shadow 기준으로 계산한다. 정상 피크를 차단하지 않도록 경고 단계부터 시작한다.
- timeout과 retry 예산을 정한다. 앱·Gateway·제공자 SDK가 각각 재시도하지 않도록 소유 계층을 하나로 정한다.
- 동일 품질의 fallback부터 시험한다. 컨텍스트 길이, 도구 호출, 구조화 출력이 호환되지 않는 모델을 무조건 대체 모델로 두지 않는다.
- 장애 주입 테스트를 한다. 429, 500, timeout, 잘못된 키, DB 단절, 로그 저장 실패를 재현하고 복구 경로를 확인한다.
- 점진적으로 트래픽을 전환한다. 내부 사용자와 낮은 위험 요청부터 시작해 오류율과 비용 변화를 비교한다.
운영에서 자주 실패하는 다섯 가지 조건
| 실패 조건 | 왜 위험한가 | 대응 |
|---|---|---|
| 중첩 재시도 | 앱·Gateway·SDK가 각각 재시도해 요청 폭증과 비용 증가가 생김 | 재시도 소유 계층 하나, 최대 시도 횟수와 총 시간 예산 지정 |
| 의미가 다른 모델 fallback | 도구 호출·JSON 스키마·안전 정책 차이로 조용한 품질 저하 발생 | 호환성 테스트와 평가셋 통과 모델만 fallback 그룹에 포함 |
| 원문 로그 무기한 저장 | 개인정보·API 키·프롬프트 비밀이 장기간 남음 | 필드별 마스킹, 최소 보존 기간, 접근 감사 적용 |
| Gateway 단일 인스턴스 | 공통 계층이 전체 AI 기능의 단일 장애점이 됨 | 헬스체크, 다중 인스턴스, 우회 또는 fail-open/closed 정책 명시 |
| 버전 자동 추종 | 설정 스키마·DB 변경이 예고 없이 운영에 반영됨 | 이미지 digest 고정, staging 검증, 롤백과 DB 백업 준비 |
비용과 보안에서 반드시 확인할 체크리스트
- Gateway 사용료뿐 아니라 로그 저장소, DB, 캐시, egress, 모니터링 비용을 합산한다.
- 제공자 키는 앱에 남기지 않고 Gateway의 시크릿 저장소 또는 외부 secret manager로 이동한다.
- 사용자·팀·서비스 계정을 구분하고 공유 키를 피한다.
- 프롬프트와 응답 본문을 꼭 저장해야 하는지 검토하고, 기본값은 최소 수집으로 둔다.
- 캐시는 동일 요청에만 적용되는지, 사용자별 데이터가 잘못 공유될 가능성이 없는지 확인한다. Cloudflare 캐시는 공식 문서상 동일 요청의 텍스트·이미지 응답에 적용된다.
- 비용 한도 도달 시 차단할지, 저가 모델로 내릴지, 관리자 승인을 요구할지 정책을 미리 정한다.
- LiteLLM 예산 기능은 공식 문서상 DB의 지출 기록을 기준으로 강제되므로 DB 없는 배포에서 동일한 통제를 기대하면 안 된다.
관련 글
- AI 에이전트 비용 추적 가이드 — Gateway에 넣을 비용 태그와 팀별 관리 기준을 정리했다.
- AI 에이전트 관측 도구 비교 — Gateway 로그 이후 trace·평가 계층을 선택할 때 참고할 수 있다.
- RAG 평가 실무 가이드 — fallback이나 라우팅 변경 전 품질 회귀를 검증하는 방법을 다룬다.
FAQ
AI Gateway는 트래픽이 적어도 필요한가?
단일 앱·단일 모델이고 키 관리와 장애 대응이 단순하다면 바로 도입할 필요는 없다. 다만 여러 서비스가 키를 공유하거나 비용 귀속이 불분명해지는 시점부터 중앙 계층의 가치가 커진다.
Cloudflare AI Gateway와 LiteLLM 중 어느 쪽이 더 저렴한가?
Cloudflare는 핵심 기능이 현재 무료지만 로그 한도와 연계 서비스 비용을 확인해야 한다. LiteLLM은 오픈소스여도 서버·DB·관측·업그레이드 인력이 비용이다. 월 요청 수보다 운영 인력과 데이터 보존 요구를 포함한 총소유비용으로 비교해야 한다.
fallback에 더 저렴한 모델을 넣으면 비용이 항상 줄어드는가?
그렇지 않다. 출력 형식이나 도구 호출 호환성이 낮으면 재시도와 품질 회귀가 늘 수 있다. 같은 평가셋과 실패 조건을 통과한 모델만 그룹에 넣고, 비용과 성공률을 함께 봐야 한다.
참고 자료
- Cloudflare AI Gateway 공식 문서 (확인: 2026-08-21)
- Cloudflare AI Gateway Pricing (문서 갱신: 2026-05-19)
- Cloudflare AI Gateway Caching (문서 갱신: 2026-06-15)
- Cloudflare Unified API (OpenAI 호환) (문서 갱신: 2026-08-07)
- LiteLLM 공식 문서
- LiteLLM Fallbacks 공식 문서
- LiteLLM Budgets·Rate Limits 공식 문서
- LiteLLM v1.97.0 릴리스 (2026-08-16)
