$20짜리 구독이 월 $1,400 청구서로 돌아왔다. Hacker News에 올라온 한 개발자의 고백이다. 5명짜리 팀은 6주 만에 Cursor 단독으로 $4,600을 태웠다. Max 5× 플랜 구독자는 한 시간 만에 월 할당량 전체를 소진했다. dev.to에 올라온 'The Receipt Trail' 기사가 정리한 숫자들이다. 이게 예외적 사례였다면 그냥 넘어갔을 것이다. 문제는 이게 구조적으로 설계된 결과라는 점이다.
숨겨진 세 겹의 과금 구조
Cursor와 Windsurf의 비용 폭탄에는 세 겹의 레이어가 있다. 첫 번째는 토크나이저 인플레이션이다. Claude Opus 4.7의 신규 토크나이저는 2K 이상 프롬프트에서 토큰 수를 32~47% 더 많이 계산한다. 가격표는 그대로인데 실제 과금은 최대 47% 올라간 것이다. OpenRouter와 Finout의 실측 데이터가 이를 검증했다. Anthropic은 "가격 변동 없음"을 공식 입장으로 유지하고 있다.
두 번째는 에이전트 모드의 배율 효과다. Cursor의 'Max Mode'나 Windsurf의 'Cascade'처럼 멀티스텝 에이전트가 실행되면, 사용자가 명령 하나를 입력할 때 내부적으로 12번 안팎의 API 호출이 발생한다. 토크나이저 인플레이션이 이 12번 각각에 복리로 적용된다. 할당량이 순식간에 증발하는 이유다.
세 번째는 쿼터 설계 자체의 불투명성이다. Windsurf는 2026년 3월 이후 주간 쿼터 시스템으로 전환하면서 복잡한 일별·주별 리셋 정책을 도입했다. 한 세션에서 주간 할당량의 50%가 소진되고, 이후 추가 크레딧 구매를 유도하는 구조다. 더 심각한 건 Windsurf의 코어 팀 전체가 Google DeepMind로 이직했다는 사실이다. 지금 당신이 구독하는 Windsurf는 Cognition이 인수한 좀비 제품이다.
Claude Code도 예외는 아니다—단, 대응 도구가 있다
Claude Code도 쿼터 관리가 쉽지 않다. Pro 플랜은 5시간마다 쿼터가 리셋되고, Max 5/Max 20 플랜은 사이클 기반으로 운영되는데, 실시간 사용량 확인 화면이 기본 제공되지 않는다. 크리티컬한 작업 중간에 쿼터가 터지는 경험은 Claude Code 사용자라면 한 번씩 겪어봤을 것이다.
dev.to에서 소개된 오픈소스 툴 claudestat은 이 문제에 직접적인 해법을 제시한다. npm install -g @statforge/claudestat으로 설치하면 실시간 토큰 번레이트, 도구별 비용 분해, 쿼터 70/85/95% 알림, 그리고 임계치 도달 시 새 세션을 자동 차단하는 킬스위치까지 제공한다. 30일 분석을 돌리면 Bash 호출이 전체 비용의 35~45%를 차지하는 패턴이 대부분의 프로젝트에서 나온다. 셸 명령어를 배치 처리하는 것만으로 비용을 즉각 줄일 수 있다는 뜻이다. 모든 데이터가 로컬에만 저장된다는 점도 팀 도입 결정에 걸림돌을 줄여준다.
하루 만에 끝난 Java 8→25 업그레이드가 보여준 것
반대쪽 끝에 있는 사례도 살펴볼 필요가 있다. 브런치에 올라온 Claude Opus 4.7 위임형 워크플로우 실전기가 그것이다. Java 8에서 25로, AWS SDK v1에서 v2로, JWT·JSON·로깅 라이브러리까지 메이저 업그레이드를 포함한 작업을 하루 만에 완주했다. 수만 SLOC, 의존성 60개 안팎, 운영 중인 Lambda 함수군이 대상이었다. 기존 예상 공수는 최소 몇 주였다.
핵심은 두 가지였다. 첫째, 'Phase 분리'다. 변경을 Java 8 런타임에서 동작하는 라이브러리 교체(Phase A), 런타임 전환(Phase B), 불필요 의존성 정리(Phase C)로 나눠 각 Phase를 독립적으로 롤백 가능한 단위로 설계했다. 회귀가 발생했을 때 원인 범위를 즉시 좁힐 수 있는 구조를 선제적으로 깔았다.
둘째, 'Acceptance Criteria 선명화'다. Claude Opus 4.7의 공식 문서 표현대로 "한 줄씩 가이드하는 페어 프로그래머가 아니라 일을 맡길 수 있는 엔지니어"로 다루기 위해, 첫 턴에 Goal/Constraints/Done 정의를 명문화해서 건넸다. Done 정의에 "CloudWatch에 예상 외 WARN/ERROR 없음"을 포함시켰더니, Claude가 개입 없이 스스로 aws logs filter-log-events를 실행해 SLF4J NOP 폴백 경고를 보고했다. 사람이 "로그 확인해줘"라고 개입하지 않아도.
이 사례에서 비용 관점으로 중요한 것은 따로 있다. 위임이 잘 작동하려면 환경 설계가 먼저다. CLI 직접 실행 권한, Phase 단위 롤백 기준점, 검증 자동화 파이프라인—이 인프라가 없으면 Claude가 수정안을 내놓고 사람이 손으로 실행하고 로그를 복붙으로 돌려보내는 왕복 루프가 계속된다. 그 왕복 루프 자체가 토큰을 태운다.
팀 리드가 설계해야 할 비용 거버넌스 3층
세 가지 사례를 합치면 구조가 보인다. AI 코딩 도구의 비용 거버넌스는 세 층위로 설계해야 한다.
1층: 과금 구조 감사. 도구를 도입하기 전에 에이전트 모드 활성화 시 실제 API 호출 횟수를 측정하라. 마케팅 페이지의 '무제한'이나 월정액 숫자를 그대로 믿지 마라. 특히 멀티스텝 에이전트 기능은 반드시 소규모 파일럿으로 실측치를 뽑아야 한다.
2층: 실시간 모니터링 강제화. claudestat처럼 번레이트와 도구별 비용을 실시간으로 추적하는 레이어를 팀 표준으로 설정하라. 개인 개발자 수준의 킬스위치를 팀 레벨로 올리면, 특정 팀원이 에이전트 모드를 무제한으로 돌려 팀 예산을 소진하는 사고를 예방할 수 있다.
3층: 위임 워크플로우 설계. AI에 일을 맡기는 방식 자체가 비용 효율에 직결된다. Goal/Constraints/Acceptance Criteria를 선명하게 정의하고, Phase 단위로 롤백 가능한 환경을 준비하면, 같은 작업에서 소비되는 토큰이 눈에 띄게 줄어든다. 막연한 프롬프트로 에이전트가 헤매는 루프 자체가 비용이다.
전망: '무제한' 시대는 끝났다
Cursor와 Windsurf가 'unlimited'에서 메터링 빌링으로 전환한 것은 개별 기업의 정책 변경이 아니다. 보조금으로 구축한 사용자 의존성을 수익화하는 단계로의 업계 전환이다. Claude Code도, 다음에 등장할 에이전트 도구도 같은 경로를 밟을 가능성이 높다.
팀 리드 입장에서 지금 해야 할 일은 하나다. 도구 도입 결정과 동시에, 혹은 그 이전에, 비용 거버넌스를 설계하는 것. 청구서가 먼저 오면 늦다. AI 도구의 ROI는 기능 스펙이 아니라 비용 구조를 얼마나 정확하게 파악하고 설계했느냐에서 갈린다.