같은 값의 Opus 5가 36% 더 쓴 이유, 앤트로픽의 비용 줄이는 법

글은 한국 시각 9월 9일 새벽 2시에 X 아티클로 올라왔고, 쓴 사람은 앤트로픽의 랜스 마틴입니다. 비용을 줄이려면 성능을 내줘야 한다고들 여기지만, Claude 플랫폼을 쓰는 애플리케이션 상당수는 세 가지만 고쳐도 성능을 지키면서 비용을 줄일 수 있다는 것이 글의 요지입니다. 세 명령은 프롬프트에 남은 옛 지침을 찾아 고치는 prompt-audit, 애플리케이션 전체의 지출을 훑는 cost-optimize, 평가 데이터를 주면 구성을 바꿔 가며 탐색하는 hillclimb입니다.

같은 단가의 새 모델이 36% 더 쓴 이유

앤트로픽 가격표에서 Opus 4.8과 Opus 5는 입력 100만 토큰당 5달러, 출력 25달러로 값이 같습니다. 그런데 고객지원 평가에서 Opus 5의 티켓당 비용은 2.52센트에서 3.43센트로 올랐습니다. 단가가 그대로이니 늘어난 비용은 모두 새 모델이 더 쓴 토큰에서 나왔습니다.

실험은 이렇게 짰습니다. 깨끗한 프롬프트에 옛 지침을 하나씩 심어 옛날식 프롬프트 여섯 개를 만들었습니다. 심은 지침은 퇴역한 사고 설정, 서로 모순되는 환불 규칙 한 쌍, 수동 메모장, 「두 번 확인하라」, 「최대한 철저히 하라」, 여섯 단계를 반드시 밟으라는 절차입니다. 이 여섯 개를 Opus 4.8, 모델 이름만 바꾼 Opus 5, prompt-audit를 한 번 돌린 Opus 5에서 각각 돌려 평균을 냈습니다.

더 쓴 토큰이 어디로 갔는지도 글에 나옵니다. 「두 번 확인하라」는 문장 때문에 Opus 5는 환불을 처리할 때마다 주문 조회를 한 번 더 했고, 「최대한 철저히 하라」는 문장은 필요 없는 지식 베이스 검색 수십 번으로 이어졌습니다. 새 모델이 지시를 더 충실히 따르면서, 옛 모델의 약점을 메우려고 넣은 문장이 그대로 작업량이 된 겁니다.

prompt-audit는 이런 지침을 걷어내 비용을 14.6% 줄이고 정확도를 5.3%포인트 올렸습니다. 정확도가 오른 이유는 세 가지였습니다. 퇴역한 사고 설정 때문에 API가 라우팅 요청을 전부 거절하고 있었고, 모순된 환불 규칙 때문에 Opus 5가 줘야 할 환불 4건을 고객 확인을 받겠다며 보류했습니다. 수동 메모장은 Opus 5에 내장된 사고와 부딪혀, 티켓 3건에서 도구 호출을 추론 안에만 적고 실제로 실행하지 않았습니다.

감사를 마친 Opus 5도 Opus 4.8보다 티켓당 16% 비쌉니다. 정확도가 7.6%포인트 높으니 맞힌 티켓 하나로 나눠 보면 Opus 4.8은 약 2.82센트, 감사를 마친 Opus 5는 약 3.02센트로 차이가 7% 안팎으로 좁혀집니다.

앤트로픽이 걷어내라고 꼽은 여섯 가지

앤트로픽은 최신 모델에서 비용을 늘리는 옛 지침을 여섯 가지로 정리했습니다. 앞의 실험에 심은 지침 여섯 개는 이 가운데 옛 예시를 뺀 다섯 유형에서 나왔습니다.

원문은 최신 모델이라는 말에 Claude Code 팀의 타리크가 7월에 올린 게시물을 연결해 두었습니다. 최신 모델용으로 Claude Code의 시스템 프롬프트를 약 80% 지웠고, 그 과정에서 배운 것을 정리했다는 글입니다.

지침을 크게 덜어 내도 성능이 떨어지지 않았던 이 실험은 시스템 프롬프트의 80%를 지운 Claude Code 팀의 기록에서 다뤘습니다. 이번 글은 같은 원칙을 API 애플리케이션으로 넓히고, 걷어내는 일을 명령 하나로 맡길 수 있게 했습니다.

캐시 읽기는 새 입력의 40분의 1까지 내려갑니다

Claude는 답을 만들기 전에 프롬프트 전체를 내부 작업 상태로 바꾸는 계산을 먼저 합니다. 이 단계를 프리필이라고 부르고, 입력 처리 비용 대부분이 여기서 나옵니다. 프롬프트 캐싱은 그 상태(키와 값을 담은 KV 캐시)를 저장해 두었다가, 다음 요청이 같은 앞부분으로 시작하면 다시 계산하지 않고 읽어 오는 기능입니다. 9월 9일 기준 가격표를 보면 캐시를 새로 쓸 때는 웃돈이 붙고, 읽을 때는 크게 깎입니다.

단위는 100만 토큰당 가격입니다(출처: Claude Platform 가격 문서). 캐시 읽기는 보통 새 입력 가격의 0.1배인데, Fable 5.1과 Mythos 5.1만 0.025배입니다. Fable 5.1에서는 같은 토큰을 캐시로 읽으면 새로 처리할 때의 40분의 1을 내고, 캐시를 놓쳐 5분 캐시를 다시 쓰면 읽기 값의 50배를 냅니다. Opus 5와 Sonnet 5는 그 차이가 10배라, 캐시를 지키는 일의 값이 Fable 5.1에서 4배 큽니다. Fable 5.1이 캐시 읽기 요금을 직전 모델의 1달러에서 75% 내린 이야기는 Fable 5.1 출시를 다룬 글에 있습니다.

가격 문서는 5분 캐시는 한 번, 1시간 캐시는 두 번 읽으면 쓰기 웃돈을 뽑는다고 적고 있습니다. 캐시가 적용되려면 조건이 셋 붙습니다. 캐시는 모델마다 따로 저장되고, 앞부분이 바이트 단위까지 같아야 하며, 유지 시간이 정해져 있습니다.

캐시는 어디서 깨지나

글은 캐시가 깨지는 곳을 넷으로 꼽았습니다. 추론 강도 설정은 본문보다 앞에 렌더링되므로 대화 중간에 바꾸면 앞부분 전체가 어긋나고, 이를 피해 강도를 바꿀 수 있는 모델은 Opus 5와 Fable 5.1 같은 일부 모델입니다. 시스템 프롬프트에 호출마다 달라지는 시각이나 아이디가 들어가도, 도구 정의의 순서가 흔들려도 캐시가 깨집니다. 서브에이전트는 앞부분과 모델, 추론 강도가 부모와 모두 같을 때만 부모의 캐시를 함께 씁니다.

고치는 방법도 함께 적었습니다. 도구는 전부 선언하되 드물게 쓰는 것은 지연 로딩(defer_loading)으로 표시해 캐시되는 앞부분 밖에 두고, Claude가 도구 검색으로 찾을 때만 대화에 붙입니다. 대화 도중 지침을 더해야 하면 시스템 프롬프트를 고치지 않고 메시지로 넣습니다. 모델이나 추론 강도는 대화 압축처럼 어차피 캐시를 새로 쌓는 시점에 몰아서 바꿉니다.

응답 속도를 위한 요령도 있습니다. 사용자가 입력하는 동안 출력 길이를 0으로 둔 요청을 먼저 보내면, 아무것도 생성하지 않고 프롬프트만 처리해 캐시를 미리 채워 둡니다. 5분 유지 시간은 요청이 시작된 순간부터 세기 때문에, 도구 호출이나 서브에이전트가 5분을 넘기면 결과가 돌아오기 전에 부모의 캐시가 사라집니다. 이럴 때는 앞부분에 1시간 캐시를 거는 편이 낫다고 글은 권합니다.

앞부분이 어디서 어긋났는지는 Claude 콘솔과 캐시 진단 API가 연속된 두 요청을 비교해 알려 줍니다. 예시 화면에서는 한 주 동안 캐시 읽기 비율이 71.3%였고, 놓친 토큰 12억 개가 메시지 변경, 시스템 변경, 도구 변경, 모델 변경의 네 사유로 나뉘어 있습니다.

29CM는 두 달 먼저 같은 결론에 닿았습니다

국내에도 같은 원칙으로 비용을 줄인 기록이 있습니다. 7월 7일 무신사 테크 블로그에 29CM 가격 팀의 정다해 개발자가 올린 글입니다. 29CM는 상품 속성 추출과 고객 응대 등에 AWS 베드록 기반 LLM을 쓰는데, 베드록 콘솔은 하루 토큰과 비용 합계만 보여 줘서 어떤 기능이 얼마를 쓰는지 알 수 없었습니다.

팀은 호출마다 API 경로와 모델, 입력·출력·캐시 읽기·캐시 쓰기 토큰을 따로 기록하는 대시보드부터 만들었습니다. 그러자 상품 속성 추출 기능 하나가 전체 LLM 토큰의 약 92%를 쓰고 있었습니다. 이 기능은 약 1만 5,000토큰짜리 시스템 프롬프트와 상품 100개 분량의 데이터 약 2,000토큰을 호출마다 함께 보냈고, 매번 같은 1만 5,000토큰을 처음부터 다시 처리하고 있었습니다.

규칙과 예시, 출력 형식은 시스템 블록에 고정하고 상품 데이터는 사용자 메시지로 옮긴 뒤, 시스템 블록 끝에 캐시 지점을 찍고 1시간 유지를 걸었습니다. 코드 변경은 세 줄이었지만 프롬프트를 고정 부분과 변동 부분으로 나누는 작업이 먼저 필요했습니다. 1주 측정에서 캐시 읽기 비중은 약 98%가 됐고, 전체 LLM 청구액은 64% 줄었으며 정확도는 그대로였습니다. 29CM 글은 캐시가 동작하지 않아도 API가 오류를 내지 않고 캐시 읽기 값이 0으로 찍힐 뿐이라, 대시보드를 보지 않으면 모르고 지나간다고 적었습니다.

앤트로픽이 권한 프롬프트 순서와 29CM의 구조 변경은 같은 원리입니다. 우버도 8월 27일 엔지니어링 블로그에 올린 기록에서 대화형 세션의 캐시 수명을 1시간으로 늘리고 90초 안에 끝나는 서브에이전트는 5분에 남겨 두었습니다. 우버의 비용 절감 기록에는 1시간 캐시가 5턴 비용을 39% 줄인 계산이 실려 있습니다.

추론 강도, 마지막 한 단계의 값

추론 강도(effort)는 Claude에게 얼마나 애써 일할지를 알려 주는 설정입니다. 문서에 따르면 low, medium, high, xhigh, max 다섯 단계가 있고 기본값은 high입니다. 이 설정은 사고 토큰에만 걸리지 않고 답변 텍스트와 도구 호출까지 모든 출력 토큰에 걸리며, 강도를 낮추면 도구 호출도 줄고 짧아집니다.

가장 어려운 코딩 과제 50개를 모은 FrontierCode Diamond에서 Fable 5는 low로 과제당 5.35달러에 11.5%를, max로 19달러에 30.9%를 받았습니다. 점수는 2.7배(19.4포인트) 오르고 비용은 약 3.5배가 됐습니다. 도표를 보면 xhigh까지는 단계를 올릴 때마다 점수가 크게 올랐고, max에서 오름폭이 줄었습니다.

도구 없이 푸는 Humanity's Last Exam에서 Fable 5.1은 모양이 다릅니다. low에서 문항당 약 0.30달러에 약 53%, max에서 약 2.23달러에 약 61%인데, max로 올라가는 마지막 한 단계는 비용을 46% 더 쓰고 점수는 약 0.5점 얻습니다. 글은 이 차이가 벤치마크를 돌릴 때마다 생기는 잡음 안에 있어서, 돈을 더 내고 잴 수 있는 이득은 얻지 못한다고 적었습니다.

낮은 단계의 새 모델이 높은 단계의 옛 모델을 따라잡았습니다

앤트로픽이 권한 방법은 더 싼 모델로 내려가기 전에 더 강한 모델을 낮은 단계로 써 보는 것입니다. 코딩 평가 CursorBench 3.2에서 low의 Fable 5.1은 high의 Fable 5와 같은 점수를 비용 3분의 1로 냈습니다.

새 모델이 싼 데는 두 가지 이유가 있습니다. 낮은 단계에서는 과제 하나에 하는 일이 적고, 캐시 읽기 값이 100만 토큰당 0.25달러로 Fable 5의 1달러보다 쌉니다. Fable 5의 가격표를 그대로 적용해도 low의 Fable 5.1이 약 40% 쌌다고 글은 밝혔습니다.

강도를 너무 낮추는 쪽의 부작용도 적었습니다. 증거가 모이기 전에 멈춰 세 번째 검색 결과 대신 첫 결과로 답하고, 평소 스스로 하던 확인을 건너뜁니다. 답은 끝난 것처럼 보이지만 일부 정보 위에 서 있다는 설명입니다. 포화되지 않은 평가에서 강도를 올려도 점수 곡선이 평평하다면, 그 작업은 생각하는 양에 묶여 있지 않으니 강도를 올릴 이유가 없다고 봤습니다. 강도를 한 단계 올릴 때 토큰이 얼마나 느는지는 Claude Code의 모델·노력 설정을 다룬 글에서 잰 적이 있습니다.

hillclimb, 훈련 98.9%와 시험 90.5% 사이

hillclimb은 이 비교를 자동으로 돌립니다. 평가 데이터를 훈련용과 시험용으로 나누고, 구성을 바꿔 돌린 뒤 틀린 훈련 사례를 읽어 프롬프트를 고칩니다. 같은 고객지원 평가에서 출발점은 Opus 4.8의 기본 강도(high)였고, 훈련 구간 정확도는 74.4%였습니다.

첫 수는 Opus 5를 low로 돌리면서 prompt-audit로 강제 도구 호출 의례와 메모장 단계, 모순된 규칙을 걷어내는 것이었고, 훈련 정확도 98.9%에 티켓당 2.6센트가 나왔습니다. 다음에는 Sonnet 5 low로 내려가 1센트가 됐지만 정확도가 88.9%로 떨어졌습니다. Claude가 틀린 훈련 티켓을 읽고 라우팅 규칙과 환불 한도의 상호 참조를 프롬프트에 적어 넣자, 같은 1센트에서 98.9%로 돌아왔습니다. 2.6센트에서 1센트로 내려간 폭은 Opus 5와 Sonnet 5의 단가 차이(입력 5달러 대 2달러, 출력 25달러 대 10달러, 모두 2.5배)와 비슷합니다.

탐색에 한 번도 쓰지 않은 시험 티켓 14개로 재면 최종 구성은 90.5%, 원래 구성은 78.6%였고 비용은 약 5분의 1이었습니다. 훈련 구간에서는 24.5%포인트가 올랐는데 시험 구간에서 오른 폭은 11.9%포인트로 절반에 못 미칩니다. hillclimb이 훈련 티켓의 실패를 읽고 프롬프트를 고치는 방식이라, 고친 규칙 일부는 그 티켓들에만 맞았을 수 있습니다. 시험 티켓이 14개뿐이라 한 개를 더 맞히거나 틀리면 약 7%포인트가 움직입니다.

cost-optimize가 네 평가에서 줄인 것

cost-optimize는 애플리케이션 전체를 훑습니다. 먼저 토큰이 어디로 가는지 찾는데, Claude 관리자 API 키가 있으면 조직의 사용량·비용 보고서를, 응답마다 사용량을 기록해 두었으면 그 기록을 읽고, 둘 다 없으면 요청을 만드는 코드를 읽어 추정합니다. 이어 프롬프트 캐싱, 요청에 실리는 내용 줄이기(prompt-audit 포함), 출력 길이 제한, 사람이 기다리지 않는 작업의 일괄 처리 순으로 절감안을 매깁니다.

LegalBench에서는 사고 토큰이 10만 2,779개에서 8,284개로 줄었고, SWE-bench에서는 과제당 단계의 중앙값이 29에서 17로, 프롬프트 토큰이 7,520만 개에서 3,370만 개로 줄었습니다. SWE-bench는 기본 설정이 이미 캐시를 제대로 쓰고 있어서, 절감이 전부 추론 강도를 medium으로 낮추고 답을 몇 문장으로 줄인 데서 나왔습니다.

표를 읽을 때 걸리는 곳이 둘 있습니다. 네 평가 가운데 두 개는 배치 API를 썼는데, 배치는 결과를 바로 받지 못하는 대신 입력과 출력을 모두 50% 할인하는 방식입니다. OfficeQA Pro의 52.4% 절감 대부분은 이 할인으로 설명되고, 사용자가 답을 기다리는 서비스에는 그대로 옮길 수 없습니다. 네 신뢰구간이 모두 0을 지나지만, 본문은 LegalBench를 잡음 안, tau2-bench를 변화 없음으로 적었을 뿐 SWE-bench의 −3.3%포인트는 따로 언급하지 않았습니다. 그 신뢰구간은 아래로 9.6%포인트까지 열려 있습니다.

숫자에 붙은 조건

글의 숫자는 모두 앤트로픽이 자기 제품으로 잰 값입니다. 고객지원 평가는 이름과 문항이 공개되지 않았고, hillclimb의 시험 구간은 티켓 14개입니다. 세 명령도 앤트로픽의 Claude Code 안에서 돌아가니, 절감 방법을 알려 주는 쪽과 절감이 일어나는 플랫폼을 파는 쪽이 같습니다.

그래도 가격표에서 나온 숫자는 누구나 확인할 수 있습니다. Opus 4.8과 Opus 5의 단가가 같다는 것, Fable 5.1의 캐시 읽기가 0.025배라는 것, 배치가 50% 할인이라는 것은 공개 가격 문서에 있습니다. 캐시 적중률과 기능별 토큰 사용량도 29CM처럼 각자 호출 기록을 남기면 사내에서 바로 잴 수 있습니다.

국내 팀에 달라지는 것

가장 먼저 달라지는 것은 모델을 바꾸는 날의 계산입니다. 단가가 같은 모델로 옮겨도 옛 프롬프트를 그대로 두면 티켓당 비용이 36% 오를 수 있고, 앤트로픽의 실험에서 비용이 내려간 것은 모델 교체 뒤 프롬프트 감사를 거친 다음이었습니다. Fable 5.1을 쓰는 팀이라면 캐시를 한 번 놓칠 때 잃는 값이 다른 모델보다 4배 큽니다.

베드록 같은 클라우드 콘솔로 LLM 비용을 보는 팀은 29CM와 같은 문제를 겪기 쉽습니다. 콘솔이 하루 합계만 보여 주면 어느 기능이 비용을 만드는지 알 수 없고, 캐시가 깨져도 오류가 나지 않습니다. 29CM가 92%라는 숫자를 찾은 것도 기능별 기록을 심은 뒤였습니다.

모델 값의 변수도 하나 줄었습니다. 가격 문서에는 Sonnet 5의 입력 2달러, 출력 10달러가 8월 31일까지의 도입 가격에서 정식 가격이 됐고, 9월 1일로 예정됐던 3달러·15달러 인상은 없던 일이 됐다고 적혀 있습니다. hillclimb이 마지막에 고른 구성도 Sonnet 5 low였습니다.

아티클·11분 읽기AIGPT-5.6이 자기 GPU 코드를 고쳐 오픈AI 서빙 비용이 20% 줄었습니다GPT-5.6 Sol이 다시 쓴 커널로 종단 서빙 비용이 20% 줄고, 스스로 개선한 초안 모델로 토큰 생성 효율이 15% 넘게 올랐습니다. 하네스는 도구 출력을 기본 1만 토큰에서 자르고 기록을 뒤에만 덧붙여, 일반 입력의 10분의 1 가격인 캐시를 지킵니다.읽기

읽어 주셔서 고맙습니다.

초이 드림