빠른 비교
| 설정 | 성격 | 적합한 상황 |
|---|---|---|
| thinking 없음 | 직접 답변 중심 | 짧은 요약, 단순 분류 |
| adaptive thinking | 난이도에 따라 thinking 사용 | agentic coding, tool-heavy workflow |
effort: low | 속도와 비용 우선 | 대량 처리, 단순 질의 |
effort: medium | 균형점 | 일반 제품 기능 |
effort: high 이상 | 품질 우선 | 복잡한 추론, 장기 작업 |
| manual budget | 구형 모델 또는 하드 ceiling | 이전 extended thinking 흐름 |
{
"model": "claude-opus-4-7",
"thinking": { "type": "adaptive" },
"output_config": {
"effort": "medium"
}
}구조
Adaptive thinking은 요청마다 Claude가 thinking 필요 여부와 깊이를 동적으로 조절하는 방식입니다. 예전처럼 budget_tokens를 일일이 정하는 방식보다, 모델과 workload가 thinking 양을 조절하도록 맡기는 쪽에 가깝습니다.
effort는 thinking token만이 아니라 응답 전체의 token 사용 성향에 영향을 주는 제어값입니다. 설명, tool call, function argument, thinking이 모두 더 자세해지거나 더 간결해질 수 있습니다.
낮은 effort
-> 빠름, 저렴함, 단순 작업에 적합
높은 effort
-> 느릴 수 있음, 더 깊은 검토, 복잡한 작업에 적합복잡한 tool workflow에서는 tool 결과를 받은 뒤 다시 평가하고 다음 행동을 고르는 능력이 중요합니다. 이때 adaptive thinking과 명확한 작업 기준을 함께 쓰면, 단순히 "자세히 생각해"라고 지시하는 것보다 운영하기 쉽습니다.
선택 기준
| 상황 | 권장 |
|---|---|
| latency가 가장 중요함 | 낮은 effort부터 eval |
| 코딩, multi-step tool use | adaptive thinking과 medium 이상 |
| 고위험 판단 또는 복잡한 분석 | high 이상을 별도 평가 |
| token 비용이 예측 가능해야 함 | 낮은 effort 또는 구형 budget 전략 검토 |
| 쉬운 요청에서 thinking이 과함 | prompt로 thinking 사용 조건 제한 |
| 모델을 바꿈 | 지원되는 thinking 방식과 effort 의미 재확인 |
중요한 점은 effort를 감으로 정하지 않는 것입니다. 같은 test case로 low, medium, high를 비교해 품질과 비용이 실제로 어떻게 바뀌는지 봐야 합니다.
주의할 점
effort는 엄격한 token 상한이 아닙니다. 비용과 latency를 반드시 제한해야 하는 시스템에서는 max_tokens, timeout, 재시도 정책, 요청 분리까지 함께 설계해야 합니다.
모델별 thinking 지원 방식은 빠르게 바뀔 수 있습니다. budget_tokens 기반 extended thinking을 쓰던 구현은 최신 모델에서 adaptive thinking과 effort로 옮길 수 있는지 공식 문서 기준으로 다시 확인하세요.
참고 링크
2 sources