당신의 AI 에이전트가 실패하는 이유는 환각 때문이 아니라 속도 제한 (Rate Limits) 때문입니다

제 에이전트들이 프로덕션 (Production) 환경에서 실패하기 시작했을 때, 저는 누구나 처음 하는 것처럼 환각 (Hallucinations)을 찾아 나섰습니다. 더 나은 프롬프트 (Prompts), 더 엄격한 출력 스키마 (Output schemas), 더 많은 가드레일 (Guardrails). 하지만 그 어떤 것도 상황을 개선하지 못했습니다. 왜냐하면 저는 잘못된 계층 (Layer)을 디버깅하고 있었기 때문입니다. 에이전트의 추론 (Reasoning)은 괜찮았습니다. 계속해서 무너지고 있었던 것은 바로 배관 (Plumbing) 이었습니다. 그리고 가장 큰 원인은 상상할 수 있는 가장 지루한 것이었습니다. 바로 속도 제한 (Rate limits)이었습니다.

이것은 비단 저만의 문제가 아닌 것으로 드러났습니다. 이는 현재 LLM 애플리케이션에서 나타나는 지배적인 프로덕션 실패 모드 (Failure mode)이며, 데모 (Demo)용으로는 적합하지 않기 때문에 거의 아무도 이에 대해 이야기하지 않습니다.

요약 (TL;DR) — 프로덕션 환경에서 에이전트를 무너뜨리는 것은 대개 잘못된 추론이 아니라 용량 (Capacity)입니다. 제공업체의 속도 제한 (Rate limits)은 이제 실제 트레이스 (Traces)에서 LLM 호출 오류의 가장 큰 원인 중 하나가 되었습니다. 데모는 한 번에 하나의 요청만 수행하지만, 프로덕션 에이전트는 수십 개의 체이닝 (Chained), 재시도 (Retrying), 동시 호출 (Concurrent calls)로 확장되며 데모에서는 전혀 닿지 않았던 제한 사항에 부딪힙니다. 해결책은 더 똑똑한 모델이 아니라 용량 엔지니어링 (Capacity engineering)입니다: 예산 책정 (Budgeting), 백프레셔 (Backpressure), 지터 (Jitter)를 포함한 재시도, 폴백 모델 (Fallback models), 그리고 캐싱 (Caching)입니다.

아무도 피치 덱 (Pitch deck)에 넣지 않는 데이터

여기 에이전트의 신뢰성 (Reliability)에 대한 제 생각을 재정립해 준 수치가 있습니다. Datadog의 실제 LLM 관측성 (Observability) 트레이스 분석에 따르면, 속도 제한 (Rate-limit) 오류는 모든 LLM 호출 실패의 거대한 비중을 차지했습니다. 2026년 3월 기준으로, 모든 LLM 스팬 (Span) 오류의 약 3분의 1이 속도 제한이었으며, 이는 수백만 건의 개별 오류 규모였습니다. 그들의 결론은 냉혹했습니다: LLM 애플리케이션의 지배적인 실패 모드가 용량 문제라면, 프롬프트 엔지니어링 (Prompt engineering)이 아니라 용량 엔지니어링 (Capacity engineering) 에 배로 집중해야 한다는 것입니다.

이 사실을 곱씹어 보십시오. 실패 모드는 모델이 멍청해서 발생하는 것이 아닙니다. 모델 제공업체가 "요청이 너무 많습니다 (Too many requests)"라고 말하는 것이며, 당신의 에이전트는 그 답변에 대한 아무런 계획이 없는 상태인 것입니다.

이는 모두가 작성하고 있는 더 넓은 의미의 "프로덕션 환경에서 에이전트가 실패하는" 이야기와 거의 완벽하게 일치합니다. 데모가 거짓말을 하는 이유는 악의가 아니라 구조적인 문제입니다. 데모는 단 하나의 깨끗한 요청, 단 한 명의 사용자, 단 하나의 해피 패스 (Happy Path)로 실행됩니다. 반면 프로덕션은 동시성 (Concurrency), 재시도 (Retries), 팬아웃 (Fan-out), 그리고 부하 (Load)의 환경이며, 이는 바로 속도 제한 (Rate-limit) 오류를 만들어내는 정확한 조건들입니다. "노트북에서 작동하는 것"과 "부하가 걸린 새벽 3시에 작동하는 것" 사이의 간극은, 사람들이 인정하는 것보다 훨씬 더 자주, 신뢰성이라는 가면을 쓴 용량 (Capacity)의 격차입니다.

에이전트가 챗봇보다 이 벽에 더 세게 부딪히는 이유

일반적인 챗봇은 사용자 턴당 한 번의 API 호출을 수행합니다. 하지만 에이전트는 전혀 다른 괴물입니다. 단 하나의 "작업 (Task)"은 다음과 같이 확장됩니다:

• 계획 (Planning) 호출 1회.
• 루프를 돌며 발생하는 N번의 도구 선택 (Tool-selection) 호출.
• 다음 단계를 결정하기 위한 각 도구 결과당 1회의 호출.
• 무언가 불안정할 때 발생하는 각 호출에 대한 재시도 (Retries).
• 종종 각자의 루프를 가진 한두 개의 하위 에이전트 (Sub-agent).

따라서 사용자의 단 한 번의 행동이 10~40회의 모델 호출로 이어지며, 이는 빈번하게 _동시적 (Concurrent)_이고, 빈번하게 _재시도 (Retrying)_됩니다. 이 배수 효과가 바로 에이전트의 핵심이며, 동시에 당신을 속도 제한 (Rate limit)으로 몰아넣는 정확한 원인이기도 합니다. 더 나쁜 것은 순진한 실패 대응 방식이 상황을 재앙으로 만든다는 점입니다. 호출 하나가 429 오류를 받으면, 프레임워크는 즉시 재시도하고, 그 재시도 또한 429를 받게 되며, 이제 당신은 단 하나의 속도 제한 오류를 전체 작업을 무너뜨리는 재시도 폭풍 (Retry storm)으로 바꿔버린 것입니다.

이를 수식으로 써보면 계산은 가차 없습니다. 당신의 제공업체가 분당 500회의 요청을 허용한다고 가정해 봅시다. 만약 각 에이전트 작업이 약 20회의 모델 호출로 팬아웃 (Fan-out)된다면, 단 25개의 동시 작업만으로도 전체 할당량 (Quota)이 포화됩니다. 이는 재시도가 단 한 번도 발생하기 전의 수치입니다. 결과로 나타나는 429 오류에 대해 순진하게 즉각적인 재시도를 추가하면, 시스템은 점진적으로 저하되는 것이 아니라 천장을 뚫고 수직 상승하며 무너집니다. 저는 이 패턴이 전개되는 것을 한두 번 본 것이 아니며, 그때마다 회의실에서의 첫 번째 본능은 "모델이 고장 났다"는 것이었습니다. 정작 모델은 실행조차 되지 않았는데 말입니다.

(https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fkcw0usb2uaz7iit0canq.png)

이것이 바로 서버리스 (serverless) 환경이 당신을 괴롭히는 지점이기도 합니다. Cloud Run에서는 트래픽 급증 시 새로운 인스턴스를 기쁘게 생성하며, 컴퓨팅 (compute) 자원은 원활하게 확장됩니다. 하지만 당신의 LLM 제공업체 할당량 (quota)은 컨테이너 수에 맞춰 확장되지 않습니다. 따라서 오토스케일링 (autoscaling)은 최악의 상황을 초래합니다. 더 많은 동시 에이전트 (concurrent agents)가 실행되도록 허용하고, 각 에이전트는 호출 팬아웃 (call fan-out)을 발생시키며, 이들은 모두 동일한 고정된 제공업체 할당량을 사용하려 하다가 한꺼번에 한계치에 도달하게 됩니다. 부하를 흡수해야 할 플랫폼이 오히려 부하를 증폭시켜 속도 제한기 (rate limiter)로 몰아넣는 도구가 되는 것입니다. 이는 진정으로 직관에 반하는 실패입니다. 컴퓨팅 대시보드에서 오토스케일링이 건강해 보일수록, 당신은 오토스케일링과 함께 확장될 수 없는 할당량을 더 세게 두드리고 있는 셈입니다.

용량 엔지니어링 도구 모음 (The capacity-engineering toolkit)

해결책 중 특별히 생소한 것은 없습니다. 분산 시스템 (distributed-systems) 전문가들이 수십 년 동안 사용해 온 것과 동일한 패턴들입니다. 다만 이 분야가 운영 (ops)이 아닌 프롬프트 엔지니어링 (prompt-craft)을 중심으로 성장했기 때문에, 대부분의 에이전트 코드베이스에는 아직 이식되지 않았을 뿐입니다. 제 신뢰성 수치를 실제로 변화시킨 방법들은 다음과 같습니다.

1. 단순히 재시도하지 말고, 예산(Budget)과 백프레셔(backpressure)를 관리하세요

본능적으로는 더 강하게 재시도(retry)하고 싶어집니다. 하지만 해결책은 ￤ 더 적게 보내는 것(￤)입니다. 모든 외부 모델 호출 앞에 동시성 제한기 (concurrency limiter, 예: 세마포어 (semaphore) / 토큰 버킷 (token bucket))를 배치하여, 앱이 애초에 알고 있는 제공업체 할당량을 초과하지 않도록 하세요. 예산이 가득 차면, 일단 대기열(queue)에 넣으세요. 바로 실행하고 재시도하지 마십시오. 이 단 한 번의 변화는 그 어떤 재시도 튜닝보다 더 큰 효과를 발휘하는데, 그 이유는 폭풍으로부터 회복하는 대신 폭풍 자체를 방지하기 때문입니다.

import asyncio

# 제공업체의 실제 제한치 미만으로 동시 실행 호출(in-flight calls)을 제한합니다.
...

2. 지터 (jitter)를 포함한 지수 백오프 (exponential backoff)로 재시도하세요

재시도를 할 때는 절대 즉시 재시도하지 말고, 절대 일정한 간격으로 재시도하지 마세요. 여러 워커(worker)로부터 발생하는 동기화된 재시도는 제한 사항을 다시 트리거하는 천둥 치는 들소 떼(thundering herd) 현상을 만들어냅니다. 무작위 지터 (jitter)를 포함한 지수 백오프 (exponential backoff)는 재시도 시점을 분산시킵니다.

import asyncio, random

async def with_backoff(fn, max_retries=5, base=0.5):
...

만약 제공자(provider)가 Retry-After 헤더를 보낸다면 이를 준수하세요. 이는 추측하는 것보다 훨씬 정확하게 얼마나 기다려야 하는지를 알려줍니다.

3. 단순한 실패가 아닌 폴백 모델 (Fallback model)

이를 증류 (distillation) 개념과 연결해 보세요. 모든 호출에 프런티어 모델 (frontier model)이 필요한 것은 아닙니다. 기본 모델이 속도 제한 (rate-limited)에 걸리면 더 저렴하거나 보조적인 모델(다른 제공자 또는 별도의 할당량(quota)을 가진 더 작은 모델)로 라우팅하세요. 중단된 작업보다는 품질이 다소 떨어진 답변이라도 얻는 것이 낫고, 하나의 할당량에 과부하를 주는 대신 두 개의 할당량 풀에 부하를 분산하게 됩니다. 이는 쉬운 90%의 작업에는 저렴한 학생 모델 (student model)을 사용하고, 어려운 작업에는 비싼 교사 모델 (teacher model)로 폴백하는 하이브리드 패턴과 동일합니다. 다만 이를 성능(capability)이 아닌 가용성(availability)에 적용한 것뿐입니다.

4. 공격적인 캐싱 (Cache aggressively)

에이전트 호출 중 놀라울 정도로 많은 비중이 거의 중복된 호출입니다. 동일한 도구 설명 (tool descriptions), 동일한 시스템 컨텍스트 (system context), 여러 실행에 걸친 동일한 하위 쿼리 (sub-queries) 등이 이에 해당합니다. 프롬프트/응답 캐싱 (Prompt/response caching)과 제공자 측의 프롬프트 캐싱 (prompt caching)을 재사용하면 제한기에 도달하는 호출량 자체를 줄일 수 있습니다. 가장 저렴한 속도 제한 오류는 아예 보내지 않은 요청입니다.

5. 용량 가시성 확보 (Make capacity observable)

보이지 않는 것은 설계할 수 없습니다. 속도 제한이 팀을 당혹스럽게 만드는 이유는 이것이 라벨링된 용량 문제로 나타나지 않고, 일반적인 "에이전트 실패" 오류로 나타나기 때문입니다. 오류 클래스 (error class) (429 오류 vs 타임아웃 vs 도구 오류)를 기록하고, 현재 진행 중인 동시성 (concurrency)과 429 발생률을 일급 메트릭 (first-class metrics)으로 추적하며 이에 대해 알림을 설정하세요. 저에게 가장 중요했던 변화는 텔레메트리 (telemetry)에서 단순히 "모델이 틀렸다"와 "제공자가 거절했다"를 분리하는 것이었습니다. 그렇게 하기 전까지는 모든 실패가 추론 버그 (reasoning bug)처럼 보였고, 계속해서 잘못된 계층 (layer)을 수정하게 됩니다.

사고 모델의 전환 (The mental model shift)

과거의 나에게 해주고 싶은 말은 이것입니다: LLM 제공업체의 할당량(quota)을 CPU처럼 탄력적인 자원이 아니라, 데이터베이스 연결 풀(database connection pool)처럼 공유되고 한정적이며 확장 불가능한 자원으로 취급하십시오. 컴퓨팅(Compute)은 탄력적으로 확장됩니다. 하지만 여러분의 분당 토큰 수(TPM)와 분당 요청 수(RPM) 할당량은 그렇지 않습니다. 이 점을 내재화하고 나면, 에이전트의 신뢰성 문제는 AI의 문제가 아니라 고전적인 분산 시스템(distributed-systems)의 용량(capacity) 문제로 보이기 시작할 것입니다. 이는 아주 좋은 소식입니다. 왜냐하면 우리는 이미 그런 문제들을 어떻게 해결하는지 알고 있기 때문입니다.

여기서 더 똑똑한 모델이 여러분을 구원해주지는 못합니다. 완벽하게 추론하는 GPT-6라 할지라도, 할당량을 초과하면 여전히 429 에러를 반환합니다. 2026년 에이전트의 신뢰성 경계선은 지능이 아니라 용량 엔지니어링(capacity engineering)에 있습니다.

만약 여러분이 프로덕션 환경에서 에이전트를 운영하고 있다면, 에러 유형(reasoning, capacity, tool integration)을 분리했을 때 실제로 가장 지배적인 실패 모드(failure mode)가 무엇인지 궁금합니다. 저는 점점 더 용량(capacity) 문제에 무게를 두고 있습니다. 제가 틀렸다면 댓글로 알려주세요.

출처 및 추가 읽을거리

• Datadog, "State of AI Engineering" (2026) — 프로덕션 트레이스(production traces)에서 LLM 호출 실패의 주요 원인으로서의 속도 제한(rate-limit) 에러.
• "Why AI Agents Fail in Production and How Engineering Teams Are Fixing It", C# Corner (2026).
• "The AI Agent Reliability Gap in 2026", DEV Community.
• "Why 88% of AI Agents Never Reach Production", Digital Applied (2026).