AI 에이전트 비용 관리와 거버넌스 — 폭주를 막는 실전 설계

8월 20, 2026

에이전트를 붙이고 나서 처음 놀라는 지점은 성능이 아니라 청구서다. 챗봇은 한 번 물으면 한 번 답하지만, 에이전트는 한 번의 요청으로 수십 번 모델을 호출한다. 단가는 그대로인데 호출 횟수가 두 자릿수로 곱해지는 구조다. 게다가 에이전트는 스스로 멈추지 않는다. 실패한 도구 호출을 계속 다시 부르고, 같은 파일을 몇 번이고 다시 읽는다. 이 글은 어디서 비용이 새는지, 무엇을 코드로 못 박아야 하는지, 그리고 에이전트에게 어디까지 권한을 줄 것인지를 정리한다.

비용이 새는 다섯 지점

무한 재시도 — 종료 조건 없이 도구 호출을 반복한다. 가장 흔하고 가장 비싸다.
컨텍스트 재전송 — 매 턴 전체 대화와 파일을 다시 첨부한다. 열 번째 턴은 첫 턴의 몇 배 비용이 든다.
도구 과다 노출 — 쓰지 않는 도구의 정의까지 매 호출마다 함께 전송된다. 연결한 서버가 늘수록 고정 비용이 커진다.
모델 획일화 — 로그 분류나 형식 변환처럼 쉬운 일까지 최상위 모델로 처리한다.
병렬 폭주 — 동시 실행 수를 정하지 않아 한 요청이 수십 개 호출로 번진다.

다섯 가지의 공통점은 단건 비용이 작다는 것이다. 한 번의 호출은 눈에 띄지 않고, 합계만 조용히 쌓인다. 그래서 대응도 사후 절감이 아니라 사전 상한이어야 한다.

가장 먼저 할 일 — 상한을 코드로 못 박는다

프롬프트에 "간결하게 처리하라"고 쓰는 것은 비용 통제가 아니다. 실행 루프 바깥에 물리적 한계를 두는 것이 통제다.

class Budget:
    def __init__(self, max_steps=15, max_tokens=250_000, max_parallel=4):
        self.max_steps, self.max_tokens = max_steps, max_tokens
        self.max_parallel = max_parallel
        self.steps, self.tokens = 0, 0

    def charge(self, step_tokens: int):
        self.steps += 1
        self.tokens += step_tokens
        if self.steps > self.max_steps:
            raise BudgetExceeded("step_limit")
        if self.tokens > self.max_tokens:
            raise BudgetExceeded("token_limit")

# 요청 단위로 새 Budget을 만들고, 초과는 조용히 넘기지 말고 예외로 올린다

중요한 것은 초과를 실패로 드러내는 것이다. 예산이 떨어졌는데 부분 결과를 성공으로 반환하면, 미완성 출력이 다음 단계로 흘러가 더 큰 비용을 만든다.

모델 라우팅 — 난이도로 계층을 나눈다

단일 요청 안에서도 작업 난이도는 균일하지 않다. 파일 목록을 훑어 후보를 고르는 일과 설계를 판단하는 일은 요구 수준이 다르다. 라우팅의 원리는 단순하다. 쉬운 일은 가벼운 모델로 보내고, 어려운 일에만 상위 모델을 쓴다.

공식 가격표를 보면 같은 제공사 안에서도 가장 가벼운 계층과 최상위 계층의 토큰 단가는 배수 단위로 벌어진다. 여러 모델을 함께 제공하는 라인업이 일반적인 지금은, 어느 모델이 가장 좋은가보다 어떤 일을 어느 계층으로 보낼 것인가가 실질적인 절감 레버다. 참고로 2026년 7월 말에는 상위 성능대 모델을 기존과 같은 단가로 내놓는 사례도 있었는데, 이런 변화가 잦기 때문에 라우팅 규칙은 특정 모델 이름이 아니라 계층 이름으로 관리하는 편이 안전하다.

계층	보낼 작업	판단 기준
경량	분류, 추출, 형식 변환, 요약, 라우팅 판단 자체	정답이 좁고 검증이 기계적으로 가능
표준	일반 코드 작성, 리뷰, 문서화, 대화 응답	맥락은 필요하나 추론 깊이는 보통
최상위	아키텍처 판단, 어려운 디버깅, 장기 추론	틀렸을 때 비용이 큰 결정

라우팅 규칙에서 흔한 실수 두 가지가 있다. 하나는 사용자 등급으로 나누는 것이다. 유료 사용자에게 무조건 상위 모델을 주는 방식은 비용만 늘고 품질 차이는 잘 안 난다. 기준은 작업 난이도여야 한다. 다른 하나는 라우팅 판단 자체를 비싼 모델에게 시키는 것이다. 분류는 경량 모델이나 규칙 기반으로 충분하다.

실패 시 상향 재시도를 붙이면 안정성이 올라간다. 경량 모델로 처리하고 검증에 실패하면 그때 상위 계층으로 한 번만 올린다. 이 방식은 평균 비용을 낮추면서 최악의 품질을 방어한다. 다만 승격 횟수에도 상한을 둬야 무한 상향으로 번지지 않는다.

캐싱과 배치는 언제 무력화되는가

입력 캐싱과 비동기 배치 처리는 공식 문서에 명시된 대표적인 절감 수단이고, 조건이 맞으면 절감폭이 크다. 문제는 에이전트 워크로드가 그 조건을 자주 깬다는 데 있다.

캐싱은 앞부분이 고정돼야 이득이 난다. 그런데 에이전트는 매 턴 도구 결과가 앞쪽에 끼어들어 접두부가 계속 바뀌기 쉽다. 고정 지시문과 변동 이력을 물리적으로 분리하고, 변하지 않는 블록을 앞에 몰아 두는 배치 설계가 선행돼야 한다.
배치는 즉시 응답이 필요 없는 작업에만 쓸 수 있다. 대화형 에이전트 본체에는 못 붙이지만, 야간 인덱싱이나 대량 분류 같은 주변 작업은 대부분 옮길 수 있다. 실시간 경로와 지연 허용 경로를 처음부터 분리해 두면 나중에 옮기기 쉽다.

즉 절감 기법을 나중에 얹는 게 아니라, 어느 호출이 실시간이고 어느 호출이 아닌지를 아키텍처 단계에서 갈라 두는 것이 핵심이다.

무엇을 기록할 것인가

비용을 줄이려면 먼저 어디에 쓰였는지 알아야 한다. 그런데 모델 제공사 콘솔의 합계만으로는 어느 기능이 얼마를 썼는지 알 수 없다. 호출 경로를 하나의 게이트웨이로 모으고, 매 호출마다 아래 항목을 남기는 방식이 실무에서 가장 무난하다.

{
  "ts": "2026-08-04T09:12:31Z",
  "request_id": "req_8f21",
  "actor": "svc-agent-review",     // 사람인가 서비스인가
  "feature": "pr_review",          // 어느 기능이 쓴 비용인가
  "model_tier": "standard",
  "tokens_in": 18240, "tokens_out": 1120,
  "cache_read": 15000,             // 캐시가 실제로 먹었는지
  "tool_calls": 6, "retries": 1,
  "latency_ms": 4310,
  "stop_reason": "completed",      // completed / budget / error
  "approval": "auto"               // auto / human / denied
}

feature와 stop_reason이 특히 값을 한다. 기능 단위로 묶어야 "리뷰 자동화가 전체의 절반을 쓴다" 같은 판단이 가능하고, 종료 사유를 보면 예산 초과로 끝난 비율이 드러난다. 예산 초과 비율이 높다면 그건 비용 문제가 아니라 설계 문제다.

알림 기준도 정해 두는 편이 좋다. 월 예산 대비 누적 비율, 요청당 평균 토큰의 급증, 재시도율 상승 세 가지면 대부분의 폭주를 초기에 잡는다.

권한 경계 — 에이전트에게 무엇을 허용할 것인가

거버넌스에서 가장 실용적인 질문은 "이 작업은 되돌릴 수 있는가"다. 도구 종류가 아니라 복구 비용으로 경계를 나누면 규칙이 단순해진다.

자동 허용 — 읽기 전용 조회, 테스트와 린트 실행, 로컬 브랜치 커밋처럼 되돌리기 쉬운 작업.
승인 후 실행 — 의존성 설치, 외부 API 호출, 원격 저장소 푸시, 비용이 발생하는 작업.
금지 — 운영 데이터베이스 쓰기, 인프라 삭제, 비밀키 직접 접근. 승인 절차를 두는 게 아니라 아예 도구를 주지 않는다.

승인 경계를 설계할 때 자주 빠지는 함정이 승인 피로다. 확인 창이 너무 자주 뜨면 사람은 내용을 안 보고 누른다. 그러면 승인 절차가 있으나 마나가 된다. 자동 허용 목록을 충분히 넓게 잡고, 대신 금지 목록을 좁고 단단하게 유지하는 쪽이 실제로는 더 안전하다.

권한은 역할 단위로 주는 것도 중요하다. 조사 담당 에이전트에게 쓰기 도구를 주지 않는 것만으로 사고 가능성의 상당 부분이 사라진다. 프롬프트로 금지하는 것과 도구를 안 주는 것은 강도가 다르다.

감사 로그 — 나중에 설명할 수 있는가

조직 규모가 커지면 "왜 이 변경이 들어갔는가"에 답해야 하는 순간이 온다. 여러 규제·인증 절차에서도 문서화된 정책만이 아니라 그 정책이 기술적으로 강제되고 있는지, 그리고 로그가 남는지를 함께 확인하는 흐름이 자리 잡는 추세다. 정책 문서만 있고 강제 수단이 없는 상태가 가장 흔한 지적 사항으로 언급된다.

최소한 아래 세 가지는 남겨 두는 편이 좋다.

누가 승인했는가 — 사람 승인인지 자동 허용인지, 자동이라면 어느 규칙에 의한 것인지.
무엇을 바꿨는가 — 도구 호출 인자와 실제 변경 대상. 결과 요약만으로는 재현이 안 된다.
어떤 데이터를 봤는가 — 에이전트가 접근한 소스. 유출 사고 조사에서 첫 번째로 필요한 정보다.

도입 체크리스트

요청 단위 예산(스텝·토큰·동시 실행)을 코드로 강제했는가.
예산 초과와 재시도 초과가 성공이 아니라 실패로 기록되는가.
호출이 게이트웨이 한 곳을 지나며 기능 단위로 태깅되는가.
작업 난이도 기준 라우팅 규칙이 있고, 계층 이름으로 관리되는가.
실시간 경로와 지연 허용 경로가 분리돼 있는가.
자동 허용·승인·금지 목록이 문서가 아니라 설정으로 존재하는가.
승인 결정과 도구 호출 인자가 감사 로그에 남는가.

정리

에이전트 비용 문제의 본질은 단가가 아니라 횟수이고, 거버넌스 문제의 본질은 금지 목록이 아니라 복구 비용이다. 상한을 코드로 걸고, 난이도로 모델을 나누고, 기능 단위로 기록하고, 되돌릴 수 있는지로 권한을 가르는 네 가지면 대부분의 사고는 예방된다. 반대로 이 넷이 없으면 어떤 절감 기법을 붙여도 새는 곳이 더 빨리 커진다.

함께 보면 좋은 글: Claude 프롬프트 캐싱으로 API 비용 90% 줄이기

※ 모델 계층 구성과 가격 정책은 2026년 8월 기준이며 변경될 수 있습니다. 정확한 단가는 각 제공사 공식 가격 문서를 확인하시기 바랍니다.

이 블로그 검색

에이븐스튜디오