Claude Code 작업 하나는 실제로 얼마인가

월간은 작업을 가린다

월간 평균은 정직한 회계이고 쓸모없는 핸들입니다. 같은 개발자의 같은 달 안에서도 작업 단위 비용은 사람 단위 차이보다 훨씬 크게 움직입니다——노력이 아니라 형태가 다르면 한 자릿수가 차이납니다. 세 가지 형태가 에이전트 일의 거의 전부를 덮습니다:

1. 외과적 버그 수정. 턴 수 적고 컨텍스트 조밀하고 파일은 이미 읽힘——캐시가 일의 대부분을 한다. 가장 싼 형태이자 에이전트를 '무료처럼 느끼게' 하는 것.
2. 스캐폴딩/신기능. 턴 수는 많지만 컨텍스트가 예측 가능하게 자라고 안정 접두사(지시·규약·기존 파일)가 잘 캐시된다. 중간 비용, 매우 예측 가능.
3. 깊은 리팩터링/마라톤 세션. 수백 턴, 컨텍스트가 턴마다 눈덩이처럼 붙고, 캐시 적중률이 모델 정가보다 청구액을 좌우한다. 예산이 죽는 곳.

컨텍스트 눈덩이

세 번째 형태를 비싸게 만드는 메커니즘: 에이전트는 통신상 무상태입니다. 15번째 턴은 지금까지의 대화를 통째로 재전송합니다——시스템 프롬프트, 읽은 파일, 도구 결과까지. 각 턴의 입력은 이력과 함께 자라므로 토큰 단가가 고정이어도 긴 세션의 턴당 비용은 오릅니다. 경계 있는 작업으로 자르면 컨텍스트는 각자 한 번만 지불하고, 무한히 이어지는 한 세션은 전부를 몇 번이고 지불합니다. 세션 형태 자체가 비용 결정입니다.

같은 작업인데 청구가 다른 이유

두 사람이 같은 리팩터링을 돌려도 청구는 크게 다릅니다. 영향 순 용의자: 캐시 동작(안정 접두사의 값싼 재읽기 vs 휘발성 접두사의 반복 차가운 결제), 세션 규율(경계 있는 새 세션 vs 구르는 메가 세션), 모델 라우팅(모든 단계에 기함 vs 어려운 곳만 기함). 이것들은 정가에 쓰이지 않고 요청별 명세에만 나타납니다——'왜 비쌌는지'를 재판할 수 있는 유일한 장소입니다.

작업 단위로 계량하고, 작업 단위로 결정하라

게이트웨이가 요청 라벨링이나 프로젝트별 키를 허용하면 작업이 비용 단위가 됩니다: 이 리팩터링은 이만큼, 이 수정 레인은 주 이만큼. 이 정도 분해능이 바로 지난 글의 월간 예산을 지탱합니다——마법의 평균을 다투는 게 아니라 작업별 장부를 읽는 것. 라벨링이 없다면 세션 분할+프로젝트별 키가 실용적 대안입니다.