토큰 비용 모니터링, 실행 단위로 기록해야 하는 이유

토큰 비용 모니터링, 호출이 아니라 '실행' 단위로 봐야 할까?

결론부터 말하면 그렇다. 단일 프롬프트 호출당 비용을 보면 숫자는 안정적으로 보이지만, 실제 워크플로는 검색·도구 호출·재시도·메모리 갱신을 포함한 하나의 '실행(run)'으로 움직인다. 비용 폭탄은 거의 항상 이 실행 전체를 다시 들여다봐야 보인다.

이번 실험에서 검증하려 한 것은 하나다 — "완료 작업 1건당 비용"을 자동 계측하고, 예산을 넘으면 실행 중에 멈추고, 사람 개입이 필요한 지점만 명시적으로 분리할 수 있는가.

핵심 정리

• 비용 단위는 요청 1건이 아니라 완료 작업(run) 1건으로 잡아야 재시도·도구 호출 비용이 숨지 않는다.
• 장시간 에이전트에서 재전송 컨텍스트가 전체 추론 비용의 상당 부분을 차지할 수 있다는 연구 인용이 있다(특정 구성 기준, 일반화 주의).
• 저위험·정형 작업은 소형 모델이나 규칙으로, 되돌리기 어려운 판단은 사람 승인 게이트로 분리한다.
• 토큰 비용과 사람 개입 비용은 같은 대시보드에서 비교해야 "저렴한 모델이 재작업을 늘리는" 함정을 피할 수 있다.
• 예산 초과 시 자동 중단은 비용 통제의 마지막 안전장치이지, 설계를 대체하지 않는다.

완료 작업 1건당 비용을 어떻게 기록했나?

초기 설계는 API 게이트웨이에서 모델명, 입력·출력 토큰, 호출 비용만 기록하는 수준이었다. 문제는 이것만으로는 어떤 작업이 왜 비쌌는지 추적이 안 된다는 점이었다. 실무 권고를 참고해 최소 기록 필드를 workflow_id, run_id, 모델명·버전, 입력·출력·캐시 토큰, 호출 횟수, 도구 호출 횟수, 재시도 횟수, 지연 시간, 추정 비용, 성공·실패·사람 개입 여부로 확장했다. 호출별 모델 식별자와 입출력 토큰, 지연 시간까지 계측해야 비용 귀속이 가능하다는 지적을 그대로 따른 것이다 출처. 여기에 더해 추론 호출과 LLM-as-a-judge 평가 호출을 같은 비용 항목으로 묶지 않도록 purpose=evaluation 태그를 따로 붙였다. 합산해두면 평가 비용이 운영 비용 뒤에 숨어 보이지 않게 된다.

재전송 컨텍스트를 줄이면 실제로 비용이 줄었나?

줄긴 했지만 기대만큼은 아니었다. 장시간 실행되는 에이전트는 루프마다 전체 대화·검색 결과·도구 결과를 다시 보내는 경향이 있고, 이런 재전송 컨텍스트가 전체 에이전트 추론 청구액의 62%까지 차지할 수 있다는 업계 분석 인용이 있다(특정 연구·구성 기준) 출처. 이 수치를 우리 워크플로에 그대로 대입할 수는 없었지만, 시스템 지침·불변 정책·도구 스키마·작업별 입력·이전 결과를 분리하고 전체 로그 재전송을 멈추는 방향은 맞았다. 요약 메모리와 검색 근거 상위 k개 제한, 중복 제거를 적용한 뒤 평균 입력 토큰/단계와 재전송 토큰 비율을 전후 비교했더니 단계당 평균 입력 토큰은 줄었지만, 재시도가 늘어난 구간에서는 총비용이 오히려 늘었다. 줄인 것은 '정상 경로'의 비용이고, '실패 경로'의 비용은 다른 문제였다.

저위험 반복과 고위험 판단을 어떻게 갈랐나?

형식 변환, 분류, 정해진 필드 추출처럼 오류 비용이 낮고 성공 조건이 명확한 작업은 소형 모델이나 비LLM 규칙으로 넘겼다. 반대로 예외·모호성·고위험 판단만 상위 모델과 사람 검토로 보냈다. 비용은 모델 품질만이 아니라 지연 요구, 작업 빈도, 반복 루프 수에 따라 달라진다는 지적을 설계 기준으로 삼았다 출처. 자동화 단계는 수집 → 정규화 → 검증 → 초안 생성처럼 되돌릴 수 있는 반복 작업으로 제한했고, 결제·삭제·대외 발송·법적 판단은 human_approval_required=true로 걸어 중단시켰다. 사람 검토 결과는 단순 실패 처리로 묻어두지 않고 승인·수정·반려·사유를 각각 이벤트로 남겼다. 여기서 알게 된 것은, 토큰 비용표만 보면 자동화율이 높아 보이는데 사람의 수정 이벤트가 쌓이는 워크플로가 있었다는 점이다. 토큰 비용이 변동 실행비의 20~25%, 사람 감독 비용이 70~75%까지 될 수 있다는 분석을 인용하면 왜 이 구조가 필요한지 설명이 된다(특정 분석 모델 추정치) 출처.

예산 초과는 실행 중에 실제로 막을 수 있었나?

부분적으로 막았다. 워크플로마다 최대 단계 수, 최대 도구 호출 수, 입력·출력 토큰 상한, 최대 재시도 횟수, 실행당 달러 한도를 설정하고 한도 초과 시 자동 중단 후 사람에게 예산 초과 사유와 현재 상태를 전달하도록 했다. 재시도 정책도 오류 유형별로 나눠 네트워크 오류는 제한된 지수 백오프를 허용하되, 스키마 오류는 같은 프롬프트를 반복 전송하지 않고 오류 메시지와 실패 필드만 다시 보냈다. 모델이 같은 답을 반복하거나 도구 결과가 변하지 않으면 즉시 중단하도록 했고, retry_count, retry_reason, retry_tokens를 저장하니 재시도가 비용을 얼마나 키웠는지 사후에 확인할 수 있었다. 토큰 임계치 알림으로 비용 이상 징후를 조기에 잡아야 한다는 운영 권고를 따른 것인데 출처, 실패도 있었다 — 임계치를 너무 보수적으로 잡아 정상 작업까지 중단되는 오탐이 초기 2주간 반복됐고, 임계치 자체를 다시 조정하는 작업에 추가 리소스가 들었다.

공개 수치는 어디까지 참고할 수 있나?

공개된 예시값은 방향을 잡는 데는 유용하지만 그대로 견적서처럼 쓸 수는 없다. 2026년 기준 한 분석에는 단순 선형 대화가 상호작용당 약 0.04달러, 도구·추론·반복 루프를 포함한 오케스트레이션 워크플로가 약 1.20달러까지 늘 수 있다는 비교가 있다 출처. 이 값은 특정 분석의 예시일 뿐이고, 모델 버전과 가격표가 바뀌면 바로 낡는다. 그래서 우리도 벤치마크에 모델명, API 가격표 확인일, 입력·출력 토큰 수, 캐시 사용 여부, 도구 수, 최대 반복 횟수, 평가 데이터셋, 사람 검토 포함 여부를 함께 기록해두는 방식을 택했다. "2025년 측정" 같은 범위 표기 없이 숫자만 공유하면 몇 달 뒤 그 숫자는 틀린 말이 된다.

이 모니터링 구조가 막히는 지점은 어디인가?

토큰 비용과 사람 개입 비용을 같은 대시보드에 올려도, 사람 개입 비용 자체를 추정하는 기준이 조직마다 다르다는 문제는 남는다. 인건비·업무 복잡도·오류율이 다르면 "토큰 비용 대 사람 감독 비용" 비율은 금방 달라진다. 또한 캐시·배치 할인은 모델 제공자의 가격 정책과 버전에 따라 바뀌므로, 오늘 유리했던 구조가 다음 분기에도 유리하다는 보장은 없다. 무엇보다 "토큰 단가가 낮으니 자동화가 싸다"는 식의 판단은 피해야 한다. 실제 비용에는 모델 호출뿐 아니라 평가, 관측성, 인프라, 보안, 통합, 사람 검토와 재작업까지 들어가며, 운영 판단은 토큰 단가가 아니라 완료된 업무의 총비용으로 해야 한다는 지적이 있다 출처.

다음 실험에서는 무엇을 바꿀까?

이번 라운드에서 확인한 것은 토큰 비용표만 보고 자동화를 "싸다"고 판단하면 사람 수정 비용이 뒤늦게 터진다는 점이다. 다음에는 평가 기준 자체를 완료 작업당 비용, 성공률, 사람 승인율, 사람 수정률, 재시도율, 오류 1건당 비용을 함께 묶어서 보려 한다. 토큰을 줄였는가만 보면 값싼 모델이 사람 수정과 재작업을 늘려 총비용을 악화시킬 수 있다는 걸 이번에 직접 겪었기 때문이다. 구조는 1단계 호출 로깅부터 7단계 비용 대비 성과 재평가까지 순서대로 다시 밟을 계획이고, 임계치 오탐 문제는 단계별 알림 민감도를 나눠서 다시 잡을 생각이다.