「Opus가 최상위」라고 기억하던 찰나, 그 위가 등장했습니다.

모델명 인플레이션에 지쳐 있는 여러분, 안녕하세요. 안심하세요. 이번 이야기는 단순히 "숫자가 늘어난" 것이 아니라, 계층이 하나 늘어난 구조적 변화에 관한 것입니다. 구조만 파악하면 오히려 정리는 더 쉬워집니다. 이 기사를 통해 3분~5분 만에 파악해 봅시다.

지금까지 Claude의 계급은 3단계였습니다.

(구) Haiku < Sonnet < Opus
(신) Haiku < Sonnet < Opus < Mythos급 (Fable 5 / Mythos 5)

2026년 7월 시점의 주요 라인업을 가격을 포함하여 정리하면 다음과 같습니다.

모델	모델 ID	위치	가격 (입력/출력, 100만 토큰당)
Claude Fable 5	claude-fable-5	일반 제공 최상위 (Mythos급)	USD 10 / USD 50
Claude Mythos 5	claude-mythos-5	승인 조직 한정 (Project Glasswing)	USD 10 / USD 50
Claude Opus 4.8	claude-opus-4-8	일상의 주력 모델 (Workhorse)	USD 5 / USD 25
Claude Sonnet 5	claude-sonnet-5	가성비 라인업. 코딩은 Opus급에 근접	USD 3 / USD 15 (2026-08-31까지 도입 가격 USD 2 / USD 10)
Claude Haiku 4.5	claude-haiku-4-5	빠르고 저렴함	USD 1 / USD 5

Fable 5는 Opus 4.8의 정확히 2배 가격입니다. 컨텍스트(Context)는 100만 토큰, 최대 출력은 128K 토큰입니다.

"Opus를 더 똑똑하게 만들면 되는 것 아닌가?"라고 생각할지도 모릅니다. 하지만 Mythos급의 사양을 나열해 보면, 목표가 단순한 지능의 향상이 아니라 **장시간의 자율 가동 (Autonomous operation)**에 있다는 것을 알 수 있습니다.

사고(Thinking)가 상시 ON 상태이며 끌 수 없음 → 처음부터 얕은 즉답을 상정하지 않음 -
컨텍스트 1M 토큰 · 최대 출력 128K → 수십 번 도구(Tool)를 호출하며 실행하는 장기전이 전제됨 -
1개 요청(Request)이 수 분 ~ 십수 분 → "대화하는" 단위가 아니라 "업무를 맡기는" 단위

즉, 이것은 "즉답이 똑똑한 모델"이 아니라 "수 시간의 업무를 혼자서 완수하는 모델"입니다. 반대로 말하면, 이러한 특성이 필요 없는 업무——짧은 정형 응답, 저지연(Low latency)이 필수적인 채팅, 분류·정형화——에서는 가격 차이에 걸맞은 차이가 나타나기 어렵습니다. 이것이 이 티어(Tier)의 명확한 한계이며, 후술할 판단 흐름에서 "대부분의 사람은 교체할 필요가 없다"라고 단언할 수 있는 이유이기도 합니다.

이 부분이 가장 오해하기 쉬운 포인트입니다.

**동일한 기반 모델 (Foundation Model)**입니다. 능력·가격·API 서피스(Surface)는 거의 동일합니다 -
Fable 5: 누구나 사용할 수 있습니다. 단, 바이오·사이버 등의 이중 용도(Dual-use) 영역에 **추가적인 안전 분류기 (Safety classifier)**가 포함되어 있습니다 -
Mythos 5: 해당 안전 조치 없이 제공되는 대신, 심사를 통과한 조직만 (Project Glasswing 경유) 사용할 수 있습니다

즉 "성능의 차이"가 아니라 "제공 조건의 차이"입니다. 일반 사용자가 신경 써야 할 것은 Fable 5뿐이며, Mythos는 "그런 영역도 있다"라고 알고 있으면 충분합니다.

참고로 이름은 Fable(우화)과 Mythos(신화)입니다. Haiku(하이쿠) → Sonnet(소네트) → Opus(대작)로 이어져, 마침내 신화에 도달했습니다. 모델명이 점점 문학부스러워지고 있지만, 내용은 이과입니다 (※ 학부는 관계없습니다).

API를 사용하는 분들을 위한 요점입니다.

사고(Thinking)는 상시 ON:
thinking 파라미터를 생략하면 됩니다. 명시적으로 disabled로 설정하려고 하면 400 에러가 발생합니다. 깊이(Depth)는 effort (low~max)로 제어하는 설계로 변경되었습니다 -
가공되지 않은 사고 로그는 반환되지 않음:
display: "summarized"

를 지정하면 요약된 사고(thinking)를 볼 수 있습니다. 기본값은 비표시 -
1턴이 김: 어려운 태스크의 경우 1회 요청(request)이 몇 분에서 십수 분 동안 실행되는 일이 흔합니다. 타임아웃 설계, 스트리밍(streaming), 진행 상황 표시가 필수적인 전제 조건입니다 -
refusal(거부) 대응: 안전 분류기(safety classifier)가 HTTP 200과 함께 stop_reason: "refusal"을 반환하는 경우가 있으며, 보안 업무와 같은 무해한 작업에서도 오작동할 수 있습니다. fallbacks 파라미터(베타)를 추가해 두면, 거부 시 동일한 요청 내에서 Opus 4.8로 자동 퇴피(fallback)할 수 있습니다 -
운영 요건: 30일 데이터 보존이 필수입니다. 제로 데이터 보존(ZDR) 설정 조직에서는 모든 요청이 400 에러가 발생하므로, 계약 설정을 먼저 확인해야 합니다.

Opus 4.7 이후의 흐름을 계승하고 있으므로, 오래된 코드에서 마이그레이션할 때 다음 사항들이 지뢰가 될 수 있습니다.

thinking: {type: "enabled", budget_tokens: N}

→ 400 (adaptive로 변경됨) -
thinking: {type: "disabled"}

→ 400 (Fable 5는 파라미터 자체를 생략) -
temperature / top_p / top_k

→ 400 (삭제해야 함) -
어시스턴트 프리필(assistant message를 마지막에 배치하는 기술) →
400 (structured outputs로 변경) -
max_tokens가 작은 상태 유지 → 사고 과정이 긴 만큼, 여유를 두지 않으면 중간에 끊깁니다.

"어제까지 잘 작동하던 코드가 모델 ID를 바꾸는 순간 400 에러의 비를 맞는다"는 이 업계의 풍경이지만, 먹구름의 위치를 알고 있다면 우산을 쓸 수 있습니다.

흔한 실패 사례 중 하나를 들어보겠습니다. 모델 ID는 설정 파일에서 교체했지만, 공통 API 래퍼(wrapper) 깊숙한 곳에 temperature: 0이 하드코딩되어 있어, 모든 엔드포인트가 일제히 400 에러를 뱉는 것이 마이그레이션 사고의 전형적인 패턴입니다. 파라미터는 코드 깊은 곳에 묻혀 있는 경우가 많으므로, 마이그레이션 전에 temperature|top_p|top_k|budget_tokens 정도로 리포지토리를 grep 해두면 먹구름의 위치를 미리 파악할 수 있습니다.

솔직히 말해서, 대부분의 사람은 오늘 당장 갈아탈 필요가 없습니다.

• 일상적인 코딩·에이전트 업무 → Opus 4.8 유지 (능력이 충분하며 가격은 절반) -
• 대량 처리·가성비 중시 → Sonnet 5 (현재 도입 가격으로 더욱 저렴) -
• 분류·정형화 등의 경작업 → Haiku 4.5 -
• 수 시간 동안 실행되는 자율 에이전트, 최난도 설계·조사·디버깅 → Fable 5를 시도해 볼 가치가 있음. 1회 요청에 시간은 걸리지만, 인간이 매달리는 시간까지 포함한 토탈 비용 측면에서는 더 저렴할 수 있습니다.

이 흐름을 도식화하면 다음과 같습니다. 위에서부터 순서대로 판단해 나가면 길을 잃지 않습니다.

기준은 "Opus 4.8로 2~3번 다시 시도해도 납득할 만한 결과가 나오지 않는 태스크"가 나타나면, 그것을 Fable 5에 던져보는 것입니다. 차이가 없다면 다시 돌아오면 그만입니다. "일단 최강 모델을 상시 사용하고 싶다"는 마음은 이해하지만, 우선 다음 달 청구서와 상담하십시오.

비용감의 기준도 적어둡니다 (공식 단가 기준의 기계적 추산이며, 실측치는 아닙니다). 입력 10만 + 출력 3만 토큰의 무거운 요청 1회당, Fable 5는 약 2.50 USD, Opus 4.8은 약 1.25 USD입니다. 만약 하루에 20번 요청한다고 가정하면 차액은 하루 약 25 USD, 한 달로 치면 약 750 USD입니다. "엔지니어가 매달리는 시간이 줄어든다면 싸다"고 볼 것인지, "월 750달러의 고정비"로 볼 것인지는 태스크에 따라 다릅니다. 그렇기 때문에 전면 마이그레이션이 아닌 "최난도 작업만 Fable"이라는 구분 사용이 효과적입니다.

Q. Mythos 5는 신청하면 누구나 사용할 수 있나요?

A. 아니요. Project Glasswing을 통한 심사를 통과한 조직에 한정됩니다. 일반 개발자가 접할 기회는 당분간 없다고 생각해도 무방합니다. 능력은 Fable 5와 동일하므로 부러워할 필요도 없습니다.

Q. Fable 5로 바꾸면 무엇이든 똑똑해지나요?

A. 그렇지 않습니다. 짧은 정형 태스크나 분류 작업에서는 Opus 4.8 이하 모델과의 차이가 거의 없으며, 가격만 2배가 됩니다. 차이가 발생하는 영역은 "장시간·다단계·최난도" 영역입니다.

Q. refusal(거부)가 반환되면 프롬프트가 잘못된 건가요?

A. 반드시 그렇지는 않습니다. 안전 분류기의 오작동(보안 업무나 라이프 사이언스 계열의 무해한 작업에서도 발생할 수 있음) 가능성이 있으므로, 우선 stop_details

카테고리를 확인하고, fallbacks를 통해 Opus 4.8로 자동 퇴피(fallback)시키는 것이 정석입니다.

• Claude 5 패밀리는 **Opus 위의 새로운 티어(tier)**입니다. Fable 5(일반 제공)와 Mythos 5(승인된 조직 한정)는 동일한 모델이며, 차이점은 안전 조치와 제공 조건입니다. - API 측면의 변화: 사고(Reasoning) 상시 활성화, effort로 제어, 장시간 턴(turn) 전제, refusal + fallbacks, 30일 데이터 보유 필수
• 주력은 Opus 4.8 / Sonnet 5를 그대로 유지해도 좋습니다. Fable은 "최난도 작업의 히든카드"로서 테스트해 보세요.

참고 링크

• 공식 발표: https://www.anthropic.com/news/claude-fable-5-mythos-5
• 모델 목록 및 가격: https://platform.claude.com/docs/en/about-claude/models/overview

*최신 모델 해설, 수요가 있다면 계속하겠습니다. "사용 후기" 편을 보고 싶으시다면 '좋아요'로 투표해 주세요.