Agent 호출 비용, 사람이 아니라 시스템이 통제하게 하려면
← 전체 목차 · 이전: 왜 모델 다운그레이드 전략을 만들어야 하는가 · 다음: 업무 로그와 모델 로그를 구분해야 한다
"성능비 좋은 모델을 고르고, 호출 횟수를 줄이고, 부를 때마다 필요한지 한 번 더 생각한다" — 틀린 말은 아니지만 이것은 사람의 자각에 기대는 방식이다. 장체인 작업이 대형모델을 반복 호출하고, 같은 파라미터로 제3자 도구를 중복 조회하는 상황에서 비용은 선형이 아니라 지수적으로 불어나고, 청구서를 열어봐야 초과를 안다. "다 쓰고 나서 계산서 확인"은 관제가 아니라 사후 기록일 뿐이다. 진짜 관제는 호출이 발생하기 이전에 결정돼 있어야 한다.
비용이 새는 다섯 갈래
모델 단가가 비싼 것이 문제의 본질이 아니다. 문제는 아래 다섯 지점에서 낭비가 누적된다는 데 있다.
| # | 실효 지점 | 낭비의 형태 |
|---|
| 1 | 장체인 작업의 무의미한 반복 추론 | Token 무효 소모 |
| 2 | 제3자 도구 중복·무효 호출 | 불필요한 과금 발생 (실패 후 무작정 N회 재시도 포함) |
| 3 | 모델 선정 일률화 | 간단한 작업에 고사양 모델을 씀 — 연산 자원 오배치 |
| 4 | 예산 사전 관제 부재 | 쓴 만큼 계산 — 사후에야 초과를 발견 |
| 5 | 작업 스케줄링 무차별 | 피크 시간대에 고가 자원을 전량 점유 — 비용 피크 실속 |
기준선: 계량 + 라우팅 + 쿼터
세 가지를 순서대로 세운 뒤, 중복 제거 · 작업 강등 · 동적 피크 분산을 보조 수단으로 얹는다.
1. 전체 링크 비용 계량
매 모델 호출·도구 호출을 실시간 계량
작업 / 업무 라인 / 시나리오 3개 차원으로 귀속
→ 모든 지출 항목을 추적·통계 가능하게 만듦 (라우팅과 쿼터의 데이터 기반)
2. 등급별 모델 라우팅
작업 복잡도 + 정밀도 요구를 입력으로
단순 조회·기초 처리 → 경량 모델
복잡 추론·생성 작업 → 주력 모델
→ 효과 기준선을 지키면서 비용을 최대로 낮춤
3. 도구 호출 사전 중복 제거
동일 파라미터 + 동일 시나리오 요청 → 과거 결과를 바로 반환
→ 중복 과금 호출을 막고, 실패 후 무작정 재시도도 함께 억제
4. 예산 쿼터 하드 관제
업무 라인별·주기별로 비용 쿼터를 배분
임계 근접 → 자동 경보 / 임계 초과 → 자동 작업 강등 또는 제한
→ "무제한 소모"라는 경로를 아예 없앰
계량이 먼저인 이유는 라우팅도 쿼터도 전부 "이 한 스텝에 얼마를 썼는가"라는 사실 위에서만 작동하기 때문이다. 작업 / 업무 라인 / 시나리오 세 축으로 귀속하지 않으면 쿼터를 나눌 수도, 이상을 특정 시나리오로 좁혀 찾을 수도 없다.
프로덕션 투입의 이상 처리 4계
기준선 세 가지를 실전에서 살아남게 만드는 디테일.
| 항목 | 규칙 |
|---|
| 비용-효과 기준선 | 업무 시나리오마다 최소 효과 요구치를 미리 못 박음. 비용 최적화가 이 선 아래로 내려가는 것은 금지 — 절약한 소액이 대형 사고로 돌아오는 것을 막는 하한선 |
| 피크 관제 | 피크 시간대 작업을 자동 등급화 — 핵심 작업은 자원 우선 보장, 비핵심 작업은 대기 또는 강등 실행 (피크 분산·저점 보충) |
| 비용 이상 탐지 | 단건 비용이 비정상적으로 높은 호출을 자동 식별 → 먼저 차단한 뒤 심사 (먼저 통과시키고 사후 복기하지 않음) — 코드 버그로 인한 비용 눈덩이를 사전 차단 |
| 거버넌스 시스템 자체의 다운그레이드 | 계량·라우팅 시스템 자체가 장애 나면, 업무는 고정 쿼터 제한 모드로 내려가 비핵심 작업을 중단하고 비용 레드라인만 지킨다 — 관제 시스템의 가용성에 기대지 않는 가장 단순한 방어선 |
핵심 통찰
- 비용 실패는 조달 문제가 아니라 아키텍처 문제다 — "모델이 비싸다"는 진단은 해법을 "더 싼 모델로 바꾸자"로 좁혀 버린다. 실제 누수는 장체인 공회전, 중복 호출, 자원 오배치에서 나므로 모델을 바꿔도 한 푼도 절약되지 않는다.
- "돌아간다"와 "돈이 안 샌다"는 서로 다른 축이다 — 기능이 완결돼도 재무적으로는 지속 불가능할 수 있다. 비용 관제를 명시적으로 설계하지 않은 시스템은 이 두 번째 축이 통째로 비어 있는 것이다.
- 관제는 호출 이전으로 당겨져야 한다 — "다 쓰고 계산서를 본다"는 사후 기록이지 관제가 아니다. 진짜 통제는 이 요청을 시작하기 전에 쿼터가 남았는지, 과거 결과로 대체 가능한지, 이 작업에 주력 모델이 필요한지를 판단하는 지점에서 일어난다. 사후에만 발동하는 메커니즘은 전부 관제로 칠 수 없다.
- 계량은 라우팅·쿼터가 서는 지반이다 — "이 한 스텝이 얼마였는가"라는 사실 없이는 쿼터를 나눌 수도, 이상을 찾을 수도, 최적화 효과를 검증할 수도 없다. 그래서 기준선에서 "모델을 바꾸자"보다 계량을 앞에 둔다.
- 절감은 반드시 효과 하한과 함께 가야 한다 — 비용-효과 기준선이 없는 절감은 또 다른 사고다. 단일 목표로 비용만 최적화하는 것은 프로덕션 환경에서 반드시 대가를 치른다.
- 중복 호출은 선형이 아니라 지수로 자란다 — 장체인 Agent의 매 스텝이 재시도와 재조회를 유발할 수 있어, 호출 빈도가 짧은 시간 안에 수십 배로 뛴다. 선형적인 사람의 순찰로는 따라잡을 수 없으므로 중복 제거와 회로 차단을 메커니즘 층위에서 끊어야 한다.
- 피크 시점의 정답은 등급화이지 예산 증액이 아니다 — 핵심 업무는 자원을 우선 배정하고 비핵심은 지연·강등시켜 피크를 분산하고 저점을 보충하는 것은 스케줄링 문제이지 재무 결재 문제가 아니다.
- 관제 시스템 자체도 실패 대비책이 있어야 한다 — 계량·라우팅이 죽었을 때 고정 쿼터 제한 모드로 강등하고 비핵심 작업을 중단하는 것은, 가용성이 불확실한 컴포넌트 하나에 비용 레드라인 전체를 걸지 않겠다는 뜻이다. "더 멍청하지만 반드시 작동하는" 모드가 최후의 보루여야 한다.
엔지니어링 실전 Tips
- 귀속 차원(작업 / 업무 라인 / 시나리오)을 처음부터 세 개 다 갖출 것. 하나라도 빠지면 쿼터를 업무 라인별로 나눌 수 없고 이상도 특정 시나리오로 좁혀 찾을 수 없다.
- 중복 제거의 히트 조건은 "파라미터 + 시나리오"를 동시에 볼 것. 같은 파라미터라도 시나리오가 다르면 의미가 다를 수 있다.
- 임계값은 반드시 2단계로 나눌 것. 근접 시 경보, 초과 시 자동 강등/제한 — 1단계뿐이면 너무 시끄럽거나 너무 늦다.
- 재시도 정책이 제3자 청구서의 주요 변수임을 잊지 말 것. "실패 후 무작정 N회 재시도"는 건당 과금 구조에서 그대로 청구액에 곱해진다.
- 이상 호출은 먼저 차단하고 나중에 심사할 것. 먼저 통과시키고 사후 복기하는 순서는 코드 버그로 인한 비용 눈덩이를 막지 못한다.
- 비용 최적화율과 효과 달성률을 항상 짝으로 볼 것. 비용 최적화율만 단독으로 오르면 효과가 몰래 깎이고 있다는 신호일 수 있다.
- 거버넌스 시스템의 강등 모드는 계량·라우팅 링크에 의존하지 않는, 가장 단순한 고정 쿼터 방식으로 설계할 것. 관제 시스템이 죽었을 때 관제 시스템에 기대는 대비책은 대비책이 아니다.
- 모델 등급 배정 자체는 이 문서의 범위가 아니라 AGENT/05 모델 라우팅과 AGENT/33 모델 다운그레이드 전략에서 다룬다. 이 문서는 그 라우팅 결정이 비용 관제 체계 안에서 어떻게 계량·쿼터와 맞물리는지에 집중한다.