같은 질문을 보내도 어떤 모델에 물어보느냐에 따라 답이 달라지다 보니, 코딩할 땐 이 모델을 쓰고 글을 쓸 땐 저 모델을 쓰는 식으로 매번 다른 도구를 골라 쓰게 돼요.
성능 좋은 모델을 쓰고 싶다가도 비용이나 응답 속도까지 따지기 시작하면 선택은 더 복잡해져요.
이 여러 모델을 매번 따로 고르는 대신, 하나의 창구 뒤에 다 모아놓고 알아서 적합한 걸 골라 쓰게 하는 방식이 있어요.
이런 구조를 넓게는 모델 오케스트레이션이라고 부르는데, 그 안에서 질문이나 작업을 어떤 모델로 보낼지 정하는 기능을 AI 라우터 라고 해요.
Fugu는 모델을 고르거나 작업 흐름을 설계해요
일본 스타트업 사카나 AI가 만든 Fugu가 이 방식을 보여주는 사례예요.
서비스를 만드는 쪽에서는 Fugu API 하나에 질문을 보내는 것처럼 보이지만, 뒤에서는 Fugu가 작업에 맞는 프론티어 모델 하나를 고르거나 상위 버전인 Fugu-Ultra가 여러 단계를 거치는 작업 흐름까지 설계해요.
Fugu 자체도 언어모델이고, 이 모델이 다른 모델들을 부르고 조율하는 법을 학습했어요. 사카나 AI는 이 구조가 TRINITY를 비롯한 ICLR 2026 연구를 바탕으로 한다고 설명해요.
그중 TRINITY는 계획을 세우는 Thinker, 실제로 답을 만드는 Worker, 결과를 점검하는 Verifier로 역할을 나눠 모델들을 지휘하는 방식을 제안해요.
배정 규칙도 사람이 짜지 않고, 학습으로 만들어졌어요
여기서 중요한 건 이 배정 규칙 자체가 미리 정해진 게 아니라 학습된 거라는 점이에요. “코딩 질문이면 A 모델, 글쓰기면 B 모델” 식으로 사람이 정해둔 if-else 규칙이 아니에요.
대신 여러 배정 조합 중 어떤 게 더 좋은 결과를 냈는지를 점수처럼 평가받고, 그 결과를 바탕으로 다음 배정을 조정하는 방식으로 학습했어요.
사카나 AI가 이 방식을 설명하며 내세우는 이유 중 하나는 특정 회사 모델에 대한 의존을 줄이는 일이에요.
실제로 지난 6월 미국 정부가 수출통제를 이유로 앤트로픽의 Fable 5와 Mythos 5에 대한 해외 이용자 전체의 접근을 한때 막은 일이 있었는데, 사카나 AI는 이 사례를 들면서 하나의 회사 API에만 의존하는 게 위험하다고 설명해요.
다만 이 방식이 실제로 얼마나 잘 작동하는지, 벤치마크만큼 실사용에서도 만족스러운지는 또 다른 이야기예요.
Fugu를 직접 써본 사람들 반응은 갈렸는데, 그 부분은 다른 글에서 이미 다뤘어요.
그래도 Fugu는 여러 AI 모델을 함께 쓸 때, 사람이 배정 규칙을 하나씩 정하지 않아도 되는 방식을 보여주는 사례예요.
여러 모델을 직접 비교해서 고르는 일이 편한가요, 아니면 질문에 따라 알아서 나눠 맡기는 방식이 더 편할 것 같으세요?