AI 비용은 줄이고 성능은 높이는 3가지 방법: Claude 플랫폼 최적화 가이드

한 줄 요약: AI 비용을 줄이는 가장 좋은 방법은 무조건 싼 모델을 고르는 것이 아니다. 반복되는 입력은 캐시하고, 낡은 프롬프트 규칙은 걷어내고, 일의 난이도에 맞춰 AI가 생각하는 강도를 조절해야 한다.

Anthropic이 2026년 9월 8일 공개한 글은 흔히 갖는 오해부터 뒤집는다. 보통 비용을 아끼려면 성능을 포기해야 한다고 생각한다. 하지만 Claude Platform을 실제로 운영해 보니, 설정과 프롬프트를 제대로 다듬는 것만으로 비용을 낮추면서 정확도까지 높일 수 있었다는 설명이다.

핵심은 세 가지다. 프롬프트 캐시 적중률을 높이고, 최신 모델에 맞지 않는 낡은 지시문을 없애고, 업무 난이도에 맞춰 effort(생각하는 강도)를 조절하는 것이다. 기술 용어가 많아 보이지만, 사무실 업무에 빗대면 어렵지 않다.

1. 프롬프트 캐시: 매번 서류철을 처음부터 읽히지 말자

Claude가 답을 만들기 전에는 사용자가 보낸 지시문, 참고자료, 도구 설명, 지금까지의 대화를 먼저 읽고 내부 작업 상태를 만든다. 이 입력 처리 과정을 프리필(prefill)이라고 한다. 긴 문서를 매번 처음부터 읽히면 시간과 비용이 든다.

프롬프트 캐시는 한 번 읽은 공통 내용을 잠시 보관했다가, 다음 요청이 같은 내용으로 시작하면 다시 계산하지 않고 불러오는 기능이다. 캐시 읽기 비용은 전체 입력을 새로 처리하는 비용보다 훨씬 싸다.

예시: 100쪽짜리 사내 규정집을 참고하는 인사 상담 AI

직원이 휴가 질문을 할 때마다 규정집 100쪽을 새로 읽힌다고 해보자. 질문은 한 줄인데 비용 대부분은 같은 규정집을 반복해서 읽는 데 쓰인다. 규정집과 공통 지시문을 앞부분에 고정해 캐시하면, 다음 질문부터는 이미 읽어 둔 규정집을 꺼내 쓰는 것처럼 처리할 수 있다.

캐시가 자꾸 깨지는 이유

• 앞부분에 현재 시각이나 매번 바뀌는 ID를 넣는다. 캐시는 바이트 단위로 정확히 같아야 하므로 한 글자만 달라도 다른 입력으로 본다.
• 도구 목록의 순서가 매번 바뀐다. 도구 정의는 프롬프트 앞부분에 들어가므로 순서가 달라지면 공통 시작 부분이 달라진다.
• 대화 도중 모델이나 effort 설정을 바꾼다. 모델별 캐시가 따로 있고 설정도 캐시 앞부분에 반영될 수 있다.
• 도구 실행이나 하위 에이전트가 캐시 유효시간보다 오래 걸린다. 기본 5분 캐시가 만료되면 다음 요청에서 다시 써야 한다. 원문에 따르면 재작성은 일반 입력 가격의 1.25배이며, 1시간 캐시는 2배다.

실무에서는 이렇게 고친다

• 시스템 지시문과 자주 쓰는 도구처럼 변하지 않는 내용은 앞에, 사용자 질문과 결과처럼 변하는 내용은 뒤에 둔다.
• Claude Console의 캐시 진단으로 어디서 입력이 달라졌는지 확인한다.
• 거의 쓰지 않는 도구는 defer_loading으로 미뤄, 필요할 때만 불러온다.
• 시스템 규칙을 대화 중에 바꿔야 한다면 시스템 프롬프트 자체를 고치기보다 메시지로 추가한다.
• 첫 요청 전에 max_tokens: 0으로 캐시를 미리 데워 두면 사용자가 실제 질문을 보낼 때 응답 지연을 줄일 수 있다.
• 작업이 5분을 넘길 가능성이 크면 1시간 TTL을 검토한다. 다만 더 비싼 캐시 쓰기 비용과 실제 재사용 횟수를 함께 계산해야 한다.

2. 낡은 프롬프트 청소: 최신 AI에게 옛날식 잔소리를 반복하지 말자

AI 모델이 약하던 시절에는 실수를 막기 위해 프롬프트에 보조 규칙을 계속 덧붙였다. “반드시 두 번 검증하라”, “최대한 철저하게 답하라”, “항상 여섯 단계로 처리하라” 같은 문장이다. 최신 모델은 이런 지시를 더 충실히 따르기 때문에 오히려 불필요한 검색과 도구 호출을 반복할 수 있다.

예시: 고객 환불 상담 AI

간단히 주문을 조회하고 환불하면 되는 상황인데 “모든 작업을 두 번 검증하라”는 규칙이 남아 있으면 주문 조회를 두 번 할 수 있다. “최대한 철저하게”라는 말까지 있으면 관련 없는 지식문서를 수십 번 찾을 수도 있다. 사람으로 치면 숙련 직원에게 간단한 환불 한 건을 맡기면서 보고서와 확인서를 매번 두 벌씩 만들라고 시키는 셈이다.

원문 실험에서는 Opus 4.8용 프롬프트에 낡은 설정, 서로 모순되는 환불 규칙, 수동 생각 과정, “두 번 검증”, “최대한 철저하게”, 의무적인 6단계 절차를 하나씩 심었다. 모델 ID만 Opus 5로 바꾼 경우와 /claude-api prompt-audit으로 정리한 경우를 비교했더니, 프롬프트 정리 후 평균 비용은 14.6% 감소하고 정확도는 5.3% 높아졌다.

특히 찾아볼 프롬프트의 낡은 습관

• 두 번, 세 번 확인하라는 검증 의식
• “매우 중요”, “무조건”, “최대한 철저하게” 같은 강조 문구
• 고정된 단계와 수동 scratchpad를 요구하는 사고 절차
• 이전 모델의 약점을 보완하려고 넣은 오래된 예시
• “정책 안에서는 항상 환불”과 “승인 없이는 절대 환불 금지”처럼 서로 충돌하는 규칙
• 새 모델에서 더는 지원하지 않는 구식 설정

중요한 것은 프롬프트를 짧게 만드는 일 자체가 아니다. 업무에 꼭 필요한 정책과 예외는 남기되, 모델이 이미 할 수 있는 일을 강제로 반복시키는 장식을 빼는 것이다.

3. Effort 조절: 모든 일에 최고 강도로 생각하게 하지 말자

effort는 Claude에게 얼마나 깊게 생각하고 확인할지 알려 주는 설정이다. 낮으면 빨리 결론을 내리고, 높으면 더 오래 검토하고 대안도 탐색한다. 높은 effort가 항상 좋은 것은 아니다. 쉬운 일에 너무 높게 설정하면 비용과 지연이 늘고, 필요 이상으로 생각하다가 답이 오히려 나빠질 수도 있다. 반대로 어려운 일에 너무 낮게 설정하면 충분한 자료를 찾기 전에 답을 끝낸다.

예시: 회사 업무별로 다른 생각의 강도

• 회의 날짜를 형식에 맞춰 정리하기: 낮은 effort
• 고객 문의를 분류하고 답변 초안을 만들기: 낮음 또는 중간 effort
• 계약서 위험 조항을 비교하거나 복잡한 장애 원인을 찾기: 높은 effort

모든 직원에게 모든 업무를 임원회의 안건처럼 검토하라고 하면 조직이 느려진다. AI도 마찬가지다.

원문이 소개한 Humanity’s Last Exam 사례에서는 Fable 5.1이 낮은 effort에서 문제당 약 0.30달러로 약 53%를 기록했고, 최대 effort에서는 약 2.23달러로 약 61%를 기록했다. 마지막 단계에서 비용은 46% 늘었지만 점수 상승은 약 0.5%포인트에 그쳐 측정 잡음 범위였다. 더 많은 비용이 눈에 띄는 품질 개선으로 이어지지 않은 구간이다.

반대로 FrontierCode Diamond처럼 매우 어려운 코딩 과제에서는 Fable 5의 최대 effort가 낮은 effort보다 점수가 크게 높았다. 결국 정답은 “항상 낮게”도 “항상 높게”도 아니다. 실제 업무 샘플로 비용과 성공률을 함께 측정해 적정 지점을 찾는 것이다.

더 강한 모델을 낮은 effort로 쓰는 선택

흥미로운 방법은 구형 또는 약한 모델을 높은 effort로 돌리는 대신, 더 강한 최신 모델을 낮은 effort로 쓰는 것이다. Anthropic의 CursorBench 3.2 사례에서 Fable 5.1 낮은 effort는 Fable 5 높은 effort와 비슷한 성능을 내면서 비용은 약 3분의 1이었다. 새 모델의 캐시 읽기 가격이 더 낮고, 낮은 effort로 처리하는 작업량도 적었기 때문이다.

자동차로 비유하면 작은 엔진을 늘 최고 회전수로 돌리는 것보다 효율 좋은 새 엔진을 여유 있게 쓰는 편이 더 빠르고 경제적일 수 있다는 뜻이다. 단, 내 업무에서도 그런지는 반드시 평가 데이터로 확인해야 한다.

Anthropic이 공개한 세 가지 도구

• /claude-api prompt-audit: 프롬프트, 스킬, 도구 설명에서 최신 모델의 성능을 방해하는 낡은 패턴을 찾고 정리한다.
• /claude-api cost-optimize: 토큰이 어디에 쓰이는지 분석하고 캐시, 출력 제한, 배치 처리, effort와 모델 선택 등 절감 후보를 시험한다.
• /claude-api hillclimb: 평가 데이터를 학습용과 검증용으로 나누고, 비용을 줄이면서 기준 성능을 유지하는 설정을 반복 탐색한다.

공개 벤치마크에서 cost-optimize를 적용한 결과로는 LegalBench 약 58%, tau2-bench retail 73%, OfficeQA Pro 약 52%, SWE-bench Verified 약 55%의 비용 감소가 소개됐다. 각 과제마다 캐시, 배치 처리, effort 조절, 출력 길이 제한처럼 효과가 컸던 방법은 달랐다.

소규모 조직과 개인 AI 에이전트에 주는 의미

이 원칙은 대기업 API 시스템에만 해당하지 않는다. 개인용 AI 에이전트나 작은 회사의 업무자동화에서도 똑같이 적용된다. 비용을 줄인다고 무조건 가장 싼 모델 하나로 통일하면 어려운 업무의 성공률이 떨어진다. 반대로 모든 업무를 최고 모델·최고 effort로 처리하면 간단한 분류와 요약에도 돈을 낭비한다.

제가 말하는 비용 인식형 개인 에이전트 오케스트레이션(CPAO)의 관점에서도 핵심은 같은 질문이다. 어떤 일은 캐시할 것인가, 어떤 지시는 지울 것인가, 어떤 일에 어느 정도의 모델과 생각을 배정할 것인가. 비용 관리는 모델 가격표만 비교하는 일이 아니라, 일의 성격에 맞춰 AI의 작업 방식을 설계하는 일이다.

내일부터 적용할 6가지 점검표

1. 요청마다 반복해서 보내는 긴 규정, 매뉴얼, 도구 설명이 있는지 찾는다.
2. 변하지 않는 공통 내용은 앞에, 시각·ID·질문 같은 변동 내용은 뒤에 둔다.
3. 캐시 적중률과 캐시가 깨지는 위치를 실제 로그와 진단 화면으로 확인한다.
4. “두 번 검증”, “최대한 철저하게”, 고정 scratchpad 같은 낡은 지시를 점검한다.
5. 쉬운 일·보통 일·어려운 일의 대표 샘플을 만들고 effort별 비용과 성공률을 비교한다.
6. 비용만 보지 말고 정확도, 처리시간, 도구 호출 횟수를 함께 기록한다.

마무리

AI 비용 최적화는 성능을 깎는 절약이 아니다. 같은 내용을 반복해서 읽히지 않고, 최신 모델에 불필요한 절차를 강요하지 않고, 쉬운 일과 어려운 일에 서로 다른 힘을 쓰게 만드는 운영 설계다.

가장 먼저 할 일은 모델을 바꾸는 것이 아니라 현재 요청 하나가 어떻게 만들어지는지 보는 것이다. 프롬프트 앞부분이 매번 달라지는지, 오래된 지시가 도구 호출을 늘리는지, 쉬운 업무에 지나친 effort를 쓰고 있는지 확인해 보자. 여기서 새는 비용을 막으면 더 적게 쓰면서 더 좋은 결과를 얻을 가능성이 크다.

---

참고: Lance Martin, “Reducing cost and improving performance with Claude Platform”, Anthropic, 2026년 9월 8일
원문 기사 읽기