Haiku 5.5: Anthropic이 모델 능력을 하나의 분업 체계로 바꾸고 있다

Claude Haiku 5.5의 가치는 더 빠르고 더 저렴하게 답하는 데만 있지 않고, 모델 호출을 대규모로 배포할 수 있는 인프라로 바꾸기 시작했다는 데 있다.

Anthropic은 2026년 10월 7일 Claude Haiku 5.5를 발표했다. 먼저 혼동하기 쉬운 이름 하나를 밝힌다. 공개된 Anthropic 공식 자료에서 모델 이름은 Claude Haiku 5.5이고, 모델 ID는 claude-haiku-5-5이며, "Claude Hiya 5.5"라는 이름의 공식 모델은 없다. 이 글은 내내 Haiku 5.5를 쓴다.

Anthropic이 이 모델을 두는 위치는 분명하다. 높은 동시성, 낮은 지연, 비용에 민감한 작업을 위한 작은 모델이며, 분류, 정보 추출, 요약, 컨텍스트 압축, 데이터베이스 질의, 브라우저 조작, Agent 하위 작업에 적합하다. 공식 설명에 따르면 Haiku 5.5의 평균 운영 비용은 Haiku 4.5보다 약 75% 낮다. 또한 Haiku 시리즈에서 조절 가능한 effort 설정을 처음 제공하는 모델이다.

그래서 Haiku 5.5에 대한 질문은 “또 하나의 더 강한 작은 모델인가”에서 더 실제적인 질문으로 바뀐다. 한 모델이 대량으로 호출될 만큼 충분히 싸질 때, AI 제품의 모델 분업은 어떻게 달라지는가?

Claude 5.5 패밀리는 분명한 분업을 이루고 있다

모델 이름만 보면 Opus, Sonnet, Haiku를 같은 능력 순위표의 세 자리로 이해하기 쉽다. 더 정확한 이해는, 이것들이 서로 다른 작업 부하를 위한 모델 분업을 이루고 있다는 것이다.

모델	더 알맞은 역할	전형적인 작업
Claude Opus 5.5	복잡한 문제의 전문가이자 장기 계획자	복잡한 Agent, 장시간 코딩, 어려운 추론, 핵심 결정
Claude Sonnet 5.5	일상 업무의 주력 모델	코드 수정, 문서 생성, 분석, 여러 단계의 지식 작업
Claude Haiku 5.5	고빈도 호출의 실행 계층	분류, 추출, 요약, 압축, 라우팅, 브라우저와 하위 에이전트 작업

Anthropic의 모델 개요도 비슷한 위치를 쓴다. Opus 5.5는 장시간 Agent 프로그래밍과 지식 작업을 향하고, Sonnet 5.5는 속도와 지능의 균형을 강조하며, Haiku 5.5는 높은 동시성과 낮은 지연의 분류, 추출, 라우팅 작업을 향한다.

이는 Haiku 5.5의 경쟁력이 반드시 “모든 일에서 중형 모델보다 강하다”로 나타나지 않는다는 뜻이다. 그것은 다른 곳에서 나타날 가능성이 더 크다. 비용, 지연 또는 처리량 때문에 자동화할 가치가 없던 많은 국소 작업을, 계속 실행할 수 있는 시스템 단계로 바꿀 수 있는가.

가격이 내리면서 바뀌는 것은 호출 방식이다

Haiku 5.5의 공식 가격은 두 구간으로 나눠 이해해야 한다. 입력 프롬프트가 100K tokens를 넘지 않는 요청의 입력 가격은 백만 tokens당 $0.10이고, 출력 가격은 백만 tokens당 $0.50이다. 100K tokens를 넘으면 가격은 각각 $0.50과 $2.50이다.

요청 규모	입력	출력	Cache read
100K tokens 이하	$0.10 / MTok	$0.50 / MTok	$0.01 / MTok
100K tokens 초과	$0.50 / MTok	$2.50 / MTok	$0.05 / MTok

여기에는 놓치기 쉬운 세부 사항이 두 가지 있다.

첫째, 단가가 내리는 것과 실제 비용이 내리는 것은 같은 일이 아니다. Anthropic의 “평균 운영 비용이 약 75% 낮다”는 말은 이미 새 tokenizer가 가져온 token 사용량 변화를 고려한 것이다. 즉, 새 모델과 이전 모델의 백만 token 단가를 나누기만 해서 제품 청구서가 같은 비율로 내려간다고 추론할 수는 없다.

둘째, 모델이 작업을 성공적으로 끝냈는지는 실제 비용에 영향을 준다. 호출 한 번은 매우 쌀 수 있다. 그러나 재시도가 필요하거나 Sonnet으로 fallback하거나 사람 검사가 늘어나면, 최종 작업 비용은 여전히 높을 수 있다.

따라서 제품 팀이 더 주목해야 할 지표는 이것이다.

성공한 작업 하나당 비용
= 작업을 마치는 데 든 모델과 도구 비용의 합 ÷ 성공적으로 마친 작업 수

서로 다른 아키텍처를 더 비교하려면, 재시도, fallback, 도구 호출, 사람 인수를 총 청구서에 넣어야 한다.

Haiku 5.5에서 가장 중요한 변화 중 하나는 effort를 조절할 수 있게 된 것이다

Haiku 5.5는 Haiku 시리즈에서 조절 가능한 effort를 처음 제공하는 모델이다. 이 설정은 “모델 선택”이 유일한 비용 스위치가 아니게 하고, 시스템은 같은 모델 안에서도 추론에 넣는 양을 조절할 수 있다.

자동차의 주행 모드로 이해할 수 있다.

• 단순한 분류와 형식 변환에는 더 낮은 effort를 써서 속도와 낮은 비용을 우선한다.
• 구조화된 추출과 긴 글 압축에는 중간 effort를 써서 품질과 비용의 균형을 맞춘다.
• 여러 단계의 판단이 필요한 작업에는 effort를 높인다.
• 그래도 작업이 실패하면 Sonnet 또는 Opus로 올린다.

이것은 새로운 결정식을 가져온다.

최종 효과 = 모델 × effort × 컨텍스트 × 도구 × 재시도 전략

따라서 앞으로 모델을 비교할 때는 “Haiku 5.5와 Sonnet 5.5 중 누가 더 강한가”만 물을 수 없다. 다음도 물어야 한다.

• 같은 작업에서 어느 effort 구간이 가장 이득인가?
• effort를 높여 얻는 품질 향상이 추가 비용을 덮는가?
• 단순한 작업에서 effort를 높이는 것은 기다리는 시간만 늘리는가?
• Haiku에게 한 번 더 시도하게 하는 편이 이득인가, 아니면 Sonnet을 한 번 호출하는 편이 이득인가?

이것이 Haiku 5.5를 출력 한 번의 느낌이 아니라 작업 단위 비용으로 평가하는 편이 더 알맞은 이유다.

Agent는 “큰 모델 하나가 모든 것을 맡는 구조”에서 계층 협업으로 바뀔 수 있다

과거의 많은 Agent 구조는 이와 비슷했다. 사용자가 요청을 내면, 큰 모델 하나가 계획, 검색, 도구 호출, 결과 정리, 최종 답변을 맡았다.

사용자 요청 → 큰 모델이 계획 → 큰 모델이 검색 → 큰 모델이 요약 → 큰 모델이 출력

이 구조는 단순하지만, 모든 국소 동작이 똑같이 비싼 모델을 쓰게 한다. 문서를 수십 건 검색하거나, 기록을 수백 건 처리하거나, 브라우저를 반복해서 호출하는 Agent에서는 비용과 지연이 금방 쌓인다.

Haiku 5.5는 아래와 같은 계층 구조에 더 잘 들어간다.

사용자 요청
   ↓
Sonnet 또는 Opus가 작업을 나누고 계획을 세운다
   ↓
Haiku 5.5가 검색, 분류, 추출, 요약, 한 단계 도구 호출을 맡는다
   ↓
Sonnet 또는 Opus가 결과를 검토하고 최종 결정을 마친다

이 구조에서 Haiku 5.5의 가치는 가장 복잡한 작업을 혼자 끝내는 것이 아니라, Agent의 “작업자 층”이 되는 것이다. 수가 가장 많고, 구조가 비교적 분명하며, 검증할 수 있는 국소 작업을 처리한다.

Haiku 5.5에 맡기기 적합한 작업

• 사용자 요청을 서로 다른 작업 흐름으로 라우팅한다.
• 문서 하나 또는 몇 개에서 고정 필드를 추출한다.
• 티켓을 분류하고 우선순위를 매긴다.
• 긴 대화를 다음 Agent 턴에 필요한 컨텍스트로 압축한다.
• 검색 결과의 중복을 제거하고 1차 요약을 한다.
• 명확한 브라우저 조작을 한 번 수행한다.
• 코드 형식을 검사하거나, 간단한 테스트를 만들거나, 국소 코드를 설명한다.
• Sonnet 또는 Opus의 하위 에이전트로서 짧은 작업 한 조각을 끝낸다.

기본값으로 Haiku 5.5에 맡기지 말아야 할 작업

• 장기 계획이 필요한 복잡한 프로젝트.
• 여러 파일, 여러 의존성, 여러 차례의 피드백이 얽힌 코드 수정.
• 한 번의 실수가 큰 손실을 가져오는 핵심 결정.
• 긴 작업 과정에서 복잡한 상태를 유지해야 하는 일.
• 자동으로 검증할 수단이 없고 사람의 판단에만 의존하는 작업.

여기서 핵심은 모델에 “할 수 있다” 또는 “할 수 없다”는 딱지를 붙이는 것이 아니라, 작업이 실패한 뒤의 대가를 평가하는 것이다. 자동으로 검사할 수 있고 실패 뒤 다시 시도할 수 있는 작업에서는 Haiku 5.5의 가성비가 더 매력적이다. 실패의 대가가 큰 작업에서는 Sonnet 또는 Opus가 여전히 더 안정적이다.

일반 개발자는 세 등급 모델을 어떻게 고르는가

작업의 복잡도와 실패의 대가로 단순한 라우팅을 먼저 할 수 있다.

작업의 특징	기본 선택	올릴 조건
출력 형식이 고정되어 있고 자동 검증이 된다	Haiku 5.5	형식 오류가 이어지거나 핵심 필드가 빠진다
호출량이 많고 지연에 민감하다	Haiku 5.5	p95 지연 또는 실패율이 제품 임계값을 넘는다
요약, 압축, 분류, 추출이 필요하다	Haiku 5.5	문서 사이의 추론이나 컨텍스트 충돌이 나타난다
일반적인 지식 작업과 코드 수정	Sonnet 5.5	작업의 범위가 길거나 여러 차례의 계획이 필요하다
복잡한 Agent와 장기 코딩	Sonnet 5.5 또는 Opus 5.5	오류 허용도가 매우 낮거나 깊은 추론이 필요하다
고위험 판단과 최종 검토	Sonnet 5.5 또는 Opus 5.5	오류의 대가와 검증 능력에 따라 결정한다

이 표를 영원히 고정된 답으로 보면 안 된다. 실제로 운영에 넣기 전에, 자신의 작업 집합으로 각 등급 모델이 성공률, 지연, 성공한 작업 하나당 비용에서 갈라지는 지점을 측정해야 한다.

100K tokens는 특히 살펴야 할 가격 경계다

Haiku 5.5의 홍보 가격은 매우 낮지만, 100K tokens 이후에는 가격이 뚜렷이 올라간다. 긴 문서, 코드 저장소, 긴 대화를 다루는 팀은 모델의 공개된 시작 가격만 보면 안 된다.

긴 컨텍스트 작업 흐름은 몇 단계로 나눌 수 있다.

1. 문서를 처음 읽을 때 캐시를 만든다.
2. Haiku 5.5로 컨텍스트를 압축한다.
3. 현재 질문과 관련된 조각만 Sonnet에 넘긴다.
4. 중간 결과를 구조화된 상태로 저장한다.
5. 매 턴마다 전체 기록을 다시 보내지 않는다.

이 흐름에는 이점이 두 가지 있다. 100K 가격 구간을 넘을 확률을 낮추고, 서로 다른 모델이 서로 다른 일을 맡게 한다.

따라서 Haiku 5.5의 긴 컨텍스트 가치는 “최대 몇 tokens를 읽을 수 있는가”만으로 잴 수 없다. 더 실제적인 질문은 이것이다.

• 원본 내용을 얼마나 모델에 넣어야 하는가.
• 어떤 내용을 먼저 압축해야 하는가.
• 캐시 적중률은 얼마인가.
• 100K를 넘긴 뒤의 가격을 여전히 받아들일 수 있는가.
• 압축으로 잃은 정보가 이후 작업을 실패하게 하는가.

Haiku 5.5의 발표는 모델 평가의 초점도 바꾼다

공식 페이지는 이미 GDPval-AA, OSWorld, Humanity's Last Exam, Terminal-Bench 등 여러 성적을 제공한다. 그것들은 독자가 모델의 대략적인 능력 범위를 아는 데 도움이 되지만, 제품 팀은 여전히 자신의 작업으로 한 테스트가 필요하다.

실제 시스템에서 가장 볼 만한 것은 한 모델이 어떤 기준에서 받은 단일 성적이 아니라, 아래 지표들이다.

• 작업 성공률.
• 출력 품질.
• p50과 p95 지연.
• 입력과 출력 token 수.
• 재시도율.
• 도구 호출 오류율.
• fallback률.
• 사람 인수율.
• 성공한 작업 하나당 비용.

특히 반복 실행의 안정성에 주의해야 한다. 같은 Prompt가 멋진 답을 한 번 얻었다는 것은 그 실행이 성공했다는 뜻일 뿐이다. 그것이 모델이 운영 환경에서 같은 종류의 작업을 안정적으로 끝낸다는 직접적인 설명은 되지 못한다.

더 믿을 수 있는 테스트 방식은 이것이다.

• 작업 종류마다 독립된 표본 한 묶음을 준비한다.
• 같은 시스템 프롬프트, 컨텍스트, 도구 정의, 지역 조건에서 실행한다.
• 각 표본을 여러 번 반복한다.
• 규칙, 숨긴 테스트, 또는 사람의 맹검 평가로 결과를 판단한다.
• 성공률과 신뢰구간을 보고한다.
• 가장 나쁜 사례와 실패 유형을 따로 적는다.

이 방법은 결국 모델 평가를 “어느 출력이 가장 좋았는가”에서 “이 시스템이 일을 계속 끝낼 수 있는가”로 바꾼다.

개인 사용자에게 Haiku 5.5는 무엇을 의미하는가

개인 사용자는 API 단가의 변화를 직접 느끼지 못할 수 있다. 그래도 Haiku 5.5의 위치는 세 각도에서 이해할 수 있다.

첫째, 빠르고 반복되며 경계가 분명한 작업에 더 알맞다. 예를 들어 텍스트 정리, 정보 추출, 구조화된 초안 작성, 많은 작은 문제의 처리다.

둘째, 모든 고급 모델을 대체하기에 알맞다고는 할 수 없다. 복잡한 글쓰기, 장기 계획, 어려운 코드, 상태를 이어서 유지해야 하는 작업은 여전히 Sonnet 또는 Opus에 더 의존한다.

셋째, 모델 사이의 차이는 단순한 높고 낮음의 차이보다 “일하는 방식의 차이”에 점점 더 가까워진다. 모델을 고를 때는 먼저 작업의 빈도, 지연 요구, 오류의 대가, 검증 수단을 보고, 그다음 모델의 단발 능력을 봐야 한다.

제품 팀에게 정말로 다시 계산해야 할 것은 단위 작업의 경제학이다

Haiku 5.5는 과거에는 자동화할 가치가 없던 많은 단계를 더 쉽게 시도하게 한다.

• 입력 분류를 한 층 더 둔다.
• 검색 결과 압축을 한 차례 더 한다.
• 문서를 전담하는 하위 에이전트를 하나 더 둔다.
• 비용이 낮은 출력 검사를 한 번 더 한다.
• 최종 답변 전에 구조화된 검증을 한 번 더 넣는다.

이 추가 단계 자체는 호출 횟수를 늘린다. 그러나 최종 실패율을 낮출 수 있다면, 제품 전체의 비용은 오히려 내려갈 수 있다.

이것이 “호출 한 번의 모델 가격”만으로는 부족한 이유다. 제품 팀이 정말로 비교해야 하는 것은 이것이다.

호출 한 번의 비용
→ 작업 한 번의 총비용
→ 성공한 작업 하나의 총비용
→ 인도할 수 있는 결과 하나의 총비용

Haiku 5.5가 충분히 쌀 때, 시스템은 여러 작은 작업으로 더 높은 최종 신뢰성을 얻을 수 있다. 이 변화는 Agent의 설계, 제품의 이익 구조, 그리고 팀이 어떤 일을 모델에게 자동으로 맡길지에 영향을 준다.

맺음말: Haiku 5.5는 아키텍처의 변화다

Haiku 5.5의 발표는 작은 모델의 한 차례 업그레이드로 이해할 수도 있고, Anthropic이 모델 제품의 형태를 한 걸음 밀어 올린 것으로 이해할 수도 있다.

세 질문을 같은 결정표 위에 올려 둔다.

• 이 작업에는 지능이 얼마나 필요한가.
• 이 작업은 지연을 얼마나 견딜 수 있는가.
• 이 작업은 돈을 얼마나 쓸 가치가 있는가.

모델 선택이 작업 라우팅, effort, 캐시, 재시도, 사람 인수와 함께 놓이면, “어느 모델이 가장 강한가”는 더 이상 유일한 질문이 아니다. 더 중요한 질문은 이렇게 바뀐다.

어느 모델이 어느 호출을 처리해야 하는가. 어떻게 가장 낮은 종단 간 비용으로 충분히 믿을 수 있는 결과를 얻는가?

Haiku 5.5의 의미는, 이 질문을 처음으로 충분히 싸게 만들어 대규모로 한 번 물어볼 가치가 있게 했다는 데 있을 수 있다.

참고 자료

• Anthropic: Introducing Claude Haiku 5.5
• Claude Platform Docs: Models overview