바이브 코딩은 손이 덜 가는 대신 토큰이 듭니다. 문제는 그 토큰이 어디서 얼마나 나가는지 감이 잘 안 온다는 점입니다.
팀에 도입을 검토할 때 가장 먼저 나오는 질문도 이겁니다. "한 사람당 한 달에 얼마나 들어요?"
Anthropic은 Claude Code 문서에 이 질문에 대한 숫자를 적어 두었습니다. 그 숫자에서 출발해, 비용이 어디서 불어나는지 따라가 봤습니다.
먼저, 평균값
문서의 숫자는 엔터프라이즈 배포 전체의 평균입니다.
- 활성일(실제로 쓴 날) 기준 개발자 1인당 약 13달러
- 월 기준 1인당 150~250달러
- 사용자의 **90%**는 활성일당 30달러 미만
숫자 바로 뒤에 조건이 붙습니다. 1인당 비용은 모델 선택, 코드베이스 크기, 여러 인스턴스를 동시에 돌리거나 자동화에 쓰는 사용 패턴에 따라 크게 달라진다고 합니다. 그래서 작은 파일럿 그룹으로 시작해 기준선을 잡은 뒤 넓히라고 권합니다.
평균은 출발점일 뿐입니다. 우리 팀의 숫자는 직접 재야 나옵니다.
한 줄 질문이 비싼 이유
문서에서 가장 실무적인 부분은 '긴 세션에서 사용량이 오르는 이유'입니다.
Claude Code는 요청할 때마다 대화 전체를 보냅니다. 도구를 쓸 때마다 그 결과를 실은 요청이 하나 더 나갑니다. 프롬프트 캐싱 덕분에 지난 기록은 캐시 요금으로 다시 읽히지만, 그래도 하루 종일 열어 둔 세션에서 던진 한 줄짜리 질문은 대화 전체만큼의 사용량을 끌고 갑니다.
문서가 꼽는 다른 원인들도 같은 구조입니다.
- 캐시 미스: 캐시 수명보다 길게 쉬었다가 보낸 첫 메시지는 캐시를 놓치고 전체 컨텍스트를 다시 처리합니다.
- 예약 작업: 세션 범위의 반복 작업은 세션이 놀고 있어도 주기마다 전체 컨텍스트를 보냅니다.
- 하위 에이전트와 에이전트 팀: 하위 에이전트는 각자 요청을 보냅니다. 에이전트 팀은 팀원이 플랜 모드로 돌 때 일반 세션보다 약 7배 많은 토큰을 쓴다고 적혀 있습니다.
- 압축:
/compact는 요약할 대화 전체를 읽으니 그 자체로 큰 요청입니다. 이어 갈 필요가 없다면/clear는 비용이 들지 않는다고 합니다.
줄이는 법은 대부분 '덜 싣기'
절약법도 원인과 짝을 이룹니다. 결국 요청마다 싣는 양을 줄이는 이야기입니다.
작업이 바뀌면 /clear. 상관없는 일로 넘어갈 때 지난 컨텍스트는 매 메시지마다 토큰을 낭비합니다. 나중에 돌아올 세션이라면 /rename으로 이름을 붙여 두고 /resume으로 돌아오면 됩니다.
모델을 일에 맞추기. 문서는 대부분의 코딩 작업은 Sonnet이 잘하고 Opus보다 싸다고 말합니다. Opus는 복잡한 설계 판단이나 여러 단계의 추론에 남겨 두라고 합니다.
Claude가 읽기 전에 거르기. 1만 줄짜리 로그를 통째로 읽게 하는 대신, 훅이 ERROR가 든 줄만 골라 넘기면 수만 토큰이 수백 토큰으로 줄어든다는 예가 있습니다. 테스트 출력에서 실패한 부분만 남기는 훅 예시도 실려 있습니다.
CLAUDE.md를 가볍게. 이 파일은 세션이 시작될 때마다 컨텍스트에 실립니다. PR 리뷰나 DB 마이그레이션처럼 특정 작업용 지침은 필요할 때만 불러오는 스킬로 옮기고, CLAUDE.md는 200줄 아래로 유지하라고 권합니다.
구체적으로 묻기. "이 코드베이스를 개선해 줘"는 넓은 탐색을 부릅니다. "auth.ts의 login 함수에 입력 검증을 추가해 줘"는 적은 파일 읽기로 끝납니다.
팀 단위로는 한도를 먼저
팀이라면 개인의 습관보다 한도 설정이 먼저입니다. 문서는 Claude Console(API)로 쓰는 조직을 위해 팀 규모별 사용자당 권장값을 표로 줍니다.
문서의 예시로는 200명이면 1인당 20k TPM, 모두 합쳐 400만 TPM을 요청할 수 있습니다. 이 한도는 사람마다가 아니라 조직 단위로 걸리기 때문에, 다른 사람이 쉬는 동안에는 한 사람이 자기 몫보다 많이 쓸 수 있다고 합니다. 대규모 교육처럼 동시에 몰리는 날에는 더 높은 값이 필요할 수 있다는 단서도 붙어 있습니다.
Console로 처음 인증하면 'Claude Code'라는 워크스페이스가 자동으로 생기고, 여기서 지출 한도를 걸 수 있습니다. 조직 전체의 API 레이트 리밋을 공유하니, 다른 운영 워크로드를 지키려면 이 워크스페이스에 따로 레이트 리밋을 거는 방법도 안내되어 있습니다.
청구서가 이상할 때
문서는 예상보다 비용이 높게 나온 경우 대개 두 가지로 거슬러 올라간다고 말합니다. 한 번도 정리하지 않은 긴 세션, 그리고 기본 모델로 남겨 둔 Opus입니다.
그래서 팀에 가장 먼저 알릴 습관도 두 가지입니다. 관계없는 작업 사이에서 지우기, 일에 맞는 모델 고르기. 바이브 코딩에서 '감'에 맡겨도 되는 건 코드의 세부 사항이지, 청구서는 아닙니다.
숫자를 실제로 모으는 방법, 그러니까 개발자별 토큰과 비용을 우리 모니터링 시스템으로 끌어오는 이야기는 다음 5편에서 이어 갑니다.
