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

들어가며#

Part 1 에서 세 티어의 가격표를 검증하고, 토큰 단가와 작업당 비용이 다르며, effort 와 캐시가 티어보다 큰 레버라는 것을 확인했습니다. 이번 편은 바이브 코딩 세션을 단계로 쪼개는 일 입니다. “어느 모델이 좋은가” 라는 질문은 단계를 나누기 전에는 답이 없습니다. 같은 세션 안에서도 토큰이 소비되는 모양과 실수의 대가가 단계마다 다르기 때문입니다.

1. 여섯 단계#

바이브 코딩 세션은 대체로 다음 순서로 흐릅니다. 이름은 이 시리즈에서 쓰기 위해 붙인 것이고, Claude Code 의 모범 사례 문서가 권하는 “먼저 탐색하고, 계획하고, 그다음 코드를 쓴다” 는 순서와 Codex 모범 사례의 “하나의 대화에 하나의 작업 단위” 원칙을 합친 것입니다.

flowchart LR
    E["① 탐색<br/>코드베이스 읽기"] --> P["② 계획<br/>설계·명세"]
    P --> I["③ 구현<br/>코드 작성"]
    I --> D["④ 디버깅<br/>실패 원인 찾기"]
    D --> I
    I --> R["⑤ 리뷰<br/>검증·비판"]
    R --> C["⑥ 정리<br/>테스트·문서·커밋"]
    R -. 되돌림 .-> P
    style E fill:#E0E0E0,color:#000000
    style P fill:#FFD700,color:#000000
    style I fill:#87CEEB,color:#000000
    style D fill:#87CEEB,color:#000000
    style R fill:#FFD700,color:#000000
    style C fill:#90EE90,color:#000000
단계하는 일입력 대 출력실수의 대가
① 탐색파일을 읽고, 구조를 파악하고, 관련 코드를 찾는다입력이 압도적. 출력은 요약 몇 줄낮음. 놓친 것은 다음 단계에서 다시 읽으면 된다
② 계획설계 결정, 명세 작성, 작업 분해입력 중간, 출력 적음매우 높음. 틀린 결정이 ③④⑤ 전체를 오염시킨다
③ 구현코드를 쓰고 파일을 고친다입력·출력 모두 많음. 세션에서 가장 큰 덩어리중간. 테스트가 잡아 주면 낮고, 없으면 높다
④ 디버깅실패의 원인을 찾고 고친다입력 많음(로그·스택), 출력은 작은 수정높음. 원인을 잘못 짚으면 루프에 빠진다
⑤ 리뷰결과를 비판적으로 검증한다입력 많음(diff), 출력은 지적 사항높음. 놓친 버그는 프로덕션까지 간다
⑥ 정리테스트 보강, 문서, 커밋 메시지, 포맷입력 적음, 출력 정형적낮음. 무엇이 좋은 결과인지 명확하다

이 표에서 두 열이 티어 선택을 결정합니다.

  • 입력 대 출력 비율 은 어느 단가가 지배하는지 정합니다. 탐색처럼 입력이 압도적인 단계는 입력 단가(그리고 캐시 단가)가 비용을 정합니다. 구현처럼 출력이 많은 단계는 출력 단가가 정합니다. Anthropic 의 최적화 문서는 “Sonnet 5 에서 출력 토큰은 입력의 5배 값이고, 에이전트 루프에서 모델이 쓴 모든 토큰은 이후 모든 턴에 입력으로 되돌아온다” 고 경고합니다.
  • 실수의 대가 는 재작업 비용입니다. 대가가 큰 단계에서 티어를 낮추는 것은 절약이 아니라 도박입니다. 대가가 작은 단계에서 티어를 높이는 것은 보험이 아니라 낭비입니다.

Every 의 Kieran Klaassen 이 만든 Compound Engineering 플러그인이 “가치의 80% 는 계획과 리뷰에, 20% 는 실행에 있다” 고 설명하는 것도 같은 그림입니다. 토큰의 대부분은 ③ 에서 소비되지만, 결과의 대부분은 ② 와 ⑤ 에서 결정됩니다.

2. 단계별 티어 매핑 — 세 출처의 종합#

아래 표는 세 갈래 자료를 단계별로 모은 것입니다. “공식” 은 Anthropic·OpenAI 문서와 두 회사 소속 엔지니어의 공개 글, “블로거” 는 직접 실험을 공개한 테크블로거, “커뮤니티” 는 Hacker News·X·GitHub 의 실사용자입니다. 티어 표기는 Part 1 의 정의(고가 Fable·Astra, 중가 Opus·Sol, 저가 Sonnet·Terra, 바닥 Haiku·Luna)를 따릅니다.

단계공식블로거커뮤니티종합
① 탐색Claude Code 문서: “단순한 서브에이전트 작업은 model: haiku”. Codex: 탐색·테스트·분류는 서브에이전트로Willison: 구현 서브에이전트는 낮은 모델. Osmani: 탐색은 Haiku. Augment: 코드 내비게이션은 Haiku“조사는 대부분 읽기이고, 읽기는 가장 싼 일”. Luna 는 “research/scout 서브에이전트”바닥 또는 저가, 읽기 전용 서브에이전트로
② 계획opusplan: 계획은 Opus, 실행은 Sonnet. Hallie: 아키텍처 결정은 큰 모델. Codex: Sol 은 “모호하고 가치 높은 작업”Osmani: 계획은 Opus/GPT. Yegge: 계획 에이전트는 Fable 5. Danielsen: “실행 요율로 아키텍처를 사는 것이 비싼 실수”HN 에서 가장 많이 반복된 워크플로. “Fable 로 계획, Opus 로 구현”고가 또는 중가 high 이상. 토큰이 적어 비용 부담이 작다
③ 구현Claude Code 문서: “Sonnet 이 대부분의 코딩을 잘 처리”. Max 요금제 기본값은 Opus 5. Codex: Terra 는 “일상 작업”Osmani: 구현은 Sonnet/Codex-mini, “명확한 명세가 있으면 충분”. Pocock: Sonnet 이 구현Claude 쪽은 Opus 5 로 기울고, Codex 쪽은 Terra·Luna-xhigh중가가 기본, 명세가 정확하면 저가
④ 디버깅Hallie: “미묘한 버그” 는 큰 모델. Codex: High·Extra High 는 “어려운 디버깅”Cosmic JS: 저가가 두 번 실패하면 중가로. MindStudio: 검증 실패 시 상위로 재시도“Opus 4.6 이 10년 된 크래시를 첫 시도에 고쳤다”. 실패 후 한 칸 올린다중가 high 이상, 실패하면 고가
⑤ 리뷰Claude Code 모범 사례: model: opus 의 security-reviewer 예시. Willison: 검토는 Fable 루프에 남긴다Pocock: “리뷰에는 지능이 필요하다”, 새 컨텍스트로. Osmani: 빌더 3~4에 리뷰어 1Fable 5.1 리뷰가 “incredible”. Luna 리뷰 정확도 74% 대 Astra 96%위험한 변경은 고가, 국소 변경은 중가. 새 컨텍스트에서
⑥ 정리Codex: Luna 는 “좋은 결과를 아는 반복 작업”. Cat Wu: Haiku 는 슬래시 커맨드류Willison: 릴리스 노트는 “에이전트에 맡겨도 되는 글”. Vaughan: Luna 는 문서·포맷·lint“Luna 로 테스트·lint·문서”. “Opus 에게 설정 파일을 고치게 하는 건 어리석다”바닥 또는 저가

출처의 개별 인용은 Part 3·4 에서 단계별로 자세히 다룹니다. 여기서는 표의 모양만 봐 두면 됩니다. 세 출처가 거의 같은 결론에 도달했습니다. 판단이 필요한 단계(②⑤, 그리고 ④의 후반)에는 위쪽 티어를, 물량이 많거나 정형적인 단계(①③⑥)에는 아래쪽 티어를 씁니다.

3. 토큰이 소비되는 모양#

같은 결론에 도달한 이유를 숫자로 보겠습니다. 실측이 아니라 가정 입니다. 기능 하나를 구현하는 세션에서 단계별 토큰이 다음과 같다고 두겠습니다. 캐시 읽기가 많은 것은 에이전트 루프가 매 턴 대화 전체를 다시 보내기 때문입니다.

단계신규 입력캐시 읽기출력
① 탐색60K400K6K
② 계획40K300K20K
③ 구현150K1,500K80K
④ 디버깅60K700K40K
⑤ 리뷰50K300K15K
⑥ 정리30K250K12K

Part 1 의 가격표로 계산하면 (단위: 달러) 다음과 같습니다.

Claude 사다리

전략탐색계획구현디버깅리뷰정리합계
전부 Fable1.001.485.882.771.320.9613.41
전부 Opus0.650.853.501.650.780.578.00
전부 Sonnet0.260.341.400.660.310.233.20
단계별 A (Haiku·Fable·Opus·Opus·Fable·Sonnet)0.131.483.501.651.320.238.31
단계별 B (Sonnet·Fable·Sonnet·Opus·Opus·Haiku)0.261.481.401.650.780.125.67

Codex 사다리

전략탐색계획구현디버깅리뷰정리합계
전부 Astra1.301.707.003.301.551.1516.00
전부 Sol0.520.682.801.320.620.466.40
전부 Terra0.270.381.560.740.340.253.55
단계별 A (Luna·Astra·Sol·Sol·Astra·Terra)0.031.702.801.321.550.257.65
단계별 B (Terra·Astra·Terra·Sol·Sol·Luna)0.271.701.561.320.620.035.50

이 표에서 읽어야 할 것은 절대값이 아니라 구조 입니다.

  1. 구현 단계가 전체의 40~45% 를 차지합니다. 어느 전략이든 구현에 어떤 티어를 쓰느냐가 합계를 정합니다. “전부 Fable” 과 “단계별 A” 의 차이 $5 중 $2.4 가 구현 한 칸에서 나옵니다.
  2. 계획과 리뷰를 고가로 올려도 합계는 별로 안 움직입니다. 단계별 A 는 계획·리뷰를 Fable 로 올렸는데 “전부 Opus” 와 $0.31 차이입니다. 토큰이 적은 단계에서 티어를 올리는 것은 싼 보험입니다.
  3. 탐색과 정리를 바닥으로 내리면 거의 공짜가 됩니다. Luna 로 돌린 탐색은 3센트입니다.
  4. 단계별 B 는 “전부 중가” 보다 30% 싸면서 계획은 고가로 합니다. 이것이 커뮤니티가 말하는 “plan big, implement small” 의 경제학입니다.

이 계산에는 빠진 것이 둘 있습니다. 재작업 과 토큰 효율의 차이 입니다. 저가 모델이 구현에서 두 번 실패해 디버깅이 두 배로 늘면 단계별 B 의 이점은 사라집니다. 반대로 Part 1 에서 본 것처럼 고가 모델이 같은 일을 절반의 토큰으로 끝내면 “전부 Fable” 의 실제 비용은 표보다 낮습니다. 표는 출발점이지 결론이 아닙니다.

4. 두 진영과 한 절충안#

커뮤니티와 블로거의 의견은 크게 세 자리로 모입니다.

4.1 “항상 최고 모델” 진영#

  • Boris Cherny(Claude Code): “덜 조종해도 되니 결국 작은 모델보다 거의 항상 빠르다.” 2026년 6월에는 “새 모델은 계획 단계가 사실상 필요 없다” 며 명시적 plan mode 사용을 그만두었다고도 했습니다.
  • Dan Shipper(Every): Fable 5.1 이 Opus 5 의 일을 절반의 토큰으로 하므로 표시 가격이 실제 비용을 과장한다는 입장입니다. 모든 코딩을 Fable 5.1 로 옮겼습니다.
  • Hacker News 의 한 사용자: “Fable 5.1 을 모든 일에 쓰라고 말한다. low effort 여도 충분히 값어치를 한다.”
  • Ethan Mollick, Thorsten Ball: 최상위 티어가 열어 주는 위임의 폭이 아래 티어와 질적으로 다르다는 입장.

이 진영의 전제는 한계 토큰이 사실상 공짜 라는 것입니다. 정액 구독에서 한도를 다 못 쓰거나, 개발자 시급이 토큰보다 훨씬 비싼 경우입니다.

4.2 “공격적으로 낮춰라” 진영#

  • Gergely Orosz 의 토큰 지출 조사 (2026-04): 시드 단계 인프라 회사에서 엔지니어 1인당 월 $200 이 6개월 만에 $3,000 이 되었고, 핀테크는 하루 $500, 헬스케어는 한 사람이 하루 $1,400 을 쓴 날도 있었습니다. 대응책 1순위가 Sonnet 을 조직 기본 모델로 설정 하는 것이었습니다.
  • Steve Yegge 의 에이전트 도시 에세이 (2026-08): 계획 에이전트는 Fable 5, 함대 노동자는 Opus 5, 프로덕션 역할 에이전트는 “대부분 Sonnet”. 7월 한 달 690억 토큰을 썼는데 캐시 적중률 96% 로 정가 $87K 어치를 월 $2,800 에 해결했습니다. 비싼 모델을 무분별하게 쓰는 것을 “시스템 설계 버그” 로 봅니다.
  • Simon Willison 의 sqlite-utils 4.0 회고: 37개 프롬프트, $149.25 중 $141 이 Fable. “내 조언대로 더 싼 모델의 서브에이전트에 기대야 했다.”

이 진영의 전제는 물량이 많고 작업이 잘 분해되어 있다 는 것입니다.

4.3 “단계에 따라 라우팅” — 절충안이자 벤더가 제품화한 답#

가장 큰 진영이고, 이 시리즈의 입장이기도 합니다.

  • Claude Code 의 opusplan 별칭, 서브에이전트의 model 필드, 실험 단계의 Advisor 도구.
  • Codex 의 에이전트별 모델 지정, Sol·Astra 의 ultra effort.
  • Cursor 의 Router (2026-07): 60만 건의 실요청으로 분류기를 학습해, 모든 요청을 Opus 4.8 로 보내는 것 대비 “프론티어 품질을 60% 절감으로” 냈다고 보고합니다.
  • Augment 의 라우팅 가이드: 조정은 Opus, 구현은 Sonnet, 내비게이션은 Haiku 로 세션당 51% 절감.
  • Simon Willison 의 한 줄 CLAUDE.md: “모든 코딩 작업에 대해 적절한 낮은 모델을 스스로 판단해 서브에이전트로 돌려라.”

이 진영의 비판도 있습니다. Anthropic 의 Thariq Shihipar 는 동적 워크플로 글에서 “병렬화와 전문화는 조정 비용을 스스로 벌어야 한다”, “대부분의 전통적 코딩 작업에는 리뷰어 다섯 명이 필요 없다” 고 썼습니다. Birgitta Böckeler 는 에이전트가 헤맬 때 모델을 올리기 전에 “무엇이 빠졌는지 하네스에서 찾으라” 고 합니다. 라우팅 자체가 비용이라는 경고입니다.

5. 갈림길은 결국 두 질문이다#

세 진영이 갈리는 지점을 걷어 내면 질문은 둘로 줄어듭니다.

첫째, 지금 이 단계에서 실수하면 얼마가 드는가. 계획과 리뷰에서 실수하면 그 뒤의 모든 단계를 다시 합니다. 여기서 티어를 낮추는 것은 절약이 아닙니다. 탐색과 정리에서 실수하면 다시 읽거나 다시 쓰면 됩니다. 여기서 티어를 올리는 것은 보험이 아닙니다.

둘째, 이 단계의 토큰이 세션 전체에서 얼마나 큰가. 구현이 40% 이상입니다. 여기서 한 칸 내리면 합계가 크게 움직이고, 계획·리뷰에서 한 칸 올려도 합계는 거의 안 움직입니다.

두 질문의 답을 겹치면 다음 두 편의 내용이 됩니다. 고가 티어는 실수의 대가가 큰 곳에(Part 3), 중가·저가·바닥 티어는 토큰이 많은 곳과 정형적인 곳에(Part 4). 그리고 그 사이를 실제로 어떻게 오가는지(Part 5).

References#

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

테크블로거·분석 (2026)

커뮤니티 (2026)