AI 코딩 도구를 오래 사용하다 보면 어느 순간 비슷한 고민을 하게 됩니다.
“왜 이렇게 많은 작업을 했는데 사용량이 빨리 줄어들지?”
특히 Claude Code처럼 프로젝트 전체를 읽고 파일을 검색하고 코드를 수정하며 테스트까지 수행하는 에이전트형 개발 도구에서는 단순히 질문 한 번에 답을 얻는 방식과 토큰이 사용되는 구조가 상당히 다릅니다.
코드베이스를 탐색하고, 관련 파일을 찾고, 테스트 로그를 확인하고, 여러 파일을 수정하는 과정이 반복되기 때문입니다.
그렇다고 모든 작업을 가장 성능이 높은 모델에 맡길 필요는 없습니다.
오히려 최근 Claude 모델과 Claude Code의 발전을 보면 더 효율적인 방법이 있습니다.
핵심은 간단합니다.
어려운 판단은 상위 모델이 담당하고, 반복적인 실행 작업은 더 저렴하고 빠른 모델에게 넘기는 것입니다.
이른바 '모델 분업' 방식입니다.
2026년 10월 현재 이 방법은 단순한 토큰 절약 팁을 넘어 에이전트형 개발 환경을 효율적으로 운영하는 하나의 방법으로 볼 수 있습니다.
1. 먼저 알아둘 것, '토큰 절약'과 '작업 비용 절감'은 같은 말이 아니다
Claude Code를 사용할 때 가장 먼저 구분해야 할 부분이 있습니다.
API를 직접 사용하는 경우에는 모델별 토큰 가격 차이가 곧바로 비용 차이로 연결됩니다.
반면 Claude Pro나 Max 같은 구독형 서비스에서는 사용량이 단순히 “토큰 몇 개를 썼느냐”만으로 계산되는 것이 아니라 모델, 작업량, 사용 제한 등 여러 요소가 영향을 줍니다.
따라서 “Haiku를 사용하면 무조건 토큰이 정확히 몇 % 줄어든다”고 말하는 것은 적절하지 않습니다.
보다 정확한 표현은 다음과 같습니다.
비싼 상위 모델이 처리해야 할 컨텍스트와 실행 작업을 줄이면 전체적인 사용 효율을 높일 수 있다.
이 차이를 이해하는 것이 중요합니다.
실제로 Anthropic은 2026년 9~10월에 Claude Opus 5.5, Sonnet 5.5, Haiku 5.5를 차례로 선보였습니다.
특히 Haiku 5.5는 대량 처리와 비용에 민감한 작업을 겨냥한 모델로 소개됐으며, Anthropic은 아예 Opus 5.5나 Sonnet 5.5와 함께 코딩 서브에이전트로 사용할 수 있다고 설명하고 있습니다.
즉 현재의 모델 라인업 자체가 '모든 작업을 하나의 최고급 모델로 처리하는 구조'에서 벗어나고 있는 셈입니다.
2. 현재 Claude 모델을 어떻게 나눠 쓰면 좋을까?
2026년 10월 기준으로 Claude Code를 운용한다면 과거 글에서 자주 등장했던 단순한
Opus = 어려운 작업
Sonnet = 보통 작업
Haiku = 쉬운 작업
이라는 구분에서 한 단계 더 나아갈 필요가 있습니다.
최근 모델들의 성능 차이가 줄어들었고, 특히 Sonnet 5.5와 Haiku 5.5가 크게 개선됐기 때문입니다.
Opus 5.5
복잡한 구조를 이해하고 장시간 작업해야 하는 경우에 적합합니다.
예를 들면 다음과 같습니다.
대규모 코드베이스 아키텍처 분석
복잡한 버그의 원인 추적
대규모 리팩터링 계획
여러 모듈에 걸친 설계 변경
보안이나 안정성에 중요한 코드 검토
최종적인 구현 방향 결정
Anthropic은 Opus 5.5를 복잡한 에이전트형 코딩과 장기 작업에 강한 모델로 소개하고 있으며, 이전 Opus 5보다 일반적인 작업 비용이 약 40% 낮아졌다고 설명했습니다.
따라서 이제는 “Opus는 너무 비싸니까 최대한 사용하지 말자”보다는 정말 판단력이 필요한 구간에 집중적으로 사용한다고 생각하는 편이 좋습니다.
Sonnet 5.5
실제 개발 작업의 중심축으로 사용하기 좋습니다.
Anthropic 역시 Sonnet 5.5를 잘 정의된 일반적인 작업, 버그 수정, 문서 작성 등의 용도에 적합한 모델로 설명하고 있습니다.
예를 들면
새로운 기능 구현
일반적인 리팩터링
테스트 코드 작성
API 연결
UI 수정
중간 수준의 디버깅
코드 리뷰
등을 맡길 수 있습니다.
Haiku 5.5
반복적이고 범위가 명확한 작업에서 특히 유용합니다.
Anthropic은 Haiku 5.5를 고빈도·비용 민감 작업을 위한 모델로 소개하고 있으며 요약, 분류, 반복적인 처리뿐 아니라 서브에이전트 작업에도 적합하다고 설명합니다.
따라서
파일 구조 조사
특정 문자열 검색
로그 요약
간단한 코드 수정
반복적인 변환
단순 테스트 실행 및 결과 정리
문서의 작은 수정
같은 작업을 넘기기 좋습니다.
중요한 것은 작업 난이도를 기계적으로 분류하는 것이 아니라 작업의 목적을 기준으로 모델을 선택하는 것입니다.
3. 가장 재미있는 방법은 '모델 선택'까지 Claude에게 맡기는 것
여기서 한 단계 더 발전시킬 수 있습니다.
직접
“이건 Haiku로 해.”
“저건 Sonnet으로 해.”
라고 매번 결정할 필요가 없습니다.
2026년 7월 개발자 Simon Willison이 공개한 실험이 좋은 사례입니다.
그는 Claude Code에게 다음과 같은 취지의 지시를 내렸습니다.
코딩 작업을 수행할 때 적절한 낮은 등급의 모델을 판단해서 서브에이전트로 실행하라.
이후 Claude Code가 작업 성격에 따라 낮은 성능의 모델을 선택해 코딩 작업을 위임하도록 했고, 자신이 사용하는 상위 모델의 사용량이 이전보다 천천히 줄어드는 효과를 경험했다고 밝혔습니다.
여기서 중요한 포인트가 있습니다.
사람이 미리 20개짜리 규칙표를 만드는 것이 아닙니다.
상위 모델을 일종의 작업 관리자처럼 사용하는 것입니다.
예를 들어 사용자가
“로그인 시스템의 오류를 수정해줘.”
라고 요청했다고 가정해 보겠습니다.
상위 모델이 먼저 코드를 살펴본 다음,
인증 구조를 이해한다.
오류의 원인을 추적한다.
단순한 파일 수정으로 판단한다.
실제 수정은 Sonnet 또는 Haiku 서브에이전트에 맡긴다.
결과를 다시 가져온다.
상위 모델이 변경 내용을 검토한다.
필요한 경우 테스트를 추가로 지시한다.
이런 구조가 가능합니다.
즉,
상위 모델 = 팀장 또는 수석 개발자
서브에이전트 = 실제 작업을 수행하는 개발자
처럼 생각하면 이해하기 쉽습니다.
4. 서브에이전트를 사용하는 진짜 이유는 모델 가격만이 아니다
많은 사람들이 서브에이전트를 사용하는 이유를 단순히 “싼 모델을 쓰기 위해서”라고 생각합니다.
하지만 또 하나의 중요한 이유가 있습니다.
바로 컨텍스트를 분리할 수 있다는 점입니다.
메인 세션에서 프로젝트를 조사하다 보면 수많은 내용이 쌓입니다.
예를 들어
수십 개의 파일 검색 결과
빌드 로그
테스트 결과
에러 메시지
임시 분석
사용하지 않는 코드
여러 차례의 시행착오
등이 대화에 포함될 수 있습니다.
이 상태에서 모든 작업을 메인 모델이 계속 처리하면 컨텍스트가 점점 복잡해집니다.
반면 서브에이전트는 별도의 새로운 컨텍스트에서 작업을 수행할 수 있습니다.
Simon Willison 역시 서브에이전트의 장점으로 새로운 컨텍스트에서 특정 작업을 처리할 수 있다는 점을 설명하고 있습니다.
따라서 메인 모델에는 최종적으로 필요한 결과만 돌아오게 만들 수 있습니다.
이 구조는 단순한 비용 절약뿐 아니라 긴 개발 세션의 컨텍스트 관리에도 도움이 됩니다.
5. 그렇다면 모든 작업을 Haiku에게 맡기면 될까?
그렇지는 않습니다.
이 부분이 모델 위임 전략에서 가장 중요한 주의점입니다.
싼 모델을 무조건 많이 사용하는 것이 목표가 아닙니다.
작업 실패로 인해 다시 상위 모델을 호출해야 한다면 오히려 전체 비용과 시간이 증가할 수 있기 때문입니다.
예를 들어 다음 작업을 생각해 보겠습니다.
“결제 시스템의 인증 구조를 변경해줘.”
이 작업을 무조건 Haiku에게 넘기는 것은 좋은 전략이 아닙니다.
결제 로직의 구조와 데이터 흐름을 잘못 이해하면 수정 자체는 성공했더라도 심각한 문제가 발생할 수 있습니다.
반대로
“이 프로젝트에서 console.log를 찾아 제거해줘.”
같은 작업은 매우 명확합니다.
이런 경우에는 굳이 최상위 모델이 직접 파일을 하나씩 수정할 이유가 없습니다.
따라서 실전에서는 다음과 같이 생각하는 것이 좋습니다.
상위 모델에 남겨둘 작업
아키텍처 설계
복잡한 디버깅
보안 관련 판단
데이터 모델 변경
여러 시스템에 영향을 주는 변경
최종 리뷰
중요한 의사결정
Sonnet급 모델에 맡기기 좋은 작업
일반적인 기능 구현
버그 수정
테스트 코드 작성
리팩터링
API 구현
UI 기능 추가
Haiku급 모델에 맡기기 좋은 작업
파일 탐색
검색
로그 정리
단순 치환
반복 작업
간단한 문서 수정
명확한 범위의 작은 코드 변경
다만 이것은 절대적인 규칙이 아니라 출발점입니다.
실제 Claude Code의 장점은 작업에 따라 모델을 유연하게 바꿀 수 있다는 데 있습니다.
6. Claude Code에서는 직접 서브에이전트를 정의할 수도 있다
반복적으로 같은 작업을 한다면 아예 전용 서브에이전트를 만들어 놓는 방법도 있습니다.
예를 들어 테스트 결과를 분석하는 에이전트라면 다음과 같은 개념으로 구성할 수 있습니다.
---
name: test-analyzer
description: 테스트 실행 결과를 분석하고 실패 원인을 요약한다.
model: haiku
---핵심은 model을 명시할 수 있다는 점입니다.
특정 작업을 담당하는 에이전트라면 굳이 메인 모델과 동일한 모델을 사용할 필요가 없습니다.
특히 반복적인 테스트 분석이나 탐색 작업이라면 저비용 모델을 고정하는 것이 효율적일 수 있습니다.
반대로 매우 중요한 코드 리뷰 에이전트라면 상위 모델을 지정하는 방식도 가능합니다.
Claude Code는 이러한 서브에이전트를 별도의 컨텍스트에서 실행하기 때문에 메인 대화와 작업 공간을 분리할 수 있습니다.
7. CLAUDE.md를 활용하면 같은 설명을 반복할 필요도 줄어든다
토큰을 절약하려면 서브에이전트뿐 아니라 프로젝트 지침 관리도 중요합니다.
프로젝트를 열 때마다
“우리 프로젝트는 npm이 아니라 pnpm을 사용해.”
“테스트는 Vitest야.”
“TypeScript strict 모드를 사용해.”
“컴포넌트는 이 규칙으로 만들어.”
라고 반복해서 설명하면 불필요한 컨텍스트가 계속 발생합니다.
Claude Code에서는 CLAUDE.md를 프로젝트 지침 파일로 활용할 수 있습니다.
Anthropic 문서에서도 프로젝트 초기화 과정에서 CLAUDE.md를 생성하고 프로젝트의 빌드 방법, 구조, 규칙 등을 기록하는 방식을 안내하고 있습니다.
다만 여기에도 요령이 있습니다.
CLAUDE.md에 모든 문서를 집어넣는 것은 좋은 방법이 아닙니다.
자주 필요한 핵심 규칙만 넣는 것이 좋습니다.
예를 들어
# Project Rules
- Package manager: pnpm
- Test: pnpm test
- Build: pnpm build
- Do not modify generated files.
- New API endpoints require tests.
- Follow existing component patterns.정도로 간결하게 유지하는 편이 좋습니다.
8. 2026년 9~10월 모델 업데이트가 중요한 이유
이번 전략에서 최근 모델 업데이트를 빼놓을 수 없습니다.
2026년 9월에는 Opus 5.5가 공개됐고, 이어 Sonnet 5.5가 출시됐습니다. 10월에는 Haiku 5.5까지 등장했습니다.
특히 Haiku 5.5는 이전 세대보다 가격 경쟁력을 크게 높였습니다.
Anthropic 발표에 따르면 10만 토큰 이하 요청에서 Haiku 5.5의 입력 가격은 100만 토큰당 0.10달러, 출력은 0.50달러입니다. Sonnet 5.5는 입력 2달러, 출력 10달러 수준입니다.
따라서 API를 직접 사용하는 개발자라면 모델별 역할 분리가 실제 비용 차이로 연결될 수 있습니다.
또 하나 중요한 변화는 노력 수준(Effort) 조절입니다.
Sonnet 5.5에서는 노력 수준을 낮추면 응답 속도와 사용 토큰을 줄이고, 반대로 높은 수준에서는 더 많은 추론과 검증을 수행하도록 조절할 수 있습니다. Claude Code와 관련 제품에서는 기본적으로 중간 수준의 effort가 적용되고 있습니다.
즉 앞으로의 비용 최적화는 단순히
“Opus냐 Sonnet이냐 Haiku냐”
만의 문제가 아닙니다.
어떤 모델을 쓰느냐 + 어느 정도의 추론을 요구하느냐 + 어떤 작업을 서브에이전트로 분리하느냐
를 함께 관리하는 방향으로 발전하고 있습니다.
9. 실전에서 가장 추천하는 운영 방식
개인 개발자라면 처음부터 복잡한 에이전트 시스템을 만들 필요가 없습니다.
다음 정도로 시작하는 것이 현실적입니다.
1단계
메인 Claude Code 세션에서는 상위 또는 중상위 모델을 사용합니다.
2단계
작업을 시작하기 전에 다음과 같은 원칙을 전달합니다.
코딩 작업을 수행할 때 작업 난이도와 중요도를 판단해서 적절한 하위 모델을 서브에이전트로 활용해줘. 단순하고 반복적인 작업은 저렴한 모델에 맡기고, 복잡한 설계와 최종 판단은 메인 모델이 담당해줘. 서브에이전트가 수정한 결과는 반드시 메인 모델에서 검토한 뒤 다음 단계로 진행해줘.3단계
탐색이나 로그 분석처럼 결과가 명확한 작업은 적극적으로 분리합니다.
4단계
기능 구현은 Sonnet급 모델을 우선 고려합니다.
5단계
최종 설계와 리뷰는 상위 모델이 담당하게 합니다.
이렇게 하면 사람이 매번 모델을 선택하는 번거로움도 줄일 수 있습니다.
10. 오히려 토큰을 낭비하는 패턴도 있다
서브에이전트를 사용한다고 항상 효율적인 것은 아닙니다.
작은 작업을 서브에이전트에 넘기기 위해 별도의 설명을 길게 작성하면 오히려 손해일 수 있습니다.
예를 들어 한 줄짜리 수정에
“현재 프로젝트 구조는 이렇고, 이전 대화에서는 이런 이야기를 했으며, 이 파일은 이런 목적으로 만들어졌고…”
라고 긴 설명을 붙인다면 서브에이전트가 사용하는 컨텍스트가 커집니다.
따라서 좋은 위임 프롬프트는 길 필요가 없습니다.
목표, 대상, 제약조건, 완료 조건 정도만 명확하면 됩니다.
예를 들어
src/auth/login.ts의 타입 오류를 수정해줘.
기존 API 동작은 변경하지 말고,
관련 테스트를 실행한 뒤 실패하면 원인을 요약해줘.정도면 충분합니다.
11. 최근 Claude Code에서 주목할 또 하나의 변화
최근 Claude Code에는 단순한 서브에이전트 외에도 병렬적인 에이전트 작업을 지원하는 방향의 기능들이 계속 추가되고 있습니다.
Claude Code의 최신 릴리스에서는 서브에이전트 실행 방식과 백그라운드 작업 처리 방식도 계속 개선되고 있습니다.
다만 여기서 '에이전트를 많이 띄우면 무조건 빠르고 싸진다'고 생각해서는 안 됩니다.
여러 에이전트가 동시에 같은 파일을 수정하거나 서로 중복된 조사를 수행하면 오히려 관리 비용이 증가할 수 있습니다.
특히 현재 Claude Code의 Agent Teams 기능은 실험적 기능으로 제공되고 있으므로, 일반적인 프로젝트에서는 우선 기존 서브에이전트 구조부터 익히는 편이 안전합니다.
12. 가장 중요한 것은 '검토'다
이 전략을 사용할 때 절대 빠뜨리면 안 되는 단계가 있습니다.
바로 검토입니다.
하위 모델이 코드를 만들었다고 해서 그것이 최종적으로 올바른 코드는 아닙니다.
따라서 이상적인 흐름은 다음과 같습니다.
상위 모델이 계획 → 하위 모델이 실행 → 상위 모델이 검토 → 테스트 → 최종 반영
입니다.
특히 다음과 같은 작업은 반드시 사람이 확인하는 것이 좋습니다.
인증
결제
개인정보
데이터베이스 마이그레이션
권한 처리
보안 코드
운영 서버 설정
대규모 리팩터링
토큰을 몇 달러 아끼려다가 실제 서비스 장애를 발생시키면 의미가 없습니다.
마무리: 최고의 모델을 계속 쓰는 것이 능사는 아니다
Claude Code를 효율적으로 사용하는 핵심은 무조건 가장 저렴한 모델을 선택하는 것도 아니고, 반대로 가장 강력한 모델만 고집하는 것도 아닙니다.
중요한 것은 각 모델이 가장 잘하는 일을 맡기는 것입니다.
현재의 Claude 모델 체계를 기준으로 보면 다음과 같은 구조가 상당히 합리적입니다.
Opus 5.5 → 복잡한 판단과 설계
Sonnet 5.5 → 일반적인 개발과 구현
Haiku 5.5 → 반복 작업과 탐색·요약
그리고 이 작업 배분 자체를 메인 모델이 판단하도록 만들 수 있습니다.
이 방식의 장점은 단순히 API 비용을 줄이는 데 있지 않습니다.
메인 컨텍스트를 깨끗하게 유지하고, 긴 개발 세션에서 불필요한 정보를 줄이며, 각 작업에 적절한 수준의 모델을 사용할 수 있다는 것이 더 큰 장점입니다.
특히 2026년 하반기 들어 Opus 5.5, Sonnet 5.5, Haiku 5.5가 잇따라 출시되면서 모델 간 역할 분담을 활용하기가 이전보다 훨씬 쉬워졌습니다.
결국 효율적인 AI 개발의 방향은
“가장 좋은 모델 하나로 모든 일을 한다”
에서
“필요한 순간에 필요한 수준의 모델을 사용한다”
로 이동하고 있다고 볼 수 있습니다.
Claude Code를 자주 사용하는 개발자라면 모든 코드를 직접 상위 모델에게 시키기보다, 먼저 작업을 나누는 것부터 습관화해 보는 것이 좋습니다.
AI에게 일을 시키는 능력만큼이나 어떤 AI에게 어떤 일을 맡길 것인지 결정하는 능력이 중요해지고 있기 때문입니다.
