GitHub Copilot 모델 폐기: 9월부터 바뀐 대체 모델과 점검 포인트

검색 의도: GitHub Copilot 모델 폐기, Copilot 대체 모델, Copilot Enterprise 모델 정책 점검

9월 1일부터 GitHub Copilot에서 일부 모델이 폐기됐다. GitHub changelog 기준으로 Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6, Raptor Mini가 대부분의 Copilot 경험에서 deprecated 상태가 됐다. 영향 범위는 Copilot Chat, inline edits, ask mode, agent mode, code completions까지 넓다. 개인 사용자는 모델 선택지만 하나 줄어든 정도로 느낄 수 있지만, 조직에서는 CI 보조 스크립트, 사내 문서, 교육 자료, 모델 정책, 비용 추정표가 동시에 어긋날 수 있다.

중요한 점은 “모델이 안 보인다”가 장애의 전부가 아니라는 것이다. AI 코딩 도구를 팀 표준으로 쓰는 조직은 모델 이름을 운영 계약처럼 다루는 경우가 많다. 예를 들어 특정 레포의 agent mode는 Claude Sonnet 4.6을 권장하고, 보안 리뷰는 Opus 계열을 쓰고, 빠른 autocomplete는 Raptor Mini를 쓰도록 문서화했을 수 있다. 이런 상태에서 모델이 사라지면 개발자는 임의로 가까워 보이는 모델을 고르고, 결과 품질과 비용은 팀마다 달라진다.

무엇이 바뀌었나

GitHub가 공지한 대체 방향은 비교적 명확하다. Gemini 3.1 Pro는 Gemini 3.7 Flash로, Claude Sonnet 4.5와 4.6은 Claude Sonnet 5로, Claude Opus 4.5와 4.6은 Claude Opus 4.7, 4.8 또는 Opus 5로 옮기라는 식이다. Raptor Mini는 MAI-Code-1.1-Flash가 대체 후보로 제시됐다. 조직 관리자는 Copilot settings의 model policy에서 대체 모델 접근을 켜야 한다. 켜지 않으면 개발자 화면의 모델 선택기에 대체 모델이 나타나지 않을 수 있다.

이 변경은 단순한 버전 업그레이드가 아니다. 모델마다 강점, 응답 길이, 비용 단위, latency, tool use 안정성이 다르다. Sonnet 4.6에서 Sonnet 5로 옮긴다고 해서 모든 프롬프트가 같은 방식으로 동작한다고 보면 안 된다. 특히 agent mode에서 파일을 여럿 수정하거나 테스트 로그를 읽는 작업은 모델의 reasoning budget과 context handling에 민감하다. deprecated 모델을 쓰던 프롬프트가 새 모델에서 더 공격적으로 코드를 바꾸거나, 반대로 보수적으로 멈출 수도 있다.

개발팀에서 먼저 깨지는 지점

첫 번째는 문서다. README, CONTRIBUTING, 사내 위키, 온보딩 문서에 “이 작업은 Claude Sonnet 4.6으로 실행” 같은 문장이 남아 있으면 신입 개발자는 그대로 따라 하다가 모델을 찾지 못한다. 두 번째는 자동화다. Copilot CLI나 agent workflow를 감싼 스크립트가 모델명을 인자로 받는다면 실패 모드가 두 가지로 갈린다. 명시적으로 오류가 나면 낫다. 더 위험한 경우는 기본 모델로 조용히 fallback되는 것이다.

세 번째는 비용과 품질 기준이다. 기존 모델로 “문서 수정 1건당 평균 3분, 리뷰 코멘트 5개 이하” 같은 내부 기준을 잡아뒀다면 대체 모델에서 다시 측정해야 한다. 모델이 바뀌면 토큰 사용량, 재시도 횟수, 리뷰 노이즈가 달라진다. GitHub 공지는 “지원 모델로 업데이트하라”고 말하지만, 실무에서는 업데이트 이후의 회귀 테스트가 핵심이다.

마이그레이션 순서

먼저 조직 model policy를 확인한다. Enterprise나 Business 플랜이라면 관리자가 대체 모델을 활성화했는지 봐야 한다. 그 다음 모델명을 하드코딩한 위치를 찾는다. 검색 대상은 .github, docs, scripts, Makefile, 사내 에이전트 템플릿, IDE 설정 가이드다. 문자열 검색은 단순하지만 효과가 좋다. Claude Sonnet 4.6, Opus 4.5, Gemini 3.1 Pro, Raptor Mini처럼 사람이 문서에 적었을 법한 표기까지 함께 찾는 편이 낫다.

그 다음은 작업 유형별 대체 모델을 정한다. 빠른 코드 설명, 작은 수정, 대규모 리팩터링, 보안 리뷰, 테스트 실패 분석을 한 모델로 몰아넣지 말자. 예를 들어 작은 수정은 Flash 계열, 복잡한 설계 검토는 Opus 또는 상위 reasoning 모델, 반복적인 PR 설명 생성은 비용이 낮은 모델로 나누는 식이다. 이 구분을 해두면 이후 모델 변경이 다시 와도 영향 범위를 줄일 수 있다.

운영자가 봐야 할 지표

모델 교체 후에는 “응답이 그럴듯한가”보다 운영 지표를 봐야 한다. PR당 AI 수정 파일 수, 사람 리뷰에서 되돌린 비율, 테스트 재실행 횟수, 평균 토큰 사용량, 모델별 월간 비용, agent mode 중단 비율을 추적하면 된다. 특히 deprecated 모델에서 새 모델로 바뀐 첫 2주는 샘플 PR을 모아 사람이 비교 리뷰하는 것이 좋다. 모델 업그레이드는 품질 향상 기회이지만, 검증 없이 올리면 팀 전체에 작은 불안정성이 퍼진다.

공식 근거는 GitHub Changelog의 “Selected GitHub Copilot models deprecated” 공지다. 공지에는 폐기 모델, 폐기일, 제안 대체 모델, Enterprise 관리자가 확인해야 할 model policy가 정리돼 있다. 개발팀은 이 내용을 릴리즈 노트처럼 읽지 말고 운영 변경 요청으로 다루는 편이 안전하다.

실행 체크리스트

• Copilot model policy에서 대체 모델 접근이 켜져 있는지 확인한다.
• 문서와 스크립트에서 폐기 모델명을 문자열 검색한다.
• 작업 유형별 기본 모델을 다시 정한다.
• 최소 5개 실제 PR로 이전 모델 대비 리뷰 품질과 수정 범위를 비교한다.
• fallback이 조용히 발생하지 않도록 실패 로그를 남긴다.
• 비용 대시보드에서 모델별 토큰 사용량을 2주간 분리해서 본다.
• 온보딩 문서와 에이전트 사용 예시를 같은 날 수정한다.

이번 Copilot 모델 폐기는 “AI 모델도 의존성이다”라는 사실을 다시 보여준다. npm 패키지 버전을 올릴 때 changelog와 regression test를 보듯, Copilot 모델도 정책, 문서, 비용, 품질 지표를 같이 옮겨야 한다.