GitHub은 이번 달 Copilot CLI와 Copilot SDK에 AI 크레딧 세션 제한(AI credit session limits)을 추가했으며, 이 기능은 결제 관련 용어가 들려주는 것보다 훨씬 더 흥미롭습니다.

가장 명백한 해석은 간단합니다. 에이전트(agents)는 비용이 발생하므로, 벤더들이 사용자에게 비용 발생을 멈출 수 있는 조절 장치를 제공한다는 것입니다.

좋습니다. 그것은 사실입니다.

하지만 더 나은 해석은 이것입니다. 에이전트 크레딧 제한은 새로운 타임아웃(timeout)이 되고 있다는 점입니다.

watching the meter

과거의 자동화에서는 통제 불능의 작업(runaway job)이 CPU, 메모리, 디스크, 락(locks), 큐 용량(queue capacity), 그리고 어쩌면 누군가의 일요일 아침을 태워버렸습니다. 에이전트 자동화에서 통제 불능의 세션은 토큰(tokens), API 호출(API calls), 도구 실행(tool executions), CI 분(minutes), 리뷰 집중력(review attention), 클라우드 샌드박스(cloud sandboxes), 브랜치 이름(branch names), 그리고 에이전트가 저장소의 절반을 헤맨 끝에 왜 풀 리퀘스트(pull request)를 생성했는지 설명해야 하는 사람의 인내심을 태워버립니다.

이것은 단지 비용의 문제만이 아닙니다.

이것은 제어(control)의 문제입니다.

타임아웃은 결코 시간만을 위한 것이 아니었다

타임아웃은 실제 시스템을 운영하기 전까지는 작은 설정값처럼 보입니다.

타임아웃은 의존성(dependency)이 건강하지 않다고 인정하기 전까지 서비스가 얼마나 오래 기다릴지를 결정합니다. 백그라운드 작업이 불멸의 존재가 되는 것을 막습니다. 워커 풀(worker pools)을 보호합니다. 실패를 가시화합니다. 엔지니어가 특정 워크플로우(workflow)에 대해 무엇이 "너무 긴" 것인지를 결정하도록 강제합니다.

좋은 타임아웃은 임의적인 것이 아닙니다. 그것은 작업에 대한 믿음을 인코딩(encode)합니다.

이 요청은 얼마나 걸려야 하는가? 호출자(caller)는 어느 정도의 지연을 견딜 수 있는가? 의존성이 느리지만 죽지는 않았다면 어떻게 되는가? 재시도(retry)해야 하는가? 빠르게 실패(fail fast)해야 하는가? 성능을 저하시켜야(degrade) 하는가? 사람에게 페이지(paged)를 보내야 하는가?

숫자는 가장 흥미롭지 않은 부분입니다. 흥미로운 부분은 그 뒤에 숨겨진 소유권(ownership)에 대한 대화입니다.

에이전트 크레딧 제한도 이와 같은 형태를 띠고 있습니다.

GitHub의 변경 사항(changelog)에 따르면, 이제 Copilot은 모델 호출(model calls), 서브에이전트(subagents), 그리고 압축(compaction)과 같은 백그라운드 작업을 포함하여 세션 전체에 걸친 AI 크레딧 사용량을 제한할 수 있습니다. 비대화형 실행(noninteractive runs)의 경우, 명령줄 플래그(command-line flag)를 통해 단일 실행의 범위를 제한할 수 있습니다. 제한에 도달하면 에이전트는 작업이 완료되거나 수동으로 중단될 때까지 계속하는 대신 작업을 마무리합니다.

이것은 제품 기능(product feature)입니다.

동시에 설계 제약(design constraint)이기도 합니다.

관리되지 않는 작업에는 예산 경계가 필요합니다

GitHub 변경 사항에서 무서운 단어는 "크레딧"이 아닙니다.

바로 "자동화(automation)"입니다.

GitHub는 이 기능을 에이전트의 작업을 아무도 능동적으로 모니터링하지 않을 때 유용하다고 명시적으로 프레임화하고 있습니다. 바로 그 순간이 멘탈 모델(mental model)이 변하는 시점입니다. 사람이 지켜보고 있는 채팅 어시스턴트는 관리되는 에이전트가 할 수 없는 방식으로 엉성하게 행동할 수 있습니다. 사람은 중단하거나, 방향을 재설정하거나, 어시스턴트가 이제 확신을 가지고 엉뚱한 건물을 개보수하고 있다고 판단할 수 있기 때문입니다.

관리되지 않는 에이전트에는 더 엄격한 경계가 필요합니다.

에이전트가 악해서가 아닙니다. 관리되지 않는 작업은 작은 실수들이 복리로 쌓이는 곳이기 때문입니다.

지출 상한선(spend cap)이 없는 코딩 에이전트는 계속 검색하고, 계속 요약하고, 계속 보조 작업을 생성하고, 계속 컨텍스트를 압축하고, 계속 다른 테스트를 시도하고, 계속 다른 파일을 읽고, 계속해서 또 다른 모델 호출을 위해 스스로를 설명할 수 있습니다. 각 단계는 개별적으로는 합리적으로 보일 수 있습니다. 하지만 전체 경로는 여전히 낭비가 될 수 있습니다.

이는 분산 시스템(distributed systems)에서 익숙한 패턴입니다. 대부분의 장애는 하나의 극적인 악당 요청에 의해 발생하는 것이 아닙니다. 압박 속에서 일반적인 재시도(retries), 큐(queues), 폴백(fallbacks), 그리고 기본값(defaults)들이 나쁘게 상호작용하면서 발생합니다.

에이전트들은 지식 노동(knowledge work)에 바로 그와 동일한 패턴을 가져오고 있습니다.

크레딧 제한은 제품의 관점입니다

크레딧 제한은 중립적이지 않습니다.

너무 낮게 설정하면 에이전트가 유용한 작업을 수행할 만큼 충분한 컨텍스트 (Context)를 확보하기 전에 멈춰버립니다. 너무 높게 설정하면 에이전트가 작은 작업을 비용이 많이 드는 고고학적 탐사로 변질시킬 수 있습니다. 이를 전역적으로 설정하면 단순한 팀들은 이해하기 쉽겠지만, 복잡한 워크플로 (Workflow)는 기이한 한계에 부딪힐 것입니다. 너무 유연하게 설정하면 모든 리포지토리 (Repository)가 아무도 기억하지 못하는 자신들만의 작은 예산 정책을 만들어내게 됩니다.

이는 결국 플랫폼 팀이 에이전트 예산 표준을 세워야 함을 의미합니다.

단순히 "월간 AI 지출액" 같은 것이 아닙니다.

그보다는 다음과 같은 것에 가깝습니다:

• 의존성 업데이트 (Dependency bump)를 위한 최대 크레딧 예산
• 보안 자동 수정 (Security autofix)을 위한 별도의 예산
• 마이그레이션 조사 (Migration research)를 위한 더 높은 예산, 단 코드 변경 전 필수적인 인간 검토 포함
• 서브 에이전트 (Subagents)를 위한 별도의 예산
• 새로운 증거 없이 CI 실패가 반복될 때의 강제 중단 (Hard stop)
• 비용이 많이 드는 모델 사용 시 왜 필요했는지 설명하는 흔적을 남겨야 한다는 규칙

만약 당신이 여전히 에이전트를 장난감이라고 생각한다면, 이 모든 것이 관료주의적으로 들릴 것입니다.

하지만 에이전트가 노동자라면, 예산은 업무 계약의 일부입니다.

workflow with a receipt

리뷰 비용은 여전히 비용입니다

관련된 GitHub Copilot 코드 리뷰 포스트는 이 점을 더욱 명확하게 해줍니다.

GitHub는 Copilot 코드 리뷰를 공유된 Unix 스타일의 탐색 도구로 옮기는 내부 변경 사항을 설명했는데, 초기에는 리뷰 에이전트의 성능이 저하되었습니다. 즉, 비용은 상승하고 유용한 이슈는 더 적게 포착되었습니다. 해결책은 마법 같은 새로운 모델이 아니었습니다. 리뷰어가 실제로 풀 리퀘스트 (Pull Request)를 검사하는 방식에 맞춰 워크플로 (Workflow)를 재구성하는 것이었습니다.

그것이 교훈입니다.

에이전트 비용은 단순히 토큰당 가격이 아닙니다. 그것은 워크플로 (Workflow)의 형태입니다.

리포지토리 (Repository)를 광범위하게 탐색하는 리뷰 에이전트는 더 나은 리뷰를 생성하지 못한 채 더 많은 컨텍스트 (Context), 더 많은 비용, 그리고 더 많은 인간의 신뢰를 소모할 수 있습니다. 더 나은 리뷰 에이전트는 디프 (Diff)에서 시작하여, 좁은 범위의 질문을 던지고, 증거를 수집하며, 충분한 정보가 모이면 멈춥니다.

그것은 유능한 인간 리뷰어들이 일하는 방식과 정확히 일치합니다.

차이점은 인간은 보통 피로를 느낀다는 것입니다. 에이전트에게는 그 피로를 정책 (Policy)으로 번역해 줄 필요가 있습니다.

크레딧 제한 (Credit limits)은 그 번역 방법 중 하나입니다.

이것은 가격 책정이 아니라 로그 옆에 있어야 합니다

저는 에이전트 크레딧 제한이 결제 화면에만 숨겨져 있는 것을 원하지 않습니다.

그것은 로그 (Logs), 트레이스 (Traces), 도구 호출 (Tool calls), 작업 템플릿 (Task templates), 그리고 리포지토리 정책 (Repository policy) 옆에 있어야 합니다.

에이전트가 크레딧 제한에 도달하여 멈췄을 때, 유용한 질문은 단지 "비용이 얼마나 들었는가?"만이 아닙니다.

유용한 질문들은 다음과 같습니다:

• 작업이 무엇을 하려고 했는가?
• 어떤 증거를 수집했는가?
• 어떤 도구 호출 (Tool calls)이 예산을 소모했는가?
• 너무 일찍 검색 범위를 넓혔는가?
• 하위 에이전트 (Subagents)가 도움이 되었는가, 아니면 단순히 활동량만 늘렸는가?
• 유용한 부분적 결과 (Partial result)를 남기고 멈췄는가?
• 이 작업 유형에 더 높은 제한을 부여해야 하는가, 아니면 작업 프레임 (Framing)이 잘못되었는가?

이것이 바로 관찰 가능성 (Observability) 작업입니다.

만약 유일한 출력이 "제한 도달"뿐이라면, 그 기능은 계량기 (Meter)에 불과합니다. 만약 출력이 그 경로를 설명한다면, 그 기능은 운영 피드백 (Operational feedback)이 됩니다.

이 지점이 성숙한 에이전트 플랫폼이 차별화되는 지점이 될 것입니다. 승리하는 제품은 단순히 기업이 돈을 덜 쓰게 만드는 것에 그치지 않을 것입니다. 그들은 팀이 왜 특정 작업에 그만큼의 비용이 발생했는지 이해하도록 도울 것입니다.

크레딧은 새로운 폭발 반경 (Blast radius)이다

클라우드는 팀들에게 돈이 아키텍처 신호 (Architecture signal)라는 것을 학습시켰습니다. 잘못된 오토스케일링 (Autoscaling) 규칙, 수다스러운 서비스 (Chatty service), 잊혀진 로그 스트림 (Log stream), 또는 과도하게 큰 데이터베이스는 실제 청구서로 변할 수 있습니다. 그것이 클라우드를 나쁘게 만든 것이 아닙니다. 비용을 엔지니어링의 일부로 만든 것입니다.

AI 에이전트도 동일한 일을 하고 있지만, 훨씬 더 밀접한 계층에서 수행하고 있습니다.

지출 단위가 추론 (Reasoning), 도구 사용 (Tool use), 그리고 생성된 작업에 결합되어 있습니다. 허술한 지시 (Instruction)는 단순히 혼란스러운 프롬프트 (Prompt)에 그치지 않습니다. 그것은 반복적인 비용 패턴이 될 수 있습니다. 모호한 자동화는 단순히 낮은 품질에 그치지 않습니다. 그것은 지속적인 예산 누수 (Budget leak)가 될 수 있습니다. 누락된 중단 조건 (Stop condition)은 단순히 정돈되지 않은 상태가 아닙니다. 그것은 축소된 형태의 운영 리스크 (Production risk)입니다.

이것이 제가 타임아웃 (Timeout) 비유를 좋아하는 이유입니다.

진지한 사람이라면 아무도 "타임아웃 (Timeout)은 분산 시스템 (Distributed systems)을 사용하기에 너무 위험하다는 증거다"라고 말하지 않습니다.

우리는 "당연히 시스템에는 타임아웃이 필요하다"라고 말합니다.

에이전트 (Agent)에 대해서도 똑같이 말해야 합니다.

당연히 세션 (Session)에는 제한이 필요합니다.

당연히 그 제한은 작업 (Job)에 따라 달라져야 합니다.

당연히 중단 시에는 증거가 남아야 합니다.

당연히 팀은 계속해서 한계치에 도달하는 작업들을 검토해야 합니다.

핵심 (The punchline)

에이전트 크레딧 제한 (Agent credit limits)은 마치 과금 제어 (Billing controls)처럼 보이지만, 이는 과금이 고통이 가장 먼저 가시화되는 지점이기 때문입니다.

하지만 그것들은 실제로는 초기 단계의 제어 평면 (Control-plane) 기능입니다.

이 기능들은 팀으로 하여금, 특정 작업이 중단, 요약, 그리고 다른 결정을 요청하기 전에 어느 정도의 자율적 추론 (Autonomous reasoning)을 수행할 가치가 있는지 말하도록 강제합니다. 이것은 건강한 방식입니다. 이는 에이전트의 작업을 "모델이 끝났다고 느낄 때까지 계속하라"에서 "우리가 선택한 경계 안에서 작동하라"로 전환시킵니다.

에이전트 기반 소프트웨어 엔지니어링 (Agentic software engineering)의 미래에는 우리가 이미 존중하는 법을 배운 모든 지루한 제어 장치들이 포함될 것입니다: 타임아웃 (Timeouts), 할당량 (Quotas), 예산 (Budgets), 재시도 (Retries), 로그 (Logs), 트레이스 (Traces), 소유권 (Ownership), 그리고 에스컬레이션 경로 (Escalation paths).

훌륭합니다.

이는 이 카테고리가 성숙해지고 있음을 의미합니다.

참고 문헌 (References)

• GitHub Changelog, Set AI credit session limits in Copilot CLI and SDK
• GitHub Blog, Better tools made Copilot code review worse. Here's how we actually improved it.

automation meter cooling down

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작하기 위해 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.