Sakana Fugu: 선택과 협업의 비용

모든 질문에 에이전트 세 명을 부르면 쉬운 질문도 세 번의 답을 기다린다. 반대로 언제나 한 명만 부르면 구현 담당의 오류를 다른 관점에서 찾을 기회를 놓칠 수 있다. 여러 모델을 쓰는 시스템을 설계할 때는 누구를 고를지와 몇 단계를 협업할지를 나눠 생각해야 한다.

Sakana Fugu Technical Report(Sakana AI, 2026년 6월 19일, arXiv v1)은 이 두 선택을 Fugu와 Fugu-Ultra로 구분한다. Fugu는 한 입력에서 작업자 하나를 빠르게 고르고 Fugu-Ultra는 작업 지시와 결과 전달 경로를 포함한 여러 단계의 협업을 만든다. 이 글은 연결된 v1을 기준으로 두 방식의 차이, 도구 호출의 기억 경계, 보고된 성능이 말하는 범위를 살핀다.

조정자도 답을 길게 쓰면 기다려야 한다

라우팅은 입력에 맞는 작업자를 고르는 일이다. 조정자가 “이 질문은 수학 문제이며…” 같은 긴 설명을 생성한 뒤 작업자를 호출하면 그 설명을 생성하는 시간까지 응답 지연에 들어간다. 작업자가 이미 답을 만들 수 있다면 선택 과정에서 굳이 같은 내용을 다시 풀 필요가 없다.

Fugu의 조정자는 모델 내부의 은닉 상태, 즉 입력을 처리하며 만든 수치 표현을 사용한다. 마지막 계층 뒤에 붙인 작은 선택 모듈은 작업자마다 점수를 하나씩 내고 그 점수로 작업자를 고른다. 조정자가 자연어 계획 전체를 생성할 필요가 없으므로 생성 토큰에 따른 대기 시간을 줄일 수 있다. v1에서는 역할까지 고르지 않고 선택한 모델을 항상 작업자로 부른다. Fugu 원문

여기서 “작업자 하나”는 대화가 끝날 때까지 같은 모델을 고정한다는 뜻이 아니다. 여러 턴의 작업에서는 그동안의 도구 결과와 대화 상태를 입력으로 다시 선택한다. 코드를 만들 때 고른 모델과 실패한 실행을 분석할 때 고른 모델이 달라질 수 있다. 한 번의 선택에 여러 에이전트의 합의가 필요하지 않다는 의미에 가깝다.

학습도 두 단계다. 먼저 정답을 확인할 수 있는 질문에 여러 작업자를 반복 실행해 각자의 평균 보상을 구한다. 가장 높은 모델 하나만 정답으로 삼지 않고 보상에 따라 부드러운 목표 분포를 만든다. 비슷한 성능의 두 작업자가 있으면 그 차이를 지나치게 확정하지 않기 위해서다. 그 뒤에는 도구 호출·코드 수정·실행 피드백이 있는 전체 작업의 완료 여부를 보상으로 삼아 선택 정책을 진화 전략으로 다듬는다. 한 질문의 정답률과 도구 환경에서의 완주 능력이 같지 않다는 판단이 학습에 들어간다.

선택 모듈이 가벼워도 그 입력 표현까지 고정하는 것은 아니다. 보고서는 일부 가중치 행렬을 분해한 뒤 방향을 나타내는 성분은 고정하고 특잇값의 크기만 학습한다. 입력을 읽는 표현을 라우팅에 맞춰 조정하면서 학습할 매개변수를 줄이는 방식이다. 이어지는 진화 전략은 매개변수를 조금씩 바꾼 여러 선택 정책을 실제 작업에 실행하고 완료 보상이 높은 정책을 다음 탐색에 반영한다. 외부 작업자와 도구 환경을 미분하지 않고도 전체 성공률을 최적화할 수 있는 이유다. Fugu 선택 정책의 학습

이 설계는 “작은 라우터가 모든 것을 이해한다”는 주장보다 훨씬 구체적이다. 라우터는 입력을 읽어 누구에게 맡길지 판단하고 실제 해결은 작업자가 수행한다. 또 빠른 선택과 저렴한 전체 실행은 같지 않다. 최종 완료 여부를 보상으로 쓰는 학습식에는 달러 비용이나 응답 지연의 벌점이 없으므로 지연을 줄이는 근거는 생성 계획을 생략한 구조에 있다. 실제 사용에서 비용과 지연이 얼마나 줄었는지는 별도로 측정해야 한다.

Fugu-Ultra에서는 지시와 전달 경로까지 정한다

Fugu-Ultra는 Conductor 방식의 조정자를 확장한다. 한 단계에는 자연어 하위 작업, 담당 작업자, 앞 단계의 어떤 결과를 볼지 정하는 **접근 목록(access list)**이 들어간다. 조정자는 최대 다섯 단계의 흐름을 만들도록 학습한다. 단순히 여러 모델에 같은 질문을 보내 다수결을 하는 것보다 넓은 선택 공간이다.

예를 들어 입력에 구현과 검증이 함께 필요하다면 구현 담당에게 완성본을 만들게 하고 다른 작업자에게 오류를 찾게 한 뒤 마지막 단계에서 필요한 결과를 모을 수 있다. 어느 모델을 최종 정리 담당으로 쓸지도 문제에 따라 바뀐다. 하지만 단계가 늘면 작업자 호출, 전달하는 컨텍스트, 완료 대기도 늘어난다. 보고서는 Fugu를 지연을 고려한 방식, Ultra를 더 높은 답변 품질을 위한 방식으로 제시한다. 이를 “여러 모델을 부르면 항상 더 좋다”는 규칙으로 읽으면 두 모델을 따로 둔 이유를 놓친다.

같은 도구를 쓰더라도 결과는 원래 작업자에게 돌아가야 한다

아래는 도구 호출의 기억 문제를 설명하기 위해 구성한 가상 예제다. 입력은 “작은 CSV를 읽고 평균을 계산하는 프로그램을 작성하라”다. 작업자 A는 구현을, 작업자 B는 빈 입력과 잘못된 값의 처리를 검토한다. 두 작업자는 같은 도구를 호출할 수 있다.

이 표는 동시 호출 성능을 측정한 결과가 아니다. 작업자를 바꿀 수 있는 도구 실행 흐름에서 누가 호출했고 어느 단계에서 멈췄는지를 보존해야 한다는 점을 드러낸다. 단일 에이전트는 도구 결과를 같은 대화에 붙이면 되지만 여러 작업자는 같은 결과를 받을 대상이 하나라고 가정할 수 없다.

Fugu-Ultra는 호출 주체, 배정된 하위 작업, 협업 구조를 사용자와의 상호작용 동안 추적한다. 같은 도구 이름을 쓴다는 사실만으로 결과를 교환해도 되는 것은 아니다. 선택 정책의 정확도와 별개로, 실행기의 상태 관리가 올바르게 연결되어야 한다.

기억을 모두 공유해도, 모두 숨겨도 문제가 된다

가상 CSV 예제에서 A가 “빈 행은 무시하면 된다”고 가정했다고 하자. B에게 A의 전체 도구 기록과 해석을 처음부터 보여 주면 B도 그 가정을 받아들이고 정작 빈 파일에서 나눗셈이 어떻게 되는지 놓칠 수 있다. 보고서는 첫 작업자의 실행 경로가 이후 작업자를 같은 방향으로 끌고 가는 현상을 **오케스트레이션 붕괴(orchestration collapse)**라고 설명한다.

그래서 Ultra는 현재 협업 흐름 안에서 작업자별 도구 실행 기록을 분리한다. 다른 작업자의 행동과 결과는 조정자가 접근 목록으로 전달한 범위에서만 본다. 작업자를 늘렸는데 사실상 같은 사고를 반복하는 상황을 줄이려는 설계다.

그렇다고 대화 전체의 기억을 매번 지우면 다른 문제가 생긴다. 이전 흐름에서 “CSV의 숫자 열은 두 번째 열”이라는 정보를 이미 확인했는데 새 흐름의 모든 작업자가 열을 다시 조사할 수 있다. Ultra는 현재 흐름 안의 실행은 분리하고 이전 흐름의 도구 기록은 공유한다. 독립 검토를 위한 분리와 중복 작업을 줄이는 기억을 서로 다른 시간 경계에 배치한다.

이 경계가 항상 맞는 것은 아니다. 사용자가 다음 턴에 새 CSV를 올려 열 구조가 바뀌었다면 과거 기억의 “두 번째 열”을 그대로 적용하면 틀린다. 입력 버전이 바뀌었다는 조건에서는 현재 파일을 다시 읽어야 한다. 이는 이 글의 설계 추론이다. 논문의 기억 공유 방식만으로 과거 관찰의 최신성이나 도구 쓰기 충돌이 해결됐다고 볼 수 없다.

독립적인 경로가 의미 있는 것은 오류의 근거가 달라질 때다

보고서의 패키지 서버 사례는 검토자를 더 부르는 이유를 보여 준다. 첫 작업자는 서버를 구현하고 접근 가능하다고 확인했다. 다음 작업자는 패키지 서버 대신 일반 정적 HTTP 서버를 쓴 점 등을 지적했고 앞선 접근 검사가 남아 있던 다른 서버를 확인한 결과였다는 사실도 찾았다. “실행된다”는 결론에 동의한 사람이 늘어난 것이 아니라, 그 결론을 만든 관찰이 다른 실행을 가리킨다는 반증이 추가된 것이다. 보고서는 이 발견을 구현 담당에게 돌려보내 수정했다고 설명한다. 패키지 서버 검토 사례

이런 사례는 기억 분리와 구체적인 검토 지시의 필요성을 잘 설명하지만 성공 사례만으로 각각의 효과를 분리하지는 못한다. 같은 작업자·예산에서 기록을 전부 공유한 구성, 흐름 안에서만 분리한 구성, 이전 흐름까지 분리한 구성을 비교해야 제안한 기억 경계의 효과를 직접 평가할 수 있다. 모델들이 같은 오류를 반복할 가능성도 남는다. 서로의 기록을 숨겨도 학습 데이터와 문제 해석이 비슷하면 독립적인 컨텍스트가 독립적인 오류를 보장하지는 않는다.

이 때문에 Fugu-Ultra를 “여러 전문가의 합의”로 이해하는 것보다 반증할 수 있는 작업을 어떻게 배정하는지로 이해하는 편이 유용하다. CSV 예제에서도 “평균 계산을 검토하라”보다 빈 입력을 실제로 실행하고 기대한 오류 처리를 확인하게 하는 지시가 평가 가능한 역할을 만든다. 이 지시가 더 좋은 점수를 낸다는 실험을 이 글에서 수행한 것은 아니지만 무엇을 확인해야 성공을 인정할지 명확해진다.

벤치마크는 Ultra의 우위와 예외를 함께 보여 준다

다음은 원문 표 1에서 다섯 벤치마크를 골라 열 순서를 바꾼 저자 보고값이다. 모든 값의 단위는 해당 벤치마크 점수(%)이며 높을수록 좋다. 각 벤치마크는 입력과 평가 방식이 다르므로 행 사이의 점수 크기를 직접 비교하지 않는다.

출처: Sakana Fugu 원문. 전체 표의 나머지 벤치마크는 생략했다.

SWE Bench Pro는 Mini-SWE-agent, Terminal Bench는 Terminus 2 하네스를 사용한다. LiveCodeBench v6는 2025년 1~4월의 175문제, GPQA는 EvalScope 1.8.1 기본 구성이다. SciCode는 배경 정보를 제공한 288개 하위 문제의 해결률이며 일부 테스트를 실행하려고 numpy·scipy·sympy 버전을 올렸다고 명시한다. 표의 작업자 모델은 비교 시 최대 추론 수준을 사용한다.

중요한 비교 한계도 있다. 기준 모델 점수는 가능한 경우 제공사가 보고한 값을 가져왔고 일부는 직접 평가하거나 외부 평가에서 가져왔다. SciCode의 기준값은 Artificial Analysis에서 가져온다. 모두를 같은 실행 환경에서 다시 측정한 짝 비교로 받아들이면 안 된다. 표에는 요청당 API 비용과 지연 분포가 없으므로 점수 차이만으로 비용 대비 우위나 지연 동등성을 계산할 수 없다.

SWE Bench Pro에서 Ultra는 가장 높은 기준 모델보다 4.5%포인트 높지만 SciCode에서는 Fugu보다 1.4%포인트 낮다. 이 차이는 위 표에서 계산한 값이다. GPQA는 두 모델이 같다. 더 복잡한 조정이 모든 문제에서 더 나은 선택이라는 주장을 결과 자체가 지지하지 않는다.

실험 예산이 같아도 작은 차이는 작게 읽는다

보고서는 자율 학습 최적화에서도 비교한다. 같은 AutoResearch 기반, 데이터, 실험당 예산과 H100 GPU 한 대를 사용하며 각 시스템이 123개 실험을 수행한다. 시드별 약 14시간, 세 시드의 결과다. 측정값인 BPB(bits per byte)는 검증 데이터의 바이트당 비트 수로, 낮을수록 좋다.

아래는 원문 표 2의 평균과 표준편차다. 익명 기준 모델의 이름은 원문이 공개하지 않으므로 그대로 둔다.

출처: Sakana Fugu 원문. 최선 단일 시드 열은 생략했다.

Ultra와 Model C의 평균 차이는 0.0007 BPB다. Ultra가 가장 낮다는 관찰은 유지하되 이 작은 차이를 보고 모든 시드에서 압도적이라고 말할 수는 없다. 표준편차와 세 시드라는 표본 크기를 함께 봐야 한다. 같은 GPU 실험 예산도 조정자와 작업자들의 API 지출까지 같다는 뜻은 아니다.

지연을 줄여야 하는 서비스라면 먼저 한 작업자로 해결되는 질문의 비율을 확인하는 편이 낫다. 복잡한 구현과 독립 검토가 필요한 요청에서는 단계가 늘어나는 대가를 받아들일 수 있다. 어느 쪽이든 모델 점수만 보고 결정하기 전에 도구 결과가 누구에게 돌아가고 어떤 기억이 다음 단계로 넘어가는지를 설명할 수 있어야 한다. 그 상태 경계가 흐리면 작업자를 바꾸는 장점이 새로운 실행 오류로 바뀐다.

원문과 참고 자료

• Sakana AI(Fugu Team), Sakana Fugu Technical Report, arXiv:2606.21228v1, 2026년 6월 19일. 논문 · HTML · PDF
• Stefan Nielsen 외, Learning to Orchestrate Agents in Natural Language with the Conductor. Conductor 논문