Sakana는 공식 비교표에서 Fugu와 Fugu Ultra가 일부 코딩·추론·과학·agentic benchmark에서 공개 접근 가능한 프론티어 모델을 앞서거나 경쟁력 있는 결과를 냈다고 보고합니다. 모든 프론티어 모델이나 모든 benchmark를 이겼다는 뜻은 아니며, 독립적으로 검증된 우월성을 뜻하지도 않습니다. 그럼에도 이 표가 눈길을 끈 이유는 결과를 만든 주체가 단일 모델이 아니기 때문입니다. 하나의 모델 API 뒤에서 여러 모델과 전문 Agent가 역할을 나누고, task에 맞춰 참여할 모델을 고르고 전환하며 결과를 만듭니다.
Sakana Fugu가 내세운 개념은 “Multi-Agent System as a Model”입니다. 여러 모델을 연결하는 Gateway를 넘어, 모델들의 협업 자체를 하나의 모델처럼 제공하겠다는 접근입니다.
이 구조는 모델의 경계를 넓히는 동시에 비용에 관한 질문을 남깁니다. 여러 모델을 동적으로 선택하고 전환할 때, 무엇을 기준으로 효율적이라고 판단해야 할까요. 요청 하나의 가격만 비교하면 충분할까요. 긴 Agent 작업이라면 cache miss와 문맥 재처리까지 포함해 작업을 끝내는 데 든 비용을 봐야 하지 않을까요.
이 글의 중심 질문은 Router가 어떤 모델을 골랐는지가 아니라, 그 선택과 협업을 어떤 비용 단위로 평가할 것인가입니다.
Multi-Agent System as a Model
Fugu 공식 페이지는 제품을 “A Multi-Agent System, Delivered as One Model”이라고 설명합니다. 다양한 모델 풀을 동적으로 조정하고 orchestration하며, task마다 모델 선택과 전환을 처리한다고 밝힙니다. 외부에서는 이 시스템을 하나의 API로 사용할 수 있습니다.
Sakana의 Fugu 공식 페이지에 공개된 제품 아키텍처 소개 이미지입니다. 내부 모델·Agent 구성과 성능을 독립적으로 검증한 자료는 아닙니다.
Sakana 자체 공개 비교표입니다. Fugu 측은 일부 baseline에 provider-reported score를 사용했고, SWE Bench Pro는 mini-swe-agent scaffold를 사용한다고 주석을 답니다. 따라서 독립 재현이나 모든 작업의 일반적 우월성을 증명하는 자료는 아닙니다.
이 성능 비교표를 글의 출발점으로 삼는 이유는 수치만으로 Fugu를 평가하기 위해서가 아닙니다. 표에 나타난 결과가 단일 모델 성능만의 결과가 아니라 모델 선택, Agent coordination, scaffold를 포함한 시스템 결과이기 때문입니다. 그렇다면 비교해야 할 대상도 모델 한 번의 호출 가격에 머물 수 없습니다. 결과를 만드는 동안 든 총 작업 비용과 cache miss, 모델 전환 비용까지 함께 물어야 합니다.
공식 페이지에 따르면 Fugu는 복수의 전문 모델을 하나의 API로 제공하고, task에 맞춰 모델을 선택하거나 전환합니다. 사용자는 특정 provider나 모델을 Agent pool에서 제외해 데이터, 개인정보, 규제 또는 조직의 요구에 대응할 수도 있습니다. Fugu, Fugu Ultra, Fugu Cyber는 하나의 OpenAI-compatible API를 통해 제공된다고 설명합니다.
중요한 변화는 호출 방식보다 제품의 경계에 있습니다. 일반적인 모델 API에서는 endpoint 뒤에 하나의 모델이 있다고 생각하기 쉽습니다. Fugu에서는 endpoint 뒤의 실행 주체가 하나의 모델이 아니라 여러 모델과 Agent의 협업입니다. 호출자에게는 그 전체가 하나의 모델 surface로 보입니다.
따라서 Router의 역할도 달라 보입니다. 입력을 분류해 모델 하나를 고르는 데서 끝나지 않고, task를 수행할 Agent를 구성하고 여러 차례의 협업을 조정하는 orchestration의 일부가 됩니다. “어떤 모델을 호출할까”보다 “어떤 조합과 실행 경로로 결과를 만들까”에 가까운 질문입니다.
다만 여기서 Fugu의 개별 실험 결과를 multi-agent 구조의 일반적인 우월성으로 확대해서는 안 됩니다. 공식 페이지가 공개한 결과는 Sakana의 자체 평가입니다. 이 글은 Fugu의 범용 성능을 평가하려는 글이 아니라, 여러 모델의 협업을 하나의 모델처럼 제공하는 제품 경계를 살펴보는 architecture reading입니다.
동적 orchestration은 어떤 비용을 남기나
여러 모델을 task에 따라 선택하고 전환할 수 있다면, 각 단계에 가장 적합한 모델을 배치할 수 있습니다. 반면 실행 경로가 길어질수록 비용을 계산하는 단위는 복잡해집니다.
Agent 작업은 보통 요청 한 번으로 끝나지 않습니다. 대화와 코드가 쌓이고, 도구 호출 결과를 다음 입력에 포함하며, 중간 결과를 검토하거나 수정합니다. 뒤로 갈수록 앞선 작업의 긴 맥락을 다시 전달해야 할 수 있습니다.
설명을 위한 코드 Agent 작업을 가정해 보겠습니다.
Turn 1: “이 코드베이스의 인증 흐름을 파악해줘”
Turn 2: “토큰 갱신 오류의 원인을 찾아줘”
Turn 3: “수정안을 적용해줘”
Turn 4: “테스트가 실패했어. 원인을 다시 봐줘”
Turn 5: “그럼 마지막으로 함수 이름만 정리해줘”Turn 5만 보면 단순한 요청이라 저비용 모델로 전환하기 쉬워 보입니다. 하지만 Turn 1~4의 관련 파일, 이전 분석, 수정 코드, 테스트 로그, 도구 결과가 누적돼 있다면 모델 전환은 단순한 단가 절감이 아닙니다. 이미 쌓인 작업 상태를 다시 구성할지 결정하는 일이 됩니다.
새 요청의 단가는 낮아졌지만 기존 context 또는 prefix cache를 활용하지 못할 가능성이 있다면, 긴 입력을 다시 처리하는 비용과 지연이 추가될 수 있습니다. 요청 하나만 보면 절약이지만 작업 전체로 보면 비용이 늘 수도 있습니다. 다만 실제 비용과 영향은 제품, 작업, 전환 방식에 따라 별도로 측정해야 합니다.
여기서 세션을 고려한 라우팅은 지금 들어온 문장 하나만 보고 모델을 고르지 않고, 이 요청이 앞선 작업의 후속인지, 전환하면 어떤 맥락과 cache를 다시 처리해야 하는지를 함께 보는 설계 관점입니다. 특정 제품의 공개 기술 명칭이나 구현 사실을 뜻하지는 않습니다.
이것은 동적 orchestration에서 검토해야 할 일반적인 비용 질문이지, Fugu의 실제 동작이나 문제를 설명하는 문장이 아닙니다. Fugu가 모델 사이에서 KV cache를 공유하는지, session affinity를 적용하는지, 전환 비용을 어떤 수식으로 계산하는지, 구체적으로 어떻게 라우팅하는지는 공식 페이지에서 확인되지 않습니다.
Cache miss의 범위도 구분해야 합니다. Cache miss는 이미 처리한 입력을 다시 계산하면서 생기는 비용과 지연의 문제입니다. 작업 연속성이나 재작업은 상태 보존, 프롬프트 재구성, 도구 이력 전달, 모델 행동과 task 특성까지 포함합니다. Cache miss가 곧 문맥 단절이나 재작업을 뜻하지는 않습니다. 각각을 따로 관측하고 평가해야 합니다.
그렇다면 동적 orchestration의 경제성을 요청당 모델 가격만으로 평가하기 어렵습니다. 어떤 모델을 몇 번 썼는지뿐 아니라, 전환 과정에서 입력을 얼마나 다시 처리했는지, 재시도와 수정이 얼마나 발생했는지, 최종적으로 원하는 결과를 얻었는지를 함께 봐야 합니다.
작업 완료 비용 = 기본 모델 호출 비용 + 전환으로 인한 문맥 재구성·재처리 비용 + 재시도·수정·검증 비용 + 실패와 지연의 비용
문맥 재구성·재처리 비용에는 cache miss로 기존 prefix를 다시 처리하는 비용이 포함될 수 있습니다. 하지만 cache miss가 곧 문맥 단절이나 재작업을 뜻하지는 않습니다. 이 식은 Fugu가 공개한 알고리즘이 아닙니다. Multi-Agent System as a Model이라는 제품 경계를 운영 관점에서 읽을 때 사용할 수 있는 설계 프레임입니다.
Cursor는 이 비용을 평가에 어떻게 반영했나
Fugu는 모델들의 동적 협업을 하나의 모델 surface로 제공하는 사례입니다. Cursor Router는 별개의 제품과 문제 맥락에서, 동적 라우팅으로 발생하는 cache 비용을 학습과 평가에 반영했다고 공개한 사례입니다. Cursor의 설명은 Fugu의 구현을 뒷받침하는 증거가 아닙니다. 두 사례를 연결하는 지점은 구현의 동일성이 아니라, 모델 선택과 전환을 요청 단가보다 넓은 비용으로 평가해야 한다는 질문입니다.
Cursor는 모델 실행 전에 요청을 분류한다고 설명합니다. 쿼리와 맥락, 작업 복잡도, 도메인, 모델의 동작 특성을 결합해 후보를 분류합니다. 특히 cache miss로 이어지는 라우팅 사례를 학습 데이터에 포함하고, 프로덕션 평가에서도 라우팅 결정에서 발생한 cache miss 비용을 반영한다고 밝힙니다.
평가도 요청 한 번에만 머물지 않습니다. Cursor는 실제 대화 환경에서 온라인 A/B 테스트를 진행하고, 사용자 만족도와 생성 코드의 유지율, 커밋당 비용을 함께 본다고 설명합니다. 모델 선택의 결과를 대화와 작업 결과에 가까운 지표로 평가하려는 접근으로 읽을 수 있습니다.
출처: Cursor Router 공식 블로그. Cursor가 자체 공개한 온라인 평가 결과이며, 독립적으로 재현된 결과나 Fugu의 성능·구현을 입증하는 자료가 아닙니다.
Cursor가 공개한 범위에도 경계가 있습니다. 모델이나 provider 사이에서 KV cache를 공유한다는 설명은 없습니다. Session affinity 규칙, 전환 penalty 수식, 구체적인 라우팅 알고리즘 역시 공식 글만으로 확인되지 않습니다. 확인할 수 있는 것은 cache miss로 이어지는 사례를 학습 데이터에 넣고, 운영 평가에 그 비용을 포함했다는 점입니다.
Cursor는 대화 중 모델 전환을 어떻게 다루나
Cursor의 Agent Harness 글은 Router 글과 다른 층에서 모델 전환을 설명합니다. Router 글이 어떤 선택이 cache miss 비용을 만드는지 학습과 평가에 반영하는 방식이라면, Harness 글은 사용자가 대화 중 모델을 바꿨을 때 생기는 context와 도구 계약의 문제를 다룹니다.
Cursor는 cache가 provider와 model마다 다르므로 전환이 일어나면 cache miss가 발생하고, 전환 뒤 첫 턴은 더 느리고 비용도 더 많이 들 수 있다고 설명합니다. 이를 완화하기 위해 전환 시점에 대화를 요약해 새 모델에 전달하는 방식을 실험했습니다. 다만 복잡한 작업을 깊이 진행한 상태에서는 요약 과정에서 중요한 정보가 빠질 수 있습니다. 특별히 전환할 이유가 없다면 대화가 끝날 때까지 같은 모델을 계속 쓰는 편을 권장한다는 설명입니다.
전환 문제는 cache만으로 끝나지 않습니다. Cursor는 새 모델에 맞춘 prompt와 도구 집합을 적용하고, 다른 모델로부터 작업을 넘겨받았음을 알리는 맞춤 지침을 제공합니다. 이전 대화에는 있지만 새 모델의 도구 집합에는 없는 도구를 호출하지 않도록 유도하기 위해서입니다. 직접 전환이 불리한 경우에는 새 context window에서 시작하는 sub-agent를 대안으로 제시합니다.
이것은 모델 간 KV cache를 공유한다는 설명이 아닙니다. 전환에 따른 cache penalty와 작업 상태 인계의 문제를 인정하고, 대화 요약·모델별 Harness·새 context의 sub-agent로 완화하려는 공개된 접근입니다.
아래 구분은 공개된 cache 관련 설명을 바탕으로, 일반적인 시스템 설계 관점에서 정리한 것입니다. 각 제품의 실제 cache 범위와 구현은 공개 정보만으로 확인되지 않습니다.
| 구분 | Semantic cache | Context / prefix cache |
|---|---|---|
| 줄이려는 비용 | 유사 요청의 생성 호출 | 누적된 입력 맥락의 재처리 |
| 주로 보는 단위 | 요청 간 의미 유사성 | 같은 대화·작업의 prefix 연속성 |
| 멀티턴에서의 쟁점 | 이전 답을 재사용해도 되는가 | 모델 전환 시 기존 맥락을 다시 읽어야 하는가 |
| 대표 위험 | 유사하지만 다른 요청에 잘못된 답 재사용 | 전환 후 비용·지연 증가, 맥락 이해 저하 가능성 |
두 cache는 모두 비용을 줄이지만, semantic cache는 “이 요청을 다시 생성해야 하는가”를 묻고, context/prefix cache는 “이 작업의 누적 맥락을 다시 처리해야 하는가”를 묻습니다.
Router와 orchestration을 볼 때 물어야 할 것
Multi-Agent System as a Model은 외부 인터페이스를 단순하게 만듭니다. 그러나 단일 API가 내부 실행까지 단순하다는 뜻은 아닙니다. 여러 모델과 Agent가 협업하는 제품을 평가할 때는 다음 질문을 함께 볼 필요가 있습니다.
-
모델 선택의 단위는 무엇인가?
요청마다 하나의 모델을 고르는지, task를 여러 단계로 나눠 Agent와 모델을 구성하는지 확인해야 합니다. -
모델 전환 비용을 관측할 수 있는가?
전환 전후의 입력 처리량, cache miss, 지연과 호출 비용을 추적할 수 있어야 합니다. -
이 요청은 기존 작업의 후속인가, 독립된 새 작업인가?
이 경계가 불분명하면 Router는 요청 단가만 보고 전환해, 이미 쌓인 맥락의 가치와 전환 비용을 놓칠 수 있습니다.
-
세션 상태는 누가 전달하는가?
Router 또는 orchestrator가 모든 상태를 가져야 한다는 뜻은 아닙니다. 대화, 도구 이력, 중간 결과를 구성하는 runtime과 모델 선택 계층 사이의 계약이 분명해야 합니다.
-
작업 결과를 어떤 지표로 평가하는가?
요청당 가격 외에 완료율, 유지된 결과, 통과한 검증, 재시도 횟수처럼 실제 task에 가까운 지표가 필요합니다.
-
데이터 정책을 모델 풀 전체에 적용할 수 있는가?
어떤 provider와 모델이 참여할 수 있는지 통제하고, 개인정보·규제·조직 정책을 실행 경로 전체에서 지킬 수 있어야 합니다.
-
공개되지 않은 구현을 추정하고 있지는 않은가?
“동적으로 선택한다”는 설명만으로 cache 공유, session affinity 또는 특정 최적화 알고리즘을 가정해서는 안 됩니다.
하나의 모델처럼 보이는 시스템을 어떻게 평가할까
Fugu가 흥미로운 이유는 더 많은 모델을 한 API에 연결했기 때문만은 아닙니다. 복수 모델과 전문 Agent의 협업을 외부에는 하나의 모델처럼 제공하면서, 모델 제품의 경계를 orchestration 시스템으로 넓혔기 때문입니다.
이 경계가 넓어지면 평가 기준도 함께 넓어져야 합니다. 내부에서 동적 선택과 전환이 일어난다면 가장 싼 요청을 골랐는지만 볼 수 없습니다. Cache miss와 문맥 재처리, 재시도와 최종 결과까지 포함해 작업을 끝내는 데 얼마가 들었는지 물어야 합니다.
Cursor는 별도의 공개 사례에서 cache miss 비용을 라우팅의 학습과 운영 평가에 포함하고, 대화 환경과 커밋당 비용 같은 결과 지표를 본다고 설명했습니다. Harness 글에서는 대화 중 모델 전환이 cache miss와 작업 상태 인계 문제를 함께 만든다고 보고, 요약·모델별 도구 계약·새 context의 sub-agent 같은 완화 방식을 설명합니다. 이것이 Fugu의 구현을 말해주지는 않지만, 동적 라우팅과 전환을 어떤 비용 단위와 운영 계약으로 평가할지에 관한 하나의 구체적인 접근을 보여줍니다.
Router가 단순 Gateway를 넘어 모델들의 협업을 하나의 모델처럼 제공할 수 있을까요. Fugu는 그 가능성을 제품 형태로 제시했습니다. 이제 더 중요한 질문은 내부에 몇 개의 모델이 있는지가 아니라, 그 협업이 실제 작업을 어떤 품질과 총비용으로 끝내는지일 것 같습니다.
참고 자료
- Sakana Fugu — Multi-Agent System as a Model
- Cursor Router
- Cursor — Continually improving the agent harness
이 글은 두 서비스를 직접 설치하거나 성능을 재현한 실험기가 아닙니다. 각 공식 페이지가 공개한 제품 설명과 평가 방식을 비교해 읽은 architecture reading입니다. Fugu의 내부 cache, session affinity, 라우팅 알고리즘과 범용 성능 우월성을 추정하지 않으며, Cursor의 공개 결과를 Fugu 구현의 증거로 사용하지 않습니다.