AWS 멀티 에이전트 AI의 에이전트별 비용 추적

AI 요약

멀티 에이전트가 올바른 답을 반환하고 오류 없이 끝나도 실행 비용은 불필요하게 늘어날 수 있습니다. 기존 APM(Application Performance Monitoring)은 가동 여부, 지연 시간, 오류를 살피지만, 에이전트가 반복 추론을 하거나 같은 도구를 다시 호출하고 긴 컨텍스트를 다음 단계에 넘기는 상황은 놓치기 쉽습니다. 글은 이 문제를 해결하려면 실행 전체의 성공 여부뿐 아니라 에이전트별 추론 횟수, 도구 호출, 토큰 수와 비용을 추적해야 한다고 설명합니다.

저자는 AWS 계정을 읽기 전용으로 조사하는 에이전트 팀을 만들었습니다. AWS Strands Agents와 Amazon Nova Pro를 사용하고, 조사 지휘자 역할의 supervisor가 비용 분석, 운영 상태 확인, 보안 점검을 맡은 세 specialist 중 필요한 에이전트만 호출합니다. 각 에이전트는 Cost Explorer, EC2, CloudWatch, S3, Lambda, IAM, GuardDuty의 읽기 API를 사용합니다. 리소스를 생성·변경·삭제하는 권한은 주지 않습니다.

추적 데이터 설계

각 LLM 호출과 AWS 도구 호출을 OpenTelemetry(OTel) span으로 기록합니다. span에는 실행 시간뿐 아니라 에이전트 식별자, 추론 횟수, 도구 호출 수, 입력·출력 토큰, 비용을 넣습니다. 한 실행의 span 묶음은 trace로 볼 수 있습니다. 글에서는 supervisor와 specialist마다 별도 trace를 만들고, 같은 조사에서 나온 trace를 session.id로 연결합니다. agent.delegated_to에는 실제 호출한 specialist를 남깁니다. 이렇게 하면 독립적인 에이전트 단위와 전체 조사 단위를 오가며 비용을 볼 수 있습니다.

AWS Strands와 Bedrock 호출은 사용 토큰 정보를 돌려주지만, 당시 사용한 Traccia SDK는 Strands나 raw Bedrock 호출을 자동 계측하지 않았습니다. 저자는 입력 토큰과 출력 토큰에 Nova Pro의 us-east-1 기준 가격을 적용해 비용을 계산한 뒤 span에 기록했습니다. 글에 제시된 가격은 입력 1,000토큰당 0.0008달러, 출력 1,000토큰당 0.0032달러입니다. llm.model, span.type, 토큰 수를 span 속성으로 설정해야 비용 계산기가 비용을 산출합니다. 특히 llm.request.model처럼 다른 이름을 쓰면 오류 없이 비용 값이 0으로 남을 수 있습니다.

비용 집계에서 supervisor와 하위 에이전트의 토큰을 중복 계산하는지도 확인했습니다. Strands에서는 하위 에이전트의 누적 사용량이 supervisor 사용량에 포함되지 않아, supervisor 비용과 specialist 비용을 더하는 방식으로 전체 비용을 구했다고 합니다. 또 같은 프로세스에서 에이전트별 trace를 분리할 때 OTel 실행 컨텍스트를 끊어야 했고, 도구 호출 시간을 정확히 기록하려면 호출이 끝난 뒤 span을 재구성하지 말고 실제 boto3 호출을 감싸야 했습니다. 도구 span에도 호출한 에이전트 식별자를 넣어야 대시보드에서 올바른 에이전트에 묶입니다.

세 가지 낭비 패턴

저자는 정상 실행을 기준선으로 두고, 재현용 코드를 이용해 세 가지 패턴을 비교했습니다. 수치는 대표 실행의 예시이며 LLM 사용량에 따라 달라집니다.

첫째, 반복 추론과 재호출입니다. 기준 실행의 Health & Ops 에이전트는 3회 추론했고 입력 토큰은 2,274개였습니다. 낭비 실행에서는 4회 추론하며 CPU 사용률 도구를 두 번 읽었고 입력 토큰은 약 1.6배인 3,557개로 늘었습니다. 비용은 0.0083달러에서 0.0100달러로 약 1.2배가 됐습니다. 최종 답변은 같고 APM 상태도 200 OK지만 cycle count와 도구 호출 수가 증가한 점으로 이상을 찾습니다.

둘째, 불필요한 도구 재호출입니다. 실행 비용은 0.0083달러에서 0.0085달러로 약 1.03배에 그쳤지만, running_instances 도구를 한 번 대신 세 번 호출했습니다. 단일 실행에서는 작은 차이지만 반복 횟수가 많으면 누적 비용이 됩니다. 전체 비용만 보면 놓칠 수 있어 도구별·에이전트별 호출 횟수를 비교해야 합니다.

셋째, 컨텍스트 비대화입니다. 입력 토큰이 늘면 specialist 비용뿐 아니라 그 결과를 받아 요약하는 supervisor 비용도 함께 커질 수 있습니다. 제시된 실행에서는 전체 비용이 0.0083달러에서 0.0119달러로 약 43% 증가했고, 두 실행 모두 답변은 맞고 APM 상태는 200 OK였습니다. 저자는 에이전트별 prompt token과 비용을 기준선과 비교해 이 변화를 찾습니다.

감지 규칙은 간단합니다. 기준선보다 추론 횟수가 많으면 반복 루프 가능성을 표시하고, 입력 토큰이 기준선의 1.25배를 넘으면 컨텍스트 증가를 의심합니다. 도구별 호출 횟수가 기준선보다 늘어도 표시합니다. 이 규칙은 절대적인 비용 한도를 알아서 정하는 방식이 아니라, 같은 종류의 작업에서 알려진 정상 실행과 달라진 점을 찾는 방식입니다. 따라서 기준선을 만들 때 작업 유형이나 호출한 에이전트 구성이 다른 실행을 무작정 비교하면 안 됩니다.

구현과 도구의 한계

Traccia는 Apache-2.0 라이선스의 오픈소스 SDK이며 OTel 기반입니다. API 키가 없으면 trace를 로컬 파일로 내보내므로 호스팅 대시보드 없이도 사용할 수 있습니다. LangChain, CrewAI, OpenAI Agents 및 OpenAI·Anthropic·Gemini 클라이언트에는 자동 계측을 제공하지만, 글 작성 당시 Strands와 raw Bedrock 호출은 직접 연결해야 했습니다. 저자는 비용 연결 코드가 약 40줄이라고 설명합니다.

저자는 SDK 동작을 확인하며 문서에 드러나지 않은 제약도 찾았습니다. 비용 처리기가 필요한 span 속성을 찾지 못하면 조용히 건너뛰고, span_scope(parent=None)도 현재 OTel 컨텍스트를 상속할 수 있어 별도 trace를 만들려면 컨텍스트를 분리해야 합니다. 계측 방식을 바꿨을 때 도구 호출 횟수를 읽던 감지 코드가 더는 동작하지 않은 사례도 소개합니다. 추적 형식 변경이 감지 로직까지 깨뜨릴 수 있으므로, 계측과 비교 코드를 함께 검증해야 한다는 설명입니다.

dev.to 반응

• @sarvar_04 — 글 전체가 ‘약 1.4배 청구됐다’는 표현에 기대지만, 그 수치는 세 사례 중 가장 큰 값입니다. 실제 범위는 1.03~1.4배이고 절대 차이는 1센트 미만입니다(0.0083달러에서 0.0119달러). 이 계산을 해보는 독자는 과장된 느낌을 받을 수 있습니다. 본문처럼 정직하게 범위를 먼저 제시하고, 가장 눈에 띄지 않는 1.03배 낭비가 놓치기 쉽다는 점을 강조하면 신뢰를 지킬 수 있습니다.
• @steven_r_404 — 영상과 자세한 글을 함께 제공해서 정말 도움이 됩니다.
  • @sarvar_04 — 좋은 말씀 감사합니다.
• @jn_141414 — 오픈소스 도구인가요?
  • @adityasaroj — 네, Traccia는 오픈소스입니다. github.com/traccia-ai/traccia-py를 확인해 보세요.
  • @sarvar_04 — 네, 오픈소스입니다. GitHub 주소는 github.com/traccia-ai/traccia-py입니다.
• @salman_khan_c31307505285e — 컨텍스트 비대화 사례가 흥미롭습니다. 비용을 줄일 때 출력 토큰을 주로 살피지만, 프롬프트 쪽 토큰도 조용히 늘어날 수 있습니다.
• @adityasaroj — 자세하고 직접 실험한 내용이 좋습니다.
  • @sarvar_04 — 정말 감사합니다, Aditya.
• @brianainews — 멀티 에이전트 시스템에는 비용 가시성이 빠져 있는 제어 계층입니다. 성공한 실행도 중복 검색이나 컨텍스트 증가를 감출 수 있다는 점을 짚은 것이 좋습니다. 다음 단계로는 문제가 있는 분기만 멈추고 나머지 워크플로는 계속 실행하는 예산 경보가 있으면 좋겠습니다.
  • @sarvar_04 — 전체 워크플로를 멈추는 것보다 특정 분기에 예산 제한을 두는 편이 더 유용합니다. 문제가 있는 에이전트만 감지해 일시 중지하거나 제한하고 나머지 에이전트는 계속 실행하는 방식입니다. 런타임 계층이나 관측성 계층에서 어떻게 제어할지 궁금합니다.
• @pratikponde — 1.03배의 중복 호출 사례가 1.4배 사례보다 더 흥미롭습니다. 한 번 실행에서 작은 낭비는 무시하기 쉽지만, 수천 번 실행되면 달라집니다.
  • @sarvar_04 — 한 번 실행에서 3%는 사고처럼 보이지 않지만, 수천 번 반복되면 실제 비용 문제가 됩니다. 최종 AWS 청구액만 보지 않고 도구와 에이전트 수준에서 감지하려 한 이유입니다.
• @anasbuilds997 — 전체 워크플로가 아니라 에이전트별 비용을 추적해야 조용한 토큰 증가를 일찍 찾을 수 있습니다. 저희 멀티 에이전트 파이프라인에서는 재시도나 핸드오프 루프에서 중간 라우팅·평가 에이전트가 전체 토큰 예산의 60% 이상을 쓰면서 사용자에게 직접 보이는 결과를 만들지 않는 경우를 확인했습니다. 각 하위 에이전트 호출에 trace/span ID를 이어 붙이면 어느 에이전트가 달라졌는지 더 빨리 찾을 수 있습니다.
• @nomad-link-id — 200 OK인데 비용이 1.4배 더 나오는 상황은, 종료 코드는 0인데 결과가 비어 있는 상황과 비용 측면에서 닮았습니다. 평가 기준이 성공 형태, 즉 정답과 정상 APM만 본다면 멀티 에이전트 시스템은 의도하지 않은 중첩 호출로 비용을 쓰면서도 완료된 것처럼 보일 수 있습니다. 에이전트 역할별 성공 결과당 비용을 과업 성공 여부와 함께 확인하고, 합의한 지출 한도를 넘으면 실패 처리해야 합니다.
  • @sarvar_04 — 제가 생각한 방향도 같습니다. 기술적으로 성공한 실행이 효율적이거나 건강하다는 뜻은 아닙니다. 에이전트 역할별 성공 결과당 비용이 규모가 커질 때 더 나은 신호가 됩니다. 지출 한도를 비용과 따로 확인하지 않고 평가 기준에 포함한다는 생각도 좋습니다.
  • @nomad-link-id — 동의합니다. 흥미로운 예외는 한 에이전트는 성공 결과당 비용이 정상인데 다른 에이전트 분기만 조용히 1.4배를 쓰는 경우입니다. 역할별 한도는 이를 잡지만 전체 비용 한도 하나만 두면 문제 있는 specialist를 놓칠 수 있습니다. 문제가 있는 역할만 멈추는 분기 단위 제어는 평가 기준을 런타임에 적용하는 방법입니다.
• @mustkhim_inamdar — llm.model 문제를 잘 찾았습니다. 조용한 실패는 모든 것이 작동하는 것처럼 보이므로 명확한 오류보다 더 나쁠 수 있습니다.
• @pushpendraagrawal — 실행이 끝난 뒤 trace를 보면 패턴을 발견했을 때 이미 비용을 쓴 뒤입니다. 처음부터 단순한 도구 선택, 재시도, 서식 지정에는 저렴한 모델을 쓰고 실제 추론에만 비싼 모델을 쓰는 편이 낭비를 쌓이지 않게 하는 더 저렴한 해결책입니다.
• @sinarezaei — ‘같은 답, 다른 청구액’이라는 점이 기억에 남습니다. 기존 모니터링에서는 200 OK이고 지연 시간과 오류가 정상이면 요청도 건강하다고 여기기 쉽습니다. 하지만 멀티 에이전트에서는 추가 추론, 도구 재호출, 불필요한 컨텍스트 전달이 감춰질 수 있습니다. 전체 실행을 하나의 숫자로 묶지 않고 에이전트별 비용을 추적하면 비용이 디버깅 신호가 됩니다. 계측을 바꾸면서 감지 로직을 깨뜨린 사례도 좋았습니다. 실제 시스템에서 생기지만 깔끔한 데모에서는 빠지기 쉬운 문제입니다. 답변은 시스템이 무엇을 만들었는지 보여주고, trace는 그 결과에 어떤 비용이 들었는지 보여줍니다.
• @kartik-nvjk — 1.4배 과금 문제는 실제 멀티 에이전트 환경에서도 봤습니다. MAST 논문에서 실패가 오류로 끝나지 않고 완료된 것처럼 보이면서 비용을 쓴다는 점이 핵심입니다. 저는 모든 trace에 과업당 비용을 붙이기 시작했고, 어느 에이전트가 병목인지 바로 드러났습니다. 한 에이전트가 성공적으로 보이는 출력을 내지만 실제로는 비싼 쓰레기라 다음 에이전트가 정리해야 하는 상황은 어떻게 처리하나요?
  • @nomad-link-id — 그 상황은 겉보기에는 성공한 상위 에이전트의 수습 비용이 다음 에이전트에 넘어가는, ‘성공한 듯한 빈 결과’의 비용 버전입니다. 하위 에이전트가 수습하는 토큰 비용을 결과를 만든 에이전트 역할에 귀속하고, 그 역할의 사용 가능한 핸드오프당 비용이 한도를 넘으면 실행을 실패 처리하겠습니다. 그렇지 않으면 에이전트별 비용을 추적해도 비싼 쓰레기를 만든 specialist를 놓칠 수 있습니다.
• @raju_dandigam — agent-inspect에서 일하고 있어 올바른 답과 비효율적인 실행 경로를 구분하는 점에 공감합니다. llm.model이 없어 비용이 0으로 남는 문제는 기준선으로 잡아야 할 계측 실패입니다. supervisor가 비용 관련 질문에는 더 적은 specialist를 호출하므로, 기준선을 작업 유형과 위임된 에이전트 구성, 모델·가격 버전별로 나누시겠습니까? 그렇지 않으면 전체 계정 조사를 좁은 조사와 비교해 정당한 비용 증가를 컨텍스트 비대화로 오해할 수 있습니다.

원문: dev.to / 번역·요약: Trawling