Amazon Bedrock가 이제 표준 AWS Service Quotas 콘솔에서 Mantle 엔드포인트의 분당 토큰 수 할당량을 노출한다. 모델별 input-tokens-per-minute와 output-tokens-per-minute 한도를 직접 읽을 수 있고, AWS의 다른 모든 항목에서 이미 사용하던 동일한 워크플로로 증액을 요청할 수 있다. 사소한 콘솔 변경처럼 들린다. 하지만 멀티 에이전트 시스템을 운영 환경에서 돌리는 사람에게 이것은 용량을 미리 계획하느냐, 아니면 429의 벽으로 그것을 발견하느냐의 차이다.

핵심을 다시 정리하면 이렇다. 에이전트형 워크로드에서는 분당 요청 수가 아니라 분당 토큰 수가 진짜 확장 한계다. 대부분의 팀은 데모에서는 멀쩡히 돌아가던 agent 함대가 실제 트래픽에서 throttling을 당하기 시작할 때까지 이 사실을 체득하지 못한다. 이제 그 숫자가 보이게 되었으니, 할 일은 그것을 갑작스러운 사고가 아니라 용량 계획처럼 다루는 것이다.

Mantle이란 무엇인가, 간단히

Bedrock Mantle 엔드포인트(bedrock-mantle)는 OpenAI Responses API, OpenAI Chat Completions API, 그리고 Anthropic Messages API를 Bedrock 위에서 제공하는 엔드포인트로, 그 네이티브 API들에 맞춰 작성된 코드를 최소한의 변경만으로 사용할 수 있게 해준다. 기존의 OpenAI 또는 Anthropic 형태의 agent를 호출 지점 재작성 없이 Bedrock로 가리킬 수 있게 해주는 것이 바로 이것이다. 이번 할당량 변경으로 그 엔드포인트 뒤의 각 모델이 이제 자신의 input과 output TPM 한도를 일급 Service Quotas 항목으로 보고하게 되었다.

agent에게는 왜 RPM이 아니라 TPM이 상한선인가

전통적인 API 기반 앱은 토큰을 대체로 사용자 수에 비례해 소비한다. 하나의 요청, 하나의 응답, 예측 가능한 크기다. 분당 요청 한도가 지켜봐야 할 대상이다.

에이전트형 시스템은 그 비례 관계를 깨뜨린다. 단일 사용자 작업이 팬아웃된다. 플래너 agent가 작업을 분해하고 서브 에이전트를 띄우며, 각 서브 에이전트는 여러 번 tool call을 하고, 각 호출은 system prompt, 누적된 컨텍스트, tool schema, 그리고 다시 빠져나오는 모델의 추론 결과를 함께 실어 나른다. 사용자에게 보이는 하나의 작업이 치르는 token 비용은 하나의 프롬프트와 하나의 완성이 아니다. 그것은 수십 개이고, 컨텍스트는 매 단계마다 커지는 경향이 있다.

그러니 토큰 소비량은 사용자 수가 아니라 agent 수 × 단계 수 × 컨텍스트 크기에 비례해 늘어난다. 어떤 요청 속도 한도에도 한참 못 미치는 상태에서도 분당 토큰 수 상한선을 그대로 뚫어버릴 수 있다. 각 요청이 크고, 작업 하나당 그런 요청이 여러 개이기 때문이다. 이것이 바로 모델별 TPM 숫자를 지켜봐야 하는 이유이고, 그것이 Service Quotas에 들어온 것이 중요한 이유다.

실패 양상, 순서대로

TPM 선을 넘으면 Bedrock는 ThrottlingException(HTTP 429)을 반환한다. 그 자체만으로는 괜찮다. 문제는 멀티 에이전트 시스템이 그다음에 하는 행동이다.

  • throttle된 호출이 backoff를 두고 재시도한다. 같은 분 안에 동일한 모델별 할당량에 부딪힌 다른 agent들도 마찬가지다.
  • 재시도 자체가 동일한 상한선에 대한 token 소비이므로, 부하 상태의 함대는 스스로를 계속 throttle된 상태로 유지할 수 있다.
  • 호출이 backoff 타이머 뒤에 줄을 서면서 지연이 치솟는다. 8초 걸리던 작업이 이제 40초가 되거나 타임아웃된다.
  • 부분 실패는 agent들을 불일치 상태로 남긴다. 플래너는 서브 작업이 실행됐다고 여기는데, 서브 에이전트는 출력 토큰을 단 하나도 받지 못한 상태다.

이 중 어느 것도 단일 사용자 개발 환경에서는 드러나지 않는다. 개발자 한 명은 한도를 넘길 만큼의 분당 토큰을 결코 만들어내지 못하기 때문이다. 그것은 실제 동시성이 처음 도착하는 순간 드러나는데, 바로 그때가 자신의 상한선을 알게 되기에 가장 최악의 타이밍이다.

출시 전에 토큰 예산을 모델링하라

계산은 어렵지 않으며, 사고로 계산되기 전에 종이 위에서 해둘 가치가 있다. 주어진 모델에 대해 다음을 추정하라.

tokens_per_minute =
    concurrent_tasks
  × agents_per_task
  × model_calls_per_agent
  × avg_tokens_per_call        # input + output
  × (1 / task_duration_minutes)

그런 다음 input과 output을 따로 떼어 이제 읽을 수 있게 된 input-TPM 및 output-TPM 할당량과 각각 비교하라. 둘은 독립적으로 관리되고, 에이전트형 출력(추론, 긴 tool 인자)은 과소평가하기 쉽기 때문이다. 예상 피크 시점에 추정 숫자가 할당량의 대략 70퍼센트를 넘는 어디쯤에든 앉아 있다면, 당신에게는 여유가 있는 것이 아니라 날짜가 적힌 미래의 사고가 있는 것이다.

가정하지 말고, 지켜봐라

콘솔을 클릭해 들어가는 대신 CLI에서 곧장 할당량을 나열할 수 있다.

aws service-quotas list-service-quotas \
  --service-code bedrock \
  --query "Quotas[?contains(QuotaName, 'tokens per minute')].[QuotaName,Value]" \
  --output table

이를 CloudWatch의 Bedrock 사용량 지표와 짝지어, 각 모델 TPM의 70~80퍼센트 지점에 알람을 설정하라. 목표는 상한선에 다가가고 있다는 사실을 금요일 밤에 사용자에게서가 아니라, 화요일에 대시보드에서 알아내는 것이다.

"할당량을 더 달라"가 아닌 완화책

증액 요청은 명백한 지렛대이고, 때로는 옳은 선택이다. 하지만 숫자를 올리는 것이 token을 부주의하게 쓰는 아키텍처를 고쳐주지는 않는다. 티켓을 제출하기 전에 다음을 하라.

  • 컨텍스트를 다듬어라. 가장 큰 에이전트형 토큰 낭비는 전체 히스토리와 모든 tool schema를 매 단계마다 끌고 다니는 것이다. 그 단계가 필요로 하는 것만 전달하라.
  • 프롬프트를 캐싱하라. 안정적인 system prompt와 tool 정의는 매 호출마다 동일한 토큰이다. prompt caching이 그것을 미터기에서 빼준다.
  • 동시성을 제한하고 큐를 두어라. 모델 앞단에 둔 경계가 있는 워커 풀은 토큰 급증을 throttling 폭풍 대신 조금 느리지만 살아남는 시스템으로 바꾼다.
  • 난이도에 따라 라우팅하라. 모든 단계가 최전선 모델을 필요로 하지는 않는다. 값싸고 기계적인 단계는 더 작고 저렴한 모델로 보내고, 비싼 모델은 그만한 값을 하는 추론에 아껴두라.
  • input과 output의 절제를 분리하라. 긴 출력은 자체 할당량으로 과금되고 throttle된다. 단계별 최대 출력 토큰을 제약해, 폭주하는 생성이 혼자서 output TPM을 먹어치우지 못하게 하라.

증액을 요청할 때는

Service Quotas에서 특정 모델의 input 또는 output TPM 항목에 대해 요청을 열고, 위의 예산 계산을 함께 가져가라. AWS는 낙관에서 뽑은 둥근 숫자보다, 추정 피크 부하와 작업당 token 분해를 보여줄 수 있을 때 증액을 더 빠르게 승인한다. 그것을 용량 요청으로 다루어라. 실제로 그것이 용량 요청이기 때문이다.

핵심 정리

Mantle의 토큰 할당량을 Service Quotas에 노출한 것은 필요조건이지 충분조건이 아니다. 숫자가 보인다고 해서 당신을 지켜주지는 않는다. 그저 그것에 놀랄 변명거리가 더는 없다는 뜻일 뿐이다. 에이전트형 시스템에서 분당 토큰 수는 하중을 떠받치는 한계이고, 신뢰할 수 있는 agent를 출시하는 팀은 AWS에 상한선을 올려 달라고 요청하기 전에 그 예산을 모델링하고, 모니터링하며, 자신의 토큰 소비를 미리 낮추도록 설계하는 팀이다.

다음으로 읽을 글

이것을 대규모로 안전하게 운영하기 위한 인프라와 플랫폼 측면에 대해서는, 클라우드 현장 노트가 ercan.cloud에 있다. 여기에는 agent가 절대 혼자 실행해서는 안 되는 고위험 작업을 위한 multi-party approval도 포함된다. AWS, AI, 플랫폼 작업에 대한 컨설팅이나 그냥 인사를 건네고 싶다면 ercanermis.com에서 시작하라.