한 달에 $514. 50세션. 375개의 루프. 이 숫자들은 추정치가 아니다. dev.to에 올라온 실측 데이터다. Claude Code를 진지하게 쓰는 팀이라면 이 숫자 앞에서 한 번은 멈춰야 한다. 비용이 무섭다는 얘기가 아니다. 이 숫자가 나오기까지 얼마나 오래 '블랙박스' 안에서 일했는지가 문제다.
루프가 조용히 비용을 태운다
$514 중 가장 비싼 단일 세션은 $32.94였다. Claude가 리팩토링 작업을 몇 시간째 혼자 돌리는 동안 아무도 보지 않았다. 31개의 루프가 발생했고, 효율 점수는 100점 만점에 35점이었다. 패턴은 단순했다: Read → Edit → Edit → Edit → Read → Edit. Claude가 뭔가를 시도하고, 안 되면 조금 다르게 시도하고, 또 반복한다. 컨텍스트 윈도우가 95%에 도달하면 출력 품질이 떨어지기 시작하는데, 당시엔 그 경고조차 없었다.
루프는 Claude Code를 쓰는 팀 대부분이 인식하지 못하는 '조용한 비용 킬러'다. 작업이 진행되는 것처럼 보이지만 실제로는 같은 자리를 맴돈다. claudestat 같은 모니터링 도구가 주는 핵심 가치는 이 루프를 가시화하는 것이다. 같은 툴이 3회 이상 연속 호출되거나, 컨텍스트가 올라가는데 출력이 정체되거나, Claude가 "Let me try..."를 반복한다면 이미 루프에 들어간 것이다. /compact를 일찍 치는 습관 하나가 세션 비용을 절반으로 줄일 수 있다.
MCP vs CLI: 17배 토큰 차이의 구조적 이유
루프보다 더 근본적인 비용 문제가 있다. 같은 구글 검색을 SerpApi MCP 서버와 CLI로 각각 실행했을 때, MCP는 기본 모드에서 6,047토큰을 반환했고 CLI는 351토큰이었다. 17배 차이. 이 수치는 dev.to의 실측 벤치마크에서 나온 것으로, 단순 비교가 아니라 동일 쿼리·동일 라이브러리·동일 머신 조건이었다.
차이의 원인은 크게 세 가지다. 첫째, MCP는 에이전트 루프의 매 턴마다 툴 스키마(771토큰)를 컨텍스트에 주입한다. CLI는 PATH에 있는 바이너리이므로 대기 비용이 0이다. 둘째, MCP의 기본 응답 포맷은 indent=2로 프리티프린트된 JSON이고, CLI는 필요한 필드만 골라 미니파이한다. --fields title,link 옵션 하나로 6,000토큰짜리 응답이 351토큰이 된다. 셋째, MCP 서버를 10개 붙이면 대기 비용이 10배로 쌓인다. 에이전트가 아직 아무 작업도 하기 전에 수천 토큰이 컨텍스트를 채운다.
이 비교는 'MCP가 나쁘다'는 주장이 아니다. OAuth·멀티유저 인증·서버사이드 레이트리밋·세션 상태 유지가 필요하다면 MCP가 맞는 선택이다. 핵심은 트랜스포트를 호출 특성에 맞게 선택해야 한다는 것이다. 상태 없는 단순 쿼리라면 CLI가 토큰 예산 측면에서 압도적으로 유리하다. Anthropic 자체 벤치마크에서도 툴 정의를 코드로 호출하는 방식이 MCP 대비 토큰을 98.7% 절감했다는 데이터가 있다. 큰 숫자지만 방향은 같다.
Hooks·Skills·Subagents: 프리미티브를 잘못 고르면 비용이 된다
토큰 비용을 구조적으로 통제하려면 Claude Code의 확장 프리미티브 선택이 중요하다. Hooks, Skills, Subagents는 각각 다른 트레이드오프를 가진다.
Hooks는 툴 호출 전후에 결정론적 코드를 실행한다. 입력 검증, 정책 체크, 로깅이 목적이라면 Hooks가 가장 정확하다. 단, PreToolUse 훅은 툴 호출당 약 12ms의 오버헤드를 추가한다. 고빈도 파이프라인에서는 이게 누적된다. 반대로 보안·컴플라이언스 경로처럼 결정론적 보장이 필수인 경우엔 오버헤드를 감수할 가치가 있다. 테스트 측면에서도 유리하다—훅의 반환값이 툴 실행 여부를 100% 결정하므로 유닛테스트에서 외부 서비스 없이 동작을 검증할 수 있다.
Skills는 재사용 가능한 인스트럭션 번들이다. 프롬프트에 같은 절차를 반복해서 쓰는 대신 스킬로 패키징하면 프롬프트 토큰을 최대 30%까지 줄일 수 있다. MCP vs CLI 비교에서 언급된 searching-with-serpapi 스킬이 좋은 예다. 110토큰짜리 스킬이 트리거될 때만 로드되고, 에이전트가 어떤 엔진을 쓸지·언제 검색을 아예 하지 말아야 하는지까지 담고 있다. 캐퍼빌리티는 CLI나 MCP가 주고, 절차는 스킬이 담는 구조다.
Subagents는 독립적으로 병렬 실행이 가능한 작업 단위다. 컨텍스트 공유가 필요 없는 작업들을 분산시켜 전체 처리 시간을 줄이는 데 유효하다. 다만 오케스트레이션 복잡도와 디버깅 비용이 올라간다. 잘못 쪼개면 각 서브에이전트가 독립적으로 컨텍스트를 채워 오히려 전체 토큰 비용이 늘어난다.
측정이 먼저, 설계가 그 다음이다
세 기사를 관통하는 메시지는 하나다: 보이지 않으면 통제할 수 없다. $514는 그 자체로 큰 숫자가 아닐 수 있다. 하지만 63%가 사이드 프로젝트 하나에서 나왔고, 그 사실을 추적 없이는 알 수 없었다는 게 핵심이다. MCP 17배 토큰 차이도, 프리미티브 선택도—측정 기반이 없으면 '왜 이렇게 비싸지?'라는 질문조차 못 던진다.
AI-First 팀이 Claude Code를 운영할 때 필요한 설계 기준은 세 레이어로 정리된다. 모니터링 레이어: 세션 단위 토큰·루프·효율 점수를 실시간으로 추적한다. 루프 감지와 컨텍스트 임계값 알림은 기본이다. 트랜스포트 레이어: MCP와 CLI를 호출 특성에 따라 구분해 배치한다. 상태 없는 단순 호출은 CLI, 거버넌스가 필요한 연결은 MCP. 프리미티브 레이어: 결정론이 필요하면 Hooks, 재사용 절차라면 Skills, 병렬 분산이 필요하면 Subagents. 각 레이어의 선택이 토큰 비용에 직접 연결된다.
다음 단계는 팀 표준화다
개인이 claudestat으로 자기 비용을 추적하는 것과, 팀 전체가 동일한 기준으로 Claude Code를 운영하는 것은 다른 문제다. 개인 수준의 측정은 이미 방법이 있다. 이제 팀 수준의 과제가 남는다. 어떤 프로젝트가 토큰을 지나치게 소모하는지, 어떤 팀원의 세션이 루프 빈도가 높은지, MCP 서버 구성이 팀 전체 컨텍스트 예산에 어떤 영향을 주는지—이 질문들에 답하는 구조를 팀 차원에서 설계해야 한다. 토큰 비용 거버넌스는 더 이상 인프라 팀의 일이 아니다. 코드를 짜는 모든 사람의 설계 기준이 됐다.