서론

주식회사 GENDA 개발부 엔지니어 오쿠야마입니다.

최근 Claude Fable 5가 공개되어, Opus를 상회하는 Mythos급 성능을 일반 제공(General Availability)으로 사용할 수 있다는 점이 화제가 되었습니다.

공식 벤치마크에서도 코딩을 포함한 각 분야에서 최고 수준의 스코어가 나타나고 있습니다.

한편, 성능이 올라간 만큼 가격도 상승했습니다.

이 정도 수준의 단가를 가진 모델에 확정된 사양을 코드로 옮기는 작업이나, grep으로 파일을 하나하나 읽는 것과 같은 단순한 작업을 맡기는 것은 적절하지 않다고 느꼈습니다.

이전부터 작업을 서브 에이전트 (Sub-agent)에게 위임하는 메커니즘 자체는 운용하고 있었으나, 이를 계기로 다시 한번 정비하여 "메인 세션은 상위 모델을 유지하되, 구현이나 조사는 서브 에이전트를 통해 Sonnet / Opus로 위임한다"라는 운용 규칙으로 다시 설계했습니다.

비용 구조

위임 규칙을 만들기 전에, 먼저 모델별 가격을 비교해 두겠습니다.

비용 = 토큰 수 × 모델 단가

과금은 "소비 토큰 수 × 모델별 단가"로 결정됩니다.

API 가격(2026-06-11 시점, $/1M 토큰)은 다음과 같습니다.

동일한 토큰 수를 처리할 경우, Opus는 Fable의 절반, Sonnet은 30%, Haiku는 **10%**의 비용이 듭니다 (비율은 Input / Output 도 동일합니다).

구독 플랜(Max 등)의 quota 소비도 모델마다 가중치가 부여되어 있으므로 같은 방향으로 작용합니다 (정확한 비율은 공개되지 않았습니다).

토크나이저 (Tokenizer)에 의한 비용 차이

가격표만으로는 보이지 않는 요소로 토크나이저의 차이가 있습니다.

공식 가격 페이지에 따르면, Opus 4.7 이후의 모델(Fable 5 포함)은 새로운 토크나이저를 채택하고 있어, 동일한 내용이 기존 모델 대비 최대 35% 정도 더 많은 토큰으로 토큰화된다고 합니다.

Opus 4.7 and later use a new tokenizer compared to previous models, contributing to their improved performance on a wide range of tasks. This new tokenizer may use up to 35% more tokens for the same fixed text.

Sonnet 4.6은 기존 토크나이저를 사용하므로, (내용에 따라 다르지만) 동일한 파일을 읽는 데 필요한 토큰 수 자체가 최대 Fable 5의 3/4 정도로 적어집니다.

단가(Fable 대비 30%)와 곱하면, 동일한 작업의 비용은 개략적으로 실질 1/4 전후가 된다는 계산이 나옵니다. "대량의 파일 읽기를 동반하는 작업"을 위임할 때의 효과가 특히 큰 이유는 바로 이 때문입니다.

참고로, Opus 4.8은 Fable 5와 동일한 토크나이저를 사용하므로, Opus로 위임할 때의 이점은 단가가 절반이 되는 부분뿐입니다.

effort에 의한 비용 차이

비용에 영향을 미치는 또 다른 요소로, thinking의 깊이를 조정하는 파라미터인 effort(low / medium / high / xhigh / max. 대응 수준은 모델에 따라 다름)가 있습니다.

effort를 낮추면 thinking이 얕아지고, 툴 콜 (Tool call)이 통합되어 output 토큰이 줄어듭니다. 단, 단가는 변하지 않습니다.

모델 변경이 "단가"를 바꾸는 것에 반해, effort는 "토큰량"을 바꾼다고 정리할 수 있습니다.

모델 자체의 기본값은 Sonnet 4.6 / Opus 4.8 모두 high입니다 (참고로 Haiku에는 effort 개념이 없습니다).

기본적으로는 기본값 그대로 두는 것이 좋다고 생각하지만, 비용이 신경 쓰이는 경우에는 사양이 명확한 단순 태스크의 위임 대상에 한해서 낮추는 선택지도 있습니다.

effort는 후술할 서브 에이전트 정의의 frontmatter effort 필드에서 에이전트 단위로 지정할 수 있으며, 지정하지 않은 경우 세션의 effort를 상속합니다.

역할 기반의 모델 구분 사용

방침은 심플합니다. 태스크의 역할에 따라 담당 모델을 고정하는 것입니다.

지능이 결과에 영향을 미치는 작업은 메인 세션(Fable)에 남겨두고, 단순히 손이 많이 가는 작업은 서브 에이전트(Sub-agent)로 넘깁니다.

구현뿐만 아니라 조사(Investigation)도 위임 대상으로 삼은 이유는, '탐색적인 파일 읽기'야말로 메인 컨텍스트(Main Context)를 압박하는 가장 큰 요인이기 때문입니다.

반대로, 원인 파악부터 필요한 디버깅(Debugging)까지 능력이 부족한 모델에게 맡기면, 재시도(Retry)와 우회로 인해 오히려 토큰(Token)을 더 소비하게 됩니다. 따라서 Sonnet에는 사양이 확정된 태스크만 한정하여 맡기고, 디버깅은 Opus에게 맡깁니다.

같은 이유로, 가장 저렴한 Haiku에게 코드를 작성하게 하지는 않습니다.

다만 '테스트를 실행하고 합격 여부의 요약만 반환하는' 용도로는 충분하기 때문에, 테스트 실행 전용인 test-runner에만 Haiku를 할당하고 있습니다. 이는 방대한 테스트 출력을 메인 컨텍스트에 넣지 않아도 되므로, 단가가 저렴하다는 점 이상으로 컨텍스트 절약 측면에서 효과적입니다.

또한, 서브 에이전트를 호출하는 데에도 비용이 발생하므로, 툴 콜(Tool Call) 몇 번으로 끝날 소규모 태스크는 위임하는 왕복 비용이 더 높을 수 있습니다. 그래서 규모의 기준과 위임 시의 규칙도 포함했습니다.

위임한다: 여러 파일의 읽기·편집이나 시행착오가 예상되는, 어느 정도 규모가 큰 자기 완결적(Self-contained) 태스크
위임하지 않는다: 1~2개 파일의 작은 편집은 메인 세션이 직접 수행
한꺼번에 전달한다: 소규모 태스크가 여러 개 있는 경우, 1개의 에이전트에게 태스크 리스트를 통째로 전달(호출을 1회로 압축)
재설명을 피한다: 지시는 plan 파일이나 태스크 리스트의 경로를 전달하며, 메인 세션이 장문을 새로 작성하지 않도록 함

이러한 규모의 구분은 체감에 기반한 잠정적인 것이며, 운용하면서 조정해 나갈 예정입니다.

참고로, 위임 내용에 따라 토큰의 총량은 늘어날 수도 있습니다. 그럼에도 목적이 비용(Quota 소비) 절감이라면 문제없다고 생각합니다.

대부분의 토큰을 Sonnet / Opus 단가로 옮기는 것 자체가 절약의 핵심이기 때문입니다.

위임 대상은 .claude/agents/ 하위의 커스텀 에이전트(Custom Agent)로 정의합니다.

프런트매터(Frontmatter)의 model:을 통해 위임할 모델을 구조적으로 고정할 수 있으므로, "Sonnet을 사용하라"고 문장으로 지시하는 것보다 확실합니다.

앞서 언급한 effort도 여기서 지정할 수 있습니다.

---
name: implementer
description: Implementation agent for well-specified coding tasks
...

위임 판단의 위치

에이전트 정의를 준비했다고 해서 Claude가 매번 그것을 사용한다는 보장은 없습니다.

"어떤 태스크가 왔을 때 위임할 것인가"라는 판단 기준을 모든 태스크에서 매번 적용할 수 있는 장치가 별도로 필요합니다.

Claude Code에서 지시를 심어둘 수 있는 곳은 여러 군데(CLAUDE.md, Rules, Skill)가 있으며, 어느 것이 적절할지 검토했습니다.

채택한 방법은, 위임 기준을 정리한 파일을 작성하고 CLAUDE.md에서 @를 통해 불러오는 방법입니다.

세션 시작 시 로드되기 때문에, 태스크의 종류와 상관없이 매번 판단 기준이 적용됩니다.

구성 방식은 다음과 같습니다.

~/.claude/
├── references/
│ └── role-based-model-selection.md ← 위임 기준 (CLAUDE.md에서 @로 참조)
...

CLAUDE.md 측에는 다음과 같이 @로 참조하는 행만 작성하면 됩니다.

# Personal Claude Code Instructions
@references/role-based-model-selection.md

Skill을 채택하지 않은 이유

위임 규칙을 Skill로 묶는 방법도 검토했지만, Skill을 호출할지 여부는 Claude 자신의 판단에 달려 있습니다.

"판단 기준이 컨텍스트에 포함되어 있음"을 구조적으로 보장하고 싶었기 때문에, 이번에는 채택하지 않았습니다.

Rules와의 비교

Claude Code에는 ~/.claude/rules/에 두기만 하면 자동으로 로드되는 Rules가 있으며, "CLAUDE.md + @ import" 방식과 어느 쪽이 더 나은지도 조사했습니다.

Rules의 실질적인 강점은 frontmatter의 paths: (glob)를 통한 **조건부 로드 (conditional load)**로, 매칭된 파일을 다룰 때만 규칙이 적용된다는 점입니다.

역으로 말하면, 상시 적용되는 규칙에 한해서는 무조건적인 Rules와 @ import는 기능적으로 거의 동일하며, 차이점은 유지보수성 정도입니다.

이번 위임 규칙은 태스크 유형 기반의 상시 적용 방식이라 paths의 혜택을 받을 수 없었기에, 기존의 @ import 패턴을 계속 사용했습니다.

경로 스코프(path scope)화하고 싶은 규칙이 나타나는 시점에 Rules로의 이전을 검토하는 것으로 충분하다고 생각합니다.

운용의 묘미

Plan 파일에 owner 주석 달기

계획 단계에서 plan 파일을 작성할 때, 각 구현 단계(implementation step)에 담당자를 주석으로 남기도록 합니다.

## 구현 단계
1. API 엔드포인트 추가 (owner: implementer)
2. 인증 관련 리팩토링 (owner: heavy-implementer)
...

또한, 위임 시에는 "plan 파일의 경로 + 단계 참조"를 전달하는 것만으로 충분하므로, 메인 세션이 지시문을 길게 작성할 필요가 없습니다.

보고 계약 (Reporting Contract)

서브 에이전트의 최종 보고는 메인 컨텍스트(context)로 돌아오기 때문에, 이 부분이 길어지면 위임의 의미가 퇴색됩니다.

에이전트 정의에 "보고는 변경된 파일 목록, 주요 판단, 검증 결과만 작성할 것. 코드 전문이나 읽은 파일의 내용을 붙여넣지 말 것"이라는 제약을 넣어 왕복 비용(round-trip cost)을 억제하고 있습니다.

조사 에이전트의 경우 "발견 사항은 file_path:line_number 참조로 반환한다"라고 정해두면, 메인 세션은 그 부분만 핀포인트로 읽을 수 있습니다.

마치며

Claude Fable 5의 공개를 계기로 서브 에이전트 활용 규칙을 재검토한 과정을 소개했습니다.

모델이나 하네스(harness)의 성능 향상은 눈부시며, 깊이 고민하지 않아도 "맡겨두면 알아서 돌아가는" 상황이 늘어나고 있습니다.

그렇기에 이번 재검토는 비용 측면에서 한 번 멈춰 서서 정리해 보는 좋은 기회가 되었습니다.

편리함에 안주하지 않고 개선할 수 있는 부분은 앞으로도 적극적으로 개선해 나가고자 합니다.

효과 측정은 이제부터 시작이므로, ccusage 등을 통해 소비량을 관측하며 입도(granularity) 기준을 조정해 나갈 예정입니다.

본 기사가 Claude Code의 비용 문제로 고민하는 분들에게 도움이 되기를 바랍니다.

Discussion