Claude Opus 4.8은 가격을 올리지 않았습니다. 기본 설정을 올렸을 뿐입니다. `effort=high`가 청구서에 미치는 영향

Anthropic은 목요일에 Claude Opus 4.8을 출시했습니다. 가격은 변하지 않았습니다. 입력 토큰 100만 개당 5달러, 출력 100만 개당 25달러로 4.7과 동일합니다.

하지만 그들은 한 가지 기본 설정(default)을 변경했습니다. 이제 effort 설정이 API, Claude Code, 웹 앱 등 모든 곳에서 high로 설정되어 출시됩니다.

토큰당 가격은 일정합니다. 하지만 작업당 토큰 수는 그렇지 않습니다. 월요일에 대시보드를 열어보면 그 차이를 확인하게 될 것입니다.

실제로 출시된 내용

출시 게시물의 수식어들을 제외하고, 2026년 5월 28일에 실제로 적용된 내용은 다음과 같습니다:

동일한 헤드라인 가격. Opus 4.8은 입력 100만 개당 5달러, 출력 100만 개당 25달러로 4.7과 동일합니다. Anthropic은 이 점을 강조했으며, 이는 사실입니다.
Fast mode 가격 재조정. Fast mode는 2.5배 빠른 출력 속도로 작동하며, 입력 100만 개당 10달러, 출력 100만 개당 50달러의 비용이 듭니다. Anthropic의 설명 방식은 다음과 같습니다: "이전 모델의 Fast mode보다 3배 저렴합니다." 이 문장을 다시 읽어보세요. 표준(standard) 모델보다 3배 저렴한 것이 아니라, 이전의 Fast mode보다 3배 저렴하다는 뜻입니다. Fast mode는 여전히 표준 Opus 가격의 2배입니다.
effort 기본값이 high로 설정. 이것이 숨겨진 핵심입니다. high, xhigh, max와 같은 effort 파라미터는 모델이 답변하기 전에 얼마나 많은 추론 토큰 (reasoning tokens)을 사용할지 제어합니다. 4.8 버전에서는 모든 인터페이스에서 이 값이 high로 기본 설정됩니다. 사용자가 직접 낮출 수는 있지만, 기본값은 그렇지 않습니다.
Dynamic Workflows (리서치 프리뷰). 이제 Claude는 작업을 계획하고

경쟁적 프레이밍 (The competitive framing). Anthropic은 4.8이 자사의 Super-Agent 벤치마크에서 모든 케이스를 엔드 투 엔드 (end-to-end)로 완료한 유일한 모델이며, "비용 측면에서 GPT-5.5와 동등한 수준(at parity on cost)으로 압도했다"고 주장합니다. "비용 측면에서 동등하다(at parity on cost)"라는 문구는 매우 중요한 역할을 합니다. 이제 마케팅 포인트는 더 이상 "더 똑똑하다"가 아니라, "같은 비용으로 더 똑똑하다"가 되었습니다. 이는 현재 시장 전체가 어디에서 경쟁하고 있는지를 보여주는 신호입니다.

이것이 출시 내용입니다. 이제 출시 게시물이 당신을 위해 해주지 않을 부분, 즉 수학적 계산을 살펴볼 차례입니다.

이것이 변경 로그(changelog)가 아닌 청구서에 반영되는 이유

"4.7과 동일한 가격"이 헤드라인입니다. 하지만 이것은 동시에 눈속임이기도 합니다.

가격은 토큰당 달러($)입니다. 당신의 청구서는 (토큰당 달러) × (작업당 토큰 수) × (월간 작업 수)로 계산됩니다. Anthropic은 첫 번째 숫자는 동결했지만, 기본 설정(default)을 통해 두 번째 숫자를 높였습니다.

effort=high는 호출당 더 많은 추론 토큰 (reasoning tokens)을 의미합니다. 이것들은 출력 토큰 (output tokens)입니다. 출력 토큰은 5달러짜리 계측기가 아니라 25달러짜리 계측기 쪽의 영역입니다. 낮은 노력 (lower effort) 설정에서 4,000개의 출력 토큰으로 생각(thinking)을 처리하던 작업이 high 설정에서는 12,000개가 들 수 있습니다. 모델도 같고, 프롬프트 (prompt)도 같고, 토큰당 가격도 같지만, 청구 항목은 3배가 되는 것입니다.

이 논의를 정직하게 다루려면 숫자로 계산해 봐야 합니다. 당신이 고객 지원 분류 (support-triage) 제품을 운영한다고 가정해 봅시다. 한 달에 500,000번의 에이전트 호출이 발생하고, 각 호출에는 2,000토큰의 캐시된 프롬프트 (cached prompt)와 약 800토큰의 답변이 포함됩니다. medium 수준의 추론 예산(reasoning budget)을 기준으로, 호출당 총 1,500개의 출력 토큰이 사용된다고 가정하겠습니다. 출력 토큰 100만 개당 25달러($25/M)일 때, 출력 측 비용은 500,000 × 1,500 / 1,000,000 × $25 = $18,750/월이 됩니다. 이 호출들을 모두 high로 전환하면 추론 예산이 급증합니다. 호출당 4,000개의 출력 토큰이 사용된다고 가정해 봅시다. 동일한 산식: 500,000 × 4,000 / 1,000,000 × $25 = $50,000/월. 당신은 코드 한 줄도 바꾸지 않았습니다. 모델도 바꾸지 않았습니다. 아무것도 바꾸지 않았지만, 기본 설정이 당신도 모르게 바뀌었기 때문에 출력 비용은 약 1만 9천 달러에서 약 5만 달러로 뛰었습니다. 이 월 3만 1천 달러의 차이가 바로 이 글의 핵심 주제입니다.

현재 당신이 처한 상황은 다음과 같습니다:

제품에서 API를 통해 Opus를 실행하고 있습니다. 아무것도 배포하지 않았는데 단위 경제성 (unit economics)이 변했습니다. 이제 모든 고객 요청이 high effort로 기본 설정됩니다.
팀에서 Claude Code를 실행하고 있습니다. 모든 개발자의 모든 프롬프트가 이제 high effort로 기본 설정됩니다. 이를 인원수와 근무 일수로 곱해 보십시오.
Dynamic Workflows를 활성화하려던 참이었습니다. 수백 개의 하위 에이전트 (subagents)는 수백 개의 병렬 과금 스트림을 의미합니다. 기능을 켜기 전에 다음 섹션을 읽으십시오.
1분기에 Claude 예산을 승인한 CTO입니다. 그 예산은 4.7 버전의 기본 설정에 맞춰 산정되었습니다. 이제 그 예산은 틀렸습니다.

모델은 더 좋아졌습니다. 그 부분은 사실이며 저는 이를 옹호할 것입니다. 하지만 "더 좋아졌다"는 것은 "태스크당 비용이 더 비싸졌다"는 것과 함께 패키지로 제공되었으며, 헤드라인 너머를 읽지 않는 한 이 패키지는 눈에 보이지 않습니다.

메커니즘: 토큰 수를 변화시키는 세 가지 변화

순서대로 이해하십시오.

1. effort 파라미터는 다이얼이 달린 토큰 승수 (token multiplier)입니다.

effort는 추론 예산 (reasoning budget), 즉 모델이 답변을 확정하기 전까지 얼마나 오래 생각할지를 제어합니다. effort가 높을수록 더 많은 생각 토큰 (thinking tokens)을 사용하며, 어려운 작업에서 더 나은 답변을 내놓지만, 어렵든 사소하든 모든 작업에서 더 큰 출력 토큰 (output-token) 청구액이 발생합니다.

함정은 이제 high가 당신이 선택한 설정이 아니라, 당신이 시작하는 바닥 (floor)이라는 점입니다:

# 4.8 동작 방식: high가 기본값입니다. 낮춰야 합니다.
client.messages.create(
    model="clalaude-opus-4-8",
...

"이 티켓을 다섯 가지 범주 중 하나로 분류하세요"라는 호출의 경우, high effort는 순전한 낭비입니다. 단 한 단어의 답변을 내놓기 위해 한 단락 분량의 추론 비용을 지불하고 있는 셈입니다. 반면 "이 마이그레이션 계획을 세우세요"라는 호출의 경우, 모든 토큰의 가치가 있습니다. 모델은 그 차이를 구분할 수 없습니다. 당신이 구분해야 합니다.

이러한 비대칭성이 핵심입니다. 어려운 작업(hard task)의 경우, 한계 추론 토큰(marginal reasoning tokens)은 실질적인 정확도 향상을 가져다줍니다. Anthropic이 기본 설정을 이 지점에 맞춰 튜닝한 이유도 바로 이것이며, 대부분의 '어려운' 작업에는 effort=high가 필요하다는 그들의 판단은 옳습니다. 하지만 실제 서비스 트래픽(production traffic)은 대부분 어려운 작업이 아닙니다. 대부분 분류(classify), 추출(extract), 라우팅(route), 요약(summarize)과 같은 작업들입니다. 이는 대량으로 발생하며 리스크는 낮은(low-stakes) 호출들로, 추가적인 추론이 정답을 바꾸는 경우는 1% 미만이지만 청구 금액은 100%의 경우에 모두 바뀝니다. 기본 설정은 어려운 5%의 호출에는 최적화되어 있지만, 그렇지 않은 95%의 호출에는 세금을 매기는 격입니다. 이는 연구용 데모(research demo)에는 괜찮은 기본 설정일지 모르나, 대량의 트래픽을 처리하는 제품(high-volume product)에는 끔찍한 설정이며, 이것이 바로 이 설정을 암시적(implicit)으로 남겨두어서는 안 되는 정확한 이유입니다.

2. 동적 워크플로우(Dynamic Workflows)는 토큰뿐만 아니라 작업(tasks)을 배가시킵니다.

단일 동적 워크플로우(Dynamic Workflow) 세션은 수백 개의 하위 에이전트(subagents)로 확장될 수 있습니다. 각 하위 에이전트는 자신만의 컨텍스트(context), 자신만의 추론 예산(reasoning budget), 자신만의 계측기(meter)를 가집니다.

작업 도중에 자신의 지침(instructions)을 업데이트하는 모든 장기 실행 에이전트 — 즉, 대부분의 프로덕션 에이전트 — 의 경우, 이는 계측기(meter)의 입력(input) 측면에서 실질적인 비용 절감입니다. 변경 로그(changelog)에 단 한 줄로 기재되어 있고 데모도 없기 때문에, 거의 아무도 이를 알아차리지 못할 것입니다.

반대 의견: "스마트한 기본 설정은 스마트하다"

합리적인 반론은 다음과 같으며, 아마 화요일쯤이면 팀원 중 누군가에게서 이 말을 듣게 될 것입니다:

"당신은 스마트한 기본 설정이 너무 스마트하다고 불평하고 있습니다. high 노력(effort)은 더 나은 답변을 제공하고, 모델이 버그를 배포할 확률을 4배 낮춰주며, 빠른 모드(fast mode)는 그 어느 때보다 저렴합니다. Anthropic은 품질을 위해 기본 설정을 조정했습니다. 중요하지 않은 작업에서 토큰 30% 절약을 위해 최적화하는 일을 멈추세요."

이 말이 틀린 것은 아닙니다. 많은 팀에게 있어 올바른 선택은 high 설정을 유지하고 더 나은 결과물을 내놓는 것입니다. 만약 당신의 Opus 지출이 월 400달러라면, 노력(effort) 설정을 튜닝하는 것은 엔지니어의 오후 시간을 낭비하는 일입니다. 투입 대비 효과(the juice isn't worth the squeeze)가 낮으며, 품질 향상은 공짜 레버리지나 다름없기 때문입니다.

그리고 정직성(honesty)의 개선은 마케팅용 미사여구가 아닙니다. "자신의 코드 결함을 통과시킬 확률이 4배 낮아진다"는 변화는 새벽 2시에 발생하는 장애(incident)가 줄어드는 결과로 나타나며, 이는 대부분의 팀에게 토큰 차이보다 훨씬 더 가치 있는 일입니다. 만약 high 노력이 그러한 정직성 이득을 만들어내는 요소 중 하나라면 — 더 많은 추론(reasoning)이 모델이 자신의 실수를 잡아내는 방식이므로 거의 확실히 그렇습니다 — 토큰을 아끼기 위해 코드 리뷰 경로의 노력(effort) 설정을 낮추는 것은 '푼돈 아끼려다 큰 사고를 치는(penny-wise and incident-foolish)' 격입니다. 반대 의견에도 일리가 있습니다. 비싼 기본 설정을 원하는 경로가 분명히 존재하며, 코드 생성(code generation)이 바로 그 명백한 사례입니다.

하지만 두 가지 사실은 변하지 않습니다. 첫째, 벤치마크 수치 — Terminal-Bench에서 86.5%, OSWorld에서 84% — 는 Anthropic의 작업 혼합(task mix)에 대한 Anthropic의 평가(evals) 결과입니다. 이는 테스트를 해야 할 이유이지, 신뢰해야 할 이유는 아닙니다. "직접 평가(evals)를 수행하기 전까지는 주장을 확인되지 않은 것으로 취급하라"고 말했던 출시 전의 회의론자들은 그때도 옳았고, 지금도 옳습니다. 변한 것은 오직 그 주장들이 공식화되었다는 점뿐입니다. 둘째, "기본 설정이 똑똑하다"와 "기본 설정이 무료다"는 서로 다른 문장입니다. 기본 설정은 똑똑합니다. 하지만 무료는 아닙니다. 피해를 보는 팀은 첫 번째 문장을 듣고 두 번째 문장이라고 가정해 버리는 팀들입니다.

플레이북: 다섯 가지 단계, 순서대로

제가 월요일에 할 일입니다.

1. 앱 단위가 아닌 작업 클래스(task class)별로 effort 고정하기

high가 암묵적으로 설정되도록 두는 것을 멈추세요. 작업의 가치에 따라 effort를 라우팅(route)하십시오:

EFFORT_BY_TASK = {
    "classify":    "low",     # 한 단어 답변, 추론(reasoning) 불필요
    "extract":     "low",
...

이 표 하나를 만드는 것이 이 포스트에서 가장 레버리지(leverage)가 높은 변화입니다. 대부분의 프로덕션 트래픽은 classify/extract/summarize이며, 이들 대부분은 high 설정이 필요하지 않습니다. 클래스별로 effort를 고정하는 것이 실제로 청구 금액을 움직이는 지점입니다.

일주일의 시간을 아껴줄 두 가지 참고 사항이 있습니다. 첫째, .get()의 기본값을 high가 아닌 medium으로 설정하세요. 그래야 누군가 등록하는 것을 잊은 작업 유형이 "비싼" 설정이 아닌 "합리적인" 수준으로 저하됩니다. 암묵적인 실패 모드(failure mode)는 저렴해야 합니다. 둘째, 지출 추적에 사용하는 도구에 토큰 사용량과 함께 task_type을 기록하세요. 청구 금액이 변했을 때, 오후 내내 조사하는 것이 아니라 단 한 번의 쿼리로 "어떤 작업 클래스가 금액을 변화시켰는가"에 답할 수 있어야 합니다. 비용 급증 상황에서 살아남는 팀은 지출을 작업 유형별로 귀속(attribute)시킬 수 있는 팀입니다. 그렇지 못한 팀은 비용 급증뿐만 아니라 조사 비용까지 지출하게 됩니다.

2. 동적 워크플로(Dynamic Workflows)를 활성화하기 전에 상한선(Cap) 설정하기

서브에이전트 팬아웃(subagent fan-out)을 기저 사례(base case)가 없는 재귀 함수(recursive function)처럼 취급하십시오. 프로덕션(prod) 환경에서 실행되기 전에 상한선(ceiling)을 설정해야 합니다. 서브에이전트의 수를 제한하고, 파일 세트의 범위를 명시적으로 지정하며, 서브에이전트별 토큰 지출을 기록하여 통제 불능 상태가 청구서가 아닌 대시보드에서 먼저 나타나도록 하십시오. 만약 사용 중인 하네스(harness)가 아직 서브에이전트 상한 설정을 지원하지 않는다면, 해당 기능이 추가될 때까지 프로덕션 자격 증명(production credentials)에서 동적 워크플로(Dynamic Workflows)를 활성화하지 마십시오.

첫 실행 전에 대략적인 계산(back-of-envelope)을 해보십시오. 200개의 서브에이전트가 팬아웃(fan-out)되고, 각 서브에이전트가 high 설정에서 약 30,000 토큰의 컨텍스트(context)와 추론(reasoning) 비용을 소모한다면, 단 한 번의 세션에 600만 토큰이 소모됩니다. 입력/출력 비율에 따라 다르겠지만, 인간의 단 한 번의 "실행(go)"에 30달러에서 150달러 사이의 비용이 발생한다고 볼 수 있습니다. 만약 이 작업이 엔지니어에게 이틀치 업무를 맡겼어야 할 400개의 파일을 마이그레이션(migrate)한 것이라면 저렴한 비용입니다. 하지만 단일 에이전트와 grep 명령어로 처리할 수 있었던 단순 검색 작업이었다면 이는 재앙(fire)입니다. 이 기능은 전동 공구처럼 가격이 책정되어 있으며, 전동 공구가 잘못된 작업에 사용될 때 손가락을 다치게 하듯 이 기능도 마찬가지입니다. 상한선을 "원하는 만큼"이 아니라, 진정으로 독립적인 작업 단위의 수로 설정하십시오.

3. 느낌(vibes)이 아닌 산술(arithmetic)로 패스트 모드(fast mode)를 결정하기

패스트 모드(fast mode)는 속도는 2.5배 빠르지만 가격은 표준 가격의 2배입니다. 문제는 추상적으로 "패스트 모드가 가치가 있는가"가 아닙니다. 질문은 "이 특정 지연 시간(latency)이 토큰 비용 2배만큼의 가치가 있는가"가 되어야 합니다. 개발자가 작업이 막혀 기다리고 있는 인터랙티브(interactive) 코딩 세션의 경우, 15만 달러 연봉을 받는 엔지니어의 작업을 2.5배 빠르게 재개하기 위해 2배의 비용을 지불하는 것은 당연히 가치가 있습니다. 엔지니어의 시간당 총비용(loaded hourly rate)이 토큰 비용의 차이보다 압도적으로 크기 때문에 계산 결과는 명확합니다. 반면, 아무도 지켜보지 않는 야간 배치 작업(overnight batch job)에서 아무도 체감할 수 없는 속도를 위해 2배의 비용을 지불하는 것은 돈을 불태우는 것과 같습니다. 워크로드에 interactive 또는 batch 태그를 달고, 빠른 반응 속도를 선호하는 개발자의 느낌이 아니라 그 태그에 따라 결정하도록 하십시오.