Anthropic의 새로운 Claude Fable 5 추론 엔진은 모든 요청에 대해 심층 사고 기능을 항상 켠 상태로 유지하며, 대신 개발자가 추론의 깊이를 높이거나 낮출 수 있도록 합니다. 과거 대규모 언어 모델(LLM)은 질문의 복잡성에 관계없이 균일한 속도로 토큰을 생성하는 고정된 연산 매개변수로 작동했습니다. 단순한 인사말도 고도의 수학적 증명과 동일한 연산 에너지를 소모했습니다. Fable 5와 함께 Anthropic은 사고 기능이 항상 활성화되어 있으며 단일 effort 설정을 통해 모델이 얼마나 깊이 연산할지를 제어하는 하이브리드 추론 프레임워크를 선보였습니다. 본 튜토리얼에서는 API 작동 방식, effort 레벨을 선택하는 방법, 그리고 실제 상용 파이프라인에 이 아키텍처를 도입하는 방법을 설명합니다.
[!WARNING] API 제약 사항 경고: Fable 5에서는 사고 기능이 항상 켜져 있으므로 이를 끌 수 없습니다.
thinking: {type: "enabled"}또는thinking: {type: "disabled"}를 전달하거나budget_tokens값을 지정하면 HTTP 400 오류가 반환됩니다. 해당 매개변수들은 제거되었습니다. 대신output_config: {effort: "..."}로 추론 깊이를 제어하고, 높은 effort 레벨에서는 최종 답변을 출력할 수 있도록max_tokens에 충분한 여유를 남겨 두십시오.핵심 요약:
- 토글이 아닌 Effort 조절:
output_config.effort를low,medium,high,xhigh또는max로 설정하십시오. 켜고 끄는 스위치는 없습니다.- 사고 기능은 자동:
thinking을 생략하거나{type: "adaptive"}를 전달하십시오. 적응형 사고(adaptive thinking)는 모든 요청에서 실행됩니다.- 스트림 파싱: 실시간 서버 스트림에서
thinking_delta델타가 포함된thinking콘텐츠 블록을 처리하십시오.- 비용 관리: 시스템 프롬프트를 캐싱하면 반복적인 사고 연산 주기를 줄일 수 있습니다.
Claude 하이브리드 추론 엔진의 메커니즘
Fable 5의 핵심 혁신은 최종 답변을 출력하기 전에 문제를 충분히 사고하는 능력입니다. 이는 모델이 클라이언트 요청에 답변하기에 앞서 내부적으로 해결 방안에 대한 논리적 초안을 먼저 작성함을 의미합니다. 무엇보다 중요한 점은, 이 사고 단계가 항상 켜져 있다는 것입니다. 이를 끌 수 없으며, 별도로 전환해 들어가는 ‘속도 모드’도 존재하지 않습니다.
복잡한 질문을 제출하면 모델은 즉시 다음 단어를 추측하려 하지 않습니다. 대신 내부 사고 토큰을 생성하여 단계별 추론 과정을 시뮬레이션합니다. 이러한 아키텍처는 수학 연산, 코딩, 논리 평가의 정확도를 비약적으로 향상시킵니다.
다양한 엔터프라이즈 요구 사항을 지원하기 위해 Anthropic은 단일 effort 컨트롤을 통해 개발자가 사고의 깊이를 필요에 따라 조절할 수 있도록 합니다. low effort에서는 모델이 짧게 사고한 뒤 빠르게 답변하여 지연 시간과 토큰 소비를 낮게 유지합니다. high 또는 max effort에서는 훨씬 더 깊이 추론하며, 어려운 수학, 다단계 논리, 복잡한 코드에 필요한 추가 연산 자원을 투입합니다. 속도 대 깊이의 트레이드오프는 활성화/비활성화 토글이 아니라 전적으로 이 effort 레벨을 통해 표현됩니다.
Fable 5 API 매개변수 구성하기
이 기능을 소프트웨어에 구현하려면 업데이트된 Anthropic API 스키마를 사용해야 합니다. 이 스키마를 통해 클라이언트 애플리케이션이 올바른 모델명과 실행 매개변수를 지정할 수 있습니다.
추론 깊이는 output_config 블록을 통해 설정합니다. 그 안의 effort 필드는 "low", "medium", "high", "xhigh", "max" 중 하나를 받으며, 이 단일 값이 기존의 토큰 예산 다이얼을 대체합니다. 단순한 경우에는 thinking 블록을 전혀 전달하지 않습니다. 적응형 사고가 자동으로 실행되기 때문입니다. 아래 JavaScript 연동 예시는 이 요청을 구성하는 방법을 보여줍니다.
1import Anthropic from "@anthropic-ai/sdk";
2
3export default {
4 async fetch(request, env) {
5 const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
6
7 try {
8 const response = await anthropic.messages.create({
9 model: "claude-fable-5",
10 max_tokens: 8192,
11 // Thinking is always on for Fable 5; dial reasoning depth with effort:
12 output_config: { effort: "high" }, // "low" | "medium" | "high" | "xhigh" | "max"
13 messages: [
14 {
15 role: "user",
16 content: "Generate an optimised database migration script for 10 million records."
17 }
18 ]
19 });
20
21 return Response.json(response);
22 } catch (err) {
23 return Response.json({ error: err.message }, { status: 500 });
24 }
25 }
26};
사고 기능을 비활성화하거나 budget_tokens 값을 전달하려 하지 마십시오. thinking: {type: "disabled"}, thinking: {type: "enabled"}, 그리고 모든 budget_tokens 필드는 Fable 5에서 HTTP 400을 반환합니다. 이 모델(그리고 Opus 4.7 및 4.8)에서 해당 매개변수들이 제거되었기 때문입니다. 속도를 위해서는 낮은 effort 레벨을, 깊이를 위해서는 높은 레벨을 선택하고, effort를 높일 때는 최종 답변을 위해 max_tokens에 충분한 여유를 남겨 두십시오. 서버리스 아키텍처에 대한 자세한 내용은 Cloudflare Workers로 서버리스 API 개발하기
안내서를 참고하십시오.
스트림 응답에서 추론 토큰 파싱하기
챗봇 인터페이스와 같은 실시간 애플리케이션에서는 스트리밍 응답이 필수적입니다. Fable 5는 사고 단계와 최종 콘텐츠를 모두 SSE(Server-Sent Events) 채널을 통해 출력합니다.
스트리밍 중 사고 내용은 thinking 콘텐츠 블록으로 도착하며, delta.type이 "thinking_delta"인 content_block_delta 이벤트를 통해 전달됩니다. 텍스트는 delta.thinking에서 읽고, 최종 답변은 일반적인 text_delta 델타에서 읽습니다. 원본 사고 연쇄(chain-of-thought)는 절대 반환되지 않습니다. 읽을 수 있는 요약을 받으려면 thinking: {type: "adaptive", display: "summarized"}로 명시적으로 opt-in 해야 하며, 기본값인 "omitted"는 빈 사고 텍스트를 스트리밍합니다. 최소한의 핸들러는 다음과 같습니다.
1const stream = await anthropic.messages.stream({
2 model: "claude-fable-5",
3 max_tokens: 8192,
4 output_config: { effort: "high" },
5 thinking: { type: "adaptive", display: "summarized" },
6 messages: [{ role: "user", content: prompt }]
7});
8
9for await (const event of stream) {
10 if (event.type === "content_block_delta") {
11 if (event.delta.type === "thinking_delta") {
12 process.stdout.write(event.delta.thinking); // summarised reasoning
13 } else if (event.delta.type === "text_delta") {
14 process.stdout.write(event.delta.text); // final answer
15 }
16 }
17}
이러한 thinking_delta 청크를 접이식 “생각 중…” 패널로 흘려보내거나, 이를 버리고 답변만 렌더링할 수 있습니다. Anthropic 연동에 대한 자세한 레퍼런스는 Anthropic 개발자 문서
를 직접 참고하십시오.
토큰 정산을 신중하게 관리하십시오. 사고 토큰은 출력 API 과금에 포함됩니다. 따라서 동일한 입력에 대해 추론 주기를 다시 실행하지 않도록 적극적인 프롬프트 캐싱을 구현하십시오. 상용 배포를 계획할 때 에지 원격 분석 계층을 통해 이러한 수치를 추적하면 사고 토큰 사용량이 일반적인 범위를 초과하는 지점을 파악하는 데 도움이 됩니다.
API 연동 단계별 워크플로우
애플리케이션에 추론 엔진을 구현하려면 먼저 로컬 패키지를 Fable 5 사양에 맞게 업데이트하십시오. 오래된 SDK 버전은 여전히 budget_tokens를 전송하는데, 이는 이제 API 직렬화 과정에서 HTTP 400 스키마 오류를 유발합니다.
다음으로 명확한 지연 시간 기준을 정의하십시오. 단순한 대화 흐름이나 인사말에는 low effort 레벨을 설정하여 지연 시간을 낮게 유지하십시오. high 또는 max effort는 코드 생성이나 수학 연산과 같은 작업에 한정하십시오.
또한 Wrangler와 같은 도구를 사용하여 API 자격 증명을 서버리스 환경 매개변수 내부에 안전하게 저장하십시오. 스트림 출력 이벤트를 처리할 때는 thinking_delta 패킷을 걸러내는 견고한 프론트엔드 핸들러를 작성하십시오. 모델의 추론 단계를 직접 표시할 의도가 아니라면 이 작업이 필요합니다. 마지막으로 프롬프트 캐시 적중률을 점검하여 캐싱이 토큰 소비 오버헤드를 최소화하고 있는지 확인하십시오. 에지 API 설계에 대해서는 Cloudflare Workers AI 가이드
를 살펴보십시오.
한눈에 보는 Low Effort vs. High Effort
effort 레벨을 선택하는 것은 지연 시간, 비용, 답변 품질 간의 트레이드오프입니다. 아래 표는 요청 규모를 산정할 때 가장 중요한 요소들을 비교합니다. 지연 시간과 처리량 수치는 예시이며 프롬프트 길이, 부하, 리전에 따라 달라지지만, 이들 사이의 관계는 유지됩니다.
| 고려 지표 | Low effort | High effort |
|---|---|---|
| 첫 토큰 반응 속도 | 1초 미만 (예시) | 모델이 더 많이 사고할수록 증가 |
| 요청당 비용 | 사고 토큰이 적어 비용이 낮음 | 사고 토큰이 많으며 출력 단가로 과금 |
| 어려운 작업의 정확도 | 기본 수준 | 수학, 다단계 논리, 코드에서 현저히 높음 |
| 토큰 예측 가능성 | 더 촘촘하고 예측하기 쉬움 | 가변적이며 어려운 프롬프트에서 더 큼 |
| 적합한 워크로드 | 챗봇, 분류, 검색 결과 포맷팅 | 디버깅, 증명, 기획, 복잡한 생성 |
| 설정 | output_config.effort = "low" | output_config.effort = "high" 또는 "max" |
핵심은 사고 토큰이 실제 출력 토큰이라는 점입니다. low-effort 요청은 짧게 사고하고 대부분 작성한 답변에 대해 과금되지만, high 또는 max effort 요청은 응답의 첫 단어가 나오기도 전에 대량의 사고 토큰을 생성할 수 있습니다. 사고는 결코 꺼지지 않습니다. 여러분은 단지 그것을 얼마나 소비할지를 선택할 뿐입니다.
각 Effort 레벨을 사용해야 하는 시점
실용적인 접근법은 각 작업 유형을 기본 effort 레벨에 매핑한 뒤, 특정 요청이 명백히 더 많은 여유가 필요할 때만 이를 재정의하는 것입니다. high 및 max effort는 잘못된 답변을 나중에 바로잡는 비용이 큰 문제에 한정하십시오.
| 업무 유형 | 권장 effort |
|---|---|
| 인사말, FAQ 및 잡담 | low |
| 의도 분류 및 라우팅 | low |
| 단문 문서 요약 | low |
| 구조화된 데이터 추출 | low 또는 medium |
| 다중 파일 코드 생성 | high |
| 재무 또는 수학적 추론 | high 또는 xhigh |
| 근본 원인 디버깅 | xhigh 또는 max |
low effort 레벨을 선택해야 할 때: 응답이 짧고 대체로 결정론적일 때, 첫 토큰 반응 속도가 사용자 경험을 좌우할 때(라이브 챗봇, 자동완성, 양식 작성 도우미), 또는 모든 추가 출력 토큰이 수백만 건의 호출에 걸쳐 곱해지는 대용량·저마진 워크로드를 운영할 때 적합합니다.
high 또는 max effort 레벨을 선택해야 할 때: 잘못된 답변 하나가 실제 비용으로 이어지거나(깨진 마이그레이션 스크립트, 잘못 계산된 견적, 취약한 코드 경로), 모델이 함께 유지해야 하는 여러 종속 단계가 작업에 포함될 때입니다. 이러한 워크로드에서는 몇 초의 추가 지연 시간이 신뢰성의 의미 있는 향상으로 이어집니다.
실전 예시: 지연 시간과 비용의 트레이드오프
하루에 50,000건의 요청을 처리하는 지원 도우미를 생각해 봅시다. 각 최종 답변은 약 250 토큰이고, low effort 레벨은 소수의 사고 토큰만 추가하며, high effort 레벨은 일반적인 어려운 질의에서 약 1,500개의 사고 토큰을 소비한다고 가정합니다. 아래의 모든 토큰 단가는 예시이므로 실제 견적이 아닌 모델링 연습으로 받아들이시고, 백만 토큰당 출력 단가는 $15로 가정합니다.
모든 요청을 low effort로 실행하면 하루에 약 50,000 × 250 = 1,250만 출력 토큰, 예시 단가로 약 하루 $188가 발생합니다. 반면 모든 요청을 high effort로 실행하면 50,000 × (1,500 + 250) = 하루 8,750만 토큰, 약 하루 $1,313가 청구됩니다. 7배에 달하는 비용이며, 대부분은 추가 깊이가 전혀 필요 없던 질의를 추론하는 데 소비됩니다.
이제 선택적으로 라우팅해 봅시다. 저렴한 low-effort 분류기가 트래픽의 **15%**만이 실제로 복잡하다고 판단한다고 가정합니다. 7,500건을 high effort로, 42,500건을 low effort로 보내면 1,310만 + 1,060만 ≈ 하루 2,370만 토큰, 약 하루 $356가 됩니다. 모든 요청을 high effort로 실행하는 것보다 약 73% 절감이며, 깊은 추론이 제값을 하는 곳에는 여전히 이를 적용합니다.
지연 시간 양상도 이와 마찬가지입니다. low effort에서는 첫 토큰이 일반적으로 1초 훨씬 이내에 나타납니다. high effort에서는 모델이 답변을 시작하기 전에 훨씬 큰 추론 초안을 생성하므로, 초당 60 토큰이라는 예시 속도에서 1,500 토큰의 내부 초안은 눈에 보이는 응답을 약 25초 지연시킵니다. thinking_delta 블록을 접이식 “생각 중…” 패널로 스트리밍하는 것이 최종 사용자가 그 대기 시간을 견딜 수 있게 해 줍니다.
마이그레이션과 총소유비용(TCO)
고정 연산 모델에서 이전하는 경우 가장 큰 변화는 이제 추론 깊이가 모든 호출에 지불하는 정액 요금이 아니라 요청마다 설정하는 다이얼이라는 점입니다. 청구 비용에 가장 큰 영향을 미치는 요소는 개별 호출의 effort 레벨이 아니라, 어떤 요청이 애초에 high effort 레벨을 받을 자격이 있는지를 결정하는 라우팅 계층입니다. 비싼 high-effort 호출을 걸러 주는 몇 백 토큰짜리 가벼운 low-effort 분류 호출은 거의 항상 그 값을 합니다.
총소유비용을 예측 가능하게 유지하는 두 가지 습관이 있습니다. 첫째, 넉넉한 글로벌 기본값 대신 각 작업 유형을 확실히 해결하는 가장 낮은 effort 레벨을 설정하십시오. 모든 곳에 max effort 레벨을 적용하는 것은 예상치 못한 청구서의 가장 흔한 원인입니다. 둘째, 안정적인 시스템 프롬프트를 캐싱하여 반복되는 컨텍스트가 모든 추론 주기마다 다시 과금되지 않도록 하십시오. 요청별 라우팅과 프롬프트 캐싱을 함께 사용하면 대부분의 비용이 실제로 이를 통해 이득을 보는 소수의 요청에 집중됩니다.
핵심 결론
- Fable 5(
claude-fable-5, 100만 토큰 컨텍스트, 최대 128K 출력)는 사고를 항상 켠 상태로 유지합니다. 이를 켜고 끄는 대신 깊이를 조절합니다. - 추론 깊이는
output_config: {effort: "low" | "medium" | "high" | "xhigh" | "max"}로 설정합니다.budget_tokens와thinking.type의 “enabled”/“disabled"는 이제 HTTP 400을 반환합니다. - 모델의 사고 단계를 최종 사용자에게 표시하려면
thinking콘텐츠 블록(thinking_delta델타)으로 스트리밍하고, 읽을 수 있는 요약을 원하면thinking: {type: "adaptive", display: "summarized"}로 opt-in 하십시오. - 실행 가능한 가장 낮은 effort 레벨을 선택하고 자주 사용하는 프롬프트를 캐싱하여 API 과금 비용을 제어하십시오.
- 전송 지연 시간을 줄이기 위해 API 미들웨어를 서버리스 에지 네트워크에 배포하십시오.
자주 묻는 질문 (FAQ)
Claude Fable 5 추론이란 무엇인가요?
Claude Fable 5 추론은 모델이 최종 응답을 출력하기 전에 내부 사고 토큰을 생성하여 복잡한 논리 문제를 해결하는, 항상 켜져 있는 기능입니다. 다음 단어를 즉시 추측하려 하는 대신, 신경망은 단계별 사고 과정을 시뮬레이션하여 아키텍처·수학·코딩 오류를 해결하며, effort 설정으로 얼마나 깊이 사고할지를 조절합니다.
API에서 추론 effort는 어떻게 설정하나요?
API 요청 페이로드 안에 output_config: { effort: "low" | "medium" | "high" | "xhigh" | "max" }를 전달하여 추론 깊이를 설정합니다. 낮은 effort 레벨은 짧게 사고하고 더 적은 토큰으로 더 빠르게 답변하며, 높은 레벨은 더 깊이 추론합니다. 기존의 budget_tokens 매개변수는 제거되었으며 이제 Fable 5에서 HTTP 400 오류를 반환합니다.
내부 추론 토큰은 단가가 다르게 청구되나요? 아닙니다. 추론 토큰은 모델의 표준 출력 토큰 요율로 청구됩니다. 이 토큰들은 출력 연산을 나타내므로 API 과금에 직접 포함되며, 따라서 소프트웨어 비용을 제어하려면 프롬프트 캐싱과 합리적인 effort 레벨 설정이 필수적입니다.
Fable 5의 응답을 더 빠르게 하려면 어떻게 하나요?
추론은 비활성화할 수 없습니다. Fable 5에서는 사고가 항상 켜져 있으며, thinking: {type: "disabled"}를 전달하면 HTTP 400 오류가 반환됩니다. 지연 시간을 줄이려면 output_config: { effort: "low" }로 effort 레벨을 낮추십시오. 이는 사고 단계를 단축하고 기본적인 대화 작업의 첫 토큰 반응 속도를 최소화합니다.
실시간 SSE 스트림에서 추론 토큰을 어떻게 파싱하나요?
서버리스 SSE 스트리밍 중, 사고 내용은 delta.type이 thinking_delta인 content_block_delta 이벤트를 통해 thinking 콘텐츠 블록으로 도착합니다. 텍스트는 표준 text_delta 출력과 별개로 delta.thinking에서 읽습니다. 읽을 수 있는 요약을 받으려면 thinking: {type: "adaptive", display: "summarized"}로 opt-in 한 뒤, 프론트엔드 UI 선호에 따라 해당 토큰을 렌더링하거나 버리면 됩니다.
댓글