코딩 에이전트 플랜은 보조금일 뿐이다

월별 요금은 접근 비용을 알려줄 뿐, 실제 작업에 소모되는 자원을 알려주지는 않습니다.

Nasiko에서는 모든 에이전트를 사용하는 팀이 답할 수 있어야 하는 질문을 중심으로 구축하고 있습니다. 즉, 이 작업이 무엇을 소비했고, 무엇을 달성했는가? 코딩 구독 모델은 이러한 연결 고리를 놓치기 쉽게 만듭니다. 월별 요금은 예측 가능하지만, 그 뒤에 숨겨진 작업 내용은 변할 수 있습니다.

코딩 에이전트로 버그를 수정하는 도중에 사용량 한도에 부딪힌다고 가정해 봅시다. 몇 가지 변경 사항을 적용했지만 테스트는 여전히 실패합니다. 계속하려면 리셋될 때까지 기다려야 합니다.

남아 있는 작업량이 있다는 것은 알지만, 무엇이 할당량을 소진했는지 파악하기가 더 어렵습니다. 에이전트는 코드베이스를 읽고, 테스트를 실행하고, 수정을 시도하는 데 시간을 사용했습니다. 대화는 진행됨에 따라 길어졌습니다. 세부 내역 분석 없이는 어떤 부분이 가장 많이 기여했는지 추측할 수밖에 없습니다.

월별 청구서가 도움이 되지 않습니다. 작업이 어떻게 되었든 지난달 지불한 것과 같은 금액입니다.

이러한 예측 가능성은 실험을 더 쉽게 만듭니다. 질문 하나하나에 가격을 매기지 않고 생소한 코드베이스를 탐색할 수 있습니다. 하지만 동시에 작업과 그 소비량을 분리시킵니다.

구독 모델은 특정한 규칙 하에서 접근 비용을 책정합니다. 이는 다른 청구 방식 하에서 동일한 작업이 얼마의 비용이 들지 알려주지는 않습니다.

이러한 노출도를 이해하려면, 소비량과 그 원인이 된 작업을 연결해야 합니다. 이 연결 고리는 리셋을 기다릴 때 중요하며, 워크플로우를 배포하거나 사용 범위를 확장하거나 예산을 설명해야 할 때 더욱 중요합니다.

2026년 6월, SemiAnalysis는 OpenAI와 Anthropic의 플랜 티어별 구독 모델을 구매하여 주간 한도를 소진할 때까지 장시간 코딩 작업을 실행했습니다. 그들은 $200 ChatGPT 티어에 대해 약 $14,000, $200 Claude 티어에 대해 약 $8,000의 최대 월 API 등가 사용량을 추정했습니다. 이는 SemiAnalysis의 방법론과 보고된 결과입니다.

이 수치들은 API 소매 가격으로 평가된 소비량일 뿐, 벤더 비용은 아닙니다.

SemiAnalysis는 75%의 API 총이익률(gross margin)을 가정하여 구독 총이익(subscription gross margins)을 모델링했습니다. 이들이 발표한 손익분기점 임계값은 최고 OpenAI 등급에서 약 5.7% 사용률, 최고 Anthropic 등급에서 10%였습니다. 이러한 임계값은 양사의 전체 수익성(overall profitability)이 아닌 모델링된 구독 총이익에 관한 것입니다. 보고된 마진 추정치.

산술 계산을 통해 이 임계값이 재현됩니다: 해당 가정 하에서는 API 가격 책정 소비액 14,000달러가 서비스 비용 3,500달러를 의미하며, 200달러를 3,500달러로 나눈 값은 약 5.7%입니다. Claude의 예시는 서비스 비용 2,000달러와 10% 임계값을 시사합니다.

이것들은 명시된 마진 가정 하에서의 스트레스 테스트 추정치일 뿐이며, 일반적인 고객 청구서나 보장된 할당량은 아닙니다. 이 수치들의 유용성은 구독 가격과 측정 기반 접근 방식의 경제성 사이에서 노출되는 격차입니다.

예산을 짜는 팀에게 그 격차는 조사해야 할 질문입니다. 우리 자체 워크로드는 이러한 극단값보다 훨씬 낮을 수도 있습니다. 또한 성공적인 실험이 매일 실행하는 무언가가 되면 크게 바뀔 수도 있습니다.

캐싱(Caching)이 비교에 주의가 필요한 이유를 설명합니다.

코딩 에이전트는 중복되는 컨텍스트(context): 지침, 도구 정의, 리포지토리 내용, 대화 기록을 반복적으로 전송합니다. 프롬프트 캐싱(Prompt caching)은 제공업체가 일치하는 접두사(prefixes)의 처리를 재사용할 수 있게 합니다.

Requesty가 생산 게이트웨이 트래픽에 대해 분석한 결과, 2026년 4월 Claude Code에서 입력 토큰 캐시 적중률(input-token cache hit rate)이 92%를 기록했다고 보고했습니다. 이 관찰은 Requesty의 데이터셋에 속하지만, 그 결과는 명확합니다: 해당 워크로드의 많은 입력이 재사용된 컨텍스트였기 때문에, 원시 토큰 수(raw token count)가 처리 비용을 측정하는 좋은 지표가 아닙니다. (출처: Requesty 연구)

따라서 구독 방식은 워크로드를 서비스하기에 효율적이기 때문에 관대해 보일 수 있습니다. 구독 방식 하에서는 포함된 캐시 읽기(included cache reads)가 청구서에 별도의 요금을 발생시키지 않습니다. API 가격 책정 방식 하에서는 읽기는 할인되지만 여전히 측정되며, 반면 캐시 쓰기(cache writes), 새로운 입력, 출력은 각각의 요율로 청구됩니다. (출처: Anthropic 캐싱 문서)

유용한 비교는 이러한 카테고리를 유지합니다. 모든 토큰을 캐시되지 않은 입력으로 가격 책정하면 추정치가 부풀려집니다. 모든 캐시된 토큰을 무료로 취급하는 것은 이를 과소평가합니다.

헤비 인터랙티브 사용자들은 여전히 구독 서비스에서 훌륭한 가치를 얻을 수 있습니다. 캐싱은 또한 API 워크로드를 합리적인 수준으로 유지할 수 있게 합니다. 효율성은 이전하더라도 살아남을 수 있지만, 구독 권한은 목적지의 규칙에 달려있습니다.

file-1

우리는 일반적인 엔지니어링 작업에서 이러한 경계를 마주합니다.

실험은 서비스가 됩니다. 각 실행을 감독하는 대신, 우리는 에이전트에게 큐(queue)를 처리하도록 예약합니다. 작업들은 겹치고, 재시도들이 쌓이며, 세션들은 다른 컨텍스트로 시작됩니다.

팀은 자체 도구를 표준화합니다. 그들의 엔터프라이즈 계약은 개발자들이 평가 과정에서 사용했던 개별 플랜과는 다른 허용량이나 측정 방식(metering)을 가집니다.

또는 제공업체가 액세스에 포함되는 내용을 변경합니다.

Anthropic이 제안한 Agent SDK의 청구 분할은 이러한 경계가 얼마나 불안정한 상태로 남아있는지를 보여줍니다. 이 회사는 SDK와 claude -p 사용에 대한 별도의 크레딧 체계를 발표했다가 6월 15일에 중단했습니다. 현재 공지에는 영향을 받는 사용량이 계속해서 구독 한도에서 차감되며, 발표된 별도의 크레딧은 사용할 수 없다고 명시되어 있습니다. 제안된 분할은 구현된 변경으로 간주되어서는 안 됩니다. Anthropic의 현재 공지.

GitHub가 실제로 구현된 예시를 제공합니다. 사용량 기반 AI 크레딧 청구(Usage-based AI Credits billing)가 6월 1일에 시작되었으며, 포함된 허용량과 추가 지출에 대한 통제 기능을 갖추고 있습니다. 조직들은 지출 한도를 설정할 수 있습니다. GitHub의 배포 발표.

전환 기간 동안 6월, 7월, 8월에는 Business의 경우 월 $30, Enterprise의 경우 $70의 임시 보조금이 지급되었으며, 이는 발표된 표준 보조금인 $19와 $39에 비해 높은 금액입니다. 이 프로모션 기간이 끝나면 팀들은 소비량의 변화를 플랜이 커버하는 범위의 변화와 구별할 필요가 있습니다. GitHub 청구 안내문.

우리는 구독 종료에 대한 예측을 할 필요가 없습니다. 이미 그들과 무관하게 우리의 워크로드를 이해할 수 있는 실질적인 이유를 가지고 있습니다.

조직적 영향은 인보이스(invoice)를 넘어 확장됩니다.

5월, Windows Central는 The Verge를 인용하여 Microsoft의 Experiences + Devices 부문이 6월 말까지 Claude Code에서 GitHub Copilot CLI로 이동할 것으로 예상했다고 보도했습니다. 이 보고서는 재정적 고려 사항과 함께 내부 저장소 주변으로 자체 도구를 형성하려는 Microsoft의 관심사, 보안 요구 사항 및 워크플로우를 설명했습니다. Windows Central의 보고서.

이 예시는 개발자의 선호도가 예산, 통합, 거버넌스(governance)와 함께 도구 선택에 놓여 있음을 보여줍니다. 하지만 같은 문제는 훨씬 작은 팀에서도 나타납니다.

자동화된 풀 리퀘스트 검토를 도입하는 팀을 상상해 보세요. 지출이 증가합니다. 팀장은 개발자별 사용량을 볼 수 있지만, 그 증가가 더 광범위한 검토 범위에서 왔는지, 동일한 실패 작업에 대한 반복적인 시도에서 온 것인지, 아니면 모든 요청에 포함된 더 긴 컨텍스트(context) 때문인지를 알 수 없습니다.

일괄적인 상한선은 총량을 통제할 수는 있지만, 이러한 질문들에 대한 답을 남겨둡니다. 유용한 검토를 중단시키고 낭비되는 검토는 보존할 수도 있습니다. 예산을 변경하기 전에, 팀은 추가 소비가 무엇을 달성했는지 식별해야 합니다.

이는 귀속(attribution) 문제를 재정적 관심사만큼이나 엔지니어링적 관심사로 만듭니다.
계정, 프로젝트, 키, 그리고 때로는 사용자 또는 모델별 지출을 확인할 수 있는 청구 내보내기(billing export)가 있습니다. 이러한 차원들은 비용 할당에 도움이 됩니다. 이를 설명하기 위해서는 실행 컨텍스트가 필요합니다.

공유 키는 마이그레이션 어시스턴트(migration assistant), 인시던트 조사(incident investigation), 그리고 야간 검토 작업(nightly review job)에 사용될 수 있습니다. 개인 키는 여러 리포지토리(repositories)에 걸쳐 있을 수 있습니다. 하나의 세션은 생산적인 작업 후에 길고 성공하지 못한 우회 경로를 포함할 수도 있습니다.

우리가 비용을 지불하는 단위와 우리가 결정을 내리는 단위는 다릅니다. 제공업체(Providers)는 요청과 토큰(tokens)을 측정합니다. 엔지니어링 팀은 마이그레이션, 조사, 또는 검토가 할 가치가 있었는지 결정합니다.

재시도 루프(retry loop)를 고려해 봅시다. 제공업체는 각 시도에 대해 소비된 토큰을 정확하게 보고할 수 있습니다. 실행 컨텍스트(Execution context)는 그 시도들이 동일한 미해결 작업(unresolved task)에 속했음을 보여줍니다. 작업 식별자(task identifier), 연결된 요청, 그리고 완료 상태를 통해 우리는 비용이 많이 든 성공과 비용이 많이 든 실패를 구별할 수 있습니다.

툴 호출(Tool calls) 역시 비슷한 주의가 필요합니다. 로컬 테스트 명령어는 모델 자체에 비용을 발생시키지 않을 수 있지만, 그 출력이 다음 모델 요청의 비용을 증가시킵니다. 이 기록은 모든 툴 호출이 독립적으로 측정 가능한 토큰 청구서를 갖는다고 가정하지 않으면서도 비용을 설명하는 데 도움이 됩니다.

file-kv

기존의 원격 측정(telemetry) 시스템은 이러한 증거 중 일부를 제공합니다. Claude Code는 사용량, 비용, 툴 활동, 그리고 세션에 대한 OpenTelemetry 내보내기(exports)를 지원합니다. 필요한 작업은 이를 일관되게 수집하고 우리 조직이 이해하는 리포지토리, 작업, 소유자, 결과와 연결하는 것입니다. Claude Code 모니터링 문서.

이를 통해 우리는 의사 결정권자들과 더 생산적인 대화를 나눌 수 있습니다. 어떤 워크플로우가 더 많은 비용을 소비했는지, 성공적으로 완료되었는지, 그리고 사람들이 여전히 개입해야 했던 부분이 어디인지를 보여줄 수 있습니다. 무거운 사용량을 낮은 판단력의 증거로 취급하지 않으면서 반복되는 실패를 조사할 수 있습니다.

토큰 카운트만으로는 가치를 판단할 수 없습니다. 프로덕션(production)에서 발생하는 사고를 해결하는 값비싼 세션은 변경 사항이 폐기되는 수십 개의 저렴한 세션보다 훨씬 더 가치가 있을 수 있습니다. 측정은 그 트레이드오프(tradeoff)를 눈에 보이게 만듭니다. 하지만 판단을 대신 내려주지는 않습니다.

이번 주에 시작할 수 있는 세 가지 구체적인 단계가 있습니다.

1. 지난주 사용량을 공개된 API 요율로 책정해 봅니다. 사용 가능한 이용 기록을 내보냅니다(Export). 모델별로 캐시되지 않은 입력(uncached input), 캐시 쓰기(cache writes), 캐시 읽기(cache reads), 출력을 분리한 다음, 해당되는 요율을 적용합니다. 그 결과를 “API 등가 추정치(API-equivalent estimate)”로 표시하고 실제 구독 결제액과 함께 보관합니다. 기록이 불완전하다면, 누락된 부분을 파악하여 지금 바로 수집하기 시작해야 합니다.

2. 소비량을 세션 및 작업에 연결합니다. 세션 및 요청 식별자(identifier), 저장소(repository), 작업(task), 모델, 토큰 카테고리, 재시도 횟수(retries), 도구 이벤트(tool events)를 기록합니다. 에이전트가 작업을 위임할 때 부모-자식 관계(parent-child relationships)를 보존합니다. 하나의 워크플로우(workflow)로 시작하여 비용이 많이 드는 실행이 엔지니어가 인식할 수 있는 무언가와 추적될 수 있는지 확인합니다. 예산 결정을 위해 사용하기 전에 기록을 제공업체 총계(provider totals)와 조정합니다(Reconcile).

3. 현재 플랜에서 벗어나는 경로에 가격을 책정합니다. 의도된 배포 환경에서 어떤 워크플로우가 API 청구(API billing)를 필요로 할지 파악합니다. 관찰된 캐시 동작, 예상 볼륨, 동시성(concurrency), 재시도 횟수를 사용하여 비용을 추정합니다. 이 추정치를 승인된 변경 사항이나 해결된 사고와 같은 결과 측정 지표(outcome measure)와 짝짓습니다. 이렇게 하면 청구 방식이 변경될 때 무엇에 자금을 지원할 가치가 있는지 결정하는 근거를 얻게 됩니다.

Nasiko는 에이전트 실행 및 소비량을 동일한 뷰로 가져와 팀들이 자신들의 지출 뒤에 있는 실행 과정을 조사할 수 있도록 구축되었습니다. 당사의 오픈 소스 플랫폼은 실행 추적(execution traces)을 기록하고 원격 측정(telemetry)으로부터 토큰 사용량과 비용을 수집하며, 지원되는 코딩 에이전트에 대한 세션 보고 기능을 제공합니다. Nasiko 저장소에는 원격 측정 설정과 필수 전제 조건만 갖춰지면 몇 분 만에 플랫폼을 실행할 수 있는 Docker 퀵스타트가 포함되어 있습니다.

세션이 리셋 창에서 멈추더라도 다음번에는 기다리기로 선택할 수 있습니다. 구독은 우리가 작업하는 방식에 있어 여전히 최선의 거래일 수 있습니다.

하지만 중단되기 전에 무슨 일이 일어났는지 설명할 수 있어야 합니다. 어떤 작업이 할당량을 소모했는지, 그것이 무엇을 달성했는지, 그리고 비교 가능한 측정 실행 비용이 얼마였는지를 말입니다.

구독의 한도, 적격성 및 향후 약관은 제공업체가 결정합니다.

우리가 수행한 작업에 대한 기록은 우리 것이어야 합니다.