Copilot HydraFusion은 한 프롬프트에 모델 여러 개를 돌리고 최종 응답 하나만 보여준다. 버려진 초안이 이미 고친 파일은 되돌려지지 않고, 크레딧은 모델마다 표준 단가로 빠진다. 커밋 전에 git diff와 /usage의 모델별 크레딧을 응답 문구와 따로 확인해야 한다.
코딩 에이전트의 작업을 검토할 때 리뷰어가 먼저 읽는 것은 대개 채팅 창의 마지막 응답이다. "두 파일을 고쳤고 테스트를 추가했다"는 문장을 보고 그 두 파일을 연다. 응답을 쓴 모델과 파일을 고친 모델이 같다는 전제다.
GitHub 10월 14일 HydraFusion 업데이트 공지는 그 전제를 깬다. HydraFusion은 Claude Opus 5.5·GPT-6 Astra·GPT-6.1 Sol·GPT-6 Luna를 섞어 응답 하나를 만들고, 초안에는 medium, 리뷰에는 high 추론 강도를 쓴다. 더 깊은 추론용 HydraFusion Max도 함께 나왔다. VS Code, Copilot 앱, Copilot CLI에서 쓸 수 있다.
HydraFusion이 숨기는 것은 초안이고, 초안이 고친 파일은 작업 트리에 남는다
GitHub Docs의 HydraFusion 문서는 이 기능을 모델이 아니라 런타임 오케스트레이터로 정의한다. 프롬프트마다 아래 세 패턴 중 하나와 각 단계의 모델·추론 강도를 고르므로, 한 세션 안에서도 패턴이 섞인다.
| 패턴 | 실행 방식 | 화면에 남는 것 |
|---|---|---|
| Single | 모델 하나가 처리 | 그 모델의 응답 |
| Cascade | 효율 모델이 초안, 판정자가 채택하거나 상위 모델로 넘김 | 최종 응답 |
| Critique | 한 모델이 초안, 다른 모델이 비평, 원래 모델이 한 번 고침 | 최종 응답 |
문서는 중간 초안을 보여주지 않는 이유로 초안이 수정되거나 폐기될 수 있다는 점을 든다. 같은 문서의 한계 항목에는 이 문장이 붙어 있다: 폐기된 초안이 작업 공간에서 이미 한 변경(파일 수정 등)은 자동으로 되돌려지지 않으니 커밋 전에 변경을 검토하라. Cascade에서 판정자가 초안을 물리고 상위 모델로 넘겨도, 하위 모델이 쓴 파일은 그대로 남을 수 있다. 최종 응답은 마지막 패스가 한 일을 설명한다.
응답에 적힌 변경 목록과 실제 작업 트리는 서로 다른 기록이다.
둘이 얼마나 자주 어긋나는지는 Microsoft·Hugging Face의 10월 3일 ThinkingBox 발표가 수치로 보여준다. 12개 모델로 돌린 유효 시행 121,680회 중 실행 검사에서 떨어진 79,853회의 67.24%는 상태를 바꾸는 도구를 호출하고 도구 오류 없이 깔끔하게 끝났다. 실패 가운데 77.61%는 필드 값이 틀렸다. 이 벤치마크는 그래서 응답 문구 대신 백엔드의 최종 상태로 채점한다. HydraFusion 세션의 채점 기준도 응답이 아니라 git diff로 옮겨야 한다.
청구서는 응답 하나가 아니라 모델 패스마다 쌓인다
HydraFusion 자체 요금은 없고, 쓰인 모델마다 그 모델의 표준 단가로 AI 크레딧이 빠진다. GitHub의 자동 모델 선택 문서가 유료 플랜에 주는 10% 할인은 HydraFusion에 적용되지 않는다. Cascade와 Critique는 패스를 여러 번 돌려 느리고 크레딧을 더 쓸 수 있어서, 문서는 짧은 일상 작업에는 Auto를 고르라고 권한다. 공지의 "적당한 토큰 절감"에는 비교 기준이 없다.
비용 확인도 모델 단위로 한다. Copilot CLI의 /usage는 모델별 크레딧을, /collect-debug-logs는 단계마다 고른 패턴과 모델을 아카이브로 남긴다. 표시되는 컨텍스트 창은 풀에서 가장 작은 한도 기준이라, 긴 대화는 전환 전에 압축해야 한다.
풀에 들어갈 모델은 사용자가 고르지 못한다. 조직 모델 정책이 허용한 모델만 쓰이고, 하나도 없으면 선택기에서 사라진다. GitHub 10월 15일 모델 종료 공지는 11월 16일 Claude Opus 4.8·Claude Opus 5·GPT-5.6 Terra를 내리고 대체 모델로 Claude Opus 5.5와 GPT-6.1 Sol·GPT-6 Luna를 제시했다. 전역 기본값을 꺼 둔 Business·Enterprise 조직은 대체 모델을 직접 허용해야 하고, 그 선택이 HydraFusion이 쓸 풀도 함께 정한다. 모델 풀이 청구서를 정하는 구조는 Copilot 자동 모델 선택의 효율 티어는 예산 상한이 아니라 가중치다, 청구서를 정하는 건 관리자가 남겨 둔 모델 풀이다에서 다뤘다.
가져갈 것
- HydraFusion을 켠 사람이 커밋 전에
git status·git diff를 응답에 적힌 변경 목록과 대조하는 단계가 PR 템플릿이나 팀 규칙에 들어 있는가? -
copilot --experimental --model hydrafusion -p를 CI나 배치 스크립트에 넣은 곳이 있는가? 문서는 SLA가 없고 프로덕션 용도가 아니라고 적었다. - Copilot CLI 비용 점검이
/usage의 모델별 AI 크레딧을 보는가, 아니면 Auto 10% 할인을 전제로 짠 예산표를 그대로 쓰는가? - 11월 16일 전에 조직 모델 정책에서 Claude Opus 5.5·GPT-6 Astra·GPT-6.1 Sol·GPT-6 Luna 네 모델의 허용 여부를 한 표로 확인했는가?
- HydraFusion 결과가 이상할 때
/collect-debug-logs아카이브를 첨부하도록 신고 절차에 적혀 있는가?
안 되는 경우
- HydraFusion은 Copilot Pro·Pro+·Business·Enterprise에서 실험·프리뷰 기능을 켠 사용자에게만 열린다. 프리뷰 기능을 막아 둔 조직에는 아직 해당하지 않는다.
- 작업 트리를 건드리지 않는 질의응답이나 Single 패턴으로 끝난 요청에서는 diff 대조로 얻는 것이 적다.
- 소스가 밝히지 않은 것: 풀의 일부 모델만 막았을 때의 동작, 패턴별 평균 크레딧, 데이터 보존과 학습 사용 여부. 문서는 풀 전체가 막힌 경우만 설명한다.
- ThinkingBox 수치는 합성 업무 과제와 12개 모델로 잰 값이며, HydraFusion을 직접 측정하지 않았다.
이번 주에 바꿀 것은 PR 템플릿의 한 줄이다. "응답에 없는 변경 파일이 diff에 있는가"를 넣으면 패스가 여러 번 도는 다른 에이전트 세션에도 같은 기준이 걸린다. 에이전트 검토 절차를 팀 규칙으로 옮기다 막혔다면 그 지점부터 같이 점검해 볼 수 있다.