Sakana Fugu Ultra 공개, 73.7점 SWE-Bench Pro와 단일 요금

AI 요약

• 무슨 일: Sakana AI가 2026년 6월 22일 Fugu와 Fugu Ultra를 일반 제공으로 공개했습니다.
  • 두 모델은 여러 공개 프런티어 모델과 전문 에이전트를 내부에서 조율하지만, 사용자는 OpenAI 호환 API의 모델 하나처럼 호출합니다.
• 숫자: 업체 발표 기준 Fugu Ultra는 SWE-Bench Pro 73.7, Terminal-Bench 2.1 82.1, LiveCodeBench Pro 90.8을 기록했습니다.
• 실무 조건: Fugu Ultra는 100만 토큰당 입력 5달러·출력 30달러이지만, 272K 컨텍스트를 넘으면 더 높은 단가가 붙습니다.
  • 어떤 기초 모델을 골랐는지는 공개되지 않고, Fugu Ultra의 에이전트 풀은 고정입니다.

Sakana AI가 새 모델을 공개했습니다. 다만 이번 발표를 “일본 AI 스타트업이 또 하나의 강한 LLM을 냈다”로 읽으면 중요한 부분을 놓칩니다. 공식 발표와 제품 페이지에서 Sakana가 내세운 제품은 단일 기초 모델이 아니라, 여러 공개 프런티어 모델과 전문 에이전트를 내부에서 고르고 조율하는 시스템입니다. 사용자는 Fugu 또는 Fugu Ultra라는 모델 이름을 OpenAI 호환 API에 넣지만, 실제로는 모델 선택, 위임, 검증, 합성이 API 뒤에서 일어납니다.

발표일은 2026년 6월 22일입니다. 시점도 눈에 띕니다. 같은 달 Anthropic은 Fable 5와 Mythos 5 접근을 중단했고, OpenAI는 GPT-5.6 Sol을 제한 프리뷰로 열었습니다. devlery가 최근 다룬 흐름은 모델 성능 자체보다 누가 모델에 접근할 수 있고, 에이전트가 어떤 도구를 쓰며, 기업이 어떤 권한 경계를 둘 수 있는지로 이동했습니다. Sakana Fugu는 이 논의에 “모델을 직접 고르는 코드를 제품 밖으로 뺄 수 있는가”라는 질문을 붙입니다.

.

Sakana의 설명에 따르면 Fugu는 하나의 엔드포인트처럼 보이지만 내부에서는 작업 성격에 따라 직접 답하거나, 여러 전문 모델을 모아 역할을 나누고, 중간 결과를 합칩니다. 회사는 이 접근이 2026년 ICLR 논문인 TRINITY: An Evolved LLM Coordinator와 Learning to Orchestrate Agents in Natural Language with the Conductor에서 이어졌다고 설명합니다. 두 연구의 공통점은 사람이 고정 워크플로를 설계하는 대신, 조율 전략 자체를 학습 대상으로 둔다는 점입니다.

개발자 입장에서 달라지는 표면은 단순합니다. 기존 멀티 모델 앱은 GPT, Claude, Gemini, 오픈 모델, 검색 도구, 코드 실행기를 각각 붙이고 라우팅 규칙을 애플리케이션 코드에 넣었습니다. 실패하면 재시도하고, 서로 다른 답을 검증하고, 비용이 너무 높으면 더 싼 모델로 내려가는 로직도 개발팀이 갖고 있었습니다. Fugu는 이 일부를 “모델”의 책임으로 포장합니다. API 호출자는 프롬프트와 모델 이름을 보내고, 내부 모델 선택과 조율은 Sakana가 맡습니다.

Fugu와 Fugu Ultra의 역할도 다릅니다. Fugu는 일상 코딩, 코드 리뷰, 챗봇처럼 응답성과 품질 균형이 필요한 작업을 겨냥합니다. 제품 페이지는 Fugu에서 특정 에이전트를 풀에서 제외할 수 있다고 적습니다. 데이터, 개인정보, 컴플라이언스 조건 때문에 특정 제공자를 쓰기 어렵다면 콘솔에서 조정하는 식입니다. 반대로 Fugu Ultra는 복잡한 다단계 문제의 답변 품질을 우선합니다. 논문 재현, Kaggle 대회, 사이버보안 분석, 문헌·특허 조사 같은 고부하 작업이 예시로 제시됐습니다.

이 차이는 곧 통제권 차이입니다. Sakana FAQ는 Fugu Ultra가 성능을 내기 위해 전체 에이전트 풀에 의존하므로 풀이 고정돼 있다고 설명합니다. Fugu에서는 일부 모델을 제외할 수 있지만, Ultra에서는 그 선택권이 줄어듭니다. 또한 각 쿼리에서 어떤 기초 모델을 선택했고 어떻게 조율했는지는 독자 기술이라 공개하지 않는다고 적었습니다. 개발팀이 모델 라우팅 코드를 덜 갖게 되는 대신, 라우팅 설명 가능성 일부를 공급자에게 넘기는 구조입니다.

벤치마크 표는 이 제품을 시장 뉴스로 만든 숫자입니다. Sakana가 공개한 표에서 Fugu Ultra는 SWE-Bench Pro 73.7, Terminal-Bench 2.1 82.1, LiveCodeBench 93.2, LiveCodeBench Pro 90.8을 기록했습니다. 같은 표에서 Opus 4.8은 SWE-Bench Pro 69.2, GPT-5.5는 58.6, Gemini 3.1 Pro는 54.2로 적혔습니다. Sakana는 Fable 5와 Mythos Preview가 공개 접근 가능한 모델이 아니므로 Fugu의 에이전트 풀에는 들어가지 않는다고 덧붙였습니다.

이 숫자는 강하지만, 읽는 방식에는 주의가 필요합니다. 공식 페이지는 비교 대상 점수에 대해 모델 제공자가 공개한 값을 사용했다고 밝힙니다. 같은 하네스, 같은 날짜, 같은 예산에서 독립 기관이 재측정한 결과가 아닙니다. SWE-Bench Pro 항목에는 mini-swe-agent를 스캐폴드로 사용했다는 주석도 붙습니다. 따라서 “Fugu Ultra가 모든 코딩 모델을 이겼다”보다, “Sakana가 모델 오케스트레이션을 벤치마크 경쟁 단위로 밀어 올렸다”가 더 정확한 해석입니다.

가격표도 이번 발표의 핵심입니다. Fugu Ultra의 fugu-ultra-20260615는 제품 페이지 기준 100만 토큰당 입력 5달러, 출력 30달러, 캐시 입력 0.50달러입니다. 컨텍스트가 272K를 넘으면 입력 10달러, 출력 45달러, 캐시 입력 1달러로 올라갑니다. 월 구독은 Standard 20달러, Pro 100달러, Max 200달러이며 세 플랜 모두 Fugu와 Fugu Ultra를 포함합니다. Pay-as-you-go 경로는 토큰 사용량 기준으로 과금됩니다.

Sakana가 강조한 문장은 “모델 요금을 쌓지 않는다”는 부분입니다. 여러 에이전트가 작동하더라도 사용한 모델 각각의 비용을 합산하지 않고, 활성 풀에서 최상위 모델의 단일 요금만 청구한다는 설명입니다. 이 설계가 사실상 Fugu의 판매 포인트입니다. 개발자가 직접 멀티 모델 라우터를 만들면 각 공급자 요금, 캐시 정책, 실패 재시도 비용, 장문 컨텍스트 비용을 따로 계산해야 합니다. Fugu는 그 복잡성을 하나의 요금표로 바꿉니다.

Fugu는 일상 코딩, 코드 리뷰, 챗봇처럼 응답성과 비용 균형이 필요한 작업을 맡습니다.

Fugu Ultra는 논문 재현, 보안 분석, 장문 조사처럼 품질과 깊이가 더 중요한 작업을 겨냥합니다.

Fugu에서는 일부 모델을 제외할 수 있지만, Fugu Ultra는 성능을 위해 에이전트 풀이 고정됩니다.

두 모델 모두 선택한 기초 모델과 조율 방식은 공개하지 않습니다.

가격은 Fugu가 활성 풀의 최상위 모델 기준 단일 요금을 따르고, Fugu Ultra는 272K 컨텍스트 초과 시 더 높은 단가를 적용합니다.

여기서 개발팀이 따져야 할 첫 번째 질문은 성능보다 관측성입니다. Fugu가 어떤 기초 모델을 썼는지 알 수 없다면, 회귀 분석과 장애 조사는 공급자가 제공하는 결과 품질과 로그에 의존합니다. 코드 리뷰에서 특정 버그를 놓쳤을 때, 문제 원인이 프롬프트인지, 내부 라우팅인지, 사용된 모델인지 분리하기 어렵습니다. 반대로 직접 라우터를 운영하면 더 많은 로그를 가질 수 있지만, 모델별 오류와 비용을 직접 관리해야 합니다.

두 번째 질문은 데이터 사용입니다. 제품 페이지의 FAQ는 사용 데이터가 Fugu 성능 개선에 도움이 된다고 말하면서도, 콘솔에서 학습 데이터 사용을 언제든 선택 해제할 수 있다고 적습니다. 기업 고객에게 이 문장은 구매 전 확인 항목입니다. 코드 저장소, 보안 점검 결과, 특허 조사 문서, 고객 데이터가 들어가는 작업이라면 기본 설정, 보존 기간, 하위 모델 제공자와의 데이터 경계, 선택 해제 증빙을 계약 단계에서 봐야 합니다.

세 번째 질문은 장문 작업 비용입니다. Fugu Ultra는 긴 연구·코딩 작업을 겨냥하지만, 272K 컨텍스트를 넘는 순간 입력 단가와 출력 단가가 모두 올라갑니다. 장기 실행 에이전트가 로그, 파일, 테스트 결과, 검색 결과를 계속 붙이면 컨텍스트는 빠르게 커집니다. 캐시 입력 단가가 낮더라도, 어떤 부분이 캐시되고 어떤 부분이 새 입력으로 잡히는지에 따라 실제 비용이 달라집니다. 벤치마크 점수와 월 구독료만 보고 도입하면 장문 세션에서 예산이 흔들릴 수 있습니다.

실험 설계도 바뀝니다. 기존 평가에서는 같은 문제를 여러 모델에 보내고 정답률, 실행 시간, 토큰 비용을 나란히 비교했습니다. Fugu Ultra를 넣으면 비교 단위가 “모델 하나”에서 “Sakana가 고른 내부 조합”으로 바뀝니다. 그래서 평가 로그에는 입력 길이, 캐시 여부, 응답 시간, 최종 산출물의 검증 결과를 따로 남겨야 합니다. 내부 라우팅을 볼 수 없으므로, 사용자가 직접 관측할 수 있는 지표를 더 촘촘히 잡아야 합니다.

보안팀이 볼 항목도 있습니다. 코드 리뷰나 침투 테스트 보조에 Fugu Ultra를 쓰면, 프롬프트 안에는 취약점 설명, 재현 절차, 비공개 저장소 경로, 테스트 로그가 들어갈 수 있습니다. Sakana는 보안 평가 사례를 제품 장점으로 소개했지만, 기업 구매자는 그만큼 데이터 처리 경계를 계약서로 확인해야 합니다. 특히 Fugu가 여러 기초 모델을 내부에서 조율한다면, 하위 제공자에게 어떤 데이터가 전달되는지와 어떤 지역에서 처리되는지가 조달 질문으로 올라옵니다.

Sakana의 포지셔닝은 OpenRouter, Vercel AI Gateway, LiteLLM, Requesty 같은 모델 라우팅 계층과도 겹칩니다. 차이는 Fugu가 “여러 모델을 고를 수 있는 게이트웨이”가 아니라 “여러 모델을 조율하도록 학습된 모델”이라고 주장한다는 점입니다. 게이트웨이는 보통 개발자가 라우팅 정책을 정하고, 실패 시 대체 모델을 고르며, 비용 정책을 구성합니다. Fugu는 그 판단의 일부를 자연어 조율 모델과 전문 에이전트 풀로 옮깁니다.

이 접근은 코딩 에이전트 제품에도 영향을 줍니다. Copilot, Codex, Claude Code, Antigravity 같은 도구는 이미 작업 난이도와 모델 가용성에 따라 모델 선택을 제품 내부로 숨기고 있습니다. Fugu는 그 흐름을 앱이 아니라 API 계층에서 제공합니다. 사내 코딩 하네스나 리뷰 봇을 운영하는 팀은 model 값을 바꾸는 것만으로 멀티 모델 조율을 시험할 수 있습니다. 대신 모델별 결과 차이를 명시적으로 비교하던 실험 설계는 더 조심해야 합니다.

커뮤니티 반응은 아직 큰 단일 토론보다 보조 보도와 초기 사용기에 흩어져 있습니다. The Verge와 Tom's Guide는 Fugu를 Fable 5 접근 중단 이후의 공급자 독립성 사례로 읽었습니다. Requesty는 모델 페이지에서 100만 토큰 가격과 1M 컨텍스트 같은 통합 정보를 정리했습니다. Classmethod DevelopersIO는 실제 가입 뒤 사용한 인상을 공유하며, 제품 메커니즘이 일반 모델 호출보다 흥미롭다고 평가했습니다. 반대로 공개 검증이 부족하다는 점과 라우팅 비공개는 계속 남는 제한입니다.

Fugu Ultra가 당장 모든 팀의 기본 모델이 된다는 뜻은 아닙니다. 지연 시간이 중요한 챗봇, 규제상 하위 모델을 명시해야 하는 금융·의료 시스템, 모델별 재현성이 필요한 평가 파이프라인에는 내부 라우팅 비공개가 부담일 수 있습니다. 그러나 장문 코드 리뷰, 논문 재현, 보안 보고서 초안, 특허 조사처럼 사람이 여러 모델을 번갈아 물어보고 결과를 합치던 작업에서는 제품 가설이 분명합니다. 조율을 사람이 하는 대신, 조율 모델에게 비용과 품질을 맡겨보라는 제안입니다.

제품팀에는 또 다른 판단 기준이 생깁니다. 사용자에게 “이 답은 어떤 모델이 만들었는가”를 보여줘야 하는 제품이라면 Fugu의 비공개 라우팅은 맞지 않을 수 있습니다. 반대로 사용자가 원하는 것이 모델명보다 완성된 보고서, 검토 결과, 재현 가능한 패치라면 내부 조율은 숨겨져도 됩니다. 실제 도입 여부는 모델 철학보다 제품 약속에 달려 있습니다. 설명 가능한 모델 선택을 팔 것인지, 더 나은 최종 산출물을 팔 것인지가 기준입니다.

개발자 경험 측면에서는 OpenAI 호환 API가 진입 장벽을 낮춥니다. 기존 클라이언트의 base_url과 model 값만 바꾸는 식으로 시험할 수 있기 때문입니다. 하지만 이 쉬운 전환이 곧 쉬운 운영을 뜻하지는 않습니다. 장애 대응 문서, 비용 알림, 민감 데이터 필터, 결과 검증 테스트는 여전히 애플리케이션 쪽에 남습니다. Fugu는 모델 선택 코드를 줄여줄 수 있지만, 결과 책임과 제품 품질 책임까지 대신 가져가지는 않습니다.

이번 발표의 실무 결론은 “가장 높은 점수를 낸 모델을 쓰자”가 아닙니다. 개발팀은 세 가지를 먼저 실험해야 합니다. 같은 프롬프트를 기존 단일 모델, 자체 라우터, Fugu Ultra에 넣었을 때 결함 발견률과 재현성을 비교해야 합니다. 272K를 넘는 장문 세션에서 실제 청구 비용을 기록해야 합니다. 마지막으로 보안·개인정보 정책상 하위 모델 비공개와 학습 데이터 선택 해제가 허용되는지 확인해야 합니다. 이 세 조건을 통과할 때 Fugu는 단순 모델 교체가 아니라, 모델 선택 코드 일부를 외부 서비스로 이전하는 선택지가 됩니다.

Sakana는 앞으로 공개 프런티어 모델이 나오면 약 2주 동안 업데이트된 Fugu 모델을 훈련하고 평가한 뒤 배포하겠다고 적었습니다. 이 약속이 지켜지면 Fugu의 경쟁력은 특정 시점의 SWE-Bench Pro 73.7보다 업데이트 주기와 평가 신뢰도에서 갈릴 가능성이 큽니다. 새 모델이 나올 때마다 애플리케이션 코드를 고치지 않아도 된다는 장점은 분명합니다. 하지만 어떤 모델이 어떤 순간에 쓰였는지 모르는 구조를 받아들일 수 있는지는 팀마다 다릅니다. Fugu Ultra는 모델 성능 경쟁의 끝이 아니라, 모델 선택권을 어디에 둘 것인지 묻는 새로운 API 제품입니다.