AI 서비스를 운영하다 보면 결국 이 질문을 만나게 됩니다.

“성능을 유지하면서 API 비용을 줄일 수 있을까?”

보통 비용과 성능은 반비례한다고 생각합니다.

더 좋은 모델을 쓰거나 더 오래 생각하게 하면 성능은 올라가지만 비용도 올라가고, 비용을 줄이려면 어느 정도 품질 저하를 감수해야 한다는 식입니다.

그런데 Anthropic이 최근 공개한 Claude Platform 비용 최적화 사례는 조금 다른 이야기를 합니다.

비용을 줄이는 과정에서 오히려 정확도가 올라갈 수도 있습니다.

핵심은 더 싼 모델을 선택하는 것이 아닙니다.

Claude가 실제로 어디에서 토큰을 소비하고, 어떤 이유로 불필요한 작업을 반복하는지부터 찾아야 합니다.

Anthropic이 강조하는 핵심은 세 가지입니다.

Prompt CachePrompt InstructionsEffort

1. Prompt Cache부터 확인해야 합니다

Claude가 답변을 생성하기 전에는 입력된 프롬프트를 내부 상태로 처리하는 Prefill 과정이 필요합니다.

이 과정이 입력 처리 비용에서 상당히 중요한 부분을 차지합니다.

Prompt Caching은 동일한 프롬프트 Prefix에 대해 이전에 계산한 KV Cache를 다시 사용하는 방식입니다. 캐시를 읽는 비용은 전체 입력을 다시 처리하는 것보다 훨씬 저렴합니다.

문제는 캐시가 생각보다 쉽게 깨진다는 것입니다.

예를 들어 System Prompt 앞부분에 현재 시간이나 동적인 ID를 넣으면 매 요청마다 Prefix가 달라집니다.

Tool Definition의 순서가 달라져도 캐시가 깨질 수 있습니다.

Subagent를 만들거나 대화를 Fork할 때도 모델, Effort, Prefix가 동일하지 않으면 부모 Agent의 캐시를 그대로 활용하지 못합니다.

즉 Agent 시스템에서 비용을 줄이고 싶다면 가장 먼저 확인해야 하는 지표 중 하나가

Prompt Cache Hit Rate

입니다.

캐시를 살리는 몇 가지 방법

Anthropic은 실제 운영에서 몇 가지 패턴을 권장합니다.

자주 사용하지 않는 Tool은 defer_loading으로 뒤로 미루고, System Prompt를 중간에 변경해야 한다면 지원되는 모델에서는 System Message 형태로 추가합니다.

또 프롬프트 구조도 중요합니다.

앞부분에는 변하지 않는

Tool Definition → System Prompt → Static Context

를 두고,

변화가 많은 Conversation Context를 뒤쪽에 배치하는 편이 캐시를 유지하는 데 유리합니다.

첫 요청의 지연시간이 중요하다면 Cache Pre-warming도 사용할 수 있습니다.

max_tokens: 0 요청을 먼저 보내 캐시를 만들어두면 실제 첫 요청에서 Warm Cache를 사용할 수 있습니다.

다만 기본 Cache TTL이 5분이기 때문에 Tool Call이나 Subagent 작업이 오래 걸리는 Agent라면 캐시가 작업 도중 만료될 수도 있습니다. 이런 경우 1시간 TTL 사용을 검토할 수 있습니다.

2. 오래된 Prompt가 오히려 최신 모델의 성능을 떨어뜨립니다

두 번째는 조금 더 흥미롭습니다.

모델은 계속 발전하는데 Prompt는 그대로 남아 있는 경우가 많습니다.

과거 모델의 약점을 보완하기 위해 넣었던 지시문이 최신 Frontier Model에서는 오히려 방해가 될 수 있습니다.

대표적인 예가 이런 문장입니다.

반드시 두 번 검증하세요.최대한 철저하게 분석하세요.항상 다음 6단계를 수행하세요.

예전에는 이런 지시가 모델의 실수를 줄이는 안전장치 역할을 했습니다.

하지만 최신 모델에서는 이미 자체적인 Reasoning 과정이 있기 때문에 이런 지시가 중복 Reasoning이나 불필요한 Tool Call을 발생시킬 수 있습니다.

Anthropic이 지적한 대표적인 Anti-pattern은 다음과 같습니다.

Prompt를 줄였는데 정확도가 올라갔습니다

Anthropic은 Opus 4.8용 Prompt를 Opus 5로 Migration하는 실험을 진행했습니다.

Prompt에는 일부러 여섯 종류의 Legacy Anti-pattern을 넣었습니다.

그리고 단순히 모델만 Opus 5로 바꾼 경우와, /claude-api prompt-audit을 적용한 경우를 비교했습니다.

결과는 꽤 의미가 있습니다.

비용 14.6% 감소정확도 5.3% 증가

했습니다.

비용이 감소한 이유는 단순합니다.

불필요한 Tool Call과 중복 Reasoning이 사라졌기 때문입니다.

더 중요한 부분은 정확도까지 올라갔다는 점입니다.

예를 들어 “verify twice”라는 지시 때문에 Refund 처리 때마다 Order Lookup이 중복됐고, “be maximally thorough”라는 지시는 필요하지 않은 Knowledge Base Search를 수십 번 발생시키기도 했습니다.

여기서 한 가지 중요한 교훈을 얻을 수 있습니다.

Prompt Engineering은 계속 추가하는 작업이 아니라, 모델이 발전할수록 다시 삭제하는 작업이기도 합니다.

3. Effort는 높을수록 좋은 것이 아닙니다

Claude의 Effort는 모델에게 사실상

“이 문제를 얼마나 열심히 생각할 것인가”

를 지정하는 설정입니다.

Low Effort에서는 빠르게 결론에 도달하고, High Effort에서는 더 오래 검토하고 대안을 탐색합니다.

당연히 어려운 문제라면 높은 Effort가 도움이 될 수 있습니다.

하지만 모든 요청을 High Effort로 처리하면 문제가 생깁니다.

필요 이상으로 오래 고민하면서

가 발생할 수 있습니다.

심지어 과도한 Deliberation이 답변 품질을 떨어뜨릴 수도 있습니다.

반대로 Effort를 지나치게 낮추면 충분한 증거를 찾기도 전에 답을 만들어버릴 수 있습니다.

그래서 중요한 것은

High냐 Low냐가 아니라 Task에 맞는 Effort를 찾는 것

입니다.

더 좋은 모델을 낮은 Effort로 쓰는 것이 더 쌀 수도 있습니다

Anthropic이 제시한 비교 중 특히 눈에 들어오는 부분이 있습니다.

CursorBench 3.2에서 Claude Fable 5.1을 Low Effort로 사용한 결과가 Fable 5 High Effort와 비슷한 성능을 냈습니다.

그런데 비용은 약 3분의 1 수준이었습니다.

우리는 흔히 AI 비용을 줄일 때 이렇게 생각합니다.

비싼 모델 → 싼 모델

하지만 실제 최적화는

강한 모델 × 낮은 Effort

가

약한 모델 × 높은 Effort

보다 나을 수도 있습니다.

결국 Model Routing도 모델 가격표만 보고 결정해서는 안 됩니다.

모델 × Effort × Cache Hit Rate × Task Success Rate

를 같이 봐야 합니다.

Anthropic은 이 과정을 자동화하기 시작했습니다

이번 글에서 흥미로운 부분은 Anthropic이 단순히 최적화 방법만 설명한 것이 아니라 이를 Claude Code의 Skill로 만들었다는 점입니다.

/claude-api prompt-audit

기존 Prompt와 Skill, Tool Description을 분석해서 최신 모델에서 문제가 될 수 있는 Anti-pattern을 찾습니다.

/claude-api cost-optimize

API 사용량이나 애플리케이션 코드를 분석해 토큰이 어디에서 사용되는지 찾고,

Prompt Caching, Prompt Audit, Output 제한, Batch Processing 등을 적용합니다.

/claude-api hillclimb

Evaluation이 있다면 Model과 Effort 조합을 바꾸면서 비용과 성능을 탐색합니다.

Train/Test Set으로 Evaluation을 나누고 실패한 케이스를 분석해 설정이나 Prompt를 다시 수정합니다.

사실상 LLM FinOps를 Agent가 수행하기 시작한 것에 가깝습니다.

실제 비용 절감 폭은 어느 정도였을까

Anthropic은 cost-optimize를 몇 가지 공개 Benchmark에 적용했습니다.

결과는 다음과 같습니다.

LegalBench약 58% 비용 절감

Prompt Caching + Low Effort + Batch API를 적용했고 Pass Rate는 큰 변화가 없었습니다.

tau2-bench retail약 73% 비용 절감

Prompt Cache Breakpoint를 제대로 적용한 것만으로 비용을 크게 줄였습니다.

OfficeQA Pro약 52% 비용 절감

Batch Processing과 Document Caching을 적용해 비용이 $136.20 → $64.87로 감소했습니다.

SWE-bench Verified약 55% 비용 절감

이미 Cache는 제대로 작동하고 있었기 때문에 Effort를 Medium으로 낮추고 Agent Output을 제한했습니다.

그 결과 Median Step이 29 → 17, Prompt Token은 75.2M → 33.7M으로 감소했습니다.

여기에서도 재미있는 점이 있습니다.

최적화 방법이 Benchmark마다 전부 다릅니다.

즉,

“AI 비용을 줄이는 최고의 설정”은 존재하지 않습니다.

Task와 Agent 구조에 따라 병목이 다르기 때문입니다.

이제 Prompt도 코드처럼 리팩터링해야 합니다

이번 Anthropic의 글에서 제가 가장 중요하게 본 부분은 비용 절감 숫자가 아닙니다.

LLM 애플리케이션을 운영하는 방법이 바뀌고 있다는 점입니다.

예전에는 Prompt를 잘 만드는 것이 중요했습니다.

앞으로는

Prompt를 지속적으로 측정하고, 평가하고, 삭제하고, 다시 최적화하는 운영 체계

가 더 중요해질 가능성이 큽니다.

특히 Agent 시스템에서는

PromptTool DefinitionModelEffortCacheContextEvaluation

이 서로 연결되어 있습니다.

이 중 하나만 바꿔도 비용과 성능이 동시에 움직일 수 있습니다.

그래서 AI 비용 최적화는 단순한 Token 절감 문제가 아닙니다.

AI 시스템의 실행 경로를 최적화하는 문제에 더 가깝습니다.

이번 글에서 가져갈 것

Claude API 비용이 고민이라면 모델부터 낮추기 전에 세 가지부터 확인해볼 만합니다.

1. Prompt Cache Hit Rate가 제대로 나오고 있는가

동적인 값이나 Tool Definition 변경 때문에 Cache가 계속 깨지고 있지는 않은지 확인합니다.

2. Prompt에 오래된 지시가 쌓여 있지 않은가

“반드시 두 번 확인”, “최대한 철저하게”, 강제 Scratchpad 같은 지시가 최신 모델의 Native Reasoning과 충돌하고 있지 않은지 점검합니다.

3. 모든 Task를 같은 Effort로 처리하고 있지 않은가

Task별 Evaluation을 만들고 Model과 Effort를 함께 테스트해야 합니다.

결국 가장 좋은 최적화는

가장 싼 모델을 찾는 것이 아니라목표 성능을 만족하는 가장 싼 실행 경로를 찾는 것

입니다.

그리고 Anthropic은 그 탐색 과정 자체도 Agent에게 맡기기 시작했습니다.

참고

Anthropic, Reducing cost and improving performance with Claude Platform

Claude Code에서는 claude-api Skill을 통해 prompt-audit, cost-optimize, hillclimb 기능을 사용할 수 있습니다.