당신이 Haiku를 과소평가하는 이유

대부분의 사람들은 모델을 잘못된 방식으로 선택합니다. 리더보드(leaderboard)를 보고 Opus가 상단에 있는 것을 확인하면 기본적으로 그것을 선택합니다. 비용을 아끼고 싶다면 Sonnet을 선택하죠. 하지만 Haiku는 거의 선택되지 않는데, 그 이유는 이름이 "작다(small)"라고 말하고 있기 때문입니다.

그러한 습관은 손해를 불러옵니다. 당신이 실제로 구축하는 많은 작업에서 Haiku가 적절한 선택임에도 불구하고, 작업에서 전혀 사용하지 않을 성능을 위해 3~5배 더 많은 비용을 지불하고 있습니다. 이 포스트는 어떻게 모델을 선택해야 하는지, 그리고 왜 Haiku를 지금보다 더 자주 기본값으로 사용해야 하는지에 대해 다룹니다.

요약하자면: "어떤 모델이 가장 좋은가"에서 시작하지 마세요. "이 작업에 무엇이 필요한가"에서 시작하세요. 대부분의 작업은 많은 것을 필요로 하지 않습니다.

비교 (Comparison)

선택할 때 중요한 수치들을 포함한 현재 라인업은 다음과 같습니다.

	Haiku 4.5	Sonnet 4.6	Opus 4.8
Model ID	`claude-haiku-4-5`	`claude-sonnet-4-6`	`claude-opus-4-8`
...

두 가지 사항이 눈에 띕니다.

첫째, **가격 (price)**입니다. Haiku의 입력 비용은 Opus의 5분의 1, Sonnet의 3분의 1 수준입니다. 출력 비용도 동일한 비율입니다. 만약 Opus를 통해 100만 토큰을 보내는 데 25달러를 썼는데, Haiku로도 충분히 처리할 수 있는 작업이었다면 당신은 아무런 이득 없이 20달러를 더 쓴 것입니다. 그리고 그 격차는 요청(request)마다 발생하므로 복리로 쌓입니다. 하루에 만 번 실행되는 기능이 Haiku 대신 Opus에서 실행된다면, 그것은 단순한 오차가 아닙니다. 그것은 출시될 기능과 비용 문제로 인해 폐기될 기능 사이의 차이입니다.

둘째, **컨텍스트 윈도우 (context window)**입니다. 이 부분은 Haiku가 포기하는 지점입니다: 1M(100만) 토큰 대신 200K(20만) 토큰을 제공합니다. 이것이 실제적인 트레이드오프(tradeoff)이며, 언제 Haiku를 사용해야 하는지를 명확히 알려줍니다. 이 부분은 나중에 다시 다루겠습니다.

사고 모델 (The mental model)

모델의 순위를 매기는 것을 멈추세요. 대신 _작업(tasks)_의 순위를 매기세요. 눈앞에 놓인 작업에 대해 세 가지 질문을 던져보세요:

실제 추론 (Reasoning)이 필요한가, 아니면 경계가 정해져 있는가 (Bounded)? 유능한 주니어 직원이 명확한 사양 (Spec)을 바탕으로 큰 판단 없이 수행할 수 있는 작업이라면 경계가 정해진 (Bounded) 작업입니다. 예를 들어, 특정 필드 추출하기, 다섯 가지 범주 중 하나로 분류하기, 다른 어조로 다시 쓰기, 제공된 텍스트에서 답변 찾기 등이 이에 해당합니다. 반면, 경로가 명확하지 않은 작업은 추론 (Reasoning)이 필요합니다. 여러 파일에 걸친 디버깅 (Debug), 마이그레이션 (Migration) 계획 수립, 트레이드오프 (Tradeoffs) 비교 등이 그 예입니다.
오답의 비용은 얼마인가? 잘못된 출력이 테스트, 스키마 체크 (Schema check), 또는 2초 뒤의 사람에 의해 발견된다면, 오류 비용은 저렴하므로 속도와 가격을 우선시해야 합니다. 만약 잘못된 출력이 실제 돈을 지불하게 하거나 프로덕션 (Production) 환경을 망가뜨린다면, 오류 비용은 비싸며 더 나은 모델을 위해 비용을 지불해야 합니다.
얼마나 자주 실행되며, 지연 시간 (Latency)이 중요한가? 하루에 한 번 실행되는 야간 작업 (Nightly job)은 속도나 호출당 비용을 신경 쓰지 않습니다. 하지만 모든 키 입력마다 실행되는 루프 (Loop)나 수십만 개의 아이템을 처리하는 배치 (Batch) 작업은 두 가지 모두를 매우 중요하게 여깁니다.

이제 답변을 매핑해 보세요:

경계가 정해져 있고 (Bounded), 틀려도 비용이 저렴하며, 처리량이 많거나 지연 시간에 민감함 → Haiku. 당신이 구축하는 대부분의 작업이 여기에 해당합니다.
어느 정도의 판단이 필요하고, 출력이 길며, 리스크가 중간 정도임 → Sonnet.
어려운 추론 (Hard reasoning)이 필요하고, 단계가 많은 긴 작업이며, 틀렸을 때의 비용이 비쌈 → Opus.

당신이 Haiku를 과소평가하는 이유는 리더보드 (Leaderboard)를 통해 하향식으로 모델을 선택했기 때문입니다. 리더보드의 테스트는 항상 어려운 과제들뿐입니다. 하지만 프로덕션 (Production) 환경에 배포되는 작업 중 리더보드 수준으로 어려운 작업은 거의 없습니다. 대부분은 추출 (Extraction), 라우팅 (Routing), 분류 (Classification), 요약 (Summaries), 그리고 반복적으로 수행되는 작은 편집 작업들입니다. 그것이 바로 Haiku가 만들어진 목적입니다.

Haiku가 실제로 잘하는 것

이것들은 Haiku가 타협안이 아닌, 올바른 도구로서 기능하는 작업들입니다.

분류 및 라우팅 (Classification and routing). "이 티켓이 버그인가요, 기능 요청인가요, 아니면 스팸인가요?" "이것은 여덟 개의 대기열 중 어디로 가야 하나요?" 범위가 제한적이고, 검증 가능하며, 종종 처리량이 매우 높습니다.
추출 (Extraction). 이 메시지에서 이름, 이메일, 플랜을 뽑아내세요. 이를 구조화된 출력 (Structured outputs, Haiku는 이를 지원함)과 결합하면, 결과물은 파싱하고 기도하며 매달려야 하는 문자열이 아니라 검증된 객체 (Object)가 됩니다.
요약 및 재작성 (Summarizing and rewriting). 이 단락을 다듬으세요. 이 메모들을 변경 로그 (Changelog) 한 줄로 바꾸세요. 이것을 번역하세요. 입력값이 바로 거기에 있으므로, 추론 (Reasoning)할 것이 없습니다.
1차 필터링 (First-pass filtering). 수천 개의 기록에 대해 Haiku를 실행하여 자세히 살펴볼 가치가 있는 50개를 찾아낸 다음, 그 50개만 더 큰 모델로 보냅니다. 이렇게 하면 품질에는 거의 영향을 주지 않으면서 Opus 비용을 95% 절감할 수 있습니다.
에이전트 (Agent)의 내부 단계. 이에 대해서는 다음 섹션에서 더 자세히 다루겠습니다. 왜냐하면 이것이 가장 많이 변화하는 패턴이기 때문입니다.

이것들을 하나로 묶는 공통점은 다음과 같습니다: 정답이 입력값 안에 있거나 짧은 선택지 목록 안에 있으며, 출력값이 짧고, 저렴하게 검증할 수 있다는 점입니다. 그것이 바로 Haiku의 영역 (Haiku zone)입니다.

가장 중요한 패턴: 혼합 모델 (Mixed models)

가장 큰 실수는 모델 선택을 앱 전체에 대한 단 하나의 결정으로 취급하는 것입니다. 그것은 '단계별 (per step)' 결정이어야 합니다.

진정한 에이전트는 한 가지 일만 하지 않습니다. 파일을 읽고, 검색하고, 계획하고, 편집하고, 확인합니다. 이러한 단계들은 난이도가 동일하지 않습니다. 계획 (Planning) 단계에는 Opus가 필요할 수 있습니다. 하지만 "이 12개의 파일을 읽고 인증 (Auth)을 언급하는 파일이 무엇인지 알려줘"라는 단계는 필요하지 않습니다. 그것은 Haiku의 작업이며, 보통 그런 작업은 매우 많습니다.

따라서 메인 루프 (Main loop)는 강력한 모델로 실행하고, 저렴하고 병렬적인 하위 작업 (Sub-tasks)들은 Haiku에게 맡기세요. 이것이 바로 Claude Code가 작동하는 방식입니다. Claude Code의 탐색 하위 에이전트 (Explore subagents)는 Haiku에서 실행되는 반면, 메인 에이전트는 더 큰 모델을 유지합니다. 비싼 모델은 사고(Thinking)를 하고, 저렴하고 빠른 모델은 발품을 파는 작업 (Legwork)을 수행하며, 종종 여러 개를 동시에 처리합니다.

대화 중간에 모델을 교체하는 대신 서브에이전트 (subagents)를 사용하는 두 번째 이유는 다음과 같습니다. 모델을 전환하면 프롬프트 캐시 (prompt cache)가 무효화됩니다. 캐시는 하나의 모델에 종속되어 있습니다. 만약 메인 루프 (main loop)를 Opus에서 Haiku로, 그리고 다시 되돌린다면, 매번 캐싱된 접두사 (prefix)를 버리게 되며 이를 다시 구축하기 위해 전체 비용을 지불해야 합니다. 하위 작업 (sub-task)을 위해 Haiku 서브에이전트를 생성하면 메인 루프의 캐시를 온전하게 유지할 수 있습니다. 즉, 저렴한 모델을 사용하면서 동시에 따뜻한 캐시 (warm cache) 상태를 유지할 수 있는 것입니다.

대략적인 구조는 다음과 같습니다:

# 메인 루프: 어려운 부분을 수행하는 모델
plan = client.messages.create(model="claude-opus-4-8", ...)

...

여러 토큰 볼륨 (token volume)의 대부분은 이러한 하위 작업들에서 발생합니다. 이 작업들을 Haiku로 옮기면, 그 어떤 단일 모델 업그레이드보다도 청구 금액이 크게 달라질 것입니다.

대량 작업을 위한 Haiku와 배치 (Batch) API의 조합

작업이 시간에 민감하지 않다면 — 밤사이의 분류 (classification), 라벨 백필링 (backfilling labels), 대규모 내보내기 (export) 처리 등 — 배치 API (Batch API)를 통해 전송하세요. 이는 Haiku의 이미 낮은 가격에서 추가로 50%를 더 할인받는 것입니다. Haiku의 출력 비용은 백만 토큰당 5달러에서 2.50달러로 떨어집니다. 대량 작업에 있어서는 그 어떤 것도 이에 근접할 수 없으며, 대량 작업은 거의 항상 경계가 정해진 작업 (bounded work)이기 때문에 품질 또한 충분합니다.

Haiku가 잘못된 선택인 경우

이 사고 모델 (mental model)은 양날의 검과 같습니다. 잘못된 작업에 Haiku를 사용하는 것 또한 실수입니다. 다음과 같은 경우에는 상위 모델로 넘겨야 합니다:

작업에 깊고 다단계적인 추론 (multi-step reasoning)이 필요한 경우. Haiku는 빠르고 직접적으로 답변합니다. Haiku는 모델에게 얼마나 깊게 생각할지를 지시하는 설정인 effort 파라미터를 지원조차 하지 않으며, 이 기능은 Sonnet 4.6과 Opus 티어에서만 지원됩니다. 이것이 핵심입니다. Haiku는 느린 사고가 아닌 빠른 답변을 위해 구축되었습니다. 어려운 디버깅, 계획 수립, 심층 연구 작업은 Opus로 보내세요.
컨텍스트 (context)가 매우 큰 경우. 200K도 많은 양이지만, Sonnet과 Opus는 1M를 제공합니다. 전체 코드베이스나 방대한 문서 더미를 한꺼번에 입력해야 한다면 더 큰 컨텍스트 윈도우 (context window)가 필요합니다.
잘못된 답변의 비용이 큰 경우. 돈을 움직이거나, 검토 없이 사용자에게 배포되거나, 되돌리기 어려운 작업들이 이에 해당합니다. 더 나은 모델에 비용을 지불하세요. 방지한 오류의 가치는 절약한 토큰 (tokens)의 가치보다 더 큽니다.
출력이 길고 구조적인 경우. 긴 코딩 실행이나 방대한 생성 문서 등이 해당됩니다. 이 지점이 바로 Opus의 128K 출력 능력과 긴 작업 동안 흐름을 놓치지 않는 재능이 제값을 발휘하는 곳입니다.

어떤 티어가 작업에 필요한지 확신이 서지 않는다면, 저렴한 실험 방법은 먼저 Haiku에서 실행해 보고 실패 사례를 살펴보는 것입니다. 결과가 이미 충분히 좋다면 그대로 진행하면 됩니다. 만약 명확하고 일관된 방식으로 실패한다면, 비용을 지불하기 전에 해당 작업에 정확히 어떤 능력이 필요한지 파악하게 된 것입니다.

시도하는 방법

단 한 줄의 변경만으로 가능합니다. API 인터페이스 (API surface)는 세 모델 모두 동일하므로, 모델 문자열을 교체하는 것이 보통 전부입니다:

response = client.messages.create(
    model="claude-haiku-4-5",
    max_tokens=1024,
...

시작하기 전에 알아두어야 할 두 가지가 있습니다. Haiku는 상위 모델들과 분리된 자체 속도 제한 (rate-limit) 풀을 가지고 있으므로, 실제로 예상하는 볼륨에서 처리량 (throughput)을 테스트하십시오. 그리고 Haiku는 effort 파라미터를 지원하지 않으므로, 요청에 해당 파라미터가 포함되어 있다면 제거해야 합니다. 그렇지 않으면 호출 시 오류가 발생합니다.

가장 호출량이 많고 지루한 API 호출을 하나 골라보세요. 분류기(classifier), 추출기(extractor), 혹은 하루에 수천 번씩 실행하는 요약기(summarizer) 같은 것 말입니다. 그것을 Haiku로 옮기고, 하루 동안 실패 사례를 관찰한 뒤, 주말에 청구서를 확인해 보세요. 그 단 한 번의 변화가 보통 실험 비용의 몇 배를 상회하는 가치를 돌려줄 것입니다.

Haiku 4.5는 실제로 성능이 좋은 걸까요, 아니면 그냥 저렴한 걸까요?
둘 다입니다. Haiku 4.5는 성능을 깎아낸 모델이 아니라 현세대 모델입니다. 범위가 제한적이고 명확하게 정의된 작업(bounded, well-specified tasks)에서는 더 큰 모델들과의 격차가 작으며, 스키마 체크(schema check)나 테스트를 추가하면 그 차이가 거의 느껴지지 않는 경우가 많습니다. 격차는 어려운 추론(hard reasoning)에서 나타나는데, 이는 어차피 Haiku로 보내지 말아야 할 작업들입니다.

모델 ID는 무엇인가요?
claude-haiku-4-5 또는 고정된 스냅샷인 claude-haiku-4-5-20251001입니다.

정말로 얼마나 더 저렴한가요?
백만 토큰당 입력(in) $1 / 출력(out) $5로, Sonnet의 $3 / $15 및 Opus의 $5 / $25와 비교됩니다. Opus의 5분의 1, Sonnet의 3분의 1 수준입니다. Batch API를 사용하면 비용을 다시 절반으로 줄일 수 있습니다.

Haiku는 무엇을 포기해야 하나요?
더 작은 컨텍스트 윈도우(context window, 200K vs 1M), effort 파라미터 미지원, 그리고 어려운 다단계 추론(multi-step reasoning)에서의 깊이 부족입니다. 이 세 가지 항목이 바로 Haiku를 넘어 다른 모델을 사용해야 할 시점을 알려줍니다.

구조화된 출력(structured outputs)을 지원하나요?
네. Haiku 4.5, Sonnet 4.6, Opus 4.8 모두 지원합니다. 추출(extraction)과 분류(classification)에 이를 사용하여, 파싱(parse)해야 하는 문자열 대신 검증된 객체(validated object)를 받으세요.

그렇다면 언제 여전히 Opus를 사용해야 하나요?
가장 어려운 추론, 가장 긴 다단계 작업, 그리고 오답의 비용이 큰 모든 작업에 사용하세요. 앱 전체가 아니라, 그 기능이 꼭 필요한 단계에만 Opus를 사용하십시오.