Claude Haiku 5.5 가격 인하를 운영비 절감으로 연결하는 법

10만 토큰의 요청 전체 과금 경계, 새 토크나이저와 adaptive thinking 설정을 확인하고 문의 분류·요약·추출부터 옮기는 운영 전환 안내입니다.

개정 1판 · 최근 고침: 공식 가격·전환·effort 문서와 고객 증언을 대조하고 요청 계약·업무당 비용·단계적 복구 가이드를 추가했습니다. · 고침 기록 보기

공식 API 요금과 Anthropic 게재 고객 증언을 구분합니다. 비용 계산·업무 전환은 가상의 산술·설계이며 코드는 구문 검사만 했고 모델 API 호출이나 실측을 하지 않았습니다.

반복 업무에서 절감액을 확인하기

입력 100만 토큰당 0.10달러라는 가격은 매력적이다. 다만 10만 토큰의 과금 경계, 달라진 토크나이저, 추론 설정까지 함께 바꿔야 기대한 절감액에 가까워진다. 고객 문의 분류부터 문서 추출까지, 작은 작업부터 옮기는 실무 순서를 정리했다.

AI 서비스의 비용은 사용자가 보는 마지막 답변에서만 생기지 않는다. 문의를 분류하고 관련 문서를 고르고 긴 대화를 요약하고 다음 작업을 어느 도구로 보낼지 결정하는 과정에도 모델 호출이 들어간다. 각각은 짧은 일이지만 하루 수만 번 반복되면 운영비에서 무시하기 어려운 비중을 차지한다. 이런 작업을 더 저렴하게 처리할 수 있다면 제품의 기능을 줄이지 않고도 비용 구조를 바꿀 여지가 생긴다.

Anthropic이 2026년 10월 7일 발표한 Claude Haiku 5.5는 이런 대량·반복 작업을 겨냥한다. 회사가 제시한 주요 용도도 요약, 분류, 검색 보조, 더 큰 모델을 돕는 하위 에이전트다. 공식 발표

도입을 검토하는 팀이라면 첫 질문을 조금 구체화하는 편이 좋다. 전체 챗봇을 한 번에 바꿀 수 있는지보다, 현재 비용을 많이 쓰면서 정답을 확인하기 쉬운 작업이 무엇인지부터 찾아보자. 배송 문의를 담당 부서로 보내는 일과 복잡한 환불 분쟁을 판단하는 일은 같은 고객 지원 안에서도 위험과 난도가 다르다. Haiku 5.5의 경제성은 이런 차이를 모델 선택에 반영할 때 확인하기 쉽다.

이 절의 근거 S87

가격표에서 먼저 읽어야 할 두 줄

Claude Platform의 기본 토큰 가격은 다음과 같다. MTok은 100만 토큰이며 금액은 미국 달러다.

Haiku 5.5의 두 가격 구간은 Haiku 제품 페이지, 이전 모델과의 비교는 공식 가격 문서에서 확인할 수 있다. 이 표는 API 토큰 단가다. 구독형 채팅 상품의 월 요금이나 서비스 전체 운영비를 뜻하지 않는다.

특히 10만 토큰을 넘으면 해당 요청에 높은 단가가 적용된다. 초과한 부분만 비싸지는 누진 방식이 아니다. 경계 판정에는 캐시 읽기와 쓰기를 포함한 전체 입력 토큰이 들어간다. 캐시가 많은 긴 대화도 이 조건을 피하지 못한다. 긴 컨텍스트 과금 기준

예를 들어 캐시가 없는 요청의 입력이 9만 9,000토큰, 출력이 1,000토큰이면 기본 토큰 비용은 0.0104달러다. 입력이 10만 1,000토큰으로 늘고 출력이 같다면 0.053달러가 된다. 단순 산술 예시이며 도구 비용이나 별도 가산금은 제외했다. 입력이 약 2% 늘었는데 계산된 비용은 약 5.1배가 되는 셈이다.

따라서 모니터링 화면에는 월 총액만 두지 말고 요청 길이 분포도 함께 두자. 평균 입력 길이가 짧아도 특정 고객의 긴 대화나 대형 첨부 문서가 경계를 반복해서 넘을 수 있다. 비용이 큰 요청 몇 건을 찾아 원문 전체가 필요한지, 관련 구간만 전달해도 되는지 점검하는 방식이 실용적이다. 다만 가격 문턱을 맞추려고 문서를 무조건 자르면 답에 필요한 근거까지 사라질 수 있으므로 품질 확인을 함께 해야 한다.

이 절의 근거 S210 · S88

같은 문서를 보내도 토큰 수는 달라진다

이전 모델에서 기록한 토큰 수를 새 가격표에 곧바로 곱하면 오차가 생긴다. 마이그레이션 문서에 따르면 Haiku 5.5는 같은 입력 텍스트를 Haiku 4.5보다 약 30% 많은 토큰으로 계산한다. 실제 증가폭은 내용에 따라 다르다. 예전 출력 한도도 다시 살펴야 한다. 같은 토큰 한도에 담기는 글의 분량이 줄어 답변이 잘릴 수 있기 때문이다. Haiku 5.5 마이그레이션 가이드

단순히 30% 증가한다고 가정하면 과거 8만 토큰이던 자료는 10만 4,000토큰이 된다. 이 경우에는 단가 하락뿐 아니라 과금 구간 변화도 함께 계산해야 한다. 모든 한국어 문서가 정확히 이 비율로 늘어난다는 의미는 아니다. 한글 본문, 영문 코드, 표가 섞인 문서를 각각 재측정할 이유를 보여주는 가상 예시다.

입력 길이를 확인할 때는 실제 호출과 같은 모델 ID, 시스템 지침, 메시지, 도구 정의를 사용하자. Claude의 토큰 계산 API는 생성 요청 전에 입력 크기를 추정하는 데 쓸 수 있다. 결과는 예상치이므로 최종 비용 집계에는 실제 응답의 사용량도 남겨야 한다. 토큰 계산 문서

실무에서는 모델별 토큰 수와 원문 길이를 함께 기록하면 전환 원인을 이해하기 쉽다. 원문은 그대로인데 토큰만 늘었는지, 새 프롬프트에 예시가 추가됐는지, 검색 도구가 불필요하게 많은 문서를 가져왔는지를 구분할 수 있다. 비용 대시보드의 숫자가 바뀌었다고 곧바로 모델이 더 장황해졌다고 결론 내리지 않아도 된다.

이 절의 근거 S90 · S211

모델 이름과 함께 바꿔야 할 설정

기존 Messages API 연동을 옮길 때 가장 먼저 찾을 항목은 추론 설정이다. 예전의 thinking: {"type": "enabled", "budget_tokens": N}을 그대로 보내면 400 오류가 발생한다. thinking을 adaptive로 바꾸고 추론 강도는 output_config.effort로 조절한다. Claude API 모델 ID는 claude-haiku-5-5다.

기존 요청의 temperature, top_p, top_k도 제거하는 것이 공식 전환 지침이다. 마지막 assistant 메시지를 미리 채워 이어 쓰게 하는 prefill 방식 역시 교체해야 한다. 응답을 읽는 코드는 첫 번째 블록이 답변이라고 가정하지 말고 블록의 type을 확인해야 한다. 요청 형식 변경 사항

이런 항목은 애플리케이션 코드 한 곳에만 있지 않을 수 있다. 공통 API 래퍼, 평가용 스크립트, 백그라운드 작업, 장애 시 호출하는 예비 경로까지 검색해 보자. 대화 화면은 정상인데 야간 분류 작업만 실패하는 상황을 피하려면 실제 운영에서 사용되는 요청 경로를 목록으로 만드는 편이 낫다.

또한 모델을 되돌리는 기능과 설정을 되돌리는 기능을 묶어야 한다. 새 모델용 요청을 예전 모델 ID에 보내거나 그 반대가 되면, 되돌리기 자체가 또 다른 장애 원인이 된다. 모델 이름, 요청 옵션, 응답 해석기를 하나의 버전으로 취급하고 선택하게 만드는 구성을 권한다.

이 절의 근거 S90

짧은 호출에서 출발하는 예제

아래는 Claude Python SDK로 입력 토큰을 확인한 뒤 짧은 문의 요약을 요청하는 예시다. SDK와 인증이 준비됐다는 전제이며 설명을 위해 작성한 코드로 실행 결과를 제시하는 것은 아니다.

import anthropic

client = anthropic.Anthropic()
request = {
    "model": "claude-haiku-5-5",
    "system": "문의의 요청 사항과 확인할 정보를 두 문장으로 요약하세요.",
    "messages": [{
        "role": "user",
        "content": "어제 주문했는데 주소를 잘못 적었어요. 아직 발송 전입니다."
    }],
}

count = client.messages.count_tokens(**request)
print("estimated_input_tokens:", count.input_tokens)

response = client.messages.create(
    **request,
    max_tokens=2048,
    thinking={"type": "adaptive"},
    output_config={"effort": "low"},
)

if response.stop_reason != "end_turn":
    raise RuntimeError(f"검토가 필요한 종료 상태: {response.stop_reason}")

answer = "\n".join(b.text for b in response.content if b.type == "text")
print(answer)
print(response.usage)

종료 상태와 요약 단계의 범위를 확인한다

입력 계산 부분은 토큰 계산 API, 추론 강도와 텍스트 블록 선택 방식은 effort 문서를 바탕으로 구성했다. 2048은 이 예시의 출력 한도일 뿐 모든 업무에 권장되는 값은 아니다. 운영 코드에는 통신 오류 처리, 제한된 재시도, 로그의 개인정보 제거, 업무별 결과 검증이 추가로 필요하다.

이 코드는 주소를 변경하지 않는다. 문의를 요약하는 단계만 보여준다. 실제 주문을 수정하려면 주문자 확인, 수정 가능 여부 조회, 변경 대상 확인을 별도 절차로 둬야 한다. 도입 초기에는 이렇게 읽기와 제안을 담당하는 작업부터 옮기면 문제가 생겼을 때 영향을 제한하기 쉽다.

이 절의 근거 S211 · S212

effort를 낮출 때 함께 봐야 하는 것

Haiku 5.5의 기본 effort는 medium이며 low, high, xhigh, max도 제공된다. Anthropic은 짧은 도구 작업과 단순 대량 요청에 low를, 엄격한 지시 준수나 긴 작업에는 high를 검토하도록 안내한다. effort는 고정 토큰 예산이 아니다. 낮은 설정에서도 어려운 요청에는 추론이 발생할 수 있다. 추론 토큰도 max_tokens에 포함되므로 최종 답변이 짧다는 이유만으로 출력 한도를 지나치게 낮추지 않아야 한다. 모델별 effort 권장 설정

분류 정확도가 같더라도 출력이 짧아졌다는 이유만으로 좋은 설정이라고 판단하기는 어렵다. 상담 요약이라면 고객의 핵심 요구가 빠지지 않았는지, 문서 추출이라면 단위와 기간이 함께 남았는지 봐야 한다. 특정 필드 누락이 다음 시스템의 재질문을 늘리면 첫 호출에서 아낀 비용이 뒤에서 다시 발생한다.

간단한 비교 방법은 동일한 평가 묶음을 low와 medium에 각각 보내는 것이다. 답변을 사람이 읽어 좋은 쪽을 고르는 데서 끝내지 말고 누락·잘못된 분류·추가 확인 필요 여부를 같은 기준으로 표시한다. 설정별 차이가 특정 업무에 집중된다면 전체 서비스의 강도를 올리는 대신 그 업무만 다른 경로로 보낼 수 있다.

프롬프트에 “바로 답하라”는 문구를 넣는 것만으로 추론 비용이 줄어든다고 기대해서도 안 된다. 공식 안내는 Haiku 5.5에서 이런 지시가 추론을 안정적으로 줄이지 못하므로 effort 조절을 우선하도록 설명한다. 추론과 비용 제어

이 절의 근거 S212 · S213

고객 사례에서 가져올 것은 작업의 크기다

출시 발표에 실린 고객 증언은 활용 지점을 보여준다. Asana는 AI Teammates 평가에서 작업 완료 지연이 30% 넘게 줄었다고 밝혔다. HubSpot은 모의 CRM 환경의 평가에서 세 번 실행한 평균 점수가 92.8%였다고 설명했다. Rogo는 큰 모델이 발표 자료를 만드는 동안 Haiku 하위 에이전트가 10-K에서 필요한 부문 매출 항목을 가져오는 사용 예를 제시했다. 모두 Anthropic이 발표문에 게재한 고객 설명이며 이 기사가 별도로 재현한 성능 결과는 아니다. 고객 사례 원문

이 사례를 자사 업무로 옮길 때는 비교 수치보다 요청의 경계를 살펴보자. “이번 분기 사업을 분석하라”는 넓은 요청보다 “지정 문서에서 특정 사업부 매출과 해당 기간을 찾아라”는 요청은 완료 조건을 세우기 쉽다. 답이 문서의 어느 부분에서 나왔는지 검사할 수도 있다.

예를 들어 매주 판매 현황 보고서를 만든다고 하자. 자료 수집, 숫자 확인, 주요 변화 해석, 문장 작성까지 모두 한 모델에 맡길 필요는 없다. Haiku에는 각 파일에서 정해진 항목을 읽고 출처 위치를 반환하게 하고 계산은 코드로 수행하며 여러 지표를 종합하는 판단은 별도 단계에서 처리하는 구성이 가능하다. 이는 위 사례에서 착안한 설계 예시이지, 특정 회사가 이 구조로 운영한다는 뜻은 아니다.

하위 작업을 나눌 때에는 전달 형식도 정해야 한다. 값만 돌려받으면 단위나 기준일이 사라질 수 있다. 값, 통화, 기간, 문서 식별자, 근거 위치, 찾지 못한 이유처럼 후속 검증에 필요한 항목을 먼저 정하면 모델을 교체해도 전체 흐름을 유지하기 쉽다.

이 절의 근거 S87

일주일짜리 전환 실험을 설계한다면

고객 문의 분류 기능을 옮긴다고 가정해 보자. 작은 팀에서도 같은 입력에 대한 품질과 비용을 함께 비교할 수 있도록 범위를 좁혀 시작한다.

첫 단계에서는 현재 문의에서 대표 묶음을 만든다. 자주 들어오는 배송·교환 질문만 모으지 말고 여러 요구가 섞인 문의, 오타가 많은 문장, 정책에 없는 예외, 정보가 부족한 요청도 넣는다. 먼저 사람이 기대하는 분류와 넘겨야 할 담당 부서를 표시한다. 애매한 항목은 억지로 하나의 정답을 만들기보다 “사람 확인”이 맞는 경우로 남겨두는 편이 좋다.

두 번째 단계에서는 기존 모델과 새 모델을 같은 자료에 적용한다. 새 모델의 평가 결과를 보고 곧바로 정답표를 수정하면 비교 기준이 흔들린다. 평가 자료 일부는 프롬프트 개선에 쓰고 나머지는 최종 확인용으로 남겨두자. 운영 담당자에게는 모델 이름을 가린 결과를 보여주면 익숙한 이름에 끌리는 판단을 줄일 수 있다.

측정 항목은 다섯 가지 정도면 출발할 수 있다. 정확한 담당 부서로 보낸 비율, 반드시 사람이 볼 문의를 놓친 수, 결과 형식 오류, 완료 시간의 상위 5% 경계인 p95, 성공적으로 끝난 문의 한 건당 비용이다. 평균 응답 속도가 좋아도 느린 요청이 고객 대기열을 막을 수 있으므로 p95를 함께 본다. 실제 업무와 예외 상황에 맞는 평가, 품질·지연·가격의 동시 측정이라는 원칙은 Anthropic 평가 설계 문서와도 맞닿아 있다.

세 번째 단계는 사용자에게 결과를 노출하지 않는 병행 실행이다. 기존 시스템이 실제 분류를 담당하는 동안, 새 모델은 같은 입력에 대한 후보 결과만 만든다. 두 결과가 다른 문의를 우선 검토하면 무작위로 모든 답을 읽는 것보다 차이를 발견하기 쉽다. 개인정보가 포함된 로그는 필요한 항목만 남기고 접근 범위를 제한해야 한다.

마지막 단계에서는 검증을 통과한 문의 종류만 새 경로로 보낸다. 변경을 되돌릴 담당자, 중단 기준, 기존 경로로 복구하는 방법을 배포 전에 적어둔다. 가령 오분류가 늘어도 전체 성공률이 유지되면 넘어갈 것인지, 특정 고위험 문의를 한 번 놓쳐도 즉시 중단할 것인지 미리 합의해야 한다. 기준은 모델의 평균 점수보다 서비스가 감당할 수 있는 오류에서 출발하는 편이 낫다.

여기서 비용의 분모를 분명히 하자. API 호출 한 번이 저렴해도 결과가 틀려 세 번 다시 호출하거나 사람이 수정하면 업무 완료 비용은 올라간다. 첫 요청, 재시도, 다른 모델로 전환하는 과정, 검토 시간을 함께 모아야 도입 후 무엇이 좋아졌는지 설명할 수 있다. 사람의 검토 시간을 금액으로 환산하기 어렵다면 최소한 건수와 소요 시간이라도 별도로 기록해 두자.

이 절의 근거 S214

구조화 출력과 캐시도 다시 확인한다

분류나 추출 결과를 다른 시스템에 넘긴다면 문장보다 정해진 JSON 구조가 편리하다. Claude의 structured outputs는 output_config.format으로 출력 형식을 지정한다. 다만 형식에 맞는 결과가 업무적으로도 맞는 결과라는 보장은 없다. 거절이나 출력 한도 도달 시에는 스키마와 다른 결과가 나올 수도 있으므로 종료 상태를 먼저 확인해야 한다. Haiku 5.5의 Amazon Bedrock 연동에서는 구조화 출력 지원 여부에 특히 주의해야 한다. 현재 문서상 해당 모델에서 지원되지 않는다. 구조화 출력과 플랫폼 호환성

예를 들어 주문 번호가 문자열이라는 검사는 통과했어도 실제 주문이 존재하는지는 별도 조회로 확인해야 한다. 모델이 반환한 담당 부서 이름도 허용된 목록과 대조해야 한다. 모델을 저렴하게 바꾸는 작업과 결과 검증을 강화하는 작업을 함께 진행하면 이후 다른 모델을 추가할 때도 이 검증 장치를 재사용할 수 있다.

고정 지침과 반복 문서가 많다면 프롬프트 캐시도 검토하자. Haiku 5.5의 짧은 프롬프트 구간에서 캐시 읽기는 100만 토큰당 0.01달러, 5분 캐시 쓰기는 0.125달러다. 긴 프롬프트 구간에서는 각각 0.05달러와 0.625달러다. 정적인 내용을 앞에, 요청마다 바뀌는 내용을 뒤에 배치하고 재사용되는 구간을 지정하는 것이 출발점이다. 프롬프트 캐싱 안내

캐시를 켰다는 설정값만 보지 말고 실제 읽기 사용량이 발생했는지 확인하자. 공통 지침 앞에 매번 달라지는 시간이나 사용자 정보를 붙이면 재사용하려던 구간이 달라질 수 있다. 고객별 자료를 처리한다면 정확히 같은 내용만 재사용되는지와 별개로, 애플리케이션이 다른 고객의 문서를 잘못 조립해 보내지 않는지도 검사해야 한다.

실시간 응답이 필요 없는 분류 작업이라면 Message Batches도 후보가 된다. 공식 문서는 배치 요청의 입력·출력 토큰을 표준 요율보다 50% 낮게 과금한다고 설명한다. 배치 처리 문서 전날 들어온 문의의 통계 집계처럼 기다릴 수 있는 작업에 먼저 검토하고 고객이 화면 앞에서 기다리는 요청과 처리 경로를 분리하는 것이 자연스럽다.

이 절의 근거 S215 · S216 · S217

어떤 작업부터 옮길 것인가

첫 후보는 입력 범위가 작고 결과를 쉽게 검사할 수 있는 반복 작업이다. 정해진 분류표에 맞춘 문의 분류, 짧은 대화 요약, 문서에서 지정 항목 추출, 다음 도구 선택처럼 완료 조건이 분명한 기능이 여기에 해당한다. 결과가 곧바로 외부 행동으로 이어지지 않는다면 실험의 부담도 줄어든다.

반대로 여러 자료의 모순을 판단하거나, 긴 작업 중 계획을 계속 수정하거나, 오류 한 번의 손실이 큰 업무는 비용만 보고 전환 범위를 넓히기 어렵다. 이런 업무에서도 자료 추출 같은 하위 단계는 따로 실험할 수 있다. 어느 단계에서 누가 검증하고 최종 판단을 내리는지 정해두는 일이 중요하다.

Haiku 5.5를 도입한 뒤 확인할 최종 숫자는 토큰 단가 자체보다 정해진 품질을 만족한 업무 한 건의 비용이다. 새 모델로 토큰을 다시 세고 과금 경계를 확인하고 요청 설정을 정리한 다음, 실제 업무 자료로 비교하자. 가격 인하의 폭이 큰 지금은 익숙한 호출을 그대로 옮기기보다 반복 작업의 경계를 한 번 정리해 볼 만하다. 그 정리가 되어 있으면 이번 전환 결과도 더 명확하게 판단할 수 있다.