AI 코딩 에이전트(AI coding agents)를 사용하는 모든 팀은 동일한 벽에 부딪힙니다. 구독 서비스는 사용량을 측정하고, 제한(cap)은 사용자(seat)당 적용되며, 소비량은 불과 3미터 거리에 앉아 있는 개발자들 사이에서도 극명하게 갈립니다. 한 명은 목요일이면 주간 할당량을 다 써버리는 반면, 다른 한 명은 제한 경고를 본 적조차 없습니다. 이 격차는 연차의 문제가 아니라 습관, 워크플로(workflow), 그리고 자동화의 차이입니다.

알려진 임시방편인 '1인당 두 번째 구독'은 대부분의 서비스 약관(terms of service)을 위반하므로, "계정을 잃는 방법" 항목에 적어두고 넘어가십시오.

흥미로운 방식은 이전에는 존재하지 않았습니다. 개발자 1이 작업을 GitHub issue로 범위를 지정했지만 이를 실행할 예산이 남아있지 않습니다. 제한에 걸린 적이 없는 개발자 2가 아무런 컨텍스트(context)나 추가 입력 없이 이를 넘겨받아, 에이전트(agent)가 작업을 완료할 때까지 남은 토큰을 소비합니다. 한 명은 생각을 제공했고, 다른 한 명은 연산(compute)을 제공했습니다. 두 번째 사람을 '토큰 기부자(Token Donor)'라고 부릅시다. 에이전트가 등장하기 전에는 아이디어에 전력을 기여할 수 있는 방법이 없었습니다.

제로 컨텍스트(Zero context)가 핵심 기능이다

기부된 실행에는 후속 채널이 없습니다. 기부자는 당신이 "불안정한 테스트(flaky test)를 수정하라"고 말했을 때 그 의도가 무엇이었는지 묻지 않을 것입니다. 에이전트는 issue에 적힌 그대로 수행하므로, issue는 반드시 정확한 내용을 담고 있어야 합니다. 낯선 사람의 에이전트가 실행할 수 있는 티켓(ticket)은 실제로 충분히 고민된 티켓입니다. 업계는 지난 30년 동안 템플릿과 준비 완료 정의(definition-of-ready) 체크리스트를 통해 그 속성을 쫓아왔지만 결코 잡지 못했습니다. 결제 제한(billing cap)이 우연히 그것을 잡아냈습니다. 우리는 좋은 티켓을 살 수 없었습니다. 대신 우연히 그것을 빌려 쓰게 된 것입니다.

뼈아픈 두 가지 반론

새벽 2시에 발생한 버그의 소유권은 누구에게 있는가? 매번 issue 작성자에게 있습니다. 기부자는 전력 공급원(power supply)이지 승인자(approver)가 아니며, 아무도 CI 러너(CI runner)를 호출(page)하지 않습니다.

이것이 게으름을 다른 사람의 예산으로 세탁하는 것인가? 아닙니다. 제로 컨텍스트 규칙은 안티-세탁(anti-laundering) 규칙입니다. 모호한 명세(spec)는 기부자의 비용을 들여 단 한 번 눈에 띄게 실패할 것이며, 그 이후에 기부자들은 사과가 아닌 명세를 수락할 것입니다. 공로(Credit)는 어떻게 인정하는가? Git은 이미 수년 전에 Co-authored-by 트레일러를 도입했습니다.

느낌이 아닌 숫자로 경로를 지정하라

단 하나의 어려운 의존성: 누가 실제로 잉여분(surplus)을 보유하고 있는지 반드시 알아야 한다는 점입니다. 자기 보고(Self-report)는 실패합니다. 가장 많이 사용하는 사용자는 예외 없이 자신이 검소하다고 확신하기 때문입니다. Claude Code는 세션 로그를 로컬에 작성하며, 해당 로그를 위한 무료 브라우저 분석기를 통해 프로젝트 및 Git 브랜치별로 지출을 세분화하여 보여줍니다. 브랜치별 수치는 논쟁을 종결시킵니다.

첫 번째 기부된 실행 (The first donated run)

가장 가치 있는 기부된 사양(spec)은 에이전트(agent) 스스로가 추가한 불필요한 요소(bloat)를 삭제하는 것입니다. 바로 아래 줄의 내용을 재진술하는 중복된 주석, 프레임워크가 작동함을 단언하는 테스트, 발생할 수 없는 조건에 대한 방어적 스캐폴딩(defensive scaffolds) 등이 이에 해당합니다. 개인별 한도(personal cap) 내에서 삭제 작업을 수행할 자금을 지원하는 사람은 아무도 없으며, 이것이 바로 이 작업이 남는 컴퓨팅 자원(spare compute)에 적합한 이유입니다.

토큰당 가격은 하락할 수 있습니다. 제가 아닌 공개된 모델 가격 기록이 이를 말해줄 것입니다. 하지만 에이전트는 세대가 거듭될수록 작업당 더 많은 토큰을 소비하므로, 결과적으로 한도는 점점 더 타이트해집니다. 토큰 효율성(Token efficiency)은 아직 인정받지 못한 기술이지만, 올바른 엔지니어링 본능입니다. 다음과 같이 정의되어야 합니다: 금요일에 토큰이 남은 개발자는 업무량이 부족한 것이 아니라, 팀이 빌려 쓸 수 있는 대역폭(bandwidth)을 보유하고 있는 것입니다.

댓글을 위한 질문입니다, 솔직하게 답해 주세요: 당신은 기부자(donor)입니까, 아니면 소모자(drain)입니까? 사양을 보지 않은 상태에서 동료의 이슈를 자신의 예산으로 실제로 실행해 보고, 그것이 성공하는 것을 지켜본 사람이 있습니까? 만약 당신의 팀이 가장 많이 사용하는 사용자를 향한 공동의 눈총 이상의 방법으로 '목요일의 문제'를 해결하고 있다면, 그 사례를 읽어보고 싶습니다.