AI 성능 경쟁은 흔히 “더 큰 모델”이나 “더 높은 벤치마크 점수”로 설명됩니다. 도쿄 기반 AI 스타트업 Sakana AI가 공개한 Fugu는 조금 다른 방향을 제시합니다. 하나의 거대한 모델에 모든 일을 맡기기보다, 여러 LLM과 에이전트를 상황에 맞게 고르고 조율하는 방식입니다.
핵심 질문은 이것입니다. 앞으로 AI를 잘 쓰는 기준은 “어떤 모델 하나를 고르느냐”가 아니라 “여러 모델을 어떻게 지휘하느냐”가 될 수 있을까요?
Fugu는 하나의 모델처럼 보이는 멀티에이전트 시스템
Fugu는 여러 AI 에이전트를 내부에서 조율하지만, 사용자에게는 하나의 모델처럼 제공됩니다.1 사용자는 단일 API 엔드포인트로 요청을 보내고, Fugu는 그 요청을 직접 처리할지, 아니면 전문 모델들로 팀을 구성할지 내부적으로 판단합니다.2
여기서 중요한 점은 Fugu 자체도 언어 모델이라는 사실입니다. Fugu는 어떤 LLM을 호출할지, 작업을 어떻게 나눌지, 결과를 어떻게 검증하고 통합할지를 관리하도록 설계되었습니다.2 필요하면 자기 자신을 에이전트 풀의 일부로 다시 호출할 수도 있습니다.2
즉 Fugu의 가치는 “또 하나의 챗봇”이라기보다, 복잡한 멀티에이전트 구성을 사용자가 직접 설계하지 않아도 되게 만드는 조율 계층에 있습니다. 사용자는 하나의 모델을 쓰는 것처럼 접근하지만, 내부에서는 요청의 성격에 따라 여러 모델과 에이전트가 동적으로 활용될 수 있습니다.
무엇이 달라지나: 모델 선택에서 조율 전략으로
Fugu가 흥미로운 이유는 성능 경쟁의 초점을 바꾼다는 데 있습니다. 기존에는 특정 업무에 가장 강한 단일 모델을 고르는 것이 중요했습니다. Fugu식 접근에서는 요청을 해석하고, 적절한 모델을 배치하고, 결과를 검증해 합치는 과정 자체가 핵심 역량이 됩니다.
이 방식은 운영 측면에서도 의미가 있습니다. 특정 모델 API 하나에만 의존하면 가격, 정책, 접근 권한, 규제 변화에 취약해질 수 있습니다. 반면 Fugu는 내부 모델 풀을 활용하는 구조이기 때문에, 어떤 모델을 조합할지에 따라 유연성을 확보할 여지가 있습니다.2
물론 이것이 완전한 독립성이나 “AI 주권”을 보장한다는 뜻은 아닙니다. Fugu의 성능과 안정성도 결국 어떤 모델을 풀에 넣고, 어떤 방식으로 호출하며, 실제 업무에서 얼마나 잘 검증되느냐에 달려 있습니다. 따라서 도입 여부를 판단할 때는 발표 자료의 성능 주장만 볼 것이 아니라, 자신의 업무 데이터와 지연시간, 비용, 보안 요구에 맞춰 평가해야 합니다.
Fugu와 Fugu Ultra는 어떻게 다르게 봐야 하나
Sakana AI는 Fugu와 Fugu Ultra 두 가지 변형을 출시했습니다. 일반 Fugu는 낮은 지연시간과 강한 성능의 균형을 목표로 한 일반 업무용 모델입니다.2 코딩 도구, 코드 리뷰, 챗봇, 대화형 서비스처럼 응답 속도와 품질을 함께 요구하는 사용 사례에 적합합니다.2
Fugu Ultra는 더 어려운 다단계 문제에서 답변 품질을 극대화하도록 조정된 모델입니다.2 복잡한 분석, 긴 문서 검토, 연구 보조, 여러 단계의 추론이 필요한 작업처럼 단순 응답보다 검토와 통합 능력이 중요한 상황에 더 어울립니다.
실무적으로는 이렇게 나눠 생각할 수 있습니다.
빠른 응답과 범용성이 중요하다면 Fugu
복잡한 문제 해결과 답변 품질이 더 중요하다면 Fugu Ultra
비용, 지연시간, 정확도 사이의 균형이 필요하다면 두 모델을 업무별로 나눠 평가
기존 워크플로우에 붙이기 쉬운 구조
Fugu의 또 다른 장점은 도입 방식입니다. Sakana API는 Fugu에 대해 Chat Completions와 Responses 엔드포인트를 지원합니다.1 또한 Fugu는 단일 OpenAI 호환 API를 통해 제공되므로, 기존에 OpenAI 스타일 API를 사용하던 시스템이라면 비교적 익숙한 방식으로 실험할 수 있습니다.2
이는 멀티에이전트 시스템의 복잡성을 상당 부분 감춥니다. 개발자는 여러 모델 호출 순서, 작업 분배, 결과 통합 로직을 처음부터 직접 구현하지 않고도, 하나의 API 뒤에서 작동하는 조율 시스템을 테스트할 수 있습니다.
다만 기업 환경에서는 추가로 확인할 지점이 있습니다. Fugu는 데이터, 개인정보, 컴플라이언스 요구에 맞춰 특정 에이전트를 풀에서 제외하는 옵션을 제공합니다.2 따라서 실제 도입 시에는 어떤 에이전트가 사용되는지, 어떤 데이터가 어디로 전달되는지, 제외 설정이 조직의 보안 정책과 맞는지를 함께 검토해야 합니다.
Fugu가 보여주는 실무적 교훈
Sakana AI에 따르면 약 500명의 베타 사용자가 Fugu를 테스트했습니다. 이 숫자만으로 제품의 완성도를 판단할 수는 없지만, 적어도 Fugu가 단순한 연구 아이디어가 아니라 실제 사용 환경을 겨냥한 시스템이라는 점은 분명합니다.
Fugu가 던지는 메시지는 명확합니다. 앞으로 AI 도입 판단 기준은 “가장 똑똑한 단일 모델이 무엇인가”에서 “업무에 맞게 모델을 얼마나 잘 조합하고 운영할 수 있는가”로 확장될 수 있습니다.
따라서 Fugu를 볼 때는 단순히 새 모델 하나가 나왔다고 보기보다, 다음 질문을 던지는 것이 더 유용합니다.
우리 업무는 단일 모델보다 여러 전문 모델의 조합이 유리한가?
지연시간과 품질 중 무엇을 더 우선해야 하는가?
모델 API 의존성과 운영 리스크를 어떻게 줄일 것인가?
데이터와 컴플라이언스 요구에 맞춰 에이전트 사용을 통제할 수 있는가?
기존 API 워크플로우에 얼마나 쉽게 연결할 수 있는가?
결론적으로 Fugu는 “더 큰 모델”보다 “더 잘 지휘하는 모델”이 중요해질 수 있음을 보여주는 사례입니다. AI 활용의 경쟁력은 모델 성능표만이 아니라, 조율 방식, 비용, 지연시간, 보안, 벤더 리스크를 함께 설계하는 능력에서 나올 가능성이 커지고 있습니다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.