GitHub Copilot 모델 지원 종료에 대비하는 방법: 이름보다 정책을 먼저 고정하기

AI 코딩 도구에서 모델 이름을 프롬프트에 직접 박아 두면 어느 날 같은 작업의 결과가 달라질 수 있습니다. GitHub는 2026년 9월 1일을 기준으로 Copilot의 여러 경험에서 일부 모델을 지원 종료하고 대체 모델을 안내했습니다. 중요한 건 모델 목록 자체보다, 이 변경을 조직 정책과 회귀 검증의 문제로 다루는 것입니다.

이번 지원 종료 대상

GitHub Changelog는 Copilot Chat, 인라인 편집, ask·agent 모드, 코드 자동 완성 등 대부분의 Copilot 경험에서 다음 모델을 지원 종료했다고 설명합니다.

지원 종료 모델	GitHub가 제시한 대체 모델
Gemini 3.1 Pro	Gemini 3.7 Flash
Claude Opus 4.5	Claude Opus 4.7, 4.8 또는 5
Claude Opus 4.6	Claude Opus 4.7, 4.8 또는 5
Claude Sonnet 4.5	Claude Sonnet 5
Claude Sonnet 4.6	Claude Sonnet 5
Raptor Mini	MAI-Code-1.1-Flash

GitHub는 Claude Sonnet 4.6이 개인 Copilot 연간 요금제에서는 계속 사용 가능하다는 예외도 덧붙였습니다. 이 예외는 전체 조직에서 모델이 유지된다는 뜻이 아니므로, 계정 유형과 조직 좌석을 나눠 확인해야 합니다.

대체 모델은 이름만 바꾸는 작업이 아니다

공급자가 제시한 대체 모델은 “새 모델을 선택할 수 있다”는 운영 안내이지, 기존 모델과 동일한 결과를 보장하는 독립 평가가 아닙니다. 확인한 GitHub 공지에는 조직 코드베이스에서의 정확도·지연 시간·비용을 비교한 제3자 검증 결과가 없습니다. 따라서 Claude Sonnet 4.6을 Claude Sonnet 5로 일괄 치환하는 것은 마이그레이션의 시작일 뿐입니다.

특히 에이전트 모드에서는 다음 변화가 함께 생길 수 있습니다.

• 도구 호출 순서나 명령 실행 제안이 달라질 수 있습니다.
• 같은 컨텍스트를 읽어도 요약 방식과 수정 범위가 달라질 수 있습니다.
• 응답 속도·토큰 사용량·실패 후 재시도 패턴이 바뀔 수 있습니다.
• 조직 정책에서 새 모델을 허용하지 않으면 사용자가 선택할 수 없습니다.

GitHub 공지도 대체 모델을 관리자가 정책에서 활성화해야 할 수 있다고 안내합니다. 즉 개인의 모델 선택 화면보다 기업·조직·저장소 정책이 먼저입니다.

마이그레이션 기록을 남기는 최소 단위

Copilot을 여러 저장소에서 사용한다면 모델 이름만 기록하지 말고 “작업·권한·검증”을 함께 남기는 편이 좋습니다.

1. 작업 목록: 코드 생성, 테스트 수정, 리팩터링, 코드 리뷰처럼 모델이 맡는 일을 분리합니다.
2. 입력 계약: 에이전트가 읽을 수 있는 파일, 실행 가능한 명령, 수정 가능한 경로를 적습니다.
3. 기준 결과: 대표 PR, 테스트 통과 여부, 변경 파일 수, 사람이 되돌린 수정의 유형을 저장합니다.
4. 대체 모델: 새 모델을 기본값으로 바꾸기 전 기존 모델과 같은 작업 세트를 실행합니다.
5. 되돌림 조건: 실패율, 보안 민감 파일 변경, 테스트 회귀처럼 다시 정책을 바꿀 조건을 정합니다.

이 기록은 모델 성능 순위를 만드는 자료가 아니라, 모델이 바뀌어도 저장소의 승인 절차가 흔들리지 않게 하는 운영 계약입니다.

GitHub 정책에서 확인할 부분

이번 공지에 따르면 Copilot Enterprise 관리자는 대체 모델 접근을 모델 정책에서 허용해야 할 수 있습니다. 사용자는 모델 선택기에 보이는 이름만 보고 실제 적용 가능하다고 판단하지 말고 다음을 확인해야 합니다.

• 기업·조직의 모델 정책이 새 모델을 허용하는가
• 해당 저장소가 다른 조직 좌석이나 플랜의 영향을 받는가
• 채팅·인라인·ask·agent·자동 완성에서 동일한 지원 범위를 갖는가
• 모델 고정이 필요한 CI나 자동화가 별도 인증·설정으로 남아 있는가

지원 종료 모델을 직접 삭제하는 별도 작업은 필요하지 않다고 GitHub는 설명하지만, 사용 중인 프롬프트·문서·내부 가이드에서 이전 모델명이 기준값으로 남아 있지 않은지는 점검해야 합니다.

적용 판단

지원 종료 공지는 “더 좋은 모델로 무료 업그레이드”라는 소식보다 의존성 변경 공지에 가깝습니다. 모델을 선택할 수 있는 화면보다 모델이 바뀌었을 때 업무가 어떻게 검증되는지가 더 중요합니다. 작은 테스트 저장소에서 대표 작업을 고정하고, 모델별 결과 차이를 기록한 뒤 조직 정책과 저장소 규칙을 함께 바꾸는 순서가 안전합니다.

이 글에서 확인한 근거는 GitHub의 공식 Changelog와 그 안에서 안내한 정책 범위입니다. 별도의 독립 벤치마크나 이 저장소에서의 Copilot 실사용 결과를 근거로 모델 우열을 주장하지 않았습니다. 모델명이 유지되는지보다, 변경된 모델을 어떤 입력·권한·검증 조건에서 허용할지 먼저 정하는 것이 장기적으로 덜 흔들리는 방식입니다.

• GitHub 공식 Changelog: Selected GitHub Copilot models deprecated
• GitHub Copilot 공식 Changelog