모델 선택 화면 앞에서 "이 작업엔 Opus? Sonnet? GPT?"를 고민하는 장면, 익숙합니다.

GitHub은 그 고민 자체를 런타임에 넘기는 실험을 이어가고 있습니다. 10월 14일 공개된 HydraFusion 업데이트가 그 최신 버전입니다.

HydraFusion = 여러 모델을 조합해 하나의 응답을 만드는 런타임
              (모델 하나를 고르는 기능이 아님)

이번 업데이트
  ① 모델 풀 갱신: Claude Opus 5.5, GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna
  ② 단계별 추론 강도: 초안은 medium, 검토는 high
  ③ Cascade에 '판정' 단계 추가
  ④ Critique가 요약 대신 실제 워크스페이스를 직접 확인 (병렬 critic)
  ⑤ 강도 높은 작업용 HydraFusion Max 옵션 추가

여전히 연구 프리뷰(research preview)입니다. 하지만 이번 업데이트는 "모델을 고르는 일"이 "작업을 어떻게 배분할지 설계하는 일"로 옮겨가는 흐름을 잘 보여줍니다.

세 가지 실행 패턴부터 이해하면 쉽습니다

HydraFusion은 프롬프트마다 세 가지 패턴 중 하나를 고릅니다.

Single    — 모델 하나가 바로 해결. 오버헤드 없음.
Cascade   — 저렴한 모델이 초안 → 품질 게이트가 판정
            → 필요할 때만 강한 모델로 에스컬레이션
Critique  — 한 모델이 초안 → 다른 모델 계열의 '읽기 전용 critic'이
            병렬로 검토 → 1회 수정

여기서 10월 14일 업데이트가 손댄 지점이 보입니다.

Cascade 변경
  기존: 초안 → 문제가 있으면 강한 모델로 전환
  이제: 중간에 판정(judging) 단계가 초안을 검사하고
        정말 필요할 때만 수리에 들어감

Critique 변경
  기존: 텍스트 요약을 중심으로 검토
  이제: 도구를 써서 실제 워크스페이스를 직접 확인
        + critic 모델 여러 개가 병렬로 검토

추론 강도도 단계별로 나뉩니다. 초안은 medium, 검토는 high. 작성은 효율적으로, 확인은 깊게 — Reasoning High vs Max 글에서 다뤘던 "작업 난이도에 예산을 맞추기"가 제품 기본값으로 들어온 셈입니다.

HydraFusion과 Max, 무엇을 고르나

새로 생긴 Max는 같은 아키텍처에 "깊이"를 더한 옵션입니다.

HydraFusion      — 균형형. 중간 수준의 토큰 절약.
                   속도·비용·성능의 균형이 필요한 에이전트 작업.
HydraFusion Max  — 프런티어급. 가장 깊은 추론이 필요한 작업.
                   토큰 효율은 오케스트레이션으로 관리.

둘 다 VS Code, GitHub Copilot 앱, Copilot CLI 세 곳에서 쓸 수 있고, Copilot Pro·Pro+·Business·Enterprise 플랜에서 실험·프리뷰 기능을 켠 경우에만 나타납니다. 조직의 모델 정책이 허용하는 모델만 사용합니다.

배경: 9월 첫 공개와 벤치마크, 그리고 그 한계

HydraFusion은 9월 4일 Copilot CLI의 실험 모드에서 연구 프리뷰로 시작해 9월 30일 VS Code와 Copilot 앱으로 확장됐습니다. 당시 GitHub이 공개한 오프라인 테스트 결과(Claude Opus 5와 비교, 모두 medium 추론 강도)는 이랬습니다.

TerminalBench 2.1   : 비용 67% 절감, 품질 +4.9점
DeepSWE             : 비용 36% 절감, 품질 -1.5점
CheckpointBench(내부): 비용 65% 절감, 품질 -0.1점

절대 수치 (pass@1, 작업당 비용)
  TerminalBench 2.1  HydraFusion 84.7% / $0.30
                     Opus 5      79.8% / $0.90
  DeepSWE            HydraFusion 62.6% / $2.70
                     Opus 5      64.1% / $4.20

이 표를 읽을 때 세 가지를 기억해야 합니다.

① 세 시험 중 1개에서만 Opus 5를 앞섰다 (나머지는 근소한 열세 + 큰 비용 절감)
② 비교 대상 모델들이 벌써 한 세대 이전이다 (Opus 5.5·GPT-6.1 Sol이 그 뒤에 나옴)
③ 오프라인 테스트, 최적 설정, 특정 가격 가정 기준이다

"Opus보다 낫다"가 아니라 비슷한 품질을 훨씬 싸게, 한 시험에서는 더 좋게가 정확한 요약입니다. Gemini 4 Argon 벤치마크 글에서 봤던 것처럼, 시험지마다 결과가 갈리는 건 이제 자연스러운 일입니다.

과금과 지연: 두 가지를 미리 알아두세요

과금
  사용된 모든 leg(초안·검토·수정·에스컬레이션·재시도)의
  각 모델 표준 요금을 합산.
  Auto 모델 선택의 10% 할인은 적용되지 않음.
  → AI Credits(1 크레딧 = $0.01)로 청구

지연
  Single은 단일 모델 호출과 비슷.
  Cascade·Critique는 검토 패스가 붙어 더 오래 걸림.
  → 한 번에 맡기는 큰 작업에 맞고, 실시간 대화형 루프에는 부담

워크플로 선택 자체는 가볍습니다. 문제는 패스 수입니다. 같은 프롬프트라도 게이트가 열리면 비용이 늘고, Critique은 항상 최소 두 번 이상의 모델 호출을 씁니다. 그래서 CLI에는 실행당 상한(--max-ai-credits) 같은 브레이크가 있고, 팀 단위로는 기본 모델을 정할 때 이 상한을 함께 정하는 게 좋습니다.

한계도 분명합니다

- 연구 프리뷰, SLA 없음, 프로덕션 용도 아님(문서 명시)
- 모델 풀은 고정 목록을 공개하지 않음 (정책)
- 서브에이전트는 HydraFusion이 관여하지 않음
- 중간 초안이 버려져도 이미 한 파일 수정은 자동 롤백되지 않음
- 컨텍스트 창은 사용 모델 중 가장 작은 값 기준
- 첫 턴, 잘 정의된 단일 프롬프트 작업이 가장 잘 맞음

네 번째 항목은 꼭 기억하세요. "실패하면 패치를 적용하지 않는다"는 원칙이 작업 트리 보호를 뜻하지는 않습니다. 디스크에 이미 들어간 수정은 남습니다. 브랜치나 일회용 워크트리에서 돌리고 diff를 확인하는 습관은 여기서도 그대로입니다.

CodeBridge Mini Lab: 같은 작업으로 셋을 비교하세요

브리핑의 액션을 실험으로 바꾸면 이렇습니다.

① 검증 가능한 작업 2개를 고른다 (예: 실패 테스트 1개 수정, 다중 파일 리팩토링 1개)
② 설정 3가지를 같은 조건으로 돌린다: Auto / HydraFusion / HydraFusion Max
③ 각 2회씩 반복하고 기록한다:

   [ ] 성공률 (테스트 통과 같은 결정적 기준)
   [ ] 소요 시간 중앙값
   [ ] 사용된 AI Credits
   [ ] 실제로 쓰인 모델 목록과 실행 패턴 (Single/Cascade/Critique)
   [ ] diff를 열어 검토 (테스트를 지워서 통과시키는 경우 확인)
④ "품질을 유지하면서 예산이 어디서 줄었는가"로 판단한다

포인트는 벤치마크를 믿는 게 아니라 내 작업에서 다시 재는 것입니다. 프리뷰는 바뀌니 CLI 버전과 날짜도 함께 기록해 두세요.

결론: 모델을 고르는 사람에서, 작업을 배분하는 사람으로

한 문장으로 정리하면 이렇습니다.

좋은 질문은 더 이상 "어떤 모델을 쓰지?"가 아니라
"이 작업은 몇 번의 패스를 쓸 가치가 있나?"다.

초안은 가볍게, 검토는 깊게, 에스컬레이션은 아껴서. HydraFusion Max는 그 배분을 제품 기본 동작으로 만들어 가는 시도입니다. 프리뷰가 프로덕션용이 아니라는 점은 변함없으니, 도입 판단은 자기 작업으로 만든 비교표 하나로 하세요. 그 표가 없으면 67%라는 숫자는 남의 이야기일 뿐입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

초안·검토·에스컬레이션을 단계로 나누는 감각은 멀티모델 기능 하나를 아는 것보다 오래 갑니다. 하네스·루프·그래프를 직접 설계하며 "어디서 모델을 바꾸고, 어디서 검증할지"를 연습해 보세요.