사용량 기반 AI 코딩에는 결제 대시보드뿐만 아니라 런타임 예산(Runtime Budgets)이 필요하다

신호

GitHub는 Copilot이 사용량 기반 결제(usage-based billing) 방식으로 전환된 이후 AI 코딩에 대한 수요가 지속적으로 성장함에 따라, 6월에 "역대 최고의 달"을 기록했다고 보고되었습니다. Business Insider 또한 사용량 증가가 2026년의 주요 장애와 용량 압박의 원인이 되었다고 보도했습니다.

GitHub의 자체 결제 공지사항은 이러한 근본적인 변화를 설명합니다. Copilot은 6월 1일에 AI 크레딧(AI Credits) 방식으로 전환되었으며, 사용량은 입력(input), 출력(output), 캐시된 토큰(cached tokens)을 포함한 토큰 소비량을 기준으로 계산됩니다. 또한 GitHub는 Copilot이 여러 저장소(repositories)에 걸쳐 길고 다단계적인 코딩 세션을 수행할 수 있는 에이전트 플랫폼(agentic platform)으로 진화하고 있다고 설명했습니다.

이는 엔지니어링 측면에서 중요합니다.

길고 다단계적인 코딩 세션은 단순한 채팅 메시지가 아닙니다.

그것은 루프(loop)입니다.

그리고 루프에는 런타임 예산(runtime budgets)이 필요합니다.

이것이 단순한 가격 책정 문제가 아닌 이유

사용량 기반 결제는 한 가지 사실을 매우 명확하게 해줍니다:

런타임 동작(runtime behavior)은 재정적 결과(financial consequences)를 초래한다는 점입니다.

코딩 에이전트(coding agent)는 유용하기 때문에 비용을 쓸 수 있습니다.

하지만 막혀 있기 때문에 비용을 쓸 수도 있습니다.

실패 모드(failure mode)는 보통 극적으로 보이지 않습니다.

다음과 같이 보입니다:

파일 검사 (inspect files)
모델 호출 (call a model)
코드 수정 (edit code)
테스트 실행 (run tests)
실패 (fail)
컨텍스트 추가 (add context)
모델 다시 호출 (call the model again)
유사한 프롬프트로 재시도 (retry with a similar prompt)
전략 전환 (switch strategy)
다른 모델 호출 (call another model)
테스트 다시 실행 (run tests again)
계속 진행 (keep going)

모든 단계는 합리적으로 보일 수 있습니다.

하지만 전체 실행 과정은 여전히 낭비일 수 있습니다.

그것이 바로 결제 대시보드(billing dashboard)만으로는 충분하지 않은 이유입니다.

대시보드는 사용량이 발생한 '후'에 무슨 일이 일어났는지를 알려줍니다.

런타임 예산(runtime budget)은 다음 호출이 이루어져야 할지 여부를 결정합니다.

순진한 에이전트 루프 (A naive agent loop)

단순한 코딩 에이전트 루프는 다음과 같을 수 있습니다:

while (!task.done) {
const response = await provider.call({
model: task.model,
messages: task.messages,
});

task = await applyAgentStep(task, response);
}

이것은 이해하기 쉽습니다.

하지만 또한 위험합니다.

예산(budget)이 없습니다.

최대 단계 제한(max-step limit)도 없습니다.

재시도 폭풍 탐지(retry-storm detection)도 없습니다.

프롬프트 루프 탐지(prompt-loop detection)도 없습니다.

알려진 가격 확인(known-pricing check)도 없습니다.

진전 없음 탐지(no-progress detection)도 없습니다.

만약 이 루프가 막히게 되면, 다른 무언가가 멈추게 할 때까지 계속해서 비용을 지출하게 됩니다.

그 "다른 무언가"는 제공업체 제한(provider limit), 사용자의 중단, 관리자 상한선(admin cap), 또는 청구서일 수도 있습니다.

이 중 어느 것도 이상적인 런타임 제어(runtime controls)는 아닙니다.

호출 전 결정 단계 추가

더 안전한 패턴은 제공업체 호출(provider call) 전에 가드(guard)를 배치하는 것입니다:

const decision = guard.beforeCall({
  runId: task.id,
  model: task.model,
  messages: task.messages,
  stepCount: task.steps.length,
  retryCount: task.retryCount,
  budgetRemaining: task.budgetRemaining,
  previousPrompts: task.previousPrompts,
  progressState: task.progress,
});

if (!decision.allowed) {
  return {
    status: "stopped",
    reason: decision.reason,
    error: decision.error,
  };
}

const response = await provider.call({
  model: task.model,
  messages: task.messages,
});

정확한 API는 중요하지 않습니다.

배치 위치가 중요합니다.

체크는 제공업체 호출 전에 발생합니다.

이는 런타임이 토큰 사용량이 생성되기 전에 안전하지 않은 실행을 중단할 수 있음을 의미합니다.

런타임은 무엇을 체크해야 할까요?

1. 알려진 모델 가격(Known model pricing)

런타임이 모델 가격을 알지 못한다면, 신뢰할 수 있는 예산(budget)을 강제할 수 없습니다.

추측하지 마세요.

실패 시 차단(Fail closed)하세요.

if (!pricingCatalog.has(model)) {
  throw new Error(`Unknown pricing for model: ${model}`);
}

사용량 기반 과금(usage-based billing)에서 모델 식별(model identity)은 비용 계약의 일부입니다.

오타, 별칭(alias), 폴백(fallback), 또는 래퍼(wrapper) 불일치는 가정을 깨뜨릴 수 있습니다.

2. 작업 수준 예산(Task-level budget)

월간 한도는 유용합니다.

하지만 에이전트 실행(agent runs)에는 작업 수준의 예산도 필요합니다.

코드 리뷰 작업이 몇 시간 동안 지속되는 마이그레이션 작업과 동일한 지출 상한선을 가져서는 안 됩니다.

if (estimatedNextCallCost > budgetRemaining) {
  return {
    allowed: false,
    reason: "budget_exceeded",
  };
}

이를 통해 에이전트는 다음 호출이 일어난 후가 아니라, 호출 전에 중단할 수 있습니다.

3. 최대 단계 보호(Max-step protection)

에이전트 루프에는 단계 제한(step limits)이 필요합니다.

if (stepCount >= maxSteps) {
  return {
    allowed: false,
    reason: "max_steps_exceeded",
  };
}

이는 기본적이지만 중요합니다.

합리적인 단계 내에 완료하지 못하는 에이전트는 갇혀(stuck) 있을 수 있습니다.

4. 재시도 폭풍 탐지(Retry-storm detection)

재시도(Retries)는 유용합니다.

재시도 폭풍(Retry storms)은 유용하지 않습니다.

if (retryCount >= maxRetries && lastErrorsAreSimilar(task.errors)) {  
return {  
allowed: false,  
reason: "retry_storm_detected",  
};  
}

목표는 재시도(Retries)를 제거하는 것이 아닙니다.

목표는 맹목적인 재시도(blind retries)를 방지하는 것입니다.

1. 프롬프트 루프 탐지 (Prompt-loop detection)

에이전트(Agents)는 때때로 거의 동일한 프롬프트(prompt)를 반복해서 보냅니다.

미세한 문구 변화는 실행(run)이 진전되지 않고 있다는 사실을 숨길 수 있습니다.

if (isSimilarToRecentPrompt(currentPrompt, previousPrompts)) {  
return {  
allowed: false,  
reason: "similar_prompt_loop",  
};  
}

프롬프트 루프 탐지가 완벽하지는 않습니다.

하지만 단순한 버전이라도 명백한 낭비를 잡아낼 수 있습니다.

2. 진전 없음 탐지 (No-progress detection)

실행(run)이 활성화되어 있어도 여전히 무용지물일 수 있습니다.

에이전트는 파일을 편집하고, 도구(tools)를 호출하며, 로그를 생성하고 있을지도 모릅니다.

하지만 작업(task)이 수렴(converging)하지 않을 수 있습니다.

런타임(runtime)은 다음과 같은 진전 신호(progress signals)를 추적해야 합니다:

• 테스트 통과 (tests passing)
• 에러 감소 (errors decreasing)
• 의미 있는 파일 변경 (files changing meaningfully)
• 계획 단계 완료 (plan steps completing)
• 최종 답변에 근접 (final answer getting closer)
• 사용자 정의 성공 기준 (user-defined success criteria)

진전 없이 단계(steps)만 소비하는 실행은 중단하십시오.

관리자 제한(admin caps)만으로는 부족한 이유

GitHub의 발표에 따르면 관리자는 엔터프라이즈, 비용 센터(cost center), 사용자 수준에서 예산을 설정할 수 있으며, 포함된 크레딧이 소진되었을 때 추가 사용을 허용할지 결정할 수 있다고 합니다.

그것은 유용합니다.

하지만 관리자 제한은 광범위한 수준에서 작동합니다.

그들은 단일 에이전트 실행이 왜 갇혀(stuck) 있는지 알지 못합니다.

그들은 프롬프트가 반복되고 있는지 알지 못합니다.

그들은 이 특정 작업이 추가 호출을 할 가치가 있는지 알지 못합니다.

그 결정은 런타임(runtime)에 더 가까운 곳에서 이루어져야 합니다.

AI CostGuard가 필요한 위치

AI CostGuard는 제가 이 문제를 해결하기 위해 구축하고 있는 로컬 우선(local-first) TypeScript 런타임 계층입니다.

이는 제공자(provider) 호출이 실행되기 전에 비용이 많이 드는 에이전트 실패 모드(failure modes)를 차단하도록 설계되었습니다:

• 재시도 폭풍 (retry storms)
• 프롬프트 루프 (prompt loops)
• 최대 단계 폭발 (max-step explosions)
• 진전 없는 실행 (no-progress runs)
• 예산 초과 (budget overruns)
• 알 수 없는 모델 가격 (unknown model pricing)
• 폭주하는 에이전트 동작 (runaway agent behavior)

이것은 결제 대시보드(billing dashboard)가 아닙니다.

이것은 클라우드 제어 평면(cloud control plane)이 아닙니다.

이것은 엄격한 보안 경계(security boundary)도 아닙니다.

이것은 에이전트 비용(agent cost)과 루프 실패(loop failures)를 방지하기 위한 호출 전 킬 스위치(pre-call kill switch)입니다.

시사점 (The takeaway)

사용량 기반 AI 코딩은 엔지니어링 모델을 변화시킵니다.

단순히 다음과 같이 물어서는 안 됩니다:

“이 도구의 월간 비용은 얼마인가?”

대신 다음과 같이 물어야 합니다:

“내 에이전트가 막혔을 때 무엇을 하는가?”

에이전트 기반 코딩(agentic coding)에서 비용 제어는 런타임(runtime)에 속해야 합니다.

제공자 호출(provider call) 이전에.

청구서(bill)가 나오기 전에.

루프가 낭비가 되기 전에.

https://github.com/salimassili62-afk/ai-costguard