AI 에이전트 토큰 비용을 작업 단위로 통제하는 프롬프트 캐싱 설계

가격표가 내려가도 작업 비용은 커질 수 있다

모델 단가가 계속 낮아져도 100만 토큰 컨텍스트와 다단계 에이전트 루프는 호출당 토큰 수를 몇 배로 키운다. 호출 횟수까지 늘어나면 단가 인하보다 사용량 증가가 더 커져 청구액이 오르는 역전이 발생한다.

비용을 100만 토큰당 5달러 같은 가격표로만 관리하면 예산을 예측할 수 없다. 한 작업이 몇 번의 호출을 거치고, 그 과정에서 입력·출력·캐시 읽기·캐시 쓰기 토큰을 얼마나 소비했는지 알 수 없기 때문이다.

사용량을 밀어 올리는 요인은 컨텍스트 창 확장에 따른 입력 증가, 에이전트의 다단계 호출, 그리고 출력으로 계상되는 사고 과정(reasoning) 토큰이다. 따라서 관리 단위는 단가가 아니라 사용자 요청 하나를 완료하는 데 드는 총 토큰이어야 한다.

반복되는 시스템 지시와 참조 문서는 프롬프트 캐시에 고정할 수 있다. 품질을 낮추지 않고 입력 과금을 줄이는 구조적 수단이다. 다만 캐시는 접두부 일치를 기준으로 하므로, 기능을 켜는 것만으로는 충분하지 않다. 변동 요소가 앞에 놓인 프롬프트는 적중률이 낮아진다.

요청부터 결과까지 비용을 연결하는 계측 구조

작업 비용을 보려면 요청이 시작될 때 상관 식별자(correlation id)를 부여하고, 하위 호출 전체에 전달해야 한다. 각 호출의 입력·출력·캐시 읽기·캐시 쓰기 토큰을 이 식별자로 묶어 합산한다. 식별자가 중간에 끊기면 작업 단위 비용도 계산할 수 없다.

에이전트 루프에서는 모델 호출뿐 아니라 도구 호출과 서브에이전트 호출까지 트리로 남겨야 한다. 어느 단계가 토큰을 소비하는지 알아야 최적화 대상도 보인다. 반복 횟수의 평균만 봐서는 부족하다. 평균이 3회여도 상위 1%가 30회 반복한다면 비용은 그 꼬리 구간에서 커진다.

캐시 적중률은 캐시 읽기 토큰을 전체 입력 토큰으로 나눈 비율로 두고, 프롬프트 유형별로 분리해 확인한다. 적중률이 낮다면 타임스탬프, 사용자 식별자, 랜덤 요소처럼 자주 바뀌는 값이 접두부에 섞였는지 먼저 살핀다. 이런 요소는 뒤로 보내고, 고정 시스템 지시·참조 문서·few-shot 예시·도구 정의 스키마를 앞쪽에 둔다.

참조 문서가 갱신되면 캐시를 명시적으로 무효화해야 한다. 캐시 수명이 문서 갱신 주기보다 길면 오래된 근거가 계속 사용될 수 있다. 무효화 이벤트 자체도 로그로 남겨야 적중률 급락의 원인을 추적할 수 있다.

⤢✕

예산 한도와 캐시 정책을 운영 경로에 넣기

먼저 업무별로 작업 한 건에 허용할 비용을 정한다. 건당 매출 기여가 큰 작업과 내부 보조 작업은 같은 목표를 가질 이유가 없다. 목표 비용이 있어야 초과 여부와 최적화 우선순위도 정할 수 있다.

캐싱은 호출 빈도와 접두부 길이의 곱이 큰 곳부터 적용한다. 긴 고정 접두부를 반복 사용하는 경로가 가장 먼저 대상이 된다. 시스템 지시, 바뀌지 않는 참조 문서, 반복 few-shot 예시, 도구 정의 스키마가 여기에 해당한다.

에이전트 루프에는 반복 상한을 정책으로 적용하고, 상한에 도달하면 부분 결과를 반환한다. 동일 도구를 같은 인자로 재호출하는 등 진전 없는 반복은 조기 중단 신호로 다룬다. 무한 루프는 비용 사고의 대표 경로다.

모델별 단가는 코드 내부가 아니라 설정 테이블에서 관리한다. 벤더 가격 변경이 잦을수록 이 분리가 유리하다. 부서·서비스·사용자별 예산 한도는 게이트웨이에서 강제한다. 공용 API 키 하나로 전사가 사용하는 구조에서는 소비 주체별 통제가 어렵다.

한도에 가까워졌을 때는 상위 모델 요청을 하위 티어로 내리거나 effort를 낮출 수 있다. 즉시 차단보다 서비스 연속성을 유지하는 방식이다. 한도 초과 시 강등·대기·차단 중 무엇을 적용할지는 부서 성격에 맞춰 다르게 설정한다.

시간당 토큰 소비가 이동 평균에서 급증하면 알림을 발생시키고, 원인 조사 절차를 남긴다. 코드 배포, 프롬프트 변경, 캐시 무효화, 트래픽 증가를 구분해야 한다. 일 단위 확인은 하루치 손실을 전제한다.

운영 지표에는 작업당 총 토큰, 작업당 총비용, 캐시 적중률, 루프 반복 횟수 분포, 부서별 소비량을 포함한다. 단가 테이블·예산 한도·캐시 정책에는 각각 소유자를 지정하고 변경 이력을 유지한다.

가격 관리만으로는 놓치는 비용 신호

구분	작업당 총비용 관리	토큰 단가 기준 관리
예산 예측 정확도	높음	낮음
계측 구현 부담	큼(체인 추적 필요)	작음
최적화 대상 식별	가능	불가능
벤더 단가 변동 대응	흡수 가능	계획 무효화
사용량 증가 감지	즉시	청구서 시점
쇼백 적용	가능	어려움

토큰 단가 기준 관리는 벤더 가격표만 보면 되므로 계측 부담이 작다. 반면 작업별 호출 수와 토큰 소비량을 알 수 없어 예산 예측이 성립하지 않고, 사용량 증가는 청구서가 도착한 뒤에야 드러난다. 작업당 총비용 관리는 상관 식별자 전파와 체인 추적이 필요하지만, 비용을 만드는 구간을 찾아 쇼백까지 적용할 수 있다. 에이전트 루프를 운영한다면 이 방식이 사실상 필요하다.

저단가 모델로 바꾸는 일은 바로 실행할 수 있고 절감폭도 크지만, 품질 하락과 품질 하한 검증이 뒤따른다. 캐싱과 압축은 품질을 유지하면서 청구 토큰을 줄일 수 있으나, 프롬프트 구조 재설계와 압축 손실 관리가 필요하다. 적용 순서는 캐싱, 압축, 모델 전환이 적절하다. 품질 손실 없는 수단을 모두 검토하기 전에는 모델을 낮출 이유가 없다.

선불 약정은 단가 할인과 용량 확보에 유리하지만, 사용량 예측이 틀리면 미사용 잔액이 손실된다. 종량 과금은 유연한 대신 단가가 높고 급증 시 예산 방어가 어렵다. 작업당 총 토큰 데이터가 쌓이기 전에는 종량으로 운영하며 소비 데이터를 모으고, 패턴이 안정된 뒤 약정 규모를 산정하는 편이 안전하다.

서비스 원가와 통제 지점을 함께 본다

토큰은 소비 자원이고 작업은 원가 대상이다. 원가를 산정하려면 자원 단가와 원가 대상의 소비량을 분리해 관리해야 한다. 단가 인하는 공급자 측 변화이고 사용량 증가는 수요 측 변화이므로, 한 축만 보면 청구액 변동을 설명할 수 없다.

청구서를 받은 뒤 확인하는 행위는 통제가 아니다. 게이트웨이에서 한도를 적용하는 사전 통제와 이상 급증 알림을 통한 탐지 통제를 함께 둬야 한다. 티어 강등은 서비스 연속성과 예산 준수 사이의 완충 장치가 된다. 즉시 차단만 두면 운영 사고로 이어질 수 있다.

작업당 총비용은 AI 기능의 서비스 단위 원가를 계산하는 직접 입력값이다. 이 값이 없으면 손익을 계산할 수 없다. 캐시 적중률 역시 원가 구조를 바꾸는 변수다. 적중률이 개선되면 매출 증가 없이 마진이 개선된다.

운영 관행으로 자리 잡을 변화

2026년에는 프롬프트 캐시 적중률이 AI 서비스 운영의 표준 KPI로 편입되고, 캐시 친화적 프롬프트 구조가 설계 관행으로 정착할 전망이다. 모델 게이트웨이에는 예산 한도 강제와 티어 강등이 기본 기능으로 탑재되며 애플리케이션 코드에서 분리되는 흐름이 예상된다.

작업당 총비용을 계산하는 관측 도구가 표준화되면서 상관 식별자 전파가 SDK 기본 동작으로 제공되는 방향도 이어질 수 있다. 단가 하락과 사용량 증가의 역전이 반복될수록, 예산 계획은 단가가 아니라 작업 단위 소비량을 중심으로 세워질 전망이다.