Gemini 3.7 Flash가 출시 3주 만에 교체됐습니다.

단순한 버전 업데이트가 아니었습니다. 다른 모델로의 전환이었습니다. 그 모델 이름을 코드에 직접 써 두었던 팀은 그날 밤 다시 배포했습니다.

모델 교체 주기는 이제 3주입니다

6개월에 한 번이던 모델 업데이트 주기가 급격히 짧아지고 있습니다. Gemini 3.7 Flash 사례가 단적인 예입니다. 최신 벤치마크 1위 모델이 3주 뒤에 구형이 되는 속도에서, 코드에 특정 모델명을 박아 두는 것은 기술 부채를 스스로 쌓는 행위입니다.

모델 이름을 코드에 직접 쓴 팀과 라우팅 정책에 위임한 팀의 차이는 다음 출시일에 드러납니다.

”어떤 모델이 제일 좋은가”는 이제 틀린 질문입니다

모델 선택에서 자주 틀리는 출발점이 있습니다. “어떤 모델이 제일 좋은가”라는 질문 자체입니다.

4개 모델에 동일한 앱 빌드 과제를 줘봤을 때, 과제마다 승자가 달랐습니다. 코딩에서 1위였던 모델이 요약에서 1위가 아닙니다. “단일 최고 모델”은 실측에서 지지받지 못하는 개념이 됐습니다.

그래서 평가 기준이 바뀌어야 합니다. 실전에서 의미 있는 지표는 “1달러당 성능 점수”입니다. 특정 태스크 유형과 비용 예산을 함께 고려할 때, 어떤 모델이 적합한지 윤곽이 잡힙니다.

skillassay는 이 방향의 측정 방법론을 구체화했습니다. 핵심 원칙은 하나입니다. “어떻게 줄이나”보다 “제대로 재고 있나”가 선행해야 한다는 것. 컨텍스트 크기를 측정할 때도 동일 하네스로 동시에 로딩 범위만 측정해야 하고, tokenizer를 병기해야 숫자가 비교 가능합니다. 측정 방법이 틀려 있으면 라우팅 기준도 틀립니다.

라우팅 정책을 설계하는 세 가지 원칙

Anthropic은 Advisor 구조에서 이 접근을 제품으로 구현했습니다. 복잡한 판단에는 고비용 모델(Opus), 일반 실행에는 저비용 모델을 배정합니다. 단일 모델을 전체에 쓰는 게 아니라, 태스크 특성에 따라 적합한 모델을 보내는 방식입니다.

에이전트 시스템에서 라우팅 정책을 설계할 때 도움이 됐던 원칙 세 가지입니다.

태스크 특성으로 분기 기준을 잡는다. 모델 이름 대신 “이 태스크는 추론이 필요한가, 아니면 빠른 응답이 필요한가”로 분기를 만듭니다. 모델이 교체될 때 분기 기준은 그대로 유지됩니다. 교체의 영향 범위가 라우팅 매핑 테이블 하나로 줄어듭니다.

fallback을 사전에 설계한다. 특정 모델의 rate limit에 걸렸을 때 어디로 보낼지, 응답 품질이 기준치 이하일 때 어떻게 재시도할지를 미리 정합니다. 운영 중에 결정하는 것이 아니라 설계 단계에서 정해야 합니다. 이 준비가 없으면 장애는 예측 가능한 시점에 옵니다.

비용 구조는 라우팅 레이어에서 통제한다. 무거운 태스크에 항상 최고 모델을 쓰면 비용이 예측 불가능해집니다. 태스크 유형별 모델 배정과 캐시 재사용 정책을 함께 설계할 때 비용이 안정화됩니다.

코드 한 줄보다 기준 한 줄이 오래 삽니다

# 이렇게 쓰면 모델 교체 때마다 코드베이스를 열어야 합니다
model = "gemini-3.7-flash"

# 이렇게 쓰면 매핑 테이블만 업데이트합니다
model = task_router.select(task_type=TaskType.SUMMARIZE, budget_tier="standard")

gemini-3.7-flash 한 줄이 코드베이스 여러 곳에 박혀 있다면, 다음 교체 때 그 줄들을 전부 찾아야 합니다. 라우팅 레이어를 하나 두면, 다음 교체 때 매핑 테이블 하나만 바꿉니다.

모델이 빠르게 바뀌는 지금, 라우팅 정책을 코드 레벨에 분리해 두는 것이 유지보수의 핵심이 됐습니다. 모델 이름을 박은 코드는 다음 출시 때마다 부채가 됩니다. 선택 기준을 박은 코드는 다음 출시가 와도 그대로 씁니다.

지금 당신의 에이전트 코드에서 모델 이름은 몇 군데에 하드코딩돼 있습니까?