AI 모델 라우팅 운영법: 최신 모델 교체를 장애 없이 처리하는 체크리스트

2026년 9월의 AI API 릴리즈 노트를 보면 공통된 흐름이 보인다. 구글은 Gemini 2.5 접근을 기존 사용자 중심으로 제한하고 신규 프로젝트에는 3.x 모델을 권한다. OpenAI Codex는 provider별 reasoning summary 지원 차이 때문에 기본값을 조정했다. Claude Code는 Auto Mode classifier와 프로젝트 지침 파일 처리를 바꿨다. 겉으로는 각 회사의 개별 업데이트지만, 운영팀 입장에서는 같은 메시지다.

모델은 계속 바뀐다. 그래서 AI 제품은 “어떤 모델을 쓰느냐”보다 “모델이 바뀌어도 제품이 무너지지 않는 구조”가 중요하다.

하드코딩된 모델 ID부터 제거하라

가장 흔한 문제는 모델 ID가 코드 곳곳에 박혀 있는 상태다. 서버 코드, 워커, 프론트엔드, 노션 자동화, GitHub Action, 크론 스크립트, 고객사별 설정에 흩어져 있으면 교체가 거의 불가능하다.

나쁜 구조는 이렇다.

await client.responses.create({
  model: "some-latest-model",
  input: prompt,
});

처음에는 빠르다. 하지만 모델이 deprecated되거나, 신규 프로젝트 접근이 제한되거나, 특정 provider 옵션이 실패하면 전체 코드를 뒤져야 한다.

더 나은 방식은 모델 목적을 먼저 정의하는 것이다.

const MODEL_ROUTES = {
  fastSummary: { provider: "google", model: "gemini-3.5-flash-lite" },
  codingAgent: { provider: "google", model: "gemini-3.8-flash" },
  sensitiveReview: { provider: "anthropic", model: "team-approved" },
  legacyFallback: { provider: "google", model: "gemini-2.5-flash" }
};

서비스 코드는 모델 이름이 아니라 목적을 호출해야 한다. fastSummary, codingAgent, sensitiveReview처럼 말이다. 그래야 교체 범위가 줄어든다.

모델 라우팅 기준은 비용이 아니라 실패 비용이다

많은 팀이 모델 라우팅을 비용 기준으로만 설계한다. “싼 모델 먼저, 실패하면 비싼 모델” 방식이다. 이 접근은 절반만 맞다. 더 중요한 것은 실패 비용이다.

예를 들어 내부 문서 요약이 조금 어색한 것은 큰 문제가 아닐 수 있다. 하지만 고객에게 잘못된 환불 안내를 보내거나, 코드 마이그레이션에서 잘못된 파일을 수정하거나, 보안 경고를 놓치는 것은 비용이 크다. 이런 작업은 처음부터 더 강한 모델이나 사람 승인 경로를 타야 한다.

라우팅 기준은 최소 네 가지로 나눠야 한다.

• 작업 복잡도: 단순 변환인가, 다단계 추론인가
• 실패 비용: 틀렸을 때 피해가 큰가
• 지연 허용치: 1초 안에 답해야 하는가, 30초 기다려도 되는가
• 데이터 민감도: 고객 데이터, 소스 코드, 결제 정보가 포함되는가

이 네 가지를 점수화하면 “싼 모델부터”보다 훨씬 안정적인 라우팅이 된다.

provider별 옵션을 분리하라

Codex CLI 0.155.1의 reasoning summary 기본값 변경은 좋은 사례다. 어떤 provider는 특정 옵션을 지원하고, 어떤 provider는 지원하지 않는다. 공통 설정을 모든 provider에 그대로 보내면 요청이 실패한다.

운영 코드에서는 다음을 분리해야 한다.

• 모델 ID
• reasoning 관련 옵션
• tool/function calling 포맷
• JSON schema 지원 방식
• safety 설정
• timeout과 retry 정책
• streaming 지원 여부

특히 tool calling은 provider마다 미묘하게 다르다. 같은 함수 호출처럼 보여도 인자 이름, nested object 처리, schema 엄격도, 에러 메시지가 다르다. 모델 교체 테스트에서 일반 대화만 확인하면 실제 제품에서 깨진다.

deprecation 캘린더를 만들어라

AI API의 모델 수명주기는 점점 짧아지고 있다. preview 모델은 몇 달 단위로 바뀌고, GA 모델도 alias나 접근 정책이 달라질 수 있다. 따라서 릴리즈 노트를 사람이 가끔 읽는 방식으로는 부족하다.

최소한 다음 정보를 추적해야 한다.

• 사용 중인 모델 ID
• provider
• 사용 위치
• lifecycle 상태: preview, GA, deprecated, shutdown 예정
• 대체 모델 후보
• 마지막 회귀 테스트 날짜
• 담당자

스프레드시트로 시작해도 된다. 중요한 것은 “우리 서비스가 어떤 모델에 의존하는지”를 한눈에 보는 것이다. 모델이 5개를 넘어가면 문서 없이 기억으로 운영하기 어렵다.

회귀 테스트는 프롬프트 단위로 관리하라

AI 모델 교체의 핵심은 회귀 테스트다. 일반적인 유닛 테스트처럼 항상 같은 문자열을 기대하면 안 된다. 대신 통과 조건을 정의해야 한다.

예를 들어 고객 문의 답변 생성이라면 조건은 이렇게 쓸 수 있다.

• 환불 정책 날짜를 바꾸지 않는다.
• 고객에게 내부 정책명을 노출하지 않는다.
• 답변 길이는 700자 이하로 유지한다.
• 마지막에 다음 액션을 포함한다.
• 모르면 상담원 연결을 안내한다.

코드 생성이라면 조건이 다르다.

• 변경 범위가 지정된 파일 안에 머문다.
• 테스트 명령을 제안하거나 실행한다.
• 기존 public API를 깨지 않는다.
• 민감정보를 로그에 출력하지 않는다.

이런 조건 기반 평가를 30~100개만 만들어도 모델 교체 리스크가 크게 줄어든다.

fallback은 자동이어도 승인은 자동이면 안 된다

모델 호출 실패 시 fallback은 필요하다. 하지만 모든 fallback을 자동으로 처리하면 위험하다. 단순 요약이나 내부 초안 생성은 자동 fallback이 괜찮다. 반면 외부 발송, 결제, 예약, 권한 변경, 데이터 삭제는 fallback 뒤에도 사람 승인이 필요하다.

예를 들어 기본 모델이 실패해서 대체 모델로 이메일 답변을 생성할 수는 있다. 하지만 그 답변을 고객에게 바로 보내면 안 된다. 모델이 바뀌면 문체, 보수성, 정책 해석이 달라질 수 있기 때문이다.

fallback 정책에는 다음을 포함해야 한다.

• 어떤 오류에서 fallback할지
• 어떤 모델로 fallback할지
• fallback 결과를 사용자에게 표시할지
• 외부 액션은 재승인을 받을지
• fallback 발생을 로그와 알림에 남길지

운영 체크리스트

• 코드 전체에서 모델 ID 하드코딩을 제거한다.
• 모델을 이름이 아니라 작업 목적 기준으로 호출한다.
• 작업 복잡도, 실패 비용, 지연 허용치, 데이터 민감도로 라우팅 기준을 만든다.
• provider별 옵션과 tool calling 포맷을 분리한다.
• 사용 중인 모델의 lifecycle과 shutdown 일정을 문서화한다.
• 대표 프롬프트 30~100개로 회귀 테스트 세트를 만든다.
• fallback 정책에 사람 승인 조건을 넣는다.
• 모델 교체 전후 비용, 지연 시간, 실패율을 비교한다.
• preview 모델은 핵심 경로가 아니라 실험 경로에 먼저 붙인다.

AI 모델 업데이트는 앞으로 더 잦아질 것이다. 매번 릴리즈 노트에 끌려다니지 않으려면 모델 라우팅, 회귀 테스트, deprecation 캘린더를 운영 체계로 만들어야 한다. 최신 모델을 빨리 쓰는 팀보다, 모델이 바뀌어도 장애 없이 바꾸는 팀이 오래 간다.