비용 67% 깎고 품질 4.9포인트 올렸다: GitHub이 모델 하나 고르기를 그만뒀다

모델 목록에서 하나를 고르는 화면은 이제 3년째 그대로다. GPT를 쓸지 Claude를 쓸지 고르고 작업을 던진다. GitHub이 9월 4일 그 목록에 이름 하나를 더 넣었는데 그건 모델이 아니라 실행 계획을 짜는 층이다.

Project HydraFusion은 요청을 받으면 먼저 어떻게 풀지를 정한다. 한 모델로 끝낼지, 값싼 모델에 초안을 맡기고 통과 못 하면 센 모델로 올릴지, 초안을 쓴 모델과 다른 계열의 모델에 검토를 시킬지. 세 패턴 중 하나를 고르고 여러 제공사의 모델을 섞어 돌린다.

한 줄 정리

GitHub이 모델 선택을 런타임 최적화 문제로 바꿔 놓았고 그 결과 같은 품질을 훨씬 싸게 뽑았다.

한눈에 보기

벤치마크	Opus 5 대비 비용	Opus 5 대비 품질
TerminalBench 2.1	67% 낮음	+4.9포인트
DeepSWE	36% 낮음	-1.5포인트
CheckpointBench (GitHub 내부)	65% 낮음	-0.1포인트

세 줄을 나란히 보면 이 제품의 정체가 나온다. 품질은 두 곳에서 오히려 소수점 단위로 내려갔다. 크게 움직인 건 비용 쪽이다. 품질을 올리는 제품이 아니라 같은 품질을 싸게 만드는 제품이다.

세 가지 실행 패턴

Single. 모델 하나가 바로 푼다. 한 번에 될 일에 검토를 붙이면 돈과 시간만 나간다.
Cascade. 효율 좋은 모델이 초안을 쓰고 품질 게이트가 통과 여부를 판정한다. 못 넘기면 더 센 모델로 올린다.
Critique. 한 모델이 초안을 쓰고 다른 계열의 모델이 읽기 전용으로 검토한 뒤 초안을 쓴 모델이 한 번 고친다.

Critique의 조건 하나가 눈에 띈다. 검토 모델은 도구 없는 격리된 컨텍스트에서 돈다. 저장소를 못 건드리고 읽고 말만 한다. 사람 팀에서 리뷰어에게 머지 권한을 안 주는 규칙과 같은 모양이다.

나머지 운영 원칙도 비슷한 결이다. 초안·검토·수정·에스컬레이션·재시도·폴백까지 모든 구간의 비용을 합산해 기록한다. 구간마다 타임아웃과 취소 동작을 박아 실행이 무한정 늘어지지 않게 한다. 워크플로가 취소되거나 검증에 실패하면 패치를 아예 적용하지 않는다. 절반만 반영된 변경이 저장소에 남는 상황을 원천 차단한 것이다.

자동 선택과 뭐가 다른가

GitHub은 올해 초에 이미 Auto model selection을 냈다. 작업을 보고 가장 잘 맞는 모델을 골라 주는 기능이다. 거기까지는 고르기다. 목록에서 사람이 하던 선택을 기계가 대신할 뿐 실행은 여전히 모델 하나가 한다.

HydraFusion은 실행 계획 자체를 만든다. 추론·코드 생성·디버깅·도구 사용에 대한 능력 신호를 보고 품질 기준을 맞출 수 있는 가장 단순한 워크플로를 고른다. 여기서 핵심은 선택이 아니라 절약이다. 추가 호출은 결과를 개선할 가능성이 있을 때만 붙인다.

모델 풀이 고정도 아니다. Copilot에 새 모델이 들어오면 평가해 풀에 넣고 잘하는 작업에 배정한다. 이번 평가에서 비교 대상으로 쓴 것도 Opus 5 하나가 아니라 GPT-5.6 Sol까지 둘이다. 특정 제공사에 묶이지 않는 구조를 제품 차원에서 밀고 있다.

지금 상태와 조건

Copilot CLI에서 /experimental on 을 켠 뒤 모델 목록에서 고르면 된다. 모든 Copilot 요금제에서 쓸 수 있고 과금은 HydraFusion이 실제로 부른 모델들의 표준 토큰 단가를 그대로 따른다. 즉 오케스트레이션 자체에 별도 요금은 없고 여러 번 부르면 여러 번 값을 낸다.

제약도 분명하다. 벤치마크 결과는 전부 통제된 오프라인 평가이고 특정 시점의 워크플로 설정, 모델 풀, 가격 가정에 묶여 있다. 비교 대상은 Opus 5와 GPT-5.6 Sol이며 전부 중간 수준 추론으로 맞춰 쟀다. GitHub이 권하는 사용법도 좁다. 첫 턴에 단일 프롬프트로 던지는 잘 정의된 작업이다. 여러 턴을 주고받는 긴 세션은 다음 과제로 남겨 뒀다.

체감상 걸리는 지점이 하나 더 있다. 중간 초안을 안 보여 준다. 검토와 수정을 거쳐 버려질 수 있는 결과를 실시간으로 노출하면 미완성이 완성처럼 보인다는 이유인데, 쓰는 쪽에서는 아무것도 안 보이는 대기 시간이 된다. GitHub도 이걸 실제 트레이드오프로 인정하고 개선 대상에 올려 뒀다.

anyAX 관점

지난 2년간 팀이 모델을 고르는 방식은 대개 이랬다. 누군가 벤치마크 표를 들고 와서 회의를 하고, 기본 모델을 하나 정하고, 아무도 그 결정을 다시 안 본다. 새 모델이 나오면 그 회의를 또 한다.

TerminalBench 2.1의 67%는 그 회의가 틀렸다는 이야기가 아니다. 작업마다 답이 달라서 하나로 못 고정한다는 이야기다. 리팩터링과 오탈자 수정에 같은 모델을 쓰면 한쪽은 부족하고 다른 쪽은 낭비다. HydraFusion은 그 판단을 회의에서 런타임으로 옮겨 놓았다.

여기서 팀이 실제로 가져갈 것은 도구가 아니라 순서다. 초안과 검토를 다른 모델 계열로 나누고 검토 쪽에는 쓰기 권한을 안 주는 구성. 이건 Copilot 없이도 오늘 만들 수 있다. 요구되는 건 API 두 개와 검토 프롬프트 하나다.

그리고 이 그림에서 사람이 남는 자리도 선명해진다. HydraFusion이 대신 못 하는 판단은 어떤 작업을 자동 오케스트레이션에 넘길지다. 틀렸을 때 되돌리기 쉬운 일과 그렇지 않은 일을 가르는 선이 있고, 그 선은 코드가 아니라 사업이 정한다. 실패 시 패치를 아예 적용하지 않는 원칙을 GitHub이 다섯 가지 중 하나로 박아 둔 이유도 같다. 자동화의 신뢰도는 잘 됐을 때가 아니라 실패했을 때 무엇을 남기느냐로 결정된다.