1인 개발자로서 Claude Code로 약 10개의 프로젝트를 진행하고 있습니다. 저는 모든 프로젝트의 작업 대기열(task queue)을 확인하며 밤새 unattended(무인) 작업을 수행하는 자율 에이전트 루프(autonomous agent loop)를 구축했습니다. 처음 이틀 밤은 아주 잘 진행되었습니다. 하지만 세 번째 밤, 결제 주간이 4일이나 남았음에도 Claude Code가 모든 질문에 하드 리밋(hard limit) 메시지로 응답했습니다. 작업을 계속하기 위해 정가로 긴급 토큰(emergency tokens)을 구매했습니다. 주의를 기울였음에도 불구하고, 4일 동안 실제 비용이 발생했습니다. 이 사건이 저로 하여금 추측하는 대신 실제로 사용량 측정기(usage meter)를 구축하게 만들었습니다.

네 번의 시도는 다음과 같은 순서로 진행되었습니다: 첫째, 로컬 로그에서 추정한 1달러 한도에 대해 총 1달러를 사용하도록 설정했습니다. 하지만 구독 플랜은 달러 단위로 측정되는 것이 아니라, 주간 허용량의 백분율(percent)로만 측정된다는 사실을 알게 되었습니다. 제가 비교 대상으로 삼았던 한도는 제 추측 외에는 어디에도 존재하지 않았습니다. 둘째, Anthropic의 자체 사용량 엔드포인트(usage endpoint)에서 가져온 실제 백분율을 사용했습니다. 하지만 이것만으로는 쓸모가 없었습니다. 첫째 날의 12%와 여섯째 날의 12%는 서로 다른 의미를 갖는데, 리셋 일정(reset schedule)을 모르면 이를 구분할 방법이 없었기 때문입니다. 셋째, 대신 '예측' 수치를 도입했습니다: 현재 속도로 며칠이나 더 지속될지, 그리고 언제 리셋되는지를 나타내는 수치입니다. 여기서 두 가지 문서화된 사실이 매우 중요하게 작용했습니다: 리셋은 rolling window(이동 창) 방식이 아니라 고정된 주간 시계(fixed weekly clock) 방식이라는 점(API 필드 이름인 seven_day는 그렇지 않은 것처럼 보여 오해를 불러일으킵니다), 그리고 사용하지 않은 허용량은 이월되지 않는다는 점입니다. 따라서 일주일 내내 예산 미만으로 사용한다면 그것은 사용하지 못한 지불된 돈이 됩니다. 수학적 댐핑(damping)이 필요했는데, 그렇지 않으면 바쁜 월요일의 수치가 주간 사용량의 140%로 투영될 수 있기 때문입니다. 저는 임의의 계수 대신 Gamma-Poisson 모델을 사용하여 이를 적절히 처리했습니다. 그 후 사이클-일(cycle-day)과 사용량 수준(usage-level)의 모든 조합, 즉 133가지 케이스를 로직에 통과시켰고, 일반적인 주간 사용 시에는 절대 나타나지 않았을 두 개의 실제 버그를 발견했습니다. 하루 뒤, 기초 데이터가 오래되었거나 완전히 누락되었을 때 어떤 일이 발생하는지 확인하는 두 번째 검토를 수행했고, 동일한 계열의 버그 4개를 더 발견했습니다. 모두 같은 문제였습니다: 측정기가 모른다고 인정하는 대신 계속해서 안심시키는 수치(comforting number)를 계산하고 있었습니다.

각 단계별 실제 터미널 출력 결과가 포함된 전체 글(Full write-up)은 다음에서 확인하실 수 있습니다: https://martin-schenk.es/blog/the-number-that-lied/ /u/ma8nk 님이 제출함 [link] [comments]