AI 에이전트의 비용을 비교할 때는 요청 하나에 쓴 돈과, 검증된 완료 하나를 얻는 데 쓴 돈을 함께 보자. 모델 호출이 저렴해져도 재시도와 사람의 수정이 늘면 전체 처리 비용은 커질 수 있다. 먼저 완료 기준과 비용에 포함할 범위를 고정해야 비교가 가능하다.
이번 AI Agent Fast Learning은 섀도 테스트와 카나리 배포에서 관찰 항목으로 남겨 둔 비용을 구체화한다. 아래 A·B 방식과 금액은 계산을 설명하기 위한 합성 데이터다. 실제 모델 요금, 고객 처리 기록, 성능 측정 결과가 아니다.
토큰 단가에서 작업 단위로 시선을 옮긴다
FinOps Foundation은 토큰·저장량 같은 자원 단위의 효율과, 거래·해결된 사례 같은 업무 단위의 지표를 구분한다. 무엇을 조직의 성과로 볼지에 따라 단위를 정하고 계산 범위를 명시하도록 안내한다. 이 글은 그 원칙을 “검증된 완료 1건”에 적용한 측정 설계다. FinOps Foundation: Unit Economics
토큰 단가는 특정 자원을 얼마나 싸게 쓰는지 알려 준다. 하지만 한 요청에 모델을 몇 번 부르는지, 검색 도구를 얼마나 쓰는지, 사람이 얼마나 오래 검토하는지까지 말해 주지는 않는다. 같은 모델이어도 실행 흐름이 바뀌면 작업 비용이 달라진다.
먼저 “완료”를 한 문장으로 정한다
가상의 업무를 “공개 제품 문서에서 질문의 답과 근거 위치를 찾아 내부 검토용 답변을 만든다”로 정하자. 완료는 질문에 답하고, 근거가 실제 문서와 일치하고, 필수 항목을 갖춘 답변이 최종 검토를 통과한 상태다. 사람이 고쳐 통과한 건도 완료에 포함하되, 그 수정 시간은 비용에 넣는다. 단순히 모델이 종료됐거나 자신이 완료했다고 말한 상태는 세지 않는다.
Anthropic의 평가 안내도 실행 기록과 최종 환경 상태를 구분하고, 고정된 작업 묶음에서 지연·토큰 사용·작업당 비용·오류를 함께 추적할 수 있다고 설명한다. 이 글의 완료 기준과 아래 계산식은 해당 문서의 공식 지표가 아니라 학습용으로 정한 것이다. Anthropic: Demystifying evals for AI agents
결과를 아직 확인하지 못한 요청은 미해결로 남긴다. 검토를 기다리는 건을 실패로 단정할 필요는 없지만, 검증된 완료 수에 넣을 수도 없다. 집계 시점과 상태별 건수를 같이 남겨야 다음 집계와 비교할 수 있다.
두 분모를 나란히 둔다
| 지표 | 계산 | 읽는 방법 |
|---|---|---|
| 요청 1건당 비용 | 선택한 총비용 ÷ 대상 요청 수 | 들어온 일을 처리하는 데 얼마나 썼는가 |
| 완료 1건당 비용 | 같은 총비용 ÷ 검증된 완료 수 | 검증된 결과 하나를 얻는 데 얼마나 썼는가 |
| 완료율 | 검증된 완료 수 ÷ 대상 요청 수 | 요청 중 실제로 마무리한 비율은 얼마인가 |
총비용에는 같은 요청 묶음에서 발생한 실패·재시도·미해결 건의 비용도 포함한다. 성공한 실행의 비용만 골라 나누면 실패에 쓴 돈이 사라진다. 완료 1건당 비용은 완료한 건만의 평균 처리비가 아니라, 선택한 전체 비용을 완료 수로 나눈 값이다. 완료 수가 0이면 이 비율은 계산 불가로 표시하고 총비용과 0건을 그대로 보여 준다.
합성 예시: 호출비가 싼 A가 전체 비용도 낮을까
두 방식에 같은 질문 100개를 주고, 같은 문서 버전과 완료 기준으로 검토했다고 가정하자. 관측 범위는 각 요청의 시작부터 정해 둔 마감까지다. 외부 발송은 없고, 검토·수정 시간에는 미해결 건에 쓴 시간도 포함한다. 시간의 환산 단가는 설명을 위해 분당 300원으로 둔다. 실제 인건비를 뜻하지 않는다.
| 항목 | A 방식 | B 방식 |
|---|---|---|
| 대상 요청 | 100건 | 100건 |
| 모델·도구 비용 합계 | 6,000원 | 10,000원 |
| 검토·수정 시간 합계 | 40분 | 20분 |
| 시간 환산 비용 | 12,000원 | 6,000원 |
| 선택한 총비용 | 18,000원 | 16,000원 |
| 검증된 완료 / 미해결 | 80건 / 20건 | 90건 / 10건 |
| 요청 1건당 비용 | 180원 | 160원 |
| 완료 1건당 비용 | 225원 | 약 177.78원 |
| 완료율 | 80% | 90% |
A의 모델·도구 비용은 더 작다. 그러나 이 가정에서는 사람의 검토·수정 시간이 더 많이 들어 총비용은 B보다 2,000원 높다. 완료 1건당 비용도 A는 18,000 ÷ 80 = 225원, B는 16,000 ÷ 90 ≈ 177.78원이다. 이는 입력한 가정의 산술 결과이며 B라는 실제 제품이나 특정 모델의 우수성을 입증하지 않는다.
여기서 선택한 비용은 모델·도구와 검토·수정 시간뿐이다. 개발비, 공용 서버, 저장·관측 시스템, 운영 지원비 등은 제외했다. 따라서 이 표를 총소유비용이나 이익률로 읽으면 안 된다. 실제 비교에서는 무엇을 포함하고 제외했는지 먼저 정하고, 공동 비용을 배분했다면 배분 기준도 적는다.
실제 기록은 요청과 실행을 분리한다
사용자의 요청 하나를 최초 실행한 뒤 두 번 재시도했다면 요청은 1건이고 실행 기록은 3개다. 실행 수를 분모로 쓰면 재시도가 많은 방식이 일을 더 많이 처리한 것처럼 보인다. 요청 식별자 아래 모델 호출, 도구 호출, 재시도, 사람의 수정 시간을 묶고 마지막에 검증된 완료 여부를 연결한다.
| 기록 항목 | 남길 내용 |
|---|---|
| 요청 묶음 | 대상 조건, 요청 수, 시작·마감 시점, 집계 기준 |
| 구성 버전 | 모델 식별자, 프롬프트·도구·문서·평가 기준 버전 |
| 비용 원장 | 호출별 금액·통화·요금 기준일, 재시도와 도구 비용 |
| 사람의 작업 | 검토·수정 시간, 환산 단가, 포함한 작업 범위 |
| 최종 결과 | 완료·미해결·실패 등의 상태와 확인 근거 |
| 별도 경고 | 권한 위반, 누락 비용, 지연, 미확인 결과 |
모든 실패 호출이 같은 방식으로 과금된다고 가정하지 않는다. 공급자가 반환한 사용량과 청구 정책을 확인하고, 추정액과 확정 청구액을 구분한다. 여러 통화를 합칠 때는 환산 기준일과 환율을 남긴다. 본문·고객정보 전체를 비용 로그에 복사할 필요는 없다. 접근 가능한 요청 식별자와 필요한 수치만으로 연결할 수 있도록 설계한다.
비교를 망치는 네 가지 지름길
- 쉬운 요청만 후보에 주기. 두 방식의 대상 구성이 다르면 비용과 완료율의 차이를 모델 차이로 해석하기 어렵다. 같은 평가 묶음을 쓰고, 어려운 유형은 따로 본다.
- 미해결 건을 집계에서 빼기. 처음 정한 대상 요청을 유지하고, 마감 뒤 추가된 비용·완료 결과는 같은 묶음에 귀속해 재집계하거나 별도 후속 값으로 표시한다.
- 사람이 고친 결과를 자동 완료로 세기. 최종 완료에는 포함할 수 있지만 자동 처리 성과와는 구분하고 수정 시간을 포함한다.
- 비용만 낮추고 통과 기준도 낮추기. 근거 확인이나 권한 검사를 빼면 비교하려던 품질 조건이 바뀐다. 안전 위반은 금액으로 상쇄하지 않고 별도 중단 조건으로 다룬다.
완료율과 비용이 좋아도 사용자가 기다릴 수 있는 시간을 넘었다면 채택하기 어렵다. 요청별 총 처리 시간과 오래 걸린 사례를 별도로 확인하자. 반대로 평균 비용이 낮아도 일부 요청이 예산을 대부분 소모한다면 반복 호출 구간부터 살펴볼 수 있다. 비용 한도는 권한을 늘려 주지 않으며, 한도 도달 시 미완료 상태를 명확히 남겨야 한다.
다음 비교 전에 확인할 체크리스트
- 무엇이 검증된 완료인지, 사람이 고친 완료를 어떻게 세는지 정했는가?
- 대상 요청 묶음, 문서·구성 버전, 마감 시점을 고정했는가?
- 실패·재시도·미해결 건의 비용과 검토 시간을 포함했는가?
- 추정 비용과 확정 비용, 포함 비용과 제외 비용을 구분했는가?
- 요청당 비용·완료당 비용·완료율·지연·안전 위반을 함께 보는가?
- 완료가 0건이거나 비용이 누락됐을 때 값 대신 계산 불가·미확인으로 표시하는가?
첫 비교에서는 모델을 바꾸기 전에 비용 원장에서 가장 큰 항목 하나를 찾는 편이 낫다. 검토 시간이 대부분이라면 답변의 근거 표시와 누락 항목 검사가 개선 후보가 된다. 반복 검색이 대부분이라면 필요한 자료를 언제 다시 읽는지 확인할 수 있다. 바꾼 뒤에는 같은 완료 기준으로 다시 계산한다. 줄어든 비용이 어느 작업의 변화에서 나왔는지 설명할 수 있어야 한다.
적용 범위와 확인한 자료
자료 확인일: 2026년 10월 9일. 적용 범위는 특정 SDK·모델 버전에 종속되지 않는 측정 설계다. FinOps Unit Economics는 확인일의 웹 문서, Anthropic 평가 안내는 2026년 1월 9일 공개 문서를 기준으로 읽었다. 계산식·기록표·체크리스트는 이 글의 설계 제안이다. 합성 수치의 합계·나눗셈은 로컬 Python 표준 라이브러리로 검사했다. 실제 모델·유료 API 호출, 고객 데이터 사용, 운영 성능 실험은 수행하지 않았다.