Sakana Fugu 해설: 모델 오케스트레이션은 성능표보다 라우팅 비용·검증 로그·fallback 경계를 먼저 설계해야 하는 이유

한 줄 문제 정의: Fugu의 핵심은 “더 강한 단일 모델”이 아니라, 여러 모델을 한 API 뒤에서 선택·위임·검증·통합하는 운영 방식입니다. 개발팀이 봐야 할 문제는 벤치마크 1등 여부보다 라우팅 실패, 비용 폭증, 관측성 부족을 어떻게 통제할지입니다. 이 글은 Fugu를 바로 도입하라는 소개가 아니라, 모델 오케스트레이션을 제품에 넣기 전에 어떤 경계를 설계해야 하는지 정리한 실무 가이드입니다.

1. 문제 정의: 모델을 하나 더 붙이는 문제가 아니다

핵심 요약: 모델 오케스트레이션은 성능 문제가 아니라 운영 구조 문제입니다.

AI타임스는 2026년 6월 23일 사카나 AI가 모델 오케스트레이션 플랫폼 Fugu를 공개했다고 보도했습니다. 공식 발표 기준으로 Fugu는 하나의 OpenAI 호환 API처럼 보이지만, 내부에서는 여러 LLM을 선택하고 작업을 나누고 결과를 합칩니다.

이 구조는 모델 선택을 애플리케이션 코드에서 떼어낼 수 있다는 장점이 있습니다. 대신 “왜 이 모델이 호출됐는가”, “실패하면 어떤 모델로 넘어갔는가”, “내부 오케스트레이션 토큰이 얼마나 썼는가” 같은 운영 질문이 새로 생깁니다.

적용 범위는 코딩 리뷰, 리서치, 보안 분석, 긴 문서 검토처럼 한 번의 모델 호출로 끝나지 않는 업무입니다. 반대로 짧은 FAQ, 정해진 분류, 단순 요약처럼 지연 시간과 비용이 더 중요한 작업에는 과할 수 있습니다.

2. 먼저 결론: Fugu는 ‘기본 모델’보다 ‘고난도 작업용 라우터’로 봐야 한다

핵심 요약: 모든 요청을 Fugu Ultra로 보내면 성능보다 비용과 디버깅 문제가 먼저 터질 가능성이 큽니다.

Fugu를 검토한다면 첫 도입 대상은 전체 트래픽이 아니라 실패 비용이 큰 일부 작업이어야 합니다. 예를 들면 PR 리뷰의 보안 취약점 탐지, 긴 리서치 보고서 작성, 특허·논문 조사, 복잡한 장애 원인 분석처럼 “한 번 틀리면 사람이 오래 다시 보는 작업”입니다.

추천 방식은 3단계입니다. 기본 요청은 기존 단일 모델로 처리하고, 난이도 점수가 높은 요청만 Fugu로 보냅니다. 그중에서도 정확도와 깊이가 정말 중요한 요청만 Fugu Ultra로 올립니다.

비추천하는 방식도 분명합니다. 단일 모델 호출 비용도 아직 측정하지 못한 팀, 프롬프트·평가셋·로그가 없는 팀, 개인정보 처리 경계가 불명확한 팀은 Fugu를 먼저 붙이면 문제 원인을 더 찾기 어려워집니다.

3. 핵심 구조 분해: 단일 API 뒤에 있는 네 가지 층

핵심 요약: Fugu는 호출 인터페이스, 오케스트레이터, 에이전트 풀, 검증·합성 단계로 나눠 봐야 이해됩니다.

첫째, OpenAI 호환 API 층

개발자는 Fugu를 하나의 모델처럼 호출합니다. 공식 모델 문서에 따르면 Responses API, Chat Completions API, Models API를 지원하고, 모델 ID는 fugu, fugu-ultra, fugu-ultra-20260615처럼 제공됩니다.

둘째, 오케스트레이터 모델 층

Fugu 자체가 언어 모델이며, 어떤 문제는 직접 풀고 어떤 문제는 다른 모델에게 위임합니다. “라우터”라는 말만으로는 부족합니다. 단순 분기보다 계획, 위임, 재검토, 합성까지 담당하기 때문입니다.

셋째, 에이전트 풀 층

공식 발표는 Fugu가 다양한 LLM 풀을 호출한다고 설명합니다. 다만 어떤 모델이 몇 개 쓰이는지, 어떤 경로로 분배되는지는 모두 공개하지 않았습니다. 이 비공개성은 경쟁력인 동시에 운영 리스크입니다.

넷째, 검증·합성 층

여러 모델이 만든 부분 답변은 그대로 사용자에게 나가면 안 됩니다. 최종 답변으로 합치고, 충돌을 정리하고, 실패한 추론을 걸러야 합니다. 이 단계가 약하면 모델을 많이 써도 품질은 오히려 흔들립니다.

4. 설계 의도 해설: 큰 모델 하나보다 조율자를 키우는 전략

핵심 요약: Fugu의 설계 의도는 “모든 지식을 한 모델에 넣기”보다 “상황마다 강한 모델을 조합하기”에 가깝습니다.

사카나 AI는 공식 발표에서 단일 벤더 의존을 운영 취약점으로 봅니다. 특정 모델 접근이 규제, 가격, 장애, 계약 문제로 막히면 서비스 전체가 흔들릴 수 있기 때문입니다. Fugu는 이 문제를 모델 풀 교체와 동적 라우팅으로 완화하려는 시도입니다.

얻는 것은 유연성입니다. 새로운 모델이 나오면 애플리케이션 코드를 크게 바꾸지 않고 풀에 넣을 수 있습니다. 어려운 요청은 여러 전문가 모델이 나눠 처리할 수 있습니다.

포기하는 것도 있습니다. 내부 라우팅 경로가 완전히 투명하지 않으면 재현성과 감사가 어려워집니다. 모델 호출 수가 늘면 지연 시간과 비용이 증가합니다. 특히 Fugu Ultra는 공식 문서상 내부 오케스트레이션 토큰도 실제 과금 대상이므로, “최종 답변 토큰만 짧게 제한하면 싸다”는 가정이 맞지 않습니다.

5. 근거 및 비교: Fugu, DIY 라우터, 워크플로 오케스트레이터

핵심 요약: 비교 기준은 성능표가 아니라 통제권, 비용, 관측성, 장애 대응입니다.

접근	장점	한계	맞는 상황
Fugu / Fugu Ultra	단일 API로 모델 선택·위임·합성을 맡길 수 있음	내부 경로와 모델 풀이 제한적으로만 보임, Ultra는 오케스트레이션 토큰 비용 주의	복잡한 분석·코딩·리서치 품질을 빠르게 끌어올리고 싶은 팀
DIY 라우터	라우팅 기준, 로그, 예산, 개인정보 경계를 직접 통제	평가셋·운영툴·장애 대응을 직접 만들어야 함	규제 산업, 자체 모델 보유, 비용 최적화가 핵심인 팀
LangGraph·Semantic Kernel류 워크플로	상태, 승인, 재시도, 사람 검토 단계를 명시적으로 설계 가능	모델 선택 지능은 별도 구현 필요	업무 절차가 중요하고 감사 로그가 필요한 팀

벤치마크는 참고만 해야 합니다. 사카나 공식 모델 페이지는 Fugu Ultra가 LiveCodeBench 93.2, GPQA Diamond 95.5, SWE Bench Pro 73.7을 기록했다고 제시합니다. 하지만 이 수치는 공급자 발표값이 섞인 비교이며, 실제 제품 품질은 여러분의 요청 분포와 실패 기준에서 다시 측정해야 합니다.

관련 연구도 같은 방향을 말합니다. 금융 문서 처리 멀티 에이전트 비교 연구는 reflexive 구조가 가장 높은 F1을 냈지만 비용은 순차 기준보다 2.3배 높았고, 계층형 구조가 F1 0.921과 1.4배 비용으로 더 나은 균형점을 보였다고 보고했습니다. 즉 “더 많은 에이전트”가 항상 정답은 아닙니다.

6. 실제 동작 흐름: 도입 전 파일럿을 이렇게 설계한다

핵심 요약: 바로 전면 도입하지 말고, 라우팅 전후의 품질·비용·지연을 같은 데이터셋에서 비교해야 합니다.

1단계는 업무를 나누는 것입니다. 예를 들어 PR 리뷰라면 보안 취약점, 성능 문제, 타입 안정성, 테스트 누락, 문서 누락처럼 평가 항목을 분리합니다.

2단계는 난이도 게이트를 둡니다. 파일 변경 수, 보안 민감 경로, 외부 입력 처리 여부, 마이그레이션 포함 여부 같은 규칙으로 “일반 모델”, “Fugu”, “Fugu Ultra”를 나눕니다.

type Route = "single-model" | "fugu" | "fugu-ultra";

function routePullRequest(input: {
  changedFiles: number;
  touchesAuth: boolean;
  hasMigration: boolean;
  estimatedTokens: number;
}): Route {
  const risk =
    input.changedFiles * 1 +
    (input.touchesAuth ? 8 : 0) +
    (input.hasMigration ? 5 : 0) +
    (input.estimatedTokens > 60000 ? 4 : 0);

  if (risk >= 12) return "fugu-ultra";
  if (risk >= 6) return "fugu";
  return "single-model";
}

3단계는 비용 한도를 둡니다. Fugu Ultra의 max_output_tokens는 최종 응답에만 적용되고, 오케스트레이터 모델의 토큰 사용은 별도로 발생할 수 있습니다. 따라서 “요청당 최대 비용”, “작업당 최대 지연 시간”, “재시도 횟수”를 애플리케이션 쪽에서 끊어야 합니다.

# 운영 전 파일럿에서 반드시 남길 로그 예시
request_id=pr-1842
route=fugu-ultra
task_type=security_review
input_tokens=48210
final_output_tokens=3810
orchestration_tokens=측정값
latency_ms=측정값
human_acceptance=accepted_with_edits

4단계는 사람 평가를 붙입니다. 모델이 찾은 이슈 수만 세면 과탐이 늘어날 수 있습니다. “실제로 수정한 이슈”, “리뷰어가 거절한 이슈”, “놓친 심각 이슈”를 함께 기록해야 합니다.

7. 실수와 함정: 모델 라우팅은 실패가 조용히 누적된다

핵심 요약: Fugu류 시스템의 위험은 대개 답변 품질보다 로그, 비용, 재현성에서 먼저 드러납니다.

실수 1: 모든 요청을 Ultra로 보내기

예방: 요청 난이도 게이트와 예산 상한을 먼저 둡니다. 복구: 최근 7일 로그에서 작업 유형별 비용과 사람 승인률을 비교해 Ultra 대상 업무를 줄입니다.

실수 2: 내부 오케스트레이션 비용을 최종 토큰만으로 추정하기

예방: Fugu Ultra의 오케스트레이션 토큰 필드를 별도 지표로 저장합니다. 복구: p95 비용이 예산을 넘는 요청 유형은 단일 모델이나 일반 Fugu로 내립니다.

실수 3: 벤치마크 점수를 제품 성공 기준으로 착각하기

예방: 자체 평가셋 50~100개를 만들고, 정답 품질·지연·비용·거절률을 같이 봅니다. 복구: 벤치마크가 아니라 실제 사용자 작업 성공률 기준으로 라우팅 정책을 다시 튜닝합니다.

실수 4: 개인정보·기밀 데이터 경계를 나중에 정하기

예방: 어떤 데이터가 어떤 모델 풀로 갈 수 있는지 먼저 분류합니다. 복구: 민감 경로는 opt-out 가능한 일반 Fugu 또는 자체 라우터로 제한하고, 로그 보존 정책을 다시 세웁니다.

8. 강점과 한계: ‘AI 주권’ 주장도 운영 현실로 번역해야 한다

핵심 요약: Fugu는 벤더 의존을 줄일 수 있지만, 완전한 통제권을 주는 것은 아닙니다.

강점은 분명합니다. 여러 모델을 한 인터페이스 뒤에 묶으면 애플리케이션 코드는 단순해집니다. 특정 모델 장애나 접근 제한이 생겨도 라우팅으로 우회할 여지가 있습니다. 복잡한 작업에서는 단일 모델보다 검토와 합성을 더 잘할 가능성도 있습니다.

한계도 같이 봐야 합니다. 내부 모델 풀이 비공개라면 규제 대응과 재현성 설명이 어렵습니다. 품질이 좋아져도 지연 시간이 길어지면 실시간 제품에는 맞지 않을 수 있습니다. 오케스트레이션 토큰이 과금에 포함되면 사용량이 많은 서비스에서는 비용 예측이 어려워집니다.

따라서 작성자 관점의 결론은 이렇습니다. Fugu는 “모든 AI 호출의 기본값”보다 “고위험·고난도 요청의 품질 상승 옵션”으로 보는 편이 맞습니다. 금융, 의료, 공공처럼 감사와 데이터 경계가 핵심인 팀은 Fugu보다 명시적 워크플로와 자체 라우팅을 먼저 설계하는 것이 더 낫습니다.

9. 더 깊게 공부할 포인트

핵심 요약: Fugu를 이해하려면 모델 성능표보다 오케스트레이션 논문, 비용 로그, 라우팅 평가법을 봐야 합니다.

첫째, Fugu 공식 발표와 모델 문서를 읽고 지원 API와 토큰 과금 구조를 확인하세요. 둘째, Fugu 기술 보고서와 Trinity, Conductor 논문을 통해 “학습된 오케스트레이터”가 무엇을 최적화하려는지 봐야 합니다. 셋째, 멀티 에이전트 비용-정확도 연구를 참고해 에이전트를 늘릴 때 생기는 비용 곡선을 이해해야 합니다.

코드 관점에서는 다음 네 가지 파일 또는 모듈을 먼저 만들 것을 권합니다. router.ts에는 라우팅 규칙, eval-set.jsonl에는 자체 평가셋, cost-budget.ts에는 요청별 예산, review-dashboard에는 route·latency·cost·human_acceptance 지표를 둡니다.

10. 실행 체크리스트와 완료 기준

핵심 요약: 도입 완료 기준은 “API 호출 성공”이 아니라 “언제 쓰고 언제 쓰지 않을지 숫자로 설명 가능”입니다.

기존 단일 모델 기준선의 품질, 평균 비용, p95 지연 시간을 측정했다.
Fugu와 Fugu Ultra로 보낼 작업 유형을 명확히 나눴다.
자체 평가셋 50개 이상으로 단일 모델, Fugu, Fugu Ultra를 비교했다.
오케스트레이션 토큰, 최종 출력 토큰, 총 비용을 별도 필드로 저장한다.
요청당 최대 비용, 최대 지연 시간, 재시도 횟수 제한을 구현했다.
민감 데이터가 어떤 모델 풀로 갈 수 있는지 정책으로 문서화했다.
라우팅 실패 시 단일 모델 또는 사람 검토로 돌아가는 fallback을 만들었다.
벤치마크 점수 대신 사람 승인률과 실제 수정 반영률을 핵심 지표로 삼았다.

Definition of Done: Fugu 적용 대상 업무에서 단일 모델 대비 사람 승인률이 오르고, p95 비용과 p95 지연 시간이 사전에 정한 한도 안에 머물며, 실패 시 fallback 경로가 로그로 확인되면 파일럿 완료입니다.