사카나 AI 후구(Fugu)란? 가격·API·멀티에이전트 구조

사카나 AI 후구(Fugu)는 여러 프런티어 모델을 뒤에서 골라 쓰면서 외부에는 하나의 모델 API처럼 보이는 오케스트레이터다. Fugu는 일본어로 복어를 뜻한다. 사용자는 한 엔드포인트에 요청을 보낸다. 후구는 작업을 직접 풀지 여러 에이전트에게 나눌지 결정한다.

2026년 6월 22일 일반 제공이 시작된 뒤 제품은 빠르게 바뀌었다. 7월 24일 Fugu Ultra v1.1이 나왔다. 8월 13일에는 API 없이 써보는 Sakana Chat에도 후구가 들어갔다. 출시 당시의 ‘멀티에이전트 모델’ 설명만으로는 지금의 모델 ID와 가격, 실제 청구액을 알기 어렵다.

내 판단은 이렇다. 후구는 단순 분류나 짧은 요약의 단가를 낮추는 도구가 아니다. 여러 모델의 판단과 검증이 필요한 긴 작업에서 재작업을 줄일 때 의미가 생긴다. 단일 기초 모델 의존은 낮출 수 있어도 사카나 AI의 오케스트레이션 계층에 대한 의존까지 사라지는 것은 아니다.

가격과 사양은 2026년 8월 24일 사카나 AI 공식 문서에서 확인했다. 필자는 유료 API 키로 동일 작업을 반복 실행하거나 Fugu Ultra의 청구서를 대조하지 않았다. 공급사가 공개한 벤치마크 숫자는 독립 검증 결과가 아니므로 모델 선택 근거에서 제외했다.

사카나 후구는 지휘자 모델과 교체 가능한 모델 풀로 구성된다

사카나 AI의 후구 출시 발표는 후구를 ‘하나의 모델처럼 작동하는 멀티에이전트 시스템’으로 설명한다. 내부 구조는 두 층으로 나뉜다.

• 지휘자 모델: 요청을 해석하고 위임, 검증, 결과 통합 순서를 정한다.
• 모델 풀: 실제 코딩, 추론, 조사 같은 작업을 맡는 여러 기초 모델이다.

사람이 모든 라우팅 규칙을 미리 적는 방식과는 다르다. 지휘자 모델이 어느 에이전트에게 맡길지, 결과를 어떻게 모을지 학습했다. 필요하면 자기 자신도 다시 호출한다. 이 설계는 사카나 AI가 ICLR 2026에 발표한 Trinity와 Conductor 연구를 바탕으로 한다.

Gemma 4 기반 지휘자 모델 검증은 모델 풀뿐 아니라 지휘자 모델의 기반도 바꾸려는 시도다. 사카나 AI는 자체 평가 세트에서 기존 지휘자와 비슷한 성능과 비용 절감 효과를 확인했다고 밝혔다. 다만 이것 역시 회사 내부 실험이다. ‘어떤 기반 모델로도 같은 결과가 난다’는 일반 결론으로 넓히지는 않았다.

현재 선택지는 Fugu·Fugu Ultra·Fugu Cyber다

현재 모델 문서는 제품 역할과 API ID를 다음처럼 구분한다.

선택지	API ID	먼저 검토할 업무	확인할 제한
Fugu	fugu	일상적인 코딩, 코드 리뷰, 대화형 업무	사용한 기초 모델에 따라 종량 단가가 달라지고 모델 풀을 조정할 수 있음
Fugu Ultra	fugu-ultra	복잡하고 실패 비용이 큰 다단계 작업	현재 v1.1로 연결되며 고정된 풀에서 1~3개 에이전트를 조율
Fugu Ultra v1.1	fugu-ultra-v1.1	버전을 고정한 평가와 운영	고정 토큰 단가, 오케스트레이션 토큰 추가 과금
Fugu Cyber	fugu-cyber	보안 분석과 취약점 연구	종량제 전용, 별도 신청과 수동 승인 필요

fugu-ultra 별칭은 현재 fugu-ultra-v1.1을 가리킨다. 7월 24일 발표된 v1.1은 최신 기초 모델을 풀에 반영했고 v1.0과 같은 가격을 유지했다. 재현성이 중요한 테스트라면 별칭 대신 버전 ID와 실행일을 함께 남기는 편이 낫다.

사카나 AI가 별도로 제공하는 Namazu는 일본어 특화 단일 모델이다. 여러 모델을 조율하는 후구와 구조도 과금 방식도 다르다. Sakana Chat 화면에서 두 모델을 함께 선택한다고 해서 같은 제품군으로 묶으면 안 된다.

후구 가격은 구독과 종량제를 나눠 읽어야 한다

공식 가격표의 월 구독은 Fugu와 Fugu Ultra를 모두 포함한다.

플랜	월 가격	공개된 사용량 설명
Standard	$20	기준 사용량
Pro	$100	Standard의 10배
Max	$200	Standard의 20배

여기서 주의할 점은 가격표가 기준 사용량을 토큰 수나 요청 수로 공개하지 않았다는 사실이다. ‘10배’만 보고 업무 한 건당 비용을 계산할 수는 없다. 긴 작업을 자주 실행하는 팀은 콘솔에서 현재 잔량과 제한 조건을 직접 확인해야 한다.

종량제 Fugu도 하나의 고정 단가가 아니다. 한 에이전트가 처리하면 선택된 기초 모델의 표준 단가를 적용한다. 여러 에이전트가 참여해도 모델 요금을 겹쳐 받지는 않는다. 참여한 모델 가운데 가장 높은 계층의 단가 하나를 적용한다는 것이 사카나 AI의 설명이다. 요청 전에 정확한 원가를 고정해야 하는 서비스라면 이 변동 구조부터 평가해야 한다.

Fugu Ultra v1.0과 v1.1은 100만 토큰당 고정 가격을 쓴다.

토큰 유형	표준 문맥	272K 초과 문맥
입력	$5.00	$10.00
캐시 입력	$0.50	$1.00
출력	$30.00	$45.00

100K 입력과 20K 출력을 표준 문맥에서 썼다면 화면에 보이는 토큰만 계산한 금액은 $1.10이다. 이것을 최종 청구액으로 보면 안 된다. 후구가 내부에서 사용한 오케스트레이션 토큰이 더해진다.

오케스트레이션 토큰까지 더해야 실제 비용이 나온다

Fugu Ultra 응답의 usage에는 일반 입력·출력 외에 아래 값이 따로 들어간다.

• orchestration_input_tokens
• orchestration_input_cached_tokens
• orchestration_output_tokens

이 값은 참고용 내부 지표가 아니다. 가격 문서는 오케스트레이션 토큰도 일반 입력·캐시·출력과 같은 단가로 청구한다고 명시한다. 최종 비용을 계산할 때는 사용자에게 보인 답변의 토큰뿐 아니라 지휘와 에이전트 협업에 들어간 토큰을 모두 합쳐야 한다.

이 지점이 일반 모델 API와 가장 크게 다른 운영 포인트다. 여러 에이전트가 품질을 높였더라도 오케스트레이션 출력이 길어지면 비용이 예상보다 커진다. 우리 팀이라면 결과 한 건의 최초 승인률, 사람의 수정 시간, 전체 usage 비용을 같은 행에 기록한다. 단일 요청의 출력 품질만 비교해서는 멀티에이전트의 경제성을 판단하기 어렵다.

장문맥 가격 경계도 함께 본다. 가격표는 문맥이 272K를 넘는 요청에 더 높은 입력·캐시·출력 단가를 적용한다. 긴 저장소나 여러 문서를 한 번에 넘기는 테스트는 272K 이하와 초과 구간을 나눠 기록해야 한다.

API는 익숙하지만 완전히 같은 동작은 아니다

후구 시작 문서에 나온 기본 엔드포인트는 https://api.sakana.ai/v1이다. OpenAI SDK의 base_url과 모델 ID를 바꿔 Responses API를 호출한다.

import os
from openai import OpenAI

client = OpenAI(
    base_url='https://api.sakana.ai/v1',
    api_key=os.environ['SAKANA_API_KEY'],
)

response = client.responses.create(
    model='fugu-ultra-v1.1',
    input='이 저장소의 테스트 실패 원인을 찾아 수정 계획을 제안해줘.',
    reasoning={'effort': 'high'},
    timeout=120.0,
)

print(response.output_text)

Responses, Chat Completions, Models API와 Anthropic 호환 Messages API를 지원한다. Fugu Ultra v1.1은 high, xhigh, max 추론 강도를 받는다. 일반 Fugu와 Ultra v1.0은 high, xhigh를 지원하며 max를 보내면 xhigh로 처리한다.

형식이 호환된다고 기존 서비스가 그대로 작동한다는 뜻은 아니다. 모델 문서에는 temperature, top_p, seed, 빈도·존재 페널티 같은 일부 필드가 요청에는 받아들여지지만 실제로는 무시된다고 적혀 있다. Responses API의 previous_response_id도 지원하지 않아 이어지는 대화는 이전 이력을 입력에 다시 보내야 한다. 긴 작업은 응답이 늦을 수 있어 클라이언트 타임아웃도 따로 늘려야 한다.

Codex나 Claude Code에 연결할 수도 있다. 도구만 바꿔 비교하면 결과 해석이 어려우므로 동일 저장소에서 AI 코딩 도구를 비교한 절차처럼 저장소, 권한, 지시문과 합격 기준을 고정하는 편이 낫다.

API 키를 만들 때 일반 Fugu의 custom model pool을 켜고 특정 제공자를 제외한다. Fugu Ultra는 성능을 위해 전체 에이전트 풀을 사용하므로 이 설정으로 풀을 줄이지 못한다. 민감한 데이터를 다루는 팀에는 둘의 차이가 중요하다.

어느 기초 모델이 실제 요청을 처리했는지는 공개되지 않는다. 제품 FAQ는 사용 데이터의 학습 이용을 끄는 콘솔 설정을 제공한다고 안내한다. 데이터 처리 지역, 보존 기간, 하위 제공자 계약까지 이 설정으로 해결되지는 않는다. 운영 투입 전에는 계정의 데이터 이용 설정과 계약 조건을 별도로 확인해야 한다.

지역 제한도 있다. 후구 제품 페이지는 GDPR과 EU 규정 대응을 진행하는 동안 EU·EEA에서는 서비스를 제공하지 않는다고 명시한다. 한국에서 쓸 수 있다는 사실만 보고 유럽 지사와 고객에게 같은 구성을 배포하면 안 된다.

단일 모델 의존은 줄지만 새 게이트웨이 의존이 생긴다

후구의 가장 설득력 있는 가치는 기초 모델 교체 가능성이다. 한 제공자를 풀에서 빼거나 새 모델을 넣어도 외부 API를 유지하는 설계는 장애와 규제 변화에 대응하기 쉽다. 실제로 8월 10일 Gemma 4 기반 지휘자 실험까지 공개하면서 지휘 계층 자체의 교체 가능성도 시험하고 있다.

하지만 후구 API와 라우팅 정책이 멈추면 모델 풀이 살아 있어도 서비스는 영향을 받는다. 공급사 하나에 대한 의존이 사라졌다기보다 의존 지점이 기초 모델에서 오케스트레이션 게이트웨이로 이동한다. LLM API 장애 대응과 폴백 설계처럼 후구 밖의 직접 호출 경로까지 준비해야 진짜 대체 수단이 생긴다.

내가 도입을 검토한다면 먼저 Sakana Chat에서 파일 분석과 다단계 지시를 직접 확인한다. API 평가는 최근의 긴 업무 20~30건으로 좁히고 아래 값을 남긴다.

1. Fugu와 현재 단일 모델의 최초 승인률
2. 전체 입력·캐시·출력·오케스트레이션 토큰
3. 응답 완료 시간과 타임아웃·재시도 횟수
4. 사람이 고친 시간과 승인된 결과 한 건당 비용
5. 특정 제공자를 제외했을 때 품질과 장애 복구 결과

단순한 작업은 모델 하나로 처리하는 편이 싸고 빠를 가능성이 높다. 후구가 값을 만드는 구간은 작업을 나누고 검증하는 비용보다 사람의 재작업을 더 크게 줄이는 경우다. ‘여러 모델을 쓴다’는 설명보다 전체 사용량 로그와 장애 훈련 결과를 보고 결정해야 한다.

2026년 8월 24일 수정: 출시 요약과 공급사 벤치마크 중심 문장을 걷어냈다. Fugu Ultra v1.1, Sakana Chat 이용 경로, 현재 구독·종량 가격, 오케스트레이션 토큰 과금과 API 호환 시 주의점을 공식 문서 기준으로 전면 수정했다.