에이전트 인프라를 게이트웨이 지연 시간(Latency)만으로 측정하는 것을 멈춰야 하는 이유

LLM 게이트웨이 벤치마크 속도가 점점 빨라지는 것을 지켜봐 왔습니다. Bifrost는 11마이크로초(µs), Helicone은 8밀리초(ms), LiteLLM은 8ms입니다. 단일 요청에 대해 계산해 보면 결과는 잔혹합니다. Bifrost는 LiteLLM보다 720배 더 빠릅니다.

하지만 이번 주에 저는 세 팀이 게이트웨이를 벤치마킹하고, 지연 시간(Latency)을 기준으로 선택하여 프로덕션에 배포한 뒤, 자신들이 잘못된 문제를 해결했다는 것을 깨닫는 과정을 목격했습니다.

문제는 벤치마크 자체가 아닙니다. 문제는 그들이 무엇을 벤치마킹하고 있는지, 그리고 무엇을 벤치마킹하지 않고 있는지입니다.

지연 시간 벤치마크는 채팅 인터페이스를 측정합니다

전형적인 게이트웨이 지연 시간 벤치마크가 수행하는 방식은 다음과 같습니다:

단일 LLM 요청(채팅 완성(Chat Completion), 임베딩(Embedding) 호출 등)을 보냅니다.
게이트웨이가 추가하는 오버헤드(Overhead)를 측정합니다.
백분위수 지연 시간(Percentile Latency)과 처리량(Throughput)을 보고합니다.

여러분의 애플리케이션이 채팅 인터페이스라면 이 방식은 타당합니다. 한 명의 사용자가 하나의 메시지를 보냅니다. 낮은 지연 시간은 좋은 경험을 줍니다. 해당 호출을 게이트웨이를 통해 라우팅하고 11마이크로초를 추가한다고요? 보이지도 않을 만큼 경이로운 수준입니다.

하지만 에이전트 시스템(Agent systems)은 채팅 인터페이스처럼 작동하지 않습니다.

에이전트 호출은 병렬이 아닌 순차적입니다

의사결정을 내리는 프로덕션 에이전트는 일반적으로 단 한 번의 LLM 호출만 수행하지 않습니다. 다음과 같이 여러 번의 호출을 수행합니다:

계획(Planning): "어떤 도구(Tool)가 필요한가?" (1회 호출)
실행(Execution): "이 인자(Args)와 함께 도구 X를 사용하라" (도구당 1회 호출)
검증(Validation): "출력이 타당한가?" (1회 호출)
정제(Refinement): "그것이 제대로 작동했는가?" (1회 호출)
보고(Reporting): "발생한 일을 요약하라" (1회 호출)

의사결정 하나당 5~15회의 호출이 발생합니다. 어떤 에이전트는 50회 이상을 수행하기도 합니다.

각 호출이 게이트웨이를 통과한다면, 지연 시간은 복리로 쌓입니다(Compounds):

Bifrost: 호출당 11µs, 10회 호출 = 110µs
Helicone: 호출당 8ms, 10회 호출 = 80ms
LiteLLM: 호출당 8ms, 10회 호출 = 80ms

상대적인 차이는 줄어듭니다. 하지만—그리고 이 부분이 벤치마크가 숨기는 부분입니다—프로덕션 환경에서 에이전트는 고립되어 실행되지 않습니다.

여러 에이전트가 동시에 실행됩니다. 도구 호출(Tool calls)이 차단(Block)될 수 있습니다. 폴백(Fallback)이 발생하면 재시도(Retry)가 트리거됩니다. 비용 할당(Cost attribution)은 요청당 발생합니다. 세션 상태(Session state)는 충돌(Crash) 발생 시에도 지속되어야 합니다.

게이트웨이 오버헤드(Gateway overhead)는 에이전트 지연 시간(Latency)의 _한 가지 구성 요소_일 뿐입니다. 그것이 유일한 구성 요소는 아니며, 대개 가장 큰 비중을 차지하는 것도 아닙니다.

프로덕션 팀들이 실제로 평가하는 것들

이번 달에 프로덕션 환경에서 코딩 에이전트(Coding agents)를 운영 중인 5개 팀과 이야기를 나누었습니다. 그들이 실제로 중요하게 생각하는 요소들을 영향력 순으로 정리했습니다.

1. 세션 지속성 (Session Persistence)
"작업 도중 에이전트가 충돌(Crash)하면 모든 것을 잃게 됩니다. 벤치마크에서는 세션 상태(Session state)에 대해 전혀 언급하지 않았습니다." 그들은 에이전트가 포드(Pod) 재시작 시에도 생존하고, 도구 호출 이력(Tool call history)을 유지하며, 중단된 지점부터 다시 시작할 수 있기를 원했습니다.

2. 비용 귀속 (Cost Attribution)
"CFO가 각 에이전트의 결정마다 비용이 얼마나 드는지 물었습니다. 게이트웨이의 지연 시간 벤치마크는 그 답을 주지 못했습니다." 그들은 요청을 에이전트, 워크플로(Workflow), 팀, 사용자별로 태깅(Tagging)한 다음, 에이전트 및 결정당 비용을 합산(Roll up)할 수 있어야 했습니다. 지연 시간 벤치마크는 처리량(Throughput)을 측정할 뿐, 결정당 비용을 측정하지는 않습니다.

3. 모델 라우팅 (Model Routing)
"우리는 복잡한 작업에는 Claude를, 속도가 중요할 때는 GPT-4를, 저렴한 호출에는 오픈 소스(Open-source) 모델을 사용합니다. 가장 빠른 게이트웨이가 작업 복잡도에 따라 라우팅을 해주는 것은 아닙니다." 그들에게는 조건부 라우팅(Conditional routing)이 필요했습니다: "만약 이 에이전트가 금융 결정을 처리하고 있다면 Claude를 사용하고, 단순 조회라면 더 저렴한 모델을 사용하라." Bifrost가 11µs의 오버헤드를 기록하더라도, 결정 유형에 따라 라우팅할 수 없다면 의미가 없습니다.

4. 폴백 및 재시도 정책 (Fallback & Retry Policy)
"우리의 도구는 가끔 실패합니다. 우리는 단순히 총 요청 수가 얼마나 통과했는지가 아니라, 재시도(Retry)가 몇 번 발생했는지와 그 이유를 알아야 합니다." 그들은 재시도 루프(Retry loops)를 계측(Instrument)하고 비용 급증(Cost spirals)을 방지해야 했습니다. 초당 10,000건의 요청(RPS)을 처리하더라도 모든 재시도를 동일하게 로그로 남기는 게이트웨이는 도움이 되지 않습니다.

5. 샌드박스 격리 (Sandbox Isolation)
"각 에이전트는 자신만의 세션을 가집니다. 도구들은 격리된 샌드박스(Sandboxes)에서 실행됩니다. 게이트웨이 지연 시간 벤치마크는 샌드박스에 대해 전혀 언급하지 않습니다." 그들은 에이전트가 리소스 제한(Resource limits)과 감사 추적(Audit trails)을 갖춘 팀별, 워크플로별 샌드박스에서 실행되기를 원했습니다.

6. 관측성 (Observability) 및 디버깅 (Debugging)
"에이전트가 잘못된 결정을 내렸을 때, 우리는 이를 재현(Replay)할 수 있어야 합니다. 모든 도구 호출(Tool call), 모든 모델 호출(Model invocation), 모든 결정 지점을 확인해야 합니다." 그들에게 필요했던 것은 단순한 지연 시간(Latency) 지표가 아니라 구조화된 추적(Structured tracing)이었습니다.

게이트웨이 지연 시간(Gateway latency) 벤치마크는 이러한 요소들을 전혀 측정하지 못합니다.

지연 시간 논리가 무너지는 지점

실제 워크플로(Workflow)를 바탕으로 계산해 봅시다:

한 에이전트가 고객 지원 티켓을 처리합니다. 에이전트는 다음을 수행합니다:

이슈 분류를 위한 LLM 호출 (1회 호출)
고객 기록 조회 (도구 호출 (Tool call), 데이터베이스에서 약 200ms 소요)
응답 초안 작성을 위한 LLM 호출 (1회 호출)
감정 분석 (임베딩 호출 (Embedded call) 또는 도구 호출, 약 50ms 소요)
신뢰도가 낮을 경우 상담원에게 라우팅 (1회 호출)

총 지연 시간: 약 400–600ms

이 흐름에서의 게이트웨이 오버헤드(Overhead):

Bifrost: 11µs × 4 LLM 호출 = 44µs
LiteLLM: 8ms × 4 LLM 호출 = 32ms

따라서 Bifrost는 500ms 워크플로에서 31ms를 절약합니다. 이는 6%에 해당합니다. 중요할까요? 물론입니다. 하지만 비용 거버넌스(Cost governance), 세션 지속성(Session persistence), 모델 라우팅(Model routing)보다 더 중요하지는 않습니다.

또한 8ms의 오버헤드를 가진 LiteLLM은 이미 실제 워크플로 지연 시간에 의해 미미한 수준이 되었습니다.

진짜 질문: 제어 평면 (Control Plane) vs. 데이터 평면 (Data Plane)

벤치마크 대화는 모든 것을 위해 하나의 게이트웨이가 필요하다고 가정합니다. 하지만 프로덕션 에이전트 인프라에는 두 개의 계층이 필요합니다:

데이터 평면 (Data plane) (게이트웨이 지연 시간이 중요한 곳):

모델 제공업체로의 빠른 요청 라우팅 (Request routing)
폴백 (Fallback) 및 재시도 (Retry) 로직
요청 수준의 비용 추적 (Cost tracking)
최소한의 오버헤드

이곳이 바로 Bifrost가 빛을 발하는 영역입니다. Go의 동시성 모델 (Concurrency model)은 고처리량(High-throughput), 저지연(Low-latency) 라우팅에 진정으로 적합합니다. 11µs의 오버헤드는 실재하며 측정 가능합니다.

제어 평면 (Control plane) (게이트웨이 지연 시간이 중요하지 않은 곳):

재시작 시에도 유지되는 세션 지속성 (Session persistence)
에이전트별 및 팀별 샌드박스 (Sandboxes)
워크플로 스케줄링 (Workflow scheduling) 및 메모리 관리 (Memory management)
에이전트 및 워크플로에 대한 비용 귀속 (Cost attribution)
액세스 제어 (Access control) 및 감사 추적 (Audit trails)
도구 바인딩 (Tool binding) 및 검증 (Validation)

이 지점에서는 데이터 평면 (Data plane) 지연 시간 (Latency)이 무의미합니다. 세션 상태 (Session state), 샌드박스 프로비저닝 (Sandbox provisioning), 또는 워크플로 라우팅 (Workflow routing)을 처리하는 제어 평면 (Control plane) 호출이 200ms가 걸리는 것은 허용 가능한 범위입니다. 초당 5,000번씩 호출하는 것이 아니기 때문입니다. 에이전트 생명 주기 (Agent lifecycle) 동안 단 몇 번만 호출될 뿐입니다.

이것이 바로 LiteLLM Agent Platform이 작동하는 방식입니다. 이 플랫폼은 저지연 게이트웨이 (Low-latency gateway)가 되려는 것이 아닙니다. 에이전트를 실제 운영 환경 (Production)에서 실행 가능하게 만드는 신뢰할 수 있는 제어 평면 (Control plane)이 되고자 합니다.

에이전트 인프라를 평가하는 방법

팀들이 실제로 사용해야 할 프레임워크는 다음과 같습니다:

상태를 잃지 않고 포드 재시작 (Pod restarts) 시에도 에이전트를 실행할 수 있는가? (세션 지속성 (Session persistence))
팀별 및 워크플로별로 에이전트를 격리할 수 있는가? (멀티테넌시 (Multi-tenancy))
에이전트당 및 결정당 비용을 측정할 수 있는가? (비용 귀속 (Cost attribution))
단순히 지연 시간뿐만 아니라 작업 유형이나 에이전트 유형에 따라 라우팅할 수 있는가? (지능형 라우팅 (Intelligent routing))
에이전트가 왜 그런 결정을 내렸는지 확인할 수 있는가? (관측 가능성 (Observability))
에이전트별 비용 예산을 설정하고 이를 강제할 수 있는가? (비용 거버넌스 (Cost governance))
반복적인 에이전트 작업을 스케줄링할 수 있는가? (오케스트레이션 (Orchestration))
도구 (Tools), MCP, 기술 (Skills), 그리고 사용자 정의 규칙 (Custom rules)을 연결할 수 있는가? (확장성 (Extensibility))
게이트웨이가 얼마나 빠른가? (데이터 평면 성능 (Data plane performance))

대부분의 팀은 9번을 가장 먼저 묻습니다. 하지만 9번은 가장 마지막에 물어야 합니다.

실제로 작동하는 아키텍처

운영 환경의 에이전트 시스템에는 다음 두 가지가 모두 필요합니다:

빠른 데이터 평면 (Fast data plane): 요청 수준에서의 라우팅, 재시도 (Retries), 비용 추적을 위한 Bifrost, LiteLLM-Rust 또는 Helicone
신뢰할 수 있는 제어 평면 (Reliable control plane): 세션, 격리, 스케줄링 및 거버넌스를 위한 LiteLLM Agent Platform 또는 유사한 도구

지연 시간 벤치마크는 데이터 평면에 대해서만 알려줍니다. 제어 평면에 대해서는 아무것도 알려주지 않습니다.

오로지 데이터 평면의 지연 시간만을 기준으로 선택하는 팀은 결국 에이전트 세션, 비용 또는 멀티테넌시를 처리할 수 없는 빠른 게이트웨이만을 갖게 됩니다. 그들은 잘못된 문제를 해결하고 잘못된 시스템을 구축하게 됩니다.

이것이 귀하의 아키텍처에 의미하는 바

만약 에이전트 인프라를 평가하고 있다면:

계층을 분리하십시오 (Separate the layers). 모든 것을 하나의 벤치마크(Benchmark)로 측정하려고 하지 마십시오. 데이터 평면(Data plane)의 지연 시간(Latency)을 제어 평면(Control plane)의 신뢰성 및 기능적 깊이(Feature depth)와 별도로 측정하십시오.
올바른 것을 측정하십시오 (Measure the right things). 벤더(Vendor)들에게 다음과 같이 질문하십시오: 세션 지속성(Session persistence)은 어떻게 처리합니까? 비용 귀속(Cost attribution)은요? 멀티 테넌시(Multi-tenancy)는? 샌드박스 격리(Sandbox isolation)는? 관측 가능성(Observability)은? 이러한 요소들은 11µs와 8ms 사이의 차이보다 훨씬 더 중요합니다.
전체 워크플로우를 테스트하십시오 (Test the full workflow). 단일 LLM 호출만을 벤치마크하지 마십시오. 도구 호출(Tool calls), 재시도(Retries), 비용 추적(Cost tracking)을 포함한 완전한 에이전트 결정 과정을 벤치마크하십시오. 그것이 실제 운영 환경(Production)의 현실에 더 가깝습니다.
비용을 분리하십시오 (Separate costs). 데이터 평면(Data plane)은 빠르고 저렴해야 합니다 (범용 하드웨어 사용). 제어 평면(Control plane)은 신뢰할 수 있고 관리 가능해야 합니다 (요청당 비용은 더 높을 수 있지만, 요청 횟수는 더 적음).

규모 있는 에이전트를 구축하는 팀들은 11마이크로초(microsecond)의 게이트웨이 오버헤드를 쫓고 있지 않습니다. 그들은 세션이 충돌(Crash) 상황에서도 유지되고, 비용을 예측할 수 있으며, 에이전트를 실제 운영 환경에서 실제로 제어(Govern)할 수 있는 시스템을 구축하고 있습니다.

그것은 전혀 다른 차원의 문제들입니다. 그리고 지연 시간(Latency) 벤치마크는 이를 측정하지 못합니다.

Paul Twist는 베를린에 기반을 둔 AI 엔지니어입니다. 그는 에이전트를 위한 운영 인프라(Production infrastructure)를 연구하며, 데모에서 작동하는 것과 대규모 환경(Scale)에서 작동하는 것 사이의 간극에 대해 글을 씁.