45편 · 약 17분

LiteLLM 1.93~1.94: MCP OBO·Responses bridge·Rust Gateway로 LLM 게이트웨이를 제어면으로 바꾸는 방법

왜 지금 봐야 하나

2026년 7월 19일 공개된 LiteLLM v1.93.0, 7월 하순 공식 문서에 반영된 MCP OAuth / OBO / Rust gateway 가이드, 그리고 6월 22일 공개된 Rust migration 설명을 같이 읽으면 이번 변화의 방향이 선명해진다. 핵심은 새 모델 몇 개를 더 붙였다는 이야기가 아니다. LiteLLM이 단순 provider adapter에서, 에이전트·도구·IDP·LLM provider 사이의 제어면(control plane)을 맡는 게이트웨이로 이동하고 있다는 점이다.

운영자 관점에서 특히 중요한 변화는 네 가지다.

MCP 인증 구성이 계약으로 승격됐다. 공식 문서는 auth_type: oauth2 서버마다 oauth2_flow를 명시하라고 요구하고, authorization_code / client_credentials / oauth2_token_exchange / passthrough 계열을 역할별로 분리한다.
사용자 컨텍스트 도구 호출을 위한 OBO 경로가 명확해졌다. LiteLLM은 클라이언트의 bearer token을 그대로 MCP 서버에 넘기지 않고, RFC 8693 token exchange로 scoped token을 발급받아 전달할 수 있다.
에이전트 클라이언트 호환성이 게이트웨이 책임으로 올라왔다. /chat/completions에서 /responses로의 bridge, Codex CLI용 custom tool round-trip / allowlist 보존, 입력·출력 토큰 예산 분리 같은 변화는 "모델 호출"보다 에이전트 런타임 계약 유지에 가깝다.
실행면은 Rust로, 정책면은 Python으로 분리되기 시작했다. rust: true는 모델 단위 opt-in이고, 실패 시 Python path로 자동 fallback된다. 즉, 전면 재작성 없이 hot path만 단계적으로 바꾸는 구조다.

한마디로 정리하면, 이번 LiteLLM 변화는 "프록시가 더 빨라졌다"보다 게이트웨이가 인증·도구·프로토콜·비용 정책을 함께 다루는 운영 경계가 됐다는 쪽이 더 중요하다.

핵심 변화 한눈에 보기

축	최근 표면	무엇이 바뀌었나	운영 의미
MCP 인증	MCP OAuth / MCP OBO Auth 문서, `v1.93.0`	`oauth2_flow` 명시, `entra_obo` 프로필 추가, `oauth2_flow` 저장 명시화	MCP 서버별 인증 전략을 config와 감사 대상으로 다룰 수 있음
사용자 토큰 처리	MCP OBO Auth 문서	raw bearer를 직접 전달하지 않고 `subject_token`으로 교환 후 scoped token 전달	내부 도구 호출에서 최소 권한과 토큰 경계 분리가 쉬워짐
에이전트 클라이언트 호환성	`/responses` 문서, `v1.93.0`	`/chat/completions` → `/responses` bridge, Codex CLI tool allowlist round-trip 보정	provider 차이를 게이트웨이에서 흡수하고 클라이언트 계약을 유지 가능
비용/속도 제어	`v1.93.0`, Rust gateway 문서	ITPM/OTPM 분리 rate limit, Bearer key 해시 로그, `rust: true` opt-in hot path	긴 컨텍스트·대출력 워크로드의 병목을 분리해 보고, 민감 로그 노출을 줄이고, 저위험으로 Rust 도입 가능

LiteLLM 1.93~1.94 — 정책면(Python)과 실행면(Rust)의 분리

1. MCP 인증은 이제 헤더 전달이 아니라 설정 계약이다

LiteLLM의 MCP OAuth 문서는 중요한 전제를 하나 못 박는다. auth_type: oauth2 인 모든 MCP 서버는 oauth2_flow를 명시해야 한다. 그리고 이 흐름을 다음처럼 역할별로 나눈다.

authorization_code: Claude Code, Cursor 같은 사용자 대화형 클라이언트
client_credentials: CI/CD, 백엔드 워커 같은 machine-to-machine 호출
oauth2_token_exchange: 사용자 bearer를 scoped token으로 바꾸는 OBO 경로
true_passthrough, oauth_delegate: 이미 upstream token 정책이 따로 있는 경우

이 구분이 왜 중요할까. 예전에는 MCP 서버를 붙일 때 "Authorization 헤더를 그냥 넘길지, 프록시가 대신 토큰을 받을지" 정도로 접근하기 쉬웠다. 하지만 에이전트 환경에서는 같은 /mcp 라우트라도 다음 호출이 다 섞인다.

사람이 직접 쓰는 IDE 보조 도구
배치 작업을 돌리는 백엔드 워커
사내 도구를 프록시하는 agent runtime
비용 추적과 rate limit를 게이트웨이에서 통일하고 싶은 플랫폼 팀

이때 oauth2_flow를 명시하지 않으면, 호출자 신원, 토큰 수명, 비용 attribution, 실패 재시도 경계가 모두 뒤섞인다. v1.93.0에서 oauth2_flow를 create 시점에 명시적으로 저장하도록 바꾼 것도 같은 맥락이다. 읽을 때 추론하는 구조보다, 저장된 설정 자체가 감사 가능한 계약이어야 운영 실수가 줄어든다.

`entra_obo` 프로필 추가가 의미하는 것

v1.93.0 릴리스 노트에는 feat(mcp): add entra_obo profile to the token_exchange (OBO) arm 이 들어 있다. 표면만 보면 provider 추가처럼 보이지만, 실제로는 Microsoft Entra 계열 IDP를 쓰는 조직에서 사용자 컨텍스트를 가진 내부 도구 호출을 게이트웨이에서 직접 다룰 수 있다는 뜻에 가깝다.

즉, LiteLLM이 이제 모델 provider만 붙이는 프록시가 아니라, 도구 인증 경로까지 제품 표면으로 끌어올린 게이트웨이로 읽혀야 한다.

2. OBO는 "사용자 토큰을 넘기지 않고도 사용자 권한으로 도구를 호출하는 방법"이다

MCP OBO Auth 문서가 설명하는 흐름은 단순하고도 중요하다.

클라이언트가 LiteLLM에 bearer token을 보낸다.
LiteLLM은 그 토큰을 RFC 8693의 subject_token 으로 사용한다.
IDP의 token exchange endpoint에서 해당 MCP 서버용 scoped token 을 발급받는다.
LiteLLM은 교환된 토큰만 MCP 서버로 전달한다.
이 토큰은 만료 전까지 캐시되어, 같은 사용자의 반복 호출에 매번 IDP round trip을 강요하지 않는다.

이 구조는 세 가지 이유로 실무적이다.

2-1. 원본 bearer를 MCP 서버에 직접 넘기지 않아도 된다

내부 MCP 서버가 많아질수록 가장 불편한 점은, 어떤 서버가 어떤 범위의 토큰을 직접 봤는지 추적하기가 어렵다는 것이다. OBO는 원본 사용자 토큰을 도구 서버까지 흘려 보내지 않고, 해당 도구에 필요한 scope로 다시 발급한 토큰만 넘긴다. 최소 권한을 지키기 쉬워진다.

2-2. MCP 서버별로 권한 경계를 나눌 수 있다

같은 사용자가 두 개의 MCP 서버를 호출해도, 각각 다른 scoped token을 만들 수 있다. 그래서 파일 시스템용 MCP, 이슈 트래커용 MCP, 사내 분석용 MCP를 같은 사용자 세션 위에 두되 권한은 분리하는 구성이 가능하다.

2-3. 게이트웨이가 토큰 교환과 비용 정책을 함께 묶을 수 있다

passthrough만 쓰면 upstream 권한은 보존되지만, LiteLLM이 admission·spend·rate limit를 강하게 쥐기 어렵다. 반대로 OBO는 LiteLLM이 호출자 신원은 인정하되, 실제 도구 호출용 자격증명은 재발급하는 위치에 서게 만든다. 이건 플랫폼 팀에게 매우 중요한 차이다.

다만 전제도 분명하다.

IDP가 RFC 8693 token exchange 를 지원해야 한다.
도구별 scope 설계가 먼저 정리되어야 한다.
토큰 캐시 만료 시나리오와 재교환 비용을 운영자가 이해해야 한다.
모든 MCP 서버가 OBO 대상은 아니다. 공개 API proxy나 이미 upstream auth가 완성된 서비스는 true_passthrough 또는 oauth_delegate가 더 자연스러울 수 있다.

즉, OBO는 만능 기본값이 아니라 "사용자 권한은 유지하되 raw token은 직접 흘리지 않겠다"는 조직에 맞는 선택지다.

mcp_servers:
  internal_tools:
    url: "https://mcp.example.com/mcp"
    transport: "http"
    auth_type: oauth2_token_exchange
    token_exchange_endpoint: "https://idp.example.com/oauth2/token"

3. `/responses` bridge와 입력·출력 budget 분리는 에이전트 게이트웨이에서 더 중요하다

LiteLLM의 /responses 문서는 단순 provider wrapper가 아니다. 문서가 분명히 말하듯, provider가 /responses를 직접 지원하지 않아도 /chat/completions 요청이 /responses로 bridge될 수 있다. 그리고 이 경로에서 다음 기능을 지원한다고 명시한다.

streaming
WebSocket mode
fallbacks
load balancing
guardrails
create / get / delete response 연산

이 말은 곧, 에이전트 클라이언트가 보는 프로토콜 계약을 게이트웨이가 상당 부분 떠안는다는 뜻이다.

Codex CLI round-trip 수정이 시사하는 것

v1.93.0 릴리스 노트의 fix(responses-bridge): custom tool round-trip and allowlist preservation for Codex CLI 는 겉보기보다 더 중요하다. 에이전트 클라이언트는 단순 텍스트 completion보다 다음 정보에 민감하다.

tool schema와 allowlist가 그대로 보존되는지
intermediate response id와 follow-up 호출이 이어지는지
provider가 달라도 tool execution surface가 깨지지 않는지

즉, 게이트웨이가 /responses를 bridge하는 순간 책임은 "JSON 키 이름이 맞는다" 수준에서 끝나지 않는다. 클라이언트가 기대하는 agent protocol이 보존되어야 한다. Codex CLI 보정이 릴리스 노트에 직접 올라왔다는 것은 LiteLLM 팀도 이 경계를 명시적으로 다루기 시작했다는 뜻이다.

ITPM / OTPM 분리도 agent workload에 맞춘 변화다

같은 릴리스의 feat(router): add separate ITPM/OTPM deployment rate limits 도 눈여겨볼 필요가 있다. 짧은 질의응답에서는 단일 TPM 예산으로도 운영이 된다. 하지만 agent loop는 다르다.

retrieval-heavy 단계는 입력 토큰 이 급증한다.
긴 reasoning / tool synthesis 단계는 출력 토큰 이 병목이 된다.
일부 모델은 입력보다 출력 토큰이 훨씬 비싸거나 느리다.

입력과 출력을 같은 rate limit로 묶으면, 어느 쪽이 병목인지 보이지 않는다. ITPM/OTPM 분리는 단순 quota 기능이 아니라, 에이전트 워크로드의 병목을 관측 가능한 축으로 분리한 것에 가깝다.

보안 로그도 같이 봐야 한다

fix(security): hash Bearer-prefixed API keys in spend logs 도 같은 흐름이다. 게이트웨이가 spend log를 남기는 위치에 서 있다면, raw key가 로그에 남는 순간 관측면 자체가 비밀 유출면 이 된다. 비용 추적과 보안 정책은 원래 같이 움직여야 한다.

결국 /responses bridge, token budget 분리, spend log key 해시는 하나의 공통 메시지로 읽힌다. LiteLLM은 더 이상 "모델을 대신 불러 주는 프록시"가 아니라, agent traffic을 정책 단위로 다루는 gateway plane 이다.

4. Rust gateway는 재작성 프로젝트가 아니라 hot path의 점진 이관이다

LiteLLM의 Rust gateway 문서는 첫 문단부터 운영자 입장에서 중요한 사실을 박아 둔다.

beta 기능 이다.
opt-in 이고 기본값은 off 다.
Rust path가 실패하거나 아직 미지원이면 기존 Python path로 자동 fallback 된다.
적어도 현재 표면에서는, Python이 auth / configuration / routing / logging / callbacks / spend tracking 을 계속 맡는다.

즉, 이건 "LiteLLM v2"가 아니다. 공식 Rust migration 글도 같은 메시지를 반복한다. config, DB schema, client API contract는 유지한 채, request translation과 provider network call hot path만 route-by-route로 Rust로 옮기는 전략 이다.

왜 이 방식이 현실적인가

LLM gateway는 보통 다음 두 층이 얽혀 있다.

정책면: 인증, 가상 키, 팀/조직 예산, 라우팅, guardrail, 로깅
실행면: provider별 request/response 변환, streaming 처리, HTTP network call

Rust migration이 바로 전체를 뒤집지 않고, 실행면만 먼저 떼어내는 이유는 명확하다. 운영 중인 게이트웨이에서 더 위험한 쪽은 대개 정책면 파손이다. auth, billing, logging이 한번 틀어지면 영향 범위가 넓다. 반면 translation / network hot path는 성능 이득이 크면서도 fallback 설계가 가능 하다.

`rust: true`는 모델 단위 canary로 읽어야 한다

문서는 모델의 litellm_params 안에 rust: true 를 넣는 예시를 제공한다. 그리고 성공적으로 Rust 경로를 탔을 때는 응답에 x-litellm-rust: true 헤더가 붙는다고 설명한다.

이건 운영적으로 아주 좋은 신호다.

전체 게이트웨이를 한 번에 바꾸지 않아도 된다.
특정 provider / route / model 조합만 canary로 켤 수 있다.
응답 헤더로 실제 경로를 확인할 수 있다.
오류가 나면 Python path로 내려오므로 blast radius가 작다.

성능 수치는 참고용이지 계약은 아니다

Rust migration 글은 vendor-published benchmark로 0.05ms overhead, Python path의 약 7.5ms 대비, 6,782 req/s, 31.7MB peak memory 같은 숫자를 제시한다. 이 수치는 방향성 참고 로는 유용하지만 그대로 생산계 성능 계약으로 받아들이면 안 된다.

실제 체감은 다음 변수에 더 많이 좌우된다.

upstream provider latency
streaming chunk 수와 callback 부하
auth / logging callback이 hot path에 얼마나 남아 있는지
같은 노드에서 어떤 route를 Rust로 돌리는지

그래서 Rust gateway를 볼 때 핵심은 벤치마크 숫자보다, 정책면은 그대로 두고 hot path만 분리할 수 있는 배포 전략 이다.

5. 무엇이 좋아졌고, 무엇은 아직 그대로인가

이번 변화는 강력하지만 과장해서 읽으면 곤란하다.

좋아진 점

MCP 인증이 flow·토큰 경계·권한 모델까지 포함한 설정 표면으로 정리됐다.
사용자 컨텍스트 도구 호출에서 raw token 직접 전달을 피할 수 있다.
/responses 기반 agent client 호환성을 게이트웨이에서 유지할 여지가 커졌다.
입력/출력 budget을 분리해 긴 컨텍스트·장문 출력 모델의 병목을 더 잘 볼 수 있다.
Rust 경로를 route-by-route canary로 켤 수 있다.

아직 그대로인 점

Rust gateway는 아직 beta 고, route coverage가 제한적이다.
Python이 auth·routing·logging·spend tracking을 계속 맡는다. 즉, 전체 control plane이 Rust로 옮겨간 건 아니다.
OBO는 IDP와 scope 설계가 준비된 조직에서만 깔끔하게 작동한다.
/responses bridge는 프로토콜 정규화에 가깝지, provider semantic 차이를 완전히 없애 주는 마법은 아니다.

이 점 때문에 LiteLLM은 지금 당장 "완전히 새로운 gateway"가 됐다기보다, 에이전트 시대에 필요한 control plane 기능을 먼저 끌어올리고, 실행면을 조심스럽게 교체하는 중간 단계 로 보는 편이 정확하다.

언제 먼저 도입하고, 언제 미루는 게 나은가

먼저 도입할 만한 팀

Claude Code, Codex CLI, 내부 에이전트 앱을 하나의 LLM gateway 뒤에 묶으려는 플랫폼 팀
내부 MCP 서버가 많고, 사용자 raw token을 직접 흘리고 싶지 않은 조직
Anthropic /v1/messages 같은 route에서 provider translation CPU 비용 이 체감되는 팀
spend tracking / rate limit / logging을 모델 provider별이 아니라 게이트웨이 단위 정책 으로 통합하려는 팀

아직 미루는 편이 나은 팀

IDP가 RFC 8693 token exchange를 지원하지 않는 조직
MCP 도구별 scope 모델이 아직 정리되지 않은 팀
주요 트래픽이 Rust 미지원 route에 몰려 있어 이득이 제한적인 팀
/responses 브리지보다 provider native semantics 차이가 더 중요한 워크로드를 운영하는 팀

운영자 체크리스트

MCP 서버별로 authorization_code / client_credentials / oauth2_token_exchange / passthrough 중 어느 흐름을 쓸지 먼저 표로 정리한다.
OBO 대상 MCP 서버에는 필요한 최소 scope만 발급되도록 IDP 설정을 검토한다.
oauth2_flow 가 create/read 경로 모두에서 일관되게 보존되는지 관리 API와 UI에서 확인한다.
/responses 를 쓰는 클라이언트가 있다면 tool allowlist, response id follow-up, WebSocket mode를 실제 클라이언트로 검증한다.
긴 컨텍스트 모델에는 ITPM/OTPM 분리 limit를 적용해 입력 병목과 출력 병목을 따로 관찰한다.
spend log / audit sink에 raw bearer나 key 문자열이 남지 않는지 샘플 로그로 검증한다.
Rust 도입은 전체 전환이 아니라 모델 단위 rust: true canary로 시작하고, x-litellm-rust: true 헤더로 실제 경로를 확인한다.
Rust path를 켠 route에서 fallback 발생률, callback latency, upstream timeout 패턴을 Python path와 비교한다.

마무리

LiteLLM 1.93~1.94를 한 줄로 요약하면 이렇다. 게이트웨이가 더 많은 모델을 호출하게 된 것이 아니라, 에이전트·도구·IDP·provider 사이의 권한과 프로토콜을 스스로 책임지는 쪽으로 이동하고 있다.

MCP OBO는 사용자 권한을 유지하면서도 raw token 노출을 줄이는 경계를 제공하고, /responses bridge와 token budget 분리는 agent client 계약과 비용 정책을 같은 표면에서 다루게 하며, Rust gateway는 이 전체 제어면을 무너뜨리지 않고 hot path만 점진적으로 바꾸는 현실적인 이행 전략을 보여 준다.

그래서 이번 LiteLLM 변화는 "프록시 최적화"보다 에이전트 시대의 gateway control plane 설계 로 읽는 편이 맞다.

References

LiteLLM GitHub Releases, v1.93.0 (published 2026-07-19): https://github.com/BerriAI/litellm/releases/tag/v1.93.0
LiteLLM Docs, MCP OAuth: https://docs.litellm.ai/docs/mcp_oauth
LiteLLM Docs, MCP OBO Auth: https://docs.litellm.ai/docs/mcp_obo_auth
LiteLLM Docs, [Beta] Rust AI Gateway: https://docs.litellm.ai/docs/proxy/rust_gateway
LiteLLM Docs, /responses: https://docs.litellm.ai/docs/response_api
LiteLLM Blog, Migrating LiteLLM to Rust - Building the Fastest and Litest AI Gateway (published 2026-06-22): https://docs.litellm.ai/blog/litellm-rust-launch