주식회사 Good Lab에서 엔지니어로 일하고 있는 코타로입니다.

매일 Java, SQL, Git 등의 기술 정보와 신입 엔지니어를 위한 학습 노하우, AI 활용에 관한 정보를 발신하고 있습니다.

Good Lab에 대해 궁금하신 분은 코퍼레이트 사이트도 꼭 확인해 주세요.

▶ 코퍼레이트 사이트

Anthropic으로부터 신규 모델 **Claude Fable 5 (claude-fable-5)**가 등장했습니다.

지금까지 Claude의 모델 라인업은 「Opus (최상위) > Sonnet (밸런스) > Haiku (경량)」의 3단계 티어 구성이었으나, Fable 5는 Opus 티어보다 더 위에 위치하는 새로운 티어입니다. 즉, Anthropic의 모델 역사상 「가장 고성능이며 가장 지능이 높은 모델」이 Opus 위에 신설된 형태가 됩니다.

본 기사에서는 공식 Models / Migration 문서에서 확정된 정보만을 바탕으로,

• Fable 5의 위치 선정과 스펙·요금
• API 측면에서의 타 모델과의 차이 ( 사실 파괴적 변경(Breaking Change)은 단 하나뿐 )
• thinking · 샘플링 파라미터(sampling parameter) · prefill 관련 구현상의 주의사항
• 프롬프트 캐시(Prompt Cache)의 최소 접두사(minimum prefix)라는 매니아틱한 동작 차이
• Opus 4.8과의 활용 구분

을 정리합니다. Messages API를 직접 호출하는 분이나 Agent SDK로 에이전트를 구축하고 있는 분들을 위한 내용입니다.

포인트는, Fable 5가 「Opus의 대체재」가 아니라는 점입니다. 공식 문서상으로도 일반적인 AI 앱 구축의 기본값은 Opus 4.8 등의 고성능 모델 그대로이며, Fable 5는 「최고의 정밀도가 필요한 상황을 위한 최상위 선택지」로 정리되어 있습니다.

모델 ID가 에일리어스만 존재(날짜 접미사 없음)한다는 점도 기존의 claude-opus-4-8 등과 동일한 명명 스타일입니다.

가격은 Opus 4.8의 입력 2배·출력 2배입니다. 컨텍스트 윈도우(1M)와 최대 출력(128K)은 Opus 4.8과 동일하므로, 「같은 그릇에 더 높은 지능을 2배의 가격으로」라는 포지셔닝이라고 이해할 수 있습니다.

참고: 128K의 최대 출력을 온전히 사용하려면 스트리밍이 필수입니다. 비스트리밍(non-streaming) 방식의 경우 max_tokens를 16,000 정도까지 억제하는 것이 기준입니다 (후술할 코드 예시 참조).

Fable 5의 API는 기본적으로 **Opus 4.7 / 4.8과 동일한 요청 인터페이스(request surface)**입니다. 이전 작업은 「모델 ID 교체 + 프롬프트 재조정」이 중심이며, Opus 4.7 → 4.8 때와 마찬가지로 새로운 파괴적 변경은 거의 없습니다.

단, Fable 5 고유의 파괴적 변경이 단 하나 있습니다.

Opus 4.7 / 4.8 : thinking: {type: "disabled"} → 허용됨
Fable 5 : thinking: {type: "disabled"} → 400 에러

Fable 5에서는 thinking을 비활성화하고 싶더라도 disabled를 명시해서는 안 됩니다. thinking 파라미터 자체를 생략하는 것이 정답입니다.

Opus 4.7/4.8로 이전할 때 "일단 disabled를 명시해 두자"라는 식으로 코드를 작성했다면, Fable 5로 교체하는 순간 400 에러와 함께 작동이 중단되므로 이전 전에 grep으로 확인해 두시기 바랍니다.

다음은 Fable 5에 국한된 것이 아니라, Opus 4.7/4.8에서 이미 도입된 제약 사항입니다. 구형 모델(Sonnet 4.5 이전 등)에서 Fable 5로 한꺼번에 이전하는 경우에는 이 모든 사항에 해당합니다.

"어떤 모델에 어떤 thinking 설정을 보내도 되는가"는 세대마다 다르며, 이전 시 가장 밟기 쉬운 지뢰입니다. 이를 요약표로 정리합니다.

여러 모델을 교체하며 사용하는 애플리케이션에서는 "thinking을 붙일지 말지", "어떤 형식으로 붙일지"를 모델별로 분기 처리해야 합니다. 구현 방침으로는 다음과 같이 나누는 것이 가장 심플합니다.

• Fable 5 / Opus 4.8 / 4.7: thinking: {type: "adaptive"}를 붙이거나, 필요 없다면 통째로 생략
• 구형 모델: 기존 방식대로 enabled + budget_tokens의 두 계통으로 구분

import anthropic
# API 키는 환경 변수 ANTHROPIC_API_KEY에서 읽어옵니다 (하드코딩 금지)
client = anthropic.Anthropic()
...

import anthropic
client = anthropic.Anthropic()
with client.messages.stream(
...

import Anthropic from "@anthropic-ai/sdk";
// API 키는 환경 변수 ANTHROPIC_API_KEY에서 읽어옵니다
const client = new Anthropic();
...

✕ Fable 5 고유의 NG: disabled 명시

thinking={"type": "disabled"}

✕ budget_tokens는 완전 삭제 (Opus 4.7 이후와 공통)

...

미미하지만 흥미로운 모델 차이가 프롬프트 캐시 (Prompt Cache)에 있습니다. 캐시가 작동하기 시작하는 최소 접두사 길이 (Minimum Prefix Length) 가 모델마다 다릅니다.

즉, 동일한 약 3000 토큰의 시스템 프롬프트(System Prompt)라도, Opus 4.8에서는 캐시되지 않지만 (4096 미만), Fable 5에서는 캐시되는 (2048 이상) 라는 동작 차이가 발생합니다.

Fable 5는 단가가 높은 만큼, 캐시 히트 (Cache Hit) 임계값이 낮은 것은 비용 측면에서 이득인 사양입니다. Opus 계열에서 이행할 경우, "Opus에서는 캐시가 작동하지 않았던 중규모 프롬프트가 Fable 5에서는 작동하게 되는" 케이스가 있기 때문에, 비용 산출은 단순하게 "2배"로 끝나지 않을 수 있습니다.

입력·출력 모두 Opus 4.8의 2배 가격($10/$50 대 $5/$25)이므로, "전부 Fable 5"를 사용하는 것은 명백한 과잉 투자입니다. 공식 정리대로, 기본값은 Opus 4.8 등의 고성능 모델로 설정하고, Fable 5는 핀포인트로 사용하는 것이 현실적입니다.

문제는 "어디가 그 핀포인트인가"입니다. 판단 기준으로 정리해 보겠습니다.

Fable 5를 선택할 가치가 있는 것은 다음 3가지 조건 중 하나가 적용될 때입니다.

역으로 말하면, "횟수가 많음 ・ 다시 할 수 있음 ・ 인간이 저렴하게 검증할 수 있음"인 태스크는 Opus 4.8 이하로 충분합니다. 실패해도 재시도(Retry)하면 되고, 출력의 정오를 즉시 판정할 수 있는 태스크에 최고 단가 모델을 할당할 이유는 없습니다.

참고로, Fable 5와 Opus 4.8의 정밀도 차이를 벤치마크 수치로 말할 수 있는 확정 정보는 아직 없으므로, 본 절은 "최고 정밀도가 필요한 상황에서 최상위 모델을 사용한다"는 상대적인 정리로 갈음합니다.

상황: 수년간 운용해 온 모놀리스(Monolith)를 서비스 분할하고 싶다. 경계 후보가 여러 개 있으며, 모두 나름대로 타당해 보인다.

왜 Fable 5인가: 경계를 나누고 DB를 분리하며 팀 편성까지 맺어진 후에 "나눌 곳을 잘못 정했다"는 것을 깨달으면, 되돌리는 데 수개월 단위의 비용이 듭니다. 후보 도출 및 의존성 분석은 Opus 4.8로 돌리고, 의존 관계 그래프 ・ 트랜잭션 경계 ・ 팀 구성까지 읽게 한 최종 판단(Final Judge)의 단 1회만 Fable 5에게 맡기는 방식이 수지타산이 맞습니다.

상황: 구독 상태 관리나 인증 플로우 등, 출시 후에 다시 만들 수 없는 부분의 설계를 확정하고 싶다.

왜 Fable 5인가: 과금 버그는 환불 대응 및 스토어 리뷰 악화로 직결되며 (조건 a), "정상 계통에서는 작동하지만 만료 ・ 복구 ・ 오프라인의 조합에서 깨지는" 종류의 결함은 인간의 리뷰에서도 놓치기 쉽습니다 (조건 b). 설계서와 코드를 맞추어 "깨지는 시나리오를 열거해줘"라고 최고 정밀도로 1회 리뷰를 맡길 가치가 있습니다.

상황: 장기 운용 프로덕트에서 코드 ・ 사양서 ・ 과거 장애 보고서 사이에 괴리가 쌓여 있다는 의심이 든다.

왜 Fable 5인가: 1M 컨텍스트에 전부를 올려 대조하는 태스크는 입력이 클수록 "어딘가 한 곳의 간과"가 일어나기 쉬우며, 그 간과야말로 다음 장애의 씨앗이 됩니다. 입력 토큰이 지배적인 이 계열의 태스크는 원래 1회당 절대 금액이 큰 만큼, "재시도 실행 비용 + 간과로 인한 손해"와 비교하면 2배 차이는 오차 범위 내로 들어오기 쉬운 장면입니다.

상황: 한 달에 몇 번밖에 발생하지 않는 데이터 불일치. 로그, 스레드 덤프(Thread Dump), 해당 코드는 모두 갖춰져 있지만, 사람이 며칠 동안 매달려도 원인을 좁힐 수 없는 상태.

왜 Fable 5인가: 여기서의 비교 대상은 API 요금이 아니라 엔지니어의 디버깅 시간입니다. 가설의 질이 한 단계 높아져 조사 시간이 하루 단축된다면, 몇 달러의 차이는 문제가 되지 않습니다. "가능한 원인을 확신도 순으로, 검증 방법과 함께 나열해 줘"라는 단 한 번의 가설 도출에 사용합니다.

상황: 외부 공개용 REST API의 v1을 출시한다. 엔드포인트 설계, 페이지네이션(Pagination), 에러 형식을 이제부터 확정해야 하는 단계.

왜 Fable 5인가: 공개 후의 파괴적 변경(Breaking Change)은 버저닝, 이행 기간, 이용자 대응 비용이 매우 높기 때문에, "릴리스 전 마지막 리뷰 1회"가 가장 투자 효율이 높은 타이밍입니다. 초안 상태의 OpenAPI 명세를 읽게 하여, 향후 확장 시 문제가 될 부분이나 일관성이 결여된 부분을 지적하게 합니다.

상황: 예를 들어 "SwiftData인가, Core Data + CloudKit인가"와 같이, 나중에 교체하려면 데이터 이행(Migration)부터 다시 만들어야 하는 선정 단계. 비교표는 Opus 4.8로 이미 작성 완료.

왜 Fable 5인가: 선정 그 자체보다 "비교표에서 누락된 관점(마이그레이션 제약, OS 버전 요구사항, 철수 비용)을 지적하는 것"에서 최상위 모델의 가치가 드러납니다. 비교표와 자신들의 제약 조건을 전달하여, 결론과 놓친 관점을 한 번에 뽑아내게 합니다.

고빈도 배치 분류·라벨링: 태스크가 단순하여 정확도가 Opus / Sonnet에서 한계에 부딪히기 쉬운 데다, 건수가 많기 때문에 2배의 요금이 그대로 2배의 청구로 이어집니다. 회수할 전망이 없는 전형적인 사례 -
단순 요약·추출: 위와 동일. 오히려 Sonnet 4.6 / Haiku 4.5로 낮추는 방향을 검토해야 할 장면에서, 상위 모델로 올리는 것은 역행입니다.

"실행은 Opus 4.8, 최종 판단(Final Judge)만 Fable 5"가 비용 2배 대비 가장 효율적인 구성입니다. 서브 에이전트(Sub-agent) 구성의 이미지는 다음과 같습니다.

[조사 에이전트]──┐
claude-opus-4-8 │ 후보안·분석 결과 집약
[분석 에이전트]──┼──→ [최종 판단]──→ 인간이 승인
...

코드로 작성한다면, 모델 선택을 하나의 함수에 모아두어야 교체가 쉽습니다.

def select_model(task_type: str) -> str:
    """되돌아오는 비용(Rollback Cost)이 큰 최종 판단에만 Fable 5를 할당한다"""
    if task_type in ("final_judgement", "core_design_review"):
        ...

포인트는 Fable 5의 호출을 **횟수가 늘어나지 않는 위치(파이프라인의 종단·루프의 외부)**에 두는 것입니다. 루프 안으로 들어가는 순간, 단가 차이가 횟수만큼 배가되어 적용됩니다.

• 실수했을 때 며칠 이상의 재작업이 발생하거나, 공개 후에 변경하기 어려운 판단인가?
• 다시 시도할 수 없거나, 인간에 의한 검증·디버깅 비용이 높은가?
• 입력이 대규모·복잡하여, 아주 작은 간과가 치명적이 되는가?

이행 자체는 모델 ID를 교체하는 것으로 거의 완료되지만, thinking: {type: "disabled"}를 명시하고 있는 코드만은 사전에 정리해 두도록 합시다.

• Models overview - Anthropic
• Extended thinking - Anthropic
• Prompt caching - Anthropic
• Messages API - Anthropic

@kotaro_ai_lab

AI 활용 및 개발 효율화에 대해 발신하고 있습니다. 팔로우는 언제든 환영입니다!