OpenAI가 GPT-5를 출시하며 자동 라우팅을 도입하고 기존 모델 선택 방식을 바꿨을 때, 사용자가 익숙한 모델을 계속 선택할 수 있어야 한다는 요구가 컸다. 이후 일부 선택권이 복원됐지만, 제품과 API에서 구형 모델을 정리하는 흐름 자체가 사라진 것은 아니다. 구체적인 종료 일정은 바뀔 수 있으므로 운영팀은 공급자의 공식 지원 종료 공지를 계속 확인해야 한다.
창업자가 살펴볼 문제는 모델의 순간적인 성능 순위보다 공급자가 정한 일정에 따라 제품의 기반 모델을 교체해야 한다는 운영 조건이다.
프롬프트는 모델별로 다시 검증해야 한다
운영 중인 프롬프트는 특정 모델의 동작에 맞춰 조정된다. 어떤 모델에는 짧은 형식 지시만으로 충분하지만, 다른 모델에는 JSON 스키마나 예시를 더 자세히 줘야 할 수 있다. temperature와 예시 개수, 도구 설명 순서도 평가 결과를 보며 정한다. 따라서 같은 프롬프트가 다른 모델에서도 같은 품질을 낼 것이라고 기대하기 어렵다.
이런 튜닝은 모델과 버전에 따라 효과가 달라진다. 모델이 종료되거나 동작이 업데이트되면 도구 호출, 출력 형식, 기존 검증 결과가 함께 달라질 수 있다. 이때 마이그레이션 비용은 코드 몇 줄을 바꾸는 데서 끝나지 않는다. 새 모델의 반응을 확인하고 프롬프트와 평가 기준을 다시 맞추는 시간이 든다.
공급자가 정한 일정에 맞춰야 하는 의존성
특정 모델에 맞춘 프롬프트와 운영 절차가 많을수록 다른 모델로 옮기는 비용이 커진다. 여기에 공급자의 지원 종료 일정까지 겹치면 전환 시점도 사용자가 자유롭게 정하기 어렵다. 종료 전에 마이그레이션을 마치지 못하면 해당 API를 쓰는 기능이 중단될 수 있다.
자동 라우팅을 사용하는 서비스에서는 같은 제품명 아래에서도 요청을 처리하는 모델이나 설정이 달라질 수 있다. 사용자는 공급자가 제공하는 버전과 지원 정책 안에서만 모델을 선택한다. 특정 응답 습관에 프롬프트를 과도하게 맞추면 공급자의 변경이 있을 때 수정해야 할 범위가 커진다.
모델 교체를 운영 절차에 넣는다
모델 교체를 예외 상황으로 두지 말고 운영 절차에 포함해야 한다. 다음 세 가지가 기본 준비다.
첫째, 회귀 평가 세트를 관리하라. 공급자의 릴리스 노트만으로는 제품의 어떤 동작이 달라졌는지 모두 알기 어렵다. 실제 실패 사례로 만든 고정 평가 세트를 새 모델에 반복 실행해 회귀를 확인해야 한다. 자체 평가의 필요성과 AI 배포 기준에서 다룬 것처럼 제품의 핵심 작업은 팀이 직접 측정해야 한다.
둘째, 프롬프트를 모델별 어댑터로 격리하라. 입력과 출력은 스키마로 고정하고, 모델 특성에 맞춘 문구는 교체 가능한 부품으로 관리한다. 그러면 모델이 바뀌어도 핵심 로직까지 함께 고칠 가능성을 줄일 수 있다. 비용과 품질이 허용한다면 여러 공급자를 같은 인터페이스로 연결해 전환 가능성도 점검한다.
셋째, 업무의 근거를 프롬프트 밖에서 관리하라. 사실·규칙·관계를 프롬프트 예시에만 넣으면 모델 교체 때 함께 옮겨야 한다. 이를 온톨로지와 컨텍스트 계층에 두면 기반 모델이 달라져도 같은 기준을 다시 사용할 수 있다. 평가 데이터, 업무 데이터, 의미 정의를 제품이 직접 관리해야 모델 교체 비용을 낮출 수 있다.