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

들어가며#

Part 3 에서 고가 티어를 판단이 필요한 네 자리에 두고 물량에서는 뺐습니다. 그 물량을 받아 내는 것이 이번 편의 주인공입니다. 중가 티어(Claude Opus 5, GPT-5.6 Sol), 저가 티어(Claude Sonnet 5, GPT-5.6 Terra), 그리고 바닥 티어(Claude Haiku 4.5, GPT-5.6 Luna)입니다.

세 티어의 역할을 한 줄로 요약하면 이렇습니다. 중가는 구현의 기본값, 저가는 명세가 정확할 때의 구현과 정형 작업, 바닥은 읽기와 잡일. 왜 그런지, 어디까지 내려갈 수 있는지, 내려갔을 때 무엇이 깨지는지 봅니다.

1. 중가 티어가 구현의 기본값이 된 이유#

1.1 가격 붕괴#

2026년 상반기까지 Opus 와 Sonnet 의 가격 차이는 5배였습니다. 그래서 “Opus 는 아껴 쓰고 Sonnet 으로 버틴다” 가 상식이었습니다. 7월 24일 Opus 5 가 $5/$25 로 나오면서 이 차이가 2.5배 로 줄었고, Anthropic 의 발표문은 Opus 5 를 “Claude Max 의 기본 모델” 로 못박았습니다. Claude Code 의 모델 설정 문서에 따르면 Max·Team Premium·Enterprise·API 의 기본값은 Opus 5, Pro 와 Team Standard 의 기본값은 Sonnet 5 입니다.

OpenAI 쪽도 비슷합니다. Sol 은 출시가 $5/$30 에서 8월 21일 $4/$20 으로 내렸고, Terra 와의 차이는 입력 기준 2배입니다.

가격 차이가 2~2.5배로 줄면 “구현을 중가로 한다” 의 비용은 “저가로 한다” 의 2배 남짓입니다. 반면 재작업의 위험은 뚜렷이 줄어듭니다. Part 2 의 계산에서 구현 단계를 Opus 5 로 하면 $3.50, Sonnet 5 로 하면 $1.40 이었습니다. $2.10 의 차이로 구현 단계의 재시도 위험을 사는 것 이 중가 기본값의 경제학입니다.

1.2 과제당 비용으로는 중가가 고가와 대등하거나 더 싸다#

Part 1 에서 본 Anthropic 의 측정에서 Opus 5 는 SWE-bench Pro 를 Fable 5.1 기본 effort 와 같은 정확도(91.7% 대 92.1%)로, 해결 과제당 15% 싸게 풀었습니다. Artificial Analysis 의 7월 측정은 제목부터 “Fable 5 수준의 지능을 더 낮은 과제당 비용으로” 였습니다. 지능 지수 61 대 60, 과제당 $2.03 대 $2.75.

OpenAI 사다리에서는 Artificial Analysis 의 GPT-5.6 측정이 Sol(max) 을 지수 59 에 과제당 $1.04, Terra(max) 를 55 에 $0.55, Luna(max) 를 51 에 $0.21 로 놓았습니다. Sol 은 “Claude Fable 5 보다 1점 낮으면서 비용은 약 3분의 1” 이었습니다.

즉 2026년 여름 기준으로 중가 티어는 고가 티어의 코딩 능력 대부분을 절반 이하의 단가로 제공 합니다. 고가가 확연히 앞서는 것은 Terminal-Bench 4.0 같은 장시간 에이전트 과제와 Terminal-Bench-Science 같은 특수 영역이고, 이것이 Part 3 에서 고가를 판단과 장시간 작업으로 한정한 근거입니다.

1.3 커뮤니티의 실제 기본값#

Hacker News 의 Fable 5.1 발표 스레드에서 “Opus 5 가 일상 모델” 이라는 보고가 여럿 있고, “Opus 를 매일 쓰는데 주간 한도가 대부분 남는다” 는 보고도 있습니다. 두 주간의 A/B 테스트를 한 사용자는 “Sol 은 Fable 보다 Opus 에 훨씬 가깝고, Opus 가 Sol 을 이기는 경우가 잦다. Sol 이 나은 유일한 영역은 코드 리뷰” 라고 정리했습니다. Codex 쪽에서는 “Sol 은 $100 플랜으로 여러 스레드를 하루 종일 돌릴 수 있다” 는 보고와 “나에게는 Sol 만이 비용 효율적인 모델” 이라는 보고가 나란히 있습니다.

Gergely Orosz 의 2026 AI 도구 조사 (906명 응답)에서 Opus 와 Sonnet 의 언급 수는 나머지 모든 모델을 합친 것보다 많았습니다. 구현의 기본값이 이 두 모델 사이 어딘가에 있다는 것은 수요 쪽 데이터로도 확인됩니다.

2. 저가 티어가 충분해지는 조건#

저가 티어(Sonnet 5, Terra)를 구현에 쓰는 것은 틀린 선택이 아닙니다. 조건이 붙을 뿐입니다.

2.1 명세가 정확할 때#

Lydia Hallie 의 공식 글에서 Sonnet 의 자리는 “정확히 서술할 수 있는 편집, 기계적 변경, 이미 컨텍스트에 있는 코드에 대한 질문” 입니다. Addy Osmani 는 CodeCon 발표에서 구현을 Sonnet 급에 맡기며 “명확한 명세가 주어지면 완벽히 유능하다” 고 했고, 비용은 “60~70% 싸다” 고 했습니다. Matt Pocock 의 워크숍 구성도 “Sonnet 이 구현, Opus 가 리뷰” 입니다.

공통 조건은 위 티어가 만든 계획서 입니다. Part 3 의 계획 단계가 저가 구현의 전제입니다. 계획 없이 저가 모델에게 “이 기능을 만들어라” 고 하면 탐색과 설계까지 저가 모델이 떠안게 되고, 거기서 Part 2 의 재작업 비용이 발생합니다.

2.2 Codex 쪽의 “작은 모델일수록 높은 effort”#

Codex 커뮤니티에서 널리 인용되는 규칙이 Eric Provencher 의 X 게시물 (2026-07-17) 입니다.

Sol Medium, Terra high or Luna xhigh — Smaller the model, higher the reasoning you need to approach the quality bar.

Terra 를 high, Luna 를 xhigh 로 돌려 Sol medium 의 품질에 근접시키는 요령입니다. Part 1 의 Codex 가격표를 보면 Terra 는 Sol 의 절반, Luna 는 20분의 1 이므로, effort 를 올려 토큰이 몇 배 늘어도 총비용은 여전히 쌉니다. Simon Willison 의 Astra·GPT-5.6 pelican 비교에서 같은 프롬프트를 max 로 돌린 비용은 Luna 1.6센트, Terra 25.7센트, Sol 32.4센트, Astra 63.2센트였습니다. Luna 를 최고 effort 로 돌려도 Sol 의 20분의 1 입니다.

2.3 반론: “effort 가 아니라 모델을 바꿔라”#

Anthropic 쪽 커뮤니티에는 정반대 결론이 있습니다. Sonnet 5 발표 스레드에서 여러 사용자가 Anthropic 이 공개한 과제당 비용 곡선을 읽고 “Sonnet 5 medium 이 부족하면 effort 가 아니라 모델을 바꿔라” 고 정리했습니다. medium 이상에서는 Opus 가 Sonnet 을 비용·성능 모두에서 앞선다는 해석입니다. Hallie 의 글도 “Sonnet 을 높은 effort 로 돌리면 Opus 기본값보다 토큰이 더 쌓일 수 있다” 고 경고합니다.

두 규칙이 충돌하는 이유는 사다리의 간격입니다. Codex 는 Terra 와 Luna 사이가 10배라 effort 를 올릴 여지가 크고, Claude 는 Sonnet 과 Opus 사이가 2.5배라 effort 를 올리느니 모델을 바꾸는 편이 낫습니다. “작은 모델 + 높은 effort” 는 그 아래 칸이 충분히 쌀 때만 성립합니다. Claude 사다리에서는 Haiku 4.5 가 Sonnet 5 의 절반 값이라 이 요령의 여지가 작습니다.

3. 바닥 티어가 맡는 일#

Haiku 4.5 와 Luna 는 코드를 쓰는 모델이 아니라 읽고, 분류하고, 정형 출력을 만드는 모델입니다. 커뮤니티 조사에서 9개 이상의 출처가 “바닥 티어는 읽기·정찰·테스트 서브에이전트에, 판단에는 절대 쓰지 않는다” 는 데 일치했습니다.

일근거
코드베이스 탐색·파일 찾기Augment 가이드: 내비게이션·grep 은 Haiku. Danielsen: 읽기는 Haiku·Sonnet 서브에이전트
테스트·lint·포맷Osmani: 테스트는 Haiku. Vaughan: Luna 는 “테스트, lint, 문서”. HN: Luna 를 “research/scout/test 서브에이전트” 로
문서·커밋 메시지·릴리스 노트Willison: 릴리스 노트는 “에이전트에 맡겨도 되는 글”. Codex 문서: Luna 는 “좋은 결과가 무엇인지 아는 반복 작업”
대량의 기계적 변환이름 바꾸기, 포맷 통일, 대량 편집

OpenAI 의 모델 문서가 Luna 의 조건으로 붙인 “좋은 결과가 무엇인지 알 때” 가 핵심입니다. 검증 기준이 명확한 일에만 바닥 티어를 씁니다. 리뷰나 설계처럼 “무엇이 좋은지” 자체가 판단인 일에는 쓰지 않습니다. Part 3 에서 본 Luna 의 리뷰 정확도 74% 가 그 경계입니다.

바닥 티어를 이렇게 쓰면 비용은 거의 사라집니다. Part 2 의 계산에서 Luna 로 돌린 탐색은 3센트, Haiku 로 돌린 탐색은 13센트였습니다. Simon Willison 의 한 줄 CLAUDE.md 가 이것을 자동화합니다.

For all coding tasks use your judgement to decide an appropriate lower power model and run that in a subagent.

Fable 이 메인 루프에 남아 설계·검토·종합을 맡고, 실질적 구현은 Sonnet, 사소한 편집은 Haiku 서브에이전트로 내려갑니다. 그가 이렇게 한 이유는 “구현 작업에는 최상위 모델이 거의 필요 없다” 는 것과 “Fable 한도가 전보다 천천히 줄어든다” 는 것이었습니다.

4. 아래 티어로 내려갈 때 깨지는 것들#

싼 모델의 실패 모드를 알아야 어디까지 내려갈 수 있는지 정할 수 있습니다.

4.1 코너 커팅과 조기 승리 선언#

Hacker News 에서 반복되는 비교가 있습니다. Codex 모델은 “지시를 꼼꼼히 따르고 끝까지 간다”, “리뷰에 좋은 이유는 pedantic 하기 때문” 이라는 평이 있고, Claude 모델은 “코너를 자른다”, “승리를 선언한다” 는 평이 있습니다. 반대 증언(Codex 가 “지시를 노예처럼 따르다 yak-shaving 에 빠진다”)도 있으므로 벤더 차이라기보다 아래 티어일수록 두드러지는 경향 으로 읽는 것이 안전합니다.

이것을 막는 것이 검증 게이트입니다. Claude Code 의 비용 문서는 “검증 목표를 줘라. 테스트 케이스, 스크린샷, 기대 출력을 프롬프트에 포함하면 스스로 확인하고 고친다” 고 합니다. 저가 모델로 구현할 때 이 조건은 선택이 아니라 필수입니다.

4.2 컨텍스트 한계#

바닥 티어는 컨텍스트가 작거나(Haiku 4.5 는 200K, 다른 모델은 1M) 긴 컨텍스트에서 품질이 빨리 떨어집니다. Hacker News 의 Luna 리뷰 스레드에서 “컨텍스트 창 때문에 조금만 큰 리뷰에도 형편없다” 는 보고가 있습니다. Birgitta Böckeler 의 로컬 모델 실험 (2026-07)은 사다리의 맨 아래를 보여 줍니다. 작은 모델은 “단일 파일, 정확히 지목된 편집, 스크립트” 는 처리하지만 “여러 파일에 걸친 추론과 코드 탐색이 필요한 것” 은 실패합니다.

Matt Pocock 의 “똑똑한 구간은 10만 토큰 근처에서 끝난다” 는 관찰과 합치면, 아래 티어일수록 작업을 작게 쪼개고 새 컨텍스트에서 시작해야 합니다. 서브에이전트가 그 자연스러운 단위입니다.

4.3 계획에 없는 상황#

Hacker News 의 한 사용자는 “어느 하네스도 코드 작성에 낮은 모델을 쓰지 않는다” 며, 아래 티어가 계획에 없는 상황을 만나면 “추측하거나 큰 모델에 되돌리는데, 그러면 읽기 비용은 이미 낸 뒤” 라고 지적했습니다. 이 문제의 해법이 커뮤니티에서 두 가지로 나왔습니다.

  • 멈추고 보고하기. dev.to 의 TITAN 워크플로는 구현 모델이 아키텍처 변경이 필요한 상황을 만나면 즉흥적으로 고치지 않고 멈추도록 규칙을 둡니다. 결정은 대화가 아니라 저장소의 파일에 남깁니다. GitHub 의 Codex 워크플로 스킬도 Luna 가 “상위가 소유한 결정” 을 만나면 “멈추고 보고” 하게 합니다.
  • fork 로 읽기 비용 재사용. 고가 모델이 이미 읽은 컨텍스트를 서브에이전트로 넘기는 대신 세션을 fork 하면 “fork 이전의 읽기에 다시 돈을 내지 않고 재작업이 준다” 는 보고가 있습니다. 읽기 비용을 아끼려고 아래 티어에 내려보냈다가 되돌아오면 손해라는 계산입니다.

4.4 도구 지원 여부#

아래 티어로 내려가기 전에 하네스가 그 모델을 어디까지 지원하는지 확인해야 합니다.

  • Claude Code 의 Explore 서브에이전트는 이제 Haiku 로 고정되어 있지 않습니다. 서브에이전트 문서에 따르면 v2.1.198 부터 Explore 는 메인 대화의 모델을 상속하고, Opus 를 상한으로 합니다. 탐색을 싸게 하려면 model: haiku 를 명시하거나 CLAUDE_CODE_SUBAGENT_MODEL=haiku 를 설정해야 합니다.
  • Codex 의 멀티에이전트에서 Luna 는 서브에이전트로 잘 안 된다는 보고 가 있습니다. Eric Provencher 는 7월 31일 “Sol 과 Terra 만 잘 된다” 고 썼고, 다른 사용자는 Luna 를 서브에이전트 대신 max effort 의 별도 스레드로 띄우는 우회를 공유했습니다. 공식 문서에는 이 제한이 명시되어 있지 않으므로 커뮤니티 보고로 받아들이는 것이 맞습니다.

5. 오픈 모델이라는 다섯 번째 칸#

이 시리즈는 두 벤더의 사다리만 다루지만, Hacker News 에는 무시할 수 없는 크기의 진영이 하나 더 있습니다. GLM 5.3 Flash, Kimi K2.7, DeepSeek V4 같은 오픈 가중치 모델이 벤더의 저가·바닥 티어를 대체한다는 주장입니다. “하루 $5~10 이상 쓰는 것이 불가능하다”, “Haiku 의 더 싼 대체재” 라는 보고가 있고, Steve Yegge 진영의 GasTown 실험에서는 노동자 에이전트를 GLM-5·Kimi K2.5·MiniMax 로 바꿔 “6분의 1 비용” 을 노렸습니다.

같은 진영의 단서도 함께 적어 둡니다. “90% 의 품질을 10% 의 비용으로, 단 먼저 좋은 개발자여야 한다.” 아래 티어일수록 사람이 계획과 검증을 더 맡아야 한다는 뜻이고, 이것은 벤더 사다리 안에서도 같은 원리입니다.

6. Part 4 의 규칙#

티어기본 자리조건
중가 (Opus 5, Sol)구현의 기본값. 디버깅 1차, 국소 변경의 리뷰가격 붕괴 이후 고가 대비 절반 이하 단가로 대부분의 코딩 능력
저가 (Sonnet 5, Terra)명세가 정확한 구현, 정형 편집위 티어의 계획서 + 검증 게이트. Codex 는 effort 를 한 칸 올려서
바닥 (Haiku 4.5, Luna)읽기·탐색, 테스트·lint, 문서·커밋, 대량 기계적 변환“좋은 결과가 무엇인지 아는” 일에만. 리뷰·설계 금지. 작게 쪼개고 새 컨텍스트에서
어느 티어든계획에 없는 상황을 만나면 멈추고 보고즉흥 설계 변경 금지

다음 편은 실행입니다. Claude Code 와 Codex 에서 실제로 티어를 오가는 명령과 설정, 에스컬레이션 규칙, 구독 한도 관리, 그리고 하루를 어떻게 짜는지의 플레이북과 암기표입니다.

References#

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

실측·분석 (2026)

커뮤니티 (2026)