추론모델 (reasoning models / thinking)

"이 요청에 thinking 을 켜야 하나, 켜면 돈·지연이 얼마나 붙나, 프롬프팅은 뭐가 달라지나" 를 판단할 때 연다.

추론모델은 최종 답을 내기 전에 내부 추론 토큰(reasoning/thinking token)을 먼저 생성한다. 이 토큰은 대부분 사용자에게 숨겨지지만 컨텍스트 공간을 차지하고 output 토큰으로 과금된다. 표준모델과의 선택·프롬프팅 차이는 reasoning-vs-standard-models 로 분리했다 — 여기서는 추론모델 "안"의 동작을 다룬다.

뭐가 다른가

Claude 의 thinking 은 adaptive 다 (verified 2026-07). 모델이 요청마다 생각 여부와 깊이를 스스로 정한다. 단순 사실 질문은 thinking 없이 바로 답하고, 어려운 과제만 깊게 추론한다. 그래서 같은 대화 안에 thinking 있는 턴과 없는 턴이 섞인다 — "모든 assistant 턴이 thinking 블록으로 시작한다" 고 가정하는 앱 로직은 깨진다. tool use 사이의 interleaved thinking 도 자동이라 별도 베타 헤더가 필요 없다.

claude-opus-5 는 thinking 이 기본 ON 이다(thinking 필드 생략 = adaptive). Opus 4.8/4.7 은 생략하면 OFF 였다 — 뒤집힌 지점이니 주의 (verified 2026-07). 상세 모델별 차이는 claude-family 참고.

thinking 토큰: 과금과 가시성

과금 대상은 3가지다. (1) 생각하며 쓴 토큰(output 으로 과금), (2) 컨텍스트에 남은 이전 턴 thinking 블록(input 으로 과금), (3) 표준 텍스트 출력.

가장 헷갈리는 함정: 청구되는 output 토큰 수 ≠ 응답에서 보이는 토큰 수. "You are billed for the full thinking process, not the thinking content visible in the response." thinking.display 기본값은 "omitted" 라 요약조차 안 보이지만(보이게 하려면 display: "summarized" 명시), 표시 여부와 무관하게 내부에서 생성한 full thinking 토큰 전부가 과금된다 (verified 2026-07). 원본 chain of thought 는 절대 반환되지 않고 요약만 온다.

실제 사용량은 응답 usage 로 확인한다:

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    messages=[{"role": "user", "content": "..."}],
)
u = resp.usage
print(u.output_tokens, u.output_tokens_details.thinking_tokens)
# thinking_tokens ≤ output_tokens. 스트리밍이면 최종 message_delta 에만 채워진다.

OpenAI 계열도 구조가 같다(reasoning 토큰이 output 으로 과금, usage.output_tokens_details 로 확인). OpenAI 는 reasoning+output 합산으로 최소 25,000 토큰 예약을 권고한다 [aggregator][MED]. 즉 thinking 없을 때 기준으로 잡은 max_tokens 는 하드 과제에서 자주 너무 작다.

adaptive thinking 과 effort

adaptive 에서는 thinking 토큰 budget 을 직접 못 박지 않는다. 두 레버로 비용을 통제한다.

effort 는 thinking 객체 밖 output_config 에 들어가고 기본값은 high 다 (verified 2026-07).

claude-opus-5 는 low/medium 이 유난히 강해서 비용·지연 절감 1순위 레버다 (verified 2026-07). 덜 생각하게 하려면 프롬프트 문구를 손대기 전에 effort 를 먼저 낮춰라 — 문구는 민감하고 불안정하지만 effort 는 calibrated control 이다. OpenAI 의 reasoning.effort 도 같은 다이얼이되, "품질을 되찾는 주된 수단이 아니라 튜닝 노브" 로 본다 [aggregator][MED].

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=16000,
    output_config={"effort": "low"},   # thinking 은 생략 → adaptive 기본
    messages=[{"role": "user", "content": "..."}],
)

함정 — 프롬프트 캐싱 무효화: effort 값은 프롬프트에 렌더링되므로 요청 간 effort 를 바꾸면 cache breakpoint 가 깨진다(실측상 high→medium 변경 시 cache 재생성, cache_read 0). 대화 수명 동안 effort 를 고정하라. per-message steering(최신 user 메시지에 "간단히 답해" 같은 문구 추가)은 캐시를 깨지 않는다. 캐싱 자체는 prompt-caching 참고.

추론이 도움되는 작업 vs 손해인 작업

손해 케이스의 공통점은 추론이 품질을 안 올리는데 토큰만 배로 나가는 것이다. adaptive/effort 의 요점이 바로 이거다 — 쉬운 과제는 적게, 어려운 과제만 깊게 해서 불필요 연산을 피한다. 다만 thinking 을 너무 억누르면 추론이 도움 되는 과제에서 품질이 떨어지니, 워크로드에서 실제로 측정한 뒤 배포하라.

프롬프팅이 뒤집히는 지점: 표준모델에 먹히던 "단계별로 생각해봐(chain-of-thought)" 같은 유도는 추론모델에선 불필요하거나 역효과다 — 이미 내부에서 하고 있고, 억지 유도는 토큰만 늘린다. 표준↔추론 선택 기준과 프롬프팅 차이는 reasoning-vs-standard-models 에서 정리한다.

지연시간 설계 함정

• 첫 토큰이 느리다. thinking 이 끝나야 답이 시작되므로 스트리밍을 켜도 사용자는 초반 공백을 본다. 지연 민감 경로엔 effort 를 낮추거나 표준모델을 써라.
• stop_reason: "max_tokens" 가 뜨면 둘 중 하나다. 추론이 정말 필요했으면 max_tokens 를 올리고, over-think 였으면 effort 를 낮춰라. thinking 이 max_tokens 를 소모한다는 걸 잊지 마라 — 넉넉히 잡아라.
• 긴 추론은 batch 로. 32k 급 추론이 필요한 요청은 동기 호출이 타임아웃날 수 있어 배치 처리가 안전하다.
• 비용 예측 불가를 전제로 설계하라. adaptive 라 같은 프롬프트도 요청마다 thinking 량이 다르다. 토큰 예산은 output_tokens_details.thinking_tokens 로 사후 계측해 잡는다. 토큰·컨텍스트 기본은 tokens-and-context-windows 참고.

참고

• reasoning-vs-standard-models — 표준↔추론 선택 기준과 프롬프팅이 뒤집히는 지점(짝 문서)
• tokens-and-context-windows — thinking 토큰이 소모하는 컨텍스트·과금의 토대
• context-engineering — long-horizon 에이전트에서 추론+컨텍스트 예산 배분
• prompt-caching — effort 변경이 캐시를 깨는 상호작용
• model-choice-decision-guide — 과제별 모델·effort 조합 선택
• claude-family — 모델별 thinking 기본값·effort 지원 차이

출처: adaptive thinking·effort·과금은 Anthropic 1차 [HIGH] (규격서 §7 대조), reasoning 토큰 예약·effort 노브는 OpenAI [aggregator][MED]. 원본 → 2026-07-25-concepts-core