이 글은 Claude Fable 5.1 을 이용해 초안이 작성되었으며, 이후 퇴고를 거쳤습니다.

들어가며#

앞 네 편의 결론을 한 줄로 줄이면 이렇습니다. 판단이 필요한 곳(계획·리뷰·난제)에는 위 티어를, 토큰이 많은 곳(구현)에는 중가를, 정형적인 곳(읽기·테스트·문서)에는 바닥을. 이번 편은 그것을 실제 도구에서 어떻게 실행하는가입니다.

  • Part 1: 가격표, 비용의 네 가지 정의, effort 와 캐시
  • Part 2: 여섯 단계와 단계별 매핑
  • Part 3: 고가 티어의 자리
  • Part 4: 중가·저가·바닥 티어의 자리

1. Claude Code 의 전환 수단#

모두 모델 설정 문서와 서브에이전트 문서에 있는 공식 기능입니다.

1.1 세션 안에서 바꾸기#

/model                 # 선택 화면
/model fable           # 이번 세션부터 Fable 5.1
/model opus            # Opus 5
/model sonnet          # Sonnet 5
/model best            # Fable 을 쓸 수 있으면 Fable, 아니면 Opus
/model opusplan        # plan mode 는 Opus, 실행은 Sonnet
/effort low|medium|high|xhigh|max

/model 이 우선순위 최상위이고, 그 아래로 claude --model, ANTHROPIC_MODEL 환경 변수, settings.json 의 "model", ANTHROPIC_DEFAULT_MODEL 순입니다. 별칭이 가리키는 실제 모델은 ANTHROPIC_DEFAULT_FABLE_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_HAIKU_MODEL 로 바꿀 수 있습니다.

opusplan 은 이 시리즈의 전략을 한 단어로 구현한 유일한 공식 별칭입니다. 문서의 정의는 “plan mode 에서는 복잡한 추론과 아키텍처 결정에 opus, 실행 모드에서는 코드 생성과 구현에 자동으로 sonnet” 입니다. Fable 버전은 없으므로(Part 3), Fable 로 계획하려면 /model fable 로 계획을 세우고 플랜 파일로 남긴 뒤 /model opus 또는 /model sonnet 으로 내려오는 두 단계를 손으로 합니다. 계획을 새 세션에 넘기면 컨텍스트도 함께 비워집니다.

1.2 서브에이전트에 모델 고정하기#

서브에이전트 정의 파일의 frontmatter 에 model 을 씁니다. 값은 sonnet, opus, haiku, fable, 전체 모델 ID, 또는 inherit 입니다.

---
name: explorer
description: 코드베이스를 읽고 관련 파일과 구조를 요약한다
model: haiku
tools: Read, Grep, Glob
---

우선순위는 호출 시 지정 → frontmatter → CLAUDE_CODE_SUBAGENT_MODEL → 메인 모델입니다. 모든 서브에이전트를 한 모델로 강제하려면 CLAUDE_CODE_SUBAGENT_MODEL=haiku 에 CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 을 더합니다. Part 4 에서 본 것처럼 내장 Explore 는 v2.1.198 부터 메인 모델을 상속 하므로, 탐색을 싸게 하려면 이 설정이 필요합니다.

가장 짧은 방법은 Simon Willison 의 CLAUDE.md 한 줄입니다. “모든 코딩 작업에 대해 적절한 낮은 모델을 스스로 판단해 서브에이전트로 돌려라.” 모델이 라우터가 됩니다.

1.3 Advisor (실험 기능)#

/advisor opus 로 메인 모델에 조언자를 붙입니다. 조합은 Sonnet + Opus, Sonnet + Fable, Haiku + Opus 등이고, Fable 5.1 메인에는 Fable 5.1 조언자만 됩니다. 문서는 2026년 9월 현재 Anthropic API 인증에서만 동작한다고 적습니다. 구독으로 쓰는 경우에는 Part 3 의 Advisor 실측을 서브에이전트로 재현하는 수밖에 없습니다.

1.4 비용 확인#

/usage 가 세션의 토큰과 추정 비용, 모델별 사용량, 캐시 적중률을 보여 줍니다. 구독 사용자에게는 세션 비용 대신 요금제 사용량 막대와 스킬·서브에이전트·MCP 서버별 귀속 비율이 나옵니다. /insights 는 최근 세션을 분석해 HTML 보고서를 씁니다.

2. Codex 의 전환 수단#

개발자 명령 문서와 설정 참조 기준입니다.

2.1 세션 안에서 바꾸기#

/model                          # 모델과 reasoning effort 를 함께 고른다
codex -m gpt-5.6-terra          # 시작 시 지정
codex -c model_reasoning_effort=high

Astra 는 CLI 0.153 이상에서 쓸 수 있고, GitHub 의 메인테이너 답변에 따르면 초기 배포에서는 /model 선택 화면에 숨겨져 있어 -m gpt-6-astra 로 직접 지정해야 하는 경우가 있습니다. 문서상 기본값은 “권장 모델” 이고, 같은 답변에서 선택 화면의 기본은 Sol 입니다.

2.2 config.toml 과 프로파일#

model = "gpt-5.6-sol"
model_reasoning_effort = "medium"      # minimal | low | medium | high | xhigh
plan_mode_reasoning_effort = "high"    # plan mode 에서만 effort 를 올린다
review_model = "gpt-6-astra"           # /review 는 별도 모델로

[agents]
default_subagent_model = "gpt-5.6-terra"

프로파일은 $CODEX_HOME/<이름>.config.toml 로 두고 codex --profile <이름> 으로 얹습니다. sol, terra, luna 프로파일을 만들어 두고 작업 성격에 따라 시작하는 것이 커뮤니티의 관행입니다.

여기서 Claude Code 와 다른 점이 하나 있습니다. Codex 의 plan mode 는 effort 는 따로 둘 수 있지만 모델은 따로 둘 수 없습니다. plan_mode_reasoning_effort 가 있고, GitHub 토론에 따르면 “계획과 실행에 다른 모델” 은 아직 안 됩니다. 계획을 Astra 로, 구현을 Terra 로 하려면 세션을 나누거나 review_model·서브에이전트 모델로 우회합니다.

2.3 effort 사다리#

low → medium(기본) → high → xhigh → max, 그리고 Sol·Astra 에만 서브에이전트를 자동으로 띄우는 ultra 가 있습니다. 모범 사례의 배정은 “Low 는 빠르고 범위가 정해진 작업, Medium·High 는 복잡한 변경이나 디버깅, Extra High 는 길고 에이전트적인 작업” 입니다. ultra 는 토큰을 “상당히 더” 쓰므로 Daniel Vaughan 의 설정 가이드는 rollout_token_budget 으로 상한을 두라고 권합니다.

3. 에스컬레이션 규칙#

티어를 언제 올리고 내릴지의 규칙입니다. 앞 편들의 근거를 모았습니다.

flowchart TD
    S["작업 시작"] --> Q1{"단계가<br/>무엇인가"}
    Q1 -- "계획·리뷰·난제" --> HI["고가 또는<br/>중가 xhigh"]
    Q1 -- "구현·디버깅" --> MID["중가 high"]
    Q1 -- "읽기·테스트·문서" --> LO["바닥 또는 저가"]
    MID --> F1{"실패"}
    F1 -- "컨텍스트 부족" --> CTX["컨텍스트 보강 후<br/>같은 모델"]
    F1 -- "노력 부족" --> EFF["같은 모델<br/>effort 한 칸 위"]
    F1 -- "두 번째 실패" --> UP["한 칸 위 티어"]
    LO --> F2{"실패"}
    F2 -- "한 번" --> MID
    HI --> DONE["완료"]
    MID --> DONE
    LO --> DONE
    style HI fill:#FFD700,color:#000000
    style MID fill:#87CEEB,color:#000000
    style LO fill:#90EE90,color:#000000
    style UP fill:#FFD700,color:#000000
규칙근거
effort 먼저, 모델은 다음. 실패하면 “노력 부족인가 지식 부족인가” 를 묻는다Hallie (Anthropic), Anthropic 최적화 문서 “effort 스윕이 가장 싼 실험”
두 번 실패하면 한 칸 올린다. 세 번째 시도를 같은 모델로 하지 않는다Cosmic JS: “Sonnet 이 두 번 실패하면 Opus 로 한 번”. Claude Code 모범 사례: “두 번 교정 실패 후 /clear”
바로 최상위로 뛰지 않는다. 한 칸씩autoroute 의 ESCALATE 규칙: “최상위로 직행하지 않는다”
올리기 전에 컨텍스트를 채운다Böckeler: 헤맴은 빠진 것을 알려 주는 신호
계획에 없는 결정이 필요하면 멈춘다. 아래 티어가 즉흥 설계를 하지 않게TITAN 워크플로, Ivan-YYF 스킬
잘 끝난 뒤에는 내린다. 다음 작업이 정형적이면 저가로Kent Gigger: “잡일은 low 로”
쉬운 작업에 높은 effort 는 품질도 해친다HN: “쉬운 작업 + 매우 높은 추론 = 나쁨”. max 가 high 보다 낮은 벤치마크 사례

Codex 커뮤니티의 실패 처리 규칙 하나를 덧붙입니다. GitHub 의 오케스트레이션 스킬은 자식 에이전트가 “증거에 기반한 두 번의 시도가 실패하면” 멈추고 부모에게 돌려보냅니다. 세 번째 시도는 더 나은 모델이나 더 나은 정보가 있을 때만 합니다.

4. 구독 한도를 일주일 단위로 배분하기#

개인 사용자의 비용은 한도입니다(Part 1). 한도를 관리하는 규칙은 다음과 같습니다.

4.1 Claude#

  • Fable 은 주간 한도의 50% 까지 (Max·Team Premium). 이 50% 는 Part 3 의 네 자리(계획·난제·위험한 리뷰·장시간 자율 작업)에 씁니다. 50% 에 닿으면 /model opus. Pro 는 Fable 이 한도 밖이라 사용 크레딧(API 요율)이 나가므로, Pro 에서 Fable 은 정말 필요한 계획·리뷰 몇 번으로 제한하는 것이 맞습니다.
  • 모델별 한도 메시지 뒤에는 다른 계열로 바꾸면 계속 일할 수 있습니다. “Opus 한도” 에 닿으면 Sonnet 으로, 그 반대도 마찬가지입니다. 세션·주간 한도는 모든 모델 공유라 바꿔도 안 풀립니다.
  • 캐시 수명 1시간. 한 시간 넘게 자리를 비우면 첫 메시지가 컨텍스트 전체를 다시 처리합니다. 긴 세션은 자리를 비우기 전에 /compact 하거나, 돌아와서 요약으로 재개하는 것이 쌉니다. /clear 는 공짜입니다.
  • Hacker News 의 한 사용자는 “효과적인 컨텍스트 엔지니어링을 하면 20x 한도를 다 쓰기가 어렵다”, “모든 것을 최고 모델에 높은 effort 로 보내는 것이 안티패턴” 이라고 했습니다. 한도에 자주 닿는다면 티어보다 컨텍스트를 먼저 봐야 한다는 뜻입니다.

4.2 Codex#

  • Plus 기준 5시간당 Astra 5~45, Sol 10~100, Terra 25~200, Luna 250~2,000 메시지. Astra 한 메시지가 Terra 다섯 메시지 값 이라고 보면 됩니다. Pro $100 은 5배, Pro $200 은 20배.
  • Astra 는 medium 에서 시작합니다(Part 3). high 는 20분 이상 도는 에이전트 루프에만.
  • 로컬 메시지와 클라우드 작업이 같은 한도를 씁니다. 주간 한도가 따로 걸릴 수 있습니다.

4.3 두 구독을 나눠 쓰는 사람들#

Hacker News 와 X 에는 Claude Max 와 Codex 를 함께 쓰며 역할을 나누는 사용자가 여럿 있습니다. 한 사용자는 “Claude $200 과 Codex $100, 하루 10달러, 점심값보다 싸다” 고 했고, Peter Steinberger 의 codex-first 스킬은 Claude 가 “명세하고 결정하고 리뷰하고 검증” 하며 구현·테스트·rebase·PR 착지는 Astra 에 넘깁니다. 이유는 “Claude 토큰은 계량되고 비싸므로 손이 많이 가는 일은 Codex 로” 입니다. 티어 전환을 벤더 간에 하는 셈이고, 원리는 같습니다. 판단은 비싼 쪽, 물량은 싼 쪽.

5. 팀 단위 거버넌스#

API 로 쓰는 팀의 규칙은 Gergely Orosz 의 조사와 Claude Code 비용 문서에서 나옵니다.

조치근거
조직 기본 모델을 중가나 저가로 고정Orosz: 예산 초과 회사들의 1순위 대응이 “Sonnet 을 기본값으로”. Claude Code 문서: 예상 밖 지출은 “Opus 를 기본으로 둔 것” 이 흔한 원인
모델 라우팅 문서 + 비용 추적Osmani 의 MODEL_ROUTING.md. 서브에이전트 정의에 모델을 명시
월간 지출 리더보드Orosz: 여러 회사가 도입. 사용량이 눈에 보이면 습관이 바뀐다
1인당 상한과 예외 신청Orosz: “$1K/주 이상 쓰는 고급 인력은 안 보인다”
에이전트 팀은 Sonnet 으로Claude Code 문서: 팀원은 Sonnet, plan mode 팀은 표준 세션의 약 7배 토큰
캐시 적중률을 KPI 로Yegge: 96% 적중으로 정가 $87K 를 $2.8K 에. Anthropic: 캐시가 “가장 큰 레버, 2.7~5.3배”

Cursor 의 Router 처럼 벤더가 자동 라우팅을 제공하기도 합니다. 60만 건의 요청으로 분류기를 학습해 “프론티어 품질을 60% 절감으로” 냈다는 주장인데, 검증 지표가 “사용자 만족도와 유지율(keep rate)” 이라는 점을 봐야 합니다. 벤치마크가 아니라 실제 작업에서 사용자가 결과를 받아들였는지로 측정한 것입니다. 이 시리즈의 수동 라우팅은 그것을 사람이 하는 버전입니다.

6. 하루 플레이북#

Part 2 의 여섯 단계를 실제 하루에 얹어 봅니다. Claude Code Max 와 Codex 를 예로 들지만 한쪽만 써도 구조는 같습니다.

아침 — 계획 (고가, 15~30분)

새 세션을 열고 /model fable (Codex 면 -m gpt-6-astra, effort medium). 오늘 할 기능을 설명하되 단계가 아니라 결과를 설명합니다. 탐색은 Haiku 서브에이전트에 맡깁니다. 결과물은 플랜 파일입니다. 계획이 나오면 세션을 닫습니다. Fable 한도의 50% 중 이 시간이 가장 값진 사용입니다.

오전 — 구현 (중가, 2~3시간)

새 세션에서 /model opus (Codex 면 Sol medium 또는 Terra high). 플랜 파일을 주고 구현합니다. 테스트·기대 출력 같은 검증 목표를 프롬프트에 넣습니다. 작업 단위가 바뀌면 /clear. 정형적인 편집이 이어지면 /effort low 나 Sonnet 으로 내립니다.

실패 처리 — 에스컬레이션

컨텍스트가 부족했으면 채워서 다시. 노력이 부족했으면 /effort xhigh. 두 번째 실패면 /model fable 로 그 문제 하나만 풀고 다시 내려옵니다.

오후 — 리뷰 (고가, 새 컨텍스트)

구현 세션을 닫고 새 세션에서 Fable 또는 Opus 로 diff 를 리뷰합니다. 위험한 변경(인증, 결제, 마이그레이션)이면 Fable, 국소 변경이면 Opus. Codex 사용자는 review_model = "gpt-6-astra" 로 /review 를 돌리거나, 다른 벤더의 상위 모델로 교차 검토합니다.

저녁 — 정리 (바닥)

테스트 보강, 문서, 커밋 메시지는 Haiku·Luna 서브에이전트 또는 /model sonnet 에 /effort low. 좋은 결과가 무엇인지 아는 일만 여기 둡니다.

주말 전 — 한도 점검

/usage 로 주간 한도와 모델별 귀속 비율을 봅니다. Fable 이 50% 에 가까우면 남은 계획·리뷰만 Fable 로 하고 나머지는 Opus. 캐시 적중률이 낮으면 티어를 바꾸기 전에 세션 길이와 자리 비움 습관을 고칩니다.

7. 암기표#

단계Claude CodeCodexeffort왜
① 탐색Haiku 서브에이전트 (model: haiku)Luna 또는 Terra 서브에이전트low읽기는 가장 싼 일. 판단 없음
② 계획Fable (한도 50% 안에서) 또는 OpusAstra medium 또는 Sol highhigh~xhigh토큰 적고 실수의 대가 최대
③ 구현Opus (기본). 명세가 정확하면 SonnetSol medium. 명세가 정확하면 Terra highhigh세션 토큰의 40% 이상. 재작업 위험을 산다
④ 디버깅Opus xhigh → 두 번 실패 시 FableSol high → Astraxhigh노력 부족이면 effort, 지식 부족이면 모델
⑤ 리뷰위험한 변경 Fable, 국소 Opus. 새 컨텍스트review_model 을 Astra 로. 또는 교차 벤더high놓친 버그의 대가
⑥ 정리Sonnet low 또는 HaikuLunalow좋은 결과가 명확한 일

그리고 티어 전환 전에 확인할 세 가지. 캐시가 살아 있는가(세션 길이, 자리 비움), effort 가 작업에 맞는가(쉬운 일에 max 는 손해), 컨텍스트가 충분한가(헤맴은 빠진 것의 신호).

8. 마무리 — 이 시리즈가 말하지 않은 것#

세 가지를 정직하게 적어 둡니다.

첫째, 숫자는 2026년 9월의 것입니다. Sonnet 5 의 가격은 두 달 사이에 “인상 예정” 에서 “정식 가격” 으로 바뀌었고, Sol 은 프로모션 가격이며, Luna 는 두 달 만에 80% 내렸습니다. 이 블로그의 인용 규칙대로 당해 연도 자료만 썼지만, 이 분야는 6개월이면 결론이 뒤집힙니다. 티어 간격이 바뀌면 Part 4 의 “작은 모델 + 높은 effort” 같은 요령은 성립 조건이 달라집니다.

둘째, reddit 을 직접 읽지 못했습니다. 2026년 9월 현재 reddit 은 자동화된 접근을 차단하고 있어, 커뮤니티 의견은 Hacker News 의 대형 스레드와 X, GitHub, dev.to 로 대신했습니다. reddit 의 r/ClaudeCode, r/codex 등에는 여기 담지 못한 다른 결의 증언이 있을 것입니다.

셋째, Part 2 의 비용 계산은 실측이 아니라 가정입니다. 단계별 토큰 배분은 기능 하나를 구현하는 전형적인 세션을 상정한 것이고, 고가 모델의 토큰 효율(Astra 가 Fable 5.1 의 3분의 1 토큰)과 저가 모델의 재작업은 넣지 않았습니다. 자기 작업의 실제 분포는 /usage 의 모델별 귀속으로 직접 재는 것이 맞습니다.

그럼에도 남는 결론은 단순합니다. 모델 티어는 “어떤 모델이 좋은가” 의 문제가 아니라 “이 단계에서 실수하면 얼마가 드는가” 와 “이 단계의 토큰이 얼마나 되는가” 의 문제 입니다. 두 질문에 답하면 티어는 저절로 정해집니다.

References#

공식 문서·공식 블로그 (2026)

테크블로거·분석 (2026)

커뮤니티 (2026)