쓰던 AI 모델이 지원 종료되면 무엇을 해야 합니까?

모델에는 수명주기가 있습니다

모델 제공사는 새 모델을 내놓으면서 이전 모델을 정리합니다. Anthropic은 새 모델 출시를 위한 용량 확보를 이유로 들고, 종료된 모델에 대한 요청은 실패한다고 밝힙니다. 운영 중인 서비스 입장에서 모델 교체는 선택이 아니라 일정이 정해진 의무 작업이라는 뜻입니다.

정리 단계와 일정은 모델 제공사와 클라우드 플랫폼이 각각 정하며, 같은 모델이라도 플랫폼마다 종료 일정이 다를 수 있습니다. Anthropic은 자사 문서의 일정이 자사가 운영하는 플랫폼에 적용되고 Amazon Bedrock·Google Cloud는 자체 일정을 정한다고 밝힙니다. AWS도 Bedrock의 수명주기 날짜가 모델 제공사의 발표와 다를 수 있으며, Bedrock 사용에는 모델 카드에 적힌 날짜만 적용된다고 설명합니다.

AWS 문서에 따르면 2026년 9월 7일 또는 그 이후에 출시된 Bedrock 모델의 레거시 기간은 6개월과 45일 두 가지이고, 대부분은 6개월입니다. 그 전에 출시된 모델에는 별도 문서의 이전 정책이 적용되며, 레거시 기간 후반에 모델 제공사가 정하는 더 높은 요금이 붙는 「공개 연장 접근」 기간이 있을 수 있습니다. 수명주기 상태는 리전마다 다를 수 있으므로, 쓰는 모델의 모델 카드와 쓰는 리전의 상태를 직접 확인해야 합니다.

Bedrock에는 놓치기 쉬운 조건이 하나 더 있습니다. 모델이 레거시 단계에 들어가면 신규 고객은 그 모델을 쓸 수 없고, 기존 고객도 15일 동안 사용하지 않으면 접근을 잃을 수 있습니다. 한 달에 한 번 도는 정산 배치나 분기 보고서 생성처럼 드물게 호출하는 기능이 레거시 모델을 쓰고 있다면, 종료일 전에 이미 멈출 수 있다는 뜻입니다.

미세조정한 맞춤형 모델을 쓰고 있다면 영향이 더 큽니다. AWS 문서에 따르면 기반 모델이 레거시 단계에 들어간 뒤에는 그 모델로 새 미세조정 작업이나 새 프로비저닝된 처리량을 만들 수 없습니다. 레거시 진입 전에 맞춤화해 둔 모델은 기존 배포를 계속 쓰거나 온디맨드 배포를 새로 만들 수 있지만, 종료일 전에는 옮겨야 합니다. 맞춤화 결과는 기반 모델에 묶여 있어 새 기반 모델로 옮기려면 맞춤화를 다시 해야 하므로, 일반 모델 교체보다 준비 기간이 깁니다.

종료 안내를 받으면 하는 일

1. 영향 범위 확인어느 기능·계정·리전이 그 모델을 쓰는지 사용 기록에서 찾습니다
2. 대체 모델 후보 선정제공사 권장 대체 모델과 데이터 처리 위치·과금 구조를 함께 확인합니다
3. 평가 세트로 비교기존 모델과 같은 입력으로 품질·출력 형식·응답 시간을 비교합니다
4. 프롬프트와 후처리 조정새 모델의 출력 형식 차이를 흡수하도록 고칩니다
5. 단계적 전환과 잔여 호출 확인일부 트래픽부터 옮기고, 이전 모델 호출이 남지 않았는지 확인합니다

Anthropic은 콘솔의 사용량 내보내기에서 API 키·모델별 사용량을 확인해 남은 호출을 찾으라고 안내하고, 종료일보다 충분히 앞서 새 모델로 시험하라고 권합니다. 대체 모델을 고를 때는 품질만 보지 말고 데이터가 처리되는 위치도 다시 확인해야 합니다. 같은 서울 리전 호출이라도 모델에 따라 교차 리전 추론 프로파일로만 제공되는 경우가 있기 때문입니다. 제공사가 권장 대체 모델을 함께 공지하는 경우가 많지만, 그 모델이 비용 구조·처리 위치·지원 리전 면에서 우리 조건에 맞는지는 따로 확인해야 합니다.

새 모델이 일반적으로 더 낫다는 평가가 우리 업무에서도 맞는다는 보장은 없습니다. 출력의 길이와 형식, 어조, 요청을 거절하는 기준이 달라지면 다음 단계의 프로그램이 결과를 읽지 못하거나 고객에게 나가는 문장의 느낌이 바뀔 수 있습니다. 그래서 비교는 품질 점수와 함께 형식 검증 통과율, 응답 시간, 입출력 길이처럼 운영과 비용에 영향을 주는 항목을 함께 봅니다.

전환은 한 번에 하지 않습니다. 일부 요청만 새 모델로 보내 결과를 비교하고, 문제가 없으면 비중을 늘리고, 이상이 생기면 이전 모델로 되돌릴 수 있게 둡니다. 되돌릴 수 있는 기간은 종료일까지이므로 전환을 종료일 직전으로 미루지 않는 것이 좋습니다.

모델만이 아니라 요청 형식도 바뀝니다

정리되는 것은 모델만이 아닙니다. Anthropic은 요청 파라미터의 폐기도 같은 문서에 공지하며, 새 모델이 폐기된 파라미터를 거부하거나 새 API 버전이 모든 모델에서 그 파라미터를 없앨 수 있다고 밝힙니다. 2026년 10월 기준으로는 2026-10-21 API 버전에서 샘플링 파라미터 temperature·top_p·top_k가 제거되어, 이 값을 보내면 오류가 납니다. 그래서 모델 이름만 바꾸면 끝난다고 가정하지 않는 것이 안전합니다. 교체 시험에는 실제 운영 코드가 보내는 요청 그대로를 써야 이런 차이가 드러납니다. 시험 환경의 SDK·라이브러리 버전도 운영과 같게 맞춥니다. 모델 교체와 API 버전 변경이 겹치면 문제가 생겼을 때 원인을 가리기 어려우므로, 가능하면 한 번에 하나씩 바꾸고 각각 평가 세트로 확인합니다.

평소에 해 둘 것

가장 효과가 큰 준비는 모델 ID를 한곳에 모으는 것입니다. 여러 코드에 흩어져 있으면 무엇이 어떤 모델을 쓰는지 찾는 데만 시간이 걸리고, 하나를 빠뜨리면 그 기능만 종료일에 멈춥니다. 설정 값으로 모아 두면 영향 범위 확인과 전환이 모두 짧아집니다.

사용처 목록에는 모델 이름만이 아니라 그 기능의 담당자, 호출 빈도, 쓰는 리전과 추론 프로파일, 연결된 평가 세트의 위치를 함께 적습니다. 호출 빈도를 적어 두면 레거시 단계의 미사용 접근 제한에 걸릴 기능을 미리 가려낼 수 있고, 담당자를 적어 두면 종료 안내를 받았을 때 누구에게 넘길지 바로 정해집니다.

• 모델 ID를 코드에 박지 않고 설정 값으로 관리한다
• 기능별로 어떤 모델·리전·담당자를 쓰는지 목록이 있다
• 기능마다 평가 세트가 있어 새 모델을 바로 비교할 수 있다
• 모델 출력은 형식 검증 코드를 거쳐 다음 단계로 넘어간다
• 종료 안내 메일을 개인이 아니라 공용 주소에서 받는다
• 모델 카드와 제공사 공지를 정해진 주기로 확인한다

참고 자료

• AWS — Amazon Bedrock Model lifecycle
• AWS — Amazon Bedrock Model lifecycle (2026.9.7. 이전 출시 모델)
• Anthropic — Model deprecations