Claude Haiku 5.5 출시: 75% 저렴한 소형 모델이 바꾸는 에이전트 비용 구조

Anthropic이 2026년 10월 7일 Claude Haiku 5.5를 공개했다. 핵심은 단순히 “작고 빠른 모델”이 하나 더 나왔다는 얘기가 아니다. 공식 발표 기준으로 Haiku 5.5는 이전 Haiku 4.5 대비 평균 실행 비용이 약 75% 낮아졌고, 프롬프트 100,000토큰 이하 구간에서 입력 토큰은 100만 토큰당 0.10달러, 출력 토큰은 0.50달러로 책정됐다. 캐시 읽기는 100만 토큰당 0.01달러까지 내려간다.

실무 개발자에게 중요한 변화는 모델 선택 기준이 “가장 똑똑한 모델 하나를 모든 작업에 붙인다”에서 “작업 단위별로 모델을 쪼개 배치한다”로 더 빨리 이동한다는 점이다. 요약, 분류, 컴팩션, 데이터베이스 질의 보조, 반복적인 브라우저 조작, 서브에이전트 조사처럼 단위 작업이 명확한 영역은 대형 모델보다 소형 모델의 가격·지연시간이 더 큰 차이를 만든다.

무엇이 새로 나왔나

Haiku 5.5는 Anthropic의 Haiku 계열 중 가장 빠르고 저렴하며, 기존 Haiku보다 강한 소형 모델로 소개됐다. 공식 자료는 고빈도·비용 민감 작업을 주요 사용처로 든다. 예시는 요약, 컴팩션, 데이터베이스 쿼리, 분류 요청, 라이브 고객지원, 브라우저 사용, 코딩 작업의 서브에이전트다.

수치상으로 가장 먼저 봐야 할 부분은 가격표다. 프롬프트가 100,000토큰 이하일 때 Haiku 5.5의 입력 토큰 가격은 100만 토큰당 0.10달러, 출력 토큰은 0.50달러다. 같은 표에서 Haiku 4.5는 입력 1.00달러, 출력 5.00달러로 제시됐다. 장문 프롬프트를 자주 다루는 워크플로우가 아니라면, 단순 토큰 단가만 놓고도 이전 세대 대비 큰 폭의 절감이 가능하다.

캐시 가격도 중요하다. Haiku 5.5의 캐시 읽기는 100,000토큰 이하 구간에서 100만 토큰당 0.01달러다. 반복 작업에서 안정적인 시스템 프롬프트, 도메인 규칙, 스키마, 예시를 앞쪽에 두고 캐시를 잘 맞추면 입력 비용을 더 낮출 수 있다. 반대로 매 요청마다 프롬프트 구조가 바뀌면 캐시 이점은 사라진다.

개발팀이 봐야 할 가격 신호

많은 팀이 AI 비용을 “모델 단가 × 토큰 수”로만 계산한다. 실제 운영비는 여기에 실패 재시도, 긴 대기시간으로 인한 사용자 이탈, 사람이 결과를 검수하는 시간, 잘못된 자동화가 만든 복구 비용까지 붙는다. Haiku 5.5의 의미는 저렴한 단가 자체보다 “대형 모델이 맡을 필요 없는 작업을 분리할 수 있는 가격대”가 더 현실적으로 내려왔다는 데 있다.

예를 들어 고객 문의 10,000건을 매일 분류한다고 하자. 각 요청이 짧고 라벨 체계가 고정돼 있다면 Sonnet이나 Opus급 모델을 붙일 이유가 약하다. Haiku 5.5로 1차 분류를 하고, 낮은 신뢰도 또는 정책 위험이 있는 케이스만 상위 모델로 넘기는 라우팅 구조가 더 낫다. 이때 비용 절감은 단가 차이뿐 아니라 상위 모델 호출 횟수를 줄이는 데서 나온다.

Anthropic은 Sonnet 5.5 캐시 읽기 가격도 50% 낮췄다고 밝혔다. 공식 설명은 이 변경으로 대부분의 에이전트 작업에서 Sonnet 5.5 비용이 약 20% 줄어든다고 본다. 즉 이번 발표는 Haiku만의 가격 인하가 아니라, 소형 모델과 중대형 모델을 함께 쓰는 에이전트 비용 구조를 정리하는 신호에 가깝다.

어디에 바로 쓸 수 있나

첫 번째 후보는 컴팩션이다. 긴 대화나 장시간 에이전트 작업에서 중간 상태를 요약해 다음 턴으로 넘기는 작업은 자주 반복된다. 모든 컴팩션을 최고 성능 모델로 처리하면 비용이 빠르게 쌓인다. Haiku 5.5는 “결정 사항, 남은 작업, 검증 결과, 열린 질문”처럼 형식이 정해진 상태 요약에 잘 맞는다.

두 번째 후보는 분류와 라우팅이다. 고객 문의, 이슈 티켓, 로그 메시지, PR 코멘트, 문서 요청을 카테고리로 나누고 우선순위를 붙이는 작업은 소형 모델이 맡기 좋다. 중요한 조건은 라벨 정의와 예외 규칙을 명확히 쓰는 것이다. “버그인지 아닌지 판단”보다 “재현 가능한 장애, 계정·결제, 기능 요청, 보안 의심, 기타”처럼 운영 액션과 연결된 라벨이 낫다.

세 번째 후보는 브라우저·컴퓨터 사용의 보조 단계다. Anthropic은 Haiku 5.5가 속도와 가격 때문에 브라우저 사용 작업에 적합하다고 설명한다. 다만 결제, 계정 삭제, 고객 데이터 변경처럼 외부 영향이 있는 클릭은 소형 모델에 자동 위임하면 안 된다. 읽기, 캡처, 폼 초안 작성, 상태 확인까지만 자동화하고, 쓰기 액션은 승인 단계를 둬야 한다.

벤치마크보다 운영 평가가 먼저다

공식 발표에는 OSWorld, Terminal-Bench, FrontierCode, Humanity’s Last Exam 같은 벤치마크가 나온다. Haiku 5.5는 Haiku 4.5보다 크게 좋아졌지만, 복잡한 에이전트 코딩에서는 Sonnet 5.5와 Opus 5.5가 여전히 더 적합하다고 Anthropic도 선을 긋는다. 이 문장을 놓치면 안 된다.

소형 모델을 잘 쓰는 팀은 “어떤 모델이 더 똑똑한가”보다 “이 작업의 실패 비용이 얼마인가”를 먼저 본다. 분류가 조금 틀리면 사람이 다시 고칠 수 있는가. 잘못된 SQL 질의 제안이 실제 DB에 실행되는가. 브라우저 액션이 고객 계정에 영향을 주는가. 실패 비용이 낮고 검증 가능한 작업일수록 Haiku 5.5 같은 모델을 붙이기 쉽다.

운영 평가는 최소 100~300개의 실제 샘플로 시작하는 편이 안전하다. 성공률, 평균 지연시간, 95퍼센타일 지연시간, 토큰 비용, 재시도율, 사람이 수정한 비율을 같이 봐야 한다. 평균 정확도만 보면 위험 케이스가 묻힌다. 특히 보안, 결제, 의료, 법무처럼 오류 비용이 큰 도메인은 낮은 신뢰도 응답을 자동 차단하는 기준이 필요하다.

마이그레이션할 때 조심할 점

기존 Haiku 4.5나 Sonnet 기반 워크플로우를 Haiku 5.5로 바꿀 때는 프롬프트를 그대로 복사하지 말고 작업을 다시 쪼개야 한다. 상위 모델에게 주던 느슨한 지시문을 소형 모델에 넘기면 결과 품질이 흔들릴 수 있다. 소형 모델에는 입력 형식, 출력 JSON 스키마, 금지 액션, 불확실할 때의 반환값을 더 명확히 줘야 한다.

예를 들어 “이 티켓을 분석해 줘”보다 “아래 티켓을 billing, bug, security, feature, other 중 하나로 분류하고, confidence를 0~1로 반환하라. security 가능성이 있으면 confidence와 무관하게 escalate=true로 반환하라”가 낫다. 결과를 사람이 읽는 문장으로 받기보다 기계가 검증할 수 있는 구조로 받는 것도 중요하다.

또 하나는 캐시 설계다. 캐시 이점을 얻으려면 시스템 지시, 라벨 정의, 출력 예시처럼 안정적인 내용을 프롬프트 앞에 배치하고 자주 바꾸지 않아야 한다. 매 요청마다 타임스탬프나 사용자별 동적 데이터를 앞쪽에 끼워 넣으면 캐시가 깨진다. 비용 절감 목적이라면 프롬프트 순서까지 운영 변수로 관리해야 한다.

실행 체크리스트

• Haiku 5.5 후보 작업을 3개로 제한한다. 추천 후보는 분류, 요약, 컴팩션이다.
• 각 작업에 대해 실패 비용을 낮음·중간·높음으로 표시한다. 높음이면 자동 실행하지 않는다.
• 출력은 가능한 한 JSON 스키마로 고정한다. 사람이 읽는 긴 문장은 후처리가 어렵다.
• 100개 이상의 실제 샘플로 기존 모델과 Haiku 5.5를 비교한다.
• 성공률만 보지 말고 지연시간, 재시도율, 사람 수정률, 95퍼센타일 비용을 같이 측정한다.
• 캐시를 쓰는 워크플로우는 안정 프롬프트와 동적 입력의 위치를 분리한다.
• confidence가 낮거나 정책 위험이 있는 요청은 Sonnet급 모델 또는 사람 검토로 라우팅한다.
• 브라우저 사용은 읽기·초안·상태 확인부터 시작하고 외부 쓰기 액션에는 승인 단계를 둔다.