GitHub, 여러 모델을 작업마다 골라 쓰는 HydraFusion을 Copilot CLI 프리뷰로 공개

한 줄 요지 — 지금 확인할 것은 품질이 아니라 요청당 비용의 예측 가능성입니다.

무슨 일인가

GitHub이 2026년 9월 4일 Project HydraFusion을 리서치 프리뷰로 공개했습니다. 하나의 모델을 고정해 쓰는 대신, 작업마다 실행 방식을 골라 주는 모델 오케스트레이션(요청을 어느 모델·어느 절차로 처리할지 실행 시점에 고르는 방식, 용어집)입니다.

• 실행 패턴은 3종입니다.
  • Single — 모델 하나가 바로 답합니다.
  • Cascade — 값싼 모델이 초안을 내고, 품질 게이트가 통과·승격을 판정해 필요할 때만 상위 모델로 넘깁니다.
  • Critique — 모델이 초안을 내고 독립된 비평자가 검토한 뒤 원래 모델이 한 번 고칩니다.
• 벤치마크는 Claude Opus 5 기준으로 세 개를 제시했습니다.
  • TerminalBench 2.1 — 품질 +4.9%p, 비용 67% 절감.
  • DeepSWE — 품질이 1.5%p 이내로 근접, 비용 36% 절감.
  • CheckpointBench — 품질이 0.1%p 이내로 근접, 비용 65% 절감.
• 적용 범위는 전 Copilot 플랜이고, Copilot CLI에서 /experimental on 후 /model 에서 고르는 opt-in입니다.
• 과금은 별도 요율 없이 “사용한 모델의 표준 요율”을 따릅니다. 원문은 결과가 “평가한 벤치마크 리비전·워크플로 구성·모델 풀·가격 가정에 한정된다”고 명시했고, 프리뷰에서는 첫 턴 단일 프롬프트 작업부터 시작할 것을 권했습니다.

태리의 판단

이건 품질 도약이 아니라 비용 곡선을 바꾸려는 시도입니다.

근거는 GitHub 자신의 문장에 있습니다. 세 벤치마크 중 둘에 쓰인 표현이 “comes within” — 따라잡았다는 뜻이지 앞섰다는 뜻이 아닙니다. 실제로 앞선 것은 TerminalBench 하나뿐이고, 비용 절감은 전부 “estimated cost”에 “가격 가정”이라는 단서가 붙어 있습니다.

더 눈여겨볼 지점은 따로 있습니다. 모델 풀을 공개하지 않는다는 점입니다 — 원문은 “여러 제공자의 모델 중에서 고른다”고만 적었습니다. 어떤 요청이 어느 모델로 가는지 알 수 없으면 요청당 비용도, 데이터가 어느 벤더를 거치는지도 미리 알 수 없습니다. 평균 비용이 내려가도 건별 분산은 오히려 커지는 구조이고, 이건 예산을 월 단위로 잡는 팀보다 요청 단위로 상한을 거는 팀에 먼저 문제가 됩니다. Cascade가 “필요할 때만 승격”하는 이상, 승격 빈도를 모르면 상한을 설계할 수 없습니다.

이번 주 할 일

팀 관점으로는, 실제 작업 로그로 건별 비용 분포를 한 주만 재 보시길 권합니다. 평균이 아니라 상위 10% 요청의 비용이 예산 설계의 기준선이기 때문입니다. 다만 프리뷰 단계에서 측정한 값은 모델 풀이 바뀌면 그대로 쓰기 어려우므로, 이 측정은 의사결정 근거가 아니라 관측 기준선으로 두시는 편이 안전합니다.

개인 기여자 관점으로는, /experimental on 후 평소 쓰던 프롬프트 3개만 같은 조건으로 돌려 보고 답변의 결이 달라지는지만 메모해 두시면 충분합니다.