Haiku 5.5, 저가 모델의 경쟁은 이관 비용까지

Anthropic이 10월 7일 공개한 Claude Haiku 5.5는 요약·분류·문맥 압축처럼 짧고 빈번한 업무를 겨냥한다. 공식 발표는 이전 Haiku보다 평균 실행 비용이 약 75% 낮다고 설명한다. 다만 이 수치는 모든 고객의 청구액이 똑같이 줄어든다는 보장이 아니다. 입력 길이별 가격과 토큰 사용량 변화를 반영한 회사 측 계산이다.

이번 발표의 실무적 의미는 작은 모델을 무조건 기본값으로 만드는 데 있지 않다. 상위 모델이 담당하던 작업 중 범위가 좁고 결과를 쉽게 검증할 수 있는 단계를 분리할 여지가 커졌다는 점이다. 동시에 모델 이름만 바꾸는 이관은 오류를 낼 수 있어, 낮아진 단가와 호환성 변경을 함께 읽어야 한다.

10만 토큰 경계가 비용을 가른다

발표문에 따르면 Haiku 5.5는 프롬프트 10만 토큰 이하와 초과에 다른 단가를 적용한다. 아래는 발표 시점의 100만 토큰당 달러 가격이다. 실제 사용료에는 출력량, 캐시 사용, 계약 조건과 재시도가 영향을 준다.

표의 단가만 비교하면 짧은 프롬프트 구간은 90%, 긴 구간은 50% 저렴하다. 그러나 동일한 문서가 차지하는 토큰 수가 달라지므로 이를 작업당 절감률로 그대로 옮길 수 없다. 공식 이관 문서는 같은 텍스트가 이전 모델보다 대략 30% 많은 토큰이 될 수 있으며 내용에 따라 달라진다고 안내한다. 한국어 계약서와 표 중심 문서는 실제 표본으로 다시 세어야 한다.

Sonnet 5.5의 캐시 읽기 가격도 100만 토큰당 0.20달러에서 0.10달러로 내려간다. Anthropic은 대부분의 에이전트 작업에서 약 20% 비용 감소를 예상하지만, 캐시 적중률이 낮은 일회성 요청에 동일한 효과를 기대하면 안 된다. 앞서 다룬 Sonnet의 작업당 비용과 Opus의 캐시 경제성이 작은 모델 도입과 함께 다시 계산해야 할 축이다.

성능표보다 중요한 것은 맡길 업무의 경계다

Anthropic의 공개 평가에서 Haiku 5.5는 Terminal-Bench 4.0에서 39.2%, Sonnet 5.5는 70.6%를 기록했다. OSWorld 2.1 오프라인 부분집합에서는 각각 72.4%, 83.9%다. 이는 회사가 제시한 조건의 결과이며, 서로 다른 지표를 하나의 종합 생산성 순위처럼 읽어서는 안 된다. 평가 조건은 시스템 카드에서 확인할 수 있다.

작은 모델에 적합한 업무는 예를 들어 이미 찾아온 문서에서 특정 매출 행을 추출하거나, 고객 문의를 정해진 분류 체계에 배정하는 일이다. 반대로 저장소 전반의 설계를 변경하고 여러 도구의 실패를 복구해야 하는 작업은 더 큰 모델이 여전히 유리할 수 있다. 분류가 어려운 요청을 상위 모델로 넘기는 규칙이 있어야 저렴한 호출이 비싼 재작업으로 바뀌지 않는다.

Haiku 계열에 추론 강도를 조정하는 effort 설정이 처음 들어간 점도 중요하다. 분류와 요약에 같은 추론량을 배정할 필요가 없기 때문이다. 다만 최소 effort가 언제나 최저 총비용은 아니다. 오분류 한 건의 후처리 비용이 큰 업무라면 더 생각하게 하는 편이 경제적일 수 있다. GPT-6 계열의 작업 라우팅 분석과 마찬가지로 경쟁 단위는 토큰이 아니라 성공적으로 끝낸 업무다.

API 이관은 모델 ID 교체로 끝나지 않는다

공식 이관 문서는 추론 설정을 기존의 고정 budget 방식에서 adaptive 방식으로 옮기고, 응답의 첫 블록을 무조건 답변으로 해석하지 말라고 안내한다. 기본적으로 thinking 블록이 먼저 올 수 있기 때문이다. max_tokens가 너무 작으면 사고 과정 뒤에 실제 텍스트를 내보내기 전에 종료될 수 있다.

또한 sampling 매개변수와 assistant prefill, computer use 도구 형식에도 변경점이 있다. 따라서 운영 서비스에서는 기존 요청을 그대로 재생하는 호환성 검사와 출력 형식 검사를 먼저 해야 한다. 모델이 반환한 JSON을 파싱하는 코드, 분류 결과의 enum 처리, 거절 응답 분기를 별도로 살펴보는 것이 좋다. 브라우저 작업은 새로 소개된 browser use SDK 문서의 지원 범위도 확인해야 한다.

이것은 단순한 개발 편의 문제가 아니다. 토큰 예산을 잘못 옮겨 빈 응답이 증가하면 재시도 횟수가 늘고, 낮아진 가격표의 장점이 사라진다. 교체 전후의 입력 원문과 성공 기준을 고정해야 모델 개선과 프롬프트 변경의 효과를 구분할 수 있다.

한국 기업에는 좁은 작업부터 교체하는 접근이 맞다

국내 고객지원 팀이라면 한국어 문의의 존댓말, 상품명, 혼합 언어, 첨부 표를 포함한 평가 묶음을 준비할 수 있다. 처음에는 답변 발송까지 맡기지 않고 분류와 근거 추출에만 적용한다. 기존 모델과 병행 비교하면서 정확도, 상위 모델 이관률, 응답 완료 시간, 사람이 수정한 시간을 기록하는 방식이다.

개발 조직은 문맥 압축도 별도 평가해야 한다. 요약이 짧고 매끄러워도 사용자의 최신 요구나 수정 이력을 빠뜨리면 다음 단계의 에이전트가 잘못된 방향으로 일한다. 원문 대비 필수 정보 보존율과 재검색 횟수를 확인하고, 중요한 결정은 압축 결과만으로 삭제하지 않는 편이 낫다.

핵심 지표는 검수까지 통과한 작업 한 건의 비용이다. 모델 호출료에 재시도, 상위 모델 호출, 검수 시간을 더해 비교해야 한다. 이번 출시는 더 많은 반복 작업을 자동화할 가격 여지를 제공하지만, 어느 단계까지 맡길지는 각 조직의 데이터와 실패 비용이 결정한다.

FAQ

모든 요청이 90% 저렴해지는가?

아니다. 90%는 10만 토큰 이하 구간의 토큰 단가 비교다. 긴 프롬프트의 단가 차이, 새 토크나이저와 작업별 사용량 때문에 실제 절감률은 달라진다.

Haiku 5.5가 Sonnet을 완전히 대체하는가?

그렇게 볼 근거는 없다. 공개된 복잡한 코딩 평가에서는 Sonnet이 더 높은 결과를 냈다. 작은 작업을 나누고 어려운 경우를 이관하는 구성이 합리적이다.

한국어도 토큰이 정확히 30% 늘어나는가?

보장되지 않는다. 공식 문서는 대략적인 증가량을 안내하며 내용별 차이를 인정한다. 실제 한국어 요청 묶음으로 다시 측정해야 한다.

모델 ID만 바꾸면 되는가?

Messages API 통합에서는 추론 설정, 응답 블록 처리, 출력 제한과 도구 형식을 점검해야 한다. 사용 중인 플랫폼별 이관 문서를 먼저 확인하는 것이 좋다.

가장 먼저 도입할 만한 업무는 무엇인가?

분류, 제한된 필드 추출, 검증 가능한 요약처럼 입출력 범위가 명확한 업무다. 외부 발송과 데이터 변경은 품질을 확인한 뒤 별도 단계로 연결할 수 있다.