Claude Haiku 5.5 출시: 저비용 서브에이전트 설계에서 달라지는 기준

Anthropic이 Claude Haiku 5.5를 공개했다. 발표 문구는 “가장 저렴하고 빠른 small model”이지만, 개발자 관점에서 핵심은 가격표보다 워크플로우 설계다. Haiku 5.5는 고빈도 분류, 추출, 요약, compaction, database query, browser use, customer support 같은 반복 작업을 낮은 비용으로 처리하도록 설계됐다. 큰 모델 하나가 모든 일을 처리하는 구조에서, 작은 모델이 많은 서브태스크를 맡는 구조로 더 강하게 밀어주는 업데이트다.

공식 발표에 따르면 Haiku 5.5는 Haiku 4.5 대비 평균 실행 비용이 약 75% 낮다. 100,000 토큰 이하 프롬프트 기준 가격은 입력 100만 토큰당 0.10달러, 출력 100만 토큰당 0.50달러다. cache read는 0.01달러, cache write는 0.125달러다. 100,000 토큰을 넘는 요청은 더 비싸지만, Anthropic은 이전 Haiku 요청의 약 90%가 100,000 토큰 이하라고 설명했다.

무엇이 달라졌나

Haiku 5.5는 단순히 저렴한 모델이 아니다. adjustable effort setting이 들어간 첫 Haiku급 모델이라는 점이 중요하다. 같은 모델을 쓰더라도 비용을 더 아끼는 설정과 지능을 더 쓰는 설정을 선택할 수 있다. 이전에는 라우팅 기준이 “큰 모델 또는 작은 모델”이었다면, 이제는 “작은 모델 안에서도 effort 조절”이 가능해진다.

벤치마크에서도 역할이 분명하다. Anthropic 자료에서 Haiku 5.5는 OSWorld 2.1 offline subset 72.4%, Terminal-Bench 4.0 39.2%, FrontierCode 1.1 main 46.4%를 기록했다. Sonnet 5.5는 여전히 복잡한 코딩 작업에서 더 강하다. 하지만 Haiku 5.5는 빠른 customer support, browser use, narrow scoped subagent work에 유리하다고 설명된다. Asana는 내부 AI teammate 평가에서 작업 완료 latency가 30% 이상 줄고, agent turn당 inference가 최대 2.5배 빨라졌다고 밝혔다.

또 하나의 변화는 Sonnet 5.5 cache read 가격 인하다. cache read 가격이 100만 토큰당 0.20달러에서 0.10달러로 낮아져, agentic work 대부분에서 Sonnet 5.5 비용이 약 20% 줄어든다고 Anthropic은 설명했다. 즉 이번 발표는 Haiku 하나의 가격 인하가 아니라, Haiku와 Sonnet을 조합하는 에이전트 파이프라인 비용 구조를 바꾸는 업데이트다.

작은 모델을 어디에 써야 하나

작은 모델을 잘 쓰는 기준은 “쉬운 질문”이 아니다. 반복 가능하고, 평가 가능하며, 실패 비용이 제한된 작업이다. 예를 들어 고객 문의를 refund, shipping, account, bug, sales로 분류하는 일은 Haiku급 모델에 적합하다. 결과를 사람이 읽거나 다음 라우터가 검증할 수 있고, 틀렸을 때 복구가 가능하다.

반면 아키텍처 결정, 보안 패치 작성, 장기 디버깅, 대규모 리팩터링은 작은 모델로만 처리하기 어렵다. 이런 작업은 중간 추론이 길고, 실패 원인을 뒤늦게 발견하기 쉽다. Haiku 5.5가 Terminal-Bench에서 의미 있는 성능을 보여도 Sonnet 5.5와 같은 위치로 보면 안 된다. 실무에서는 Haiku를 “메인 개발자”가 아니라 “많은 보조 작업자”로 보는 편이 맞다.

좋은 사용처는 다섯 가지다. 첫째, 대화나 로그를 짧게 요약하는 compaction. 둘째, JSON 필드 추출과 schema normalization. 셋째, intent routing과 priority scoring. 넷째, 긴 문서에서 후보 근거를 찾는 pre-filter. 다섯째, browser use나 customer support처럼 지연 시간이 사용자 경험에 직접 영향을 주는 좁은 작업이다.

비용 계산 방식도 바꿔야 한다

모델 비용을 단순히 100만 토큰당 가격으로 비교하면 실수한다. 에이전트 비용은 보통 “한 요청에서 몇 번의 모델 호출이 발생하는가”로 결정된다. 큰 모델 한 번이 싸 보일 때도 있지만, 실제로는 tool call 전후로 분류, 요약, 재시도, 검증, 최종 답변이 반복된다. 이때 작은 모델을 적절히 넣으면 전체 비용이 크게 줄 수 있다.

예를 들어 고객지원 에이전트가 한 문의를 처리한다고 하자. 기존 구조는 Sonnet급 모델이 전체 대화를 읽고, intent를 판단하고, 정책 문서를 찾고, 답변까지 생성한다. Haiku 5.5를 넣으면 intent 분류, 개인정보 마스킹, 문서 후보 선별, 답변 초안 품질 점검을 작은 모델이 맡고, 최종 정책 판단과 민감 답변만 Sonnet이 처리할 수 있다. 이 구조에서는 Sonnet 호출 횟수와 입력 토큰을 줄일 수 있다.

cache 전략도 중요해진다. FAQ, 정책 문서, coding guideline처럼 반복적으로 들어가는 컨텍스트는 cache write/read를 써야 한다. Sonnet 5.5 cache read가 50% 내려간 만큼, 같은 긴 컨텍스트를 반복 사용해야 하는 에이전트는 cache hit rate를 비용 지표로 봐야 한다. “모델 가격이 내려갔다”보다 “캐시되는 토큰 비율이 몇 %인가”가 더 운영적인 질문이다.

라우팅과 검증이 없으면 비용 절감은 위험하다

작은 모델을 많이 쓰면 비용은 줄지만, 조용한 품질 저하가 생길 수 있다. 분류가 3%만 틀려도 이후 모든 단계가 틀린 문서와 도구를 선택할 수 있다. 그래서 Haiku 5.5 도입은 모델 교체가 아니라 라우팅과 검증 설계다.

첫 번째로 confidence threshold를 둬야 한다. 작은 모델이 분류 결과와 함께 확신도를 주고, 낮으면 큰 모델로 escalate한다. 둘째, 결과 형식을 엄격히 제한한다. JSON schema, enum, required fields를 쓰고, schema validation 실패 시 재시도 또는 fallback한다. 셋째, high-risk intent는 작은 모델 단독 결정을 금지한다. 환불 승인, 권한 변경, 데이터 삭제, 보안 예외 허용 같은 작업은 큰 모델 또는 사람 검토를 거쳐야 한다.

넷째, offline eval을 유지해야 한다. 작은 모델이 업데이트되면 routing distribution이 바뀔 수 있다. 기존 문의 1,000개를 대상으로 intent accuracy, escalation rate, latency, cost per ticket을 비교해야 한다. 단순 평균만 보면 안 된다. 긴 문의, 한국어 문의, 코드가 섞인 문의, 분노 표현이 있는 문의처럼 실패하기 쉬운 slice를 따로 봐야 한다.

마이그레이션 순서

가장 안전한 도입 순서는 shadow mode다. 현재 운영 모델은 그대로 두고, 같은 입력을 Haiku 5.5에도 보내 결과를 기록한다. 사용자에게는 노출하지 않는다. 1~2주 동안 기존 결과와 비교해 mismatch를 모은다. 그다음 저위험 작업부터 실제 라우팅에 넣는다. 예를 들어 태그 추천, 내부 요약, 후보 문서 검색처럼 사용자에게 직접 보이지 않는 작업이 좋다.

두 번째 단계에서는 자동 fallback을 붙인다. 작은 모델이 schema validation에 실패하거나, confidence가 낮거나, 금지 intent를 감지하면 Sonnet으로 넘긴다. 세 번째 단계에서는 비용과 품질 대시보드를 분리한다. latency p50/p95, tokens per task, cache hit rate, escalation rate, human correction rate를 같이 봐야 한다.

마지막으로 prompt를 작은 모델용으로 줄여야 한다. 큰 모델에 쓰던 긴 지시문을 그대로 넣으면 비용 이점이 줄고, 작은 모델이 중요한 제약을 놓칠 수 있다. Haiku용 프롬프트는 짧고, 출력 형식이 명확하고, 예외 조건이 적어야 한다. 복잡한 정책 판단은 애초에 큰 모델이나 rule engine으로 넘기는 편이 낫다.

실행 체크리스트

• 현재 에이전트 호출을 분해해 분류, 추출, 요약, 검색 후보 선별, 최종 답변 단계를 구분한다.
• 실패 비용이 낮고 평가 가능한 단계부터 Haiku 5.5 shadow test를 시작한다.
• 각 단계별로 accuracy, latency, cost per task, escalation rate를 측정한다.
• JSON schema와 enum validation을 붙여 작은 모델 출력 형식을 제한한다.
• confidence threshold 아래 결과는 Sonnet 5.5 또는 사람 검토로 넘긴다.
• 환불, 삭제, 권한 변경, 배포, 보안 예외 같은 high-risk 작업은 Haiku 단독 결정을 금지한다.
• 반복 컨텍스트는 prompt cache를 적용하고 cache hit rate를 대시보드에 올린다.
• 한국어, 긴 입력, 코드 포함 입력, 감정적 문의 같은 slice별 품질을 따로 본다.
• 큰 모델용 프롬프트를 그대로 쓰지 말고 작은 모델용으로 짧게 재작성한다.
• 배포 후 모델 버전, effort setting, fallback 사유를 로그에 남긴다.

Claude Haiku 5.5의 의미는 “싼 모델이 나왔다”가 아니라 “서브에이전트를 더 촘촘하게 설계할 수 있게 됐다”에 가깝다. 비용 절감은 결과다. 먼저 해야 할 일은 어떤 작업을 작은 모델에게 맡길지, 언제 큰 모델로 넘길지, 실패를 어떻게 감지할지 정하는 것이다.