저는 자체 인프라에서 많은 고객을 위해 에이전트(agent)를 운영하며, 그들이 사용하는 모든 토큰(token) 비용을 지불합니다. 어딘가에 한도를 설정해 두어도, 에이전트가 밤새 루프(loop)를 돌면 아침이 되기 전에 예산이 바닥나 버립니다. 대시보드는 이미 돈을 다 쓰고 난 후에 얼마를 썼는지 알려줍니다. 저는 턴(turn)이 실행되기 전에 지출을 확인하고 싶었습니다.

턴 실행 전 예약 (Reserved before the turn)

지출은 턴이 실행되기 전에 추정되고 예약됩니다. 턴은 실행 전 미리 추정치를 기록합니다:

[run] estimate | Estimated per-turn tokens (pre-plan) | {"stage": "estimate", "input_tokens_est": 0, "output_budget": 4000, "est_turn_tokens": 115943, "reservation_amount_dollars": 2.0}

예약은 앱(app)별로 구성됩니다:

{"economics": {"reservation_amount_dollars": 0.2}}

만약 예약 금액이 사용자의 한도를 초과할 것으로 예상되면, 해당 턴은 실행되지 않습니다. 체크가 토큰이 소비되기 전, 즉 진입 단계에서 이루어지기 때문에 한도가 유지됩니다.

예약은 홀딩(hold)일 뿐, 최종 비용이 아닙니다

이것은 제 사고방식에서 가장 중요한 교정 사항이었습니다. 예약은 한 가지 질문에 답합니다: 이 사용자의 자금이 초기 홀딩(hold) 금액을 감당할 수 있는가? 이것은 턴에 대한 고정 가격이 아닙니다.

턴이 실행됩니다. LLM 호출, 임베딩(embeddings), 검색(search) 등 각각의 작업은 발생할 때마다 계량(metered)됩니다. 턴이 완료되면, 정산(settlement) 과정에서 실제로 소비된 금액과 예약된 금액을 대조하여 조정합니다. 만약 실제 사용량이 더 적다면, 사용되지 않은 홀딩 금액은 해제됩니다. 만약 더 많다면, 정산 시 실제 기록된 비용을 적용합니다.

진입할 때 예약하고, 나갈 때 실제 사용량을 바탕으로 정산하십시오. 예약은 약속된 가격도 아니고 엄격한 최대치도 아닙니다. 그것은 입장 제어(admission control)입니다. 할당량(quotas), 동시성 제한(concurrency limits), 런타임 캡(runtime caps)은 별도의 제어 장치가 처리합니다. 만약 실제 지출이 사용자의 자금을 초과하면, 프로젝트 예산이 부족분을 흡수하며, 정확히 누가 그 원인을 제공했는지 기록합니다.

계량(metering)이 발생하는 곳

모든 도구는 경제적으로 추적 가능하도록(economically trackable) 표시될 수 있습니다. 추적은 데코레이터(decorator)로서 호출 시점에 적용됩니다 — track_llm, track_embedding, track_web_search — 따라서 앱 코드, 에이전트 하네스(agent harness), 그리고 샌드박스(sandbox) 내부에서 실행되는 생성된 코드 등 호출이 발생하는 모든 곳에서 사용량이 집계됩니다.

요청 컨텍스트(request context)는 이러한 경계를 넘어 호출 체인(call chain)을 따라 이동합니다. 작업이 신뢰할 수 있는 자식 프로세스(child process)나 감독 컨테이너(supervisor container)로 이동할 때, 작은 컨텍스트 스냅샷(context snapshot)이 함께 전달되며 제공자 도구(provider tools)가 실행되기 전에 복원됩니다. 에이전트가 직접 생성한 코드가 호출을 수행한 경우라도, 비용은 해당 호출을 유발한 사용자에게 부과됩니다.

생성된 코드는 제공자 자격 증명(provider credentials)이나 네트워크 액세스 권한을 부여받지 않습니다. 유료 기능이 필요한 경우, 신뢰할 수 있는 감독 측(supervisor-side) 도구에 요청합니다. 해당 도구는 원래의 요청 신원(request identity) 및 회계 컨텍스트(accounting context)를 가지고 실행되며, 제공자 호출은 신뢰할 수 있는 측에서 계량(metered)됩니다.

한 가지 솔직한 한계점은, 임의의 계측되지 않은(uninstrumented) 코드가 단순히 KDCube에서 실행된다고 해서 자동으로 계량되지는 않는다는 것입니다. 새로운 유료 서비스는 실제 사용량을 보고하는 회계 통합(accounting integration)이 필요합니다. 런타임(runtime)은 실제로 관찰할 수 있는 경제적 이벤트(economic events)만을 강제할 수 있습니다.

동일한 가드(guard)가 채팅 외부에서도 작동합니다

채팅 턴(chat turns)은 경제 인지적 엔트리포인트(economics-aware entrypoint)를 사용하지만, 모델이 채팅에만 국한되는 것은 아닙니다. 백그라운드 작업(background job), API 호출, 또는 예약된 작업(scheduled task)도 동일한 가드로 책임 있는 작업을 감쌀 수 있습니다:

async with EconomicsGuard(...):
    result = await do_accounted_work()

진입 시, 가드는 실행 가능성을 확인하고, 자금을 예약하며, 회계를 안정적인 요청 ID(request ID)에 바인딩(bind)합니다. 종료 시, 해당 요청의 이벤트들을 집계하고 실제 비용을 정산합니다. 작업이 사용자 메시지에서 시작되었든 크론 잡(cron job)에서 시작되었든, 동일한 결제자 신원, 동일한 할당량 정책(quota policy), 동일한 자금 조달 및 정산 규칙이 적용됩니다.

이것을 깨뜨리려고 노력하기 (Try to break it)

경제학(economics) 및 회계(accounting) 모듈은 GitHub에 있으며, 예약 로직과 추적 데코레이터가 포함되어 있습니다. 만약 미터를 우회하여 샌드박스 내부에서 회계(accounting)를 통해 비용을 흘려보내는 호출을 얻을 수 있다면, 그것이 제가 가장 보고 싶은 문제입니다.

다음으로: 제 에이전트는 매일 사용자의 Gmail과 Slack에서 작동합니다. Claude Code와 같은 외부 에이전트도 포함되는데, 이들 중 어느 것도 제공자 토큰(provider token)을 본 적이 없습니다. 이것이 작동하게 만드는 인증 체인(auth chain)입니다.

에이전트 자체가 아닌 에이전트 스택의 부분들에 대한 시리즈의 두 번째 글입니다. 첫 번째 글은 툴 호출(tool calling) 제거에 관한 것으로, 여기에서 확인할 수 있습니다.