입력에 2,000토큰을 더 넣었을 뿐인데, 요청 비용이 약 다섯 배가 된다.
Claude Haiku 5.5의 가격표에서는 가능한 일이다. 오류나 숨겨진 과금이 아니라, 요청의 입력 길이에 따라 단가가 바뀌는 구조 때문이다.
Anthropic은 10월 7일 Haiku 5.5를 공개했다. 회사가 내세우는 방향은 대량 처리와 비용에 민감한 작업이다. 최고급 모델을 모든 곳에 쓰기 부담스러운 개발자라면 눈길이 갈 만한 발표다. Haiku 5.5 공식 발표
그런데 이 모델을 고를 때는 시작 가격과 함께 ‘어디까지 그 가격인가’를 읽어야 한다. 이번 글에서는 벤치마크 순위 대신 요청 두 개의 영수증을 펼쳐보자.
가격은 2026년 10월 10일 확인한 Claude API 기준이다. 아래 비용은 명시한 토큰 수로 계산한 예시이며 실제 서비스 측정값이 아니다. Claude 앱의 구독료나 사용 한도를 계산하는 글도 아니다.
거의 같은 요청, 다른 영수증
공식 가격표에서 Haiku 5.5의 기본 단가는 다음과 같다. 금액은 100만 토큰당 미국 달러이며, 구간을 나누는 기준은 출력 길이가 아니라 해당 요청의 프롬프트 길이다.
| 요청의 프롬프트 길이 | 입력 단가 | 출력 단가 |
|---|---|---|
| 100,000토큰 이하 | $0.10 | $0.50 |
| 100,000토큰 초과 | $0.50 | $2.50 |
경계를 넘으면 그 요청에 높은 단가가 적용된다. 초과한 부분에만 추가 단가를 붙이는 누진 방식이 아니다. 이전 요청의 요금을 소급해 바꾸지는 않는다. 공식 가격 및 긴 컨텍스트 과금 기준
이제 두 요청을 가정해 보자. 캐시와 배치 할인 없이, 각각 청구 대상 출력이 1,000토큰 발생한다. 별도 도구 요금과 세금도 제외한다.
| 가상 요청 | 입력 비용 | 출력 비용 | 합계 |
|---|---|---|---|
| 입력 99,000토큰 + 출력 1,000토큰 | $0.0099 | $0.0005 | $0.0104 |
| 입력 101,000토큰 + 출력 1,000토큰 | $0.0505 | $0.0025 | $0.0530 |
입력량은 약 2% 늘었지만 합계는 약 5.1배다. 같은 조건을 각각 10만 번 반복한다면 $1,040과 $5,300이 된다. 이는 사용량 예측이 아니라, 가격 경계가 반복 호출에서 어떻게 확대되는지 보여주는 산술 예시다.
그렇다고 Haiku 5.5가 비싸다는 결론은 성급하다. 두 번째 요청의 절대 비용도 작다. 다만 “백만 토큰에 10센트”라는 숫자 하나로 월간 예산을 잡으면, 실제 요청 분포를 놓칠 수 있다.
서비스의 평균 입력 길이만 보는 것도 부족하다. 대부분의 요청이 짧고 일부가 매우 길다면, 평균은 멀쩡해 보여도 경계를 넘는 요청이 비용에서 차지하는 비중은 다를 수 있다.
에이전트는 대화를 오래 할수록 짐이 늘어난다
분류 작업과 코딩 에이전트는 같은 모델을 사용해도 입력을 쌓는 방식이 다르다.
문의 하나를 읽고 담당 부서를 고르는 작업은 요청을 작게 유지하기 쉽다. 반면 저장소를 읽고, 로그를 확인하고, 수정하고, 다시 테스트하는 작업은 이전 결과를 다음 요청에 붙이면서 입력이 커질 수 있다. 이 설명은 특정 제품의 실제 로그가 아니라, 누적 대화형 시스템을 설계할 때 고려할 상황이다.
여기서 “캐시가 있으니 괜찮다”는 답은 절반만 맞는다. 캐시는 비용을 낮추는 수단이지만, 공식 과금 기준상 프롬프트 길이를 판정할 때는 캐시 읽기와 쓰기 토큰도 포함한다. 캐시를 많이 사용한다고 100K 경계 판정에서 그 부분이 사라지지는 않는다. 프롬프트 길이 계산 기준
또 하나 혼동하기 쉬운 숫자가 있다. Haiku 5.5의 컨텍스트 창은 100만 토큰이다. 하지만 ‘받을 수 있는 최대 분량’과 ‘최저 단가가 적용되는 분량’은 다른 개념이다. 큰 가방을 살 수 있다는 사실이, 그 가방을 가득 채워 운송하는 비용까지 같다는 뜻은 아니다. 모델 사양
이 구조에서 생각해 볼 설계는 일을 작게 나누는 것이다. 전체 저장소와 모든 대화를 작은 모델에 그대로 넘기기보다, 필요한 파일과 명확한 질문을 전달하고 짧은 결과를 받는 방식이다.
물론 분할 자체가 공짜는 아니다. 작업을 나누는 비용, 결과를 합치는 비용, 빠뜨린 맥락 때문에 다시 묻는 비용이 생긴다. 그래서 ‘서브에이전트를 많이 만들면 절약된다’가 아니라, 분리해도 정확도를 유지할 수 있는 일을 찾는다가 더 나은 출발점이다.
예를 들어 특정 함수의 호출 위치를 찾는 일과, 서비스 전체의 인증 설계를 바꾸는 일은 같은 위임 단위가 아니다. 전자는 범위와 결과를 확인하기 쉽다. 후자는 작은 조각마다 맞는 답을 얻어도 전체 변경이 잘못될 수 있다.
이전 Haiku에서 옮겨오는 경우에는 토큰 수도 다시 재야 한다. 공식 문서는 Haiku 5.5의 새 토크나이저가 같은 텍스트를 Haiku 4.5보다 약 30% 많은 토큰으로 계산한다고 안내한다. 정확한 차이는 내용에 따라 달라지므로, 한국어 업무 데이터에도 무조건 1.3을 곱해 예산을 확정할 수는 없다. Haiku 5.5 모델 개요
이 때문에 모델 교체 검토에서 가장 먼저 보고 싶은 자료는 화려한 종합 점수보다 내 요청의 길이 분포와 실패 기록이다.
짧은 요청, 경계에 가까운 요청, 긴 요청을 나눠 같은 과제를 평가해 보자. 한 번의 호출 가격뿐 아니라 재시도, 상위 모델로 넘긴 비용, 사람이 고치는 시간까지 기록하면 된다. 이것은 이 글에서 제안하는 평가 방식이지, Haiku 5.5의 우열이 이미 검증됐다는 뜻은 아니다.
싸게 틀리는 모델도, 비싸게 과잉 처리하는 모델도 좋은 기본값은 아니다. 내가 필요한 수준으로 일을 마쳤을 때 얼마가 들었는지가 중요하다.
Haiku 5.5를 도입한다면 처음부터 전체 에이전트를 교체하기보다, 지금 서비스에서 반복되는 작은 작업 하나를 후보로 잡아볼 만하다. 문서의 지정 항목 추출처럼 정답을 확인하기 쉬운 일이라면 더 좋다.
그리고 결과표에 한 칸을 더 만들자.
“100K를 넘긴 요청이 몇 개였나?”
이번 가격표에서는 그 한 칸이 평균 토큰 수보다 유용한 설명을 줄 수 있다.