Huny's Dev Blog
huny.dev

GitHub Universe 2026 키노트 해부: Copilot Fusion 멀티모델 라우팅과 초당 7,200회 쓰기를 버티는 새 Git 아키텍처

GitHub Universe 2026 오프닝 키노트에서 발표된 Copilot Fusion 멀티모델 오케스트레이션과 에이전트 시대를 위한 새 Git 인프라 아키텍처를 정리한다. Single·Cascade·Critique 실행 패턴과 초당 7,200회 쓰기를 처리하는 스토리지 분리 설계를 살펴본다.

Hun Jang
Hun Jang Oct 29, 2026

GitHub가 공개한 GitHub Universe 2026 오프닝 키노트 영상과 공식 키노트 요약 포스트는 수십~수백 개의 에이전트가 동시에 코드를 작성하고 푸시하는 시대에 맞춰 개발 도구와 기반 Git 인프라를 어떻게 재설계했는지를 다룬다. Microsoft CoreAI 총괄 부사장 Jay Parikh는 지난 1년간 GitHub에서 343억 건의 커밋과 13억 건의 풀 리퀘스트(PR)가 발생했으며, 특히 2026년 9월 한 달 동안에만 에이전트와 개발자가 70억 건 이상의 커밋을 기록했다고 밝혔다.

결론부터 말하면, 이번 발표의 핵심은 개발자가 작업마다 개별 모델을 고르는 대신 Copilot Fusion이 작업 난이도에 맞춰 복수의 모델을 조합(Single·Cascade·Critique)하고, 그 아래에서 수천 개의 에이전트가 동시에 푸시해도 병목이 생기지 않도록 Git의 저장소 잠금과 스토리지 구조를 근본적으로 분리한 데 있다. 다만 이 글은 GitHub가 공개한 키노트 발표와 공식 체인지로그 문서를 바탕으로 아키텍처와 주요 기능을 정리한 것이며, 실제 사내 저장소에서 Copilot Fusion의 비용 절감 폭이나 새 Git 인프라의 체감 처리량을 직접 벤치마킹한 결과는 아니다.

단일 모델 선택과 Copilot Fusion 멀티모델 오케스트레이션의 차이

기존에는 개발자가 복잡한 설계를 할 때 고성능 모델을 골랐다가 단순 반복 작업에서도 모델을 다시 바꾸지 않아 불필요한 토큰 비용을 소모하는 일이 잦았다. 정식 출시(GA)된 GitHub Copilot Fusion은 지난 9월 연구 프리뷰로 공개되었던 Project HydraFusion의 멀티모델 오케스트레이션과 자동 모델 선택 기능을 하나로 결합한 시스템이다.

개발자는 특정 모델 이름을 고르는 대신 Fusion Standard(일상적인 코딩), Fusion High(깊은 추론과 까다로운 작업), Fusion Max(최고 난이도 작업) 중 노력 수준(effort level)만 선택한다. 그러면 시스템이 프롬프트의 요구사항(추론, 코드 생성, 디버깅, 도구 호출)을 분석해 세 가지 실행 패턴 중 하나로 모델을 조합한다.

실행 패턴
동작 방식
적합한 작업 및 비용·품질 특성
Single
단일 모델이 작업을 처음부터 끝까지 직접 처리
요구사항이 명확하고 단일 모델로 충분한 일상적 구현 작업
Cascade
경량·고효율 모델이 먼저 초안을 작성하고, 품질 검증(quality check)을 통과하지 못할 때만 상위 프론티어 모델로 에스컬레이션
대부분의 하위 단계는 저비용으로 처리하되 어려운 구간에서만 고성능 모델을 호출해 비용 절감
Critique
첫 번째 모델이 초안을 작성하면 두 번째 모델이 이를 리뷰·비평하고, 다시 원래 모델이 피드백을 반영해 수정본 완성
아키텍처 변경이나 복잡한 버그 수정처럼 교차 검증이 필요한 고난도 작업

키노트(10:15 부근)와 공식 발표에 따르면, Copilot Fusion Max는 Artificial Analysis Coding Agent Index에서 60점을 기록해 Claude Code(Opus 5.5 Max)와 2점 이내의 성능을 내면서도, 작업당 평균 API 비용과 토큰 사용량은 약 절반(50%)으로 줄이고 소요 시간은 40% 단축했다.

멀티 리포지토리 조율(Projects)과 지침 자동 정리(Dreaming)

에이전트 수가 늘어나면 개별 에이전트 루프를 일일이 감독하는 자체가 새로운 병목이 된다. 이를 줄이기 위해 GitHub Copilot 앱 업데이트와 함께 여러 계층의 오케스트레이션 및 품질 관리 기능이 추가되었다.

  • Copilot Projects (공개 프리뷰): 단일 저장소에 묶이지 않고 여러 리포지토리와 Slack 스레드, Figma 디자인 목업, 법무 검토 문서 등을 하나의 프로젝트 컨텍스트로 묶는다. 개발자가 목표를 지시하면 오케스트레이터가 백그라운드에서 저장소별로 필요한 수만큼 서브 에이전트를 병렬 실행해 각각의 PR을 생성한다.
  • Copilot Dreaming: 코드베이스가 진화하면 3주 전에 작성해 둔 에이전트용 커스텀 지침(instructions)이 오히려 잘못된 코드를 유도하는 부채가 된다. 키노트 데모(12:36 부근)에서는 기존 Java 기반 애플리케이션을 SvelteKit으로 재작성하자, Copilot Dreaming이 변경된 코드베이스와 팀 선호도(memories)를 바탕으로 오래된 지침 파일을 정리하는 PR을 자동으로 생성하는 흐름을 보여주었다.
  • Copilot Code Review Max 및 Agent Merge: 에이전트가 쏟아내는 PR의 품질을 통제하기 위해 ReviewBench 고위험(high-severity) 이슈 기준 최고 F1 점수를 기록한 Code Review Max 계층이 추가되었다. 또한 Stacked PRs로 UI·서비스·데이터 변경 PR을 계층화하고, Agent Merge를 통해 백그라운드에서 리뷰 피드백 반영·CI 실패 수정·충돌 해결 후 자동 병합까지 이어지는 구성을 지원한다.

초당 7,200회 쓰기를 버티는 새 Git 아키텍처 해부

키노트 후반부(33:20~38:55)에서 엔지니어링 관점으로 가장 주목할 만한 발표는 에이전트 시대를 위해 밑바닥부터 재설계한 Git 인프라다. 사람이 직접 코드를 푸시하던 시절에는 저장소당 초당 수십 회의 푸시(push)만 처리해도 충분했지만, 수천 개의 코딩 에이전트가 동시에 브랜치를 만들고 히스토리를 읽으며 변경 사항을 푸시하면 기존 Git 아키텍처는 즉시 한계에 부딪힌다.

GitHub 엔지니어링 팀의 April은 기존 병목을 제거하기 위해 적용한 세 가지 아키텍처 변화를 다음과 같이 설명했다.

구분
기존 Git 아키텍처
차세대 에이전트용 Git 아키텍처
쓰기 잠금 범위 (Locking)
매 쓰기(write) 작업마다 저장소 전체(entire repository)를 잠금
업데이트되는 해당 브랜치(branch)만 잠금 (서로 다른 브랜치에서 작업하는 에이전트들이 병렬 진행하여 쓰기 처리량 3~4배 즉시 향상)
스토리지와 컴퓨팅 구조
스토리지와 컴퓨팅이 결합된 상태 유지 서버 중심
스토리지와 컴퓨팅의 완전 분리: 코드 원본(source of truth)은 Azure Blob Storage에 영구 보관하고, 요청을 처리하는 Git 서버는 데이터를 캐시하는 무상태(ephemeral) 노드로 구성해 수요에 따라 즉시 확장
조율 경로 (Coordination)
무거운 전체 참조 및 객체 동기화가 임계 경로에 포함됨
조율 최소화: 아주 작은 참조 트랜잭션(reference transaction)만 임계 경로(critical path)에 남기고, 속도 최적화된 전용 복제 로그 서비스(replicated log service)가 이를 처리

이 아키텍처 위에서 5,000개의 코딩 에이전트를 단일 모노레포(monorepo)에 동시에 투입해 부하 테스트를 진행한 결과, 단일 저장소에서 초당 7,200회의 쓰기(7,200 writes/sec)를 안정적으로 유지했다. 이는 기존 처리 한계 대비 180배에 달하는 수치다. 또한 GitHub에서 가장 바쁜 오픈소스 저장소 중 하나인 OpenClaw의 24시간치 트래픽을 1분으로 압축해 재생했을 때도 지연 없이 처리되었으며, 오는 2027년 초까지 전체 저장소가 새 아키텍처로 마이그레이션될 예정이다.

엔터프라이즈 도입 및 워크플로 적용 시 확인할 점

이번 발표 내용을 실제 조직의 개발 워크플로에 적용할 때는 기능 출시 상태와 과금 구조 변화를 먼저 구분해 두어야 한다.

  • 개별 시트 구독과 종량제 예산(AI Credits)의 구분: 오늘부터 GitHub Enterprise 고객은 별도의 Copilot 구독 라이선스를 추가 구매하지 않아도 전사 개발자에게 Copilot 앱, 코드 리뷰, 자동화 기능을 활성화할 수 있다. 다만 기본 포함 사용량(allowance) 없이 첫 요청부터 기업의 AI 크레딧 예산에서 차감되므로, 예산 소진 시 코드 자동완성은 유지되지만 챗·코드 리뷰·클라우드 에이전트는 중단된다는 점을 고려해 에이전트별 지출 한도를 먼저 설정해야 한다.
  • 조직 모델 정책과 Copilot Fusion 연동 확인: Copilot Fusion은 조직 관리자가 허용한 모델 풀 안에서만 라우팅을 수행한다. 엔터프라이즈 설정에서 어떤 모델이 활성화되어 있는지 확인하고, 오는 11월 말까지 제공되는 유료 플랜 대상 Copilot Fusion 모델 비용 30% 할인 기간에 기존 단일 고정 모델 대비 토큰 효율을 비교해 보는 편이 좋다.
  • 에이전트용 커스텀 지침(Instructions)의 주기적 감사: 코드베이스나 프레임워크가 바뀌었는데도 오래된 AGENTS.md나 커스텀 지침이 남아 있으면 에이전트 품질이 급격히 떨어진다. Copilot Dreaming이나 정기적인 PR 리뷰를 통해 지침 파일도 코드와 똑같이 버전 관리하고 정리하는 규칙을 세워야 한다.

결국 에이전트 기반 개발의 성패는 얼마나 많은 에이전트를 동시에 띄우느냐가 아니라, 모델 라우팅 비용과 코드 리뷰 품질, 그리고 그 아래의 버전 관리 인프라가 늘어나는 변경 속도를 감당할 수 있는가에 달려 있다.

참고 자료

발표 내용과 기능 출시·아키텍처 사양은 October 29, 2026 공개 자료 확인 기준이다.

추천 글