실시간 에이전트가 LLM 게이트웨이 아키텍처를 재편하는 이유

6개월 전만 해도 "실시간 에이전트 (realtime agents)\

인프라 측면에서의 과제는 다음과 같습니다: 실시간 에이전트 (realtime agents)는 약 100ms 간격으로 클라이언트에게 업데이트를 전송합니다 (일반적인 속도에서 토큰당 약 50ms). 이는 에이전트당 초당 10개의 이벤트가 지속적으로 발생함을 의미합니다.

Python 게이트웨이는 토큰당 1~2ms의 오버헤드 (overhead)를 추가합니다. 이를 100개의 에이전트로 곱하면, 토큰을 버퍼링(buffering)하고 전달(forwarding)하는 것만으로도 CPU가 포화 상태에 이르게 됩니다. 병목 현상 (bottleneck)은 모델이 아니라 바로 게이트웨이입니다.

이것이 버퍼링된 에이전트 (buffered agents)가 Python 게이트웨이를 허용할 수 있는 이유입니다. 몇 초가 걸리는 결정 과정에서는 오버헤드가 미미하기 때문입니다. 하지만 실시간 에이전트는 이러한 지연 시간 비용 (latency tax)을 감당할 여유가 없습니다. 당신은 다음 중 하나를 선택해야 합니다:

• 컨테이너 포드 (container pods)에 더 많은 비용을 지불 (수직 확장 (vertical scaling))
• 더 많은 포드를 실행 (수평 확장 (horizontal scaling))
• 핫 패스 (hot path)를 더 빠른 런타임 (runtime)으로 이동

LiteLLM은 세 번째 옵션을 선택했습니다.

LiteLLM-Rust가 실시간 환경에 의미하는 것

6월 타운홀 미팅에서 LiteLLM은 OCR 경로 (routes)와 실시간 경로가 이제 Rust로 마이그레이션(migrated)되었다고 발표했습니다. 이는 일반적인 Rust 재작성이 아닙니다. 이는 타겟팅된 결정입니다. OCR과 실시간은 Python 게이트웨이의 오버헤드를 견딜 수 없는 두 가지 워크로드 (workloads)이기 때문입니다.

Rust 게이트웨이는 Python 경로의 약 7.5ms와 비교하여 요청당 약 0.05ms의 오버헤드를 추가하며, 부하 상황에서 31.7MB의 피크 메모리 (peak memory)로 초당 6,782개의 요청을 처리합니다.

이는 적절한 인프라에서 실시간 에이전트를 유지할 수 있느냐, 아니면 클라우드 포드가 필요하느냐의 차이입니다.

하지만 벤치마크보다 더 중요한 것은 LiteLLM의 스테이징 (staging) 접근 방식입니다. OCR 경로는 가장 먼저 이동하며 (Mistral 우선, 그 다음 모든 OCR 제공업체), 그 다음 /messages, 그 다음 /chat/completions 순으로 9월 1일까지 완료될 예정입니다. 이는 단계적이고 프로덕션에서 검증된 롤아웃 (rollout)입니다. 단순히 플래그를 전환하는 것이 아닙니다.

각 경로는 패리티 테스트 (parity tests)를 통과하고 프로덕션에서 실행된 후에만 Rust로 이동합니다. 팀은 인프라 마이그레이션을 프로덕션 릴리스 (production release)처럼 다루고 있습니다. 왜냐하면 실제로 그것이 프로덕션 릴리스이기 때문입니다.

에이전트 플랫폼 레이어 (The Agent Platform Layer)

하지만 여기서 미묘한 차이가 있습니다: 실시간 환경을 Rust로 옮기는 것은 문제의 절반에 불과합니다.

빠른 게이트웨이는 필수적입니다. 하지만 그것만으로는 충분하지 않습니다.

실시간 에이전트는 상태 유지 (stateful) 방식입니다. 모델은 토큰을 스트리밍 (streams)합니다. 에이전트는 다음과 같은 작업이 필요할 수 있습니다:

• 스트림 일시 중지 (사용자가 "중지"를 클릭함)
• 다른 파라미터로 재시도 (Retry)
• 대화 분기 (대안 제시)
• 의사결정 시 이전 토큰 기억

이 모든 것은 제어 평면 (control plane) 작업입니다. 바로 이 지점에서 LiteLLM Agent Platform이 등장합니다.

LiteLLM Agent Platform은 Rust 기반의 AI 게이트웨이 (AI Gateway) 및 에이전트 제어 평면 (Agent Control Plane)으로 자리매김하고 있습니다. 이들의 목표는 팀들이 여러 런타임 (runtimes)에 걸쳐 에이전트를 등록, 호출, 관찰 및 거버넌스 (govern) 할 수 있도록 하는 것입니다. 이들은 코딩 에이전트 (coding agents)부터 시작하고 있는데, 그 이유는 코딩 에이전트가 실행 시간이 길고, 상태 유지 (stateful) 방식이며, 도구 사용 (tool-heavy)이 많고, 실제 인프라가 필요할 만큼 비용이 많이 들기 때문입니다.

실시간 에이전트에게 이것이 중요한 이유는 다음과 같습니다:

• 스트리밍 상태는 어딘가에 존재해야 합니다. 에이전트의 대화 컨텍스트 (conversation context), 의사결정 이력, 그리고 부분적인 토큰들을 캡처해야 합니다. 제어 평면은 이를 중앙 집중화할 수 있는 단일 지점을 제공합니다.
• 도구 호출 (Tool calls)이 스트림 중간에 도착합니다. 실시간 환경에서는 전체 추론 (reasoning)이 완료되기 전에 도구가 나타날 수 있습니다. 제어 평면은 즉시 실행할지, 아니면 확인을 기다릴지를 결정해야 합니다.
• 관찰성 (Observability)이 변화합니다. 버퍼링된 (buffered) 에이전트의 경우 전체 응답을 로그로 남깁니다. 하지만 실시간의 경우, 토큰 스트림을 로그로 남기게 됩니다. 제어 평면은 이를 사후 고려 사항이 아닌, 네이티브하게 처리할 수 있어야 합니다.

이것이 귀하의 설정에 의미하는 바

만약 현재 Claude Managed Agents, Cursor, 또는 Bedrock AgentCore를 기반으로 에이전트를 구축하고 있다면:

빠른 게이트웨이 + 제어 평면이 바로 그 패턴입니다. "게이트웨이를 사용하라"도 아니고, "제어 평면을 사용하라"도 아닙니다. 둘 다입니다.

게이트웨이 (LiteLLM-Rust)는 실시간 토큰 스트림, 비용 귀속 (cost attribution), 그리고 제공자 변환 (provider translation)을 처리합니다. 제어 평면 (LiteLLM Agent Platform)은 세션, 메모리, 도구 거버넌스 (tool governance), 그리고 관찰성을 처리합니다.

이러한 분리는 특정 벤더 종속 (vendor lock-in)의 문제가 아닙니다. 이는 아키텍처의 문제입니다. 실시간 에이전트는 높은 처리량 (high-throughput)과 높은 거버넌스 (high-governance)를 동시에 요구합니다. 단일 계층 시스템은 이 두 차원 중 하나 또는 둘 모두에서 한계에 부딪힙니다.

2026년 7월 현재 상황

실시간 에이전트(Realtime agents)는 약 4개월 만에 "흥미로운 실험"에서 "인프라 요구 사항"으로 변모했습니다. 이러한 변화는 다음 분야에서 뚜렷하게 나타납니다:

• 코딩 에이전트 도입 (Claude Code, Cursor, Continue.dev 모두 실시간 기능 출시 중)
• 프레임워크 강조 (LangGraph, CrewAI 및 기타 프레임워크들이 실시간 에이전트 지원 추가 중)
• 게이트웨이 벤더의 행보 (모든 게이트웨이 벤더가 현재 Rust를 채택하거나 지연 시간(latency) 단축을 약속 중)

지난 6월 LiteLLM이 실시간 기능을 Rust로 마이그레이션하기로 결정한 것은 하나의 신호입니다. 이는 더 이상 선택적인 최적화가 아니라, 기초적인 인프라(foundational infrastructure)라는 의미입니다.

팀을 위한 에이전트 플랫폼을 평가하고 있다면, 실시간 기능(realtime capability)은 반드시 물어봐야 할 합리적인 질문입니다. 이는 단순한 기능 체크리스트 항목이 아니라, 인프라 성숙도를 바라보는 렌즈로서 다음과 같은 질문을 던져야 합니다:

• 게이트웨이가 실시간 경로(realtime routes)에서 밀리초 미만(sub-millisecond)의 오버헤드를 유지하는가?
• 제어 평면(control plane)이 부분 응답(partial responses)과 스트리밍 상태(streaming state)를 캡처하는가?
• 데이터 손실 없이 실시간 스트림을 일시 중지/재시도/분기(pause/retry/fork)할 수 있는가?
• 관찰 가능성(observability)이 실시간 기능에 내장되어 있는가, 아니면 사후에 덧붙여진 것인가?

이 질문들에 대한 답변이 프로토타입과 프로덕션 준비가 된 시스템(production-ready systems)을 구분합니다.

이것이 실제로 어떻게 작동하는지 알고 싶으신가요? LiteLLM Agent Platform을 사용하면 공유 제어 평면(shared control plane)을 통해 Claude Managed Agents, Cursor, Bedrock 등 다양한 런타임(runtimes)에 걸쳐 실시간 에이전트를 구축할 수 있습니다. 아키텍처를 확인하려면 문서를 참조하고, 변경 로그(changelog)를 통해 실시간 지원이 어떻게 진화하는지 추적해 보세요.

Rust 마이그레이션 일정과 기술적 세부 사항은 LiteLLM의 6월 타운홀 업데이트(June townhall update)에서 확인할 수 있습니다.