단일 모델에 의존하는 건 단일 장애점(Single Point of Failure)을 심는 것과 같다. 2026년 LLM 시장은 3개월마다 판도가 바뀐다. 네가 의존하는 모델 제공사가 내일 어떤 결정을 내릴지 아무도 모른다. 가격을 올릴 수도 있고, Rate Limit을 바꿀 수도 있고, 아예 서비스를 접을 수도 있다. 그때 가서 급하게 옮기려면 시스템 전체를 까뒤집어야 한다.

나는 이걸 Claude ID verification 사건 때 실감했다. 어느 날 갑자기 Claude Pro 구독자만 API를 쓸 수 있게 바뀌었다. 내가 짜둔 Anthropic 루트 전체가 한 방에 박살난 거다. 그날 이후로 나는 “어떤 모델이 가장 똑똑한가”보다 “이 모델이 사라져도 시스템이 돌아가는가”를 먼저 묻는다.

이게 내가 Flash / Pro / Max 3-tier로 모델을 계층화한 진짜 이유다. 비용 최적화? 맞다. 근데 그건 부차적인 거고, 진짜 목적은 위험 분산이다. 모델 하나가 내려가도 다른 모델로 갈아타는 데 30초면 된다. config 한 줄 바꾸는 걸로 끝난다.

왜 하나로 안 했는가

처음엔 나도 하나였다. “가장 똑똑한 모델 하나 골라서 다 때려박으면 되지”라는 발상. 실제로 나는 초기 몇 달 동안 단일 모델로 다 돌렸다. 대화도, 코드 생성도, cron 작업도, 트렌드 분석도 전부 같은 모델에 쑤셔넣었다.

문제는 세 가지였다. Rate Limit — 429가 일상. 적합성 — 모든 task가 같은 IQ를 필요로 하지 않는다. 의존성 — 하나가 터지면 모든 게 멈췄다.

3-tier의 실제 — Flash, Pro, Max

Flash — 대화, cron, kanban worker, 간단 구현. deepseek-v4-flash. 전체 호출의 85%.

Pro — 코드 리뷰, 복잡도 작업. deepseek-v4-pro. reviewer, implementer.

Max — 복잡한 추론, 계획, 심층 리뷰. qwen3.7-max. 가장 느리지만 가장 강력.