팀이 실제로 지키는 AI 코딩 예산 설계법

인당 상한이 가장 먼저 무너진다

일률적 인당 상한은 모든 팀이 처음 시도하고 처음 실패하는 예산입니다. 이유는 구조적입니다: 에이전트 비용은 사람이 아니라 과제로 변동합니다. 같은 개발자도 수백 턴의 대규모 리팩터링이나 캐시 효율 나쁜 코드베이스 때문에 평소의 5배를 쓰는 주가 생깁니다. 상한이 벌하는 것은 워크로드지 사람이 아닙니다——표준적인 세 가지 붕괴 패턴이 따라옵니다:

1. 상한이 무거운 과제를 조른다——도구를 산 바로 그 이유였던 일을.
2. 가벼운 사용자는 절대 안 걸린다——평균은 무의미해지고 재무는 그 줄 전체를 못 믿게 된다.
3. 집행이 스프레드시트로 가고 몇 주 늦는다——돈은 이미 나갔고 논쟁은 이미 상했다.

인두가 아니라 워크로드에 예산을 배분하라

에이전트 비용을 실제로 결정하는 세 변수——턴 수, 재전송 컨텍스트, 캐시 적중률——를 팀 규모의 배분에 씁니다:

1. 평균이 아니라 실제 형태로 인당 월 비용을 모델링: 일일 턴 × 컨텍스트 크기 × 캐시 동작. 2주 관측 데이터가 어떤 업계 벤치마크보다 낫다.
2. 머릿수가 아니라 프로젝트·과제 유형별 배분: 정형 유지보수와 깊은 아키텍처 작업은 다른 레인으로. 분기 자체가 가장 큰 정직한 절약이다.
3. 상한은 관측 형태의 80퍼센타일에——평범한 주에 걸리는 상한은 아무도 안 지킨다.

계량이 일어나는 곳에서 집행하라

스프레드시트로 집행되는 예산은 소원이다. 요청은 어차피 어딘가에서 계량됩니다——모델, 토큰, 캐시 히트, 비용, 요청별로. 그렇다면 예산도 같은 곳에 두세요: 조용히 초과하는 대신 초과 시 제한하는 키별 쿼터, 모든 줄이 아니라 이상에만 울리는 알림, 청구서와 대사되는 조직 단위 합계. 과금하는 장치가 예산을 집행하는 장치이기도 할 때, 예산은 싸움거리가 아닙니다.

주 15분 리뷰

주 1회 세 가지 질문이 예산을 살려둡니다: 캐시 적중률 추세는 평평한가, 미끄러지는가? 어떤 키·프로젝트가 가장 많이 움직였고 워크로드가 실제로 변했는가? 정당한 이유로 상한에 닿을 사람에게 먼저 배분을 조정해줘야 하는가? 이건 회의가 아니라 세 열짜리 명세를 한 번 훑는 것——분기별 소방 훈련을 통째로 대체합니다.