다중 API 속도 제한 문제
사용자의 AI 에이전트가 CRM, 데이터베이스, 검색 API, 알림 서비스에 연결되어 있습니다. 각각이 자체 속도 제한을 갖습니다. CRM은 분당 100개 요청을 허용합니다. 검색 API는 초당 10개를 허용합니다. 알림 서비스는 일일 1,000개를 허용합니다. 에이전트는 본질적으로 이러한 제한 어느 것에 대해서도 모릅니다. 필요한 만큼 빠르게 도구를 호출하다가, 제한에 부딪히면 오류를 받습니다.
적절한 처리 없이는 rate limit 오류가 연쇄됩니다. 에이전트가 즉시 재시도하고, 다시 제한에 부딪히고, 다시 재시도하면서, 아무것도 달성하지 못한 채 오류 예산을 다 써 버립니다. 좋은 rate limit 처리는 이를 관리 가능한 상황으로 바꿉니다.
잘 작동하는 백오프 전략
지수 백오프가 표준 접근입니다. 첫 실패 후 1초, 두 번째 후 2초, 세 번째 후 4초, 식으로 기다립니다. 약간의 무작위성(지터)을 더하셔서 같은 API에 부딪히는 여러 에이전트가 정확히 같은 순간에 모두 재시도하지 않게 해 주십시오. 대부분의 MCP 서버는 이를 투명하게 구현할 수 있어, 에이전트는 오류 대신 약간 지연된 응답만 보게 됩니다.
API가 제공할 때, Retry-After 헤더가 더 좋습니다. 정확히 얼마나 기다려야 할지 알려 줍니다. 존재하면 항상 존중해 주십시오. 일부 API는 Retry-After를 무시하고 계속 두드리시면 더 긴 기간 동안 차단합니다.
요청 예산 책정
속도 제한에 부딪힌 후 반응하시는 대신, 요청 예산을 사전에 관리해 주십시오. CRM이 분당 100개 요청을 허용하면, MCP 서버가 현재 윈도우에서 만든 요청 수를 추적하고 벽에 부딪히기 전에 속도를 늦출 수 있습니다. 이는 제한에 부딪히고 백오프하는 멈춤-시작 패턴을 피하게 해 줍니다.
일일 제한(그 1,000개 알림 제한 같은)에 대해서는 요청 예산이 결정적입니다. 에이전트가 첫 한 시간에 일일 예산을 다 써 버리면, 남은 23시간 동안 옴짝달싹 못합니다. 요청을 하루에 걸쳐 고르게 분산시키시거나 예산의 일부를 높은 우선순위 사용을 위해 예약하시면 이를 막을 수 있습니다.
서버 간 조율
여러 에이전트나 세션이 같은 API 자격 증명을 공유할 때, rate limit 조율이 더 어려워집니다. 에이전트 A와 에이전트 B 둘 다 같은 API key로 같은 CRM에 연결됩니다. 각각 분당 100개 요청을 갖고 있다고 생각하지만, 실제로는 그 예산을 공유하고 있습니다. 조율 없이는 둘 다 예상 속도의 절반에서 제한에 부딪힐 것입니다.
모든 에이전트가 요청을 만들기 전에 점검하는 공유 속도 제한기(Redis 기반 토큰 버킷이나 비슷한 것)가 이를 해결합니다. MCP 서버는 외부 API를 호출하기 전에 공유 제한기를 점검하고, 예산이 소진되었다면 백오프합니다. 이는 약간의 복잡도를 더하지만 조율되지 않은 접근에서 오는 예측할 수 없는 실패를 막습니다.
우아한 성능 저하
때로는 rate limit에 대한 옳은 대응이 "기다리고 재시도"가 아닙니다. "이 단계를 건너뛰고 계속"입니다. 에이전트가 100개 레코드를 풍부화하고 있는데 60번째 레코드에서 풍부화 API의 rate limit에 부딪히면, 15분 동안 막히는 대신 남은 레코드를 "풍부화 대기"로 표시하고 작업의 나머지를 완료하는 편이 더 좋을 수 있습니다. 다른 곳에서 논의된 캐싱 전략도 처음부터 제한에 부딪히는 빈도를 줄일 수 있습니다.