리즈닝 모델의 딜레마

같은 모델 이름을 단 두 번의 호출이 — 한쪽은 0.8초에 끝나고 다른 쪽은 47초가 걸리고, 비용도 한 자리 수가 다른 적이 있어요. "토큰 수가 다르겠지" 정도의 짐작으로 넘기면 곤란합니다. 추론 모델은 응답 본문에 보이지 않는 곳에서 수십~수백 스텝을 혼자 시뮬레이션한 뒤 답을 내놓고, 그 시뮬레이션 전부에 과금돼요.

추론 모델(Reasoning Model) — GPT-5.4, DeepSeek R1-0528, Gemini 2.5 Pro / 3.1 Pro, Claude Extended / Adaptive Thinking — 은 일반 모델과 다르게 작동합니다.

강력한 추론 능력을 얻는 대신 컨텍스트 소비·비용·지연 시간 세 가지가 함께 증가해요. 이것이 추론 모델의 딜레마예요.

본문 §2에서 "추론 모델을 언제 꺼내야 하는가" 라는 판단 기준을 언급했는데, 이 부록에서는 그 판단에 필요한 내부 구조와 비용 모델을 풀어 놓아요.

외부 하네스 vs 내재화된 하네스

일반 모델은 피드백 루프가 외부에 있어요:

추론 모델은 그 루프를 내부로 흡수했어요:

하네스의 피드백 루프가 뇌 안으로 들어간 구조예요. 외부에서 보면 한 번의 호출처럼 보이지만, 내부에서는 수십~수백 스텝의 자기 검토가 일어나고 있습니다.

두 구조를 나란히 그리면 차이가 한눈에 들어와요.

여기서 중요한 질문: 단순히 루프가 내부로 들어간 것뿐인가, 아니면 추론 수준 자체가 달라지는가?

답은 학습 방식이 다르기 때문에 수준 자체가 달라진다예요.

외부 하네스는 LLM이 루프 구조 설계에 관여하지 않아요. 사람이 미리 짜둔 tool schema(read_file, run_code 등)에 LLM이 끼워넣어지는 거예요. 어떤 중간 단계를 밟을지는 하드코딩되어 있습니다.

추론 모델은 RLVR(Reinforcement Learning with Verifiable Rewards — 정답 검증이 가능한 보상으로 강화학습) 방식으로 학습돼요:

1. 모델이 <thinking>...</thinking> → 최종 답을 자유롭게 생성
2. 최종 답만 reward signal로 평가 (수학 문제면 정답 여부, 코딩 문제면 테스트 통과 여부)
3. 올바른 답으로 이어진 thinking 체인이 강화됨

schema 없이 임의의 중간 추론을 생성하면서, 어떤 intermediate thought가 올바른 답으로 이어지는지를 RL로 스스로 학습해요. DeepSeek R1 의 공개 논문(arXiv 2501.12948) 이 보여준 구체적 사례 — 학습 도중 모델이 스스로 "Wait, wait. Wait. That's an aha moment I can flag here." (의역: "잠깐, 잠깐. 잠깐. 여기 표시해 둘 만한 aha moment다.") 같은 자기 점검 토큰을 직접 뱉어내는 "aha moment" — 가 이 학습 방식이 임의의 중간 전략을 발견할 수 있다는 가장 직접적인 증거예요. "백트래킹", "반례 탐색", "단계적 검증" 같은 전략은 사람이 설계한 게 아니라 모델이 reward를 보며 발견한 것입니다.

여기서 또 하나 깜짝 사실 — Adaptive Thinking 모드는 모델이 스스로 "더 생각하지 말 것"을 학습한 결과예요. 사람이 budget_tokens 를 손으로 정해주는 Manual 방식보다, 모델이 난이도에 맞춰 thinking 길이를 자율 조절하는 쪽이 평균 정답률이 높다고 보고됐어요 (Anthropic 공식 권장 근거 — bimodal·long-horizon agentic 워크로드 특정 조건). overthinking 곡선을 모델이 직접 보고 회피한다는 뜻이에요.

비유로 풀면 — 외부 하네스는 시험관이 풀이 칸을 미리 정해 둔 답안지예요. 학생은 정해진 칸에 정해진 순서대로 적기만 하면 됩니다. RLVR 추론 모델은 빈 종이 한 장만 받은 학생이에요. 풀이 과정을 어떻게 전개할지 — 가설을 먼저 세울지, 반례부터 찾을지, 케이스로 쪼갤지 — 시행착오를 거쳐 스스로 익힙니다. 같은 정답을 내더라도, 후자 쪽이 처음 보는 변형 문제에 대응하는 폭이 넓어요.

왜 내부 Chain-of-Thought가 효과적인가

"생각하는 척" 출력이 왜 실제로 성능을 높일까요?

핵심은 추론을 위한 연산 예산(compute budget)을 늘린다는 것이에요. 트랜스포머는 레이어 수가 고정되어 있어, 단일 forward pass에서 쓸 수 있는 연산량에 물리적 상한이 있어요. <thinking> 토큰을 생성하면:

1. 각 토큰 생성이 하나의 forward pass
2. N개의 thinking 토큰 = N번의 forward pass
3. 단계마다 이전 토큰들을 KV 캐시로 참조하며 "생각"을 이어감

결과적으로 test-time compute를 수직 확장합니다. 학습 시 고정된 파라미터 수에 관계없이, 추론 단계에서 더 많은 계산을 투입할 수 있어요. AlphaGo가 MCTS(Monte Carlo Tree Search — 가능한 수를 무작위로 끝까지 시뮬레이션해 보는 탐색)로 탐색 깊이를 늘린 것과 같은 원리예요.

여기서 한 가지 깜짝 사실 — thinking 토큰을 길게 쓴다고 정답률이 단조 증가하지는 않아요. 일정 지점을 넘으면 정확도가 도리어 떨어지는 "overthinking" 구간이 관측됩니다. 모델이 이미 옳은 답을 찾아 놓고도 자기 의심을 반복하다가 잘못된 길로 빠지는 식이에요. Anthropic 이 Adaptive Thinking 을 미는 이유 중 하나가 이 구간을 모델이 자율적으로 회피하기 때문입니다.

연산 예산과 정답률을 도식화하면 이런 곡선이 돼요.

곡선이 한쪽으로만 단조롭게 오르지 않는다는 점이 추론 모델 운영의 핵심 함정이에요.

숨겨진 비용

일반 모델에 <thinking> 흉내를 내게 시키면 어떻게 될까요? 속마음이 전부 텍스트로 출력되어 KV 캐시를 빠르게 잠식해요.

추론 모델 자체도 마찬가지예요. <thinking> 토큰은 사용자 눈에는 안 보이지만 컨텍스트 윈도우를 빠르게 소진합니다.

추가 주의 — Summarized Thinking의 과금 구조

Claude 4 계열은 기본값으로 Summarized Thinking을 반환해요. 응답에는 요약본만 노출되지만, 과금은 원본 thinking 토큰 전부에 대해 이루어집니다. Opus 4.7은 한 단계 더 나아가 display 기본값이 "omitted" 여서 thinking 블록의 thinking 필드가 아예 비어 있어요 (요약조차 안 보여줌). 응답 길이만 보고 비용을 계산하면 크게 과소평가합니다.

추론 모델은 "단발성 깊은 분석"에 써요. 루틴 작업을 추론 모델에 맡기는 것은 스캘펠로 나무를 베는 격입니다.

Thinking Effort 조절 — Claude 4 계열

Claude 4 계열에서 thinking 을 쓰는 방법은 두 가지예요. 하나는 Adaptive Thinking (Claude가 문제 난이도를 보고 알아서 생각량 결정), 다른 하나는 Manual Thinking (사용자가 예산 직접 지정). 2026-04 기준 공식 권장은 Adaptive 쪽이에요.

모델별 지원 현황

공식 문서가 Adaptive를 미는 이유는 bimodal 태스크와 long-horizon agentic workflow에서 고정 budget_tokens 보다 평균 품질이 높기 때문이에요. 에이전트 환경에서는 한 턴이 얼마나 어려울지 미리 모르므로, 예산을 고정하는 것보다 모델이 난이도를 보고 할당하는 편이 낫습니다.

Adaptive Thinking 기본 사용법

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16000,
    thinking={"type": "adaptive", "effort": "high"},   # effort: low | medium | high | max
    messages=[{"role": "user", "content": "Prove that sqrt(2) is irrational."}],
)

for block in response.content:
    if block.type == "thinking":
        print("[thinking]", block.thinking[:200], "...")
    elif block.type == "text":
        print("[answer]", block.text)

effort 는 생각량에 대한 소프트 가이드예요:

OpenAI GPT-5.x 의 xhigh 레벨은 §"Thinking Effort 조절" 의 공급자별 평행 비교 표에서 다뤄요 — Anthropic Adaptive Thinking 에는 같은 이름의 레벨이 없어요.

Opus 4.7의 display 기본값이 "omitted" 라서 위 코드에서 block.thinking 이 비어서 출력될 수 있어요. 요약이라도 보려면 thinking={"type": "adaptive", "display": "summarized"} 로 명시적으로 요청해야 합니다.

Manual Thinking (Sonnet 4.6 이하 레거시)

Sonnet 4.6 / Opus 4.6 에서는 아직 budget_tokens 방식이 동작해요 (deprecated). 비용을 정확히 상한 제어해야 하는 워크로드용입니다.

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000,   # max_tokens 보다 작아야 함
    },
    messages=[{"role": "user", "content": "Prove that sqrt(2) is irrational."}],
)

공식 제약은 budget_tokens < max_tokens 하나뿐이에요 (interleaved thinking을 쓰면 이 상한도 컨텍스트 윈도우까지 늘어남). Opus 4.7에서는 이 방식이 400 에러로 거부됩니다 — Adaptive로 마이그레이션해야 해요.

Thinking Effort 조절 — 공급자별 평행 비교

세 주요 공급자(OpenAI·Anthropic·Google) 모두 thinking을 외부에서 조절할 수 있는 파라미터를 제공해요. 그런데 이름·단위·기본값이 전부 달라서, 한 공급자에서 익힌 감각을 다른 공급자에 그대로 옮기면 비용이 튀거나 품질이 떨어집니다. 한 표에 정리하면 이래요.

Opus 4.7 특이 사항 — thinking: {type: "enabled", budget_tokens: ...} 형식의 manual thinking 블록은 Opus 4.7에서 400 에러를 반환해요. Opus 4.7은 adaptive thinking(thinking: {"effort": "low|medium|high|max"})만 받아들입니다. manual 블록이 필요하면 Sonnet 4.6 이하 또는 Haiku 4.5 이하를 써야 해요.

OpenAI GPT-5.4 — reasoning.effort

from openai import OpenAI
client = OpenAI()

response = client.responses.create(
    model="gpt-5.4",
    input="Prove that sqrt(2) is irrational.",
    reasoning={"effort": "high"}   # none / low / medium / high / xhigh
)

xhigh로 올리면 긴 프롬프트에서 thinking 토큰이 단발 요청당 20K 토큰까지 쉽게 쌓여요. 토큰 단가는 바뀌지 않지만 요청당 비용이 수직 상승합니다.

Google Gemini 3.1 Pro — thinking_level

from google import genai
client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.1-pro",
    contents="Prove that sqrt(2) is irrational.",
    config={"thinking_level": "HIGH"}   # LOW / MEDIUM / HIGH
)

HIGH에서 "Deep Think Mini" 가 자동 활성됩니다. 과거의 thinking_budget (정수) 도 backward compat로 지원되지만 thinking_level 사용이 권장돼요.

Anthropic Claude Opus 4.7 — thinking.effort + task_budget

Anthropic 쪽은 위 Adaptive Thinking 기본 사용법 절에서 다룬 형태와 동일해요. 다만 4.7에서 새로 들어온 task_budget은 기존 budget_tokens와 개념이 다릅니다 — thinking만이 아니라 전체 에이전트 루프 (thinking + tool call + tool result + final output) 의 토큰 총량을 상한으로 지정해요. 개별 thinking 단계를 제어하기보다 전체 비용 상한을 걸어두는 방식이에요.

import anthropic
client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-7",
    max_tokens=16000,
    thinking={
        "type": "adaptive",
        "effort": "high",          # low / medium / high / max
        "display": "summarized"
    },
    task_budget=30000,             # thinking + tool + output 합산 상한
    messages=[{"role": "user", "content": "Prove that sqrt(2) is irrational."}]
)

세 공급자 모두 "레벨" 형태로 수렴하고 있지만, 레벨 한 단계의 의미는 공급자마다 다르다는 점이 핵심이에요. GPT-5.4의 high와 Gemini의 HIGH, Opus의 high가 같은 thinking 토큰량을 의미하지 않습니다 — 아래 비용 표에서 차이가 드러나요.

에이전트 루프 속 Interleaved Thinking

주요 코딩 에이전트(Claude Code, Codex 등) 환경에서 thinking을 쓰면, thinking 블록이 도구 호출 사이사이에도 끼어들 수 있어요.

[thinking: plan file structure] --> [read_file] --> [thinking: interpret result, next strategy] --> [edit_file] --> ...

각 도구 호출 직전에 thinking이 들어가므로, "다음 어떤 도구를 써야 하는가"를 한 번 더 추론하게 돼요. 복잡한 리팩터링이나 다단계 디버깅에서 유효하지만, 도구 호출마다 thinking 비용이 붙으므로 단순 루틴 작업에는 비효율적입니다.

모드별 Interleaved 활성화 방식

에이전트 워크로드에서 Claude 4 계열을 쓴다면 Adaptive가 사실상 기본 선택이에요.

Claude 4.7의 task_budget은 이런 누적을 겨냥한 장치예요 — thinking + tool + output 토큰의 합계 상한을 지정해 에이전트 루프 전체가 예산 내에서 끝나도록 강제합니다.

2026년 실사용 비용 감각

레벨 이름만 봐서는 "한 단계 올리면 얼마나 비싸지지?" 감이 잘 안 와요. thinking 레벨별 평균 토큰 소비와 요청당 비용을 한 표에 모았어요 (2026-04 조사).

같은 프롬프트를 thinking 없음 → HIGH로 올리면 요청당 비용이 3-10배, 에이전트 루프에서 interleaved로 누적되면 세션당 비용이 수십 배가 됩니다. task_budget 또는 effort 하향은 단순히 품질 조절이 아니라 비용 통제 장치예요.

토크나이저 이슈 (Claude 4.7)

Claude Opus 4.7은 새 토크나이저를 채택해, 같은 텍스트가 4.6 대비 1x~1.35x 토큰으로 카운트됩니다. 단가가 바뀌지 않았더라도 실사용 비용은 최대 35% 상승 가능해요. 대규모 배치 작업에서는 실제 청구서가 예상보다 높게 나올 수 있으니 PoC(Proof of Concept — 본 도입 전 소규모 검증) 단계에서 실측해 두는 게 좋아요.

컨텍스트 구간 단가

긴 컨텍스트와 깊은 thinking이 겹치면 비용이 두 축에서 동시에 튀어요. 공급자별 단가 변곡점을 정리하면 이래요.

Claude는 고정 단가라 예산 예측이 쉽고, GPT/Gemini는 단가 변곡점을 넘기지 않도록 프롬프트 길이를 관리하는 게 좋아요. thinking 토큰까지 합치면 변곡점을 의식보다 빨리 넘기는 경우가 많습니다.

비유의 한계

"빈 종이를 받은 학생" 비유는 RLVR 의 자기조직성을 잘 잡아주지만, 한 가지 큰 차이가 있어요 — 학생은 한 문제를 풀고 나면 풀이 전략을 다음 문제에 의식적으로 가져갈 수 있지만, 추론 모델의 thinking 은 호출이 끝나면 사라집니다. 같은 모델을 다음 호출에서 부른다고 해서 직전의 풀이 노트를 기억하지 않아요 — 학습 단계가 아니라 추론 단계이기 때문입니다. 호출 간 추론 누적을 원한다면 결국 외부 하네스가 thinking 을 받아 컨텍스트로 다시 주입해야 해요. 즉 "내재화"는 한 호출 안에서만 성립하는 내재화이고, 호출 사이 학습은 여전히 외부의 일이에요.

또 한 가지 — 사람이 빈 종이에 풀이를 적을 때는 "여기까지 옳다 / 여기서 막혔다" 가 본인에게 명확하지만, 추론 모델은 자기 thinking 의 옳고 그름을 그 순간에는 안다고 보장할 수 없어요. 그래서 overthinking 구간이 생깁니다.

실무 판단 기준

추론 모델 투입 여부를 빠르게 판단하는 기준이에요:

추론 모델은 API 호출 비용이 일반 모델 대비 3~10배 비싸요. "정말 어려운 단발성 문제인가"를 먼저 확인하는 게 좋아요. 프롬프트를 잘 짜면 일반 모델로 해결되는 문제가 대부분입니다.

경량 모델이 대형 추론 모델을 따라잡는 현상은 경량 모델의 약진에서 벤치마크 수치로 이어 다뤄요.