AX LABS
← 블로그 AX Ops 방법론

에이전트 비용은 예산이다

토큰·도구·지연을 한 장부로 묶어야 한다

AX LABS 5분 읽기

현장에서 에이전트 PoC가 운영 전환 직전에 멈추는 장면은 비슷하다. 데모는 잘 된다. 답변 품질도 그럭저럭 나온다. 그런데 운영 부서가 묻는 순간 공기가 바뀐다. “이걸 전 직원이 쓰면 한 달에 얼마입니까. 느려지면 누가 책임집니까. 외부 도구 호출은 어디까지 허용합니까.” 이 질문에 답하지 못하면 에이전트는 제품이 아니라 시연물로 남는다.

에이전트 비용은 단순한 모델 사용료가 아니다. 입력 토큰, 출력 토큰, 캐시 입력, reasoning, 검색, 파일 검색, 코드 실행, MCP 도구, 외부 SaaS API, 재시도, 대기 시간이 한 실행 안에서 서로 영향을 준다. 그래서 월 예산표만으로는 부족하다. 실행 단위의 예산 장부가 필요하다.

비용은 세 줄로 쪼개야 보인다

에이전트 비용 모니터링의 첫 단위는 “업무 요청 1건”이다. 부서별 월 사용액을 먼저 보면 원인을 놓친다. 상담 요약, 계약 검토, 장애 분석, 보고서 초안은 같은 모델을 써도 호출 구조가 다르다.

AX Ops에서는 비용을 세 줄로 나눈다.

예산 항목 관리 대상 흔한 누수
토큰 예산 입력, 출력, 캐시, reasoning 긴 히스토리, 과한 근거 문서, 장황한 출력
도구 예산 검색, 파일 검색, 코드 실행, MCP, 사내 API 불필요한 재검색, 루프, 과도한 병렬 호출
지연 예산 첫 응답, 전체 완료, 도구 대기, 재시도 순차 호출, 느린 외부 API, 큰 출력

OpenAI 가격 문서는 모델 토큰 과금과 별도로 Web search, File search, Code Interpreter 같은 built-in tool 비용을 분리해 제시한다. Anthropic도 tool 사용 시 tool schema, tool_use, tool_result 블록이 토큰에 반영되고 server-side tool은 별도 사용량 과금이 붙는다고 명시한다. 비용 장부를 모델 호출료 하나로 합치면 이미 구조를 잘못 잡은 것이다.

에이전트 비용은 절감 대상이 아니라 실행 정책이다. 어떤 요청에 얼마만큼 생각하고, 어떤 도구를 몇 번까지 쓰며, 어느 시점에 멈출지 정하는 운영 규칙이다.

월 한도보다 실행 예산이 먼저다

대기업 조직은 예산을 월 단위로 관리하는 데 익숙하다. 그러나 에이전트는 월말에 터지지 않는다. 특정 프롬프트, 특정 문서 묶음, 특정 도구 경로에서 매번 새고 있다.

따라서 예산은 네 겹으로 둔다.

  1. 요청 예산: 업무 요청 1건의 최대 토큰·도구·지연 한도
  2. 단계 예산: 검색, 분석, 작성, 검증 단계별 한도
  3. 사용자 예산: 개인·팀·권한군별 사용 한도
  4. 업무 예산: 업무 유형별 월 집계와 승인 기준

핵심은 단계 예산이다. 예를 들어 계약 검토 에이전트가 문서 검색 단계에서 이미 충분한 근거를 찾았는데도 다시 검색하면 이후 모델 품질이 좋아지는 게 아니라 비용과 지연이 늘어난다. 장애 분석 에이전트가 로그 조회 도구를 반복 호출하면 답변이 깊어지는 게 아니라 운영 시스템에 부담을 준다.

OpenAI의 지연 최적화 가이드는 지연을 줄이는 원칙으로 더 적은 출력 토큰 생성, 더 적은 입력 토큰 사용, 요청 수 축소, 병렬화, LLM을 기본값으로 쓰지 않기 등을 제시한다. 이 원칙은 비용에도 그대로 적용된다. 출력 토큰을 줄이면 지연과 비용이 동시에 내려간다. 불필요한 LLM 호출을 제거하면 품질 저하 없이 운영 안정성이 올라간다.

모니터링은 대시보드가 아니라 차단 장치다

비용 대시보드는 필요하다. 그러나 대시보드만 있으면 사후 설명 도구에 그친다. 운영 에이전트에는 런타임 차단 장치가 들어가야 한다.

최소한 다음 필드는 모든 trace에 남겨야 한다.

  • 업무 유형, 사용자 권한, 에이전트 버전, 프롬프트 버전
  • 입력·출력·캐시·reasoning 토큰
  • 도구명, 호출 횟수, 성공·실패, 도구별 지연
  • 재시도 횟수, 중단 사유, human handoff 여부
  • 요청 예산 대비 사용률과 초과 지점

LangSmith는 agent trace에서 LLM call, tool invocation, retrieval step을 실행 트리로 보여주고 cost·latency attribution을 제공한다고 설명한다. 중요한 것은 특정 제품명이 아니다. 실행 트리 없이는 비용 원인을 찾을 수 없다는 점이다. 최종 답변만 저장하는 로그는 운영 로그가 아니다.

차단 규칙도 명시해야 한다. 도구 호출이 예산에 닿으면 더 싼 모델로 요약한다. 지연 예산을 넘기면 부분 결과를 먼저 보여주고 후속 작업으로 넘긴다. 근거 검색이 실패하면 무한 재시도하지 않고 사람에게 넘긴다. 이것이 AX Ops에서 말하는 운영 설계다.

AX Ops는 비용을 설계 산출물로 만든다

에이전트 비용 관리는 FinOps팀에 넘길 일이 아니다. 설계 단계에서 업무별 예산, 도구 사용 정책, 지연 SLA, 차단 규칙, 리포팅 구조가 함께 나와야 한다.

AX LABS가 보는 좋은 산출물은 간단하다. “이 에이전트는 어떤 요청에서 어떤 모델을 쓰고, 어떤 도구를 몇 번까지 호출하며, 얼마 이상 느려지면 어떻게 행동한다”가 한 장으로 설명된다. 그 문서가 있어야 보안, 재무, 현업, IT가 같은 화면을 본다.

다음 에이전트 프로젝트를 시작한다면 모델 성능표보다 먼저 비용 장부를 그려야 한다. 토큰·도구·지연 예산을 업무 흐름에 붙이고, trace로 검증하고, 초과 시 자동으로 멈추게 만들어야 한다. AX는 도입이 아니라 운영에서 판가름 난다. 비용을 운영 규칙으로 바꾸는 방식은 AX Ops 방법론 →에서 다룬다.

참고