조금 전, Devin의 「Fusion」에 관한 기사를 작성했습니다. 똑똑한 모델 1개로 전부 처리하는 것을 그만두고, 똑똑한 「메인(Main)」과 저렴한 「사이드킥(Sidekick)」의 2체 편성으로 구성함으로써, 품질을 유지하면서 비용을 41% 낮췄다는 이야기입니다.

그 기사를 쓰면서 한 가지 걸리는 점이 있었습니다. 이것이 Devin만의 독창적인 방안인지, 아니면 업계 전체가 그 방향으로 향하고 있는 것인지. 답은 의외로 금방 나왔습니다. Sakana AI가 2026년 6월에 발표한 Sakana Fugu가 바로 같은 방향을 다른 각도에서 공략하고 있었기 때문입니다.

Fugu의 캐치프레이즈는 「Multi-agent System as a Model」입니다. 한국어로 번역하자면 「하나의 모델로서 동작하는 멀티 에이전트 시스템 (Multi-agent System)」 정도가 될 것입니다. 내부에서는 여러 에이전트가 팀을 이루어 움직이고 있음에도, 사용하는 입장에서는 일반적인 모델을 한 번 호출하는 것처럼 보이게 만드는 설계입니다.

Devin Fusion은 에이전트 제품의 "내용물"로서 이를 수행하고, Sakana Fugu는 "모델 그 자체"로서 이를 판매합니다. 접근 방식은 다르지만, 도달하는 발상은 놀라울 정도로 닮아 있습니다. X(구 트위터)에서도 「멀티 에이전트를 하나의 모델로 내놓는 흐름」이 오고 있다는 지적이 있었습니다. 이 기사에서는 Fugu가 무엇을 하고 있는지 정리하면서, Fusion과 나란히 놓고 「이 흐름은 무엇인가」에 대해 생각해 보겠습니다.

먼저 3줄 요약

• Sakana Fugu는 여러 모델의 팀을 내부적으로 구성하여, OpenAI 호환의 단일 API를 통해 사용할 수 있게 하는 「모델」
• 이를 뒷받침하는 것은 ICLR 2026의 논문 2편(TRINITY와 Conductor)이며, 역할 분담과 연계 방식 그 자체를 학습을 통해 획득함
• Devin Fusion과 마찬가지로 「멀티 에이전트를 하나의 창구 뒤로 숨기는」 흐름. 다만 요금 체계나 내용 공개 정도는 대조적임

Fugu와 Fusion의 이야기에는 각 사가 독자적으로 붙인 명칭과 업계에서 통용되는 용어가 섞여 있습니다. 구분하기 쉽도록 먼저 정리해 두겠습니다. 헷갈린다면 이곳으로 돌아오시면 됩니다.

고유명사(각 사 독자 명칭)는 「그 제품의 세계에서만 통하는 용어」, 일반 용어는 「타사의 AI 기사에서도 등장하는 용어」라고 생각하시면 됩니다.

아주 거칠게 말하자면, Fugu는 「당신을 대신해 AI 팀을 편성해 주는 모델」입니다.

보통 여러 모델을 구분해서 사용하려면 스스로 워크플로우 (Workflow)를 설계해야 합니다. 이 처리는 저렴한 모델로, 여기는 똑똑한 모델로, 검증은 다른 모델로 직접 구성해야 합니다. 이것이 은근히 까다로우며, 모델이 늘어날수록 한계에 부딪힙니다. Fugu는 이 「팀 편성」 자체를 내부에서 수행합니다. 공식적인 표현을 빌리자면, 풀(Pool) 안에서 동적으로 에이전트를 구성하여, 인간은 생각하기 어렵지만 효율적인 연계 패턴으로 협조하게 만든다고 합니다.

사용자 경험은 심플합니다. OpenAI 호환의 단일 엔드포인트 (Endpoint)에 요청을 보내기만 하면 됩니다. 나머지는 Fugu가 「이번에는 이 모델들로 팀을 만들자」라고 스스로 결정하고, 결과를 하나로 모아서 반환해 줍니다.

역할 이름(Thinker, Worker, Verifier)이 등장했는데, 이는 후술할 연구에서 유래했습니다. 여기서는 「생각하는 사람·작업하는 사람·체크하는 사람으로 팀을 구성한다」 정도로 이해해도 충분합니다.

Fugu가 흥미로운 점은, 이 「팀을 구성하는 방식」을 사람이 설계하는 것이 아니라 학습을 통해 획득한다는 점입니다. 토대가 되는 것은 ICLR 2026에서 발표된 두 편의 논문입니다.

핵심은 역할 분담을 미리 고정해두지 않았다는 점입니다. "이 태스크라면 이런 팀 구성과 대화 방식이 효과적이다"라는 것을 모델 측에서 학습을 통해 찾아내고 있습니다. 인간이 짠 워크플로우(Workflow)의 모음이 아니라, 연계 패턴 자체가 학습의 결과물이라는 것이 Sakana의 주장입니다. 기술 보고에 따르면, TRINITY의 지휘역(Conductor 역할)은 약 0.6B 파라미터의 작은 모델을 진화적 탐색(CMA-ES)으로 단련한 것이며, Conductor는 약 7B 모델을 강화학습 (RL)으로 단련한 것이라고 합니다. 프론티어 모델 (Frontier Model)을 자체적으로 새로 훈련하는 것이 아니라, 기존의 강력한 모델들을 "묶는 방법"에 투자하고 있다는 설계 사상이 보입니다.

개발사인 Sakana AI는 도쿄에 거점을 둔 연구 랩으로, 공동 창업자인 Llion Jones는 Transformer를 세상에 알린 논문 「Attention Is All You Need」의 저자 중 한 명입니다. 사명인 「Sakana (물고기)」 또한, 무리를 짓는 물고기가 개별적으로는 단순해도 무리로서 똑똑하게 행동한다는 집단 지성의 발상에서 유래했습니다. Fugu는 그 사상을 그대로 제품화한 형태이며, 이름 짓는 방식까지 일관되어 있다는 점이 개인적으로 마음에 드는 부분입니다. 참고로 정식 서비스 시작일은 2026년 6월 22일입니다.

여기서 본론인 「흐름」에 관한 이야기입니다. Devin Fusion과 나란히 놓고 보면 공통점과 차이점이 명확해집니다.

공통점은 여러 에이전트의 복잡성을 "하나의 창구" 뒤로 숨긴다는 발상입니다. 사용하는 입장에서는 평소처럼 모델을 한 번 호출할 뿐이지만, 내부에서는 똑똑한 모델과 저렴한 모델이 역할을 나누어 움직입니다. 단순한 모델 라우팅 (Model Routing, 프롬프트를 보고 모델을 배분하는 것뿐인 방식)에 대한 불만에서 출발했다는 점도 비슷합니다.

차이점은 포지셔닝입니다. 정리하면 다음과 같습니다.

Fusion은 "Devin이라는 코딩 에이전트를 더 저렴하고 똑똑하게 움직이기 위한 내부 엔진"입니다. 반면 Fugu는 "당신의 앱에서 직접 호출할 수 있는 범용 모델"이며, 코딩에 국한되지 않습니다. 같은 발상을 한쪽은 제품 내부에, 다른 한쪽은 모델이라는 상품의 형태로 구현했다는 차이가 있습니다.

단순한 라우팅에서 시작하여 상담 패턴을 거쳐, 이제는 "멀티 에이전트를 통째로 하나의 제품/모델로 압축하는" 단계에 와 있습니다. Fusion과 Fugu는 그 최전선에 서로 다른 경로로 도달한 두 가지 사례라고 저는 보고 있습니다.

같은 흐름 속에 있더라도 요금 체계에는 각사의 성격이 드러납니다.

Fugu에서 인상 깊었던 점은 에이전트가 늘어나도 요금이 누적되지 않는 설계입니다. 공식적으로는 "여러 에이전트가 움직여도 모델 비용을 누적하여 부과하지 않는다. 관여한 최상위 모델의 단가로 일괄 과금한다"라고 명시되어 있습니다. 내부에서 5체가 움직이든 10체가 움직이든, 가장 비싼 모델 1개 분량의 요금만 지불하면 됩니다. 멀티 에이전트를 쓰다가 "어느샌가 청구 금액이 배로 불어나 있었다"라는 공포에 정면으로 대응하고 있습니다.

구체적인 요금은 구독형과 종량제(Pay-as-you-go) 두 가지 방식으로 운영됩니다.

종량제의 경우, Fugu Ultra는 100만 토큰당 입력 $5, 출력 $30 (272K를 초과하는 컨텍스트에서는 입력 $10, 출력 $45)입니다. 보안 특화 모델인 Fugu Cyber는 입력 $6, 출력 $36입니다.

Fusion이 "벤치마크 기준 비용 41% 절감"이라는 절감률로 이야기한다면, Fugu는 "누적되지 않는다"라는 과금 구조로 이야기합니다. 둘 다 비용이 주 전장이라는 점은 같지만, 보여주는 접근 방식이 다르다는 점이 흥미롭습니다.

Sakana 자체 벤치마크에 따르면, 상위 버전인 Fugu Ultra는 프론티어 모델 (Opus 4.8, Gemini 3.1 Pro, GPT-5.5)과 비교해도 손색이 없거나 일부에서는 앞서는 수치를 보여주고 있습니다.

보안 특화 모델인 Fugu Cyber는 CyberGym에서 86.9%, CTI-REALM에서 72.1%라는 수치도 기록했습니다. 마침 지난번 Devin Security Swarm 기사를 작성한 직후인데, 보안 특화 모델 계층을 일부러 준비해 오는 움직임은 업계 전체의 관심사가 어디에 있는지를 반영하고 있다는 느낌을 줍니다.

하지만 이 부분은 냉정하게 바라볼 필요가 있습니다. 이것들은 Sakana 자체의 벤치마크 (Benchmark) 값이며, 제삼자에 의한 재현은 이제부터 시작입니다. 숫자가 구체적이어서 호감을 주지만, 감안해서 읽을 여지가 있습니다. 이 주의점은 지난번 Fusion이나 Security Swarm 기사와 완전히 동일합니다. 자사 벤치마크는 자사 벤치마크로서 받아들이는 태도가 무난합니다.

도입을 검토한다면, 몇 가지 미리 파악해 두는 것이 안심됩니다.

가장 걸리는 점은 라우팅 (Routing)의 내용이 비공개라는 점입니다. "어떤 모델이 사용되었는지"가 보이지 않는 것은, Fusion이 역할 설계를 공식적으로 설명했던 것과 대조적입니다. 뒷단(Back-end)을 전부 Sakana에 맡기는 대신, 사용자는 단 하나의 API를 호출하기만 하면 됩니다. 이러한 위임 방식을 어떻게 느끼느냐는 용도와 취향에 따라 다를 것입니다.

또 하나, 속도도 솔직하게 살펴봅시다. 상위 버전인 Fugu Ultra는 하나의 요청을 여러 모델에 던져 검증까지 수행하는 만큼, 단일 모델을 한 번 호출하는 것보다 시간이 더 걸립니다. 제삼자의 검증에서는 코딩 계열 태스크에서 몇 분에서, 경우에 따라서는 30분 가까이 걸렸다는 보고도 나오고 있습니다 (Ethan Mollick 등의 관측). 이는 설정 오류가 아니라, 멀티 에이전트 (Multi-agent) 구조 그 자체에서 기인하는 트레이드오프 (Trade-off)입니다. Sakana 자신도 일상적인 사용의 기본값은 통상 버전인 Fugu, Ultra는 "어렵고 실수의 비용이 높은 문제"용이라고 위치를 정하고 있습니다. 가벼운 태스크는 통상 버전의 Fugu로, 결정적인 난제만 Ultra로 사용하는 방식이 현실적입니다.

Fugu를 조사하며 가장 납득이 갔던 점은, "멀티 에이전트는 기능이 아니라 상품의 단위가 되어가고 있다"는 것이었습니다. 지금까지 멀티 에이전트는 스스로 조립하는 "만드는 방법"의 이야기였습니다. 그것이 Fusion에서는 제품의 내용물이 되었고, Fugu에서는 모델이라는 상품 그 자체가 되었습니다. 사용하는 측은 이제 내부의 복잡함을 신경 쓰지 않아도 되게끔 변하고 있습니다.

Devin Fusion, 그리고 Sakana Fugu. 출처도 접근 방식도 다른 두 가지가 "복수의 에이전트를 하나의 창구 뒤로 접어 넣는다"라는 동일한 지점에 도달한 것은 우연이 아닐 것입니다. 이 흐름은 당분간 지속될 것이라 생각하므로, 자신의 환경에서 Fugu를 호출해 보고 실제 사용 편의성이나 비용감을 측정해 본 뒤 속편을 쓸 예정입니다. 그때는 Fusion 때의 숫자와도 대조해 보겠습니다.

• Sakana Fugu — Multi-agent System as a Model (Sakana AI 공식) (1차 정보. 사양·요금·벤치마크)
• Devin Fusion | Cognition 공식 블로그 (비교 대상 1차 정보)
• 과거 기사: Devin Fusion 해설 (메인 + 사이드킥 2체 구성으로 비용 41% 절감)
• ※ 발표일 (2026년 6월 22일)·창업자·TRINITY/Conductor의 파라미터 규모·레이턴시 (Latency) 실측 보고는 Sakana AI의 기술 보고 및 여러 제삼자 리뷰를 참조함