로컬 모델을 연결했는데 Fusion이 안 고른다면: Copilot CLI·앱의 자동 라우팅 자격표

로컬 서버를 연결했고 모델 목록에도 이름이 보인다. 그런데 Copilot Fusion은 계속 클라우드 모델을 선택한다. 이때 메모리를 늘리거나 다른 모델을 내려받기 전에 먼저 볼 것은 속도가 아니라 자격이다. 연결 성공은 서버에 접근할 수 있다는 뜻이지, Fusion 자동 라우팅 후보로 인정됐다는 뜻은 아니다.

GitHub의 2026년 10월 28일 발표는 로컬 모델 지능형 라우팅을 사용자가 켜는 실험적 프리뷰로 소개한다. Fusion 전체의 일반 제공 상태를 이 기능에 그대로 적용하면 안 된다. 또한 자동 선택이 가능하다는 말은 매 요청에서 반드시 로컬 모델을 쓴다는 보장이 아니다. 이 글은 10월 29일 확보한 공식 근거를 기준으로, 같은 모델도 CLI와 앱에서 왜 다른 판단을 받는지 정리한다. 공식 발표: 기능 범위와 프리뷰 상태

1. 먼저 클라이언트와 제공자를 같은 행에 놓는다

아래 표의 ‘후보 가능’은 공식 문서가 설명하는 지원 경로라는 뜻이다. 실제 설치 성공이나 해당 요청에서의 선택을 관찰했다는 뜻은 아니다. ‘범위 밖’은 서버 고장이라는 판정이 아니라, 발표가 자동 라우팅 대상으로 명시한 경로가 아니라는 의미다.

사용하는 곳	운영체제·제공 경로	직접 선택과 자동 라우팅의 구분	먼저 할 판단
Copilot CLI	지원 Windows 기기, Windows ML 관리형 MAI Code 1.1 Flash	준비 후 직접 선택 또는 Fusion Standard의 로컬 후보 가능	실험 기능과 관리형 설정 경로 확인
Copilot CLI	Windows·macOS·Linux, 수동 로컬 OpenAI 호환 서버	발표에 명시된 지원 모델과 제공자 설정을 갖추면 Standard 후보 가능	모델 이름뿐 아니라 지원 제공자·실험 설정 확인
Copilot 앱	지원 Windows 기기, 관리형 Windows ML 모델	현재 앱 지능형 라우팅이 지원하는 경로	제공자와 Local model auto routing 확인
Copilot 앱	호환 로컬 모델을 BYOK로 연결	연결·직접 선택은 가능하지만 그것만으로 자동 라우팅 대상이 되지는 않음	CLI 수동 라우팅 지원을 앱에 대입하지 않기
VS Code	지원 Windows 기기에서 관리형 모델 설정	발표에 별도 활성화 설정이 제시됨	CLI 수동 서버 지원과 동일하다고 추정하지 않기

핵심은 두 번째와 네 번째 행의 차이다. CLI에서 수동 서버로 쓰는 모델이 지원된다는 사실은 앱의 BYOK 자동 라우팅까지 증명하지 않는다. 공식 발표는 앱의 지능형 라우팅을 현재 관리형 Windows ML 모델로 한정한다. VS Code 역시 자체 설정이 있으므로 ‘Copilot이니까 모두 같다’는 판단을 피해야 한다. 발표: Bring your own local model

그림 1. 연결과 자동 후보 자격은 다르다. CLI의 수동 서버 지원을 앱의 자동 선택에 확장하지 않는다. 공식 발표의 경로를 비교한 자체 도식이다. 출처: github.blog/changelog/2026-10-28-github-copilot-fusion-now-supports-selection-of-local-models.

2. 모델 발견, 후보 자격, 실제 선택은 서로 다른 단계다

발표가 수동 CLI 설정 대상으로 이름을 든 것은 MAI Code 1.1 Flash와 Qwen3.8 Flash Next다. OpenAI 호환 서버라는 통신 형식을 맞췄다고 해서 임의의 모델이 모두 자동 라우팅 대상이 되는 것은 아니다. 사용자가 모델 다운로드와 추론 런타임을 관리하며, 기기에 이를 실행할 자원이 있어야 한다. 발표 본문에는 여기서 일반화할 최소 메모리나 속도 보장이 제시되지 않는다.

공식 Fusion 문서는 CLI가 Qwen 모델을 qwen3.8-flash-next-local로 식별하는 조건도 설명한다. 이 문자열은 문서상의 정확한 식별자이지, 모든 로컬 모델에 붙이면 자격을 얻는 별칭이 아니다. 모델의 버전인 1.1과 3.8도 처리 속도나 성능 배수가 아니다. 지원 모델 여부를 먼저 보고, 식별과 제공자 구성을 다음으로 봐야 한다. 문서: Selecting local models in Copilot Fusion

이를 세 단계로 나누면 진단이 쉬워진다. 첫째는 연결·발견이다. 둘째는 해당 클라이언트에서 지원되는 제공자와 모델인가 하는 자격이다. 셋째는 실험 기능과 Fusion Standard 설정을 갖춘 뒤 실제 요청에 어떤 모델이 선택되는가다. 앞 단계가 성공해도 뒤 단계가 자동으로 증명되지는 않는다. 특히 자격이 있는 후보가 클라우드 대신 선택될지는 작업 적합성에 달려 있다. 이 순서는 제품 내부 알고리즘을 재현한 것이 아니라 공식 조건을 진단 순서로 재구성한 편집상 분석이다.

그림 2. 모델이 보이는지, 지원 후보인지, 해당 요청에서 선택됐는지를 따로 판단한다. 제품 내부 로직이 아니라 출처 기반 진단 순서다. 출처: github.blog/changelog/2026-10-28-github-copilot-fusion-now-supports-selection-of-local-models.

3. CLI와 앱에서 실제로 확인할 항목을 분리한다

CLI는 공식 문서에 따라 --experimental로 시작하거나 대화형 세션에서 /experimental on을 사용해 실험 기능을 활성화한다. Windows 관리형 경로는 /model의 설정 안내를 따른다. 수동 서버 경로에서는 지원되는 로컬 모델 제공자로 설정했는지 먼저 확인한다. 어느 쪽이든 로컬 후보를 쓰는 노력 수준은 Fusion Standard다. High나 Max가 더 높은 단계라는 이유로 로컬 라우팅까지 더 넓게 지원한다고 추론해서는 안 된다. 문서: 실험 기능 활성화와 Standard 조건

앱의 관리형 Windows 경로는 Settings > Model providers에서 Windows ML 제공자를 구성하고, Settings > Experiments에서 Local model auto routing을 켠 다음 새 세션을 시작하는 순서다. Windows ML local models가 Windows에서 기본 활성화된다는 설명과, 로컬 자동 라우팅의 실험 설정은 구분해 읽어야 한다. VS Code에는 chat.copilot.localModel.enabled라는 별도 설정이 제시된다. 이 설정 이름을 앱이나 CLI에 그대로 입력하는 방식은 이 글의 안내가 아니다. 발표: Managed download and setup on Windows

예를 들어 macOS에서 Qwen3.8 Flash Next 서버가 준비돼 있다고 가정하자. CLI라면 공식적으로 설명된 수동 모델 경로와 식별자, 실험 기능, Standard를 확인할 수 있다. 반면 앱에 같은 서버를 연결했다는 사실만으로는 앱 자동 라우팅의 지원 범위를 넓힐 수 없다. 이 비교는 가상의 진단 사례이며, 이 환경에서 두 제품을 실행해 얻은 측정 결과가 아니다. 표에서 범위가 다르다면 재설치보다 경로 선택을 먼저 바꾸는 것이 이 글의 제안이다.

그림 3. 같은 서버도 클라이언트 지원 범위가 다르면 자동 후보 판단이 달라진다. 공식 조건으로 만든 가정이며 실제 제품 비교 실험은 아니다. 출처: github.blog/changelog/2026-10-28-github-copilot-fusion-now-supports-selection-of-local-models.

4. 자격이 맞아도 선택 보장과 오프라인 보장은 남지 않는다

자격을 확인한 다음에는 구독과 관리자 정책을 확인한다. 공식 문서는 Fusion이 구독과 정책에 따라 사용할 수 있는 모델에서 선택하며, 제한된 모델은 포함하지 않는다고 설명한다. 다만 이 설명만으로 독자의 조직 정책이 현재 무엇인지 판단할 수는 없다. 실제 정책을 확인하지 않은 상태에서 모든 미선택을 관리자 차단으로 단정하거나, 반대로 정책과 무관하다고 단정하지 않는 편이 맞다. 문서: Policies and availability

로컬 추론도 세션 전체의 오프라인 실행을 뜻하지 않는다. 발표는 Fusion의 라우팅 결정이 여전히 클라우드에서 이뤄진다고 명시한다. 그렇다고 정확히 어떤 필드가 전송되는지, 전체 프롬프트가 항상 전송되는지까지 이 발표로 단정할 수는 없다. 데이터 반출이 없는 환경을 요구한다면 ‘모델이 로컬’이라는 표시만으로 승인하지 말고 별도의 데이터 흐름 근거가 필요하다. 로컬 모델의 안전 보호가 Copilot 제공 클라우드 모델과 다를 수 있다는 경계도 유지해야 한다. 발표: 로컬 추론의 한계

그림 4. 추론 위치와 라우팅 결정 위치를 분리해서 읽는다. 정확한 전송 데이터 구조나 무반출을 검증한 그림은 아니다. 출처: github.blog/changelog/2026-10-28-github-copilot-fusion-now-supports-selection-of-local-models.

비용 역시 실측 없이 결론 내릴 부분이 아니다. 문서는 Fusion이 사용한 모델별 표준 요율로 과금한다고 설명하지만, 여기서는 로컬과 클라우드의 같은 작업 비용·전력·대기 시간을 측정하지 않았다. 따라서 로컬 연결만으로 전부 무료, 일정 비율 절감, 더 빠른 응답을 약속하지 않는다. 기한이 있는 할인율도 이 자격표의 판단 근거에서 제외했다. 문서: Billing for Copilot Fusion

5. 다음 행동은 더 큰 모델이 아니라 맞는 경로를 고르는 일이다

모델이 안 골린다는 현상을 기록할 때는 ‘앱 이름, 운영체제, 제공자, 정확한 모델 식별, 실험 기능, 노력 수준’을 한 묶음으로 남기면 좋다. 연결 실패와 자동 라우팅 자격 부재를 구분할 수 있고, 이미 후보 자격이 있는 경우에는 실제 요청의 선택 결과를 별도로 볼 수 있다. 이는 원인 확정 로그가 아니라 다음 확인 대상을 좁히기 위한 기록 양식이다.

이 글은 공식 발표와 문서를 대조한 자격표이며, 모델 설치·추론·제품 화면 실행을 직접 검증한 결과가 아니다. 지원 기기의 실제 자원 요구량, 동일 작업의 지연·비용, 라우팅 요청의 상세 데이터 구성은 여기서 미확인이다. 문서의 일반적인 설명이 앱 지원 범위를 넓혀 보이더라도, 이 글은 출시 발표의 명시적 Windows ML 경계를 우선했다. 실험적 프리뷰와 모델 풀은 바뀔 수 있으므로 실제 도입 때는 아래 같은 공식 출처의 해당 절을 다시 확인해야 한다.

결론은 간단하다. 로컬 연결은 출발점이고 자동 라우팅은 별도의 자격 판단이다. CLI의 수동 로컬 경로와 앱의 관리형 Windows 경로를 분리하면, 지원 범위 문제를 성능 문제로 오해해 하드웨어나 설치 작업부터 늘리는 일을 피할 수 있다.

출처와 검증 범위

• GitHub Changelog, 2026-10-28 — 로컬 모델 라우팅 출시 발표: 실험적 프리뷰, 클라이언트별 경로, 지원 모델, 앱의 제한, 클라우드 라우팅 경계.
• GitHub Docs — About GitHub Copilot Fusion: Selecting local models, 실험 활성화, 식별자, 정책과 과금. 변동 문서이며 2026-10-29 확보본에 근거했다.

표와 그림은 위 근거를 새로 구성한 설명용 분석이다. 제품 스크린샷·성능 실험·독립 재현이 아니다.