【일본산 AI】 Sakana Fugu가 놀라운 이유 ―― 「멀티 에이전트를 ‘하나의 모델 API’로 판매한다’는 발상

최근 Sakana AI가 출시한 Sakana Fugu를 조사해 보았는데, 이 발상이 꽤 흥미로워서 공유합니다.

한마디로 말하면, 「여러 개의 LLM을 배후에서 협조시키는 ‘멀티 에이전트 (Multi-agent)’를 단 하나의 모델 API로서 제공하는」 서비스입니다.

사용자 입장에서는 일반적인 모델을 하나 호출하는 것처럼 보이지만, 그 이면에서는 여러 모델이 팀을 이루어 태스크를 해결하고 있는―― 그런 물건입니다.

이 기사에서 알 수 있는 것

• Sakana Fugu가 무엇이며, 왜 새로운가
• 메커니즘 (ICLR 2026 논문 2편: TRINITY와 Conductor)의 간략한 해설
• 벤치마크에서의 위치 (Opus 4.8 / Gemini 3.1 Pro와 비교)
• 실제 사용 방식의 이미지 (OpenAI 호환)

Sakana AI ("sakana"는 물고기, "fugu"는 복어. 물고기 모티프로 통일되어 있습니다)가 공개한, 멀티 에이전트를 하나의 모델 API로 제공하는 서비스입니다.

대략적으로 말하면 「다양한 LLM을 태스크마다 동적으로 조합하여, 팀으로서 협조시킴으로써 성능을 끌어올리는」 것입니다. 핵심은, 그 조합 방식이나 역할 분담을 인간이 직접 설계하는 것이 아니라, 시스템 측에서 학습하고 있다는 점입니다.

이미지는 다음과 같습니다:

• 「LLM Pool」에 클로즈드/오픈 여부와 상관없이 다양한 모델이 들어 있음
• Fugu는 태스크마다 최적의 모델을 선택하고, 역할을 할당하여 연계시킴
• 이용자는 OpenAI 호환 API를 하나 호출하기만 하면 됨

「여러 모델을 사용하는 서비스」라고 하면 어떤 것이 떠오르시나요?

최근 몇 년간 우리가 LLM에 해온 일은 크게 두 가지였습니다.

• 하나의 강력한 모델에게 부탁하기
• 태스크에 따라 「어떤 모델을 사용할지」 선택하기 (= 라우팅 (Routing))

Fugu가 하고 있는 것은 그 어느 쪽도 아니며, 하나의 태스크에 대해 여러 모델을 동시에 실행시켜, 역할을 분담하여 “합의”하게 만드는 것 (= 오케스트레이션 (Orchestration))입니다. 게다가 그 절차를 학습을 통해 습득하고 있습니다. 이 점이 새로운 포인트입니다.

Fugu는 ICLR 2026 논문 2편을 기반으로 하고 있습니다.

• TRINITY: 경량화된 “코디네이터 (Coordinator)”가 여러 LLM을 묶고, 각각에게 Thinker / Worker / Verifier (생각하는 역할 / 만드는 역할 / 확인하는 역할)와 같은 역할을 부여하여 태스크를 배분함.
• Conductor: 강화학습 (Reinforcement Learning)을 통해, 자연어 기반의 협조 전략 그 자체를 학습시킴.

요컨대, 인간이 작성한 고정된 워크플로우에 의존하지 않고, 「태스크마다 누구를 어떻게 움직일지」를 시스템 스스로 결정하고 있다는 이미지입니다.

공개 모델과의 비교 (Sakana AI의 발표 내용). 굵은 글씨는 이 4개 모델 중 최고 점수입니다.

벤치마크	Fugu	Fugu Ultra	Opus 4.8	Gemini 3.1 Pro
SWE Bench Pro	59.0	73.7	69.2	54.2
TerminalBench 2.1	80.2	82.1	74.6	70.3
LiveCodeBench	92.9	93.2	87.8	88.5
LiveCodeBench Pro	87.8	90.8	84.8	82.9
GPQA-D	95.5	95.5	92.0	94.3
MRCRv2	86.6	93.6	87.9	84.9

특히 코드 계열 (SWE Bench Pro / TerminalBench / LiveCodeBench)에서 Ultra가 독보적으로 앞서 있는 점이 인상적입니다. 공개된 frontier 모델을 상회하는 점수를 단일 거대 모델이 아닌 여러 모델의 협조를 통해 내놓고 있다는 주장입니다.

점수는 어디까지나 제공처 (Sakana AI)가 공개한 수치입니다. 자신의 유스케이스에서 효과가 있을지는 별도로 검증을 권장합니다.

「OpenAI 호환이므로 이전이 쉽다」가 장점이므로, 코드는 아마 이런 분위기가 될 것입니다.

from openai import OpenAI
# OpenAI 호환이므로, base_url과 model을 교체하기만 하면 됨
client = OpenAI(
...

기존의 OpenAI 클라이언트를 그대로 사용하면서, base_url

와 model을 교체하기만 하면 됨――이라는 것이 목표입니다.

API는 단 1개: OpenAI 호환이므로, 기존 코드로부터의 이행 비용이 거의 제로(SDK 교체 불필요).

요금이 쌓이지 않음: 백그라운드에서 여러 모델이 작동하더라도, 과금은 "최상위 모델 1개분"의 레이트(Rate)가 기준. "멀티 에이전트(Multi-agent) = 고액"이라는 상식을 깨뜨리려 하고 있음.

모델의 옵트아웃(Opt-out) 가능: 컴플라이언스(Compliance)/데이터 요구사항에 맞춰, 특정 프로바이더(Provider)나 모델을 풀(Pool)에서 제외할 수 있음.

수출 규제 리스크 없이 frontier 급: 이 점은 일본산만의 셀링 포인트(Selling point).

라인업은 2가지.

Fugu: 퍼포먼스와 레이턴시(Latency)의 균형형 (일상적 사용)

Fugu Ultra: 어려운 태스크를 위해, 더 많은 모델을 묶어 품질 최우선

• Sakana Fugu =
  전 세계의 톱 모델을 백그라운드에서 오케스트레이션(Orchestration)하여, 1개의 API로 사용할 수 있게 만든 서비스 - "모델을 선택한다"에서 "모델들에게 분담시킨다"로의 발상 전환이 흥미로움
• 코드 계열 벤치마크에서 공개 모델을 상회하는 스코어, 게다가 요금은 쌓이지 않는 설계
• 단일 툴이라기보다, 기존의 개발 플로우에 "내용물(모델)"로서 끼워 넣을 수 있는 타입

개인적으로 가장 전율을 느낀 부분은, "멀티 에이전트를 단일 API로 추상화한" 탁월함입니다. 에이전트 개발의 복잡성을 이용자로부터 깔끔하게 숨기고 있습니다. 향후 이 "오케스트레이션 그 자체를 판매하는" 흐름이 늘어날지, 주목해 볼 필요가 있습니다.

• Sakana Fugu 공식 페이지 (https://sakana.ai/fugu/)
• ICLR 2026: TRINITY / Conductor (공식 technical report 참조)