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

AI 요약

정답을 내고 응답 코드도 200인 에이전트 실행이 기준보다 1.4배 비쌀 수 있습니다. 기존 애플리케이션 성능 모니터링(APM)은 가용성, 지연 시간, 오류를 살피지만, 에이전트가 추론을 몇 번 반복했는지, 같은 도구를 다시 호출했는지, 어느 에이전트가 토큰을 썼는지는 놓치기 쉽습니다. 글은 멀티 에이전트 실행의 비용 낭비를 찾으려면 각 단계에 토큰과 비용, 호출 횟수, 담당 에이전트를 기록해야 한다고 설명합니다. 인용한 MAST 연구는 7개 멀티 에이전트 시스템의 트레이스 150개를 분석해 실패율 41~86.7%를 보고했으며, 많은 실패가 충돌 없이 정상 완료처럼 보였다고 합니다.

구성과 계측

예제는 AWS 계정을 읽기 전용으로 조사하는 에이전트 팀입니다. 감독 에이전트가 질문에 맞춰 비용 분석가, 운영 담당자, 보안 감사자 중 필요한 전문가만 호출합니다. 각 전문가는 Cost Explorer, EC2, CloudWatch, S3, Lambda, IAM, GuardDuty의 조회 API를 사용합니다. AWS 리소스를 생성·수정·삭제하지 않으며, 실제 실행에는 Amazon Nova Pro와 Bedrock 호출 권한이 필요합니다.

저자는 OpenTelemetry 기반 관측 SDK인 Traccia를 사용합니다. 로컬 파일 내보내기는 계정이나 네트워크 연결 없이 무료로 실행하며, 호스팅 대시보드는 선택 사항입니다. Traccia는 LangChain, CrewAI, OpenAI·Anthropic·Gemini 클라이언트를 자동 계측하지만, 글 작성 시점에는 Strands와 직접 호출하는 Bedrock을 자동 계측하지 않습니다. 따라서 Bedrock 응답에서 입력·출력 토큰 수를 읽고 모델 가격을 곱해 비용을 계산한 뒤, 에이전트의 트레이스에 직접 기록합니다. 예시의 Nova Pro 가격은 us-east-1 기준 입력 1,000토큰당 0.0008달러, 출력 1,000토큰당 0.0032달러입니다.

비용 집계에는 속성 이름도 중요합니다. Traccia의 비용 처리기는 span.type이 LLM이거나 비어 있고, llm.model과 두 토큰 수가 있어야 비용을 계산합니다. 저자가 llm.request.model을 설정했을 때는 오류 없이 처리가 건너뛰어져 대시보드에 토큰과 비용이 0으로 표시됐습니다. llm.model로 바꾸자 값이 나타났습니다. 또한 Strands 하위 에이전트의 토큰은 감독자 사용량에 포함되지 않으므로, 전체 비용은 감독자와 하위 에이전트 비용을 더해 계산합니다.

트레이스 모델과 시행착오

저자는 감독자와 전문가를 하나의 부모·자식 트레이스로 묶는 대신, 각 에이전트에 별도 최상위 트레이스를 부여하고 session.id로 한 조사에 연결합니다. 각 트레이스는 에이전트별 비용과 토큰을 보여주며, 세션 단위로 묶으면 전체 실행을 볼 수 있습니다. 이 구성을 위해 각 span에 에이전트 정체성을 직접 기록하고, OpenTelemetry 컨텍스트를 분리해야 했습니다. span_scope(parent=None)만으로는 활성 컨텍스트가 계속 상속돼 여러 에이전트의 트레이스가 합쳐졌기 때문입니다.

도구 호출은 실제 boto3 요청이 진행되는 동안 span으로 감싸야 정확한 실행 시간이 기록됩니다. 실행 후 메트릭만으로 span을 만들면 도구 시간이 0ms로 나타났습니다. 또 도구 span에도 호출한 에이전트의 정체성을 넣지 않으면 대시보드에서 감독자 소속으로 묶였습니다. 도구 목록과 실제 호출 목록을 함께 기록하면 에이전트가 부여받은 권한과 사용한 기능의 차이도 확인할 수 있습니다.

기준선으로 찾은 세 가지 낭비

저자는 정상 실행 한 건을 기준으로 삼고 세 가지 상황을 재현합니다. 반복 루프에서는 운영 에이전트가 기준보다 한 번 더 추론하고 CPU 정보를 다시 읽어 비용이 0.0083달러에서 0.0100달러로 약 1.2배 늘었습니다. 중복 도구 호출은 같은 인스턴스 조회를 한 번 대신 세 번 실행해 0.0085달러, 약 1.03배가 됐습니다. 컨텍스트 비대화 사례에서는 입력 토큰이 늘고 감독자에게 전달되는 내용도 커져 비용이 0.0119달러로 증가했습니다. 기준 0.0083달러와 비교하면 약 43% 상승입니다. 세 사례 모두 답은 맞고 APM 상태도 200 OK입니다.

탐지기는 복잡하지 않습니다. 기준보다 추론 주기가 늘면 반복 루프 가능성, 프롬프트 토큰이 1.25배를 넘으면 컨텍스트 비대화 가능성, 도구별 호출 횟수가 늘면 중복 호출 가능성을 표시합니다. 단, 저자는 이 기준이 한 번의 정상 실행을 바탕으로 한 데모 수준이라고 댓글에서 인정합니다. 모델의 변동 폭이나 질문 난이도를 반영하려면 여러 번 실행해 분포를 만들고 요청 유형별 기준선을 마련해야 합니다. 실행 결과에 따라 기준을 분류하면 오히려 비정상 경로를 정상으로 학습할 수 있다는 지적도 나옵니다.

적용 시 고려할 점

기준선 비교는 프롬프트, 모델, 도구 구성의 변화에 영향을 받습니다. 글은 가격이나 프롬프트 버전별 기준선 관리, 여러 정상 실행의 통계적 변동 폭을 다루지 않습니다. 또한 비용을 토큰을 실제 사용한 에이전트에 붙이므로, 앞선 에이전트가 불필요한 내용을 만들어 다음 에이전트의 비용을 키운 경우 원인을 만든 쪽과 비용을 쓴 쪽이 달라질 수 있습니다. 댓글에서는 이 문제를 해결하려면 생성된 컨텍스트와 후속 입력 사이의 계보를 기록하고, 측정값과 비례 배분 같은 추정값을 구분해야 한다는 제안이 이어집니다.

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

dev.to 반응

• @sarvar_04 — 글의 도입부는 ‘약 1.4배 청구’에 기대고 있지만, 그 수치는 세 사례 중 가장 큰 값입니다. 실제 범위는 1.03~1.4배이고, 절대 금액도 0.0083달러에서 0.0119달러로 1센트보다 작습니다. 가장 놓치기 쉬운 사례가 1.03배라는 점을 앞세우면 본문의 신뢰성을 지킬 수 있습니다.
• @pratikponde — 1.4배 사례보다 1.03배 중복 호출 사례가 더 흥미롭습니다. 한 번의 실행에서는 작은 낭비처럼 보여도 수천 번 반복되면 비용이 커집니다.
  • @sarvar_04 — 한 번의 실행에서 3%는 문제처럼 보이지 않지만, 매일 수천 번 반복되면 실제 비용 문제가 됩니다. 그래서 최종 AWS 청구액만 보지 않고 도구와 에이전트 수준에서 탐지하려고 했습니다.
• @salman_khan_c31307505285e — 컨텍스트 비대화 사례가 흥미롭습니다. LLM 비용을 줄일 때 출력 토큰은 살펴보면서 입력 프롬프트가 조용히 커지는 점은 놓치는 경우가 많습니다.
  • @sarvar_04 — 출력 토큰은 눈에 잘 띄지만 프롬프트 쪽은 서서히 커집니다. 비대해진 하위 에이전트의 내용이 감독자에게 전달돼 감독자 비용도 늘어납니다. 에이전트별 입력 토큰을 살펴본 덕분에 찾았고, 실행 전체 토큰만 봤다면 놓쳤을 겁니다.
• @brianainews — 에이전트별 비용을 보여주는 점이 실제 조치에 유용합니다. 전체 비용은 괜찮아 보여도 특정 플래너나 재시도 루프가 예산을 태울 수 있습니다. 비용과 함께 지연 시간과 재시도 횟수도 기록하나요?
  • @sarvar_04 — 도구 span에는 실제 호출 시간이 기록되고, 추론 주기도 기록합니다. 별도의 재시도 횟수는 아직 없으며, 현재는 주기 증가와 반복 도구 호출로 추정합니다. 전용 카운터가 더 낫다는 지적은 맞습니다.
• @aifrontierpost — 기준선은 프롬프트, 모델, 도구가 바뀌면 낡습니다. 기준선을 버전별로 관리하거나 이동 분위수를 쓰지 않으면 배포 때마다 오탐이 나고 팀이 알림을 끌 수 있습니다. 컨텍스트 비대화 사례에서는 하위 에이전트의 입력 증가가 감독자 비용에도 나타나므로, span별 비용만으로 낭비의 최초 원인을 놓칠 수도 있습니다.
• @mihai_leanzero — 비결정적인 실행을 정상 기준선 한 건과 비교하면 모델의 표현 차이를 낭비로 오해할 수 있습니다. 정상 실행도 여러 번 돌려 자연 변동 폭을 확인했나요?
  • @sarvar_04 — 현재는 정상 실행 한 건을 기준으로 삼았으며, 여러 번 실행해 변동 폭을 확인하지 않았습니다. 1.25배 임계값이 낭비가 아니라 모델의 표현 차이를 재는 부분도 있을 수 있습니다. 여러 번 실행해 분포를 만들고, 질문 유형별 기준선을 두는 편이 맞습니다. 지금 기준선은 통계적으로 엄밀한 기준이 아니라 데모용입니다.
• @pushpendraagrawal — 트레이스로 패턴을 찾을 때는 이미 비용을 쓴 뒤입니다. 도구 선택, 재시도, 포맷 같은 단순 작업을 저렴한 모델로 보내고 실제 추론에만 비싼 모델을 쓰면 낭비가 쌓이기 전에 막을 수 있습니다.
  • @sarvar_04 — 두 방법은 대안 관계가 아닙니다. 트레이스로 비싼 작업을 찾아 저렴한 모델로 옮기고, 이후에도 비용과 반복 여부를 계속 확인하면 됩니다.
• @raju_dandigam — 비용 기준선을 요청 유형, 위임된 에이전트, 모델 및 가격 버전별로 나눠야 하지 않나요? 그렇지 않으면 전체 계정 조사와 좁은 질문을 비교해 정상적인 실행을 컨텍스트 비대화로 오해할 수 있습니다.
  • @sarvar_04 — 현재는 실행 전체가 아니라 에이전트별로 기준선을 둡니다. 덕분에 호출되지 않은 에이전트는 비교 대상이 되지 않습니다. 하지만 같은 에이전트 안에서는 전체 조사에 필요한 입력 증가를 비대화로 오인할 수 있습니다. 요청에서 나온 질문 유형과 가격 버전을 기준에 반영해야 하며, 아직 구현하지 않았습니다.
• @kartik-nvjk — 성공한 하위 에이전트의 결과가 비싸고 쓸모없어 다음 에이전트가 수습해야 한다면 어떻게 처리하나요?
  • @sarvar_04 — 현재는 토큰을 쓴 에이전트에 비용을 붙일 뿐, 지출을 유발한 에이전트는 기록하지 않습니다. 쓸모없는 내용을 넘긴 에이전트는 싸게 보이고 수습한 에이전트는 비싸게 보일 수 있습니다. 생성한 컨텍스트와 다음 단계 입력을 연결하는 계보 정보는 아직 없습니다.
• @kenwalger — 비용을 에이전트별뿐 아니라 컨텍스트, 검색 같은 아키텍처 범주별로도 보고할 수 있습니다. 한 span에 여러 범주를 붙이되 실제 달러를 중복 계산하지 않는 방식이 좋습니다. 원인이 된 span과 후속 컨텍스트 비용을 연결하면 비용이 어디서 발생했는지와 무엇이 유발했는지를 나눠 볼 수 있습니다.
  • @kenwalger — 직접 측정한 비용과 추정해 배분한 비용도 구분해야 합니다. 통제된 비교가 있으면 실행 간 차이를 측정값으로 쓸 수 있지만, 일반적인 운영 trace에서는 토큰 비율에 따른 배분이 추정일 수 있습니다. measured_delta, proportional, estimated, unknown 같은 attribution_method를 기록하면 수치가 무엇에 근거하는지 밝힐 수 있습니다.
• @mustkhim_inamdar — llm.model 속성 누락으로 비용이 조용히 계산되지 않는 문제를 잘 찾았습니다. 모든 것이 작동하는 것처럼 보이는 무음 실패는 명확한 오류보다 더 나쁠 수 있습니다.
  • @sarvar_04 — span에는 토큰이 있는데 대시보드에는 0으로 표시돼 원인을 찾는 데 오후를 썼습니다. llm.model이 없으면 처리기가 span을 건너뛰지만 로그도 남기지 않습니다. 건너뛴 이유를 한 줄만 기록했어도 시간을 아꼈을 겁니다.