월별 지출 상한선이 통제 불가능한 AI 에이전트 루프를 막지 못하는 이유

AI 에이전트를 운영해 본다면, 아마 월간 지출 한도를 설정하고 마음이 조금 놓였을 겁니다. 충분히 이해합니다. 하지만 월간 상한선은 '이번 달에 얼마까지 잃을 수 있는가?'라는 질문에 답할 뿐입니다. '지금 당장 이 에이전트를 어떻게 멈추는가?'라는 질문에는 답하지 못하죠. 이것들은 서로 다른 문제이며, 통제 불가능한 루프(runaway loops)는 그 사이의 간극에서 발생합니다.

제가 이 간극에 대해 배운 것들과 모든 스택을 위한 체크리스트를 공유합니다.

월간 및 청구서 상한선은 너무 늦게 작동한다

월간 상한선은 전체 계정에 대한 천장입니다. 이 한도가 초과되면 돈은 이미 나간 상태입니다. 보통 모든 것을 한 번에 멈추게 하는데, 문제가 생긴 에이전트든 정상적으로 작동하는 에이전트든 마찬가지입니다.

청구 알림(Billing alerts)도 같은 문제를 안고 있습니다. 사용량 데이터는 종종 지연되며, 잠자리에 들은 후에 도착하는 이메일로는 아무것도 막을 수 없습니다. 일반적인 작업을 방해하지 않을 만큼 충분히 높은 상한선은, 하나의 잘못된 루프가 엄청난 양의 자원을 소모하도록 내버려 두기에 충분히 높습니다.

더 나은 질문은 더 좁아야 합니다. 이 특정 에이전트가 이 특정 작업에 대해 무언가를 일시 중지하기 전에 얼마까지 지출하도록 허용해야 하는가?

루프와 재시도는 비용을 조용히 증가시킨다

에이전트 루프는 결코 극적이지 않습니다. 마치 끝나지 않는 정상적인 작업처럼 보입니다. 테스트가 실패하면, 에이전트는 그것을 '수정'하고, 테스트는 같은 방식으로 다시 실패하며, 이 과정이 반복됩니다. 또는 도구 호출(tool call)에서 오류가 반환되면 에이전트가 거의 동일한 입력으로 재시도합니다. 그 사이에 컨텍스트(context)는 계속 커지기 때문에, 모든 호출은 이전보다 더 많은 비용을 발생시킵니다.

이러한 과정 중 어느 것도 예외(exception)를 던지지 않습니다. API 입장에서는 모든 호출이 성공했다고 인식합니다. 비용이 증가하는 이유는 아무것도 턴 수(turns), 반복된 작업 또는 작업당 지출액을 계산하지 않기 때문입니다. 반복 감지(Repeat detection)는 각 시도가 저렴하더라도 '같은 것을 다시 하는' 상황을 포착하기 때문에 별도의 제어 기능이 필요합니다.

에이전트별 예산, 그리고 전체가 아닌 하나의 에이전트를 일시 중지하는 것

각 에이전트(또는 각 작업, 또는 각 API 키)에 해당 작업 규모에 맞는 개별 예산을 할당해야 합니다. 코드 리뷰 봇과 장시간 리팩토링 에이전트는 같은 자원 풀을 공유해서는 안 됩니다.

예산이나 루프 제한에 도달하면, 올바른 조치는 해당 에이전트 하나를 일시 중지하고 나머지는 그대로 두는 것입니다. 종료시키는 것보다 일시 중지하는 것이 낫습니다(Paused beats killed). 무엇을 했는지 확인할 수 있고, 프롬프트를 수정하거나 제한을 높인 후 작업을 잃지 않고 재개할 수 있습니다.

이는 모든 요청에 해당 에이전트와 태스크를 태그해야 함을 의미합니다. 누가 사용했는지 알 수 없다면, 그것을 제한할 수도 없습니다.

속도 제한(Rate limits): 실패만 하지 말고 큐잉하고 백오프하라

속도 제한은 과지출과는 다른 종류의 실패이지만, 루프를 더 악화시킵니다. 429 에러를 받고 즉시 재시도하는 에이전트는 하나의 속도 제한을 재시도 폭풍(retry storm)으로 바꿀 수 있습니다.

저는 속도 제한 처리를 에이전트 외부에서 하는 것이 낫다고 생각합니다. 요청을 큐잉하고, Retry-After 헤더를 준수하며, 지터(jitter)와 함께 백오프하고, 준비가 되었을 때 에이전트에 응답을 전달해야 합니다. 만약 대기 시간이 너무 길어지면, 또 다른 재시도를 유도하는 모호한 오류가 아니라 명확하고 구체적인 오류를 반환해야 합니다.

미터(Meter)를 에이전트 밖에 두라

만약 예산이 시스템 프롬프트(

• 에이전트 또는 프로젝트별로 별도의 API 키를 사용하고, 제공업체 측에서 가능한 제한을 설정합니다.
• 모든 에이전트 루프에 반복 횟수 상한(iteration cap)을 설정합니다. 대부분의 프레임워크가 이를 지원합니다 (max_iterations, max turns). 의도적으로 이 설정을 적용해야 합니다.
• 작업별 지출 추적 기능을 구현하여, 요청마다 토큰과 비용을 기록하고 에이전트 및 작업으로 태그를 지정합니다.
• 반복 감지(Repeat detection) 기능을 통해 동일한 도구 호출이나 거의 동일한 프롬프트를 연속적으로 여러 번 플래그 지정합니다.
• 속도 제한 처리(Rate-limit handling)를 한 곳에서 관리하고, 백오프(backoff) 및 Retry-After 지원을 구현합니다.
• 에이전트를 종료시키기보다 일시 중지(Pause)하는 방식을 사용해야 합니다. 에이전트가 상태를 유지할 수 있도록 해야 합니다.
• 에이전트가 무시하거나 재정의할 수 없는 프롬프트 외부에서 강제합니다.
• 월별 상한선은 가장 마지막 방어선으로 남겨두고, 첫 번째 방어선으로 사용해서는 안 됩니다.

현재 상황 (Where I'm at)

솔직히 말씀드리자면, 저는 텍사스에 위치한 소규모 베테랑 소유 기업인 Flaming Ape LLC를 운영하고 있으며, AI 에이전트 앞에 배치되어 에이전트별 예산 및 속도 제한 대기열을 처리하는 무료 오픈소스 자체 호스팅 코어인 Gorilla Warden을 개발하고 있습니다. 아직 공개되지는 않았습니다. 핵심 안전 아키텍처는 구현되었고 집중 테스트를 통과했습니다. 통합 작업, 적대적 테스트(adversarial testing), 그리고 독립적인 검토가 남아 있으며, 2026년 11월에 GitHub에서 무료 공개 베타 버전을 목표로 하고 있습니다. 저 역시 AI의 도움을 받아 개발하고 있기 때문에 (Claude Code, Codex 및 Grok), 이 문제가 제게는 더욱 중요합니다.

저만 이런 고민을 하는 것은 아닙니다. LiteLLM의 프록시(proxy)는 이미 키별, 팀별 예산과 속도 제한을 처리하며, 대부분의 에이전트 프레임워크에는 반복 횟수 상한 기능이 탑재되어 있습니다. 어떤 것을 사용하든 조언은 유효합니다: 에이전트당 제한을 설정하고, 반복되는 것을 포착하며, 계측기를 에이전트 외부로 유지하고, 월별 상한선을 최후의 보루로 남겨두어야 합니다.

저는 퇴역 해군 장교이자 787기 교관인 Ken입니다. 항공 분야에서는 하나의 안전장치만 믿지 않고 여러 겹으로 쌓습니다(layer them). 여기도 같은 원리가 적용됩니다.

따라가고 싶으시다면: https://flamingape.ai

귀하의 팀은 통제 불능 에이전트(runaway agents)를 어떻게 처리하시나요? 듣고 싶습니다.

AI 도움을 받아 작성하고, 제가 검토 및 편집했습니다.