가벼운 모델부터 올리는 구독 모델 라우팅

핵심 요약

• 6편의 목표는 제품 이름이 아니라 작업 난이도에 따라 가벼움·표준·심층의 세 단계 모델 사다리를 만드는 것임
• 검색·요약·명확한 단일 파일 수정은 가벼운 단계, 일반 구현은 표준 단계, 교차 영역 설계와 어려운 디버깅은 심층 단계에 배정함
• 상향은 두 번의 독립 가설 실패·세 영역 이상의 변경·상충하는 제약처럼 관찰 가능한 조건에서만 수행함
• 강한 모델로 계획한 뒤 표준 모델로 구현하는 하향 경로도 있어야 비싼 추론을 모든 턴에 반복하지 않음
• 이 편의 산출물인 routing-policy.md는 7편에서 여러 구독에 역할을 배정하는 공통 규칙이 됨

모델이 아니라 작업을 먼저 분류함

• 1단계는 결과를 쉽게 검증할 수 있는 짧은 작업임

  • 파일 위치 찾기, 로그 요약, 문서 형식화, 명확한 단일 파일 수정이 해당함
  • 테스트나 정답 키가 있어 오류를 빠르게 발견할 수 있어야 함

• 2단계는 일반적인 제품 구현과 리뷰임

  • 두세 파일의 기능 추가, 회귀 테스트 작성, 알려진 패턴의 리팩터링이 해당함
  • 대부분의 작업은 이 단계의 기본 모델에서 시작함

• 3단계는 실패 비용과 추론 결합도가 큰 작업임

  • 여러 패키지를 가로지르는 리팩터링, 재현이 어려운 결함, 아키텍처와 보안 결정이 해당함
  • 강한 모델의 추가 사용량보다 잘못된 대규모 변경의 재작업이 더 클 때 선택함

• 긴 입력과 어려운 추론을 혼동하면 안 됨

  • 5편의 출력 예산으로 로그를 줄인 뒤에도 가설을 구분하기 어려울 때 난이도가 높다고 판단함
  • 저장소가 크다는 이유만으로 항상 심층 모델을 선택하지 않음

공급자별 모델을 같은 사다리에 매핑함

• Codex는 계정에 보이는 모델 중 가벼운 탐색·일상 코딩·복잡한 문제 역할을 매핑함

  • OpenAI는 높은 추론 강도가 복잡한 작업에 도움이 될 수 있지만 더 느리고 토큰을 더 쓴다고 안내함¹
  • 실제 모델 이름과 제공 여부는 바뀔 수 있으므로 Codex의 현재 모델 선택 화면을 기준으로 갱신함

• Claude Code는 Haiku → Sonnet → Opus의 역할 구분을 공식 안내함²

  • Anthropic은 대부분의 코딩에 Sonnet, 빠른 조회와 단순 수정에 Haiku, 어려운 리팩터링·디버깅·설계에 Opus를 제시함
  • Opus로 계획하고 Sonnet으로 실행하는 경로도 공식 예시로 설명함

• Gemini CLI도 계정에 제공되는 빠른 모델과 깊은 추론 모델을 역할에 맞춰 선택함

  • 정확한 모델 이름과 한도는 구독·지역·시점에 따라 달라질 수 있음
  • 이 글은 특정 버전을 영구 추천하지 않고 현재 /model 선택지와 동일 작업 측정을 우선함

• 표는 성능 순위가 아니라 시작점 규칙임
  • 같은 모델도 저장소와 언어에 따라 완료율이 달라질 수 있음
  • US$20 구독에서 특정 모델의 제공 여부나 별도 한도는 계정의 현재 표시를 확인해야 함

상향과 하향 조건을 대칭으로 만듦

• 모델 상향은 불만이 아니라 증거로 결정함

  • 서로 다른 두 가설이 검증에서 실패함
  • 수정 범위가 세 개 이상의 책임 영역으로 확장됨
  • 보안·데이터 손실·공개 API 호환성처럼 실패 비용이 큰 판단이 나타남
  • 요구 사항 두 개가 충돌해 우선순위 결정이 필요함

• 강한 모델의 결과가 계획으로 닫히면 다시 하향함

  • 후보 파일·불변 조건·단계·검증 명령이 확정되면 표준 모델이 구현함
  • 구현 모델에는 대화 전문 대신 확정된 계획과 관련 증거만 넘김

• 세 번째 모델로 같은 실패를 반복하는 것은 라우팅 문제가 아닐 수 있음

  • 재현 절차·완료 조건·테스트가 불명확하면 먼저 작업 계약을 고침
  • 공급자를 바꾸기 전에 사람이 결정해야 할 제품 요구 사항이 남아 있는지 확인함

속도 모드도 사용량과 함께 평가함

• 빠른 출력은 토큰 절감과 같은 개념이 아님

  • Kimi는 HighSpeed가 같은 코딩 능력에서 약 5~6배 빠르지만 약 3배의 크레딧을 사용한다고 안내함³
  • 대기 시간이 병목인 짧은 반복에는 가치가 있을 수 있지만 한도 지속 시간이 목표라면 기본값으로 두기 어려움

• 추론 강도와 속도 모드는 사람 시간까지 포함해 선택함

  • 기다리는 동안 다른 일을 할 수 있으면 느린 표준 모드의 비용이 작을 수 있음
  • 장애 대응처럼 10분의 지연이 큰 손실을 만들면 추가 소진이 합리적일 수 있음

• 작성자의 권장 지표는 모델별 수용 작업/할당량과 수용 작업/시간 두 축임

  • 한 축만 보면 빠르지만 비싼 모드 또는 느리지만 실패가 많은 모드를 잘못 선택할 수 있음

라우팅 정책을 기준선으로 검증함

• 2편의 작업 표본에 예상 난이도와 실제 상향 단계를 추가함

  • initial_tier, final_tier, escalation_reason, accepted를 기록함
  • 처음부터 심층 모델을 쓴 기준선과 사다리를 쓴 실험군을 같은 유형끼리 비교함

• 절감 성공은 심층 모델 사용 비율만 낮추는 일이 아님

  • 완료 작업당 소진량이 감소해야 함
  • 수용률과 재작업 시간이 유지되어야 함
  • 상향 전 실패에서 버린 변경량이 늘지 않아야 함

• 상향이 절반을 넘으면 분류 기준이나 기본 단계가 틀렸을 수 있음

  • 해당 저장소의 일상 작업 난도가 표준 정의보다 높을 가능성이 있음
  • 가벼운 모델의 실패가 반복되면 그 작업 유형만 시작 단계를 올림

다음 편으로 역할 정책을 넘김

• routing-policy.md는 모델 이름보다 작업 역할과 상향 조건을 먼저 기록함

  • 제품이 모델을 교체해도 정책을 다시 쓸 필요가 줄어듦
  • 계정에서 실제 제공되는 모델 매핑만 별도 표로 갱신함

• 7편에서는 모델 단계와 구독 역할을 결합함

  • 탐색 구독, 주 구현 구독, 독립 리뷰 구독이 같은 작업을 중복 수행하지 않게 함
  • 한도 도달은 공급자 전환의 조건이지만 대화 전문을 복사하는 조건은 아님

실행 제안

• 지난 20건에 난이도 단계를 사후 표기하고 실제 실패·재작업과 맞았는지 확인해야 함
• 다음 10건은 가장 가벼운 적합 단계에서 시작하고 정해진 신호에서만 한 단계 올려야 함
• 모델 이름과 제공 범위는 월 1회 공식 문서와 계정 화면으로 재검증해야 함

Footnotes

1. OpenAI, Codex 모델 — 추론 강도와 토큰·지연의 관계 및 현재 모델 선택을 설명함 ↩

2. Anthropic, Claude Code의 모델·사용량·한도 — Haiku, Sonnet, Opus의 권장 역할과 모델 전환 방식을 설명함 ↩

3. Kimi, Kimi Code 멤버십 가이드 — HighSpeed의 속도와 크레딧 사용량 차이를 설명함 ↩