요즘 AI 뉴스를 보면 더 큰 모델, 더 빠른 모델, 더 싼 모델 이야기가 계속 나온다. 그런데 Sakana AI가 공개한 Fugu에서 내가 본 핵심은 새 모델 하나의 성능이 아니었다.
내 판단은 이렇다. 다음 AI 경쟁은 단일 모델의 지능이 아니라, 여러 모델을 어떻게 조합하고 검증하고 합성하느냐로 이동하고 있다.
이걸 Sakana는 collective intelligence, 그러니까 집단지능으로 설명한다. 사용자 입장에서는 하나의 모델 API처럼 보이지만, 내부에서는 여러 AI 모델과 에이전트가 작업을 나누고, 결과를 검증하고, 하나의 답으로 합치는 구조다.
이미지 출처: Sakana AI, 「Sakana Fugu」 공식 발표 자료
Fugu는 새 모델이라기보다 조율하는 모델에 가깝다
공식자료에 따르면 Fugu는 여러 전문 AI 모델을 상황에 따라 조합해 단일 모델처럼 동작하게 만드는 오케스트레이션 시스템이다. 사용자가 하나의 API endpoint에 요청을 보내면, 내부에서 어떤 모델을 쓸지 고르고, 작업을 나누고, 결과를 검증한 뒤 최종 답을 합성한다.
여기서 중요한 건 “Fugu가 GPT보다 세냐, Claude보다 세냐”가 아니다. 그 질문은 너무 좁다.
진짜 질문은 이것이다.
AI 시스템이 여러 모델의 장점을 어떻게 모으고, 약점을 어떻게 피하고, 실패를 어떻게 검증할 수 있느냐.
지금까지 많은 개발자는 모델 선택을 코드 바깥의 단순 옵션처럼 봤다. GPT를 쓸지, Claude를 쓸지, Gemini를 쓸지 고르면 된다고 생각했다. 그런데 Fugu식 접근은 그 선택 자체를 하나의 시스템 문제로 바꾼다.
이제 모델은 하나의 부품이 된다. 중요한 건 그 부품들을 어떤 순서로 부르고, 어떤 결과를 믿고, 어떤 답을 버리고, 어떤 방식으로 최종 결과를 만들 것인가다.
핵심은 learned orchestration이다
Sakana는 Fugu의 핵심을 learned orchestration으로 설명한다. 사람이 미리 “이 작업은 A 모델, 저 작업은 B 모델”이라고 고정 규칙을 짜는 방식이 아니다. 오케스트레이터 모델이 상황에 따라 어떤 에이전트를 부르고, 어떤 역할을 맡기고, 결과를 어떻게 합칠지 학습한다는 주장이다.
이 배경에는 Sakana가 공개한 TRINITY와 Conductor 연구가 있다. TRINITY는 여러 LLM에 Thinker, Worker, Verifier 같은 역할을 동적으로 배정하는 coordinator 구조를 보여준다. Conductor는 강화학습을 통해 자연어 기반 협업 전략을 학습하고, 문제 난이도에 따라 planner, executor, verifier 흐름을 만들어내는 연구다.
내가 보기엔 이 지점이 중요하다. 앞으로 AI 자동화에서 경쟁력은 “제일 좋은 모델을 하나 고르는 능력”만으로 끝나지 않는다. 여러 모델과 도구를 일하게 만드는 운영 지능이 필요해진다.
개발 자동화도 마찬가지다. 초안 생성은 빠른 모델이 하고, 코드 수정은 코딩 특화 모델이 하고, 리뷰는 더 비싼 고성능 모델이 하고, 최종 검증은 테스트와 룰 기반 체크가 맡는 구조가 더 현실적일 수 있다.
여기서부터는 프롬프트보다 워크플로우 설계가 중요해진다.
Fable과 Mythos 이슈가 보여준 단일 벤더 의존 리스크
이번 발표에서 Sakana가 강하게 밀고 있는 논리는 성능만이 아니다. 단일 벤더 의존성이다.
Anthropic은 미국 정부 지시에 따라 Fable 5와 Mythos 5 접근을 중단해야 했다고 공식 발표했다. 국내에서는 이 이슈가 Fable5처럼 붙여 쓰는 키워드로도 많이 검색된다. 핵심은 모델 이름 자체보다, 특정 고성능 모델 접근이 정책과 외부 조건에 따라 갑자기 끊길 수 있다는 점이다.
Sakana는 이 사례를 들며 중요한 인프라, 금융, 정부 시스템이 특정 AI 공급자 하나에 의존하는 것은 현실적인 취약점이라고 주장한다. 이 말은 과장해서 받아들이면 안 된다. Fugu가 모든 AI 주권 문제를 해결했다는 뜻은 아니다. Fugu 역시 여러 폐쇄형 모델 위에서 돌아가는 상용 서비스이고, 내부 모델 pool과 routing 방식은 완전히 공개되어 있지 않다.
하지만 문제 제기 자체는 맞다.
우리가 자동화 시스템을 만들 때 특정 모델명 하나를 코드 곳곳에 박아두면, 나중에 가격이 바뀌거나, API 정책이 바뀌거나, 접근이 제한될 때 전체 workflow가 흔들린다. 단일 모델 호출이 편하긴 하지만, 운영 관점에서는 취약한 구조가 될 수 있다.
그래서 앞으로는 모델을 직접 호출하는 코드보다, 모델을 교체하고 우회하고 검증할 수 있는 layer가 더 중요해진다.
개발자가 봐야 할 변화는 여섯 가지다
첫째, API abstraction이 필요하다.
특정 모델명을 코드에 직접 박는 순간 나중에 바꾸는 비용이 커진다. 지금은 편해도, 자동화가 커질수록 모델 교체 비용이 기술부채가 된다.
둘째, model pool을 생각해야 한다.
하나의 만능 모델이 아니라 작업별 모델 묶음이 필요하다. 빠른 초안 모델, 고성능 검증 모델, 코드 특화 모델, 문서화 모델, 저비용 모델을 나눠 쓰는 식이다.
셋째, verification이 핵심이 된다.
AI 답변을 그대로 믿는 구조는 오래 못 간다. 테스트 실행, 타입 체크, lint, diff 리뷰, 여러 모델 간 교차 검증, 룰 기반 gate가 붙어야 한다.
넷째, synthesis가 중요하다.
여러 모델에게 답을 받는다고 집단지능이 되는 건 아니다. 진짜 집단지능은 여러 답을 비교하고, 충돌을 정리하고, 더 나은 하나의 결과물로 합성하는 데서 나온다.
다섯째, vendor dependency를 줄여야 한다.
특정 회사 모델 하나가 막히면 전체 자동화가 멈추는 구조는 위험하다. 최소한 fallback 경로와 교체 가능한 interface는 있어야 한다.
여섯째, cost and black-box risk를 봐야 한다.
모델을 여러 개 붙이면 똑똑해지는 것처럼 보이지만, 잘못 설계하면 API 비용이 여러 배로 터진다. 게다가 내부에서 어떤 모델이 왜 선택됐는지 안 보이면 디버깅도 어려워진다.
여기서 삽질이 생긴다. 집단지능 구조는 강력하지만, 검증 로그와 비용 제어 없이 붙이면 자동화가 아니라 블랙박스 비용 폭탄이 된다.
Fugu의 벤치마크는 방향성을 보는 게 맞다
공식자료에 따르면 Fugu Ultra는 여러 코딩, 과학, 추론 benchmark에서 frontier model들과 비슷하거나 일부 앞서는 성능을 냈다고 설명한다.
다만 여기서 조심해야 한다. 공식 자료에 따르면 Fugu 외 baseline 점수는 각 모델 제공사가 보고한 수치를 사용하는 경우가 있고, Fable 5와 Mythos Preview는 Fugu의 agent pool에 포함되지 않았다고 설명한다.
그러니까 이걸 “Fugu가 모든 모델을 이겼다”로 쓰면 안 된다.
내가 보기엔 숫자보다 중요한 건 구조다. Fugu가 보여준 건 단일 모델을 더 크게 키우는 방식 말고도, 여러 모델을 잘 조율해서 frontier급 결과에 접근하는 다른 경로가 있다는 점이다.
이 흐름은 개발자에게 더 중요하다. 우리는 frontier model을 직접 만드는 사람이 아니라, 그것들을 어떻게 업무 workflow 안에 넣을지 고민하는 사람에 가깝기 때문이다.
실전 적용은 이렇게 시작하면 된다
내가 AI 자동화 workflow를 설계한다면 이제 질문 순서를 바꿀 것 같다.
예전 질문은 이랬다.
“어떤 모델이 제일 좋지?”
이제는 이렇게 물어야 한다.
“이 작업은 어떤 단계로 나뉘고, 각 단계는 어떤 모델이 맡고, 실패는 어떻게 감지하고, 최종 결과는 어떻게 검증하지?”
간단한 구조로 쓰면 이렇다.
사용자 요청
→ 작업 분류
→ 적절한 모델 선택
→ 1차 결과 생성
→ 테스트 또는 검증 모델로 확인
→ 실패 시 재시도 또는 다른 모델 호출
→ 최종 결과 합성
→ 로그 저장이 구조가 바로 계속 실험해볼 만한 영역이다. Codex, Claude Code, Hermes Agent, GitHub Actions, n8n 같은 도구를 붙일 때도 핵심은 같다. 모델 하나의 답을 잘 받는 것보다, 실패를 감지하고 다시 돌리고 검증하는 구조를 만드는 쪽이 더 오래 간다.
결론은 명확하다
Sakana Fugu가 보여준 건 단순히 새로운 AI 모델 하나가 아니다. AI 경쟁이 점점 “모델을 만드는 싸움”에서 “모델들을 어떻게 일하게 만들 것인가”로 이동하고 있다는 신호다.
개발자에게 이 변화는 꽤 중요하다. 앞으로 생산성을 올리는 사람은 프롬프트를 잘 쓰는 사람을 넘어, AI 모델과 도구와 검증 과정을 하나의 워크플로우로 설계하는 사람이 될 가능성이 크다.
집단지능은 멋진 단어지만, 실전에서는 꽤 냉정한 문제다. 어떤 모델을 부를지, 언제 믿을지, 언제 버릴지, 실패하면 어떻게 복구할지까지 설계해야 한다.
삽질은 후츠릿이 먼저 합니다.
다음 단계는 이 집단지능 구조를 실제 개발 자동화 workflow로 만들어보는 것이다.
참고 자료
'👩🏻💻 후츠릿 인사이트' 카테고리의 다른 글
| Codex Record & Replay로 업무를 Skill로 남기는 법 (0) | 2026.06.19 |
|---|---|
| Claude Code 권한 규칙, 도구보다 입력값이 위험하다 (0) | 2026.06.16 |
| 에이전트 자동화는 이제 Markdown 운영 계약으로 관리된다 (0) | 2026.06.15 |
| Claude Fable 5, Claude Code는 모델보다 작업 설계가 먼저다 (0) | 2026.06.11 |
| Codex는 리서치와 코딩이 한 루프에서 검증될 때 의미가 있다 (3) | 2026.06.10 |
