GitHub Copilot 12월 모델 종료 예고: 자동 활성화와 워크플로 전환 구분하기

모델 교체에서 접근 권한과 실제 워크플로 전환을 구분한 AI 생성 개념 이미지.

GitHub가 November 13, 2026 공개한 Copilot 모델 종료 예고는 새 모델 출시 소식보다 운영 점검에 가깝다. 핵심은 대체 모델을 사용할 수 있게 되는 것과 기존 작업이 그 모델로 안전하게 옮겨가는 것은 다르다는 점이다. 모델을 고정한 CLI·에이전트 연동이나 조직 정책이 있다면 종료 전에 확인할 항목이 생겼다. 공식 종료 예고

1. 12월 14일 종료 대상과 예외

예고된 종료일은 December 14, 2026이다. Copilot Chat, 인라인 편집, ask·agent 모드, 코드 완성을 포함한 Copilot 경험 전반이 공지 범위다. 모델별 권장 대안은 다음과 같다.

• Claude Fable 5 → Claude Fable 5.2

• Claude Haiku 4.5 → Claude Haiku 5.5

• Gemini 3.8 Flash → Gemini 4 Hydrogen

• Gemini 4 Argon → Gemini 4 Carbon

• Grok 4.6 → Grok 4.7

• Kimi K3 → 아직 발표되지 않음

개인용 Copilot 연간 구독자는 Haiku 4.5 종료 대상에서 제외된다. 이 예외를 다른 모델이나 조직 구독까지 확대해서 해석하면 안 된다. 종료된 모델은 Copilot에서 자동으로 제거되지만, GitHub는 워크플로와 연동을 지원 모델로 미리 변경하라고 안내한다. 공지는 정확한 종료 시각이나 시간대를 명시하지 않았으므로 한국 시간 자정으로 단정하지 않는다. 또한 이는 Copilot의 지원 종료이지, 각 제공사의 직접 API가 같은 날 종료된다는 발표가 아니다. 종료 대상·예외·권장 대안 원문

실무적으로는 마지막 날에 일괄 변경하기보다 담당자와 검증 날짜를 먼저 정하는 편이 낫다. Kimi K3처럼 공식 대안이 없는 경우에는 임의의 모델을 ‘공식 후속 모델’로 적지 말고, 팀이 평가할 후보와 GitHub의 추가 발표를 별도로 관리해야 한다.

2. 자동 활성화는 자동 전환이 아니다

종료 공지는 Business·Enterprise에서 기본 모델 활성화 정책에 따라 대안이 활성화될 수 있다고 설명한다. 그러나 GitHub 문서의 Default availability for released models는 모델 접근 가능 여부를 정하는 정책이며, 사용자의 세션에서 어떤 모델이 기본으로 선택되는지와는 무관하다. 개별 모델을 명시적으로 Enabled 또는 Disabled로 설정했다면 그 설정은 기본 정책을 따르지 않는다. 기본 모델 가용성 정책

따라서 점검을 세 단계로 나누는 것이 안전하다.

1. 접근: 우리 조직과 사용자의 요금제에서 대체 모델을 사용할 수 있는가?

2. 선택: 해당 IDE·CLI·연동이 실제로 어떤 모델을 선택하거나 지정하는가?

3. 동작: 전환 후에도 필요한 도구 호출, 코드 수정, 테스트가 기대한 결과를 내는가?

이는 공식 정책 구분을 바탕으로 한 운영상의 해석이다. 관리 화면에 새 모델이 보인다는 사실만으로 설정 파일의 모델 지정이나 에이전트 동작 검증까지 끝났다고 볼 수는 없다.

3. Fable 5.2는 별도 정책과 데이터 보관 조건 확인

특히 Fable 5에서 5.2로 옮길 때에는 종료 공지의 일반적인 자동 활성화 설명만 읽어서는 부족하다. 현재 기본 가용성 문서는 Fable 5.2를 기본 활성화 대상에서 제외한다. 11월 9일 개별 출시 공지 역시 Business·Enterprise 관리자가 해당 모델 정책을 직접 활성화해야 하며, 기본값은 꺼짐이라고 명시한다. 정책 예외, Fable 5.2 출시·활성화 조건

같은 출시 공지에 따르면 Fable 5.2는 기본적으로 안전 분류기 운영을 위해 Anthropic이 프롬프트와 출력을 보관하며, 이 데이터는 모델 학습에는 쓰이지 않는다. 일부 적격 기업에는 한시적인 무보관 예외가 있지만 자동 적용되는 공통 조건은 아니다. 모델 정책을 켜는 것은 보관 요건을 확인했다는 의미도 갖는다. 따라서 모델 이름만 교체하기 전에 조직의 데이터 처리 기준과 실제 승인 상태를 확인해야 한다. 데이터 보관 및 적격 기업 예외

이 글에서는 일반적인 종료 공지보다 해당 모델의 구체적인 정책 문서를 함께 적용해 해석했다. 모든 권장 대안이 아무 조건 없이 자동 활성화된다고 가정하지 않는 것이 중요하다.

4. 종료 전에 남길 전환 점검 기록

아래는 팀에서 사용할 수 있는 최소 점검안이다. 실제 계정 설정을 변경하거나 유료 모델 호출을 수행한 결과가 아니라, 전환 준비를 위한 제안이다.

• 사용처 목록: 모델을 명시한 CLI 옵션, 에이전트 연동, 팀 공통 템플릿과 IDE 설정을 찾고 소유자를 기록한다. UI의 표시 이름을 연동용 식별자로 그대로 복사하지 말고 해당 도구가 받는 값을 확인한다.

• 접근 조건: 구독 유형, 조직 정책, 클라이언트와 확장 버전을 함께 기록한다. 모델별 지원 클라이언트와 최소 버전이 다를 수 있으므로 웹에서 선택 가능하다는 사실만으로 모든 IDE에서 된다고 판단하지 않는다. 지원 모델과 클라이언트

• 대표 작업 비교: 평소 저장소의 작은 버그 수정, 테스트 추가, 도구 호출이 필요한 작업을 골라 같은 성공 기준으로 비교한다. 통과한 테스트, 의도하지 않은 파일 변경, 재시도 횟수와 사람의 수정량을 남긴다.

• 비용 확인: 기존과 같은 요청 수가 같은 비용을 뜻한다고 가정하지 않는다. 적용 중인 과금 방식과 모델별 조건을 확인하고, 비교 단위는 단순 호출 수보다 완료된 작업 하나로 잡는다. Copilot 모델별 과금 문서

• 복구 경로: 새 모델이 기준을 충족하지 못할 때 사용할 다른 지원 모델과 설정 복구 절차를 정한다. 종료 후 사용할 수 없는 이전 모델을 유일한 복구 대상으로 두지 않는다.

이번 예고에서 먼저 해야 할 일은 모델 순위를 다시 매기는 것이 아니다. 어디서 어떤 모델을 쓰는지, 누가 접근을 승인하는지, 무엇을 통과해야 전환 완료로 볼지를 연결하는 것이다. 자동 활성화는 그중 접근 단계만 해결할 수 있다.