Put Agents on a Budget: 에이전트 작업량에 상한을 걸고 결과 책임자를 정하는 AI 비용 관리

AI 청구서를 예측하려면 토큰 단가보다 에이전트가 요청 하나에 하는 일의 양을 묶어야 합니다. Forrester는 입력량, 모델 호출 수, 하위 에이전트 수에 상한을 걸고 예산이 확인된 지출만 승인하라고 권합니다. 확대 여부는 생산성이 아니라 매출·비용·리스크 지표로 판정하고 결과 책임자 한 명이 분기 마일스톤으로 추적합니다.

요약

TechTarget의 Tim Murphy가 2026년 11월 6일, 뉴욕에서 열린 Forrester Technology & Innovation Forum East 세션을 기사로 옮겼습니다. 발표자는 Forrester 수석 애널리스트 Kevin Ogunsua이고 세션은 AI 지출의 ‘공포 쇼’를 피하고 가치를 증명하는 법을 다뤘습니다. 문을 연 것은 청중의 경험담입니다. 한 참석자는 OpenAI에서 예상하지 못한 청구서를 받았는데 그달 요금이 평소 한 해 동안 쓰던 금액과 비슷했다고 말했습니다. Ogunsua는 원인을 단가가 아닌 작업량에서 찾습니다. 토큰당 가격을 알아도 에이전트가 작업 하나를 끝내려고 모델을 몇 번 부르고 다른 에이전트를 몇 개 불러들일지는 실행할 때마다 다릅니다. 시제품은 예산 안에서 만들었어도 운영으로 넘어가면 인프라, 보안 통제, 직원의 일하는 방식을 바꾸는 비용이 붙습니다. 그는 LLM이 공짜라도 운영에 올리는 비용은 남는다고 말했습니다.

같은 단가라도 요청마다 작업량이 달라 청구액을 미리 알기 어려움

처방은 두 갈래입니다. 하나는 청구서를 예측할 수 있게 만드는 일로, 에이전트의 작업량에 상한을 걸고 예산이 확인된 지출만 진행시키며 실행 한 번의 비용을 낮춥니다. 다른 하나는 돈을 쓸 가치가 있는지 판정하는 일입니다. 확대하기 전에 매출, 비용, 리스크 중 무엇을 바꾸는지 정하고 결과 책임자 한 명이 분기 마일스톤으로 추적합니다. Ogunsua는 이 전환을 tokenmaxxing(토큰을 많이 쓰는 것을 성과로 보는 태도)에서 valuemaxxing(가치를 키우는 데 맞추는 태도)으로 가는 길이라고 불렀습니다. 기사는 Forrester가 2027년 AI가 비즈니스 기술 지출의 20%를 차지하고 그 대부분이 서버와 장비로 갈 것으로 본다는 전망도 전합니다. 아래에서 여섯 가지 작동 원리와 세 사례를 본 뒤 직접 돌릴 때 필요한 기술·현업 디테일을 붙입니다.

Ogunsua가 붙인 이름. 항목은 세션 내용을 새로 묶음

핵심 메커니즘

Agent Work Variability: 단가를 알아도 청구서를 모르는 이유

에이전트 비용은 단가에 작업량을 곱한 값이고 그 작업량이 실행마다 바뀝니다. 기존 IT 예산은 컴퓨트, 네트워크, 스토리지 수요를 추정한 뒤 다년 계약과 클라우드 약정으로 묶어 계획했습니다. 에이전트는 같은 프로세스를 돌려도 요청에 따라 일의 양이 달라집니다. 간단한 요청은 모델 호출 한 번으로 끝나고 복잡한 요청은 호출이 여러 번 이어지거나 다른 에이전트를 불러들이며 그 에이전트도 다시 모델을 부릅니다. 사용량 과금 API로 에이전트를 돌리는 곳이면 어디든 해당합니다. 좌석당 정액 라이선스로만 쓰는 도구라면 이 변동은 작습니다. 가상 예시로, 계약 검토 에이전트가 2쪽짜리 비밀유지계약은 호출 1회로 끝내고 80쪽짜리 공급 계약은 조항별로 하위 에이전트 6개를 띄워 호출 40회를 쓰는 식입니다.

단가는 고정, 작업량(n·m)이 실행마다 바뀜

Three Limits: 입력량, 호출 수, 위임 수에 상한을 건다

Ogunsua가 짚은 통제 지점은 세 곳입니다. 모델에 보내는 정보량, 워크플로 하나가 부를 수 있는 모델 호출 수, 워크플로가 불러들일 수 있는 다른 에이전트 수입니다. 셋 다 요청 하나가 호출의 사슬로 번지는 길목을 막습니다. 입력량은 호출 한 번의 크기를, 호출 수는 사슬의 길이를, 위임 수는 사슬이 갈라지는 폭을 묶는다고 보면 됩니다. 셋을 함께 걸어야 최악의 경우 비용을 계산해 예산을 잡을 수 있습니다. 탐색형 연구처럼 작업량을 미리 정하기 어려운 일은 상한을 넉넉히 두고 대신 사람이 확인하는 지점을 넣는 편이 맞습니다.

세 가지 상한. 오른쪽 칸은 상한이 없을 때

Pre-approval Funding Check: 예산이 확인된 지출만 진행한다

Ogunsua는 자신이 일했던 공공 부문 시스템을 예로 듭니다. 그 시스템에서는 예산이 있는지 확인된 뒤에야 발주가 진행됐습니다. 그는 AI 지출에도 같은 확인을 두자고 제안합니다. 요청이 들어오면 해당 부서 예산이 남아 있는지, 그 부서 예산으로 낼 수 있는 활동인지를 먼저 보고 통과한 실행만 진행합니다. 실행 건수가 많고 건당 금액이 작은 워크플로는 건마다 확인하기보다 일·주 단위 한도를 미리 배정하는 편이 운영하기 쉽습니다.

공공 부문 발주 시스템의 예산 확인을 AI 지출에 옮긴 모양

Cost per Run: 실행 한 번의 비용을 낮추는 네 가지

상한이 비용의 위쪽을 막는다면 실행당 비용을 낮추는 일은 평균을 끌어내립니다. 기사는 네 가지를 듭니다. AI가 실제로 필요한 단계 가려내기, 작업마다 맞는 모델 고르기, 알맞은 곳에 캐싱 쓰기, 모델 응답을 워크플로가 쓰는 만큼으로 줄이기입니다.

왼쪽 열은 기사의 네 가지 방법, 오른쪽 열은 적용 예(새로 작성)

Valuemaxxing: 생산성 대신 사업 지표와 결과 책임자로 판정한다

지출 통제는 청구서를 예측하게 해 주지만 그 프로젝트에 돈을 더 쓸지는 다른 계산으로 정합니다. Ogunsua는 확대 전에 그 프로젝트가 매출을 늘리는지, 비용을 줄이는지, 리스크를 줄이는지를 밝히라고 합니다. 그는 이렇게 못 박았습니다. “Productivity alone is not going to get you your ROI.” 지표는 사업이 이미 추적하는 것을 씁니다. 리더들이 산출물에 합의하면 결과를 책임질 사람 한 명을 정하고 분기 마일스톤으로 진척을 봅니다. 탐색 단계의 작은 실험에는 이 장치가 무겁습니다. 확대 예산을 요청하는 시점부터 적용합니다.

생산성만으로는 ROI가 나오지 않는다는 전제

Outcome-based Contract: 토큰 대신 결과에 돈을 거는 계약

계약 구조도 바꿀 수 있습니다. 토큰 기반 가격은 쓴 만큼 냅니다. 성과 기반 가격은 구매자와 벤더가 합의한 결과에 대가를 묶습니다. 기사의 가정 예에서 500만 달러의 AI 투자는 토큰을 사는 데 쓸 수도 있고 8개 분기 동안 매출 5,000만 달러를 만든다는 목표에 묶은 계약으로 바꿀 수도 있습니다. Ogunsua는 일부 하이퍼스케일러(대형 클라우드 사업자)가 이런 약속을 내건다고 짚었습니다. 그런 약속은 측정 가능한 조항으로 계약에 넣고 분기마다 진척을 따지라고 권합니다. 결과 지표를 벤더가 아닌 우리 쪽 시스템에서 잴 수 있을 때 맞는 방식입니다.

기사에 나온 가정 예. 막대 길이는 0 기준 비례(단위 백만 달러)

통념과 다른 주장

흔히 이렇게 봅니다토큰 단가와 예상 사용량을 알면 AI 예산을 잡을 수 있고 벤더 청구서가 곧 AI 비용이다.

저자는 이렇게 봅니다단가를 알아도 에이전트의 작업량이 실행마다 달라 청구액을 예측하기 어렵습니다. 청구서 밖에 있는 운영화 비용도 예산에 넣어야 합니다.

근거한 달 요금이 평소 1년 지출과 비슷했던 참석자의 사례, 그리고 시제품 뒤에 붙는 인프라·보안·업무 변경 비용입니다. Ogunsua는 LLM이 무료여도 운영에 올리는 비용은 든다고 말합니다.

청구서 밖 비용: 인프라, 보안 통제, 일하는 방식 변경

흔히 이렇게 봅니다AI로 업무 시간이 줄면 그 생산성 향상이 곧 ROI다.

저자는 이렇게 봅니다생산성만으로는 ROI가 나오지 않습니다. 줄어든 시간이 매출, 비용, 리스크 중 어디로 이어지는지를 사업 지표로 보여야 확대할 근거가 됩니다.

근거자산관리 회사 예에서 판정 기준은 업무 속도가 아니라 남은 역량으로 고객을 더 받고 운용 자산을 늘렸느냐입니다.

자산관리 회사 예에서 판정 지표는 고객 수와 운용 자산

저자가 든 사례

깜짝 청구서: 한 달 요금이 평소 1년 지출과 비슷했다

상황: 세션 참석자의 조직이 OpenAI를 쓰고 있었습니다.
한 일: 작업량 상한이나 사전 승인 장치를 두었는지는 기사에서 밝히지 않았습니다.
결과: 그달 요금이 평소 한 해 지출과 비슷한 청구서가 왔습니다. 조직 이름과 금액은 기사에서 밝히지 않았습니다.
연결: Agent Work Variability, Three Limits, Pre-approval Funding Check.

세션을 연 청중 사례. 조직 이름과 금액은 기사에서 밝히지 않음

자산관리 회사: 빨라진 업무를 고객 수와 운용 자산으로 잰다

상황: 한 자산관리 회사가 AI로 고객 업무를 더 빨리 끝냅니다.
한 일: 절약한 시간을 더 많은 업무를 처리하는 데 씁니다.
결과: 판정 지표는 고객을 더 받고 운용 자산(AUM)을 키웠느냐입니다. 회사 이름과 수치는 기사에서 밝히지 않았습니다.
연결: Valuemaxxing.

기사에 수치 없음

공공 부문 발주 시스템: 예산이 확인돼야 발주가 나간다

상황: Ogunsua가 일했던 공공 부문 시스템입니다.
한 일: 예산이 있는지 확인된 뒤에만 발주가 진행되게 했습니다.
결과: 같은 확인을 AI 지출에 두자는 제안으로 이어졌습니다. 시스템 세부는 기사에서 밝히지 않았습니다.
연결: Pre-approval Funding Check.

Ogunsua가 일했던 시스템. 세부는 기사에서 밝히지 않음

기술 디테일: 워크플로에 예산을 거는 법

아래 필드명, 설정값, 구성은 실행 제안이자 가상 예시입니다. 기사에서 온 원칙은 괄호에 표시했습니다.

워크플로마다 예산 봉투를 선언합니다(Three Limits). 상한 세 가지와 금액 한도를 워크플로 정의 옆에 한 파일로 둡니다. 배포 파이프라인이 이 파일 없는 워크플로는 올리지 않게 합니다.

{
  "workflow_id": "contract-review-v3",
  "cost_center": "LEGAL-OPS",
  "outcome_owner": "법무운영팀장",
  "max_input_tokens_per_call": 24000,
  "max_model_calls_per_run": 12,
  "max_subagents_per_run": 3,
  "max_subagent_depth": 1,
  "max_cost_usd_per_run": 1.50,
  "daily_budget_usd": 300,
  "on_limit": "handoff_to_human",
  "warn_at_ratio": 0.8
}

max_subagent_depth를 1로 두면 하위 에이전트가 또 다른 에이전트를 부를 수 없어 위임이 한 단계에서 멈춥니다. 상한값은 처음부터 정하지 말고 2주 동안 상한 없이 로그만 쌓은 뒤 실행당 호출 수의 p95(상위 5% 경계값)에 여유 20%를 더한 값으로 시작합니다.

상한은 오케스트레이터가 호출 직전에 셉니다(Three Limits). 모델을 부르기 전에 이번 실행의 누적 호출 수, 누적 토큰, 띄운 하위 에이전트 수를 보고 상한을 넘으면 호출하지 않습니다. 하위 에이전트도 부모 실행의 카운터를 함께 씁니다. 따로 세면 위임할 때마다 상한이 새로 생깁니다. 입력 상한을 넘는 문서는 잘라 보내지 말고 검색으로 관련 구간만 골라 넣습니다. 80%에 닿으면 경고를 남기고 100%에 닿으면 on_limit 정책대로 멈추거나 그때까지 결과를 담아 사람에게 넘깁니다.

실행 제안(가상 예시). 필드명과 80% 경고선은 새로 정한 값

지출은 원장에 먼저 예약합니다(Pre-approval Funding Check). 실행을 시작할 때 최악 비용(호출 상한 × 호출당 최대 토큰 × 단가)을 계산해 cost_center의 남은 예산에서 예약합니다. 예약이 안 되면 실행하지 않습니다. 실행이 끝나면 실제 비용으로 확정하고 남은 예약분을 돌려줍니다. 부서 예산으로 낼 수 있는 활동은 cost_center마다 허용 workflow_id 목록으로 둡니다.

실행당 비용은 네 군데서 줄입니다(Cost per Run). 워크플로 정의의 단계마다 needs_llm 표시를 달아 규칙으로 되는 단계는 모델을 부르지 않습니다. 분류·추출은 작은 모델로, 판단이 갈리는 예외만 큰 모델로 보냅니다. 시스템 프롬프트와 공통 참조 문서를 입력 앞부분에 고정하면 제공사의 프롬프트 캐시를 탈 수 있습니다. 출력은 구조화 출력으로 필요한 필드만 받고 최대 출력 토큰을 정합니다.

실행마다 비용 로그를 남기고 결과 지표와 잇습니다(Valuemaxxing). 실행 로그에 run_id, workflow_id, cost_center, model_calls, subagents, input_tokens, output_tokens, cost_usd, limit_hit, outcome_ref(그 실행이 기여한 사업 레코드 ID, 예: 처리한 고객 건)를 남깁니다. 주간으로 실행당 비용의 p50·p95와 상한 도달 비율을 보고 outcome_ref로 사업 지표 한 단위당 AI 비용을 계산합니다.

막히는 경우	증상	대응
상한이 너무 빡빡함	상한 도달 비율 10% 초과, 사람에게 넘어가는 건 급증	2주 로그로 p95 재계산, 상한 상향 또는 작업 분할
하위 에이전트가 따로 셈	실행당 비용이 상한의 몇 배	부모 실행 카운터 공유, `max_subagent_depth` 1
재시도 폭주	오류 뒤 같은 호출 반복	재시도도 호출 수에 포함, 지수 대기와 재시도 2회 상한
예약이 실제보다 큼	예산이 남는데 실행이 막힘	최악 비용 대신 p99 기반 예약, 일 단위 한도 병행
비용은 줄었는데 결과도 나빠짐	결과 지표 하락	모델 낮춘 단계부터 되돌려 비교, 품질 표본 검사 주 1회

현업 실행 디테일: 누가, 언제, 무엇을

아래 역할, 일정, 기준은 기사의 권고를 바탕으로 새로 짠 가상 예시입니다.

역할	맡는 일
CIO	상한 정책과 사전 승인 규칙 승인, 분기 점검 주재
재무(FP&A)	부서별 AI 예산과 허용 활동 정의, 원장과 재무 시스템 대사
결과 책임자(사업부 리더 1명)	사업 지표·기준선·분기 마일스톤 확정, 계속·조정·중단 제안
AI·플랫폼 엔지니어	워크플로 목록, 예산 봉투, 카운터·로그 구현
구매·법무	벤더 성과 약속을 측정 가능한 계약 조항으로 정리

준비물. 최근 3개월 AI 벤더 청구서와 사용량 내역, 운영 중인 에이전트 워크플로 목록과 담당 부서, 부서별 IT 예산과 비용 코드, 시제품에서 운영으로 넘어갈 때 든 인프라·보안·교육 비용, 각 워크플로가 바꾸려는 사업 지표의 지난 4개 분기 값이 필요합니다.

기간	할 일	산출물
1~2주	워크플로 목록, 청구서 밖 비용 집계, 워크플로마다 매출·비용·리스크 중 하나 지정	워크플로·비용·지표 대장, 결과 책임자 지정
3~5주	예산 봉투 작성, 카운터와 원장 예약 구현, 부서 허용 활동 정의	상한 설정 파일, 사전 승인 흐름
6~12주	운영하며 실행당 비용·상한 도달·사업 지표를 주간 기록, 실행당 비용 절감 적용	주간 대시보드, 비용 절감 전후 비교
13주	분기 점검, 워크플로마다 계속·조정·중단 판정, 벤더 계약 조항 반영	판정서, 다음 분기 마일스톤

가상 예시 일정. 1~2주 목록, 3~5주 상한, 6~12주 운영, 13주 판정

현장에 물을 것.

지난 분기 AI 청구서가 예상과 가장 크게 어긋난 워크플로는 무엇이고 그달 실행당 호출 수는 얼마였나요?
이 워크플로가 바꾸려는 사업 지표는 매출, 비용, 리스크 중 무엇이고 지금 어느 시스템에서 보고 있나요?
시제품 뒤에 추가로 든 인프라, 보안, 교육 비용은 어느 부서 예산에서 나갔나요?
상한에 걸려 멈춘 작업은 누가 이어받고 몇 시간 안에 처리해야 하나요?
벤더가 약속한 성과 가운데 우리 시스템에서 직접 잴 수 있는 것은 무엇인가요?

진행 판정 기준(예시). 분기 말에 실행당 비용의 p95가 예산 봉투 안에 있고 상한 도달 비율이 5% 아래이며 지정한 사업 지표가 기준선보다 나아졌으면 확대 예산을 엽니다. 비용은 통제됐지만 사업 지표가 움직이지 않았다면 한 분기 더 보되 실행량을 늘리지 않습니다. 두 분기 연속 지표가 움직이지 않으면 중단하거나 다른 지표를 겨냥해 다시 설계합니다.

AX 적용 제언. 에이전트를 여러 부서에 퍼뜨리기 시작한 기업이라면 새 에이전트를 더 만들기 전에 이 장치를 먼저 깝니다. 순서는 워크플로 목록과 결과 책임자 지정, 예산 봉투와 사전 승인, 실행당 비용 절감, 분기 판정입니다. 첫 대상은 사용량 과금 비중이 크고 요청마다 작업량 편차가 큰 워크플로(문서 검토, 리서치, 고객 응대 자동화)가 좋습니다. 스폰서는 CIO와 CFO가 함께 맡아야 부서 예산 규칙이 섭니다. 벤더 갱신 협상을 앞두고 있다면 결과 지표 하나를 정해 성과 조항을 시험 삼아 넣어 봅니다.

원문 사례

항목	내용
원문	TechTarget, 2026.11.6 게재, Tim Murphy 작성
행사	Forrester Technology & Innovation Forum East(뉴욕), Kevin Ogunsua 세션
화자	Kevin Ogunsua, Forrester 수석 애널리스트
문제	토큰 단가를 알아도 에이전트 작업량이 실행마다 달라 청구액 예측이 어려움, 청구서 밖 운영화 비용
청중 사례	OpenAI 깜짝 청구서, 한 달 요금이 평소 1년 지출과 비슷
상한 세 가지	모델에 보내는 정보량, 워크플로당 모델 호출 수, 불러들이는 다른 에이전트 수
사전 승인	공공 부문 발주 시스템처럼 예산 확인 뒤 지출, 부서 예산으로 낼 활동 정의
실행당 비용	AI가 필요한 단계 선별, 작업별 모델 선택, 캐싱, 응답 길이 제한
가치 판정	매출·비용·리스크 중 무엇인지 확대 전 확정, 기존 사업 지표, 결과 책임자 1명, 분기 마일스톤
사례	자산관리 회사: 고객 수와 운용 자산 증가로 판정
계약	토큰 기반 대 성과 기반, 가정 예 500만 달러 대 8개 분기 매출 5,000만 달러 목표, 분기 점검
전망	Forrester: 2027년 AI가 비즈니스 기술 지출의 20%, 대부분 서버·장비

핵심 개념

Token-based pricing: 모델이 읽고 쓴 토큰 양에 따라 요금을 내는 방식입니다. 단가는 정해져 있어도 총액은 사용량에 따라 움직입니다.
Outcome-based pricing: 구매자와 벤더가 합의한 결과(예: 매출, 처리 건수)에 대가를 묶는 방식입니다.
Operationalization: 시제품을 실제 업무에 올리는 일입니다. 인프라, 보안 통제, 업무 방식 변경, 교육 비용이 여기서 생깁니다.
Caching: 같은 입력이나 같은 질의의 결과를 저장해 두고 다시 쓰는 방법입니다.
Hyperscaler: 대규모 데이터센터로 클라우드와 AI 인프라를 파는 대형 사업자입니다.
AUM: Assets Under Management. 자산관리 회사가 고객 대신 굴리는 자산 총액입니다.

내 메모

TODO: 내 생각 추가

원문은 TechTarget의 「AI spending horror show? Put agents on a budget and demand results」(Tim Murphy, 2026.11.6)입니다. Forrester Technology & Innovation Forum East에서 Kevin Ogunsua가 한 세션을 기사로 옮긴 글이며 노트는 이 기사만 근거로 썼습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. 500만 달러와 5,000만 달러는 기사 속 가정 예입니다. 핵심 개념의 뜻풀이와 언제 쓰고 언제 안 쓰는지에 대한 설명은 일반적인 정의로 보탰습니다. 계약 검토·송장 처리 예, JSON 예시, 카운터·원장 예약 방식, 막히는 경우 표, 역할·일정·판정 기준, 인포그래픽은 기사에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.