Claude Fable 5의 안전책은 '거절'이 아니라 '구모델로 라우팅'하는 것: Mythos 공개판의 라우팅 설계 분석

어제 6월 9일, Anthropic이 Claude Fable 5를 일반 공개했다. 코딩이나 과학 연구에서 SOTA(State-of-the-Art)를 경신했다는 헤드라인만 본다면 평범한 모델 출시처럼 보인다. 하지만 이번에는 출처가 예사롭지 않다. Fable 5는 사이버 취약점 발견 능력이 너무 높다는 이유로 일부 고객에게만 제공되어 왔던 'Mythos'의 공개판이다.

공식 발표: https://www.anthropic.com/news/claude-fable-5-mythos-5

이 기사에서는 벤치마크나 요금에 대해서는 이야기하지 않겠다. 출시 정보 중에서 설계 판단이 가장 선명하게 드러나는 지점, 즉 "민감한 질문에는 Fable 5가 아니라 구세대 모델이 답한다"라는 라우팅 (Routing) 메커니즘에 집중하여 분석해 보겠다. 이는 자체 LLM 앱을 설계하는 사람들에게도 그대로 적용되는 이야기이기 때문이다.

우선 사실 관계 정리

• 2026-06-09 공개. 위치는 "너무 위험해서 한정 제공되었던 Mythos의 공개판"
• 소프트웨어 엔지니어링, 지식 노동, vision, 과학 연구에서 SOTA를 주장
• vision 입력만 있는 최소한의 하네스(Harness)로 GBA의 포켓몬 FireRed를 클리어하는 데모 있음
• 6/22까지는 Pro/Max/Team/Enterprise에서 추가 과금 없음. 이후에는 $10/M 입력 · $50/M 출력
• 1차 자료인 System Card도 동시 공개: https://www-cdn.anthropic.com/d00db56fa754a1b115b6dd7cb2e3c342ee809620.pdf

요금의 손익분기점이나 벤치마크 해석은 다른 곳에서 충분히 다뤄지고 있으므로 깊게 들어가지 않겠다. 본론으로 들어가자.

위험한 화제에는 "구모델이" 답한다

Ars Technica가 정리한 대로, Fable 5에는 사이버 공격, 생물, 화학 등의 영역에 대한 질문에 대해 Fable 5 자신이 아닌 구세대 모델인 Opus 4.8이 응답하는 메커니즘이 내장되어 있다.

그림으로 나타내면 다음과 같다.

위험한 능력을 가진 모델의 안전 대책이라고 하면 보통 두 가지가 떠오른다. 질문을 거부하거나, 학습 단계에서 능력 자체를 억제하는 것이다. Anthropic이 선택한 것은 제3의 길로, 능력은 최상의 상태로 유지하되 출구에서 응답 모델 자체를 교체하는 액세스 제어 (Access Control)였다.

왜 이런 설계인가

여기서 읽어낼 수 있는 점이 세 가지 있다.

첫 번째. 능력의 제거는 어렵거나 아깝다. Mythos가 한정 제공되었던 이유는 취약점 발견 능력이 너무 강력했기 때문인데, 그 능력은 정당한 보안 연구나 코딩 능력과 같은 뿌리에서 나온다. 학습 단계에서 깎아내면 그 여파로 모델 전체가 저하된다. 모델 내부에서 분리하는 것보다 입구에서 질문을 분류하는 것이 더 합리적이다.

두 번째. 거절보다 경험이 깨지지 않는다. 전부 거절해 버리면 보안 학습자나 CTF 유저와 같은 정당한 사용자를 잃게 된다. 구세대로 넘기면 응답 품질은 한 단계 떨어지더라도 대화는 성립한다. "최신 능력만을 위험 영역으로부터 격리한다"는, 매우 세밀한 입도(Granularity)의 방식이다.

세 번째. 모델 라우터 (Model Router)가 벤더 제품의 내부로 들어왔다. 우리가 LiteLLM이나 API 게이트웨이에서 수행하는 비용 및 성능 라우팅과 동일한 구조를, Anthropic은 안전성을 축으로 제품 내부에 심어 놓았다. 성능 축의 자동 라우팅은 이미 타사에도 존재하지만, "1개 프로덕트 = 1개 모델"이라는 전제가 안전성 축에서도 무너졌음을 의미한다.

개발자를 위한 실무적 함의

여기서부터가 본론의 본론이다. Fable 5 위에 앱이나 에이전트 (Agent)를 구축하는 사람에게는 간과할 수 없는 점이 두 가지 있다.

평가의 재현성. 동일한 엔드포인트 (Endpoint)를 호출하더라도, 안전 분류 판정에 따라 응답하는 모델이 달라질 수 있다. 보안 중심의 태스크, 예를 들어 취약점 보고서 보조나 공격 기법 해설 생성 등을 다루는 프로덕트에서는 회귀 테스트 (Regression Test)의 기준 출력이 "어느 모델이 답했는가"에 따라 흔들린다. 모델을 고정(Pinning)했다고 생각했지만 고정되지 않은, 새로운 종류의 변동성이 생겨난 것이다.

분류의 위양성 (False Positive)이 그대로 UX 비용이 된다. 경계 영역, 예를 들어 익스플로잇 (Exploit)을 해설하는 교육 콘텐츠에서 의도치 않게 구모델로 라우팅될 경우, 사용자에게 보이는 증상은 "오늘은 왠지 답변이 얕다"가 된다. 원인이 라우팅에 있다는 것은 거의 눈치채기 어렵다. 자체적으로 2층 구조를 설계할 때도 마찬가지로, 라우터의 정밀도가 곧 제품 품질의 분산으로 이어진다.

역으로 말하면, 이 구조는 자신의 앱 설계에 대한 모범 사례가 될 수 있다. "위험하고, 비용이 높고, 리스크가 큰 쿼리만 별도 모델로 보낸다"는 안전성 측면에서도, 비용 측면에서도 동일한 패턴으로 작성할 수 있다. 벤더 스스로가 이 패턴을 정식 채택한 이상, 라우팅 계층을 전제로 한 아키텍처 (Architecture)가 표준이 되어 갈 것이다.

무료 이용 기간은 6/22까지입니다. 직접 수행 중인 실제 태스크 (Task)를 던져보며 "어느 지점에서 구모델 (Old Model)로 라우팅되는지" 그 경계를 확인해 두려 한다면, 지금이 가장 저렴한 시기입니다.

마치며

이번 릴리스 (Release)에서 가장 핵심적으로 가져가야 할 점은, SOTA (State-of-the-Art) 수치가 아니라 "최강 모델의 공개가 능력의 문제에서 액세스 설계 (Access Design)의 문제로 변했다"는 사실이라고 생각합니다. 능력을 깎아내리지 않고 출구에서 분류하는 구조는 다른 벤더 (Vendor)들도 추종할 것이며, 그렇게 되면 애플리케이션 (App) 측에서도 "어떤 쿼리 (Query)를 어떤 모델에게 보여줄 것인가"가 설계의 일급 시민 (First-class citizen)이 될 것입니다. 회귀 테스트 (Regression Test)는 모델 단위가 아니라 라우팅 (Routing)을 포함하여 작성해야 합니다. 경계 사례 (Edge Case)의 동작은 무료 이용 기간 내에 직접 확인해야 합니다. 다음 모델 릴리스를 읽을 때는 벤치마크 (Benchmark) 표보다 먼저 라우팅 사양 (Routing Specification)부터 살펴봐야 합니다. 그것이 오늘부터 변화시켜야 할 본인의 읽기 방식입니다.

참고 링크

Discussion