지난 8월 14일, zdnet이 보도한 사실이 있습니다.

Gemini 3.7 Flash가 출시 3주 만에 교체됐습니다. 새로운 버전이 나온 게 아닙니다. 같은 Flash 라인업 안에서 이름이 비슷한 다른 모델로 조용히 대체됐습니다. 공지는 있었지만 준비할 시간은 없었습니다.

GPT-4o도 비슷한 방식이었습니다. 올해 4월 3일, API를 쓰던 팀들은 그날 아침 에러 메시지로 서비스 중단 사실을 알았습니다.

모델 교체 주기가 3개월에서 3주로 줄었습니다.

두 사건은 기술 뉴스가 아닙니다.

코드베이스에 특정 모델 이름을 하드코딩한 팀들에게는 직격탄이었습니다.

model = "gemini-3.7-flash"

한 줄이 서비스 코드에 박혀 있다면, 그 한 줄이 3주 뒤에 배포 이슈로 바뀝니다.

문제는 그 한 줄이 하나가 아니라는 것입니다. 에이전트 파이프라인에서는 오케스트레이터, 서브에이전트, 배치 작업마다 모델을 다르게 쓰는 것이 당연합니다. 어느 순간 코드베이스에 모델 이름이 12군데 박혀 있습니다. 교체할 때마다 12군데를 찾아 수정하고, 테스트하고, 배포해야 합니다. 3주 주기로.

이것이 모델 하드코딩이 단순한 기술 부채가 아닌 이유입니다.

라우팅 정책의 본체는 모델 이름 목록이 아닙니다. 선택 기준입니다.

Anthropic이 Advisor 전략에서 쓰는 방식이 이것입니다. Opus는 복잡한 판단 작업에만, 일반 실행은 저비용 모델에 — 모델 이름이 아니라 역할과 조건으로 라우팅합니다. 이 방식이면 Gemini가 교체돼도 기준을 충족하는 새 모델로 설정값 하나만 바꾸면 됩니다. 코드는 건드리지 않아도 됩니다.

실제 설계 원칙은 단순합니다:

고급 추론 작업  → 현재 기준 최상위 모델
일반 텍스트 실행 → 비용 기준 경량 모델
배치/비동기 작업 → 속도보다 단가 우선

키는 모델 이름이 아니라 작업 유형과 비용 기준입니다. 이 기준이 코드에 박혀 있으면 모델 교체는 설정 변경 한 번입니다.

실제 운영 환경에서 이 설계의 가치는 숫자로 드러납니다.

멀티 프로바이더 API 키 하나로 월 1,800원에 여러 모델을 활용하는 방식이 이미 현실입니다. skillassay의 방법론이 보여주듯, 측정 범위와 tokenizer를 먼저 검증하지 않으면 모델 비교 자체가 의미 없습니다. “어떤 모델이 좋은가”보다 “지금 이 작업에 맞는 모델을 어떻게 고를 것인가”가 먼저입니다.

프런티어 경쟁이 가속될수록 교체 주기는 더 짧아집니다. 코드베이스가 그 속도를 따라가려면 이름이 아니라 기준을 심어야 합니다.

점검 항목 하나를 드립니다.

오늘 코드베이스에서 "gpt-", "claude-", "gemini-" 로 시작하는 문자열을 검색해 보십시오.

나온 숫자가 현재 라우팅 정책 없이 쌓인 교체 비용의 규모입니다.

그 숫자가 지금 관리 가능한 수준입니까, 아니면 이미 다음 교체 때 팀 전체가 멈춰야 할 규모입니까?