GitHub Copilot Fusion 활용 가이드: 모델 선택부터 비용·도입 판단까지

2026년 10월 29일 기준 GitHub의 공식 문서와 발표 내용을 확인했습니다. 이 글은 문서를 바탕으로 한 분석이며, 직접 실행해 측정한 벤치마크가 아닙니다.

GitHub Copilot Fusion을 쓰면 무엇이 달라지나요?

GitHub Copilot Fusion은 모델 선택을 맡아 처리하고, 필요하면 여러 모델의 작업도 조율합니다. 기술 리더가 변경 사항을 보고 바로 구현할지, 검토자를 붙일지, 더 깊이 다룰지를 판단하는 것과 비슷합니다. 작업을 정의하고 최종 코드의 수용 여부를 결정하는 일은 여전히 사용자의 몫입니다.

GitHub는 2026년 10월 28일 Fusion을 정식 출시하면서 Project HydraFusion의 오케스트레이션과 Auto의 모델 선택 기능을 통합했습니다. 기존의 Auto, HydraFusion, HydraFusion Max 선택 항목은 각각 대응하는 Fusion 추론 수준으로 전환됩니다. 따라서 10월의 연구 프리뷰는 Fusion의 전신이며, Fusion과 함께 별도로 써야 하는 제품이 아닙니다. GitHub의 Fusion 출시 발표.

실행 패턴은 작업을 어떤 순서와 역할로 나누어 처리하는지를 뜻합니다.

• Single: 모델 하나가 작업을 직접 처리합니다.
• Cascade: 초안을 판정 모델에 전달하고, 판정 모델은 이를 수용하거나 더 깊은 처리를 요청합니다.
• Critique: 별도의 비평을 받은 뒤, 초안을 작성한 모델이 내용을 수정합니다.

이 패턴은 GitHub의 HydraFusion 연구에서 나왔습니다. 현재 Fusion 문서는 여러 비평 모델이 병렬로 검토하고 그 피드백을 취합하는 방식을 설명합니다. 그렇다고 모든 프롬프트에서 모든 패턴을 실행한다는 뜻은 아닙니다. Fusion의 동작 방식.

예를 들어, 화면의 문구를 고치는 일과 경쟁 상태를 조사하는 일에 무조건 같은 처리 방식을 적용할 이유는 없습니다. Fusion은 세션 안에서 이 배분을 수행합니다. 기본 원리는 모델 라우터 해설에서 더 넓게 다룹니다. 작업에 알맞은 역량을 연결하고, 그 선택이 실제로 도움이 됐는지 측정하는 방식입니다.

어디에서 사용할 수 있고, 어떻게 켜나요?

Fusion은 Copilot 앱, Visual Studio Code, Copilot CLI, JetBrains IDE에서 사용할 수 있습니다. GitHub는 이들 환경과 Copilot 요금제 전반의 제공 여부를 안내합니다. 다만 모든 계정에서 동일한 추론 수준을 사용할 수 있다는 뜻은 아닙니다. 사용할 수 있는 모델은 여전히 요금제와 정책의 제한을 받습니다. 현재 지원 범위.

아래 절차를 따르기 전에 클라이언트를 업데이트하시기 바랍니다. 예전 HydraFusion 프리뷰를 켜던 설정은 현재 Fusion의 설정 방법과 다릅니다.

GitHub Copilot 앱

프롬프트 입력창 아래의 모델 이름을 클릭한 다음 Copilot Fusion을 켜고, 표시되는 추론 수준 중 하나를 선택합니다. 특정 모델을 직접 선택하는 방식으로 돌아가려면 스위치를 끄고 해당 모델을 고르면 됩니다. 앱은 이후 세션에도 이 선택을 유지합니다. 앱에서 모델 선택하기.

Visual Studio Code

설정에서 chat.copilot.dynamicAutoTiers.enabled가 활성화되어 있는지 확인합니다. Copilot harness를 사용하는 새 채팅을 시작합니다. 하네스는 모델을 에이전트의 툴에 연결하는 실행 환경입니다. 모델 선택 메뉴에서 Copilot Fusion을 선택하고, 사용할 수 있는 단계를 고릅니다. 이 설정 자체가 사용 권한을 부여하지는 않습니다. 계정에 허용된 Fusion 단계가 없으면 선택 메뉴에 계속 Auto가 표시될 수 있습니다. VS Code 설정 방법.

GitHub Copilot CLI

대화형 세션에서 /model을 입력하고 Fusion과 추론 수준을 선택한 뒤 확인합니다. GitHub는 범위를 제한해 처음 시험할 때 쓸 수 있는 다음 명령 형식을 안내합니다. 이 예시는 파일을 수정하지 않고 분석만 요청합니다.

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

현재 Fusion에서 사용하는 옵션이며, 예전 HydraFusion 실험용 플래그는 필요하지 않습니다. CLI에서 모델 선택하기.

Fusion은 어떤 모델을 사용하나요?

이름이 공개된 Claude/GPT 모델 목록은 특정 시점의 기록이며, 앞으로도 그 모델로 라우팅된다는 보장은 아닙니다. GitHub가 2026년 10월 14일 발표한 HydraFusion 업데이트에는 다음 모델이 명시되어 있습니다.

• Anthropic의 Claude Opus 5.5.
• OpenAI의 GPT-6 Astra.
• OpenAI의 GPT-6.1 Sol.
• OpenAI의 GPT-6 Luna.

이 업데이트에서는 HydraFusion Max도 도입했으며, 초안 작성과 검토에 더 깊은 추론을 적용했습니다. 위 목록은 해당 프리뷰 발표에서 확인된 모델명입니다. 10월 모델 목록 업데이트.

현재 Fusion 개요 문서는 고정된 전체 클라우드 모델 목록을 공개하지 않습니다. 모델 구성이 달라질 수 있다고 설명하며, 응답 아래의 추론 수준 표시 위에 마우스를 올리면 실제 사용된 모델을 확인할 수 있도록 합니다. Copilot의 전체 모델 카탈로그에 있는 모든 모델을 Fusion이 사용한다고 받아들여서는 안 됩니다. 현재 모델 구성의 동작 방식.

엔지니어링 리더가 실무에서 확인해야 할 목록은 자기 계정에서 허용된 모델입니다. Enterprise 소유자는 AI controls → Copilot → Models → Configure Copilot Fusion models에서 이를 설정할 수 있습니다. 여기서 선택하더라도 사용자에게 적용되는 다른 모델 정책의 범위를 벗어나지는 않습니다. Enterprise 모델 관리.

로컬 모델 라우팅은 별도의 프리뷰로 제공됩니다. Standard에서 MAI Code 1.1 Flash 또는 Qwen3.8 Flash Next를 사용하는 특정 구성을 지원합니다. 임의의 로컬 모델을 추가한다고 Fusion에서 사용할 수 있게 되는 것은 아닙니다. 로컬에서 추론하더라도 라우팅은 여전히 클라우드에서 처리하므로 Fusion이 오프라인으로 동작하는 것도 아닙니다. 로컬 모델 지원의 범위와 제한.

Standard로 시작하고, 필요할 때 추론 수준을 높이세요

Standard로 시작하되, High나 Max를 고르기 전에 추가 검토가 무엇을 확인해야 하는지 정하시기 바랍니다. GitHub는 Standard를 일상적인 코딩, High를 까다로운 작업과 더 깊은 추론, Max를 가장 어려운 작업에 쓰는 수준으로 설명합니다. 추론 수준별 정의.

다음 작업 예시는 편집 관점의 권장 사항이며, 성능을 측정해 얻은 결론은 아닙니다.

애플리케이션 전체를 개선해 달라는 막연한 요청은 Max를 시험하기에 적합하지 않습니다. 성공 기준을 정하지 않았다면 추가 추론이 도움이 됐는지도 판단할 수 없습니다. 재시도 동작을 유지하면서 중복된 요청 처리 경로를 없애는 것처럼, 결과를 관찰할 수 있는 문제로 범위를 좁히시기 바랍니다.

Fusion Max는 추론 수준의 이름이며, 반드시 가입해야 하는 구독 상품의 이름이 아닙니다. Fusion Fast도 있지만 사용자가 직접 선택할 수 없으며, VS Code 인라인 채팅에서만 쓰입니다. 추론 수준 옵션.

Fusion의 AI 크레딧은 어떻게 계산되나요?

요금은 선택된 모델이 실제로 수행한 작업에 따라 결정됩니다. 입력·출력·캐시된 토큰에 모델별 요율을 적용하고, 해당되는 경우 캐시 쓰기 요금까지 계산한 다음 AI 크레딧으로 환산합니다. Fusion 작업 한 건에 부과되는 고정 크레딧은 공개되어 있지 않습니다. GitHub의 과금 방식.

Fusion에는 별도의 오케스트레이션 요금이 없습니다. 현재 유료 Copilot 요금제에는 2026년 11월 30일까지 Fusion 모델 비용 30% 할인이 적용됩니다. Fusion 과금 안내. 요금제별 구성과 제공량은 GitHub Copilot 가격 가이드에서 다룹니다.

초안 작성, 비평, 수정은 각각 사용량에 반영됩니다. 추론 수준, 컨텍스트 크기, 툴 사용, 캐싱도 소비량에 영향을 줍니다. 따라서 라우팅이 의도대로 작동하더라도 여러 단계를 거치는 실행은 단일 모델 요청보다 크레딧을 더 많이 사용할 수 있습니다. VS Code의 AI 크레딧 소비 설명.

시험할 때는 실패한 시도와 수정을 요구한 프롬프트도 집계하시기 바랍니다. 저렴한 초안을 여러 번 고쳐야 한다면, 한 번에 수용할 만한 변경을 만드는 더 비싼 실행보다 불리할 수 있습니다. 반대로 단순한 이름 변경에 비평 비용까지 지불해도 얻는 것이 없을 수 있습니다. 가장 저렴한 개별 응답보다 최종적으로 완료한 작업을 비교해야 합니다.

GitHub 벤치마크로 알 수 있는 것과 알 수 없는 것

GitHub가 발표한 결과는 유망하지만, 내 저장소에서도 비용이 절감된다는 근거는 아닙니다. GitHub는 Universe 발표에서 다음과 같이 밝혔습니다.

해당 평가는 Artificial Analysis Coding Agent Index입니다. 이는 GitHub가 발표한 벤치마크 주장이며, 이 글을 위해 별도로 수행한 독립적인 테스트가 아닙니다. GitHub Universe 발표.

상세 변경 로그는 비교 대상을 Opus 5.5 Max를 사용하는 Claude Code로 명시하고, 비용 지표를 작업당 평균 API 비용으로 설명합니다. 이는 Fusion을 쓰면 Copilot 청구액이 절반이 된다는 주장보다 범위가 훨씬 구체적입니다. GitHub 벤치마크의 비교 조건.

여기서 합리적으로 추론할 수 있는 점은, 항상 무거운 구성을 선택하는 것보다 오케스트레이션을 통해 높은 품질의 결과를 더 효율적으로 얻을 가능성이 있다는 것입니다. 모든 버그 수정이 더 빠르거나 저렴해진다고 단정할 근거는 없습니다. 실제 효과는 작업의 구성, 수용 기준, 추가 수정량에 달려 있습니다. 한시적인 요금 할인과 벤치마크 비교 역시 별개의 내용이므로, 둘을 합쳐 절감액을 보장해서는 안 됩니다.

개발자, 엔지니어링 리더, 구매 담당자는 무엇을 살펴봐야 하나요?

개발자는 모델을 고르는 수고를 덜 수 있습니다. 다음 작업을 어떤 모델에 맡길지 고민하느라 흐름이 자주 끊긴다면, 범위를 정해 Fusion을 시험해 볼 만합니다. 이슈 설명, 기대 동작, 검토 기준은 명확하게 유지하시기 바랍니다. 모델 선택을 위임하는 목적은 주의를 빼앗기는 일을 줄이는 것이며, 작업의 정의를 느슨하게 만드는 것이 아닙니다.

엔지니어링 리더에게는 추론 수준 선택 기준과 결과 수용 기록이 필요합니다. 일상 작업에는 Standard, 검토가 필요한 한정된 변경에는 High를 쓰고, Max는 이유가 있을 때 의식적으로 선택하는 규칙으로 시작할 수 있습니다. 수준을 높인 것이 왜 도움이 됐는지 기록하시기 바랍니다. 그렇지 않으면 실제로 반영되는 코드가 나아진다는 근거 없이 가장 높은 수준만 고르는 습관이 생길 수 있습니다.

Copilot을 Claude Code나 Cursor와 비교하는 구매 담당자는 실제로 도입할 작업 흐름을 시험해야 합니다. 벤치마크는 후보를 평가해 볼 이유는 되지만, 조직 전체가 도구를 바꿀 근거는 아닙니다. 크레딧뿐 아니라 검토 부담, 저장소와의 적합성, 최종 완료 결과도 함께 평가하시기 바랍니다. 더 넓은 선택 기준은 Claude Code와 GitHub Copilot 비교를 참고할 수 있습니다. Fusion은 그 결정의 한 부분을 바꿉니다.

과장해서 기대하지 말아야 할 점과 꺼두는 편이 나은 경우

여러 모델이 관여하더라도 diff를 확인할 책임은 사라지지 않습니다. GitHub가 문서에 명시한 제한 중 특히 주의할 점이 있습니다. 폐기된 초안도 파일 수정 흔적을 남길 수 있다는 것입니다. 또한 Fusion은 자체적으로 합산된 컨텍스트 창을 제공하지 않으며, 서브에이전트를 실행하지 않습니다. Fusion의 제한 사항.

조건을 통제한 비교, 재현 가능한 조사, 명시적으로 승인된 작업 흐름 때문에 특정 모델이 필요하다면 Fusion을 꺼두시기 바랍니다. 모델을 고정하면 라우팅이 또 하나의 변수가 되는 것을 막을 수 있습니다. 언어 모델의 동작이 결정적으로 바뀌는 것은 아니며, 변동 요인 하나를 제거하는 것입니다.

익숙한 특정 모델 구성이 한정된 작업을 별다른 수정 없이 처리한다면, 시험을 통해 실질적인 이점이 확인되기 전까지는 그대로 사용해도 됩니다. 반드시 전환할 필요는 없습니다.

오프라인 작업 흐름이 필수이거나, 수용할 만한 변경이 무엇인지 정의하고 검토할 수 없는 경우에도 도입을 미루는 편이 좋습니다. 아주 작은 일상 요청이라면 Standard는 유지하면서 오케스트레이션 비중이 큰 추론 수준을 쓰지 않는 쪽이 더 나은 조정일 수 있습니다. “Max를 끄는 것”과 “Fusion을 끄는 것”은 서로 다른 결정입니다.

GitHub Copilot 사용법: 이번 주에는 저장소 하나로 Fusion을 시험하세요

모든 결과를 직접 살펴볼 수 있을 만큼 시험 범위를 작게 유지하시기 바랍니다. 잘 아는 저장소를 고른 다음, Fusion과 현재 사용하는 모델 구성을 비교합니다.

이번 주에 할 일은 해당 저장소를 맡을 개발자와 검토자를 정하고, 수용 기준에 합의한 뒤, 실제 변경 결과를 확인하고 나서 기본 설정을 결정하는 것입니다. 가장 빠른 응답의 스크린샷보다 읽고 이해할 수 있는 의사결정 기록이 더 유용합니다.

AI 개발 툴을 선택하고 운영하는 실용적인 가이드는 뉴스레터를 구독해 받아보실 수 있습니다.