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

들어가며#

Part 2 의 계산에서 한 가지가 분명해졌습니다. 계획과 리뷰는 세션 전체 토큰의 10% 안팎이라 고가 티어로 올려도 합계가 거의 움직이지 않고, 구현은 40% 이상이라 고가 티어로 두면 합계가 두 배가 됩니다. 이번 편은 그 앞부분, 즉 고가 티어(Claude Fable 5.1, GPT-6 Astra)를 어디에 써야 하고 어디에 쓰면 안 되는지를 다룹니다.

1. 벤더가 스스로 정한 자리#

두 회사의 문서는 최상위 모델의 용도를 꽤 좁게 정의합니다. 이 점이 의외로 자주 무시됩니다.

Anthropic 의 모델 선택 가이드는 “대부분의 워크로드는 Opus 5 에서 시작” 하고, Fable 5.1 은 “xhigh 나 max effort 에서도 평가가 모자랄 때” 옮기라고 합니다. Claude Code 의 모델 설정 문서에는 “Fable 을 잘 쓰는 법” 네 가지가 있습니다.

공식 지침뜻
단계가 아니라 결과를 설명하라경로를 스스로 계획하게 둔다
모호한 문제를 넘겨라“근본 원인 조사, 장애 디버깅, 아키텍처 결정” 에서 추가 조사와 검증이 값을 한다
검증 리마인더를 생략하라스스로 검증하므로 “테스트해라” 를 덧붙일 필요가 없다
큰 작업을 통째로 줘라보통 쪼개서 주던 일을 한 번에 준다. 긴 세션에서 흐름을 잃지 않는다

OpenAI 의 Codex 모델 문서는 Astra 를 “여러 단계와 도구를 가로지르는 가장 강한 능력이 필요한 작업” 으로, Sol 을 “모호하거나 어렵거나 가치가 높은 작업” 으로 정의합니다.

두 정의의 공통분모는 판단 입니다. 모호함을 걷어 내는 일, 여러 단계를 스스로 이어 가는 일, 스스로 검증하는 일. 정해진 코드를 대량으로 찍어 내는 일은 어디에도 없습니다.

Anthropic 의 Lydia Hallie 는 effort 와 모델 선택 글에서 이것을 진단 질문 하나로 압축했습니다. 모델이 실패했을 때 “충분히 노력하지 않았는가, 아니면 충분히 알지 못했는가.” 전자면 effort 를 올리고, 후자면 모델을 올립니다. 그리고 “필요한 컨텍스트를 다 가지고 분명히 노력했는데도 틀렸다면, 그것이 더 큰 모델로 갈 신호” 라고 덧붙입니다.

2. 자리 ① — 계획과 설계#

Hacker News 와 X 에서 가장 많이 반복된 워크플로가 “고가로 계획하고 그 아래로 구현” 입니다. 커뮤니티 조사에서 17개 이상의 독립된 출처가 같은 패턴을 보고했습니다.

  • Claude Code 에는 opusplan 이라는 공식 별칭이 있습니다. plan mode 에서 Opus, 실행 모드로 나오면 자동으로 Sonnet 입니다. Fable 버전의 fableplan 은 없습니다. 2026년 6월에 올라온 GitHub 이슈들은 “not planned” 로 닫혔습니다. 그래서 Nathan Danielsen 은 직접 만든 스킬에 model: fable, effort: xhigh 를 박고 읽기는 Haiku·Sonnet 서브에이전트에 맡깁니다. 그의 표현으로 “실행 요율로 아키텍처를 사는 것이 비싼 실수” 입니다.
  • Steve Yegge 의 에이전트 도시에서 계획을 맡은 18개 에이전트는 Fable 5 이고, 그 아래 노동자는 Opus 5, 프로덕션 역할은 대부분 Sonnet 입니다.
  • Addy Osmani 의 CodeCon 발표는 계획·아키텍처를 최상위 모델에, 구현을 한두 칸 아래에 두고 MODEL_ROUTING.md 로 작업 유형과 모델을 매핑하라고 권합니다.

왜 여기인가. Part 2 의 표에서 계획은 실수의 대가가 가장 큰 단계 이면서 토큰은 가장 적은 단계 입니다. 고가 티어의 단가 프리미엄이 가장 작은 금액으로 가장 큰 재작업 위험을 덮습니다.

한 가지 반론이 있습니다. Boris Cherny 는 2026년 6월 “새 모델은 계획 단계가 사실상 필요 없다” 며 명시적 plan mode 를 그만두었습니다. 그는 모든 일을 최상위 모델로 하니 계획을 따로 뗄 이유가 없다는 입장입니다. 아래 티어로 구현할 계획이라면 이 반론은 적용되지 않습니다. 구현 모델이 따라갈 계획서를 만드는 것이 이 단계의 목적이기 때문입니다.

3. 자리 ② — 모호한 문제와 난제 디버깅#

“어려운 디버깅” 은 두 회사 문서 모두에서 상위 티어 또는 상위 effort 의 자리입니다. Codex 모범 사례는 “Medium 이나 High 는 더 복잡한 변경이나 디버깅” 으로, Anthropic 문서는 “근본 원인 조사, 장애 디버깅” 을 Fable 의 자리로 적습니다.

커뮤니티 증언은 구체적입니다.

  • 10년 된 크래시 버그를 Opus 4.6 이 첫 시도에 고쳤다는 보고.
  • Fable 이 “비즈니스 로직을 풀어 생각하는 데 확연히 낫다” 는 보고. 설계 논의, 아이디어 검토에 Fable 을 쓴다는 보고가 여럿입니다.
  • max effort 로 돌렸더니 경쟁 조건(race condition)을 찾아냈다는 Kent Gigger 의 글. 그의 규칙은 “high 에서 시작, 잡일은 low 로, 막히면 max”.

여기서 순서가 중요합니다. 바로 고가로 가지 않습니다. Hallie 의 진단대로 먼저 effort 를 올려 봅니다. Part 1 에서 본 것처럼 같은 모델 안에서 effort 는 33배의 폭을 갖고, Anthropic 의 최적화 문서는 “effort 스윕이 이 페이지에서 가장 싼 실험이고 대부분의 워크로드는 거기서 끝난다” 고 합니다. 중가 모델이 xhigh 에서, 컨텍스트를 다 가진 채로 실패했을 때가 고가로 갈 시점입니다.

이것을 흐름으로 그리면 다음과 같습니다.

flowchart TD
    A["중가 모델 실패"] --> B{"컨텍스트가<br/>충분했는가"}
    B -- 아니오 --> C["컨텍스트 보강<br/>(로그·재현·관련 파일)"]
    C --> A
    B -- 예 --> D{"effort 를<br/>올려 봤는가"}
    D -- 아니오 --> E["같은 모델<br/>xhigh 로 재시도"]
    E --> A
    D -- 예 --> F["고가 모델로 에스컬레이션"]
    style A fill:#87CEEB,color:#000000
    style F fill:#FFD700,color:#000000
    style C fill:#90EE90,color:#000000
    style E fill:#90EE90,color:#000000

Birgitta Böckeler 의 하네스 엔지니어링 메모는 첫 번째 분기를 강조합니다. 에이전트가 헤맬 때 그것을 “무엇이 빠졌는지 알려 주는 신호” 로 보라는 것입니다. 모델을 올리기 전에 컨텍스트를 채우는 것이 더 싸고, 다음번에도 효과가 남습니다.

4. 자리 ③ — 위험한 변경의 리뷰#

리뷰는 직관에 반하는 자리입니다. “읽기만 하니 싼 모델로 충분하지 않은가” 라고 생각하기 쉬운데, 커뮤니티에서 고가 티어를 일상 모델로는 안 써도 리뷰에는 쓴다 는 증언이 8개 이상 나왔습니다.

  • Fable 5.1 발표 스레드에서 “리뷰가 incredible” 하다는 보고. Astra 를 “버그를 사냥하는 hunter seeker” 로 쓴다는 보고.
  • 한 사용자는 “Sol 이 코드 리뷰를 너무 잘해서 Astra 는 가장 위험한 변경에만 쓴다” 고 했습니다. 리뷰 모델을 변경의 복잡도로 고른다 는 뜻입니다.
  • 2026년 9월 14일 Hacker News 의 Luna 대 Astra 코드 리뷰 스레드에서 인용된 Entelligence 측정은 Luna 의 발견 정확도 74%, Astra 96% 였습니다. Luna 가 28배 싸지만, 리뷰에서 놓친 22% 포인트는 프로덕션으로 갑니다.
  • Simon Willison 은 sqlite-utils 4.0 작업에서 최종 리뷰어로 GPT-5.5 를 xhigh 로 썼습니다. 다른 벤더의 상위 모델로 교차 검토하는 패턴입니다.

Matt Pocock 의 워크숍은 조건을 하나 더 답니다. 리뷰어는 새 컨텍스트에서 돌려야 합니다. 구현자의 부풀어 오른 컨텍스트를 공유하는 리뷰어는 “리뷰 대상보다 멍청하다” 는 것입니다. 그는 유용한 “똑똑한 구간” 이 1M 창과 무관하게 10만 토큰 근처에서 끝난다고 봅니다. Claude Code 의 모범 사례가 보여 주는 security-reviewer 서브에이전트 예시가 model: opus 를 지정하는 것도 같은 맥락입니다. 서브에이전트는 자기 컨텍스트에서 시작합니다.

리뷰가 고가 티어에 맞는 이유는 계획과 같습니다. 토큰은 적고(diff 를 읽고 지적 사항을 쓴다), 실수의 대가는 큽니다.

5. 자리 ④ — 장시간 자율 작업#

Anthropic 의 “큰 작업을 통째로 줘라” 는 지침과 “몇 시간씩 도는 에이전트 세션” 이라는 모델 선택 가이드의 표현은 같은 것을 가리킵니다. 커뮤니티에서도 “5시간 이상 연속으로 자율 작업할 때 Fable 이 특히 뛰어나고, 서브에이전트를 쓸 때 더 그렇다” 는 보고가 있습니다. Every 의 Vibe Check도 Fable 5.1 을 “긴 코딩 작업과 위임된 빌드” 에 권합니다.

다만 이 자리에는 경고가 붙습니다.

  • Hacker News 의 한 사용자는 Fable 을 plan mode 에서 high effort 로 돌렸더니 “아무것도 출력하지 않은 채 5시간 세션을 다 썼다” 고 보고했습니다.
  • Team Premium 사용자는 첫 작업에서 “약 30분 만에” 5시간 한도에 닿았고, Max 20x 사용자는 “한 시간이 안 되어” 닿았습니다.
  • Willison 의 sqlite-utils 작업은 37개 프롬프트에 $149 였고 그중 $141 이 Fable 이었습니다.

장시간 자율 작업에 고가 티어를 쓰는 것은 옳지만, 그 안에서도 읽기와 구현은 아래 티어의 서브에이전트에 넘기는 것 이 Willison 의 회고이자 Danielsen 의 설계입니다. 고가 모델은 오케스트레이터로 남고, 물량은 아래로 내려갑니다. Part 4 에서 이어집니다.

6. 고가 모델을 “부르는” 방식 — Advisor 패턴#

고가 티어를 상시 실행자가 아니라 필요할 때 호출하는 조언자로 두는 패턴이 2026년 7월 Anthropic 에서 공식화되었습니다. 실행자(executor)는 중가나 저가 모델이고, 막히거나 결정이 필요할 때 고가 모델(advisor)에게 묻습니다.

Anthropic 의 최적화 문서가 공개한 실측입니다.

구성결과
Opus 5 실행자 + Fable 5.1 조언자측정한 구성 중 가장 정확. Opus 5 단독보다 3.5점 높으면서 “약간 더 싸게”. 과제당 $7.69, 과제당 약 2회 상담
Sonnet 5(low) 실행자 + Fable 5.1 조언자, DeepSWE계속 물어봐서 23점 상승
같은 구성, SWE-bench Pro실행자가 물어보기를 멈춤. 효과 없음
차트 읽기 과제거의 매 과제 상담. Fable 5.1 단독(medium)과 같은 점수를 2.6배 비용 으로

마지막 줄이 이 패턴의 조건입니다. 상담률이 낮을 때만 싸집니다. 실행자가 대부분의 과제에서 물어본다면 조언자 요율을 전체 워크로드에 내는 셈입니다. 문서는 “먼저 상담률을 측정하라” 고 합니다.

Claude Code 에는 이 패턴을 위한 Advisor 도구가 있습니다. /advisor opus 처럼 쓰고, “Sonnet 메인 + Opus 조언자” 는 “일상 작업은 Sonnet 이 하고 계획·모호한 실패·완료 확인을 Opus 에 올린다” 로 설명됩니다. 문서는 “빠른 메인 모델에 강한 조언자를 붙이는 것이 강한 모델을 내내 돌리는 것보다 보통 싸다” 고 적습니다. 다만 실험 기능이고 2026년 9월 현재 Anthropic API 인증에서만 동작 합니다. 구독 사용자는 서브에이전트나 플랜 파일로 같은 구조를 흉내 내야 합니다. Anthropic 의 개발자 계정이 X 에 올린 이 패턴 소개는 3만 회 이상 좋아요를 받았고, 커뮤니티에서는 React 리팩터 한 건에서 Fable 토큰 4,200 대 Sonnet 토큰 38,000(7% 대 93%) 같은 비율이 보고되었습니다.

7. 쓰면 안 되는 자리#

같은 출처들이 고가 티어의 오용 도 명확히 지목합니다.

오용근거
구현 물량 전체Willison: $149 중 $141. “더 싼 모델의 서브에이전트에 기댔어야 했다”
설정 파일·정형 편집HN: “Opus 에게 config 편집을 시키는 건 그냥 어리석다”
코드베이스 읽기Danielsen: “조사는 대부분 읽기이고 읽기는 가장 싼 일”
plan mode 에서 높은 effort 로 방치HN: 5시간 세션을 출력 없이 소진
리뷰어를 여럿 병렬로Thariq: “대부분의 코딩 작업에는 리뷰어 다섯이 필요 없다”. HN: Astra 리뷰 오케스트레이션이 “하루 구독의 절반을 한 시간에”

여기에 예외가 하나 있습니다. Part 1 에서 본 Anthropic 의 측정에서 Fable 5.1 은 low effort 로 SWE-bench Pro 를 Sonnet 5 보다 11점 높게, 해결 과제당 35% 싸게 풀었습니다. 그리고 Astra 는 같은 점수를 Fable 5.1 의 3분의 1 토큰으로 냅니다. 범위가 명확한 단일 과제 에서는 고가 모델을 낮은 effort 로 돌리는 것이 저가 모델보다 쌀 수 있습니다. Hacker News 의 한 사용자가 Astra 를 “단일 목적의, 잘 명세된 작업” 에 쓴다고 한 것이 이 경우입니다. 반대로 긴 루프에서 토큰이 25~150% 늘었다는 보고는 이 예외의 경계를 보여 줍니다. 요컨대 “고가 = 물량 금지” 의 예외는 “짧고 명확한 과제 + 낮은 effort” 입니다.

8. 한도라는 현실#

구독 사용자에게 고가 티어는 달러가 아니라 한도의 문제입니다.

  • Claude: Max·Team Premium 에서 Fable 은 주간 한도의 50% 까지. Pro 에서는 한도 밖이라 API 요율의 사용 크레딧. Claude Code 문서에 따르면 세션·주간 한도는 모든 모델에 공유되어 /model 로 바꿔도 풀리지 않지만, “Opus 한도” 나 “Sonnet 한도” 같은 모델별 한도 메시지 뒤에는 다른 계열로 바꾸면 계속 일할 수 있습니다. 커뮤니티의 관행은 Fable 을 50% 까지 쓰고 /model opus 로 넘어가는 것입니다.
  • Codex: Plus 에서 5시간당 Astra 5~45 메시지, Sol 10~100, Terra 25~200. 도움말은 “Astra 가 Sol 보다 한도를 더 빨리 소모한다” 고 적고, Plus 와 Business Standard 의 Astra 는 제한적입니다.

Astra 로 옮긴 Codex 사용자들의 조언은 일관됩니다. dev.to 의 Sol → Astra 전환기는 같은 과제를 Astra medium $25.67(51분), Astra high $37.23(77분), Sol high $31.79(75분)로 측정하고 “medium 에서 시작하라” 고 결론짓습니다. 다른 전환기는 “medium 으로 두고, medium 이 실패하는 것을 보여 줄 수 있는 작업에서만 올려라” 고 합니다. OpenAI 의 마이그레이션 가이드도 낮은 effort 에서 시작해 비교하라고 합니다.

9. Part 3 의 규칙#

자리고가 티어이유
계획·설계·명세쓴다토큰 적고 실수의 대가 최대. 아래 티어가 따라갈 계획서를 만든다
모호한 문제·난제 디버깅중가 xhigh 실패 후 쓴다Hallie 의 진단: 노력 부족이면 effort, 지식 부족이면 모델
위험한 변경의 리뷰쓴다, 새 컨텍스트에서놓친 버그의 대가. 리뷰어는 구현자의 컨텍스트를 공유하지 않는다
장시간 자율 작업오케스트레이터로 쓴다읽기·구현은 아래 티어 서브에이전트로
구현 물량·정형 편집·읽기안 쓴다세션 토큰의 대부분. 예외는 “짧고 명확한 과제 + 낮은 effort”
Advisor 로상담률이 낮을 때만매번 물어보면 2.6배

다음 편은 사다리의 아래쪽입니다. 중가 티어가 왜 2026년 여름 이후 구현의 기본값이 되었는지, 저가 티어는 어떤 조건에서 충분한지, 바닥 티어가 맡는 일은 무엇인지, 그리고 아래 티어의 실패 모드를 어떻게 막는지 다룹니다.

References#

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

테크블로거·분석 (2026)

커뮤니티 (2026)