【주의】 본 기사는 공개된 기술 리포트와 제3자의 실측 보고를 바탕으로 한 필자의 주관적인 리뷰입니다. 평가는 필자의 주관이 포함되어 있습니다. 최종적인 판단은 귀하의 워크로드에서의 실측을 바탕으로 진행해 주시기 바랍니다.

이 문구만 보면, 지나치게 완벽해 보인다.

2026년 6월, 도쿄의 Sakana AI가 Fugu와 Fugu Ultra를 공개했다. 자체적인 거대 모델을 훈련하지 않고, 기존의 프론티어 모델(GPT-5.5, Claude Opus 4.8, Gemini 3.1 Pro)을 오케스트레이션 (Orchestration) 함으로써, Anthropic의 Fable 5나 Mythos Preview와 어깨를 나란히 하는 벤치마크 성적을 기록했다고 한다.

매력적인 이야기다. 하지만 이 기사에서는 그 이야기를 잠시 제쳐두겠다. 벤치마크 수치와 실제로 사용했을 때의 체감은 일치하는가. 공개된 기술 리포트와 제3자의 실측 보고만을 근거로 검증한다.

벤치마크는 진짜다. SWE-Bench Pro 73.7, GPQA Diamond 95.5 등 단일 모델을 상회하는 수치가 기술 리포트에 기재되어 있다 -
하지만 실용성은 별개다. 여러 독립 테스터가 "Fable 정도의 실력은 실제 사용 시 느껴지지 않는다", "GPT-5.5보다 명확하게 나빴다"라고 보고했다 -
숨겨진 비용: 1회 요청(Request)당 3~5개 모델로 전개하기 때문에, 토큰 소비가 직접 호출의 4~6배가 된다 -
구조적인 아이러니: "Fable 5에 필적한다"라고 말하면서도, Fable 5는 수출 규제로 인해 에이전트 풀(Agent Pool)에 넣을 수 없다. 성능은 타사 모델의 제공 상황에 전적으로 의존한다 -
리포트 스스로 인정하는 약점: 레이턴시(Latency)·비용의 정량 데이터 없음, 베이스라인은 벤더(Vendor) 자기 신고, 일본어 태스크는 25페이지뿐

이것은 "나쁜 제품"이라는 이야기가 아니다. 오케스트레이션이라는 방향성은 연구로서 중요하다. 다만 "지금 당장 일상의 메인 모델로 삼을 수 있는가"라고 묻는다면, 현시점의 증거는 "노(No)"를 가리키고 있다.

Fugu Ultra는 단일 LLM이 아니다. **다른 모델을 호출하는 작은 조정역(Coordinator)**이다. 기술 리포트에 따르면 구조는 두 가지 계통이 있다.

• 사전 학습된 모델 위에 "경량 선택 헤드(Lightweight Selection Head)"를 얹음

• 최종 은닉층(Hidden Layer) 후단에서 어떤 워커(Worker) 모델로 보낼지를 로짓(Logit)으로 판정

• 자기회귀 디코딩(Autoregressive Decoding)을 기다리지 않고, 빠른 단계의 은닉 상태에서 즉시 디스패치(Dispatch)

• 1쿼리당 워커는 1개

• 학습은 특이값 파인튜닝(SVD Fine-tuning) + 진화적 최적화(sep-CMA-ES)

• "Conductor" 프레임워크 상에서 강화학습(GRPO)

• 서브 태스크, 담당 워커, 통신 전략을 **자연어 워크플로우 (Natural Language Workflow)**로 출력 - 최대 5단계, 트리 구조의 토폴로지(Topology)

• "orchestration collapse (조정 파탄)"를 방지하기 위한 에이전트 분리

• 여러 턴을 넘나드는 영구 공유 메모리

워커 풀은 세 가지다.

- Gemini 3.1 Pro
- Claude Opus 4.8
- GPT-5.5

이 부분이 첫 번째 중요 지점이다. Fugu Ultra의 똑똑함은 이 세 모델의 똑똑함을 재배분한 것이다. 토대 모델을 구할 수 없게 되면 성능도 연동되어 떨어진다.

기술 리포트에 기재된 주요 스코어 ("Best Single"은 각 벤치마크에서의 단일 최강 모델).

SWE-Bench Pro나 Terminal Bench에서는 단일 최강을 명확히 상회한다. 이것은 사실이다.

하지만 냉정하게 봐야 할 점도 있다.

GPQA Diamond: 95.5 대 94.3. 차이는 1.2포인트 -
Humanity's Last Exam: 50.0 대 49.8. 차이는 0.2포인트. 이것은 오차 범위라고 할 수 있다

즉 "전 영역 압승"이 아니라, 코딩 계열에서 효과적이며 지식·추론 계열에서는 단일 모델과 거의 호각이라는 것이 숫자의 솔직한 해석이다.

벤치마크는 제어된 환경의 이야기다. 실제 워크플로우에서는 어떤 일이 일어났는가. 제3자 테스터의 보고를 본다.

어느 테스터의 보고에 따르면, 전형적인 코딩 테스트(셰이더나 인터랙티브 씬) 실행에 30분이 걸렸다고 한다. 오케스트레이션은 "여러 모델에 배분하여 기다리는" 구조이므로, 레이턴시는 원리적으로 쌓이게 된다.

벤치마크에서는 Fable 5와 어깨를 나란히 한다고 하지만, 실제 사용 시의 평가는 냉혹하다.

Fable 정도의 실력은 실제 사용 시 느껴지지 않는다.

다른 테스터는 Three.js 게임 생성 태스크에서 결과가 GPT-5.5보다 명확하게 나빴으며, 수정을 위한 추가 프롬프트가 7~8회 필요했다고 보고했다 (GPT-5.5는 0회).

벤치마크 스코어는 '특정 태스크에서의 정답률'이지, '일상적인 개발에서의 사용 편의성'이 아니다. Fugu Ultra는 이 두 가지 사이의 간극이 현재 상당히 큰 모델이다.

가격표만 보면 입력 $5 / 출력 $30 (100만 토큰당)이다. Fable 5의 $10 / $50보다 저렴해 보인다.

하지만 이것은 표시 가격일 뿐이다.

Fugu Ultra는 1개의 요청(request)을 35개의 모델로 전개한다. 보고에 따르면 실제 토큰 소비량은 직접 호출할 때의 **46배**에 달한다. 한 테스터는 프롬프트 1개로 5시간 분량의 쿼터(quota)를 다 써버렸다고 한다 (개략적으로 프롬프트당 약 $6).

표시 단가: 출력 $30 / 1M 토큰
실효 소비: 1 요청당 4~6배의 토큰
→ 실효 비용은 「단가 × 팬아웃(fan-out) 배율」로 평가해야 함

'저렴한 오케스트레이터(orchestrator)'가 아니라, '여러 개의 고급 모델을 한꺼번에 호출하는 과금 방식'이라고 이해하는 것이 좋다.

가장 큰 논점은 바로 여기다.

Fugu Ultra는 'Fable 5·Mythos에 필적한다'고 주장한다. 하지만 Fable 5와 Mythos 모두 Fugu Ultra의 에이전트 풀(agent pool)에 포함되어 있지 않다. 이유는 지난 기사에서 언급했듯이, 미국의 수출 규제로 인해 Fable 5가 차단되어 있기 때문이다.

• 풀(pool)은 GPT-5.5, Opus 4.8, Gemini 3.1 Pro의 3개로 구성됨
• 즉, 'Fable에 필적하는' 성능을 Fable을 사용하지 않고 달성하고 있다는 주장이다. 이를 뒤집어 말하면, 성능은 완전히 타사 모델의 제공 상황에 의존한다.

OpenAI, Google, Anthropic 중 어느 한 곳이라도 가격 변경, 규제, API 사양 변경을 발표하면 Fugu Ultra의 실력은 그날 바로 변할 수 있다. 벤더 락인(vendor lock-in)을 피하기 위한 설계가 오히려 3개사에 대한 락인이 되어 있다고도 읽힐 수 있다.

과장을 피하려면 Sakana AI 스스로가 작성한 주의사항도 병기해야 한다.

연구로서는 성실한 공개다. 하지만 이것들을 읽어 넘기고 'Fable급'이라는 말만 받아들인다면 기대치를 잘못 설정하게 된다.

증거를 기반으로 정리하면, 적합한 용도와 그렇지 않은 용도가 명확하다.

적합한 경우

• 시간과 비용을 감수할 수 있는 고난도·다단계 문제 (연구, 논문 재현, 특허·문헌 조사)
• 1회의 정확도가 비용보다 중요한 '진득하게 앉아서 하는' 태스크
• 단일 모델에 대한 의존을 피하고 싶은 실험적 워크로드(workload)

적합하지 않은 경우

• 대화형 일상 개발 (레이턴시와 추가 프롬프트가 효율을 저해함)
• 비용 민감도가 높은 대량 처리
• '빠르고 저렴함'을 기대하는 용도

Fugu Ultra가 보여준 것은 '거대 모델을 훈련하지 않더라도, 영리하게 묶어 놓으면 최전선에 도달할 수 있다'는 방향성의 증명이다. 그 자체로는 가치가 있다.

하지만 '내일부터 나의 메인 모델로 쓸 수 있는가'는 별개의 문제다. 현시점의 증거는 벤치마크의 숫자를 실용적인 기대치로 그대로 변환하지 마라고 말하고 있다.

숫자에 현혹되지 말고, 자신의 워크로드에서 레이턴시와 팬아웃 이후의 실효 비용을 직접 측정하라. 그것이 이러한 종류의 오케스트레이션 모델과 올바르게 교류하는 방법이다.

이 기사가 도움이 되었다면 좋아요와 저장을 부탁드립니다!

여러분은 오케스트레이션형 모델을 사용해 보셨나요? 실제 측정값이 있다면 댓글로 알려주세요.

Sakana Fugu — Multi-agent System as A Model

Sakana Fugu Technical Report (arXiv)

Sakana Fugu: Benchmarks vs Real-World Testing (June 2026 Update)

No Claude Fable 5? No problem: Sakana achieves frontier performance with new Fugu multi-model system - VentureBeat

Sakana AI의 Fugu는 Anthropic의 Fable 및 Mythos 벤치마크에 필적하기 위해 여러 LLM (Large Language Models)을 조율합니다 - The Decoder