Claude 4.5에서 사고 모드를 사용하는 방법

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

Claude 4.5란 무엇인가요? (그리고 어떤 모델을 주목해야 하나요?)

Claude 4.5는 Anthropic이 점진적인 “4.5” 업데이트로 출시한 최신 Claude 모델군입니다(예: Sonnet 4.5 및 Opus 4.5). Sonnet 4.5는 대부분의 개발자에게 지능, 코딩, 에이전트 성능의 최적 균형을 제공하는 모델로 포지셔닝되어 있고, Opus 4.5는 매우 높은 수준의 추론 작업에 초점을 맞추며 멀티턴 연속성을 향상시키기 위해 thinking block을 보존합니다. 두 모델 모두 Claude의 확장 사고 기능을 지원하지만, 일부 동작(예: 요약된 thinking 대 전체 thinking)은 모델에 따라 다릅니다.

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

이 수치는 Claude 4.5가 단순히 코드 조각 작성 능력이 더 나아진 수준이 아니라, 전체 파일 시스템을 탐색하고 사람의 개입 없이 자율적인 작업을 수행하는 능력이 훨씬 더 강력해졌음을 보여줍니다.

이것이 중요한 이유

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

Claude 4.5의 Thinking Mode란 무엇인가요?

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

응답의 구조

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

Thinking mode의 핵심 속성

• 요청으로 활성화: API 호출에 {"type":"enabled","budget_tokens":10000} 같은 thinking 객체를 전달해 기능을 켜고, 추론에 사용할 내부 토큰 예산을 지정합니다.
• 예산 관리: budget_tokens는 모델의 내부 추론 토큰 수를 제한합니다. 예산이 많을수록 더 깊은 추론이 가능하지만 비용과 지연 시간도 증가합니다. Claude 4 모델에서는 사용자가 요약본만 받더라도 thinking 토큰에 대해 과금됩니다.
• 요약 및 리다이렉션: 많은 Claude 4 모델에서 사용자는 thinking 내용의 요약본만 보게 되며, 일부 내부 추론은 안전 시스템에 의해 가려져 redacted_thinking으로 반환될 수 있습니다.
• 서명 및 검증: Thinking block에는 도구 사용 시 특히 필요한, API에 thinking block을 다시 전달할 때 검증에 사용하는 불투명한 signature가 포함됩니다. 이 서명은 불투명한 값으로 취급해야 하며, 파싱하려고 해서는 안 됩니다.
• 도구와의 인터리브드 씽킹: Claude 4는 도구 실행과 thinking block을 교차(interleave)시키는 것을 지원합니다(일부 경우 베타 및 플래그 기반). 이는 에이전트형 작업에 매우 강력합니다(도구 실행 → 생각 → 또 다른 도구 실행 등).

실습 예제와 최신 파라미터는 Anthropic의 Messages/Extended Thinking 문서가 가장 신뢰할 수 있는 기준 자료입니다.

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

요약된 thinking과 전체 thinking, 암호화와 서명

서로 다른 Claude 모델 버전은 thinking을 다르게 처리합니다. 최신 Claude 4 모델(예: Sonnet/Opus 4.5)은 내부 추론의 요약된 공개 뷰를 반환하는 경우가 많고, 전체 스크래치패드는 암호화되어 signature 필드(또는 redacted block)를 통해서만 제공될 수 있습니다. 도구를 사용하는 경우(또는 도구 호출 간 내부 상태를 유지해야 하는 경우) thinking block을 API에 다시 전달하거나 문서에 설명된 signature 메커니즘을 사용해야 합니다. 이 메커니즘은 민감한 내부 추론을 보호하면서도, 필요할 때 사고 과정을 안전하게 이어갈 수 있도록 해줍니다.

실무적인 처리 패턴

도구 사용 / 이어서 진행: 다음 요청이 동일한 내부 상태를 계속 이어가야 한다면(예: thinking을 기반으로 도구가 실행된 경우), API를 다시 호출할 때 반환된 thinking block 또는 signature를 포함시켜 모델이 이전 지점부터 복호화하여 계속 진행할 수 있게 해야 합니다.

Request: thinking: {type: "enabled", budget_tokens: N} 전송

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

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

예제 1 — thinking 활성화 비스트리밍 단순 curl

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": "CSV 가져오기를 위한 견고한 데이터 검증 전략을 설계하고, 테스트와 코드도 보여줘."}
    ]
  }'

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

예제 2 — Python: 요청 후 thinking 및 text block 파싱

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": "Python에서 property-based testing을 하는 방법을 설명하고 예제 코드도 포함해줘."}]
}

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 block을 그대로 포함하세요(다음 예제 참조).

예제 3 — 멀티턴 흐름에서 thinking block 재사용(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": "이제 검증 로직을 avro 파이프라인에 맞게 조정해줘."},
    assistant_message
  ]
}
r2 = requests.post(URL, headers=HEADERS, json=payload2)

도구 통합 또는 장기 에이전트 워크플로를 수행할 때는 수정되지 않은 thinking block을 정확히 보존하는 것이 매우 중요합니다. Opus 4.5는 thinking block 보존과 캐싱에 대해 향상된 기본 동작을 제공합니다.

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

스트리밍 모범 사례

• SDK의 스트리밍 엔드포인트를 사용하세요(Python/TypeScript SDK에는 스트림 헬퍼가 있습니다). 장시간 실행되거나 높은 예산의 추론 작업에서는 스트리밍이 HTTP 타임아웃을 방지하고, 모델이 계산하는 동안 부분적인 텍스트를 받을 수 있게 해줍니다. 일반적인 코드는 text_stream(Python) iterator 또는 JS의 이벤트 파싱을 사용합니다.
• 때로는 2단계 스트림을 예상해야 합니다. 모델이 먼저 표시 가능한 추론 chunk를 생성한 뒤 답변을 마무리할 수 있습니다. UI는 chunk 단위 콘텐츠를 처리하고 “thinking…” 상태와 최종 답변 상태를 구분해 표시할 수 있어야 합니다.
• 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": "이 실패한 단위 테스트를 어떻게 디버깅할지 단계별로 설명하고 수정안도 제안해줘." } ]
  }'

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

Claude Code는 thinking mode와 어떻게 상호작용하나요? (터미널 + VS Code)

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

• 전역 / 세션별 설정: Claude Code는 동작 방식을 조정할 수 있는 /config 설정 패널을 제공합니다(에이전트가 권한 요청을 어떻게 하는지, thinking block을 보존할지 여부 등). 지속적인 동작 변경이 필요하다면 raw 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 관련 플래그(보존, verbosity 등)를 확인합니다.
3. 에이전트에게 긴 작업을 실행하도록 요청하면 thinking 콘텐츠를 생성하고, 필요 시 특정 bash 단계를 실행하기 위해 권한을 요청합니다. 나중에 결정을 검증하거나 다시 실행해야 한다면 thinking block을 보존하세요.

설치 및 설정

Claude Code는 Node.js가 필요하며 전역 설치할 수 있습니다.

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

# Authenticate
claude-code --init

터미널에서 Thinking 활성화

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

팁:

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

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

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

Interleaved Thinking (Beta)

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

예를 들어 Claude가 서버를 디버깅하는 상황을 생각해보면:

1. 생각: "먼저 로그를 확인해야겠다."
2. 도구 호출: read_file(logs.txt)
3. 생각: "로그에 데이터베이스 타임아웃이 보인다. 이제 커넥션 풀 설정을 확인해야겠다."
4. 도구 호출: read_file(db_config.yml)

이러한 “지속적인 반성”은 모델이 도구로부터 받은 데이터에 따라 전략을 조정하게 하며, 미리 정해진 경직된 계획을 따르지 않게 합니다.

Thinking Block Preservation

특히 도구 사용이 포함된 멀티턴 대화에서는 이전 thinking block을 API에 다시 전달하는 것이 중요합니다.

• 추론의 연속성: 이전 생각을 다시 받음으로써 Claude는 자신의 논리적 진행 맥락을 유지할 수 있습니다.
• Opus 4.5 최적화: Claude Opus 4.5에서는 이 동작이 자동화됩니다. 모델은 기본적으로 모든 이전 thinking block을 컨텍스트에 보존하므로, 30시간 이상 지속되는 세션에서도 10턴 전 어떤 아키텍처 결정을 왜 내렸는지 “잊지” 않습니다.

Claude 4.5에서 THINKING mode를 사용할 때의 모범 사례

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

속도, 비용, 강력한 코딩 능력의 최적 균형이 필요하다면 코딩 및 에이전트 워크플로에 Sonnet 4.5를 사용하세요. 가장 깊은 추론, 가장 큰 컨텍스트 윈도우, 또는 장시간 자율 세션이 필요하다면 Opus 4.5를 사용하세요. 두 모델 모두 확장 사고를 지원합니다. 작업의 복잡도에 비례해 budget_tokens를 설정하고(실험은 작게 시작), 품질 향상이 실제로 관찰될 때만 예산을 늘리세요.

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

사용자가 실제로 받는 것이 요약본뿐이라 하더라도, Claude가 생성한 전체 thinking 토큰에 대해 과금됩니다. 즉, 긴 내부 숙고는 짧은 요약만 보여도 비용을 증가시킵니다. 토큰 사용량을 추적하고, 탐색 단계에서 운영 단계로 넘어갈 때는 점진적으로 튜닝하세요(예: 2k → 8k → 32k).

필요할 때만 thinking block 보존

Thinking block은 이후 검증과 인터리브드 도구 사용을 위해 암호학적으로 서명되고 보존될 수 있습니다. 에이전트가 단계를 다시 실행해야 하고 이전 근거를 유지해야 하는 경우처럼, 워크플로에 정말 필요하지 않다면 모든 후속 요청에 thinking block을 계속 되돌려 보내지 마세요. 항상 보존하면 컨텍스트 부피가 커지고 토큰 계산이 복잡해질 수 있습니다.

사용자에게 thinking을 스트리밍해야 하는 경우

스트리밍된 thinking은 개발자 도구나 교육용 UI에 매우 유용합니다(모델이 숙고하는 동안 “작업 진행 중”을 보여줌). 그러나 안전성과 리다이렉션을 고려하지 않은 채 운영 환경의 소비자용 앱 최종 사용자에게 원시 thinking을 스트리밍해서는 안 됩니다. 요약된 thinking이 존재하는 이유가 바로 이것입니다. 스트리밍하는 경우에는 내부 추론임을 명확히 표시하는 UI를 제공하고(예: “Assistant reasoning — internal”), 최종 사용자에게 요약본을 보여줄지 전체 추론을 보여줄지 제어하세요.

도구 사용과 인터리빙

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

실무적인 트러블슈팅 및 운영 메모

일반적인 오류와 의미

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

관측 가능성 및 계측

다음을 로깅하세요: (1) model 선택, (2) thinking.budget_tokens, (3) 실제 thinking 토큰 소비량(과금 대상), (4) 스트리밍 지연 시간(첫 thinking_delta까지 걸린 시간), (5) 최종 텍스트 토큰 수. 이 메트릭을 사용해 사용자 대상 흐름의 예산과 SLO를 설계하세요.

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

Thinking 활성화 모델은 기능 플래그 뒤에서 점진적으로 롤아웃하세요. 개발자 또는 내부 트래픽의 일부 비율부터 시작해 실패나 redaction 사례를 수집하고, 프롬프트와 예산을 반복 개선하세요. 민감한 도메인에서는 상당한 내부 추론이 포함된 출력은 배포 전에 사람이 검토하도록 요구하세요.

디버깅 팁

• 작게 시작하세요: 낮은 budget_tokens로 활성화한 뒤 점진적으로 늘려 품질 개선 정도를 파악하세요.
• 스트리밍을 켜고 content_block_delta / signature 이벤트를 로깅해 모델이 언제 thinking block을 생성하는지 파악하세요.
• Claude Code를 사용 중이라면 /config와 프로젝트 수준 설정을 확인하고, 동작이 예상 기본값과 다르다면 Claude Code changelog를 참조하세요.

결론

Claude 4.5는 Extended Thinking 및 Claude Code CLI의 강력함과 결합되어, 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는 통합을 돕기 위해 공식 가격보다 훨씬 저렴한 가격을 제공합니다.

바로 시작할 준비가 되셨나요?→ Claude 4.5 무료 체험!