Claude Code 비용 절감법, 에이전트 작업도 운영이다

같은 수정도 세션 운영에 따라 가격이 달라진다

Anthropic은 Claude Code 세션의 토큰 가치를 높이는 방법을 공개했다. 글의 TL;DR은 실용적이다. 작업 사이에는 /clear를 쓰고, 시작 전에 모델과 effort level을 정하고, 파일명만 쓰지 말고 @로 파일을 첨부하고, noisy command에는 quiet flag를 붙이거나 subagent로 보내고, 새 세션에서 /context를 확인하고, 자리를 비우기 전에는 /compact를 하라는 것이다.

이 글이 중요한 이유는 비용 절약 팁 이상이기 때문이다. 코딩 에이전트는 편집기 플러그인이 아니라 긴 컨텍스트, 도구 출력, prompt cache, 모델 전환, 병렬 세션을 가진 운영 시스템이다. 같은 failing test를 고쳐도 한 세션은 필요한 테스트와 파일만 읽고 끝난다. 다른 세션은 repo 전체를 검색하고, 로그를 길게 읽고, 오전부터 쌓인 파일 내용을 매 턴 다시 보낸다. 결과는 같아도 토큰 사용량과 지연시간은 달라진다.

Databricks, AI 코딩 비용을 운영 지표로 만들다와 Rippling AI 비용 콘솔, 토큰맥싱의 청구서가 말한 비용 관리가 개인 개발자 세션 안으로 내려온 셈이다. Claude Code 자동모드 기본값, 권한 피로의 전환점처럼 권한 운영도 같은 맥락이다.

토큰 가격은 모델, 방향, 캐시에 의해 정해진다

Anthropic은 토큰 가격을 inference 비용으로 설명한다. 어떤 모델을 쓰는지, input token인지 output token인지, 캐시에서 읽히는지에 따라 비용이 달라진다. 출력 토큰은 decode 단계에서 한 토큰씩 생성되므로 일반적으로 입력보다 비싸고, thinking token도 여기에 포함된다. effort level은 모델이 얼마나 많은 thinking token을 쓰는지 좌우한다.

Prompt caching은 핵심이다. 서버가 이전 요청과 같은 prefix를 보면 그 상태를 재사용해 input token을 훨씬 싸게 읽을 수 있다. Claude Code는 이를 자동 관리하지만 사용자가 깨뜨릴 수 있다. 중간에 /model이나 /effort를 바꾸면 캐시 key가 달라져 전체 대화가 다시 prefill될 수 있다. /compact는 대화를 요약해 줄이지만 대화 자체를 다시 쓰므로 캐시는 달라진다. 글은 prompt cache가 구독에서는 한 시간, API key에서는 기본 5분 만료된다고 설명한다.

컨텍스트는 한 번 들어오면 계속 따라온다

글의 가장 좋은 문장은 사실 간단하다. 파일 내용과 명령 출력은 한 번만 보내지는 것이 아니라 이후 모든 turn에 다시 포함된다. 캐시 덕분에 싸게 읽혀도 0은 아니며, 모델이 생각해야 할 주변 정보도 늘어난다. 테스트 러너가 400개의 성공 테스트를 한 줄씩 출력하면 그 출력은 남은 세션의 짐이 된다.

이 관점은 한국 개발팀의 AI 코딩 도입에도 중요하다. 많은 팀이 월 구독료만 보고 비용을 판단한다. 하지만 실제 병목은 세션당 컨텍스트 오염, 실패한 빌드 로그 누적, 모델 전환, 불필요한 MCP 도구 정의, 긴 CLAUDE.md일 수 있다. Anthropic은 /context로 시작 상태를 확인하고, workflow-specific instruction은 skills로 옮기고, 필요 없는 MCP 서버는 끄라고 조언한다. 관련 문서는 Claude Code docs, Anthropic prompt caching 문서, Claude Code best practices와 이어진다.

비용 관리는 생산성 관리다

토큰을 아끼자는 말은 모델을 덜 쓰자는 뜻이 아니다. 비싼 토큰이 문제 해결에 쓰이도록 세션을 정리하자는 뜻이다. 작은 반복 수정은 작은 모델과 낮은 effort로, 아키텍처 판단은 큰 모델과 충분한 reasoning으로 보내는 식의 라우팅이 필요하다. noisy log 분석, 대규모 검색, dependency 조사처럼 메인 대화에 남기기 싫은 작업은 subagent가 더 낫다.

관리자 입장에서는 개발자에게 AI 도구를 던져주는 것보다 세션 운영 가이드를 제공해야 한다. 테스트 명령의 quiet flag, 로그 tail 규칙, 파일 첨부 규칙, 모델 전환 기준, 장기 세션 compact 기준을 팀 문서에 적어야 한다. 이렇게 해야 생산성 지표도 의미를 갖는다. 단순히 AI 사용량이 늘었다는 숫자는 좋은 소식이 아닐 수 있다.

자주 묻는 질문

Q1: /clear와 /compact는 어떻게 다른가요?

A: /clear는 새 작업을 위해 대화 컨텍스트를 비우는 데 가깝고, /compact는 같은 작업의 긴 대화를 요약해 이어가기 위한 도구다.

Q2: 모델을 중간에 바꾸면 왜 비싸질 수 있나요?

A: 모델별 cache key가 다르기 때문에 기존 대화가 다시 prefill될 수 있다. 바꿔야 한다면 시작 시점이나 /clear 직후가 낫다.

Q3: @file 첨부는 항상 좋은가요?

A: 필요한 파일을 한 번 첨부하는 것은 좋다. 같은 파일을 반복 첨부하면 중복 컨텍스트가 생길 수 있다.

Q4: subagent는 언제 써야 하나요?

A: 로그 분석, 대량 검색, 많은 파일 훑기처럼 결과 요약만 필요하고 중간 출력은 메인 세션에 남기고 싶지 않을 때 유용하다.

Q5: 팀 차원에서 무엇을 측정해야 하나요?

A: 완료 작업당 turn 수, 도구 출력량, cache miss를 부르는 모델 전환, 실패 로그 반복, PR당 AI 세션 시간을 함께 봐야 한다.