LLM 모델 종료 전에 옮기는 법: 14일 마이그레이션·롤백 런북

모델 지원 종료 메일을 받은 날 처음 해야 할 일은 새 모델 이름으로 문자열을 바꾸는 작업이 아닙니다. 지금 그 모델을 어디서, 어떤 기대값으로 쓰는지 찾는 일이다. API 서버는 바꿨는데 야간 배치나 고객별 설정에 예전 ID가 남으면 종료일에 일부 요청만 실패합니다.

제공자가 권장하는 후속 모델도 현재 업무와 자동으로 호환되지는 않습니다. 답변 문체만 달라지는 것이 아니라 JSON 형태, 도구 선택, 거부 방식, 입력 한도, 지연과 비용이 함께 움직일 수 있습니다.

OpenAI의 공식 폐기 안내는 일반 공개 모델에는 통상 6개월 이상, 특수 모델에는 3개월 이상의 예고를 목표로 하지만 미리보기 모델은 2주처럼 짧을 수 있다고 설명합니다. 안전·규제 사유로 더 빠르게 바뀌는 예외도 명시돼 있습니다. OpenAI API Deprecations

그래서 “항상 6개월 남는다”는 전제로 운영하면 안 된다. 아래 14일 계획은 짧은 통지에도 핵심 검증을 끝내기 위한 내부 목표이며 공급자의 보장 기간이 아닙니다.

0일 차: 종료 공지를 작업 티켓으로 바꾼다

공지 링크만 슬랙에 공유하면 책임과 완료 조건이 남지 않습니다. 티켓에 다음 항목을 고정합니다.

종료 모델의 정확한 ID와 접근 경로
새 요청이 실패하기 시작하는 날짜와 시간대
제공자가 제시한 대체 모델과 문서 링크
영향을 받을 제품·환경·고객
마이그레이션 책임자와 승인자
이전 모델로 되돌릴 수 있는 마지막 날짜
품질, 지연, 오류, 비용의 통과 기준

Anthropic은 모델 상태를 active, legacy, deprecated, retired로 구분합니다. retired 상태에서는 해당 모델 요청이 실패한다고 명시하며, 공개 모델에는 최소 60일의 사전 통지를 목표로 합니다. 파트너 플랫폼의 일정은 다를 수 있습니다. Anthropic Model Deprecations

각 공급자의 용어와 날짜 의미를 그대로 기록하세요. deprecated를 이미 호출 불가능한 상태로 오해하거나, 반대로 legacy를 장기 지원 약속으로 읽으면 일정이 틀어집니다.

1~2일 차: 모델 사용처를 네 방향에서 찾는다

저장소에서 모델 문자열을 검색하는 것만으로는 부족합니다.

조사 위치	놓치기 쉬운 사례	확인 방법
코드와 설정	환경변수 기본값, SDK 래퍼, 테스트 픽스처	저장소 검색, 배포 설정 목록
실행 인프라	예약 작업, 함수, 큐 소비자, 실험 서버	런타임 구성·최근 호출 로그
외부 자동화	n8n, Zapier, 스프레드시트 스크립트	연결 계정과 워크플로 내보내기
데이터 저장소	고객별 모델 설정, 프롬프트 레지스트리	DB 쿼리, 관리자 화면

가장 강한 증거는 실제 호출 로그다. 최근 30일의 provider, resolved_model_id, feature, environment, request_count, owner를 집계합니다. 별칭만 기록했다면 제공자가 실제로 해석한 모델 버전도 앞으로 같이 남깁니다.

모델 사용처 표에는 트래픽이 없더라도 재해 복구 작업과 월말 배치를 포함합니다. “최근 호출 없음”과 “더는 쓰지 않음”은 같은 뜻이 아니다.

3~4일 차: 프롬프트가 아니라 입출력 계약을 고정한다

기존 프롬프트를 새 모델에 넣고 몇 개 답변을 읽는 방식은 회귀를 찾기 어렵습니다. 기능이 지켜야 할 계약을 먼저 적습니다.

API 계약

요청 크기와 지원 콘텐츠 형식
스트리밍 이벤트 순서와 종료 신호
구조화 출력 스키마와 필수 필드
도구 이름, 인자 형태와 호출 횟수 제한
오류 코드, 시간 초과와 재시도 가능 여부

제품 계약

답변에 반드시 포함하거나 제외할 내용
검색 근거가 없을 때 거부하는 조건
사람이 승인해야 할 행동
허용 가능한 지연과 업무 1건 원가
안전 정책상 차단할 요청과 안내 문구

계약 테스트는 문자열 전체 일치보다 구조와 금지 조건을 봅니다. JSON이 파싱되는지, 존재하지 않는 도구를 고르지 않는지, 근거 없는 문서 ID를 만들지 않는지 검사합니다. 자유 서술 품질은 고정 샘플과 사람 검토를 병행합니다.

기존 평가 세트를 만드는 방법은 LLM 회귀 평가 가이드, 검색형 답변의 근거 평가는 RAG 품질 평가 가이드에 정리돼 있습니다.

5~7일 차: 같은 입력을 두 모델에 보내 차이를 분류한다

그림자 실행에서는 사용자의 실제 응답은 기존 모델로 보내고, 복제한 입력을 새 모델에도 전달해 결과를 저장합니다. 개인정보와 계약이 허용하는 범위에서만 사용해야 하며 외부 행동 도구는 실행하지 않습니다.

비교 결과를 하나의 평균 점수로 뭉개지 마세요.

축	확인할 변화
정확성·근거	사실 오류, 인용 누락, 검색 문서 불일치
형식	JSON 파싱, 필수 필드, 마크다운 구조
도구 행동	도구 선택, 인자, 반복 호출, 실행 순서
안전	거부가 늘거나 줄어든 요청, 우회 가능성
운영	p50·p95 지연, 오류율, 출력 길이, 단위 원가

실패 샘플에는 old_pass/new_fail, old_fail/new_pass, both_fail 같은 꼬리표를 붙입니다. 새 모델의 평균이 높아도 결제나 삭제 경로에서 한 건의 새 실패가 생기면 배포를 멈출 근거가 됩니다.

8~10일 차: 프롬프트와 어댑터를 최소한으로 고친다

새 모델의 답변을 예전 모델과 똑같이 만들려고 프롬프트를 계속 덧붙이면 다음 교체가 더 어려워집니다. 차이를 세 종류로 나눕니다.

공급자 API 차이: SDK 어댑터와 응답 정규화 계층에서 처리합니다.
업무 계약 위반: 프롬프트, 도구 명세, 검증기에서 고칩니다.
허용 가능한 표현 차이: 평가 기준을 만족하면 그대로 둡니다.

모델 ID를 업무 코드 곳곳에 남기지 말고 내부 별칭과 해석 표를 둡니다. 예를 들어 support-draft-primary가 어느 공급자 모델로 연결되는지 배포 설정에서 관리하되, 실제 응답 로그에는 해석된 정확한 모델 ID를 기록합니다.

Gemini 문서는 stable, preview, latest, experimental 같은 이름의 안정성이 다르다고 설명합니다. latest 별칭은 새 버전으로 교체될 수 있고 미리보기·실험 모델은 운영 안정성이 낮을 수 있습니다. Gemini 모델 문서

별칭은 운영 편의 장치이지 변경 통제를 없애는 장치가 아니다. 제공자 별칭이 자동으로 다른 모델을 가리키면 회귀 시험 없이 동작이 바뀔 수 있습니다.

11~12일 차: 작은 트래픽부터 새 모델로 보낸다

점진 배포는 고객 수만 나누지 않습니다. 위험이 낮고 되돌리기 쉬운 기능부터 옮깁니다.

내부 사용자와 테스트 계정
읽기 전용 요약·분류
외부 전송 없는 초안
낮은 비율의 일반 트래픽
승인 경계가 있는 도구 작업
전체 트래픽

각 단계에는 최소 관찰 시간과 자동 중단 기준을 둡니다. 오류율, p95 지연, JSON 실패, 도구 실행 거부, 사람 수정률, 업무 원가를 기존 기준선과 비교합니다. 표본이 작은 지표는 한두 건의 변화만으로 결론 내리지 말고 실패 원문을 함께 봅니다.

새 모델이 타임아웃을 내면 무조건 이전 모델로 재시도하는 방식도 조심해야 합니다. 이미 외부 도구를 실행한 요청이라면 중복 결제나 전송이 생길 수 있습니다. 쓰기 작업에는 멱등성 키와 실행 상태 확인이 먼저다.

13일 차: 롤백을 실제로 실행해 본다

설정에 이전 모델 ID가 남아 있다는 사실만으로 롤백이 증명되지는 않습니다. 다음 순서로 복구 훈련을 합니다.

시험 트래픽을 새 모델에서 이전 모델로 되돌립니다.
캐시와 세션이 모델별 응답 형식을 섞지 않는지 확인합니다.
진행 중인 도구 작업이 중복 실행되지 않는지 검사합니다.
대시보드와 경보가 모델 변경을 올바르게 표시하는지 봅니다.
롤백 결정자, 실행자, 고객 공지 담당자의 연락 경로를 확인합니다.

이전 모델의 종료 직전까지 양쪽을 장기간 병행하면 비용과 복잡성이 커집니다. 롤백 시험이 끝났다면 최종 전환 시점과 이전 경로 제거 시점을 확정합니다.

14일 차: 종료가 아니라 폐기 증거를 남긴다

새 모델 100% 전환 뒤에도 할 일이 남습니다.

코드, 배포 설정, DB와 노코드 워크플로에서 이전 ID를 다시 검색합니다.
이전 모델 전용 프롬프트와 파서를 제거하거나 보관 사유를 적습니다.
API 키·권한·캐시·평가 작업의 불필요한 항목을 정리합니다.
전환 전후 품질, 오류, 지연, 비용 자료를 변경 기록에 붙입니다.
다음 종료 공지를 받을 소유자와 알림 채널을 갱신합니다.

NIST 생성형 AI 프로필은 배포 뒤 모니터링에 변경 관리, 복구와 폐기 절차를 포함하도록 제안합니다. 마이그레이션은 새 모델을 켠 순간이 아니라 오래된 의존성을 제거하고 복구 근거를 남긴 때 끝납니다. NIST AI 600-1

종료 공지가 없을 때도 분기마다 확인할 것

최근 호출 로그와 모델 사용처 목록이 일치한다.
공급자의 폐기 공지 RSS·메일·상태 채널에 소유자가 등록돼 있다.
고정 평가 세트가 현재 제품 계약을 반영한다.
그림자 실행에서 외부 도구를 차단할 수 있다.
실제 모델 버전과 비용을 요청별로 추적한다.
이전 모델 없이도 안전한 축소 운영 모드가 있다.

모델 수명 정책은 공급자와 플랫폼마다 다르고 언제든 갱신될 수 있습니다. Anthropic API에서 직접 쓰는 모델과 클라우드 파트너가 제공하는 같은 계열 모델의 종료일도 같다고 단정할 수 없습니다. Gemini 역시 별도 폐기 페이지에서 모델별 일정을 안내합니다. Gemini API Deprecations

첫 준비는 거창한 멀티 모델 라우터가 아니다. 실제 호출 로그에 정확한 모델 ID와 기능 소유자를 남기고, 핵심 요청 20개로 계약 테스트를 만들어 두세요. 다음 종료 메일이 왔을 때 일정의 절반을 사용처 찾기에 쓰지 않게 됩니다.