Claude Code에서 여러 모델을 구분하여 사용하기──Bloom 분류를 통한 모델 라우팅 설계

「어떤 모델을 호출해야 할까?」라는 판단 피로

Claude Code로 하네스(Harness)를 구축하기 시작하면 곧바로 벽에 부딪힌다.

「이 태스크는 haiku로 충분할까, 아니면 sonnet이 필요할까?」

안이하게 opus를 사용하면 품질은 올라가지만, 비용이 급증한다. haiku로 해결하려 하면 분석 계열 태스크에서 출력이 흔들린다. 「대충 비싼 모델을 써두자」는 전략은 지갑에 친절하지 않다. 반대로 「전부 haiku로 몰아가자」는 전략은 품질의 편차로 인해 고민하게 된다.

나는 한 달 이상 이 판단을 감각에 의존해 왔다. 매번 「이건 sonnet으로 하자」, 「이건 haiku로 충분하겠지」라고 생각하는 것은 생각보다 비용이 많이 든다. 코드를 작성할 때마다 모델 선택에 머리를 쓰는 것은 본질적인 업무가 아니다.

이 문제에 대해, 교육 심리학의 「Bloom 분류 (Bloom's Taxonomy)」를 사용하여 체계적인 답을 내놓았다.

TL;DR

• Bloom 분류 (인지적 분류학 L1~L6)를 모델 선택 규칙에 대응시킨다
• L1-L3 → haiku, L4-L5 → sonnet, L6 → opus
• 간이 판정법: 「절차서가 있는가? Yes → haiku / No → sonnet 이상」
• Agent 호출 시 model=을 명시함으로써 판단을 규칙화할 수 있다

Bloom 분류란 무엇인가

Bloom 분류 (Bloom's Taxonomy)는 1956년 교육 심리학자 벤자민 블룸(Benjamin Bloom)이 제창한 인지 프로세스의 계층 모델이다. 교육 문맥에서는 「학습 목표를 어느 인지 수준으로 설정할 것인가」에 사용된다.

L1 (기억)에서 L6 (창조)로 갈수록 인지적 복잡성이 높아진다. 단순한 사실의 회상이 L1이고, 새로운 것을 만들어내는 것이 L6다.

이를 AI 태스크의 「사고의 무게」에 대입하는 것이 Bloom 분류를 통한 모델 라우팅이다.

L1~L6 와 모델의 매핑

Bloom 레벨	인지 프로세스	태스크 예시	사용하는 모델
L1 기억	사실의 회상·목록 취득	파일 목록, git log 표시	haiku
...

중요한 점은 「태스크의 난이도」가 아니라 「필요한 인지 프로세스의 종류」라는 점이다. 처리 과정이 길더라도 L3 (절차대로 수행)라면 haiku로 충분하며, 짧은 태스크라도 L6 (전례 없는 설계 판단)라면 opus가 필요하다.

간이 판정 플로우

모든 태스크에 대해 L1~L6를 판정하는 것은 번거롭다. 그래서 일상적으로 사용할 수 있는 간이 규칙을 마련했다.

판정의 출발점은 하나다.

「이 태스크에 절차서가 있는가?」

• Yes → 절차대로 움직이기만 하면 됨 → haiku
• Yes 이지만 도중에 판단이 필요함 → sonnet
• No → 베스트 프랙티스 (Best Practice)를 조합함 → sonnet
• No 이면서 전례도 없음 → 제로에서부터 창조함 → opus

「절차서가 있는가?」는 직관적으로 판단할 수 있다. 「CLAUDE.md에 적힌 절차를 따르기만 하면 되는가?」, 「과거의 구현 패턴을 반복하는 것뿐인가?」가 Yes라면 haiku다.

model= 지정

구현 예시: Agent 호출 시 Claude Code의 하네스에서는 Agent 툴을 호출할 때 model 파라미터를 명시할 수 있다. 이를 규칙으로서 rules/에 적어둔다.

## Agent 호출 시의 Bloom Routing 규칙
Agent 툴을 호출할 때는 태스크의 Bloom 레벨을 판정하여
model 파라미터를 지정할 것.
...

실제 호출 패턴을 구체적으로 나타낸다.

# ❌ 모델 지정 없음 (모든 태스크가 sonnet default가 됨)
Agent(subagent_type="researcher")
Agent(subagent_type="planner")
...

이를 규칙으로 적어둠으로써, 매번의 판단은 「Bloom 레벨은 무엇인가?」라는 하나의 질문으로 집약된다.

API 비용에 미치는 영향

Anthropic이 공개하고 있는 요금 (2025년 시점)으로 시산하면, Haiku는 Sonnet과 비교했을 때 input/output 모두 약 4~5배의 가격 차이가 있다.

모델	Input	Output
Haiku 4.5	$0.80/MTok	$4/MTok
Sonnet 4.6	$3/MTok	$15/MTok

모든 태스크를 Sonnet으로 실행했을 때와 L1-L3 수준의 태스크(검색·정형 출력·로그 요약)를 Haiku로 전환했을 때를 비교하면, Haiku로 전환하는 태스크의 비율에 따라 다음과 같은 절감이 이론상 기대할 수 있다.

Haiku로 전환하는 비율	추산 비용 비율
30%	약 85% (15% 절감)
...

실제 절감률은 태스크의 비율과 토큰량에 따라 달라진다. "이 하네스(Harness)에서는 어느 정도가 L1-L3인가"를 자신의 워크플로우에서 확인한 후 적용 비율을 판단하는 것이 좋다.

응답 측면:

Haiku는 Sonnet에 비해 응답이 빠르다. L1-L3 태스크에서 Haiku를 사용하면 "간단한 파일 확인", "리스트업" 등의 대기 시간이 체감상 짧아진다. 하네스 전체의 처리량(Throughput)이 올라간다.

품질 측면:

L4 이상을 확실하게 Sonnet/Opus로 할당함으로써, 분석·설계 태스크의 출력 편차를 줄일 수 있다. "Haiku를 쓰면 왠지 LLM스러운 성의 없는 답변이 돌아온다"는 문제를 회피할 수 있다.

규칙을 CLAUDE.md에 작성하여 판단을 자동화하기

개별 에이전트(Agent) 호출 시마다 매번 Bloom 레벨을 고민하는 것이 아니라, CLAUDE.md의 rules/ 폴더에 규칙으로 작성해 두는 것이 핵심이다.

# rules/bloom-routing.md
## Bloom 레벨 판정 (모델 선택 규칙)
Agent 도구 호출 전에 다음을 판정한다:
...

이 규칙을 CLAUDE.md에서 읽어오는 rules/에 배치해 두면, Claude Code 본체가 자동으로 참조한다. 모델 선택의 판단이 코드 측에 맡겨지는 것이 아니라, 규칙으로서 명문화된다.

요약

• "어떤 모델을 사용할 것인가"에 대한 판단 피로는 Bloom 분류로 해소할 수 있다.
• L1-L3 (정형·기억·응용) → Haiku, L4-L5 (분석·평가) → Sonnet, L6 (창조) → Opus
• 간이 판정은 "절차서가 있는가? Yes → Haiku / No → Sonnet 이상"이라는 한 가지 질문으로 끝낼 수 있다.
• Agent 호출 시 model= 파라미터를 명시함으로써 규칙을 구현에 반영한다. L1-L3 태스크를 Haiku로 전환하면 전환 비율에 따라 수십 %의 비용 절감을 기대할 수 있다 (Anthropic 공개 요금 기준 추산).

모델 선택은 "감각"으로 하기에는 판단 횟수가 너무 많다. Bloom 분류라는 기존의 프레임워크를 빌림으로써, 체계적이고 재현 가능한 규칙이 된다.

하네스 설계의 전체 모습은 Claude Code 하네스 엔지니어링 실전 Playbook에서 해설하고 있다.

감상이나 "이 케이스는 어떻게 하나요?"와 같은 질문은 댓글로 편하게 남겨주시면 감사하겠습니다. '좋아요'도 큰 힘이 됩니다.

저자 코멘트

참고 자료

• Bloom's Taxonomy (Wikipedia) — Benjamin Bloom이 1956년에 제창한 인지 프로세스의 계층 모델 (L1~L6)
• Anthropic API 요금 페이지 — Haiku / Sonnet / Opus의 input·output 요금. 기사 내 추산의 근거

Discussion