GitHub HydraFusion은 Copilot CLI를 위한 연구 프리뷰 오케스트레이션 시스템이다. 오프라인 벤치마크에서 나온 결과가 길고 복잡한 실제 리포지토리에서도 그대로 재현된다고 보기는 어렵다.
설정 전에 알아둘 결론
GitHub Copilot 플랜을 사용 중이고, 하나의 프롬프트로 명확하게 정의할 수 있는 규모 있는 코딩 작업이 있다면 GitHub HydraFusion은 시도해 볼 만하다. 다만 중요한 프로덕션 변경이나 여러 차례 대화를 주고받아야 하는 작업의 기본 선택지로 삼기에는 아직 이르다. GitHub가 여전히 이를 연구 프리뷰로 분류하고 있으며, 더 강력한 멀티턴 지원은 향후 과제로 언급하고 있기 때문이다.
HydraFusion은 새로운 파운데이션 모델이 아니다. GitHub Copilot CLI 안에서 동작하는 런타임 오케스트레이션 시스템으로, 작업에 단일 모델이면 충분한지, 상위 모델로 전환해야 하는지, 독립적인 검토가 필요한지를 판단한 뒤 결과를 반환한다.
Copilot CLI에서 HydraFusion 켜기
이 프리뷰는 일반적인 VS Code 모델 선택기가 아니라 Copilot CLI에서 활성화한다. GitHub 공식 발표에 따르면 실험적 명령어 절차를 통해 모든 Copilot 플랜에서 사용할 수 있다. 설치와 인증은 별도로 Copilot CLI quickstart에서 안내한다.
/update를 실행해 Copilot CLI를 업데이트한다./experimental on으로 실험 기능을 활성화한다./model을 실행해 모델 선택기를 연다.- HydraFusion (Research Preview)을 선택한다.
- 길게 이어지는 대화형 프로젝트 대신, 범위가 분명한 하나의 규모 있는 코딩 작업으로 시작한다.
HydraFusion이 목록에 보이지 않는다면 먼저 CLI를 업데이트하고, Copilot 계정과 조직 정책, CLI 빌드가 프리뷰를 지원하는지 확인한다. 현재 명령어 절차의 기준은 GitHub의 공식 발표다. 프리뷰 명칭과 제공 범위는 바뀔 수 있다.
검색 결과에는 자율주행차 센서 융합 연구 리포지토리인 AICPS/hydrafusion도 함께 나타난다. 이 프로젝트는 Copilot용 GitHub Project HydraFusion과 관계없다.
작업 성격에 따라 달라지는 실행 방식
HydraFusion은 예상 품질, 비용, 지연 시간 요구사항을 바탕으로 세 가지 실행 패턴 중 하나를 고른다. 현재 프리뷰에서 사용자가 직접 전환하는 ‘모드’는 아니다. GitHub는 HydraFusion을 런타임에 내부 워크플로를 선택하는 모델 같은 옵션으로 제공한다.
| 워크플로 | 동작 방식 | 처음 적용하기 좋은 작업 | 주요 절충점 |
|---|---|---|---|
| Single | 하나의 모델이 작업을 바로 처리한다. | 단순한 수정, 설명, 소규모 버그 수정. | 추가 오버헤드는 가장 적지만, 상위 모델 전환이나 독립 검토는 없다. |
| Cascade | 효율적인 모델이 먼저 초안을 만들고, 품질 게이트가 더 강력한 모델로 넘길지 판단한다. | 간단할 수도 있지만 더 높은 역량이 필요해질 수 있는 작업. | 첫 시도가 통과하면 비용을 아끼지만, 게이트와 두 번째 호출이 추가될 수 있다. |
| Critique | 한 모델이 초안을 만들고, 다른 모델 계열의 격리된 비평 모델이 검토한 뒤 작성 모델이 한 번 수정한다. | 두 번째 관점으로 실수를 잡아낼 여지가 있는 변경. | 호출 수와 지연 시간이 늘어나며, 비평 모델은 도구에 직접 접근할 수 없다. |
Single: 한 모델이 바로 처리
Single은 가장 단순한 경로다. GitHub 설명에 따르면 하나의 해결 모델이 작업을 받아 일반적인 권한 인식 Copilot 에이전트 루프에서 처리한다. 구현 방향이 뚜렷하고 테스트 경로가 짧은 요청에 잘 맞는다.
워크플로 오버헤드가 적다는 장점은 있지만, Single에는 기본으로 제공되는 세컨드 오피니언이 없다.
Cascade: 먼저 효율적으로, 필요할 때만 상위 모델로
Cascade는 효율적인 모델에서 시작하며, 결과가 충분한지 아니면 상위 모델로 넘겨야 하는지를 품질 게이트가 결정한다. 핵심은 선택적 에스컬레이션이다. 일상적인 요청까지 항상 가장 강력한 모델을 쓰게 할 필요는 없다는 접근이다.
첫 번째 결과가 게이트를 통과하면 Cascade는 비용을 절감할 수 있다. 다만 GitHub는 공통으로 적용되는 에스컬레이션 비율을 공개하지 않았다. 모든 요청이 저비용 경로를 탄다고 가정하기보다 실제 작업 결과로 평가해야 한다.
Critique: 초안 작성, 독립 검토, 한 번의 수정
Critique에는 다른 모델 계열의 별도 검토자가 추가된다. GitHub 설명에 따르면 비평 모델은 도구 없이 격리된 컨텍스트에서 초안을 검토하고, 원래의 해결 모델에 피드백을 보내 한 번 수정하게 한다. 비평 모델이 리포지토리를 직접 수정할 수는 없다.
자동화된 동료 검토에 가깝지만, 그만큼 모델 호출과 지연 시간이 추가된다.
벤치마크는 약속이 아니라 조건부 비교로 읽어야 한다
GitHub의 오프라인 테스트는 벤치마크별 품질·비용 절충을 보여준다. 모든 Copilot 작업에서 비용이 67% 낮아진다는 보장은 아니다.
| 벤치마크 | Claude Opus 5 대비 HydraFusion 품질 | Claude Opus 5 대비 추정 비용 | 해석할 지점 |
|---|---|---|---|
| TerminalBench 2.1 | +4.9퍼센트포인트 | 67% 낮음 | 보고된 결과 중 가장 강력하다. 검증된 작업 품질은 더 높고 추정 비용은 더 낮았다. |
| DeepSWE | −1.5포인트 | 36% 낮음 | 난도가 높은 리포지토리 작업에서는 측정 가능한 품질 양보를 전제로 의미 있는 절감 효과가 있었다. |
| CheckpointBench | −0.1포인트 | 65% 낮음 | GitHub의 내부 리플레이 방식 벤치마크에서 품질은 거의 동등했고, 추정 비용은 훨씬 낮았다. |
GitHub는 공식 HydraFusion 발표에서 일관된 평가 설정을 사용했으며, 재시도·비평·에스컬레이션·폴백을 포함한 모든 워크플로 호출을 집계했다고 설명한다.
CheckpointBench는 선별된 Copilot 세션을 변경되지 않는 공개 리포지토리 커밋을 대상으로 재실행하는 방식으로 소개된다. 단순 텍스트 생성 테스트보다 코딩 에이전트 작업과 관련성이 높지만, 여전히 통제된 벤치마크다. DeepSWE에서 HydraFusion의 품질이 더 낮게 나온 결과는 이 표를 보편적인 승리로 해석하지 못하게 하는 중요한 지점이다.
독립적인 실사용 근거는 아직 부족하다. 독립 빌더인 X의 @DoDataThings는 검증에서 핵심이 될 우려를 다음과 같이 짚었다.
“계획을 세우는 모델과 코드를 작성하는 모델이 반드시 같을 필요는 없다. GitHub는 HydraFusion이 통제된 오프라인 평가에서 Opus 5 기준선을 따라잡거나 넘어섰다고 했지만, 오프라인 평가에서 지저분한 실제 리포지토리로 넘어가는 지점이야말로 오케스트레이션이 대체로 우위를 잃는 곳이다. 그 비용 격차가 얼마나 유지될지 궁금하다.”
이 글은 측정 결과가 아니라 질문이지만, 비용과 품질을 복잡한 실제 리포지토리에서 검증해야 한다는 올바른 시험 기준을 제시한다.
실제 리포지토리에서 중요한 운영 요소
HydraFusion의 가치는 단순히 더 저렴한 모델을 고르는 데서 끝나지 않는다. GitHub 문서는 회계 처리, 취소, 라우팅 검증, 검토 격리, 패치 적용을 위한 제어 장치를 설명한다. 여러 모델 호출이 얽히면 단일 직접 요청보다 운영 상태가 많아지기 때문이다.
| 제어 장치 | 사용자 입장에서의 의미 |
|---|---|
| 비용·시간 제어 | HydraFusion은 워크플로 각 단계의 호출을 추적하고 제한된 실행을 지원한다. 다만 비평, 에스컬레이션, 재시도, 폴백은 지연 시간이나 전체 사용량을 늘릴 수 있다. |
| 라우팅·패치 제어 | GitHub는 라우트를 검증하며 워크플로가 무효하거나 취소된 경우 패치를 적용하지 않는다고 설명한다. 그렇다고 선택된 경로나 최종 코드가 올바르다는 뜻은 아니다. |
| 검토 격리 | 해결 모델은 공유 워크스페이스를 사용하지만 비평 모델은 읽기 전용이고 도구가 없다. 검토자가 직접 변경하는 위험은 줄지만, 여전히 diff 검토와 테스트는 필요하다. |
GitHub 발표는 가시성 측면의 절충도 언급한다. 중간 초안은 최종 결과가 나올 때까지 표시되지 않는다. 응답은 깔끔해지지만, 기다리는 동안 초안 작성·재시도·에스컬레이션·폐기 과정은 볼 수 없다.
HydraFusion을 처음 시험하는 가장 현실적인 방법
첫 테스트에는 코드베이스를 ‘개선해 달라’는 식의 열린 요청보다, 객관적인 통과 기준이 있는 범위 제한형 리포지토리 작업이 적합하다. 시작 커밋과 성공 기준을 고정한 실험으로 이 프리뷰를 다루는 편이 좋다.
- 깨끗한 브랜치나 worktree를 만들고 시작 커밋을 기록한다.
- 파일 범위가 좁고 재현 가능한 테스트 명령이 있는 작업 하나를 고른다.
- 첫 프롬프트에 기대 동작, 제약 조건, 테스트를 명시한다.
- HydraFusion이 작업을 마치면 에이전트의 성공 보고만 믿지 말고 diff를 확인한다.
- 관련 테스트를 직접 실행하고, 관계없는 파일 변경이 없는지도 확인한다.
- CLI가 제공한다면 지연 시간, 표시되는 사용량 또는 비용 데이터, 재시도, 에스컬레이션 동작, 최종 테스트 결과를 기록한다.
- HydraFusion을 고정 모델과 비교하거나 팀의 기본 설정을 바꾸기 전에 몇 가지 작업으로 반복한다.
성공한 패치 하나만으로 벤치마크 주장을 검증하지는 말자. 일상적인 수정, 여러 파일에 걸친 변경, 에스컬레이션이나 비평이 의미 있을 법한 의도적으로 모호한 사례를 포함한 작은 작업 묶음이 유용한 단위다.
HydraFusion의 비용과 보장하지 않는 것
GitHub는 발표에서 HydraFusion의 별도 달러 가격을 공개하지 않았다. 대신 사용량은 내부에서 쓰인 모델의 표준 토큰 요율에 따라 과금된다고 설명한다. 따라서 최종 비용은 런타임이 어떤 모델과 워크플로 단계를 사용했는지에 따라 달라진다.
| 과금 관련 질문 | 현재 답변 |
|---|---|
| HydraFusion 전용 구독료가 있나? | GitHub 발표에는 별도의 HydraFusion 요금이 명시되어 있지 않다. |
| 사용량은 어떻게 과금되나? | 구성 모델이 소비한 토큰을 각 모델의 표준 요율로 과금한다. |
| 하나의 작업에서 과금 대상 호출이 여러 번 발생할 수 있나? | 그렇다. Cascade와 Critique는 여러 워크플로 단계를 거칠 수 있으며, 회계 처리에는 재시도와 폴백도 포함된다. |
| 벤치마크의 67% 절감은 고객 비용도 67% 절감된다는 뜻인가? | 아니다. 특정 벤치마크, 정책, 모델 풀, 가격 설정을 기준으로 한 추정 비교다. |
| HydraFusion은 안정적인 프로덕션 기능인가? | 아니다. GitHub는 이를 연구 프리뷰로 분류하며 모델, 워크플로, 제공 범위, 동작, 명칭이 바뀔 수 있다고 밝힌다. |
처음에는 결과를 점검할 수 있는 단일 프롬프트 작업에 HydraFusion을 사용하고, 리포지토리 수준의 테스트가 더 폭넓은 사용을 뒷받침할 때까지 긴 멀티턴 작업이나 영향이 큰 작업에는 고정 모델 폴백을 유지하는 편이 좋다.
HydraFusion FAQ
HydraFusion은 모델인가, 라우터인가?
HydraFusion은 독립적인 파운데이션 모델이 아니라 GitHub Copilot CLI의 런타임 멀티모델 오케스트레이션 시스템이다. 코딩 작업에 맞춰 모델과 실행 패턴을 선택한다.
Copilot CLI에서 HydraFusion은 어떻게 활성화하나?
/update, /experimental on, /model을 차례로 실행한 뒤 HydraFusion (Research Preview)을 선택하면 된다.
HydraFusion은 모든 Copilot 플랜에서 사용할 수 있나?
GitHub는 Copilot CLI를 통해 모든 Copilot 플랜에서 이 프리뷰를 사용할 수 있다고 밝힌다. 다만 계정, 조직, CLI 버전, 제공 범위의 변화에 따라 표시 여부는 달라질 수 있다.
HydraFusion은 어떤 내부 모델을 사용하나?
GitHub는 여러 제공업체의 모델을 대상으로 선택한다고 설명하지만, 요청별로 고정된 모델 목록은 공개하지 않았다. 따라서 모든 작업을 특정 이름의 모델이 처리한다고 가정해서는 안 된다.
HydraFusion은 언제나 Claude Opus 5보다 나은가?
그렇지 않다. GitHub는 TerminalBench 2.1에서 향상을, CheckpointBench에서 거의 동등한 결과를, DeepSWE에서는 1.5포인트 낮은 결과를 보고했다.
HydraFusion은 추가 비용이 드나?
사용량은 내부 모델의 표준 토큰 요율로 과금되며, 하나의 라우트가 여러 모델을 호출할 수 있다. GitHub는 발표에서 별도의 HydraFusion 달러 가격을 제시하지 않았다.
HydraFusion은 VS Code에서도 사용할 수 있나?
출시 자료는 Copilot CLI를 통한 프리뷰만 문서화하고 있으므로, 그 밖의 제공 범위는 최신 GitHub 문서에서 확인해야 한다.
HydraFusion이 리포지토리를 수정하도록 맡겨도 안전한가?
GitHub는 권한 인식 해결 모델, 격리된 비평 모델, 검증된 라우팅, 제한된 실행, 무효 또는 취소된 워크플로에서의 패치 미적용을 설명한다. 그래도 병합 전에는 반드시 diff를 검토하고 테스트를 실행해야 한다.