AI 비용 보고서에서 가장 유용한 항목은 설명할 수 없는 비용입니다

AI 요약

다중 에이전트 시스템에서는 총 토큰이나 에이전트별 비용만으로 무엇을 고쳐야 할지 알기 어렵습니다. 검색기(retriever)가 많은 문맥을 넘기면 실제 비용은 감독자(supervisor) 구간에서 발생하지만, 그 비용 일부를 유발한 원인은 검색기일 수 있습니다. 글은 비용이 발생한 위치와 비용을 유발하거나 늘린 원인을 별도 축으로 기록하자고 제안합니다.

발생한 비용과 유발한 원인

검색에 0.004달러가 들고 검색 결과 2만 토큰을 감독자의 문맥에 넣었다고 가정합니다. 감독자 비용이 0.009달러라면, 검색 비용 자체는 여전히 0.004달러입니다. 하지만 감독자 비용 일부는 검색 결과가 길어서 발생했을 수 있습니다. 이를 표현하는 예시 레코드는 검색 구간의 직접 비용과 반환 토큰 수를 기록하고, 감독자 구간에 연결된 하위 비용에는 기여한 검색 구간과 귀속 방식을 붙입니다. 예시의 0.0021달러를 검색 비용에 더해 두 번 계산하지는 않습니다. 감독자가 비용을 발생시켰다는 사실과 검색기가 비용에 기여했다는 사실을 함께 기록합니다.

숫자만으로 인과관계를 단정하지 않기

비용의 원인을 확인하는 가장 강한 근거는 다른 조건은 그대로 둔 채 검색 결과만 바꾼 통제 비교입니다. 검색 결과가 없을 때 감독자 비용이 0.006달러, 있을 때 0.009달러라면 차이인 약 0.003달러를 검색 결과에 귀속할 근거가 생깁니다. 하지만 실제 실행에서는 시스템 지침, 대화 상태, 다른 에이전트의 출력, 도구 결과가 한꺼번에 감독자 문맥에 들어가므로 깨끗한 비교가 어려운 경우가 많습니다.

이럴 때는 각 출처가 문맥에 보탠 토큰 비율에 따라 비용을 나누는 비례 배분(proportional allocation)을 쓸 수 있습니다. 다만 이것은 직접 측정한 인과관계가 아닙니다. 따라서 귀속 비용마다 measured_delta, proportional, estimated, unknown 같은 attribution_method를 함께 기록해야 합니다. confidence: 0.82 같은 점수는 그 숫자가 무엇에 대한 확신인지 설명하지 못합니다. 반면 방법을 표시하면 값의 근거와 한계를 알 수 있습니다.

보고서에 표시할 정보

직접 관측한 비용에는 별도 귀속 방식이 필요하지 않습니다. 검색 구간에서 직접 측정한 0.004달러와, 검색 결과가 감독자 문맥 비용에 기여했다고 비례 배분한 0.0021달러는 보고서에서도 다르게 보여야 합니다. 두 번째 숫자에서 proportional을 감추면 추정치를 측정값처럼 보이게 만듭니다. 보고서 본문에는 금액, 비용 범주, 직접 비용인지 하위 비용인지, 귀속 방식을 표시하고, 토큰 수나 비교 실행 같은 근거는 상세 화면에 둡니다.

unknown은 관측 한계를 보여주는 값

귀속 방식을 알 수 없는 비용을 미완성 데이터로 취급해 억지로 나누지 말아야 합니다. 설명되지 않는 하위 비용은 시스템이 어디까지 관측하고 어디서부터 원인을 설명하지 못하는지 보여줍니다. 따라서 unknown은 다음에 계측을 보강할 지점을 찾는 신호입니다. 문맥은 단순히 더한 토큰 수에 비례해 비용을 늘리지 않을 수도 있습니다. 토큰 추가가 캐시 동작을 바꾸거나 모델의 추론 경로와 출력량을 바꾸면 토큰 비율과 비용 비율이 어긋납니다. 그때는 비례 배분값을 만들어내기보다 unknown이라고 기록하는 편이 정직합니다.

기존 트레이스에 귀속 의미를 더하기

부모·자식 span을 기록하고 있다면 인과관계의 연결 고리는 트레이스에 이미 들어 있습니다. 각 span에 주 비용 범주를 붙이고, 하위 효과를 만든 구간에는 contributes_to와 원인 정보를 추가합니다. 귀속 비용에는 attribution_method를 기록합니다. 보고서는 비용 범주와 직접·하위 비용이라는 두 축으로 집계하고 unknown도 독립된 항목으로 보여줍니다. 계측 방식을 바꾸면 이를 읽는 귀속 로직도 달라질 수 있으므로, 알려진 기준 실행과 비교해 수치 변화가 생겼는지 확인해야 합니다.

dev.to 반응

• @max_quimby — 발생한 비용과 유발한 원인을 나누는 관점에 동의합니다. 다만 인과관계가 여러 단계를 거치면 원인이 빠르게 희석됩니다. 검색기가 2만 토큰을 반환하고 저렴한 모델이 2천 토큰으로 요약한 뒤 감독자에게 넘기면, 감독자 구간은 얌전해 보이고 문제를 만든 검색기는 모든 span에서 보이지 않습니다. 비용은 엉망을 정리한 요약 단계에 귀속됩니다. 저희는 나중에 재구성하는 대신 contributed_by 목록을 다음 단계로 전달합니다. 요약 단계 자체 비용이 거의 없어도 검색기 ID를 물려받습니다. 검색 하나가 에이전트 셋에 병렬로 전달되는 경우는 어떻게 처리하시나요? 하위 비용을 나누나요, 각 에이전트에 전체 기여를 기록하나요? 임의적이지 않은 배분 기준을 찾지 못했습니다.
  • @kenwalger — ‘인과관계 세탁’이 바로 문제입니다. 압축 단계는 하위 span을 더 건강해 보이게 하면서, 애초에 압축이 필요했던 원인을 숨길 수 있습니다. contributed_by는 기여 관계를 배분인 척하지 않고 보존한다는 점이 좋습니다. 세 소비자가 같은 검색 결과를 받았다면 검색 결과가 세 인과 경로에 기여했다고 볼 수 있습니다. 각 경로에 33.3%를 배분하면 정밀도를 지어내는 셈입니다. 각 갈래에는 전체 기여 관계를 보존하고, 금액 배분은 별도의 귀속 방식으로 다루고 싶습니다. 기여 관계의 합이 100%가 되지 않아도 괜찮습니다. 입력 크기가 줄어도 원인의 중요성은 줄지 않을 수 있다는 실패 사례도 보여주셨습니다.
• @reidmarlow — 문맥이 가산적이지 않다는 지적은 비례 배분이 실제 환경에서 무너지는 지점을 정확히 짚습니다. 프롬프트 캐싱에서는 특히 그렇습니다. 검색 결과가 감독자 프롬프트 앞부분에 고정되지 않은 사전 키, 동적 타임스탬프, 변하는 헤더를 넣으면 감독자와 이후 대화의 접두부 캐시가 무효화됩니다. 저렴한 캐시 읽기가 대화 기록 전체에 대한 비싼 캐시 쓰기로 바뀔 수 있습니다. 표준 트레이스에서는 감독자가 같은 로직을 실행했는데도 감독자 span에 큰 비용 급증으로 나타납니다. 비례 배분을 강제하면 400바이트만 넘긴 검색기는 무관해 보이고 감독자가 예산을 낭비한 것처럼 보입니다. 캐시 경계가 바뀌면 토큰량과 실제 비용이 어긋나므로 unknown이 있어야 계측이 정직해집니다.
  • @kenwalger — 비례 배분을 반박하는 좋은 사례입니다. 상류 기여는 바이트로는 작아도 결과는 클 수 있습니다. 원인은 토큰 자체라기보다 토큰이 바꾼 캐시 경계일 수 있습니다. 감독자가 추가 비용을 발생시켰지만 감독자 자체의 동작으로는 비용 증가를 설명하지 못합니다. unknown을 유지해야 한다는 주장을 뒷받침하고, 언젠가는 검색 결과가 접두부를 바꾸고 캐시가 무효화된 뒤 감독자가 전체 비용을 부담했다는 식의 더 풍부한 인과 기록도 필요할 수 있습니다. ‘검색기 3%, 감독자 97%’보다 원인을 더 잘 설명하면서도 비율을 만들지 않는 방식입니다.
• @prpatel05 — 저희는 unknown 귀속을 대시보드의 흠이 아니라 주간 분류 작업 대기열로 다루기 시작했습니다. 비례 배분이 재무 검토에서 방법 표기 없이 숫자만 공유되면 조용히 ‘진실’로 굳어집니다. 귀속 비용 행에 attribution_method를 필수 열로 넣자 span 태그를 더 추가했을 때보다 빨리 해결됐습니다.
  • @kenwalger — unknown을 부끄러운 항목이 아니라 대기열로 보는 관점이 좋습니다. 아직 정리되지 않은 계측이 아니라 조사할 가치가 있는 인과 질문의 목록이 됩니다. 42%라는 숫자가 ‘비례 배분’ 표기 없이 시스템 밖으로 나가면 조직의 사실로 굳어지는 속도가 놀라울 정도로 빠릅니다. 기간별 unknown 비용뿐 아니라 unknown이 어떤 방식으로 해소됐는지도 보면 좋겠습니다. unknown이 줄었다는 사실만으로는 조직이 원인을 알아낸 건지, 편리한 분류를 택한 건지 알 수 없습니다.
• @aifrontierpost — confidence: 0.82라는 표현이 가져갈 만한 대목입니다. 비례 추정치에 점수를 붙이면 엄밀해 보이지만 실제로는 아무것도 알려주지 않습니다. 그래서 귀속 방식을 상세 화면에 숨기지 말고 숫자 옆에 표시해야 합니다.
  • @kenwalger — 맞습니다. confidence: 0.82는 정량적인 것처럼 보여서 무엇에 대한 확신인지 묻지 않게 만들기 쉽습니다. 확신도 높은 비례 배분도 여전히 비례 배분입니다. 방법 자체가 값의 일부이지 값에 붙는 메타데이터가 아닙니다. 방법을 빼면 그 숫자가 주장할 수 있는 의미도 달라집니다.
• @hannune — 같은 검색 단계가 요청 다섯 개에서 똑같이 실행됐는데 공통 원인과 연결되지 않아 다섯 개의 인과 경로에 각각 비용이 잡힌 적이 있습니다. 보고서에는 다섯 줄이 있었지만 실제 원인은 하나였습니다. 검색 호출에 source_request_id 태그를 추가하고 배분 전에 이를 기준으로 묶자 설명되지 않던 항목이 눈에 띄게 줄었습니다. 두 귀속 경로가 같은 근본 사건을 가리키는 경우를 스키마에서 드러내나요? 대시보드만 보고 찾기 가장 어려운 문제입니다.
  • @kenwalger — 배분 이전에 생기는 실패 사례라 유용합니다. 다섯 경로가 하나의 원천 사건에서 갈라졌다면 어떤 배분 방식도 그 정체를 확인하기 전에는 보고서를 고칠 수 없습니다. source_request_id를 나중에 재구성하지 않고 계속 전달하는 방법이 좋겠습니다. 직접 원인과 최초 요청 또는 사건의 ID를 함께 유지하면 ‘바로 무엇이 원인이었나’와 ‘어떤 공통 사건에서 갈라졌나’를 구분할 수 있습니다. 현재 스키마에는 서로 다른 두 경로가 같은 원천 사건에서 나왔는지 찾는 기능이 없습니다. 비용을 나누기 전에 원인이 몇 개인지부터 확인해야 할 수 있습니다.
• @presango — 검색 예시는 비용을 발생시킨 span과 비용을 유발한 span이 다르다는 점을 가장 명확히 보여줍니다. 저희도 세션 중 실시간 질문에 답하는 AI 프레젠터에서 비슷한 문제를 봅니다. 비싼 단계는 늘 답변 생성이지만, 원인은 질문 하나에 필요한 슬라이드 한 장보다 훨씬 많은 자료를 문맥에 넣은 상류 결정인 경우가 많습니다. 답변 단계에 비용을 귀속하면 대시보드가 잘못된 곳을 고치라고 합니다. 억지로 원인을 배정하지 않고 unknown 항목을 두는 편이 정직합니다. unknown 비중은 전체 비용보다 더 나은 건강 지표일 수도 있습니다. unknown 비중을 실행마다 추적하나요, 아니면 보고만 하나요?
  • @kenwalger — 아직 실행 간 운영 지표로 만들지는 않았지만, 비중이 변한 이유도 추적해야 한다는 의견에 동의합니다. unknown 비율이 낮아진 것은 인과관계 추적이 나아졌다는 뜻일 수도 있고, 더 공격적인 비례 추정으로 unknown을 바꿨다는 뜻일 수도 있습니다. 둘은 반대인데도 같은 개선 차트로 보입니다. unknown에서 measured_delta, proportional, estimated 등으로 바뀐 흐름을 함께 추적하면 증거를 모은 건지 확신만 키운 건지 알 수 있습니다. 프레젠터 사례도 답변 span 자체는 멀쩡해도 질문에 필요 이상으로 많은 문맥을 넣은 상류 결정 때문에 비용을 계속 치를 수 있음을 잘 보여줍니다.
• @izgorodin — 한 실행 안의 원인은 트레이스에 연결할 수 있지만, 두 가지 원인은 실행 바깥에 있어 기록이 없으면 unknown으로 남습니다. 하나는 프롬프트 캐시입니다. 공급자가 프롬프트 접두부를 캐싱하면 실행의 첫 호출이 캐시를 읽을지 새로 쓸지는 다른 실행이 캐시 수명 안에 같은 접두부를 썼는지에 달렸습니다. 공급자와 설정에 따라 수명은 몇 분에서 몇 시간입니다. 따라서 두 실행은 같아도 어느 트레이스에도 원인이 없을 수 있습니다. 다른 하나는 영구 메모리입니다. 오늘 문맥에 넣은 메모리나 요약을 과거 실행에서 길게 작성했다면 이후 실행은 그 길이만큼 비용을 내지만, 메모리를 작성한 실행의 트레이스에는 그 비용이 나타나지 않습니다. 새 귀속 필드를 만들지 않아도 대응할 수 있습니다. 공급자가 제공하는 캐시 읽기·쓰기 토큰을 각 span에 기록하면 콜드 스타트 비용이 감독자 합계에 숨지 않습니다. 저장한 메모리마다 작성 span ID를 붙이면 caused_by가 과거 트레이스의 span을 가리킬 수 있습니다. 캐시는 같은 요청을 따뜻한 상태에서 다시 실행하고 캐시 적중을 확인한 뒤 입력 비용을 비교해 measured_delta를 얻을 수도 있습니다.
• @blobdole — 저희는 크래시 디버깅 소프트웨어에서도 비슷한 문제를 고민합니다. ForensicDbg는 크래시 데이터의 누락되거나 잘못된 정보를 보정하고 알려진 레이블과 문맥을 더한 뒤 보기 좋게 연결합니다. MCP 서버에서는 마지막 단계가 흥미롭습니다. 기본적인 크래시 대부분을 해결하는 데 필요한 최소 정보만 보낼 수 있습니다. 효율적입니다. 하지만 정보가 부족하면 도구를 여러 번 왕복해야 하며, 처음부터 더 많이 보내는 것보다 훨씬 비쌉니다. 복잡하지만 정리된 분석 데이터를 보내면 크래시의 98%를 한 번에 해결할 수 있습니다. 추가 데이터가 필요해도 여섯 단계 앞서 있습니다. 하지만 간단한 응답으로 해결됐을 크래스에서는 비용이 여섯 배입니다. 적당한 중간 지점을 찾는 일은 흥미롭고 아직 진행 중인 과제입니다.
• @sizzlebop — unknown을 정리하거나 추정으로 없애야 할 문제가 아니라 유용한 결과로 다루자는 생각이 좋습니다. AI 시스템에서는 에이전트, 검색, 도구, 문맥이 서로 영향을 주면서 실제 데이터보다 대시보드가 더 정밀해 보이게 만드는 경향이 있습니다. 돈이 어디에 쓰였는지 아는 것도 유용하지만 무엇이 비용을 유발했는지 아는 일은 더 어렵고 흥미롭습니다. 아직 설명할 수 없는 부분이 있다면 바로 그곳을 살펴봐야 합니다. 교육받은 추측에 불과한 자신만만한 숫자보다 솔직한 unknown을 보겠습니다.

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