Copilot Fusion GA: ‘절반의 비용’을 우리 작업에서 검증하는 방법

저렴한 모델로 초안을 쓰고 비싼 모델로 검토하면 항상 비용이 줄까요? 초안 대부분이 재작업으로 넘어가면 두 모델의 요금을 모두 지불할 수 있습니다. Copilot Fusion을 평가할 때는 이 승격 비율을 포함한 전체 작업 비용을 봐야 합니다.

10월 28일 GA 발표에서 GitHub는 Fusion Max의 Artificial Analysis Coding Agent Index 점수가 60이며, Claude Code의 Opus 5.5 Max와 2점 이내라고 보고했습니다. 평균 작업당 API 비용과 토큰은 약 절반, 시간은 약 40% 적었다는 비교입니다. 이는 GitHub가 보고한 해당 평가의 결과이며, CodeBridge의 재현 실험이나 모든 저장소에 적용되는 절감률은 아닙니다.

모델 선택이 실행 정책 선택으로 바뀐다

Fusion 문서의 세 패턴을 작업 비용 관점에서 읽으면 다음과 같습니다.

사용자가 모델과 패턴을 매 단계 고정하는 기능으로 이해하면 어긋납니다. 선택한 effort와 작업에 따라 런타임이 구성하며, 조직의 모델 정책도 후보에 영향을 줍니다. 따라서 비교 기록에는 “Fusion”만 적기보다 effort, 클라이언트 버전, 관찰된 모델과 패턴을 남기는 편이 낫습니다.

서로 다른 모델의 검토도 독립적인 정답 판정은 아닙니다. 같은 누락된 요구사항을 공유하면 둘 다 같은 오류를 놓칠 수 있습니다. 검토를 추가한 구성의 가치는 외부 테스트나 사람이 확인한 요구사항으로 판단해야 합니다.

승격 비율 하나로 뒤집히는 비용

다음 금액은 모두 가상의 교육용 입력값입니다. 현재 모델 요금이 아닙니다. Node.js 18 이상에서 패키지·키 없이 실행할 수 있으며, 아래 계산 코드는 로컬에서 실행했습니다. 모델 호출은 없습니다.

const draft = 0.20, judge = 0.05, repair = 1.00;
for (const escalation of [0.10, 0.80]) {
  const expected = draft + judge + escalation * repair;
  console.log(`escalation=${escalation.toFixed(2)} expected_usd=${expected.toFixed(2)}`);
}
const attempts = [{ cost: 0.35, ok: true }, { cost: 0.35, ok: false }];
console.log(`cost_per_success_usd=${(attempts.reduce((n, r) => n + r.cost, 0) / attempts.filter(r => r.ok).length).toFixed(2)}`);

escalation=0.10 expected_usd=0.35
escalation=0.80 expected_usd=1.05
cost_per_success_usd=0.70

이 단순 모형에서 강한 모델을 처음부터 쓰는 비용을 1달러로 가정하면, 승격 비율 10%는 유리하지만 80%는 오히려 비쌉니다. 두 시도가 각각 0.35달러이고 하나만 성공했다면 성공 건당 비용은 0.70달러입니다. 실패한 시도를 분모와 함께 버리면 그 비용을 숨기게 됩니다.

이 가정의 손익분기점은 승격 비율 75%입니다. 0.20 + 0.05 + p × 1.00 < 1.00을 풀면 p < 0.75이기 때문입니다. 비용 조건만 충족해도 성공률이 낮아지면 성공 건당 비용은 커질 수 있으므로 품질 조건을 함께 걸어야 합니다.

실제 계산에는 캐시, 여러 검토자, 재시도, 도구 실행 시간, 사람의 수정 시간이 추가됩니다. 위 예제는 이 요소를 모델링하지 않습니다. 예측 청구서로 쓰기보다, 어떤 이벤트를 로그에 남길지 결정하는 데 쓰세요. 성공이 0건이면 이 지표를 0달러로 표시하지 말고 산출 불가로 처리해야 합니다.

같은 작업을 비교하려면 시작 상태도 같아야 한다

작은 버그 수정, 여러 파일 리팩터링, 설명만 필요한 질문을 나누고 고정 모델과 Fusion을 비교하세요. 모든 작업은 같은 커밋의 독립된 작업 디렉터리에서 시작해야 합니다. 앞선 실행이 만든 수정이나 캐시 조건을 다음 실행에 무심코 넘기면 비교 대상이 달라집니다.

실행 순서를 번갈아 배치하고 여러 번 반복하면 시간대와 일시적인 서비스 상태의 영향을 줄일 수 있습니다. 표본이 작으면 작업별 결과도 함께 공개하세요. 평균 하나로 가장 어려운 작업의 퇴행을 가리지 않는 편이 좋습니다.

문서상 폐기된 초안이 이미 바꾼 파일은 자동 복구되지 않습니다. 격리된 브랜치와 diff 검토가 필요한 이유입니다. 이 글에서는 Copilot 실행이나 위 비교 실험을 수행하지 않았습니다.

할인과 구조적 효율을 나눠 판단한다

사용한 모델별 표준 요금이 합산됩니다. 10월 29일 확인한 공식 문서에는 유료 플랜의 Fusion 모델 비용에 2026년 11월 30일까지 30% 할인이 안내되어 있습니다. 할인 적용 청구액과 할인 전 비용을 따로 기록해야 프로모션 종료 후에도 비교가 유효합니다. 벤치마크의 “절반”에 할인을 다시 곱해 최종 절감률을 단정할 수는 없습니다.

이전 HydraFusion 글은 프리뷰 당시의 설명입니다. 새 GA의 도입 기준은 이름이나 과거 숫자가 아니라 우리 작업에서 품질을 유지하면서 실패까지 포함한 비용이 줄었는가입니다. 짧은 대화라면 체감 지연, 오래 맡기는 수정 작업이라면 검증된 완료 건수에 무게를 두세요.

Copilot으로 코드를 만들고 테스트하는 기본 작업 흐름을 익히려면 아래 Java·Spring 공개 유료 강의를 참고할 수 있습니다. Fusion 전용 커리큘럼을 의미하지 않으며, 링크는 홍보 링크입니다.