GitHub Models가 종료되면서 AI 기능을 한 서비스에 묶어 뒀을 때 무엇이 끊기는지 드러났다. 대체 모델을 고르기 전에 호출 지점과 데이터 경로, 인증 방식, 품질 기준부터 목록으로 만들어야 한다.
무슨 일이 바뀌었나
GitHub는 2026년 7월 30일부로 GitHub Models를 종료했다고 공지했다. 플레이그라운드, 모델 카탈로그, 추론 API, BYOK(Bring Your Own Key) 기능이 기존 사용자를 포함한 모든 고객에게 더 이상 제공되지 않는다. 7월 1일 공지에서 이미 종료 날짜와 영향 범위를 알렸고, 7월 16일과 23일에는 준비를 위한 짧은 브라운아웃도 예고했다.
웹 화면 하나만 사라진 게 아니다. GitHub Models를 통해 모델을 시험하거나 애플리케이션에서 추론 요청을 보냈다면, 그 경로 자체가 작동하지 않는다. GitHub는 새·기존 프로젝트의 모델 접근 대안으로 Microsoft Foundry를, GitHub 안에서 AI 기반 워크플로를 만들 경우에는 GitHub Copilot을 안내한다. 하지만 이 안내가 모든 기존 구현을 자동으로 옮겨 주는 것은 아니다.
AI는 기능이면서 공급망이다
AI 기능을 붙일 때 팀은 종종 모델의 성능과 프롬프트에만 집중한다. 그러나 실제 서비스에는 호출 SDK, 엔드포인트, 인증 방식, 사용량 제한, 데이터 보관 조건, 장애 처리, 비용 청구, 평가 데이터가 함께 묶여 있다. 한 플랫폼이 종료되면 모델 이름만 바꾸어 해결되지 않는 이유다.
독립 개발자와 작은 팀도 예외가 아니다. PR 요약, 릴리스 노트 초안, 문서 검색, 고객 문의 분류, 테스트 실패 분류처럼 작은 자동화는 눈에 잘 띄지 않는 곳에서 AI API에 연결되기 쉽다. 한 독립 분석은 이런 파이프라인이 종료 시점에 바로 멈출 수 있고, 대체 경로에는 별도의 키 관리와 요금, 속도 제한이 따라온다고 지적했다. 분석 글의 해석이긴 하지만 API와 BYOK까지 종료한다는 공식 공지를 함께 보면 실제 연결 지점을 점검할 이유는 충분하다.
모델 포터빌리티와 운영 포터빌리티는 다르다
모델 포터빌리티는 A 모델 대신 B 모델을 호출할 수 있는 정도다. 입력과 출력 형식이 비슷하면 비교적 쉬워 보인다. 반면 운영 포터빌리티는 서비스가 바뀌어도 실제 업무가 계속되는 능력이다. 여기에는 다음 질문이 포함된다.
- 어느 저장소, 배치 작업, CI 워크플로, 사내 도구가 해당 공급자를 호출하는가?
- 프롬프트·시스템 지시·도구 호출·응답 파싱은 특정 API 형식에 묶여 있는가?
- 키는 어디에 보관되고 누가 권한을 승인하는가?
- 모델 교체 뒤에도 정확도, 비용, 지연 시간, 안전성은 허용 범위인가?
- 개인정보나 코드가 새 공급자의 약관과 데이터 경로에서 허용되는가?
AI를 공부할 때도 이 둘을 나눠 봐야 한다. 데모에서 모델 응답이 나오는 것과 조직에서 안정적으로 운영하는 것은 다른 과제다. 특히 에이전트나 자동화는 모델이 도구를 호출하고 결과를 다음 단계에 넘기므로, 한 단계의 API 변경이 여러 작업에 연쇄 영향을 줄 수 있다.
대체 서비스로 옮길 때의 현실적인 순서
1. 먼저 ‘어디서 쓰는지’를 찾는다
코드 저장소에서 공급자명, 엔드포인트 주소, 환경 변수 이름, SDK 패키지, 워크플로 파일을 검색한다. 프로덕션 코드만 보지 말고 GitHub Actions, 노트북, 스크립트, 내부 문서와 데모도 확인한다. 결과는 단순한 파일 목록이 아니라 ‘업무 목적·호출 주체·입력 데이터·실패 시 영향’ 표로 정리하는 편이 좋다.
2. 바꾸기 전에 성공 기준을 고정한다
대체 모델을 연결한 뒤 “대충 비슷하다”로 판단하면 회귀를 발견하기 어렵다. 실제 요청 20~50개처럼 작지만 대표성 있는 평가 묶음을 만든다. 예를 들어 PR 요약이라면 사실 보존, 금지 정보 노출 여부, 형식 준수, 응답 시간, 요청당 비용을 함께 기록한다. 모델마다 답이 달라지는 것은 자연스러운 일이며, 따라서 정답 하나만 보는 대신 업무에 필요한 기준을 명시해야 한다.
3. 연결 계층을 분리한다
애플리케이션 곳곳에서 특정 공급자의 SDK를 직접 부르면 다음 이전 비용이 커진다. 모델 호출을 하나의 모듈이나 내부 API 뒤로 모으면, 상위 기능은 ‘요약 요청’이나 ‘분류 요청’ 같은 업무 단위 인터페이스만 바라볼 수 있다. 이것이 특정 공급자를 피하자는 뜻은 아니다. 공급자를 선택하되 교체 지점을 작게 만들자는 뜻이다.
4. 권한과 비용을 새로 확인한다
기존 BYOK 또는 플랫폼 인증에서 다른 클라우드·직접 API·사내 게이트웨이로 옮기면 키 발급, 보관, 회전, 사용자 권한, 청구 계정이 바뀐다. 개발용 키를 CI에 복사해 넣는 식의 급한 이전은 피해야 한다. 최소 권한, 비밀값 관리 도구, 사용량 알림, 요청 한도는 기능 전환과 같은 날 확인할 항목이다.
대안이 있어도 바로 옮길 수는 없다
이번 종료는 팀이 모델 접근을 더 명시적으로 설계하게 만드는 계기가 될 수 있다. Microsoft Foundry처럼 여러 모델을 제공하는 플랫폼이나 직접 공급자 API를 비교하면서, 모델 선택과 애플리케이션 구조를 분리할 기회가 생긴다. GitHub Copilot은 GitHub 중심의 개발 흐름에서 다른 종류의 편의성을 제공할 수 있다.
다만 ‘대안이 있다’는 말만으로 호환성이 보장되지는 않는다. 모델의 출력 품질, 도구 호출 방식, 지역별 제공 범위, 가격, 데이터 처리 조건은 서로 다를 수 있다. GitHub의 공지는 Foundry와 Copilot을 방향으로 제시하지만, 특정 워크로드의 성능·비용·규정 적합성을 보장하지는 않는다. 대체 후보를 실제 데이터로 평가하지 않은 채 대규모 이전을 결정하면 위험하다.
지금 확인해 볼 것
- AI 호출 지도 만들기: 지금 쓰는 프로젝트 하나에서 모델 호출 위치와 목적을 30분 동안만 찾아 표로 적어 본다. ‘없다’는 결론도 검색으로 확인해야 신뢰할 수 있다.
- 작은 회귀 세트 만들기: 자주 쓰는 프롬프트 10개와 기대 조건을 저장한다. 정답 문장보다 사실성, 형식, 금지 항목, 지연 시간을 체크 항목으로 둔다.
- 교체 실험을 분리하기: 운영 경로를 바로 바꾸지 말고, 같은 입력을 기존·후보 경로에 나란히 보내 결과와 비용을 비교한다. 비밀값은 코드나 문서에 붙여 넣지 않는다.
모델보다 먼저 볼 목록
GitHub Models 종료를 겪고 보니 AI 플랫폼을 영구적인 기반으로 생각해서는 안 된다는 점이 선명해졌다. 새 모델을 급히 고르기보다 무엇이 어디에 의존하는지부터 알아야 한다. 옮긴 뒤에는 같은 기준으로 결과를 다시 평가해야 한다. AI를 실무에 쓴다는 건 모델 호출뿐 아니라 변경을 감지하고 영향을 좁히는 운영 습관까지 포함한다.