에이전트 비용 문제는 모델이 아니라 측정하지 않은 단계에 있습니다

AI 요약

에이전트 파이프라인이 사흘 만에 한 달치 예산을 소진하자, 팀은 먼저 비싼 최상위 모델을 저렴한 모델로 바꾸려 했습니다. 하지만 작성자가 각 토큰을 단계(step), 도구(tool), 모델(model) 조합에 연결해 보니 문제는 모델 가격이 아니었습니다. 간단한 분류와 요약부터 어려운 추론까지 모든 단계가 별도 설정 없이 고성능 모델을 호출하고 있었고, 어느 단계가 비용을 만들었는지 알 수 없었습니다.

총액이 아니라 호출 트리를 측정합니다

단일 LLM 호출은 비용 항목 하나로 보이지만, 에이전트 반복 과정에서는 각 단계가 모델과 도구를 호출하고, 재시도하거나 하위 단계를 실행합니다. 전체 비용은 이 호출 트리에서 발생한 지출의 합입니다. 총액만 보면 어떤 단계를 바꿔야 할지 추측하게 됩니다. 그때 흔히 나오는 대응은 모든 곳에 더 작은 모델을 쓰는 것입니다. 그러면 실제로 고성능 모델이 필요한 단계의 품질은 낮추면서, 불필요한 호출은 그대로 둘 수 있습니다.

글은 많은 에이전트 프레임워크가 시작 지점에서 모델 하나를 정하게 해, 단계별 모델 선택을 전역 설정으로 고정한다고 지적합니다. 간단한 분류와 방금 생성한 텍스트의 요약도 고성능 모델을 호출하고, 어려운 추론 호출은 그 사이에 묻힙니다. 작성자는 고성능 모델 호출의 약 80%가 실제로는 필요하지 않았다고 말합니다. 단계별 비용 추적이 없으면 어느 호출이 불필요했는지 입증하기도 어렵습니다.

단계별 비용과 재시도를 기록합니다

권장하는 계측 항목은 호출마다 단계 ID, 도구, 모델, 입력·출력 토큰 수, 지연 시간, 재시도 횟수입니다. 이 데이터가 쌓이면 전체 비용을 소수의 단계가 차지하는 경우가 드러난다고 합니다. 작성자가 경험한 사례에서는 비싼 단계처럼 보인 원인이 모델 자체가 아니라, 도구가 반환한 형식을 파서가 거부해 어려운 호출을 다섯 번 반복한 재시도 루프였습니다.

모델 오류나 시간 초과, 잘못된 출력이 발생했을 때 전체 실행 경로를 다시 돌리면 실패로 이미 비용이 발생한 상황에서 지출이 더 커집니다. 글은 단계 경계에서 해당 호출만 대체 모델로 넘기고 나머지 실행은 이어 가는 장애 대응을 제안합니다. 단, 이런 전환과 비용 측정은 호출 경로를 실제로 보는 라우팅 계층에서 함께 처리해야 한다고 설명합니다. 프롬프트 조정만으로 단계별 비용을 통제할 수는 없다는 주장입니다.

라우팅과 규정 준수

글은 동남아시아에서 PDPA에 맞춰 프롬프트와 출력을 역외로 보내지 않으려면 데이터가 지역 안에 머물러야 한다고 설명합니다. 작성자가 제시한 구성은 싱가포르에 호스팅한 Tencent Cloud 라우팅 계층입니다. 이 계층은 모든 토큰이 지나가는 경로이므로 별도 경로를 추가하지 않고 단계별 비용을 기록할 수 있다고 말합니다. OpenAI 호환 엔드포인트 하나에서 25개가 넘는 모델을 제공하는 게이트웨이는 장애 시 모델을 바꾸는 데 그치지 않고, 측정 데이터와 전환 결정을 같은 곳에서 처리하는 구성으로 소개됩니다.

dev.to 반응

• @brianainews — 단계별 비용 귀속은 비용 분석과 추측을 가르는 기준입니다. 여기에 품질 결과도 토큰 수와 함께 기록하는 안전장치를 더하고 싶습니다. 그래야 더 저렴한 경로를 지출만이 아니라 작업 성공률로 평가합니다. 그러면 라우터가 어려운 단계의 품질을 깎아 비용만 낮추는 일을 막고, 장애 전환 정책도 측정할 수 있습니다.
  • @tokenlat — 그 안전장치가 있어야 장애 전환이 반사적 대응이 아니라 정책이 됩니다. 결과 데이터가 없으면 라우터는 쉬운 80%를 조용히 최적화하고 어려운 20%를 소홀히 합니다. 토큰 옆에 품질을 기록하는 항목은 대부분 비용 대시보드에 빠져 있습니다. 단계별 성공 기준으로 장애 전환을 제한하시나요, 아니면 일정 기간의 작업 전체 성공률을 기준으로 삼으시나요? 단계별 기준은 나쁜 경로를 더 빨리 잡지만, 작업 단위 기준은 단일 단계의 잡음에 덜 흔들립니다.
• @max_quimby — “에이전트 비용은 숫자가 아니라 트리입니다”라는 표현이 정확합니다. (단계, 도구, 모델) 조합은 비용을 이해할 수 있게 만드는 단위입니다. 저희도 같은 과정을 거쳤습니다. 반사적으로 저렴한 모델로 바꾸려 하지만, 대개 잘못된 대응입니다. 낭비는 토큰 단가가 아니라 아무도 기록하지 않은 불필요한 고성능 모델 호출 횟수에서 생깁니다. 직접 운영해 보며 두 가지를 더 보탭니다. 첫째, 재시도는 가장 잘 숨어드는 비용입니다. 단계가 조용히 두 번 재시도하면 비용이 세 배가 되지만 시도 횟수를 기록하지 않으면 드러나지 않습니다. 에이전트 프레임워크는 재시도를 도구 계층 안에 감추기도 합니다. 둘째, 단계별 귀속 뒤에 봐야 할 지표는 총비용이 아니라 성공한 결과당 비용입니다. 실패해 상위 단계에서 재계획을 일으키는 저렴한 단계는 대체한 비싼 단계보다 더 비쌀 수 있습니다. 설명한 기록 방식이 정말 중요한 부분이지만, 그 효과는 “어느 단계가 가장 비싸지?”가 아니라 “성공 결과당 비용이 가장 나쁜 단계는 어디지?”라고 물을 수 있을 때 나타납니다. 태깅을 시작한 뒤 실제로 제거한 단계가 예상과 달라졌나요?
  • @tokenlat — 도구 계층 안의 재시도는 많은 팀이 놓칩니다. 관측 가능성이 도구 경계에서 끝나면 재시도가 별도 호출로 나타나지 않기 때문입니다. 성공한 결과당 비용으로 관점을 바꾸는 것도 맞습니다. 라우터의 역할은 단순히 가장 싼 경로를 고르는 게 아니라 성공하는 경로 중 가장 저렴한 것을 찾는 일이 됩니다. 질문에 답하자면, 태깅을 하니 실제로 제거한 단계가 예상과 달라졌습니다. 토큰당 비용은 낮아 보여도 재계획 비용까지 계산하면 손해인 단계가 드러났습니다. 서류상 비용은 내려갔지만 성공 기준을 통과하지 못한 단계는 남겨 두셨나요?
• @suraj09 — “비용은 트리”라는 설명이 잘 와닿습니다. 에이전트 컨텍스트에도 비슷한 관측 문제가 있다고 생각합니다. 어떤 컨텍스트를 쓸 수 있었는지는 대체로 알지만, 실제로 어떤 부분이 결정에 영향을 줬는지, 진행 중 어떤 가정이 낡았는지는 항상 알지 못합니다. 비용의 단계별 귀속은 유용해 보입니다. 오래 실행되는 에이전트도 언젠가 컨텍스트를 비슷하게 추적해야 할지 궁금합니다.
• @mickyarun — (단계, 도구, 모델) 조합은 아직 활용하지 않은 역할이 하나 더 있습니다. 비용보다 그쪽이 더 중요하다고 봅니다. 글에서는 재시도를 비용 항목으로 다룹니다. 단계가 읽기 작업일 때는 맞습니다. 하지만 단계가 행을 쓰거나 메시지를 보내거나 돈을 옮기는 효과를 일으키면, 파서가 형식을 거부해 어려운 호출을 다섯 번 재실행하는 문제는 비용이 아닙니다. 효과가 다섯 번 발생하는 문제입니다. 비용 대시보드는 중복 실행을 찾아내는 가장 값싼 감지기지만, 숫자가 달러로 표시되고 실제로 발견한 문제가 중복 실행이라 아무도 그렇게 읽지 않습니다. 결제 분야에는 오래된 규칙이 있습니다. 재시도하는 단위를 멱등하게 만드세요. 같은 단위, 같은 키입니다. 단계 경계가 장애 전환에 적합하다면 멱등성 키에도 적합합니다. 단계에는 비용뿐 아니라 종류도 있다고 인정하면 됩니다. 효과를 일으키는 단계는 키를 기준으로 재시도하고, 순수 단계는 자유롭게 재시도합니다. 지금은 둘 다 같은 조합 안에서 그저 “단계”로 취급됩니다. 장애 전환을 단계 경계에 두는 것은 맞습니다. 다만 첫 번째 모델이 이미 한 작업을 대체 모델이 이어받는다는 뜻이기도 합니다. 첫 호출이 도구 작업을 완료한 뒤 시간 초과가 났다면 대체 모델은 로그에 다른 모델 이름을 남기며 두 번째 작업을 수행합니다. 더 비싼 실행이 아니라 잘못된 실행입니다. 단계별 귀속이 있어야만 그 사실이 보입니다. 같은 단계 ID에 모델 두 개가 기록되면, 실행 경로에 들어온 줄 몰랐던 모델도 드러납니다. 실제 데이터를 확보하셨으니 묻고 싶습니다. 모든 토큰에 태그를 붙였을 때 재시도는 같은 단계 ID에 기록됐나요, 아니면 새 ID로 나타났나요? 스키마가 재시도를 단계 하나로 합치는지에 따라 “이 단계 비용이 5배 들었다”와 “이 단계가 5번 실행됐다”가 갈립니다. 중복 작업을 찾게 만드는 표현은 둘 중 하나뿐입니다.
• @julianneagu — 재시도 문제는 정말 현실적입니다. 하위 작업이 재시도되는 것만으로 저렴한 단계가 가장 비싼 단계가 되는 경우를 봤습니다. 시도 횟수를 단계 비용과 따로 추적하면 금방 드러납니다.
• @nomad-link-id — “비싼 모델을 교체하자”는 대개 첫 진단으로 적절하지 않습니다. 비용을 (단계, 도구, 모델) 조합에 귀속하면 비용은 모두가 탓하던 단 한 번의 고성능 모델 호출이 아니라, 성공 기준 없이 반복되는 저렴한 단계와 도구 호출에 있는 경우가 많습니다. 에이전트 비용은 트리이고 단일 가격표는 추측입니다. 작업 성공률과 함께 단계별 토큰 수나 비용을, 완전히 성공한 작업 하나를 기준으로 측정하겠습니다. 저렴한 경로가 비용을 줄여도 완료율을 낮춘다면 절약이 아니라 더 나쁜 계약입니다.
• @quietlabops — 저희가 계속 쓰는 사후 분석이네요. 악당은 모델 가격이 아니었습니다. 납품 가능한 결과물 없이 “거의 끝난” 상태를 계속 만드는 이름 없는 루프였습니다. 각 역할에 완료·중단 기준을 강제하고 소액의 예산을 투자 수익이 아니라 학습 비용으로 다루기 시작했습니다. 저희가 무언가를 사기 전에 쓰는 무료 한 페이지 자료입니다. 저희 상품을 살 때도 씁니다: grokbotplaybook.grok.me/ “새 파일이 없는 단계”를 별도의 비용 지표로 기록하시는지 궁금합니다.

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