제미나이 3.7 플래시가 출시 3주 만에 교체됐습니다.

구글이 21일 만에 버전을 내린 게 아닙니다. 기업 환경에서 기본 추천 모델이 갱신됐습니다. 같은 ‘플래시’ 브랜드를 달고 있어도 API 응답 품질과 가격이 바뀌었습니다. 코드에 "gemini-3.7-flash"를 직접 적어둔 팀은 이걸 누군가 직접 발견해야만 알 수 있습니다.

이런 교체 주기는 앞으로 더 짧아집니다. 프론티어 모델 경쟁이 격화될수록 출시-교체 사이클은 몇 달에서 몇 주, 며칠로 좁혀집니다. 문제는 기술이 아닙니다. 라우팅 정책을 어디에 박아뒀느냐입니다.

모델 이름은 상품명이지, 역할이 아니다

에이전트 시스템에서 모델은 도구입니다. 특정 회사의 특정 버전이 아니라, “이 작업에 필요한 추론 수준”입니다.

그런데 많은 팀이 이렇게 씁니다.

response = client.messages.create(
    model="claude-sonnet-4-6",  # 버전 직접 박아둠
    max_tokens=1024,
    messages=[{"role": "user", "content": prompt}]
)

이렇게 하면 세 가지 문제가 생깁니다.

첫째, 모델 교체 비용이 코드 비용이 됩니다. 모델 하나가 바뀌면 이 문자열이 들어간 모든 파일을 찾아야 합니다. 에이전트 파이프라인이 다섯 개라면 다섯 군데를 수정해야 합니다.

둘째, 성능 측정이 불안정해집니다. “어제까지 잘 됐는데 오늘 갑자기 결과가 이상해”의 절반은 모델 버전이 조용히 바뀐 탓입니다. 동일한 harness에서 동일한 범위로만 측정해야 하는데, 모델 이름이 바뀌면 기준선도 같이 흔들립니다.

셋째, 폴백이 없습니다. 특정 프로바이더가 장애를 내면, 그 이름이 박힌 코드 전체가 멈춥니다. 2024년 이후 주요 LLM API 다운 사례는 이미 여러 차례입니다.

라우팅 정책은 기준으로 작성한다

라우팅을 잘 하는 팀은 코드 안에 모델 이름 대신 역할을 씁니다.

MODEL_CONFIG = {
    "reasoning": "claude-opus-5",       # 복잡한 판단·계획
    "execution": "claude-haiku-4-5",    # 반복 실행·포맷 정리
    "fallback": "claude-sonnet-5",      # 기본 처리
}

def get_model(task_type: str) -> str:
    return MODEL_CONFIG.get(task_type, MODEL_CONFIG["fallback"])

이렇게 하면 Gemini 3.7 Flash가 3.8로 바뀌든, Anthropic이 새 Sonnet을 내든, 업데이트할 지점이 하나입니다. 모델 이름이 아니라 선택 기준이 단일 진실의 원천(SSOT)이 됩니다.

선택 기준을 설계하는 3단계:

1단계: 작업 유형을 분류한다. reasoning(멀티스텝 판단) / execution(반복 실행) / generation(콘텐츠 생성) / verification(검증·채점)으로 나누면 됩니다. 에이전트 파이프라인의 각 단계가 어느 유형인지 명확히 합니다.

2단계: 각 유형에 성능 기준을 붙인다. “reasoning은 SWE-bench 85점 이상, 지연 5초 허용” “execution은 응답 속도 1초 이내, 비용 $0.5/M 토큰 이하” 같은 방식입니다. 기준이 있어야 모델이 바뀌어도 교체 여부를 판단할 수 있습니다.

3단계: 선택 기준을 환경 변수 또는 설정 파일로 분리한다. .env 또는 별도 routing.yaml에 놓으면, 에이전트 코드를 건드리지 않고 모델 교체가 가능합니다.

측정 기준이 라우팅보다 먼저다

모델을 교체할 때 “어떤 모델이 더 좋은지”를 판단하려면, 측정이 먼저 안정적이어야 합니다.

그런데 많은 팀이 토크나이저 기준을 명시하지 않고 비용을 비교합니다. cl100k_base는 GPT 계열 기준이고, Claude와 Gemini는 토크나이저가 다릅니다. 같은 텍스트라도 모델마다 토큰 수가 달라집니다. “A 모델이 더 저렴하다”는 결론이 토크나이저 차이에서 나온 착시일 수 있습니다.

올바른 비교는 동일한 harness에서, 동일한 입력 범위로만 합니다. 그리고 토크나이저를 명시합니다.

측정 조건: Claude Sonnet 5, Anthropic 토크나이저
입력 범위: 사용자 요청 + 시스템 프롬프트 (히스토리 컨텍스트 제외)
cl100k_base는 proxy 값으로만 병기

이 기준이 없으면 모델을 교체해도 “더 나아졌는지”를 판단할 수 없습니다. 라우팅 결정은 측정 위에 서 있어야 합니다.

기준이 있으면 교체가 두렵지 않다

구독 3개를 끊고 API 키 하나로 월 1,800원에 에이전트를 운영한 사례가 있습니다. 구독형 서비스의 고정 비용을 없애고, 실제 사용량 기반 API로 전환했을 때 나온 숫자입니다.

이게 가능한 이유는 라우팅 설계가 되어 있기 때문입니다. 어떤 작업에 어떤 수준의 모델이 필요한지 명확하고, 폴백이 있고, 측정 기준이 있어서 언제든 교체할 수 있습니다.

플래시가 3주 만에 바뀌어도 괜찮습니다. 코드에 이름을 박아두지 않았다면요.

여러분의 에이전트 시스템에는 선택 기준이 있습니까, 모델 이름이 있습니까?