Sakana AI의 Fugu는 업계가 나아가고 있는 방향을 보여주는 좋은 사례입니다.

하나의 거대한 모델로 승리하려 하는 대신, Fugu는 강력한 모델들의 풀(pool)을 효과적으로 조정합니다. 겉으로 보기에 Fugu는 단일 API로 제공되지만, 내부적으로는 작업을 라우팅(routing)하고, 역할을 선택하며, 여러 Frontier LLM의 출력을 하나로 엮어주는 학습된 매니저(manager)처럼 동작합니다. 이는 Fugu를 단순히 프롬프트가 개선된 챗봇이 아니라, 단일 모델로 제공되는 멀티 에이전트 오케스트레이션(multi-agent orchestration) 시스템으로 만듭니다.

실제 AI 프로덕션 환경에서 발생하는 많은 복잡한 작업들은 오케스트레이션에서 비롯됩니다. 즉, 적절한 모델을 선택하고, 언제 검증할지 결정하며, 작업을 하위 작업(subtasks)으로 나누고, 더 저렴한 모델로 해결 가능한 경우 비용이 많이 드는 호출을 피하는 과정들입니다. Fugu는 바로 이 문제를 제품으로 전환했습니다.

Fugu의 실체

Sakana AI는 Fugu를 모델로서의 멀티 에이전트 시스템(multi-agent system)이라고 설명합니다. 사용자가 단일 엔드포인트로 하나의 요청을 보내면, Fugu는 전문 모델 풀에 작업을 어떻게 분배할지 결정합니다.

이 풀은 특정 벤더(vendor)에 종속되지 않습니다. 시스템은 에이전트를 동적으로 구성하고 조정할 수 있으며, 사용자가 개인정보 보호, 데이터 또는 컴플라이언스(compliance) 요구 사항에 맞춰 특정 모델이나 제공업체를 제외하도록 선택할 수도 있습니다. 목표는 백엔드 조정(coordination)을 수동으로 구축된 라우터보다 훨씬 더 스마트하게 만들면서도 API는 단순하게 유지하는 것입니다.

두 가지 공개 버전이 있습니다:

• Fugu: 지연 시간(latency)과 품질의 균형을 맞춤
• Fugu Ultra: 더 어려운 작업을 위해 더 깊은 에이전트 풀을 사용함

이러한 분리는 모든 작업이 가장 비용이 많이 드는 경로를 필요로 하지는 않기 때문에 유용합니다. 일상적인 코딩, 리뷰 및 내부 지원 작업의 상당수는 빠른 기본 설정이 필요합니다. 심층 추론(deep reasoning), 논문 재현(paper reproduction) 또는 보안 분석과 같은 더 어려운 작업은 더 무거운 오케스트레이션 설정을 정당화할 수 있습니다.

작동 방식

기본적인 워크플로우는 일반적인 단일 모델 호출 (single-model call)과는 다릅니다. 먼저, 들어오는 작업은 학습된 조정 프로세스 (learned coordination process)로 라우팅됩니다. Fugu는 어떤 에이전트가 참여해야 하는지, 각 에이전트가 어떤 역할을 수행해야 하는지, 그리고 교환이 어떻게 진행되어야 하는지를 결정합니다. 이 시스템은 인간 운영자에게는 명확히 보이지 않지만 실제로는 효과적으로 작동하는 협업 패턴을 학습합니다.

Fugu는 두 편의 ICLR 2026 논문인 TRINITY와 Conductor를 기반으로 합니다. TRINITY는 다회차 작업 (multi-turn task) 전반에 걸쳐 Thinker, Worker, Verifier와 같은 역할을 할당하는 경량화된 진화형 조정자 (evolved coordinator)를 사용합니다. Conductor는 강화학습 (reinforcement learning)을 통해 자연어 조정 전략을 학습합니다. 이들은 함께 모든 워크플로우를 수동으로 설계하는 대신, 다른 모델들을 어떻게 오케스트레이션 (orchestrate)할지 스스로 발견하도록 시스템을 훈련할 수 있음을 보여줍니다. 이는 더 광범위한 변화를 시사합니다. 지난 AI 발전의 물결이 단일 모델을 더 강력하게 만드는 데 집중했다면, 이번 물결은 모델 시스템을 더 똑똑하게 만드는 것에 관한 것입니다.

오케스트레이션 레이어 (orchestration layer)가 중요한 이유

대부분의 팀은 이미 서로 다른 모델이 각기 다른 분야에 강점이 있다는 것을 알고 있습니다. 어떤 모델은 코드 작성에 탁월할 수 있는 반면, 다른 모델은 긴 추론 (long reasoning)이나 사실적 검색 (factual retrieval)에 더 적합할 수 있습니다. 수동으로 구축된 스택에서는 어떤 모델을 언제 호출할지, 출력을 어떻게 검증할지, 그리고 언제 추가 추론 (inference) 비용 지불을 멈출지를 누군가가 결정해야 합니다. Fugu는 이러한 결정들을 하드코딩 (hard-coding)하는 대신 학습하려고 시도합니다.

이러한 접근 방식은 비용 대비 성능 (cost-performance)을 개선합니다. 시스템이 쉬운 하위 작업 (subtasks)은 더 가벼운 에이전트에게 라우팅하고, 어려운 부분에는 더 무거운 에이전트를 예약할 수 있다면, 모든 요청을 풀 내에서 가장 비싼 모델로 보내는 것보다 전체적인 결과가 더 나을 수 있습니다.

또한 신뢰성 (reliability)을 향상시킵니다. 에이전트 시스템 (agentic systems)에서 발생하는 많은 실패는 오케스트레이션이 취약하기 때문에 발생합니다. 하나의 모델이 모든 것을 수행할 때, 단 한 번의 실수가 전체 체인에 파급 효과를 일으킵니다. Fugu의 설계는 전문가 (specialists)와 검증 역할 (verification roles)을 더 의도적으로 사용함으로써 그 위험을 줄입니다.

Fugu 대 Fugu Ultra

두 변체(variants) 사이의 차이점은 주로 오케스트레이션 (orchestration)을 위해 어느 정도의 비용을 지불할 용의가 있는지에 달려 있습니다.

Fugu는 균형 잡힌 옵션으로, 지연 시간 (latency)이 여전히 중요한 코딩, 대화형 작업 및 일반적인 워크로드 (workloads)를 위한 실용적인 기본값으로 설계되었습니다.

Fugu Ultra는 한 단계 더 나아가며, Sakana는 이를 속도보다 답변의 품질이 더 중요한 복잡하고 중대한 다단계 작업 (multi-step work)을 위해 포지셔닝하고 있습니다. 그들이 강조하는 예시에는 논문 재현 (paper reproduction), Kaggle 경진대회, 보안 분석 (security analysis), 문헌 검토 (literature review) 및 특허 조사 (patent research)가 포함됩니다.

이러한 프레이밍은 이 제품의 진정한 용도가 무엇인지 보여줍니다. Fugu는 단순히 더 나은 채팅 모델이 아닙니다. 이는 모델이 답변하기 전에 추론 (reason)하고, 위임 (delegate)하고, 검증 (verify)하며, 심지어 스스로의 의견에 반박 (disagree)해야 하는 작업들을 위한 시스템입니다.

벤치마크가 시사하는 점

Sakana는 코딩, 추론 (reasoning), 과학 및 에이전트 (agentic) 벤치마크 전반에 걸쳐 강력한 성능을 보고했습니다. Fugu와 Fugu Ultra는 공개적으로 사용 가능한 프런티어 모델 (frontier models)들과 잘 비교되며, 때로는 그들과 나란히 있거나 앞서기도 합니다.

그들이 언급한 벤치마크는 다음과 같습니다:

• 코딩을 위한 SWE-Pro
• 터미널 및 도구 사용을 위한 TerminalBench
• LiveCodeBench 및 LiveCodeBench Pro
• 어려운 추론을 위한 Humanity's Last Exam
• 과학적 추론을 위한 GPQA-D
• SciCode
• 긴 문맥 추론 (Long-context reasoning)
• MRCRv2

정확한 수치보다는 패턴이 더 중요합니다. Fugu는 단일한 모놀리식 모델 (monolithic model)이라고 주장하는 대신, 오케스트레이션 (orchestration) 그 자체만으로도 어려운 작업에서 프런티어 수준의 결과를 낼 수 있음을 입증합니다.

그들의 질적 (qualitative) 예시들은 그 점을 더욱 명확하게 보여줍니다. Sakana는 자율 연구 (autonomous research), 고전 일본어 읽기 순서 복구, 루빅스 큐브 맞추기, 기계식 아이리스를 위한 CAD 생성, 눈 가리고 체스 두기, 트레이딩 시뮬레이션과 같은 작업에서 Fugu를 보여줍니다. 이러한 환경들은 매우 다르지만, 모두 한 번 추측하고 결과가 좋기를 바라는 대신 적절한 내부 전략을 선택할 수 있는 시스템에 보상을 제공합니다.

중요한 제품 세부 사항

Fugu는 OpenAI 호환 API를 통해 제공되므로, 팀들이 이를 테스트하기 위해 통합 계층 (integration layer)을 다시 구축할 필요가 없습니다. 만약 이미 OpenAI 스타일의 엔드포인트와 통신하는 클라이언트, 하네스 (harness), 또는 내부 에이전트 스택을 보유하고 있다면, Fugu는 큰 마찰 없이 바로 적용될 수 있습니다.

Sakana은 구독형 (subscription) 모델과 종량제 (pay-as-you-go) 모델을 모두 제공합니다. 종량제 모델은 풀 (pool) 내의 모든 모델에 대해 수수료가 중첩되는 것을 방지합니다. 즉, 구성된 풀에 포함된 최상위 모델을 기준으로 단일 요율을 지불하게 됩니다. 이는 오케스트레이션 (orchestration)이 감당하기 힘들 정도로 비싼 비용이 드는 대신, 재정적으로 실행 가능한 수준이 되도록 만듭니다.

한 가지 제한 사항은, Sakana이 규제 준수를 위해 노력하는 동안 Fugu는 아직 EU/EEA 지역에서 사용할 수 없다는 점입니다.

이것이 보기보다 더 큰 제품인 이유

언뜻 보기에 Fugu는 매우 훌륭한 라우터 (router)처럼 들리지만, 그러한 설명은 이 제품의 가치를 과소평가하는 것입니다. 핵심적인 아이디어는 모델 오케스트레이션 (model orchestration) 자체가 하나의 일급 기능 (first-class capability)이 되고 있다는 점입니다. 이것이 성립한다면, 그 가치는 단순히 더 나은 벤치마크 점수에 있는 것이 아니라, 비싸고 전문화된 모델 더미를 팀이 워크플로 (workflow)를 처음부터 수동으로 조정할 필요 없이 사용할 수 있는 단일 시스템으로 변모시키는 데 있습니다.

이 시스템은 멀티 모델 워크플로 (multi-model workflows)를 실용적으로 만들 수 있을 만큼의 적절한 복잡성을 숨겨주기 때문에 실제 팀들에게 유용합니다.

전략적인 측면도 존재합니다. 모든 중요한 작업에 대해 단 하나의 제공업체에 의존하는 것은 리스크입니다. 제약 사항을 우회하거나, 에이전트를 교체하거나, 특정 제공업체를 제외할 수 있는 학습된 오케스트레이션 계층 (orchestration layer)은 그러한 의존성을 줄여줍니다. Sakana은 명확하게 이 아이디어에 집중하고 있습니다.

teamcopilot.ai가 위치하는 곳

teamcopilot.ai는 AI 워크플로 (workflows), 권한, 그리고 승인을 위한 공유 제어 계층 (shared control layer)입니다. 이는 Fugu와 같은 시스템에 자연스럽게 부합합니다. Fugu가 특정 작업을 위한 오케스트레이션 엔진 (orchestration engine)이라면, teamcopilot.ai는 그 주변을 감싸는 거버넌스 계층 (governance layer)입니다. 재사용 가능한 워크플로 (workflows)를 통해 작업을 라우팅하고, 승인 과정을 가시적으로 유지하며, 모델이 작업에 직접 닿기 전에 누가 무엇을 할 수 있는지 결정할 수 있습니다. 프로덕션 AI (Production AI)는 모델을 안전하고, 반복 가능하며, 팀 전체에서 공유 가능하게 만드는 것을 요구합니다.

관련 읽을거리:

• AI 에이전트 거버넌스(Governance)는 새로운 기업용 컨트롤 플레인(Control Plane)이다
• 왜 당신의 AI 에이전트가 API 키를 절대 봐서는 안 되는가
• 2026년 팀을 위한 최고의 AI 에이전트 플랫폼: 13개 도구 비교
• 팀과 함께 Claude Code를 사용하는 방법: 공유 컨텍스트, 권한 및 MCP

트레이드오프 (The tradeoffs)

Fugu는 인상적이지만, 트레이드오프 (tradeoffs)가 존재합니다. 시스템이 여러 모델이나 여러 에이전트 단계(agent steps)를 호출할 때는 항상 지연 시간 (Latency) 문제가 논의될 수밖에 없습니다. 라이브 UI를 위해 즉각적인 응답이 필요하다면, 더 단순한 단일 모델 (single-model) 경로가 여전히 유리할 수 있습니다.

라우팅 (routing) 로직 또한 독점적입니다. Sakana는 정확한 내부 선택 프로세스를 공개하지 않으므로, 모든 결정에 대한 완전한 가시성 없이 오케스트레이션 (orchestration)의 이점만 누리게 됩니다. 또한, 표준 Fugu는 옵트아웃 (opt-outs)을 허용하지만, Fugu Ultra는 전체 에이전트 풀 (agent pool)을 사용합니다. 루프 내의 모든 제공자 (provider)에 대해 엄격한 제어가 필요하다면 이 점을 유념할 가치가 있습니다.

그럼에도 불구하고, 이는 새로운 제품 카테고리에서 나타나는 일반적인 트레이드오프입니다. 진짜 시험대는 시스템이 더 나은 결과로 그 복잡성을 상쇄할 만큼의 가치를 증명하느냐 하는 것입니다.

더 큰 시사점 (The bigger takeaway)

Fugu는 시장이 단일 모델 사고 (single-model thinking)에서 시스템 사고 (system thinking)로 이동하고 있다는 신호입니다. 원시 벤치마크 (benchmark) 수치만 본다면 이러한 변화를 놓치기 쉽지만, 제품의 스토리는 명확합니다. Sakana AI는 가장 유용한 AI 시스템이 모델들을 어떻게 사용할지 결정하는 학습된 레이어 (learned layer)를 갖춘, 조정된 모델 풀 (coordinated pools of models)이 될 것이라는 데 베팅하고 있습니다. 많은 팀이 이미 수동으로 이 방향을 향해 가고 있으며, Fugu는 단순히 오케스트레이션 레이어 (orchestration layer)를 명시적으로 만들어 줄 뿐입니다.

FAQ

Sakana Fugu란 무엇인가요?

Sakana Fugu는 단일 모델 API로 제시되는 멀티 에이전트 오케스트레이션 (multi-agent orchestration) 시스템입니다. 모든 것을 수행하기 위해 하나의 모델에 의존하는 대신, 프런티어 모델 (frontier models)의 풀을 조정합니다.

Fugu는 모델인가요, 제품인가요?

둘 다 해당합니다. Sakana는 이를 모델 API (model API)로 공개하지만, 진정한 가치는 그 뒤에 있는 오케스트레이션 시스템 (orchestration system)에 있습니다.

Fugu와 Fugu Ultra의 차이점은 무엇인가요?

Fugu는 균형 잡힌 저지연 (lower-latency) 옵션입니다. Fugu Ultra는 속도보다 품질이 더 중요한, 더 어렵고 리스크가 큰 작업들을 위해 더 깊은 에이전트 풀 (agent pool)을 사용합니다.

Fugu는 어떻게 작동하나요?

Fugu는 여러 전문 모델 (specialist models)에 걸쳐 작업을 라우팅 (route)하고, 역할을 할당하며, 응답을 조정합니다. 이 기술의 바탕이 되는 연구는 TRINITY와 Conductor에서 비롯되었습니다.

왜 그냥 프런티어 모델 (frontier model) 하나를 직접 호출하지 않나요?

모델마다 뛰어난 성능을 보이는 작업이 다르기 때문입니다. Fugu는 하나의 모델이 모든 부담을 짊어지게 하는 대신, 언제 위임 (delegate)하고, 검증 (verify)하거나, 전략을 전환할지를 결정합니다.

Fugu가 사용하는 모델을 제가 제어할 수 있나요?

네, Fugu의 경우 가능합니다. Sakana는 개인정보 보호, 데이터 또는 컴플라이언스 (compliance) 요구 사항에 맞게 특정 모델이나 제공업체를 제외하도록 선택할 수 있게 해줍니다. Fugu Ultra는 전체 풀을 사용합니다.

Fugu는 OpenAI와 호환되나요?

네. 대대적인 통합 재작성 (integration rewrite) 없이도 기존 클라이언트 및 에이전트 스택 (agent stacks)에 바로 적용할 수 있습니다.

Fugu는 어떤 작업에 가장 적합한가요?

코딩 (coding), 추론 (reasoning), 연구 (research), 보안 분석 (security analysis), 논문 재현 (paper reproduction), 그리고 오케스트레이션이 중요한 기타 다단계 워크플로 (multi-step workflows)에 적합합니다.

Fugu는 실시간 앱에 적합한가요?

반드시 그렇지는 않습니다. 조정하는 에이전트가 많아질수록 지연 시간 (latency)이 변수가 되므로, 즉각적인 응답이 필요한 경우에는 이상적이지 않을 수 있습니다.

Fugu가 어떤 기반 모델을 사용했는지 보여주나요?

아니요. Sakana는 정확한 라우팅 로직 (routing logic)을 독점 기술 (proprietary)로 취급합니다.

팀에서 Fugu를 안전하게 사용할 수 있나요?

네, 주변 워크플로가 통제되고 있다면 가능합니다. 팀 환경에서 모델을 안전하고 유용하게 만들기 위해서는 승인 계층 (approval layers), 감사 추적 (audit trails), 그리고 비밀 정보 처리 (secret handling)가 필수적입니다.

팀이 오케스트레이션에 관심을 가져야 하는 이유는 무엇인가요?

오케스트레이션이야말로 진정한 생산성 향상이 일어나는 지점이기 때문입니다. 적절한 하위 작업 (subtask)에 적절한 모델을 선택하는 것은 모델 자체를 선택하는 것만큼이나 중요할 수 있습니다.

teamcopilot.ai는 어떤 역할을 하나요?

teamcopilot.ai는 AI 워크플로(workflows), 권한(permissions), 승인(approvals)을 위한 공유 제어 계층(shared control layer)을 제공하여, Fugu와 같은 시스템을 관리되고 재사용 가능한 프로세스 내에서 쉽게 실행할 수 있도록 합니다.

Fugu가 단일 모델 워크플로(single-model workflows)를 대체할까요?

전적으로 그렇지는 않습니다. 단순한 작업은 여전히 단일 호출(single call)로 처리하는 것이 더 효율적이지만, 위임(delegation)과 검증(verification)을 통해 이득을 얻을 수 있는 더 복잡한 워크플로(workflows)는 점점 더 Fugu와 같은 시스템에 의존하게 될 것입니다.