하나의 모델보다 AI 팀을 만드는 방법: Sakana AI의 Fugu

최근 AI 업계에서는 모델 성능만큼이나 모델을 사용하는 방식이 중요해지고 있다.

그동안에는 더 뛰어난 모델이 나오면 기존 모델을 교체하는 방식이 일반적이었다. GPT의 성능이 좋아지면 GPT를 사용하고, Claude가 특정 작업에서 더 좋은 결과를 내면 Claude로 옮겨가는 식이다.

하지만 최근 Fable 5와 Mythos 5를 둘러싼 접근 제한 논란을 보면서 한 가지 생각이 들었다.

특정 모델 하나에 크게 의존하는 방식이 앞으로도 안정적인 선택일까?

 

모델의 성능이 아무리 뛰어나더라도 정책이 바뀌거나, 가격이 오르거나, 특정 사용자와 조직의 접근이 제한되면 해당 모델을 중심으로 구성한 업무 흐름 전체가 영향을 받을 수 있다. 나는 Fable5를 써보지는 못했지만, 해당 모델을 사용해본 지인은 이만한 모델이 없었다면서 여전히 아쉬워한다. 

이런 상황에서 가장 먼저 떠올릴 수 있는 대응은 다른 모델을 찾는 것이다.

예를 들면, Claude를 사용할 수 없다면 GPT를 쓰고, GPT가 적합하지 않다면 Gemini나 오픈소스 모델을 검토하는 식이다.

 

그런데 Sakana AI가 6월 22일 공개한 Fugu는 여기서 조금 다른 방향을 제안한다.

https://sakana.ai/fugu-release/

Sakana AI

하나의 모델을 다른 모델로 교체하는 것이 아니라, 처음부터 여러 모델이 협업하는 구조를 만들자는 것이다.

이번 글에서는 Sakana AI가 지금까지 보여준 주요 연구를 짧게 살펴보고, 그 연구 흐름이 Fugu라는 멀티 에이전트 오케스트레이션 시스템으로 어떻게 이어졌는지 정리해 보려고 한다.

꾸준히 다른 방향을 제시해 온 Sakana AI

Sakana AI는 2023년 일본 도쿄에서 설립된 AI 연구개발 회사다.

회사 이름인 ‘Sakana’는 일본어로 물고기를 뜻한다. 이름처럼 이 회사의 연구에는 물고기 떼와 생태계, 진화, 집단지능 같은 자연의 원리에서 영감을 받은 접근이 자주 등장한다.

최근 AI 업계에서 자주 언급되는 회사들은 OpenAI, Anthropic, Google DeepMind, Meta, DeepSeek, Alibaba 등 미국과 중국 기업에 집중되어 있다.

물론 한국을 포함한 여러 국가에서도 AI 연구가 활발하게 진행되고 있다. 다만 글로벌 AI 업계의 주요 발표를 따라가다 보면 자주 접하게 되는 이름이 일부 미국과 중국 기업에 집중되어 있는 것도 사실이다.

그런 상황에서 Sakana AI는 단순히 기존 프런티어 모델을 따라 만드는 것이 아니라, 모델을 결합하고 적응시키고 협업시키는 새로운 방법을 꾸준히 연구해 왔다. 개인적으로 Sakana AI를 인상 깊게 보는 이유도 여기에 있다.

국가나 회사 규모 자체가 중요한 것이 아니라, 대규모 모델 경쟁과는 조금 다른 질문을 계속 던지면서 세계적으로 주목받는 연구 결과를 꾸준히 내놓고 있다는 점이 흥미롭다.

더 큰 모델 대신, 기존 모델을 결합하는 방법

현재 AI 업계의 대표적인 경쟁 방식은 더 많은 데이터와 GPU를 사용해 더 큰 단일 모델을 만드는 것이다.

반면 Sakana AI의 연구에서는 다음과 같은 질문이 반복해서 등장한다.

반드시 하나의 모델을 계속 크게 만들어야 할까?

이미 존재하는 모델들을 효과적으로 조합하거나, 여러 모델이 협력하도록 만들거나, 새로운 작업에 빠르게 적응시키는 방법도 있을 수 있다.

Sakana AI가 지금까지 공개한 연구들은 이러한 철학을 여러 형태로 보여준다.

Evolutionary Model Merge

Sakana AI가 이름을 알린 대표적인 연구 중 하나는 Evolutionary Model Merge다.

https://sakana.ai/evolutionary-model-merge/

Sakana AI

일반적인 모델 개발에서는 하나의 모델을 처음부터 학습하거나, 기존 모델을 추가 데이터로 파인튜닝한다.

Evolutionary Model Merge는 서로 다른 능력을 가진 기존 모델을 결합하는 방법을 진화 알고리즘으로 탐색한다.

어떤 모델의 어떤 레이어를 활용할지, 가중치를 어떤 비율로 섞을지 등을 사람이 일일이 정하지 않고 알고리즘이 자동으로 찾는다.

예를 들어 일본어에 강한 모델과 수학에 강한 모델이 있다면, 두 모델의 장점을 효과적으로 결합하는 방법을 탐색하는 것이다.

이 연구에서 중요한 것은 단순히 새로운 모델 하나를 만들었다는 점이 아니다.

이미 존재하는 여러 모델의 능력을 어떻게 결합할 것인가?

라는 Sakana AI의 연구 방향을 분명하게 보여줬다는 점이다.

 

연구 과정 전체를 자동화한 AI Scientist

Sakana AI는 이후 The AI Scientist를 공개했다.

https://sakana.ai/ai-scientist-nature/

Sakana AI

AI Scientist는 논문을 요약하거나 연구 아이디어를 추천하는 수준을 넘어선다.

연구 아이디어 생성부터 코드 작성, 실험 실행, 결과 분석, 그래프 생성, 논문 작성과 리뷰까지 머신러닝 연구의 전체 과정을 자동화하려는 시스템이다.

물론 AI가 생성한 연구 결과의 신뢰성과 독창성에는 여전히 검토할 부분이 많다.

그럼에도 AI가 단일 작업만 수행하는 것이 아니라, 여러 단계로 구성된 긴 연구 워크플로를 스스로 실행하도록 설계했다는 점에서 큰 관심을 받았다.

Evolutionary Model Merge가 여러 모델의 능력을 결합하는 연구였다면, AI Scientist는 여러 에이전트와 작업 단계를 하나의 프로세스로 연결하는 연구라고 볼 수 있다.

이러한 흐름은 이후 Fugu의 멀티 에이전트 구조와도 연결된다.

문서와 자연어로 LoRA를 생성하는 Doc-to-LoRA와 Text-to-LoRA

내가 Sakana AI를 알게되었던 연구는 Text-to-LoRA였다.

https://sakana.ai/text-to-lora/

Sakana AI

LoRA는 대형 모델의 전체 가중치를 다시 학습하지 않고, 상대적으로 작은 어댑터만 학습해 특정 작업이나 도메인에 모델을 적응시키는 기술이다.

다만 일반적인 LoRA 역시 학습 데이터 준비와 파인튜닝 과정이 필요하다.

Sakana AI는 여기서 한 단계 더 나아가, 하이퍼네트워크가 필요한 LoRA 어댑터를 즉시 생성하는 방향을 제안했다. 당시에는 LoRA 를 이용해서 파인튜닝을 했었기 때문에 흥미로웠던 연구였기에 따로 논문도 정리했었다.

Text-to-LoRA

자연어로 원하는 작업을 설명하면, 해당 작업에 적응하기 위한 LoRA 어댑터를 생성한다. 매번 별도의 데이터셋을 만들고 파인튜닝하는 대신, 원하는 능력을 설명하면 하이퍼네트워크가 필요한 가중치 업데이트를 생성하는 것이다.

이 방법이 모든 파인튜닝이나 RAG 시스템을 바로 대체한다고 보기는 어렵다. 하지만 모델을 새로운 지식과 작업에 적응시키는 과정을 더 빠르고 유연하게 만들려는 발상은 상당히 흥미로웠다.

그리고 이번에는 여러 모델을 협업시키는 Fugu

이러한 연구 흐름 속에서 Sakana AI가 공개한 것이 Fugu다.

Fugu라는 이름만 보면 GPT나 Claude와 경쟁하는 새로운 대형 언어 모델처럼 보일 수 있다.

하지만 Fugu는 하나의 거대한 단일 모델이 아니다. 여러 AI 모델을 하나의 팀처럼 구성하고, 문제에 맞게 역할을 나누어 협업시키는 멀티 에이전트 오케스트레이션 시스템이다.

기존의 일반적인 AI 사용 방식은 다음과 같다.

사용자
  ↓
GPT 또는 Claude
  ↓
결과

사용자는 작업에 맞춰 어떤 모델을 사용할지 직접 선택한다.

코딩에는 GPT를 쓰고, 긴 문서에는 Claude를 쓰고, 검색이나 멀티모달 작업에는 Gemini를 사용하는 식이다.

반면 Fugu는 다음과 같은 방식으로 동작한다.

사용자
  ↓
Fugu
  ├─ 전체 전략을 세우는 모델
  ├─ 실제 작업을 수행하는 모델
  ├─ 결과를 검증하는 모델
  └─ 필요하면 작업을 다시 조정하는 모델
  ↓
최종 결과

사용자는 하나의 API를 호출하지만, 내부에서는 여러 모델이 각자의 역할을 맡아 문제를 해결한다.

단순한 모델 라우터와는 다르다

여러 모델을 연결한다고 하면 보통 가장 먼저 모델 라우터를 떠올릴 수 있다.

예를 들어 작업 유형에 따라 모델을 선택하는 방식이다.

if task == "coding":
    use_gpt()

if task == "document":
    use_claude()

이 방식에서는 코딩 문제면 GPT, 문서 작업이면 Claude처럼 미리 정해 둔 규칙에 따라 모델 하나를 선택한다.

Fugu는 모델 하나를 선택하는 데서 끝나지 않는다.

문제를 여러 하위 작업으로 나누고, 각 단계에 어떤 모델을 배치할지 결정한다. 첫 번째 결과가 충분하지 않다면 다른 모델을 호출해 검토하거나 수정하게 할 수도 있다. 즉, Fugu의 핵심은 다음과 같다.

어떤 모델을 사용할 것인가가 아니라, 여러 모델을 어떻게 협업시킬 것인가.

Fugu의 기반이 된 Trinity

Fugu의 기반 연구 중 하나인 Trinity는 작은 코디네이터가 여러 모델에 역할을 배정하는 구조다.

Trinity라는 이름처럼 세 가지 역할을 중심으로 구성된다.

• Thinker: 전체 문제를 분석하고 해결 전략을 세운다.
• Worker: 구체적인 문제 해결 작업을 수행한다.
• Verifier: 결과가 정확한지, 문제의 요구사항을 충족했는지 검증한다.

중요한 점은 코디네이터가 직접 모든 문제를 해결할 필요가 없다는 것이다.

코디네이터의 역할은 어떤 모델에게 어떤 작업을 맡길지 결정하고, 모델 사이에 필요한 정보를 전달하는 것이다.

사람으로 비유하면 직접 모든 업무를 처리하는 실무자보다, 각자의 전문성을 가진 팀원을 적절히 배치하는 PM에 가깝다.

 

협업 구조 자체를 학습하는 Conductor

Conductor는 여기서 한 단계 더 나아간다.

기존 에이전트 시스템에서는 사람이 워크플로를 미리 설계하는 경우가 많다.

Planner → Coder → Reviewer

이처럼 계획 담당, 코드 작성 담당, 검토 담당을 사전에 정해 두는 방식이다.

Conductor는 어떤 에이전트를 호출할지, 어떤 작업을 요청할지, 이전 작업의 어떤 내용을 전달할지까지 자연어로 구성한다.

쉬운 문제라면 모델 하나를 한 번 호출하고 끝낼 수 있다.

하지만 복잡한 코딩 문제라면 다음과 같은 구조를 만들 수 있다.

문제 분석
  ↓
구현 계획 작성
  ↓
코드 생성
  ↓
테스트 및 오류 분석
  ↓
코드 수정
  ↓
최종 검증

이 흐름은 사람이 고정해 둔 것이 아니다.

Conductor는 강화학습을 통해 문제에 따라 어떤 협업 방식이 효과적인지를 학습한다.

결국 Fugu는 여러 모델을 단순히 묶어 둔 시스템이 아니라,

AI가 다른 AI를 활용하는 방법을 학습한 시스템

기존 에이전트 프레임워크와 무엇이 다른가

멀티 에이전트나 오케스트레이션 자체가 완전히 새로운 개념은 아니다.

이미 LangGraph, CrewAI, OpenAI Agents SDK 등을 이용하면 여러 에이전트를 연결할 수 있다.

Claude Code, Codex, OpenCode 같은 코딩 도구도 계획, 실행, 검증과 유사한 흐름을 사용한다.

이전 글에서 다뤘던 하네스 엔지니어링 역시 같은 방향에 있다. 모델 자체의 성능뿐 아니라,

• 어떤 컨텍스트를 제공하는지
• 어떤 도구를 연결하는지
• 작업을 어떻게 나누는지
• 결과를 어떻게 검증하는지
• 실패했을 때 어떻게 다시 시도하는지

가 실제 결과에 큰 영향을 미친다.

다만 기존의 많은 에이전트 시스템은 개발자가 역할과 순서를 직접 설계한다.

반면 Fugu는 이러한 협업 구조를 문제마다 동적으로 구성하려 한다. 필요한 모델의 수와 역할, 호출 순서, 검증 과정까지 학습의 대상으로 확장한 것이다.

Fugu Mini와 Fugu Ultra

Sakana AI는 Fugu를 두 가지 형태로 소개했다.

• Fugu Mini
  응답 속도와 지연시간을 고려한 버전이다. 모든 문제에 많은 모델을 호출하면 비용과 시간이 증가하기 때문에, 상대적으로 실용적인 사용 환경을 고려한 모델로 볼 수 있다.
• Fugu Ultra
  전체 모델 풀을 활용해 성능을 우선하는 버전이다. 복잡한 코딩, 수학, 과학적 추론처럼 한 번의 모델 호출만으로 해결하기 어려운 작업을 대상으로 한다.

현재 Fugu는 초기 단계이기 때문에 실제 비용과 지연시간, 안정성은 더 지켜볼 필요가 있다.

여러 프런티어 모델을 호출하는 구조상 단일 모델보다 비싸고 느려질 가능성도 있다. 따라서 일상적인 간단한 질문보다, 복잡하고 실패 비용이 큰 작업에서 오케스트레이션의 장점이 얼마나 나타나는지가 중요해 보인다.

여러 회사의 API 키를 사용자가 직접 관리할 필요는 없다

Fugu를 처음 접했을 때는 다음과 같은 의문이 들 수 있다.

사용자가 OpenAI, Anthropic, Google API 키를 모두 준비해야 하는 것 아닐까?

Fugu는 사용자가 여러 모델을 직접 조립하는 프레임워크와는 다르다.

사용자는 Fugu API를 호출하고, 그 뒤에서 어떤 모델을 어떤 방식으로 협업시킬지는 Sakana AI의 시스템이 처리한다.

OpenAI API 형식과 호환되도록 제공되기 때문에 기존에 OpenAI 형식으로 만들어진 코드에서도 엔드포인트와 설정을 변경해 연결할 수 있다. 즉, Fugu의 목표는 사용자가 여러 모델과 API를 직접 관리하게 하는 것이 아니다. 여러 모델을 선택하고 협업시키는 복잡한 과정을 하나의 API 뒤로 감추는 것이다.

Fable 5와 Mythos 5 이후에 더 흥미롭게 보이는 이유

최근 Fable 5와 Mythos 5를 둘러싼 접근 제한 논란은 특정 모델에 대한 의존 문제를 다시 생각하게 만들었다.

성능이 뛰어난 모델 하나를 중심으로 업무 흐름을 구성하면 편리하다.

그러나 해당 모델의 정책이나 가격, 제공 범위가 바뀌면 전체 시스템이 영향을 받을 수 있다.

이런 상황에서 보통은 대체 모델을 찾는다.

하지만 Fugu는 대체 모델 하나를 찾는 것에서 더 나아간다.

하나의 모델에 모든 업무를 맡기지 않고, 여러 모델을 교체 가능한 팀원처럼 활용한다.

물론 Fugu 역시 연결된 외부 모델과 공급자의 정책에서 완전히 자유로운 것은 아니다.

특정 모델이 모델 풀에서 빠진다면 성능이나 협업 방식이 달라질 수 있다. 따라서 Fugu가 벤더 종속 문제를 완전히 해결한다고 보기는 어렵다. 그럼에도 사용자가 특정 모델에 맞춰 전체 워크플로를 다시 설계하지 않아도 되고, 모델 풀이 변하면 오케스트레이터가 새로운 조합을 선택할 수 있다는 점은 의미가 있다.

모델 경쟁에서 오케스트레이션 경쟁으로

지금까지 AI 업계의 중심 질문은 대체로 다음과 같았다.

어느 회사가 가장 강력한 모델을 만들 것인가?

 

하지만 Fugu가 던지는 질문은 조금 다르다.

이미 존재하는 여러 강력한 모델을 누가 가장 잘 협업시킬 것인가?

 

모든 영역에서 가장 뛰어난 단일 모델을 만드는 것은 쉽지 않다. 모델마다 강점과 약점이 다르고, 같은 코딩 작업 안에서도 계획, 구현, 디버깅, 검증에 적합한 모델이 달라질 수 있다. 앞으로는 사용자가 어떤 모델을 선택했는지보다, 최종 결과를 만들기 위해 여러 모델이 어떤 방식으로 협력했는지가 더 중요해질 수도 있다.

Fugu는 모델 선택과 에이전트 협업 구조 자체를 학습의 대상으로 확장했다는 점에서 흥미롭다.

Sakana AI를 계속 지켜보게 되는 이유

개인적으로 Sakana AI를 높게 평가하는 이유는 단순히 Fugu의 벤치마크 성능 때문이 아니다.

Evolutionary Model Merge에서는 여러 모델을 결합하는 방법을 탐색했고, AI Scientist에서는 연구 과정 전체의 자동화를 시도했다.

Doc-to-LoRA와 Text-to-LoRA에서는 모델을 새로운 지식과 작업에 적응시키는 과정을 다시 설계했다.

그리고 Trinity와 Conductor, Fugu에서는 여러 모델을 하나의 팀으로 운영하는 방법을 연구하고 있다.

 

모든 연구가 곧바로 상용화되거나 기존 방법을 대체하지는 않을 것이다.

하지만 단순히 더 큰 모델을 만드는 경쟁을 따라가기보다, 모델을 만들고 결합하고 적응시키고 운영하는 방식을 계속 새롭게 제안한다는 점은 분명 인상적이다.

AI 업계에서 자주 들리는 이름이 일부 대형 기업에 집중된 상황에서도 Sakana AI는 독자적인 연구 결과를 꾸준히 발표하며 존재감을 보여주고 있다.

개인적으로는 이런 연구 조직이 계속 새로운 접근을 제시하고, 글로벌 AI 연구 흐름에서 꾸준히 언급된다는 점을 리스펙하게 된다.

 

마무리

Fugu는 GPT나 Claude를 대체하는 새로운 단일 모델이 아니다.

GPT, Claude, Gemini, 오픈소스 모델 등 서로 다른 AI의 능력을 문제에 맞게 조합하는 멀티 에이전트 오케스트레이션 시스템이다.

Sakana AI가 지금까지 진행한 연구를 함께 보면 Fugu는 갑자기 등장한 제품도 아니다.

기존 모델을 진화적으로 결합하고, 연구 과정을 에이전트로 자동화하고, 모델이 새로운 지식과 작업에 빠르게 적응하도록 만들었던 연구들이 멀티 에이전트 오케스트레이션이라는 형태로 이어진 결과에 가깝다.

Fable 5와 Mythos 5의 접근 제한처럼 특정 모델에 대한 의존성을 다시 생각하게 만드는 사건이 이어지는 시점이라는 점에서도 흥미롭다.

앞으로 중요한 것은 최고의 모델 하나를 고르는 능력만이 아닐 수 있다.

여러 모델을 어떤 구조로 연결하고, 어떤 역할을 맡기며, 결과를 어떻게 검증할 것인가.

 

Fugu는 AI 경쟁이 단일 모델의 성능 경쟁에서 AI 팀을 구성하고 운영하는 경쟁으로 확장될 가능성을 보여준다.

그리고 Sakana AI가 이러한 방향을 꾸준한 연구를 통해 실제 제품으로 연결하고 있다는 점에서 앞으로의 행보도 계속 지켜보고 싶다.

참고 자료

https://sakana.ai/fugu-release/

https://sakana.ai/fugu-beta/

https://sakana.ai/trinity/

https://sakana.ai/learning-to-orchestrate/

https://sakana.ai/evolutionary-model-merge/

https://sakana.ai/ai-scientist/

https://sakana.ai/doc-to-lora/

https://sakana.ai/company-info/