Copilot Fusion 선택법: 모델 자동 배정과 코드 수정의 완료를 구분하기

모델 이름 대신 무엇을 맡기는가

GitHub는 2026년 10월 28일 Copilot Fusion을 정식 제공한다고 발표했다. 기존 자동 모델 선택과 HydraFusion의 다중 모델 조정을 결합한 기능이다. VS Code, Copilot 앱, CLI와 JetBrains IDE에서 모델 선택기를 통해 이용한다. Fusion 자체는 모든 Copilot 플랜에 제공되지만, 사용할 모델과 기능 범위는 구독·정책의 영향을 받는다. 정식 제공 발표

변화의 핵심은 가장 좋은 모델 하나를 대신 골라 준다는 데서 끝나지 않는다. 어떤 요청은 한 모델로 처리하고, 어떤 요청은 초안을 검사해 더 강한 모델로 넘기거나 다른 모델의 비평을 받아 고친다. 사용자가 위임하는 것은 모델 선택과 작업 진행 방식이다.

이 글은 10월 30일 확인한 공식 문서에 가상의 버그 수정 사례와 비용 계산을 연결한다. Copilot을 직접 실행하거나 특정 모델의 정답률·속도를 측정한 사용기는 아니다. 목표는 팀에서 어떤 일을 먼저 맡기고, 무엇을 완료 증거로 남길지 정하는 것이다.

노력 수준과 실행 방식을 두 축으로 읽는다

모델 선택기에서 Fusion을 고른 다음 노력 수준을 선택한다. 발표는 Standard를 일상 작업, High를 어려운 작업, Max를 가장 깊은 추론이 필요한 작업에 대응시킨다. 현행 문서는 Standard가 한 모델을 선택한다고 더 구체적으로 설명한다. High·Max는 추가 호출을 포함할 수 있다. 수준을 올린다고 모든 요청에 같은 수의 모델이 붙는다고 해석해서는 안 된다. 노력 수준과 실행 방식

실행 방식	결과가 만들어지는 경로	독자가 구분할 점
Single	한 모델이 처리	추가 모델 검토가 없다는 구조이지 쉬운 과제라는 판정은 아님
Cascade	초안 → 심판의 확인 → 수용 또는 더 강한 모델로 승격	검사 비용은 들고, 승격된 작업은 뒤 단계 비용도 듦
Critique	초안 → 다른 모델들의 비평 → 원래 모델의 수정	최종 작성자와 비평자의 역할이 다름

실행 방식은 Fusion이 요청마다 정한다. 따라서 High와 Cascade, Max와 Critique를 일대일로 대응시키면 안 된다. 공식 개념 문서는 Critique를 여러 모델이 병렬로 비평하고 피드백을 모으는 방식으로 설명한다. 출시 글의 간단한 두 모델 설명을 고정된 모델 수로 읽지 않았다. 현재 작동 설명

필자의 해석으로, 이 구조의 이점은 서로 다른 크기의 업무를 한 세션에서 처리할 때 커질 수 있다. 작은 문구 수정 뒤에 원인 추적이 필요한 버그가 들어오면 사람이 매번 모델을 다시 고르는 부담을 줄일 수 있기 때문이다. 반대로 같은 유형의 짧은 작업을 이미 검증된 고정 모델로 반복하고 있다면, 자동 조정이 꼭 필요한지는 별도 비교가 필요하다.

Fusion은 하위 에이전트(subagent)를 시작하는 기능과도 구분된다. 여러 작업자를 만들어 각자 파일을 수정하게 하는 구성으로 이해하면 작업 소유권을 잘못 설계할 수 있다. 공식 제한 사항

사례: 내보내기 버튼을 고쳤는데 왜 다른 파일도 달라졌을까

가상의 보고서 앱에서 사용자가 내보내기를 누른 뒤 화면을 닫았다가 다시 열면, 이전 요청의 완료 메시지가 새 보고서에 나타난다고 하자. 관련 파일은 화면의 요청 관리, 완료 알림 처리, 회귀 검사 세 곳이다. 이 사례와 아래 전개는 직접 만든 설명용 시나리오이며 Fusion의 실제 실행 기록이 아니다.

처음부터 “버그를 고쳐 줘”라고만 맡기면 무엇을 만족해야 하는지 모호하다. 다음처럼 완료 조건을 먼저 적을 수 있다.

작업: 이전 내보내기 완료가 새 화면에 표시되는 오류 수정
보존: 같은 화면에서 진행한 정상 내보내기는 완료 알림을 유지
차단: 화면을 떠난 이전 요청은 재진입한 화면에 알림을 남기지 않음
실패: 서버 오류는 현재 요청에만 표시하고 재시도를 허용
범위: 요청 식별과 화면 수명주기, 관련 알림·회귀 검사
제외: 서버의 내보내기 형식과 접근 권한 변경
완료 증거: 최종 변경 파일 목록과 각 조건의 검사 결과

가령 첫 초안은 늦게 오는 알림을 모두 꺼서 화면 문제를 가렸다. 이후 비평에서 정상 알림까지 사라진다는 지적을 받아 요청 식별 방식으로 고쳤다고 생각해 보자. 최종 설명은 올바른 새 설계만 이야기할 수 있지만, 알림 파일에 들어간 첫 수정이 남아 있다면 정상 경로는 여전히 깨진다.

이때 중요한 공식 제약이 있다. Fusion이 초안을 버려도 그 초안이 이미 작업 폴더에 가한 파일 수정은 자동으로 되돌리지 않는다. 초안을 거절하는 판단과 파일을 원복하는 동작은 별개다. 작업 폴더 변경에 관한 제한

이 사례에서 검토자는 최종 메시지의 설계 설명만 읽고 끝내면 안 된다. 작업 전 기준점과 비교해 바뀐 파일 전체를 보고, 정상 알림·화면 이탈·재진입·실패 후 재시도 네 경로를 확인한다. 원래 사용자가 수정해 둔 파일이 있다면 그 변경을 함께 기록해야 에이전트가 만든 변경과 구분할 수 있다. 차이가 크다고 작업 폴더 전체를 초기화하는 방법은 기존 작업을 잃을 수 있으므로 적합하지 않다.

완료 판단에는 다음 세 가지를 한 묶음으로 남기는 편이 좋다. 무엇을 고쳤다는 설명, 실제 파일 변경분, 그 변경분에 대해 실행한 검사다. 이 셋이 맞으면 모델이 중간에 어떤 초안을 버렸는지 전부 알지 못해도 결과를 검토할 수 있다. 반대로 검사가 초안 A에 대해서만 실행됐고 이후 B가 파일을 다시 바꿨다면, 그 통과 기록은 최종 상태의 증거가 아니다.

승격이 잦으면 더 싸지만 더 느릴 수도 있다

Cascade의 경제성은 초안에서 끝나는 작업과 뒤 단계까지 가는 작업의 비율에 달려 있다. 아래는 이 관계만 분리한 가상 모형이다. Fusion의 실제 내부 요금식·승격률·벤치마크가 아니다. 모든 요청이 초안과 심판 단계를 거치고, 그중 비율 p가 한 번 승격된다고 가정한다.

가상 비용 점수는 초안 0.2, 심판 0.1, 강한 모델 처리 1.2다. 순차 실행 시간은 각각 2초, 1초, 8초로 둔다. 직접 강한 모델만 쓰는 비교군은 1.2점·8초다. 품질과 도구 사용 범위는 같다고 가정하며 재시도·캐시·대기열·추가 수정·할인은 제외한다.

Cascade 평균 비용 = 0.2 + 0.1 + p × 1.2 = 0.3 + 1.2p
Cascade 평균 시간 = 2 + 1 + p × 8 = 3 + 8p

직접 처리보다 저렴할 조건: p < 0.75
직접 처리보다 빠를 조건:   p < 0.625

가정한 승격 비율	평균 비용 점수	평균 시간	직접 처리 1.2점·8초와 비교
25%	0.60	5.0초	비용과 시간 모두 낮음
70%	1.14	8.6초	비용은 낮지만 시간은 길어짐
90%	1.38	10.2초	비용과 시간 모두 높음

70% 행은 “토큰 비용이 줄었으니 작업도 빨라졌다”가 성립하지 않는 반례다. 두 판단의 경계가 다른 이유는 각 단계의 비용 비율과 시간 비율이 다르기 때문이다. 계산은 Python 유리수 연산으로 검산했고 입력·식·결과를 함께 제공한다.

실제 업무에서 더 중요한 가정은 품질이 같다는 부분이다. 심판이 틀린 초안을 통과시키면 낮은 승격률이 좋은 효율처럼 보일 수 있다. 반대로 추가 검토가 재작업을 줄이면 모델 호출 비용이 조금 높아도 사람이 고치는 시간까지 포함한 비용은 낮아질 수 있다. 따라서 위 경계값을 제품 선택 기준으로 복사하지 말고, 같은 완료 조건을 충족한 작업의 비용과 지연을 비교해야 한다.

GitHub의 현재 문서는 사용된 각 모델의 요율로 청구하며 Fusion 별도 요금은 없다고 설명한다. 유료 플랜의 모델 비용 30% 할인은 2026년 11월 30일까지로 안내돼 있다. 할인 전후 비교는 따로 남겨야 기능의 효율과 일시적인 가격 효과를 구분할 수 있다. 청구 방식과 할인 기간

먼저 확인할 것은 허용 모델과 관측 가능한 결과다

팀 도입에서는 설정 이름이 같아도 허용 모델이 다를 수 있다. 관리자는 AI controls → Copilot → Models → Configure Copilot Fusion models에서 Fusion 후보 모델을 설정한다. 여기서 허용해도 다른 모델 접근 정책이 해당 사용자를 막으면 사용할 수 없다. 기업의 Fusion 모델 설정

따라서 팀 비교표에는 노력 수준뿐 아니라 클라이언트·구독·허용 모델 조건과 확인 날짜를 적는다. 한 팀의 High와 다른 팀의 High를 이름만 보고 같은 실험군으로 묶지 않는다. 공식 문서는 응답 아래 노력 수준 이름에 포인터를 올려 사용 모델 목록을 확인하는 경로를 안내한다. 이는 공식 UI 설명이며 이 글에서 실제 화면·모바일 동작을 확인한 결과는 아니다. 진행·사용 모델 표시

지원된다면 관측된 모델·단계 정보를 기록하되, 보이지 않은 중간 초안을 추정해 채우지 않는다. 최종 응답 하나가 왔다고 호출도 한 번이었다고 세어서도 안 된다. 사용량 보고서를 보는 팀은 Copilot 지표의 집계 단위를 함께 확인할 수 있다.

로컬 모델 연동은 별도의 선택이다. 같은 날 발표된 로컬 자동 선택은 실험적 프리뷰이며 Standard에서 지원 모델을 로컬·클라우드 사이에 배정한다. 임의의 BYOK 모델을 추가했다고 Fusion 후보가 되는 것은 아니고, 라우팅 판단은 클라우드에서 이루어진다. 로컬 추론을 선택할 수 있다는 사실을 세션 전체의 오프라인 실행으로 해석하면 안 된다. 이 글의 비교는 로컬 설치를 전제로 하지 않는다. 로컬 자동 선택의 범위

팀의 첫 비교는 완료 조건이 선명한 작업으로 시작한다

앞의 내보내기 오류처럼 영향 범위와 정상 동작을 설명할 수 있는 과제를 골라, 고정 모델 또는 현재 사용 방식과 Fusion을 비교하는 것이 이 글의 제안이다. 이때 동일한 시작 버전과 요청문을 쓰고, 각 실행은 서로의 변경을 물려받지 않는 별도 복사본에서 시작한다. 한 번 잘된 결과만 뽑지 말고 실패·중단한 시도도 기록한다.

처음부터 작업 전체를 Max로 바꾸기보다 일상 수정은 Standard, 여러 파일을 건드리는 한정된 버그는 High를 후보로 놓을 수 있다. 더 어려운 원인 추적에 Max가 도움이 되는지는 별도 작업군에서 판단한다. 이는 도입을 위한 가설이지 측정으로 입증한 추천 순위가 아니다. 조직에서 허용하지 않는 수준은 비교 대상에서 제외한다.

비교할 항목	남길 기록	판단에 쓰는 이유
작업의 동일성	시작 버전·요청·완료 조건	쉬운 작업 비중이 늘어난 효과를 분리
최종 상태	전체 변경 파일·최종 검사·빠진 조건	마지막 설명과 실제 패치의 일치 확인
전체 소모	실패 포함 비용·대기·사람의 수정 시간	성공한 시도만 골라 비용을 낮춰 보이지 않기
결과의 분모	시도 수·조건 충족 수·보류 수	요청 수를 완료 업무 수와 혼동하지 않기

비용 비교는 모든 시도의 모델 비용 합계 ÷ 완료 조건을 충족한 작업 수부터 볼 수 있다. 완료가 0이면 비율을 만들지 않고 실패로 남긴다. 사람의 검토·재작업 시간은 별도 열로 기록해, 필요한 경우에만 합의한 시간 단가로 환산한다. 긴 대기를 감추지 않도록 개별 완료 시간도 보존한다.

재사용할 수 있는 작업 비교 기록지에 위 사례와 빈 기록 칸을 담았다. 값이 채워지기 전까지 승자는 미정이다. 중요한 회귀가 생기면 해당 작업군의 확대를 멈추고, 기존 방식으로 돌아갈 수 있게 시작 버전과 변경 범위를 보존한다.

모델 배정의 자동화는 개발자의 판단을 없애기보다 판단의 위치를 옮긴다. 어떤 모델 이름을 클릭할지 고민하는 시간이 줄어든다면, 그 시간을 작업의 완료 조건과 최종 패치 검토에 쓸 수 있다. 그 전환이 실제로 유용했는지는 같은 업무를 끝낸 기록으로 확인할 수 있다.

호출별 입력·캐시가 비용을 바꾸는 원리는 추론 비용과 캐시 분석에서 이어 읽을 수 있다. 기록지를 다음 도입 검토 때 찾으려면 상단 저장 기능을, 다른 개발 도구 분석을 보려면 소프트웨어 모음과 RSS를 이용하면 된다.