Fable 5가 사라졌습니다. 더 적은 비용으로 더 나은 결과를 얻기 위해 제가 사용하는 방법입니다.

우리는 Fable과 함께한 3일을 보냈습니다.

자율 코딩 (autonomous coding), 장기 추론 (long-horizon reasoning), 그리고 연구 합성 (research synthesis)이 진정으로 다르게 느껴졌던 3일이었습니다. 단순히 "지난 분기보다 약간 나은" 수준이 아니었습니다. 완전히 다른 무언가였습니다.

그러다 미국 상무부 (US Commerce Department)에서 서한을 보냈고, 미국인을 포함한 전 세계 모든 사용자에 대해 모델이 오프라인 상태가 되었습니다. 다른 법적 선택지가 없었기 때문입니다. 접근 권한은 서비스 종료 기간 (deprecation window)이나 마이그레이션 경로 (migration path)에 대한 안내도 없이, 실시간 서비스에서 순식간에 사라졌습니다.

그리고 우리가 다시 그 정도 수준의 모델을 볼 수 있을지는 알 수 없습니다.

충격은 금지 조치 그 자체 때문이 아니었습니다. 그 금지가 드러낸 사실 때문이었습니다. 즉, 정부의 서한 한 통에 12시간 만에 꺼질 수 있는 인프라 위에서 우리의 전체 프로덕션 워크플로우 (production workflow)가 돌아가고 있었다는 사실입니다.

프로덕션 (prod) 환경에서는 용납될 수 없는 일입니다.

그래서 다음으로 가장 좋은 모델을 찾기 위해 리더보드 (leaderboards)를 확인하거나, 일어날 수도 있고 일어나지 않을 수도 있는 복구를 기다리는 대신, 진짜 움직임은 다른 질문을 던지는 것이었습니다. "Fable을 무엇이 대체할 것인가"가 아닙니다. 실제 질문은 이것이었습니다: 만약 우리가 중요한 작업을 단 하나의 프런티어 오라클 (frontier oracle)로 라우팅하고 있었다면, 우리는 무엇을 사고 있었던 것인가? 그리고 구조적으로 더 나은 무언가가 존재하는가?

요약 (TL;DR): 프런티어 판사 (frontier judge)를 활용한 모델 패널이 심층 연구 벤치마크 (deep research benchmarks)에서 Fable 5 단독 모델을 이기며, 예산 설정 (budget configuration) 시 약 절반의 비용으로 실행됩니다. 문제는 Fable이 사라진 것이 아닙니다. Fable이 아직 여기에 있을 때 우리가 더 나은 무언가를 발견했다는 점입니다.

Fable이 오프라인이 된 밤

대부분의 사람들은 똑같은 세 가지 반사 작용을 보였습니다: 리더보드에서 다음으로 가장 좋은 모델을 찾거나, Fable이 돌아오기를 기다리거나, X(구 트위터)에서 불평하는 것입니다.

이 세 가지 모두 잘못된 프레임입니다.

Fable 금지는 이례적인 사건이 아니라 하나의 데이터 포인트입니다. 미국 정부의 지시로 상용 배포된 프런티어 모델 (frontier model)이 전 세계적으로 12시간 이내에 철수된 것은 이번이 처음입니다. 우리가 의존하는 모델이 어떤 이유로든 우아한 인수인계 (graceful handoff) 없이 사라지는 일은 이번이 마지막이 아닐 것입니다.

만약 당신의 프로덕션 파이프라인 (production pipeline)이 단일 모델 의존성 (single-model dependency)을 가지고 있다면, Fable 금지는 방금 그 아키텍처 문제 (architecture problem)를 가시화한 것입니다.

저는 금지 조치가 내려진 당일에 그에 대해 글을 썼습니다. 이것은 그로부터 일주일 뒤에 제가 구축한 것입니다.

오라클의 함정 (The Oracle Trap)

하나의 모델에 프롬프트(prompt)를 보내는 것은 하나의 관점, 즉 하나의 아키텍처 (architecture), 하나의 학습 혼합 (training mix), 하나의 실패 모드 (failure modes) 세트를 요청하는 것입니다. 이를 있는 그대로 부릅시다: 오라클 (oracle)이라고 말이죠. 당신의 모든 중요한 결정들을 하나의 프론티어 모델 (frontier model)에만 의존하는 것은, LLM 버전의 '유리 대포 (glass cannon)' 전략과 같습니다. 운이 좋은 날에는 최대의 출력을 내지만, 예상치 못한 움직임 하나에 전체 빌드 (build)가 오프라인 상태가 되어버립니다.

OpenRouter가 공개한 DRACO 벤치마크 (benchmark) 결과에 대한 TokenMix의 분석에 따르면, Fable 5는 법률, 의학, 금융 및 제품 분석을 아우르는 100개 과제의 심층 연구 평가에서 단독으로 65.3%를 기록했습니다. Fable 5와 GPT-5.5로 구성된 패널은 Opus 4.8을 심판으로 하여 69.0%를 기록했습니다.

더 흥미로운 데이터 포인트는 예산 패널 (budget panel)입니다: Gemini 3 Flash, Kimi K2.6, DeepSeek V4 Pro. 이 조합은 Fable 5와 1 벤치마크 포인트 차이인 64.7%를 기록했으며, 비용은 약 40% 수준이었습니다.

이 내용을 스크린샷 찍기 전에 주의할 점이 있습니다: DRACO에는 코딩 도메인 (coding domain)이 포함되어 있지 않습니다. 이 수치들은 연구 및 분석 작업, 법률적 종합 (legal synthesis), 의학적 추론 (medical reasoning), 비교 평가를 다룹니다. 순수 코드 생성 (code generation)의 경우, 이 데이터가 직접적으로 적용되지는 않습니다. 이 점을 유념하십시오.

이 수치들 속에는 더 긴 통찰이 숨겨져 있습니다. 프론티어 모델 경쟁의 전체 전제는 더 똑똑한 단일 모델이 더 나은 결과를 만들어내며, 올바른 투자는 주어진 모델을 더 똑똑하게 만드는 것이라는 점이었습니다. 하지만 DRACO 결과는 다른 프레임 (frame)을 제시합니다: 숙의의 아키텍처 (architecture of deliberation)가 개별적인 목소리의 지능보다 더 뛰어난 성능을 발휘한다는 것입니다. 경영진은 이미 수십 년 동안 이를 이해해 왔습니다 (위원회, 레드 팀 (red teams), 악마의 변호인 (devil's advocates), 동료 검토 (peer review)). 당신은 가장 비싼 분석가를 방에 혼자 가두어 두고 그가 내뱉는 첫 번째 말을 그대로 받아들이지 않습니다. 대신 이견을 강제하고 이를 해결하는 프로세스 (process)를 구축합니다. AI 개발은 3개의 중간급 시스템 간의 구조화된 논쟁이 1개의 탁월한 시스템의 무결점 출력보다 더 나은 성능을 낼 수 있는지 묻지도 않은 채, 지난 5년 동안 '더 똑똑한 단일 모델'이라는 플레이북 (playbook)을 따라왔습니다. 결과적으로, 그것이 가능할 수도 있다는 것이 밝혀졌습니다.

대부분의 벤치마크 (benchmarks)는 단거리 질주를 측정합니다. Perspective Council는 위원회를 운영하며, 이는 더 느리고 더 짜증 나지만, 일반적으로 더 정확합니다.

Perspective Council

Perspective Council: 다중 모델 심의 프레임워크 (Multi-Model Deliberation Framework)

이전에는 두 가지 접근 방식이 존재했습니다.

이전 (Before):

패널 방식 (The panel approach): 동일한 프롬프트 (prompt)를 여러 모델에 병렬로 보내고, 판사 (judge)가 이를 종합하게 합니다. 이를 통해 모델 다양성 (model diversity, 즉 서로 다른 아키텍처 (architectures), 서로 다른 학습 (training), 서로 다른 실패 모드 (failure modes))을 얻을 수 있습니다. 상관관계가 있는 오류들이 독립적인 오류들에 의해 거부되므로, 패널은 개별 구성원보다 더 높은 점수를 받습니다.

다중 관점 스캔 (The multi-perspective scan): 1개의 모델에 서로 다른 전문가 페르소나 (expert personas)를 순차적으로 할당합니다. "보안 아키텍트 (security architect)로서 답변하세요." "회의적인 경제학자 (skeptical economist)로서 답변하세요." 이를 통해 역할 다양성 (role diversity)과 동일한 기반 모델로부터 도출되는 서로 다른 추론 프레임 (reasoning frames)을 얻을 수 있습니다.

이후 (After):

Perspective Council는 이 두 가지를 동시에 쌓아 올립니다. 각 패널리스트 모델은 프롬프트를 처리하기 전에 서로 다른 전문가 페르소나 접두사 (persona prefix)를 받습니다. 보안 아키텍트 페르소나는 1번 모델에게, 회의적인 경제학자는 다른 모델에게, 시스템 역사가는 세 번째 모델에게 할당됩니다.

판사 (별도의 프런티어 모델 (frontier model) 호출)는 모든 응답을 읽고, 전문가들이 동의하는 부분과 모순되는 부분을 기록하며, 그 패턴으로부터 단일 출력을 종합합니다.

이 방식이 단일 접근 방식보다 뛰어난 이유: 역할 다양성이 없는 패널은 아키텍처의 변동성 (architectural variance)은 얻지만 상관관계가 있는 추론 프레임을 갖게 됩니다. 유사한 학습을 거친 2개의 프런티어 모델은 서로 다른 메커니즘을 통해 동일한 잘못된 결론에 도달할 수 있습니다. 1개의 모델을 사용하는 다중 관점 스캔은 프레임 다양성은 얻지만 1세트의 아키텍처적 사각지대 (architectural blind spots)를 갖게 됩니다. Perspective Council는 두 가지 변동성 축을 동시에 확보합니다.

이것이 벤치마크 수치가 유지되는 핵심 이유라고 생각하지만, 이를 확정된 과학으로 취급하기 전에는 독립적인 재현 (independent replication)이 필요할 것입니다.

테스트 중에 발견한 점이 있습니다. 저는 동일한 아키텍처 질문을 Opus 4.8을 통해 한 세션 내에서 두 번 실행했습니다. 처음에는 직접적인 패널리스트 (panelist)로서, 그다음에는 다른 3개 모델의 출력을 합성하는 심판 (judge)으로서 실행했습니다. 패널리스트의 답변은 완전하고 자신감이 있었습니다. 하지만 심판의 답변은 패널리스트가 의문을 제기하지 않았던 2가지 가정 (assumptions)을 포착해냈습니다. 동일한 모델, 동일한 질문, 체인 내의 다른 위치, 그리고 다른 답변이었습니다. 저는 이에 대해 계속 고민해 왔습니다.

날카로운 페르소나 접두사 (persona prefixes)는 이 방식이 성공하거나 혹은 무너지는 지점입니다. 모호한 페르소나는 스타일의 변화를 만들어낼 뿐, 진정한 의견 불일치를 만들어내지 못합니다. 날카로운 브리프 (briefs)는 심판이 제 역할을 수행하는 데 필요한 모순을 만들어내며, 전체 프롬프트 계약 프레임워크 (the full prompt contracts framework) (모든 LLM 호출에 대한 입출력 계약을 다룸)는 페르소나 설계로 직접 연결됩니다. 즉, 각 접두사는 해당 목소리가 어떤 최적화 목표 (optimization objective)를 수행하는지 명시하는 계약입니다.

이를 설정하는 3가지 방법

페르소나는 프롬프트 접두사입니다. 각 패널리스트 호출 시 실제 프롬프트 앞에 이를 주입합니다. 모든 도구는 이를 기본적으로 지원합니다. 인프라 선택의 핵심은 병렬 호출과 심판의 합성을 어떻게 오케스트레이션 (orchestrate) 하느냐에 달려 있습니다.

Level 1: OpenRouter Fusion

단 한 줄의 변경: "model": "openrouter/fusion". Fusion은 웹 검색이 활성화된 모델 패널에 프롬프트를 병렬로 뿌려주며, 심판이 그 결과를 합성합니다. 페르소나 계층의 경우, Fusion에 도달하기 전에 프롬프트에 수동으로 접두사를 붙이십시오. 어떤 하위 모델이 어떤 역할을 맡을지는 제어할 수 없으며, Fusion이 내부적으로 이를 관리합니다.

가장 적합한 경우: 인프라를 건드리지 않고 5분 이내에 개념을 검증하고 싶을 때. 드물게도, 당신의 로컬 환경에서 작동한다면 프로덕션 (prod)에서도 작동합니다.

한계: 페르소나와 모델 간의 라우팅 (routing)에 대한 세밀한 제어가 불가능합니다.

Level 2: Gavel

기존 API 키를 통해 Claude, Codex, Gemini를 병렬로 실행합니다. Claude가 판사 (judge) 역할을 맡습니다. 다른 모델들은 파일에 대해 읽기 전용 (read-only) 상태이므로, 실제 코드베이스에서 안전하게 사용할 수 있습니다 (Claude가 아닌 모델들은 아무것도 작성할 수 없습니다). 각 모델은 작업 프롬프트 설정 (task prompt config)을 통해 전문가 페르소나 (expert persona)를 부여받습니다.

가장 적합한 대상: 이미 3개의 API 구독을 보유하고 있으며, 라우팅 (routing) 코드를 직접 소유하고 싶은 빌더 (builders).

Level 3: OrcaRouter Routing DSL

OrcaRouter의 YAML 기반 라우팅 DSL (Routing DSL)을 사용하면 약 12줄 내외로 패널 (panel)을 정의할 수 있습니다. 어떤 모델이 팬 아웃 (fan out)할지, 어떤 모델이 판사 (judge) 역할을 할지, 어떤 중재 전략 (arbitration strategy)을 실행할지 (best_of_n, consensus, first_to_finish)를 결정합니다. 그들의 블로그에는 시작점으로 삼을 수 있는 실제 작동하는 설정 (config)이 그대로 게시되어 있습니다. 페르소나는 YAML이 아닌 프롬프트 호출 (prompt calls)에 포함됩니다. YAML은 오케스트레이션 (orchestration)을 담당하고, 프롬프트는 역할 (role)을 담당합니다.

지연 시간 (latency)보다 정밀도가 더 중요한 경우, llm-consortium은 신뢰도 임계값 (confidence threshold)에 수렴할 때까지 패널을 재실행합니다. 지연 시간은 더 길지만 더 정밀하며, 알아둘 가치가 있습니다. 완전히 자체 호스팅 (self-hosted) 가능한 CLI 대안을 선호한다면, OpenFusion이 관리형 레이어 (managed layer) 없이 best_of_n 및 consensus를 지원합니다.

가장 적합한 대상: 라우팅 그래프 (routing graph)의 버전을 관리하고, 모든 호출을 로깅하며, 재배포 없이 전략을 업데이트해야 하는 프로덕션 설정 (production setups).

현재 단계에 따라 선택하세요: 오늘 당장 개념을 검증하고 싶다면 Fusion을 선택하세요. 이미 3개의 API 구독을 보유하고 있고 코드를 직접 소유하는 것을 선호한다면 Gavel을 선택하세요. 다음 인프라 장애 상황에서도 중단 없이 작동해야 하는 프로덕션 크리티컬 (production-critical)한 무언가를 구축하고 있다면 OrcaRouter를 선택하세요.

의회(Council)가 비용을 정당화할 때

규칙: 의회가 결정하고, 경량 에이전트 (lightweight agent)가 실행합니다. 레이드 리더 (raid leader)가 처치 대상 (kill target)을 지정하면 DPS가 실제 메카닉 (mechanics)을 처리하는 것과 같다고 생각하세요. 비용이 많이 드는 호출은 실행이 아니라 전략입니다.

모든 프롬프트에 위원회 (committee)가 필요한 것은 아닙니다. 1을 소집하기 전에 간단한 테스트를 거치세요. '이 작업에 Fable 5의 비용을 지불했을 것인가?' 만약 그렇다면, 위원회 (council)를 가동하세요. 만약 Haiku나 Flash를 기본값으로 사용했을 것이라면, 하지 마세요.

Claude Code 워크플로우 내에서 위원회가 제 역할을 하는 경우:

긴 에이전트 루프 (agentic loop)를 돌리기 전의 아키텍처 결정. 위원회가 접근 방식을 심의하게 하세요. 빠른 에이전트가 이를 구현합니다. 당신은 결정에 대해 단 한 번의 프런티어 (frontier) 비용을 지불하는 것이지, 구현의 모든 줄마다 지불하는 것이 아닙니다.

마이그레이션 (Migration) 계획. 위원회가 명세서 (spec)를 작성합니다. 당신의 CLI 에이전트 군단이 이를 실행합니다. 비용이 많이 드는 호출은 결정이지, 배포 (rollout)가 아닙니다.

서브 에이전트 (Sub-agent) 목표 정의. 장기적 관점의 에이전트를 가동하기 전에, 위원회가 미션을 작성하게 하세요. 모호한 목표는 자율 에이전트 (autonomous agents)가 탈선하는 지점입니다 (모든 Claude Code 사용자가 이를 경험해 보았을 것입니다). 에이전트가 실행을 시작하기 전에 목표를 명확하게 만드세요.

지식 베이스 (Knowledge base) 구조화. 분류 체계 (Taxonomy) 결정, 스키마 (schema) 설계. 비용이 적게 드는 것처럼 보이지만, 잘못되었을 때 비용이 비싸게 누적되는 선택들입니다.

근본적인 패턴: 심의는 앞단에 배치(front-load)하고, 실행은 뒷단에 배치(back-load)하는 것입니다. 값비싼 실수는 3초의 추가적인 지연 시간 (latency)이 아닙니다. 루프 전체를 잘못된 방향으로 보내버리는 잘못된 결정입니다.

비용의 함정 (The Cost Trap)

모든 것을 위원회를 통해 라우팅하기 전에 알아두세요. 경제성은 그런 방식으로 작동하지 않습니다.