Claude 4.5에서 Thinking Mode를 사용하는 방법

“Thinking mode”(또는 extended thinking, thinking, 또는 thinking blocks)는 Claude 4.5에서 최종 답변을 내기 전에 모델이 별도로 예산화된 토큰을 사용해 내부의 단계별 추론(“chain-of-thought”)을 생성하도록 지시하는, 명시적이며 구성 가능한 운영 모드입니다. 이는 지연 시간과 토큰 비용을 더 깊은 내부 숙고로 교환하여 다단계 추론, 복잡한 코딩 및 에이전트 워크플로, 연구 작업에서의 성능을 개선하도록 설계되었습니다. Claude 4.5는 Messages API 수준에서 명시적 파라미터(예: thinking / budget_tokens 또는 effort/“interleaved-thinking” 헤더)를 통해 이 기능을 제공하며, 이후 검증이나 도구 사용을 위해 thinking 블록을 보존하고 선택적으로 암호화하며, 프로덕션 워크로드를 구축할 때 관리해야 하는 캐시 및 토큰 회계 동작을 도입합니다.

Claude 4.5란 무엇인가요? (그리고 어떤 모델을 신경 써야 할까요?)

Claude 4.5는 점증적 “4.5” 업데이트로 출시된 최신 Claude 모델 세트(예: Sonnet 4.5와 Opus 4.5)입니다. Sonnet 4.5는 대부분의 개발자에게 지능, 코딩 및 에이전트 성능의 최적 균형을 제공하도록 포지셔닝되었으며, Opus 4.5는 매우 고강도 추론에 집중하고 thinking 블록을 보존하여 멀티 턴 연속성을 향상합니다. 두 모델 모두 Claude의 확장된 thinking 기능을 지원하지만 요약 대 전체 thinking 등 일부 동작은 모델별로 다릅니다.

Claude 4.5, 특히 Sonnet 4.5에서의 성능 향상은 실제 GitHub 이슈 해결 능력을 측정하는 SWE-bench Verified 벤치마크에서 가장 두드러집니다.

이 수치는 Claude 4.5가 단순히 스니펫을 작성하는 데 더 나은 수준을 넘어, 전체 파일 시스템을 탐색하고 인간 개입 없이 자율적으로 작업을 수행하는 능력에서 크게 향상되었음을 보여줍니다.

왜 중요한가

• 코딩 및 에이전트: Sonnet 4.5는 실제 소프트웨어 작업과 장기 코딩 작업에서 강력한 향상을 보여주며, 코드 생성, 코드 편집, 자율 에이전트 플로우에 자연스러운 선택입니다.
• 확장된 thinking 및 컨텍스트: Claude 4.5 제품군 모델은 수만 토큰 이상의 매우 큰 내부 스크래치패드로 추론하도록 설계되어 더 깊은 다단계 추론이 가능합니다. 이는 프롬프트, 토큰 예산, 도구 상호작용을 설계하는 방식을 바꿉니다.

Claude 4.5의 Thinking Mode란?

Thinking Mode(공식 명칭은 "Extended Thinking")는 모델이 최종 출력을 제공하기 전에 스스로 “작업 과정을 보여주는” 능력입니다. 표준 모델이 즉시 답변을 확정하는 것과 달리, Claude 4.5는 전용 추론 공간을 사용하여 여러 가설을 탐색하고 논리의 잠재적 오류를 식별하며 전략을 정제합니다.

응답의 구조

표준 상호작용에서는 모델이 프롬프트를 받고 답변 생성을 시작합니다. Thinking Mode에서는 응답이 두 개의 구분된 블록으로 나뉩니다:

Thinking Mode의 주요 속성

• 요청 시 활성화: {"type":"enabled","budget_tokens":10000} 같은 thinking 객체를 API 호출에 전달해 켜고, 모델의 내부 추론 토큰 예산을 부여합니다.
• 예산 관리: budget_tokens는 모델의 내부 추론 토큰을 상한합니다. 예산이 많을수록 더 깊은 추론이 가능하지만 비용과 지연이 증가합니다. Claude 4 모델에서는 요약된 보기만 받아도 thinking 토큰이 과금됩니다.
• 요약 및 편집: 많은 Claude 4 모델에서 사용자는 thinking 콘텐츠의 요약본을 보게 되며, 일부 내부 추론은 안전 시스템에 의해 편집(암호화)되어 redacted_thinking로 반환될 수 있습니다.
• 서명 및 검증: Thinking 블록에는 도구 사용 시 특히 필요한 검증을 위해 API에 thinking 블록을 다시 전달할 때 사용하는 불투명한 signature가 포함됩니다. 서명은 불투명하게 취급해야 하며 해석하려고 하지 마세요.
• 도구와의 인터리브드 thinking: Claude 4는 도구 실행과 thinking 블록을 교차(interleave)하는 기능을 지원합니다(일부는 베타 및 플래그 기반). 이는 에이전트 작업에 강력합니다(도구 실행 → 생각 → 다른 도구 실행 등).

핸즈온 예제와 최신 파라미터는 Anthropic의 Messages/Extended Thinking 문서가 정식 기준입니다.

Messages API는 thinking 콘텐츠를 어떻게 반환하나요

요약 vs 전체 thinking; 암호화 및 서명

Claude 모델 버전에 따라 thinking 처리 방식이 다릅니다. 최신 Claude 4 모델(예: Sonnet/Opus 4.5)은 내부 추론의 전체 스크래치패드를 암호화하고 공개적으로는 요약된 보기를 반환하는 경우가 많습니다. 도구를 사용하는 경우(또는 도구 호출 간 내부 상태를 보존해야 하는 경우), 반환된 thinking 블록을 API에 다시 전달하거나 문서에서 설명하는 signature 메커니즘을 사용해야 합니다. 이 메커니즘은 민감한 내부 추론을 보호하면서 필요 시 안전하게 사고 과정을 이어갈 수 있게 합니다.

실무 처리 패턴

도구 사용 / 연속성 유지: 다음 요청이 동일한 내부 상태를 이어가야 한다면(예: thinking에 기반해 도구가 실행되었을 때), 반환된 thinking 블록 또는 signature를 다음 API 호출에 포함하여 모델이 복호화하고 이어서 진행할 수 있도록 하세요.

요청: thinking: {type: "enabled", budget_tokens: N}을 전송합니다.

응답: (a) 공개 요약 출력, (b) 암호화된 signature 또는 redacted_thinking 블록, (c) 둘 다를 받을 수 있습니다.

CometAPI는 공식 API 가격의 20%로 Claude 4.5 API를 제공하며, Anthropic Messages를 사용해 호출할 수도 있습니다. 시작하기 전에 API 키를 발급받아야 합니다.

예시 1 — 단순 curl(비스트리밍)으로 thinking 활성화

curl https://api.cometapi.com/v1/messages \
  -H "x-api-key: $CometAPI_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {
      "type": "enabled",
      "budget_tokens": 10000
    },
    "messages": [
      {"role": "user", "content": "Design a robust data validation strategy for CSV imports, show tests + code."}
    ]
  }'

응답에는 content 블록이 포함됩니다. 각 블록을 확인하고 최종 출력에는 text 블록을 우선 사용하세요; thinking 블록에는 모델의 내부 분석 요약이 포함됩니다.

예시 2 — Python: thinking과 text 블록 요청 및 파싱

import os, requests

API_KEY = os.environ["CometAPI_API_KEY"]
URL = "https://api.cometapi.com/v1/messages"
HEADERS = {
    "x-api-key": API_KEY,
    "anthropic-version": "2023-06-01",
    "content-type": "application/json"
}

payload = {
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "thinking": {"type": "enabled", "budget_tokens": 8000},
    "messages": [{"role": "user", "content": "Explain how to do property-based testing in Python; include example code."}]
}

r = requests.post(URL, headers=HEADERS, json=payload)
r.raise_for_status()
resp = r.json()

# Parse blocks
for block in resp.get("content", []):
    if block.get("type") == "thinking":
        thinking_summary = block.get("thinking")
        print("=== THINKING (summary) ===")
        print(thinking_summary[:1000])  # truncate for logs
        print("signature:", block.get("signature")[:64], "...")
    elif block.get("type") == "text":
        print("=== FINAL TEXT ===")
        print(block.get("text"))

이 코드는 요약된 thinking과 최종 답변을 추출해 출력합니다. 멀티 턴 에이전트 플로우에서 연속성을 유지해야 한다면, 다음 요청의 messages 배열에 수정하지 않은 thinking 블록을 포함하세요(다음 예시 참조).

예시 3 — 멀티 턴 플로우에서 thinking 블록 재사용(Python 의사 코드)

# After initial response (resp above):
# Add the assistant message including the thinking block back into the conversation
assistant_message = {
  "role": "assistant",
  "content": resp["content"]  # include raw content array (contains thinking + text blocks)
}

# Next user turn: ask follow-up and include previous assistant message
payload2 = {
  "model": "claude-opus-4-5",  # Opus preserves thinking blocks better across turns
  "max_tokens": 20000,
  "thinking": {"type": "enabled", "budget_tokens": 12000},
  "messages": [
    {"role": "user", "content": "Now adapt the validation logic for an avro pipeline."},
    assistant_message
  ]
}
r2 = requests.post(URL, headers=HEADERS, json=payload2)

도구 통합 또는 장기 에이전트 워크플로를 수행할 때는 수정되지 않은 thinking 블록을 정확히 보존하는 것이 중요합니다. Opus 4.5는 thinking 블록 보존 및 캐싱에 관한 기본값이 개선되었습니다.

thinking 출력을 스트리밍하고 UI에 진행 상황을 표시하려면?

스트리밍 모범 사례

• SDK 스트리밍 엔드포인트(Python/TypeScript SDK에 스트림 헬퍼가 있음)를 사용하세요. 장시간 실행 또는 고예산 추론 작업에서 스트리밍은 HTTP 타임아웃을 방지하고 모델이 계산하는 동안 부분 텍스트를 제공합니다. 일반 코드는 text_stream(Python) 또는 이벤트 파싱(JS)을 위한 반복자를 사용합니다.
• 가끔은 2단계 스트림을 예상하세요: 모델이 먼저 가시적인 추론 청크를 생성한 다음 답변을 확정할 수 있습니다. 청크된 콘텐츠를 처리하고 “thinking…”과 최종 답변 상태를 표시하도록 UI를 구성하세요.
• API가 스트리밍 중에 signature_delta 또는 content_block_delta를 반환하면 이를 캡처하여 명세가 요구하는 대로 후속 호출에 첨부하세요.

UI에서 중간 추론 진행 상황을 보여주려면, 응답을 스트리밍하세요. 서버는 thinking_delta 이벤트 뒤에 text_delta 이벤트를 내보냅니다.

curl https://api.cometapi.com/v1/messages \
  --header "x-api-key: $CometAPI_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 16000,
    "stream": true,
    "thinking": { "type": "enabled", "budget_tokens": 8000 },
    "messages": [ { "role": "user", "content": "Walk me through debugging this failing unit test and propose fixes." } ]
  }'

스트리밍 시 content_block_start, content_block_delta(여기에는 thinking_delta와 text_delta가 포함됨), content_block_stop 이벤트를 순서대로 처리하세요. 이렇게 하면 모델의 단계별 추론을 진행 중 그대로 표시할 수 있습니다.

Claude Code는 thinking 모드와 어떻게 상호작용하나요? (terminal + VS Code)

Claude Code는 Messages API와 도구 실행기를 통합한 대화형 에이전트형 코딩 터미널입니다. CLI/IDE 경험은 thinking을 두 가지 방식으로 노출합니다:

• 글로벌 / 세션별 설정: Claude Code는 /config 설정 패널을 통해 동작(에이전트가 권한을 요청하는 방식, thinking 블록 보존 여부 등)을 조정합니다. 지속적 동작 변경을 원한다면 원시 JSON을 다시 입력하는 대신 해당 UI를 사용하세요.
• 모델 선택 및 CLI 명령: REPL에서 claude-sonnet-4-5 또는 claude-opus-4-5를 활성 모델로 선택할 수 있으며, 도구 및 thinking 동작은 Messages API의 의미론을 따릅니다. CHANGELOG와 릴리스 노트에는 일부 Opus 4.5 배포에서 thinking이 기본 활성화되었고 구성은 /config에 노출된다는 점이 명시되어 있습니다.

Claude Code에서의 실무 흐름:

1. REPL에서 프로젝트를 시작합니다.
2. /config로 thinking 관련 플래그(보존, 상세도 등)를 확인합니다.
3. 에이전트에게 장시간 작업을 요청합니다 — 필요 시 특정 bash 단계 실행 권한을 요청하며 thinking 콘텐츠를 생성합니다. 추후 검증이나 결정 재실행이 필요하다면 thinking 블록을 보존하세요.

설치 및 설정

Claude Code는 Node.js가 필요하며 전역 설치가 가능합니다.

# Install Claude Code CLI
npm install -g @anthropic/claude-code

# Authenticate
claude-code --init

터미널에서 thinking 활성화

Claude Code는 추론 깊이를 제어하기 위한 다양한 플래그와 자연어 트리거를 지원합니다.

팁:

• 대안 구현을 탐색하게 하려면 think/think harder를 사용하세요.
• Claude Code가 도구 호출(테스트 실행, git 작업)을 수행할 때 CLI/에이전트가 thinking 블록을 반환하면 이를 보존하세요; 그렇지 않으면 단계 간 컨텍스트를 잃을 수 있습니다.

인터리브드 thinking과 블록 보존의 이점

고급 에이전트형 워크플로를 위해 Claude 4.5는 멀티 턴 상호작용과 도구 사용을 크게 강화하는 두 가지 베타 기능을 도입했습니다: Interleaved Thinking과 Thinking Block Preservation.

Interleaved Thinking(베타)

표준 추론은 출력 전에 한 번 발생합니다. Interleaved Thinking(interleaved-thinking-2025-05-14 헤더로 활성화)은 Claude가 도구 호출 사이에서 “생각”할 수 있도록 합니다.

예를 들어 Claude가 서버를 디버깅한다고 가정해 봅시다:

1. Think: "먼저 로그를 확인해야겠다."
2. Tool Call: read_file(logs.txt)
3. Think: "로그에서 데이터베이스 타임아웃이 보인다. 이제 연결 풀 설정을 확인해야겠다."
4. Tool Call: read_file(db_config.yml)

이 “지속적 성찰”은 모델이 도구로부터 받은 데이터에 기반해 전략을 조정하도록 보장하며, 사전에 정해진 경직된 계획을 따르지 않게 합니다.

Thinking Block Preservation

멀티 턴 대화, 특히 도구 사용을 포함하는 경우에는 이전 thinking 블록을 API에 다시 전달하는 것이 중요합니다.

• 추론 연속성: 이전 사고를 전달받음으로써 Claude는 논리적 맥락을 유지합니다.
• Opus 4.5 최적화: Claude Opus 4.5에서는 이 동작이 자동화됩니다. 모델은 기본적으로 모든 이전 thinking 블록을 컨텍스트에 보존하여, 30시간 이상 지속되는 세션에서도 열 턴 전에 내린 아키텍처 결정을 “왜” 내렸는지 잊지 않도록 합니다.

Claude 4.5에서 THINKING 모드를 사용하는 모범 사례

작업에 맞는 모델과 예산 선택

코딩 및 에이전트형 워크플로에서는 속도, 비용, 강력한 코딩 능력의 최적 균형을 제공하는 Sonnet 4.5를 사용하세요; 가장 깊은 추론과 가장 큰 컨텍스트 윈도우가 필요하거나 장시간 자율 세션을 계획한다면 Opus 4.5를 사용하세요. 둘 다 확장된 thinking을 지원합니다. budget_tokens는 작업 복잡도에 비례하여 선택하세요(실험은 작게 시작하고, 품질이 실질적으로 개선될 때만 예산을 늘리세요).

비용 및 지연 모니터링과 제어

Claude가 생성한 thinking 토큰 전체에 대해 과금되며, 수신한 요약 출력 길이에 대해서만 과금되는 것이 아닙니다. 즉, 내부 숙고가 길어지면 요약이 짧더라도 비용이 증가합니다. 토큰 사용량을 추적하고 탐색 단계에서 프로덕션으로 전환할 때 점진적 튜닝(예: 2k → 8k → 32k)을 고려하세요.

필요한 경우에만 thinking 블록을 보존

Thinking 블록은 암호학적 서명을 통해 나중에 검증 및 도구 사용을 위해 보존할 수 있습니다. 워크플로가 이전 내부 숙고를 유지할 필요가 있는 경우(예: 에이전트가 단계를 재실행하며 보존된 근거가 필요할 때)가 아니라면 매 요청마다 thinking 블록을 에코하지 마세요. 상시 보존은 컨텍스트 볼륨을 증가시키고 토큰 회계를 복잡하게 만들 수 있습니다.

사용자에게 thinking을 스트리밍해야 할 때

스트리밍된 thinking은 개발자 도구 및 교육용 UI에 훌륭합니다(모델이 숙고하는 동안 “진행 중”을 보여줌). 요약 thinking은 바로 이러한 이유로 존재하므로, 안전성과 편집을 고려하지 않고 프로덕션 소비자 앱의 최종 사용자에게 원시 thinking을 스트리밍하지 마세요. 스트리밍할 경우 UI에서 내부 추론을 명확히 라벨링(예: “Assistant reasoning — internal”)하고 최종 사용자가 요약본을 볼지 전체 추론을 볼지 제어하세요.

도구 사용과 인터리빙

Thinking과 도구(코드 실행, 웹 페치, 로컬 프로세스)를 결합할 때, 모델이 도구를 선택하고 실행하며 동일한 턴 내에서 결과를 기반으로 추론하도록 해야 한다면 interleaved thinking 설계를 사용하세요. 인터리빙은 복잡성을 높이며(플래그가 필요할 수 있음) 에이전트 자동화에 강력합니다. 어떤 thinking을 보존할지 명확히 하고 thinking 활성화 실행에서 모델의 도구 선택을 테스트하세요.

실무 트러블슈팅 및 운영 노트

일반적인 오류와 의미

• 유효하지 않은 thinking + 강제 도구 선택: thinking을 요청하면서 thinking과 호환되지 않는 특정 도구 사용 모드를 강제하면 API가 오류를 반환합니다 — thinking과 함께 tool_choice: {"type":"tool","name":"..."} 강제를 섞지 마세요.
• Budget > max_tokens: 인터리브드 thinking 시나리오에서는 유효 토큰 규칙이 다릅니다 — 플랫폼 문서에서 budget_tokens가 max_tokens를 초과할 수 있는 경우를 설명합니다. 대규모 예산을 테스트하기 전에 “interleaved thinking” 섹션을 주의 깊게 읽으세요.
• 서명 검증: thinking 블록을 후속 호출을 위해 보존하는 경우, 반환된 signature를 포함하여 그것이 Claude에서 왔음을 API가 검증할 수 있게 하세요; 이는 변조를 방지하고 체인을 검증 가능하게 유지합니다.

가시성 및 계측

다음을 로그로 남기세요: (1) model 선택, (2) thinking.budget_tokens, (3) 실제 thinking 토큰 소비량(이에 대해 과금됩니다), (4) 스트리밍 지연(첫 thinking_delta까지의 시간), (5) 최종 텍스트 토큰. 이러한 지표를 사용해 사용자 대상 플로우의 예산과 SLO를 수립하세요.

점진적 롤아웃 및 휴먼-인-더-루프

thinking 활성화 모델을 기능 플래그 뒤에서 롤아웃하세요. 개발자 또는 내부 트래픽의 일부 비율로 시작하고, 실패나 편집 사례를 수집하여 프롬프트와 예산을 반복하세요. 민감한 도메인에서는 상당한 내부 추론을 포함하는 출력에 대해 릴리스 전 인간 검토를 요구하세요.

디버깅 팁

• 작게 시작: 낮은 budget_tokens를 활성화하고 점진적으로 늘리며 단계적 개선을 이해하세요.
• 스트리밍을 켜고 content_block_delta / 서명 이벤트를 로그로 남겨 모델이 thinking 블록을 생성하는 시점을 파악하세요.
• Claude Code를 사용하는 경우: /config와 프로젝트 수준 설정을 확인하세요; 동작이 예상 기본값과 일치하지 않으면 Claude Code 변경 로그를 참조하세요.

결론:

Extended Thinking과 Claude Code CLI의 힘을 결합한 Claude 4.5는 IDE 발명 이후 개발자 생산성에서 가장 큰 도약을 의미합니다. 모델이 “작업 과정을 보여주고” 복잡한 문제에 대해 숙고하도록 함으로써, Anthropic은 “챗봇” 시대를 넘어 “에이전트” 시대로 나아갔습니다.

Messages API를 맞춤 개발 도구에 통합하든 Claude Code로 일상적인 PR을 관리하든, Thinking Mode를 마스터하는 것은 필수적입니다. 이는 신뢰에 필요한 투명성과 탁월함에 필요한 추론 깊이를 제공합니다.

개발자는 CometAPI를 통해 Claude 4.5(Claude Sonnet 4.5 , Claude Haiku 4.5, Claude Opus 4.5) 모델에 접근할 수 있습니다. 시작하려면 CometAPI의 모델 기능을 Playground에서 살펴보고 자세한 지침은 API 가이드를 참고하세요. 접근하기 전에 CometAPI에 로그인하고 API 키를 발급받았는지 확인하세요. CometAPI는 통합을 돕기 위해 공식 가격보다 훨씬 낮은 가격을 제공합니다.

Ready to Go?→ Claude 4.5 무료 체험!