GitHub Copilot Fusion, 노력 수준은 어떻게 동작하나?

GitHub Copilot Fusion은 2026년 10월 28일 정식 출시된 모델 라우터이자 오케스트레이터다. 사용자가 모델 하나를 고르는 대신 Fusion과 노력 수준(표준, 높음, 최대)을 고르면, 프롬프트마다 어떤 모델이 처리할지 코파일럿이 정한다. 요금은 모델마다 표준 요금으로 낸다 ^[1]. Fusion은 기존 자동 선택 옵션을 대체하며 모든 코파일럿 사용자에게 차례로 배포되고 있다 ^[7].

GitHub Copilot Fusion은 무엇인가?

Fusion은 작업마다 사용자가 모델을 고르게 하지 않고, 프롬프트 단위로 코파일럿이 모델을 배정하고 조율하게 하는 모델 선택지다 ^[1]. 깃허브는 HydraFusion 프로젝트의 다중 모델 오케스트레이션과 코파일럿 자동 모드가 이미 쓰던 모델 선택 방식을 합쳐 Fusion을 만들었다. 공식 문서는 Fusion을 "지능형 런타임 모델 라우터이자 오케스트레이터"라고 부르고, 실시간 시스템 상태와 모델 가용성도 함께 따진다고 설명한다 ^[3].

바탕이 된 연구 프리뷰는 2026년 9월 4일 공개된 HydraFusion 프로젝트다. 이 프로젝트는 여러 회사의 모델로 초안을 쓰고, 비평하고, 고쳐 쓰거나, 더 강한 모델로 작업을 올리는 런타임 오케스트레이션을 더했다 ^[6]. Fusion은 이 작업을 정식 기능으로 내놓은 형태다. 프리뷰에서 자동, HydraFusion, HydraFusion 최대를 골랐던 사용자는 대응하는 Fusion 노력 수준으로 자동으로 옮겨진다 ^[1].

Copilot Fusion은 프롬프트를 어떻게 배정하나?

Fusion은 프롬프트마다 노력 수준에 맞는 모델 묶음과 세 가지 실행 패턴 중 하나를 고른다. 그래서 한 세션 안에서도 패턴이 섞일 수 있다 ^[3]. 패턴은 다음과 같다.

• 단일(Single): 모델 하나가 작업을 끝낸다.
• 연쇄(Cascade): 가벼운 모델이 초안을 쓰고, 심판 모델이 초안을 받아들이거나 더 강한 모델로 작업을 올린다.
• 비평(Critique): 모델 하나가 초안을 쓰면 여러 모델이 동시에 비평하고, 의견을 모은 뒤 처음 모델이 초안을 고친다.

검토 호출은 작업에 꼭 필요할 때만 붙고, 연쇄와 비평 패턴은 단일 패턴보다 시간이 더 걸린다 ^[3]. 중간 초안은 버려질 수 있어 사용자에게는 최종 응답만 보인다. 다만 진행 상황을 따라가며 단계마다 어느 모델이 돌고 있는지 볼 수 있다. 응답을 만든 모델을 확인하려면 응답 아래의 노력 수준 이름 위에 마우스를 올리면 된다.

Fusion은 토큰 비용도 줄이려 한다. 캐시 경계에 맞춰 배정하고, 가능하면 주 대화를 모델 하나에 유지해 캐시된 토큰이 계속 유효하게 하며, 검토 모델에는 꼭 필요한 컨텍스트만 넘긴다 ^[3]. HydraFusion 프리뷰에서는 검토 모델이 툴 없는 컨텍스트에서 돌아 저장소를 바꿀 수 없었고, 워크플로가 취소되거나 검증에 실패하면 패치를 적용하지 않았다 ^[6]. Fusion 문서에는 이 두 가지 보장이 다시 적혀 있지 않다.

노력 수준은 무엇을 골라야 하나?

평소 작업은 표준(Standard)으로 시작하고, 깊은 추론이 필요한 작업에만 높음(High)이나 최대(Max)로 올리면 된다. 문서는 각 수준을 이렇게 설명한다 ^[3].

깃허브가 앞세운 수치는 최대 수준의 결과다. Artificial Analysis Coding Agent Index에서 Fusion 최대 수준은 60점을 받아 Opus 5.5 Max를 쓴 Claude Code와 2점 안쪽 차이를 냈다. 작업당 평균 API 비용은 절반 정도, 토큰도 절반 정도였고, 작업당 시간은 약 40% 짧았다 ^[1]. 다만 깃허브가 직접 발표한 벤치마크 하나의 결과이고, 각자의 저장소와 프롬프트에서는 결과가 다를 수 있다.

플랜에 따라 쓸 수 있는 수준도 다르다. 표준 수준은 모든 플랜에 들어 있지만, 높음과 최대 수준은 일부 하위 플랜에 포함되지 않는다 ^[3].

Copilot Fusion 요금은 어떻게 매기나?

Fusion 자체에 붙는 요금은 없다. Fusion이 쓴 모델마다 해당 모델의 표준 요금이 청구된다 ^[1]. 높음과 최대 수준은 작업 하나에 여러 모델을 부를 수 있어서, 같은 작업이라도 표준 수준보다 AI 크레딧을 더 쓸 수 있다 ^[3]. 2026년 11월 30일까지는 유료 코파일럿 플랜이 Fusion을 쓸 때 모델 비용을 30% 할인받는다.

관리자는 Copilot Fusion을 어떻게 관리하나?

관리자는 이미 쓰던 모델 정책에 더해, Fusion 전용 모델 목록과 기본 노력 수준을 정하는 관리형 설정으로 Fusion을 다룬다. Fusion은 엔터프라이즈와 조직의 모델 정책에서 켜진 모델만 쓰고, 관리자는 특정 모델을 모든 사용자에게 끄지 않고 Fusion에서만 끌 수 있다 ^[1]. 사용자 플랜에 없는 모델이나 데이터 상주, FedRAMP, 평가용 모델 정책으로 빠진 모델도 Fusion은 건너뛴다. 사용자가 쓸 수 있는 모델이 하나도 없으면 모델 선택 목록에 Fusion이 나타나지 않는다 ^[3].

엔터프라이즈에서 Fusion이 쓸 모델을 고르는 순서는 다음과 같다 ^[5].

1. 깃허브 웹사이트에서 엔터프라이즈를 열고 페이지 위쪽의 AI controls를 누른다.
2. 사이드바에서 Copilot을 고른다.
3. Models 아래의 Configure Copilot Fusion models를 누른다.
4. 목록의 모델마다 상태를 정한다.

여기서 켠 모델이라도 다른 모델 정책이 해당 사용자에게 허용해야 실제로 쓰인다 ^[5].

Fusion을 기본값으로 만들려면 엔터프라이즈 관리형 설정에서 model을 fusion으로 두고, fusionTier를 standard, high, max, unmanaged 중 하나로 정한다 ^[4]. unmanaged가 아닌 값은 노력 수준을 고정해 사용자나 저장소가 바꿀 수 없게 한다. 값을 overridable로 감싸면 엔터프라이즈 팀이 자기 설정 파일에서 바꿀 수 있는 기본값이 된다.

{
  "model": "fusion",
  "fusionTier": { "overridable": "standard" }
}

이 관리형 설정을 쓰려면 코파일럿 CLI 1.0.104-3, VS Code 1.144.0, 코파일럿 앱 1.1.33-4 이상이 필요하다 ^[4].

Copilot Fusion은 로컬 모델로도 배정하나?

실험적 프리뷰로 가능하다. 코파일럿 CLI, 코파일럿 앱, VS Code에서 Fusion은 지원되는 기기 내 모델과 클라우드 모델 사이에서 고를 수 있고, 이 기능은 사용자가 직접 켜야 한다 ^[2]. 지원되는 윈도우 기기에서는 Windows ML 공급자로 MAI Code 1.1 Flash를 내려받아 설정할 수 있다. VS Code에서는 chat.copilot.localModel.enabled 설정으로 기능을 켠 뒤 Fusion에서 표준 수준을 고르면, 코파일럿이 로컬 모델과 클라우드 모델 중에서 고른다.

윈도우 밖에서는 사용자가 직접 설정한 모델로만 배정한다. 코파일럿 CLI는 윈도우, 맥OS, 리눅스에서 수동으로 설정한 모델로 배정하며, 지원 모델은 MAI Code 1.1 Flash와 Qwen3.8 Flash Next다. 모델은 사용자가 직접 띄운 OpenAI 호환 로컬 서버에서 돌린다 ^[2]. 사용자가 자기 키를 연결해 모델을 추가해도 Fusion 대상이 자동으로 되지는 않는다. 로컬 모델은 Fusion 표준 수준에서만 쓸 수 있다 ^[3].

위 경고는 변경 기록에 적힌 내용을 그대로 옮긴 것이다 ^[2]. 데이터 규칙이 엄격한 팀이라면 로컬 라우팅을 격리 수단이 아니라 비용과 지연 시간을 줄이는 선택지로 봐야 한다.

AI 에이전트를 쓰는 팀에는 무엇이 달라지나?

팀 입장에서 Fusion은 모델 선택을 개발자 개인에서 정책으로 옮긴다. Fusion은 모든 코파일럿 플랜에서 VS Code, 코파일럿 앱, 코파일럿 CLI, 젯브레인즈 IDE에 출시됐고 ^[1], 모든 코파일럿 사용자에게 차례로 배포되면서 자동 선택 옵션을 대체한다 ^[7]. 따라서 코딩 에이전트의 답을 만드는 모델은 허용 목록 안에서 프롬프트마다 바뀔 수 있다.

실무에서 할 일은 세 가지다. 먼저 배포가 사용자에게 닿기 전에 Fusion 모델 목록을 검토한다. 평소 허용한 모델이라고 해서 자동 승격 단계에서도 쓰고 싶은 모델은 아닐 수 있다. 다음으로 fusionTier를 고정할지, 팀마다 바꿀 수 있게 둘지 정한다. 마지막으로 할인 기간 동안 높음과 최대 수준의 AI 크레딧 사용량을 지켜보고, 2026년 11월 30일 이후 표준 요금 기준으로 예산을 잡는다.

한계와 남은 질문은?

주요 한계는 문서에 나와 있지만, 일부 세부 사항은 빠져 있다. Fusion은 하위 에이전트와 따로 동작해 하위 에이전트를 띄우지 않는다. 버려진 초안이 만든 파일 수정은 자동으로 되돌려지지 않으므로 커밋 전에 변경 사항을 검토해야 한다 ^[3]. 깃허브는 실행 패턴과 모델 묶음이 앞으로 바뀔 수 있다고도 밝힌다.

문서는 노력 수준마다 어떤 모델이 들어가는지 밝히지 않는다. 그래서 어떤 프롬프트에 어느 모델이 답할지 미리 알 수 없고, 나중에 확인할 수만 있다. 깃허브가 인용한 벤치마크는 지표 하나에서 Fusion 최대 수준을 구성 하나와 비교한 결과다. HydraFusion 결과도 중간 수준 추론으로 돌린 오프라인 실험에서 나왔고, 깃허브 스스로 실제 환경 검증이 더 필요하다고 했다 ^[6]. 끝으로 변경 기록은 다른 클라이언트도 지원할 예정이라고 하면서도 날짜는 밝히지 않는다 ^[1].