Claude Adaptive Thinking,
절약된다고요? 이 수치 먼저 보세요

Extended Thinking에서 Adaptive Thinking으로 바꾸면 비용이 줄어든다 — 맞기도 하고, 틀리기도 한 말입니다. display: “omitted”로 thinking 블록을 숨겨도 토큰 비용은 100% 청구됩니다. Anthropic 공식 문서에 직접 나와 있는 내용인데, 이 부분을 모르고 마이그레이션하면 청구서에서 처음 확인하게 됩니다.

Claude Adaptive Thinking이란 무엇인지, 한 문장으로

Claude Adaptive Thinking은 2026년 2월 5일, Opus 4.6 출시와 함께 공개된 새로운 추론 방식입니다. 핵심은 간단합니다. 기존 Extended Thinking에서는 개발자가 직접 budget_tokens를 설정해서 “이 문제에 최대 1만 토큰까지 생각해”라고 지시했다면, Adaptive Thinking에서는 Claude가 스스로 “이게 복잡한 문제인지 아닌지”를 판단해서 생각 깊이를 결정합니다.

API 호출 파라미터 한 줄 차이입니다. thinking: {"type": "adaptive"}를 넣으면 됩니다. 베타 헤더도 필요 없습니다. 이게 공식 권장 방식이고, 기존 type: "enabled"는 Opus 4.6에서 공식으로 deprecated 처리됐습니다. 향후 모델에서는 제거될 예정이라고 Anthropic이 명시했습니다.

지원 모델: Claude Opus 4.6 (anthropic.claude-opus-4-6-v1), Claude Sonnet 4.6 — 이전 세대(4.5 계열)는 지원하지 않습니다. (출처: AWS Bedrock 공식 문서)

Extended Thinking과 어디가 다른지 직접 비교

“그냥 이름만 바뀐 거 아닌가?” — 처음 보면 그렇게 느껴질 수 있습니다. 실제로는 동작 구조가 4가지 포인트에서 달라집니다.

인터리브 사고(Interleaved Thinking)가 자동으로 켜진다는 부분이 에이전트 워크플로우에서 실질적인 차이를 만듭니다. 기존엔 Claude가 도구 A를 호출하고 나면 그 결과를 그냥 받아 다음 단계로 넘어갔습니다. Adaptive Thinking에서는 도구 호출 사이사이에 Claude가 다시 생각할 수 있습니다. 오류가 줄어드는 이유가 여기에 있습니다.

다만 이 자동 사고가 토큰 소비를 올리는 요인이기도 합니다. Claude Code 사용자들이 3월 말 Reddit에서 “같은 작업인데 토큰이 훨씬 빠르게 닳는다”고 보고한 배경이 여기에 있습니다.

effort 4단계, 언제 어떤 걸 써야 하는지

Adaptive Thinking에서 생각 깊이를 조정하는 유일한 레버가 effort 파라미터입니다. 4단계가 있는데, 중요한 전제를 먼저 짚고 넘어갈 필요가 있습니다.

Anthropic 공식에서 Sonnet 4.6 사용 시 기본 medium effort 권장이라고 명시합니다. 속도·비용·품질의 균형점으로 medium이 적합하다는 판단입니다. Opus 4.6은 고기본값(high)이 설정되어 있어서, 아무 설정 없이 Opus를 쓰면 이미 “항상 깊이 사고” 모드가 돌아갑니다.

Artificial Analysis의 벤치마크 결과를 보면 Opus 4.6은 표준 작업에서 약 5,800만 출력 토큰을 기록했고, Opus 4.5는 같은 작업에서 약 2,900만이었습니다. 정확히 2배 차이입니다. (출처: Artificial Analysis, 2026.02) 이걸 API 가격으로 환산하면 Opus 4.6 출력 토큰 단가 $25/1M 기준, 같은 작업에서 이전 모델 대비 약 $725 더 청구됩니다.

display: “omitted” 써도 비용은 줄지 않습니다

Adaptive Thinking에는 thinking 블록을 응답에서 숨기는 옵션이 있습니다. thinking: {"type": "adaptive", "display": "omitted"}를 설정하면 API 응답에 thinking 텍스트가 빠집니다. 응답 전송 크기가 줄고 지연(latency)이 줄어드는 효과는 있습니다.

한 가지 더 알아두면 좋은 부분이 있습니다. Claude 4.6 모델은 thinking 블록을 기본적으로 요약본으로 반환합니다. 전체 thinking 텍스트를 받으려면 Anthropic 영업팀에 별도 요청이 필요합니다. 청구는 요약본 기준이 아니라 내부 전체 thinking 토큰 기준입니다. 청구서와 실제 보이는 토큰 수가 다를 수 있는 이유입니다.

같은 작업, effort별 실제 비용 차이 (Sonnet 4.6 기준)

코드 스타일 검사 동일 작업 기준. 단순 작업에서 low effort는 high 대비 약 83% 비용 절감. (출처: APIYI 가이드, 2026.03.21)

100개 파일을 처리하는 배치 작업에 effort: high를 기본으로 놔두면 $5.3이고, low로 맞추면 $0.9입니다. 작업 성격에 맞게 effort를 나눠 쓰는 게 유의미한 절감 방법입니다.

Claude Code에서 /effort 명령어 쓰는 법

2026년 3월 업데이트 이후 Claude Code 터미널에서 /effort 명령어를 직접 입력할 수 있습니다. 코드를 수정하지 않아도 현재 세션의 사고 깊이를 실시간으로 바꿀 수 있습니다.

# 일상적인 코딩 작업
/effort medium
# 코드 리뷰, 복잡한 디버깅
/effort high
# 아키텍처 설계, 보안 감사 (Opus 4.6 전용)
/effort max
# 오타 수정, 포맷팅, 간단한 Q&A
/effort low

한 가지 주의할 부분이 있습니다. MEMORY.md 파일에 /effort를 고정으로 써 넣는 방법을 택하는 경우가 있는데, 이건 의도한 방식이 아닙니다. MEMORY.md는 전역 지속 규칙용이고, effort는 작업 단위로 변경하는 게 설계 의도입니다. 고정해 놓으면 간단한 작업에도 high effort가 계속 적용됩니다.

실무에서 써보면 60~70% 작업은 low, 20~30%는 medium, 5~10%만 high로 배분하는 패턴이 합리적이라는 분석이 나옵니다. (출처: Medium — Claude Opus 4.6 and the /effort Trap, 2026.02.14) 이 비율에서 벗어나 대부분 medium이나 high를 유지하면 할당 한도가 3~5배 빠르게 소진됩니다.

마이그레이션 시 프롬프트 캐시가 끊기는 이유

Extended Thinking에서 Adaptive Thinking으로 전환할 때 놓치기 쉬운 포인트가 있습니다. enabled 모드와 adaptive 모드를 같은 세션에서 혼용하면, 메시지 수준의 프롬프트 캐시 중단점이 무효화됩니다. 그 결과 이전까지 캐시로 절약하던 비용이 다시 발생합니다.

권장 마이그레이션 순서는 간단합니다. 기존 코드에서 thinking: {"type": "enabled", "budget_tokens": N}을 찾아 아래처럼 바꾸면 됩니다.

# ❌ 기존 방식 (Deprecated)
thinking={"type": "enabled", "budget_tokens": 10000}
# ✅ 권장 방식 (Adaptive)
thinking={"type": "adaptive"}
output_config={"effort": "medium"}  # 토큰 예산 10000 ≈ medium

budget_tokens 값을 effort 레벨로 대응시키면 대략 이렇습니다. 5,000 이하 → low, 10,000 전후 → medium, 30,000 전후 → high, 100,000 이상 → max. 정확한 1:1 대응은 아니지만 마이그레이션 시 출발점으로 쓰기에 충분합니다. 반드시 테스트 환경에서 출력 품질을 먼저 비교하는 걸 권장합니다.

자주 나오는 질문 5가지

마치며 — 정리하면 이렇습니다

Claude Adaptive Thinking은 분명히 개선된 구조입니다. budget_tokens를 추측해야 했던 번거로움이 사라지고, 에이전트 워크플로에서 인터리브 사고가 자동으로 켜지는 건 실질적인 이점입니다. 그런데 쓰기 전에 두 가지는 미리 알고 들어가는 게 좋습니다.

첫째, Opus 4.6은 기본값(high effort)에서 이미 4.5 대비 2배 출력 토큰을 씁니다. “업그레이드”했더니 비용이 올랐다면, 업그레이드 탓이 아니라 effort 기본값 탓입니다. 둘째, display: “omitted”는 비용 절감 기능이 아닙니다. 진짜 절약 레버는 effort 파라미터입니다.

개인적으로는 일상적인 작업에서 Sonnet 4.6 + medium effort 조합이 가장 실용적이라고 생각합니다. Opus 4.6은 진짜 깊은 추론이 필요한 5~10% 작업에 아껴 쓰는 것이 합리적입니다. effort를 작업 단위로 바꿔주는 습관 하나만 들여도 Claude Code 할당량 소진 속도가 체감상 달라집니다.

본 포스팅 참고 자료

1. AWS Bedrock 공식 문서 — Adaptive Thinking
   https://docs.aws.amazon.com/ko_kr/bedrock/latest/userguide/claude-messages-adaptive-thinking.html
2. ClaudeLog — What is Adaptive Thinking in Claude Code
   https://www.claudelog.com/faqs/what-is-adaptive-thinking-in-claude-code/
3. APIYI — Claude Adaptive Thinking Mode API Guide (한국어)
   https://help.apiyi.com/ko/claude-adaptive-thinking-mode-api-guide-replace-extended-thinking-ko.html
4. Medium — Claude Opus 4.6 and the /effort Trap (Christoph Schweres, 2026.02.14)
   https://medium.com/rigel-computer-com/when-claude-code-opus-4-6-eats-your-quota-understanding-effort-08b4befcc4ff