Sakana AI의 Fugu는 겉으로는 새 LLM 출시처럼 보이지만, 실제 초점은 모델 자체보다 실행 방식에 있다. 사용자는 OpenAI 호환 API 하나를 호출한다. 그러나 내부에서는 Fugu가 여러 언어모델이 들어 있는 풀에서 적절한 에이전트를 고르고, 작업을 나누고, 결과를 검토한 뒤 하나의 답으로 합친다. 필요하면 Fugu 자신도 그 풀의 일부로 동원된다.
Sakana가 공개한 벤치마크는 공격적이다. Fugu Ultra는 SWE Bench Pro 73.7, TerminalBench 2.1 82.1, LiveCodeBench Pro 90.8을 기록했고, 회사는 Anthropic의 Fable 5와 Mythos Preview급 성능을 주장한다. 흥미로운 점은 Fable과 Mythos가 Fugu의 에이전트 풀에 포함되지 않았다는 것이다. 공개 접근이 불가능한 모델이라 비교 기준으로만 쓰였고, Sakana는 각 모델 제공사의 수치를 기준으로 삼았다고 설명한다.
하지만 초기 사용 후기는 벤치마크보다 덜 매끈하다. Ethan Mollick은 Fugu Ultra가 "incredibly slow"였고 평소 코딩 테스트가 30분 걸렸다고 썼다. 또 다른 사용자는 $20 플랜의 5시간 쿼터를 프롬프트 하나에 모두 썼다고 했다. Hacker News에서는 $200 플랜도 주당 3시간이 안 된다는 불만이 나왔다. 반면 코드 리뷰에서는 Opus 4.8이나 GPT 5.5에 가까운 평가가 보인다. 긴 검토 작업에서는 강점이 있지만, 빠른 생성형 작업에서는 비용과 지연이 먼저 드러날 수 있다는 뜻이다.
Fugu의 더 큰 메시지는 공급자 종속 완화다. Sakana는 특정 회사의 API에 핵심 업무를 맡기는 것이 규제, 수출통제, 외교 변수에 취약하다고 본다. 모델 풀을 갈아끼울 수 있으면 한 제공자가 막혀도 다른 모델로 우회할 수 있다는 논리다. 이 주장은 현실적이지만 과장해서 받아들이면 곤란하다. 오케스트레이터는 의존성을 분산할 수 있지만, 풀 안의 기반 모델들 자체에 대한 의존을 없애지는 못한다.
그래도 Fugu는 중요한 방향을 짚는다. AI 성능 경쟁은 더 이상 단일 모델의 크기와 점수만으로 설명되지 않는다. 어떤 모델을 언제 부를지, 답을 어떻게 검증할지, 여러 결과를 어떤 기준으로 합칠지가 제품의 핵심이 되고 있다. 짧은 챗봇 응답보다 코드 리뷰, 보안 분석, 논문 재현, 특허·문헌 조사처럼 오래 걸리고 실패 비용이 큰 작업에서 이런 설계가 더 의미를 가질 가능성이 높다.
결국 Fugu는 "가장 똑똑한 한 모델"보다 "여러 모델을 데리고 일하는 시스템"에 가깝다. 벤치마크 승패보다 중요한 질문은 따로 있다. 모델 선택까지 모델에게 맡기는 시대에, 사용자는 품질, 비용, 지연, 책임을 어디서 통제할 수 있을까.