에이전트 재시도 폭풍이 API를 위협하고 있으며, 기존 라이브러리로는 해결할 수 없습니다
Agent retry storms are coming for everyone's APIs and No Library will save you
핵심 요약
에이전트 규모가 커질 때 발생하는 API 재시도 폭풍 문제와 이를 해결하기 위한 조정 계층의 필요성을 다룹니다.
- 재시도 폭풍 — 에이전트가 독립적으로 재시도할 때 발생하는 API 과부하 문제.
- 확장성 한계 — 기존 라이브러리의 재시도 로직이 대규모 에이전트 환경에서 작동하지 않음.
- 조정 계층 — API 호출을 중앙에서 제어하고 지역별 장애를 회피하는 솔루션 제안.
- 생산성 손실 — 워크플로우 중간 단계의 실패로 인한 컴퓨팅 자원 낭비 문제.
LangChain이나 LangGraph 에이전트를 프로덕션 환경에서 운영 중이라면, 정말 궁금한 게 하나 있습니다. 워커를 몇 개 이상으로 확장할 때 외부 API에 대한 재시도를 어떻게 처리하고 계신가요?
왜냐하면 지금 곧 문제가 터질 상황이기 때문입니다.
아무도 말하지 않는 에이전트 수학
에이전트 워크플로우는 LLM 제공업체, 도구, 데이터 소스 등 50개의 API 호출을 수행합니다. 워커가 5개일 때는 지수 백오프(exponential backoff)로 가끔 발생하는 429 에러를 처리할 수 있습니다. 괜찮죠.
그런데 자율 에이전트 워크플로우를 실행하는 워커가 100개라면 어떨까요? 제공업체 중 한 곳에서 부분적인 장애가 발생합니다. 완전히 죽은 건 아니고 그냥 느려진 상태죠. 로그에 500 에러는 없습니다. 단지 2초 걸리던 응답이 10초 걸릴 뿐입니다. 모든 워커가 독립적으로 재시도합니다. 100개 워커 × 3번 재시도 = 300개의 요청이 이미 힘겨워하는 엔드포인트를 강타합니다. DNS는 계속해서 모든 요청을 성능이 저하된 동일한 지역으로 라우팅합니다. 당신의 재시도 로직이 모두가 의존하는 API를 DDoS 공격한 셈입니다. 그리고 그 엔드포인트를 사용하는 다른 모든 팀도 똑같은 짓을 하고 있죠.
내부 서비스 vs 외부 API — 근본적으로 다릅니다
자체 마이크로서비스는 양쪽을 모두 제어할 수 있습니다. 속도 제한을 설정하고, 큐 깊이를 확인하고, 수정 사항을 배포하죠. 하지만 외부 API는 지역별 상태를 볼 수 없고, 얼마나 많은 다른 사용자가 엔드포인트를 공유하는지 알 수 없으며, 재시도 로직은 완전히 눈먼 상태입니다. 재시도는 API를 공유하는 전체 커뮤니티의 상황을 더 악화시킵니다.
이 차이는 중요합니다. LangChain 생태계가 신뢰성을 위해 사용하는 도구들(재시도 데코레이터, LiteLLM 폴백, 서킷 브레이커)은 모두 내부 서비스나 단순한 클라이언트-서버 호출을 위해 설계되었습니다. 이들은 워커 간에 조정할 수 없습니다. 부분적인 지역 장애를 감지할 수 없습니다. 시끄러운 이웃(noisy neighbors)으로부터 트래픽을 격리할 수도 없습니다.
LangGraph 워크플로우 30단계에서 무슨 일이 벌어질까요
에이전트가 한 시간 동안 실행되었습니다. 29번의 API 호출은 성공했죠. 그런데 30단계에서 속도 제한에 걸립니다. 워크플로우가 중단됩니다. 1단계부터 다시 시작해야 합니다. 한 시간 동안의 컴퓨팅과 추론 비용은 날아갔습니다. 수백 개의 동시 워크플로우에 이를 곱하면 낭비는 엄청나집니다.
이건 가설이 아닙니다. OpenRouter를 통해 에이전트를 실행하는 사람들은 이미 연쇄적인 429 에러와 쿨다운 스파이럴을 겪고 있습니다. 유료 사용자가 무료 사용자와 동일한 컴퓨팅 풀을 공유하기 때문에 속도 제한에 걸리는 것이죠. 이게 바로 애그리게이터 수준에서의 시끄러운 이웃 문제입니다.
제가 조정 계층을 만든 이유
이런 상황을 계속 지켜보는 게 지겨워서, Erlang BEAM 기반의 아웃바운드 API 호출 조정 계층인 EZThrottle을 만들었습니다.
핵심 아이디어: 사용자별, API 키별, 목적지별 큐 — SQS, Kafka, Redis로는 근본적으로 복제할 수 없는 수백만 개의 격리된 큐입니다. 지역 경주(Regional racing) — 여러 지역으로 동시에 요청을 보내 가장 빠른 응답을 취하고 나머지는 취소합니다. 워커가 sleep 루프에서 CPU를 낭비하지 않도록 요청 속도를 조절합니다. 성능이 저하된 지역을 자동으로 우회합니다. 워크플로우가 차단되지 않도록 웹훅으로 전달합니다. 제공업체 간 폴백 체인 — OpenAI가 속도 제한에 걸리면? 인프라 계층에서 자동으로 Anthropic과 Google로 경주를 시킵니다.
EZThrottle이 다운되면 SDK는 직접 호출로 돌아갑니다. 최악의 경우, 이전 상태로 돌아가는 것뿐입니다.
LangChain 커뮤니티를 위한 구체적인 제안
LangGraph 워크플로우를 프로덕션 수준으로 만들기 위한 2부작 시리즈를 작성했습니다:
-
1부 — 429 에러 처리 및 조정된 재시도: https://www.ezthrottle.network/blog/stop-losing-langgraph-progress

