비용을 시각화한 후에는 「어디를 줄일 것인가」를 결정한다

Claude Code를 본격적으로 운용하면, cost.log에 쌓이는 금액은 하루에 몇 달러 단위까지 불어난다.

시각화 단계까지는 전작인 「Claude Code의 토큰 소비를 시각화하기」에서 다루었다.

남은 과제는 「숫자를 본 뒤 무엇을 줄일 것인가」이다.

결론부터 말하겠다.

세 가지 축 — 모델 선택, 프롬프트 캐시 (Prompt Cache), 명령 단가 튜닝 — 의 조합으로, 월간 비용의 30%는 시뮬레이션 가능한 범위 내에서 줄일 수 있다.

본 기사는 실시 전의 설계와 시뮬레이션에 집중한다. 절감 잠재력의 추정 절차와 근거만을 다루며, 대책의 선정과 효과 검증은 독자의 팀에 맡긴다.

먼저, 절감이 진행되지 않는 세 가지 구조를 확인한다.

왜 비용이 불어난 채 방치되는가

시각화가 되어 있음에도 비용 절감으로 나아가지 못하는 이유는 세 가지가 있다.

첫째, 커맨드마다 최적의 모델을 확실히 결정하지 못하고 있다.

Sonnet 4.6은 강력하지만, 단순한 분류·추출·템플릿 생성에 Sonnet을 사용할 필연성은 없다.

Haiku 4.5의 입력 단가는 $1/MTok, Sonnet 4.6은 $3/MTok으로 3배 차이가 난다 (Anthropic API Pricing).

둘째, 프롬프트 캐시 (Prompt Cache)를 의식하지 않고 명령을 구성하고 있다.

캐시 히트 (Cache hit) 시의 입력 단가는 통상의 1/10이다.

커맨드 파일, MEMORY.md, 코드 단편 등 동일한 문맥을 반복하는 부분은 캐시 대상으로 맞추는 것만으로도 히트 부분의 비용이 90% 낮아진다.

셋째, 출력 토큰 (Output tokens)이 입력의 5배 단가로 작용하고 있다.

JSON ops 형식의 장황한 서론, 코드 펜스 (Code fence), 설명문을 출력하게 하면, 저렴해야 할 명령이 야금야금 비싸진다.

출력 단가는 Haiku 4.5에서 $5/MTok, Sonnet 4.6에서 $15/MTok이다.

출력 100KTok은 입력 1MTok보다 비싸다. 이 단가 구조를 전제로 설계해야 한다.

세 가지 축을 조합하면, 시각화 단계에서 보였던 「무거운 명령」의 단가를 크게 낮출 수 있다 (후술하는 시뮬레이션에서는 합계 약 30%).

대책별로 시뮬레이션해 보겠다.

대책 1: 커맨드 단위로 모델을 다시 선택하기

cost.log의 집계에서 「비용이 높은 상위 커맨드」를 뽑아낸다.

콘텐츠 자동화 파이프라인의 예로 들면, research (소재 탐색), draft (집필), review (편집 리뷰)가 비용 상위에 오르기 쉽다.

각각에 정말 Sonnet이 필요한지 판단하는 기준은 다음과 같다.

판단이 복잡한가 (복수의 문맥을 통합하는가): 필요 → Sonnet 4.6 -
템플릿 생성·추출·분류인가: 불필요 → Haiku 4.5 -
코드 생성이나 설계 판단을 포함하는가: 필요 → Sonnet 4.6

예를 들어 dispatch_ops의 JSON 정형화, 슬러그 (Slug) 중복 체크, 커밋 메시지 생성은 Haiku로도 충분하다.

반면 draft, editorial-review는 문장 구성 판단이 필요하므로 Sonnet을 유지한다.

전환 방법은 각 커맨드의 frontmatter에 model을 명시하기만 하면 된다.

---
description: "JSON ops를 정형화하여 표준 출력으로 반환"
model: claude-haiku-4-5
...

run_cmd (lib.sh)가 frontmatter의 model을 읽어 claude --print --model에 전달하는 구조라면, 단 한 줄의 변경으로 단가가 1/3이 되는 명령은 드물지 않다.

여기서 효과를 추정할 때의 시뮬레이션 예시를 둔다 (커맨드 구성·실행 횟수는 전형적인 예시 기준).

이 구성만으로 약 22%.

모델 재선택만으로도 명령량을 바꾸지 않고 2할은 줄일 수 있다는 시뮬레이션 결과가 나온다.

대책 2: 프롬프트 캐시를 커맨드 파일에 적용하기

프롬프트 캐시 (Prompt Cache)는 시스템 프롬프트, 긴 컨텍스트, 반복되는 커맨드 파일을 서버 측에 저장하는 메커니즘이다.

쓰기 비용은 통상 입력의 1.25배이지만, 히트 시에는 0.1배 — 즉 히트 부분은 90% 할인된다.

2회차 호출부터 효과가 나타난다.

효과를 내기 쉬운 사용법은 다음 세 가지 패턴이다.

시에에는 0.1배 — 즉 히트 부분은 90% 할인된다.

2회차 호출부터 효과가 나타난다.

효과를 내기 쉬운 사용법은 다음 세 가지 패턴이다.

• 같은 명령어를 연속 실행: 배치 처리에서 review를 5회 연속으로 실행하는 등 -
• 공통의 컨텍스트: 모든 명령어에서 동일한 MEMORY.md / CLAUDE.md 파일을 불러오기 -
• 긴 프롬프트 본문: 1개 명령어의 캐시 대상이 최소 단위를 초과할 경우. 최소 단위는 Sonnet 4.6 / Opus 4.7에서 2,048 토큰, Haiku 4.5에서 1,024 토큰(Anthropic 공식 문서)

캐시 대상으로 지정하려면 API 요청 측에서 cache_control을 명시해야 한다.

claude --print를 경유하는 경우, 명령어의 frontmatter에서 긴 문맥을 분리하여 재사용하기 쉽게 해두는 것이 좋다.

단가 관계는 다음과 같다(입력 단가 기준).

주의할 점은 TTL이다.

기본 TTL은 5분 (ephemeral)이며, 추가 비용 없이 캐시 히트 시 자동으로 업데이트된다.

5분을 초과하는 간격으로 캐시를 유지하고 싶을 경우에만, `ttl:

• 시책 투입 전 기준값 확보: 1주일간 cost.log를 축적하여 커맨드별 단가 산출
• 시책별 단계적 투입: 모델 전환 → 캐시 → 출력 감소 순으로 한 번에 하나의 시책씩 진행
• 각 단계의 차이 측정: 1주일 단위로 cost-report.py --date-range를 실행하여 전주 대비 차이 산출

여러 시책을 한꺼번에 투입하면 어떤 것이 효과가 있었는지 알 수 없게 된다.

하나씩 도입하며 차이를 측정하면 효과가 없는 시책을 가려낼 수 있다.

예산이 엄격할 때는 절감 폭이 가장 큰 모델 전환부터 시작한다.

캐시는 '동일한 명령을 높은 빈도로 호출한다'는 전제가 있으므로, cron 빈도가 낮은 처리에서는 효과가 나타나기 어렵다.

커맨드 빈도 분포를 확인한 뒤 순서를 결정하면 불필요한 투자를 피할 수 있다.

요약 — 시뮬레이션은 출발점, 단계적 투입을 통해 실측으로 연결

Claude Code의 비용은 가시화 이후 '절감 설계' 단계로 넘어갈 수 있을 때 비로소 운영 대상이 된다.

모델 선택, 프롬프트 캐시 (Prompt Cache), 출력 토큰 감소라는 세 가지 축을 조합하면, 시뮬레이션 기준으로 30% 절감의 잠재력을 확인할 수 있다.

단, 시뮬레이션은 실측이 아니다.

30%라는 숫자는 위의 전제(커맨드 구성, 실행 빈도, 히트율, 출력 단축률) 하에서의 추정치에 불과하다.

시뮬레이션에서 나온 절감 폭을 실측으로 옮기기 위해서는, 시책을 하나씩 단계적으로 투입하며 전주 대비 차이를 측정하는 운영이 필요하다.

설계와 시뮬레이션은 Claude Code 스스로 작성하게 해도 무방하다.

그 위에서 인간이 내려야 할 판단은 다음 세 가지로 압축할 수 있다.

• 어디까지 줄일 것인가: 30%인가, 50%인가, 품질과의 교환 비율
• 어떤 정밀도를 타협할 수 없는가: Haiku로 전환해서는 안 되는 명령은 무엇인가
• 검증 기간을 어떻게 잡을 것인가: 1주일로 끝낼 것인가, 월 단위로 측정할 것인가

시스템을 만드는 것은 Claude Code이며, 검증하여 채택 여부를 결정하는 것은 SRE이다.

비용 절감 또한 이러한 분업을 통해 앞으로 나아갈 수 있다.