드디어 쓸 만한 소형 모델

URL: https://www.youtube.com/watch?v=38_6C0dkKmU
날짜: 2026-10-09
채널: t3dotgg
원문 제목: finally a good small model

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==Anthropic의 Haiku 5.5는 저렴한 보조 모델로 실제로 쓸 가치가 있는가?==

• Anthropic은 Opus와 Sonnet처럼 큰 코딩 모델을 잘 만들었지만, 과거의 소형 모델 Haiku 4.5는 비싸고 성능이 낮아 사실상 쓸 이유가 없었다.
• Haiku 5.5는 100k 토큰 이하에서 극도로 낮은 가격, 100~200 TPS 수준의 속도, Haiku 4.5보다 두 배 이상 높은 벤치마크 점수를 내세운다.
• 가장 적합한 역할은 값싼 코딩 모델이 되는 것이 아니라, Opus·Sonnet이 호출하는 서브에이전트로서 파일 탐색·검증·분류·반복 시도·데이터 수집을 대량으로 처리하는 것이다.
• 복잡한 판단과 최종 코드 작성은 여전히 Opus나 다른 고성능 모델이 맡아야 하며, Haiku가 실패를 반복하면 오히려 더 비싸고 위험해질 수 있다.

Anthropic은 큰 모델을 만든 뒤 값싼 모델에 성능을 제대로 전달하지 못한다는 약점을 깨뜨리기 시작했다. Haiku 5.5가 모든 작업에 필요한 모델은 아니지만, 짧고 반복적인 작업과 병렬 탐색을 맡길 수 있는 첫 번째 Anthropic 소형 모델이 되었다는 것이 핵심 결론이다.

1. Anthropic 소형 모델의 오랜 약점

Anthropic의 새로운 소형 모델은 큰 모델 중심 전략이 낳은 성능 격차를 줄이는 시험대다.

1.1. 큰 모델은 강했지만 작은 모델은 뒤처졌다

1. Anthropic의 코딩 강점

   1. Anthropic은 Fable과 Opus 같은 대형 코딩 모델, 과거의 Sonnet 3.5와 도구 호출(tool call) 생태계를 통해 소프트웨어 엔지니어가 AI를 사용하는 방식을 바꿨다.
   2. 그러나 모델 라인업의 약점은 늘 소형 모델이었다. Haiku 4.5가 출시된 2025년 10월에는 괜찮아 보였지만, 당시에도 비쌌고 이후 가격 대비 성능이 빠르게 낡았다.

2. Haiku 4.5를 배제한 실제 운용

   1. Theo는 자신의 모든 도구, 에이전트 설정, Claude MD 문서에 Haiku 4.5를 피하라는 지침을 넣었다.
   2. 파일 검색이나 변경 사항 재확인처럼 비싼 모델이 토큰을 낭비하면 안 되는 일에도 Haiku 4.5를 믿지 못해, 비용을 아끼려고 Claude가 OpenAI의 Soul을 호출하도록 가르쳤다.
   3. Haiku 4.5는 “쓸모없고, 그다지 좋지 않다”는 평가를 받았으며, 출시 직후의 가격이 현재 기준으로는 우스꽝스러울 정도가 되었다.

1.2. 과거의 공개적인 모델 평가

1. Anthropic·OpenAI·Google에 대한 비판

   1. 몇 주 전 공개 글에서 “지금 Anthropic에는 쓸 만한 소형 모델이 없다”고 주장했다.
   2. 당시 OpenAI에는 Astra와 6.0 Soul만 있었고 6.1 Soul이 아직 나오지 않아 “쓸 만한 대형 모델이 없다”고도 비판했다.
   3. Google에는 “쓸 만한 모델이 하나도 없다”는 농담 섞인 평가를 덧붙였다.

2. 대형 모델에 집중한 결과

   1. Anthropic은 가장 큰 모델에 거의 모든 역량을 투입한 뒤, 더 싼 모델로 성능을 부실하게 증류하는 경향이 있었다.
   2. Mythos와 Fable 시기의 모델 계보에서는 Opus의 품질이 급락했고, 4.6·4.7·4.8을 거쳐 결국 성능이 끔찍한 Opus 5로 이어졌다는 평가가 나왔다.
   3. Opus 5.5와 Sonnet 5.5가 출시되면서 이 “큰 모델만 잘 만드는 저주”가 깨졌고, Haiku 5.5가 빠진 마지막 조각으로 기대되었다.

2. Haiku 5.5의 목적과 출시 메시지

Haiku 5.5는 최종 판단 모델이 아니라 고빈도·비용 민감형 작업을 위한 빠른 작업자다.

2.1. 공식적으로 제시된 용도

1. 반복적인 고빈도 작업

   1. 요약, 컨텍스트 압축(compaction), 데이터베이스 쿼리, 분류 요청처럼 짧고 반복되는 업무를 안정적으로 처리하도록 설계되었다.
   2. Opus와 Sonnet의 코딩 서브에이전트로 결합할 수 있다.

2. 속도가 중요한 작업

   1. 현재까지 Anthropic이 내놓은 모델 중 가장 빠른 모델이라고 소개되었다.
   2. 실시간 고객 지원, 브라우저 사용, 빠른 응답이 필요한 자동화에 적합하다.

3. 출시 가격의 핵심

   1. Haiku 4.5보다 평균 실행 비용이 약 75% 낮다.
   2. 낮은 가격만이 아니라 충분한 성능과 몇 가지 특수한 강점까지 제공해, 작은 크기에도 불구하고 실용적인 모델이 되었다.

2.2. 출시 직전의 제품 화면과 후원 메시지

1. 기존 Haiku의 비교 화면

   1. Slopolitics에서 Anthropic의 모델 라인업을 확인했을 때 Haiku 5.5는 아직 등록되지 않았고, Opus 5.5와 Sonnet 5.5 및 이전 Haiku만 볼 수 있었다.
   2. 이전 Haiku를 띄운 화면은 성능과 가격 면에서 더 설명할 필요가 없을 만큼 좋지 않다는 인상을 줬다.

2. CodeRabbit 보안 리뷰 후원

   1. 코드베이스가 AI 코딩 때문에 훨씬 커지고 복잡해지면서 일반적인 버그 리뷰만으로는 주요 보안 문제를 막기 어렵다는 문제를 제기했다.
   2. 보안 작업에서는 모델이 정책상 아예 거부하는 경우가 많지만, CodeRabbit은 승인된 모델과 계약을 확보해 풀 리퀘스트에서 실제 보안 지적을 제공한다.
   3. 지적 옆의 수정 버튼으로 승인된 모델을 사용해 바로 수정할 수 있다.
   4. 저장소 전체를 깊게 스캔하는 기능도 제공하며, 저장소를 고른 뒤 30분에서 1시간 정도 기다리면 실제로 조치할 만한 피드백을 많이 얻을 수 있다.
   5. Theo는 두 리뷰에서 발견된 문제의 절반 이상을 직접 처리했고, 일부는 심각해서 화면의 민감한 내용을 편집해야 할 정도였다고 말했다.

3. 가격 구조: 100k 토큰 안에서 극도로 싸게

Haiku 5.5의 가장 큰 변화는 단순한 모델 가격 인하가 아니라, 에이전트 비용의 상당 부분을 차지하는 캐시 읽기 가격까지 낮춘 점이다.

3.1. Sonnet 5.5와 Haiku 5.5의 가격 변화

1. Sonnet 5.5 캐시 읽기 가격 인하

   1. Sonnet 5.5의 캐시 읽기(cache read)는 백만 토큰당 20센트에서 10센트로 내려갔다.
   2. 이는 GPT-6.1 Soul의 캐시 읽기 가격과 같아져, 에이전트 작업에서 두 모델 간 비용 격차가 더 합리적으로 바뀌었다.
   3. 기존에는 Sonnet의 캐시 읽기가 Opus와 같은 가격이었고, 전체 청구액의 약 30~50%를 차지할 수 있어 Sonnet을 써도 Opus와 비용 차이가 크지 않았다.
   4. 긴 컨텍스트를 계속 재사용하는 에이전트에서는 캐시 읽기 가격이 저렴해야 모델 자체의 가격 인하가 실제 절감으로 이어진다.

2. Haiku 5.5의 기본 요금

   1. 캐시 읽기는 백만 토큰당 1센트다.
   2. 캐시 쓰기는 백만 토큰당 12.5센트다.
   3. 일반 입력은 백만 토큰당 10센트다.
   4. 출력은 백만 토큰당 50센트다.
   5. 이전 Haiku 4.5의 출력 가격은 백만 토큰당 5달러였고, Sonnet 5.5는 10달러였으므로 출력 토큰만 비교하면 Haiku 5.5가 Sonnet보다 20배 싸다.
   6. 일반 입력과 캐시 쓰기도 대략 20배 수준으로 싸고, 캐시 읽기는 Sonnet의 10분의 1이다.

3.2. 100k 토큰 경계와 5배 요금

1. 컨텍스트 한도

   1. 위 가격은 최대 100k 토큰 컨텍스트에 적용된다.
   2. 100k 토큰은 장시간 실행되는 에이전트에는 작아 보인다.
   3. Anthropic은 예전 250k~270k 토큰을 넘으면 요금을 두 배로 받던 정책을 최근 없앴지만, Haiku 5.5는 100k를 넘으면 할인 가격을 유지하지 않는다.

2. 100k 초과 시 변화

   1. 가격은 두 배가 아니라 5배가 된다.
   2. 출력은 백만 토큰당 50센트에서 2.50달러로 오른다.
   3. 입력은 백만 토큰당 10센트에서 50센트로 오른다.
   4. 컨텍스트를 메모리에 유지하려면 일정 임계점부터 필요한 RAM이 급격히 늘어나 인프라 비용도 커진다는 설명이 붙는다.

3. 가격 설계의 의도

   1. 파일 읽기, 짧은 응답, 분류처럼 100k 이하에서 끝나는 주된 사용 사례는 Anthropic이 마진 일부를 감수할 만큼 싸게 만들었다.
   2. Jev 같은 별도 분류용 API를 띄우는 대신 Haiku 하나로 텍스트 정리·분류·조직화를 처리하게 만드는 전략이다.
   3. Claude Code 안에서 긴 작업을 수행할 때는 무료에 가깝게 쓰지 못하게 하여 Anthropic이 손실을 감당하지 않도록 했다.
   4. 저렴한 짧은 작업과 비싼 장시간 작업 사이의 가격 차이가 의도된 사용처를 유도한다.

4. 자동 압축 창 설정

   1. Anthropic 직원 Lydia는 청구액을 걱정하지 않으려면 Haiku 5.5의 자동 압축 창을 100k로 직접 설정하라고 공개적으로 말했다.
   2. 이 설정은 모델별로 적용되므로 Haiku와 그 서브에이전트만 100k 이내에서 계속 실행되도록 만들 수 있다.
   3. API, Bedrock, Claude Code 어느 환경에서도 서브에이전트가 갑자기 큰 비용을 발생시키는 일을 막는 방법이다.

4. 성능 벤치마크와 경쟁 모델 비교

Haiku 5.5는 Haiku 4.5보다 큰 폭으로 좋아졌지만, 모든 가격 대비 성능 차트를 지배하는 모델은 아니다.

4.1. Haiku 4.5 대비 도약

1. 종합 벤치마크

   1. Theo의 Slopolitics 벤치에서 대부분의 항목 점수가 Haiku 4.5의 두 배를 넘었다.
   2. Anthropic 측이 특히 반가워한 지점은 Terminal Bench에서 더 이상 0점을 받지 않았다는 점이다.
   3. Terminal Bench 점수는 0에서 거의 40%까지 올라갔다.

2. 코딩 성능

   1. GPT-6 Luna는 코딩에서 16.4%를 기록했지만 Haiku 5.5는 거의 40%에 달해 두 배 이상 높았다.
   2. Luna가 코딩에 괜찮다고 생각한 사람들에게는 Haiku의 점수가 판단을 다시 생각하게 할 정도라는 농담을 던졌다.

3. 컴퓨터 사용

   1. OpenAI 모델은 컴퓨터 사용(computer use)에서 오랫동안 앞서 있었지만, 개인적인 사용 경험에서는 벤치마크보다 격차가 더 컸다.
   2. Haiku 5.5는 이 항목에서 GPT-6 Luna보다 약 40% 가까이 높은 수준으로 크게 앞섰다.
   3. 실제 컴퓨터 사용을 아직 충분히 시험하지는 않았지만, 높은 점수와 속도 때문에 유망한 소형 모델로 평가했다.

4.2. 추론 설정과 속도의 함정

1. 추론을 끈 상태의 실패

   1. Prime은 자동화 작업에서 GPT-6 Luna 대신 Haiku 5.5를 추론 없이 사용해 보았지만, 통과율이 낮아지고 실패율이 크게 높아졌으며 체감 속도도 더 느렸다고 보고했다.
   2. OpenAI는 추론을 끈 상태에서도 잘 작동하도록 모델을 훈련했지만, Anthropic은 Opus와 Sonnet에 최소한의 추론을 항상 남기는 방향으로 만들었다.
   3. Haiku에는 빠른 응답을 원하는 작업을 위해 추론 끄기 옵션이 남아 있지만, 그 모드에서는 품질이 좋지 않다.

2. 작업별 선택

   1. 추론을 끈 채 분류만 할 생각이라면 Jev를 쓰는 편이 낫다.
   2. 이미지나 비전이 필요하지 않다면 Luna가 더 싸서 유력하고, 비전이 필요할 때 Haiku 또는 Luna를 고려할 수 있다.
   3. 일반적인 Claude Code 프롬프트와 추론을 켠 상태에서는 약 180 TPS를 경험했다.
   4. 제공업체에 따라 Haiku 5.5의 처리 속도는 초당 100~200 토큰 수준이다.

4.3. 토큰 효율과 Slopolitics 분석

1. 모델별 작업당 토큰

   1. Sonnet 5.5를 최고 추론 단계인 Max로 돌리면 작업당 평균 약 20만 토큰을 사용했다.
   2. Fable은 약 7.8만 토큰으로 Sonnet의 절반 이하였고, Sonnet은 Fable보다 2.5배 많은 토큰을 사용했다.
   3. Sonnet 5.5의 작업당 비용이 Fable 5.1보다 약간 높아진 원인은 모델 지능이 아니라 Max라는 과도한 추론 설정이었다.
   4. Slopolitics의 Max 표시를 끄면 Haiku 5.5가 차트의 가장 왼쪽, 즉 가장 싼 쪽에 놓인다.

2. 가격 대비 지능의 기본 흐름

   1. Anthropic 모델만 최신 버전끼리 비교하면 Haiku 5.5는 Opus 5.5와 점수가 가까우면서도 실행 비용이 거의 5분의 1이다.
   2. Haiku 5.5의 X-High와 Max가 Anthropic 라인업에서 가장 좋은 가격 대비 성능을 보였고, Sonnet High가 Opus Low보다 똑똑하면서 Opus Medium보다 싸서 Pareto 선에 잠깐 들어왔다.
   3. 그 이후의 최선은 Opus 5.5의 Medium·High·X-High·Max가 차지했다.

3. 추론 단계와 차트 해석

   1. 로그 가격 차트는 싼 쪽의 간격을 실제보다 크게 보이게 하고 비싼 쪽의 간격을 작게 보이게 하므로, 선형 가격으로 바꿔야 차이를 정확히 읽을 수 있다.
   2. Sonnet X-High는 작업당 2.75달러로 괜찮은 가치지만, Sonnet 5.5 Max는 작업당 7.60달러라 사실상 의미가 없다.
   3. Sonnet 5.5를 Max 추론으로 사용하지 말라는 강한 권고가 나왔다.

4.4. 다른 모델을 포함한 가격 대비 성능

1. Gemini·Grok·Astra 비교

   1. Gemini 4 Argon과 38 Flash를 추가해도 Pareto 선에는 큰 변화가 없었고, Haiku 선을 오른쪽 아래로 옮긴 것처럼 보였다.
   2. Grok 4.7도 Haiku 이하에 머물러 흥미로운 변화를 만들지 못했다.
   3. GPT-6 Astra Low는 Sonnet 5.5 High와 비슷한 지능으로 Pareto 선에 들어왔다.

2. GPT-6 Luna

   1. GPT-6 Luna는 Haiku보다 항상 싸고, 해당 벤치 수치에서는 항상 조금 더 둔하지만 서로 보완적인 조합이다.
   2. 전체 Pareto 선은 Luna 전 구간, Haiku 전 구간, Astra의 짧은 구간, Sonnet, Opus 순으로 이어졌다.
   3. Astra와 Sonnet을 끄면 Luna·6.1 Soul·Opus 5.5가 API 비용 대비 지능의 단순하고 강한 선을 만든다.

3. GPT-6.1 Soul과 Mimo V26 Pro

   1. Haiku를 21.3센트에서 21.4센트로 조금 더 비싼 지점으로 옮기면 지능이 크게 뛰는 것처럼 보일 만큼 6.1 Soul과의 간격이 작다.
   2. Haiku를 차트에서 끄면 Luna·Soul·Opus를 잇는 더 매끄러운 가격 대비 성능 선이 나온다.
   3. Mimo V26 Pro는 사람들이 충분히 이야기하지 않는 저평가된 오픈 웨이트 모델이며, 가격 대비 성능이 상당히 좋다.

4. Haiku를 선택할 실용적인 이유

   1. Anthropic API만 사용하거나 Anthropic에 큰 사용량을 약정한 경우에는 외부 제공업체를 추가할 필요가 없다.
   2. Claude Code 구독자라서 Codex까지 별도로 구독하고 싶지 않은 경우에도 Haiku를 선택할 이유가 있다.
   3. Opus가 Soul보다 Haiku를 호출할 때 더 잘 맞는다는 체감처럼, 같은 Anthropic 계열 모델끼리 프롬프트와 작업 맥락을 공유하는 장점이 있을 수 있다.
   4. Haiku 4.5는 비싸고 성능이 낮아 사용할 이유가 없었지만, Haiku 5.5부터는 같은 계열 안에서 책임 있게 선택할 수 있는 소형 모델이 되었다.

4.5. 캐시 가격 수정 후의 Sonnet

1. Artificial Analysis가 Sonnet 5.5의 새로운 캐시 읽기 가격을 반영하자 Sonnet은 차트에서 왼쪽으로 이동했다.
2. Sonnet High의 Pareto 선에서 어색하게 내려앉던 지점이 덜 이상해졌고, 이전보다 훨씬 설득력이 생겼다.
3. 그래도 Haiku·Soul·Opus 사이의 가격 대비 성능 구도를 근본적으로 뒤집을 정도는 아니었다.

5. 구독 플랜, API 크레딧, SDK 변화

Anthropic은 Claude Code 구독을 API와 연결하는 방식을 더 유용하게 바꾸었다.

5.1. 구독자용 API 크레딧

1. 기존의 우려

   1. Claude Code 구독으로 Anthropic·OpenAI 등 여러 모델을 T3 Code에서 사용할 수 있었고, 구독과 도구 통합이 중단될까 걱정하는 사용자가 많았다.
   2. Anthropic이 구독을 통한 외부 도구 사용을 막을 것이라는 과거 발언이 있었지만 아직 실제로 막지는 않았다.

2. 새로운 월간 크레딧

   1. 20x 사용자, 즉 월 200달러 플랜 가입자는 매달 200달러의 API 크레딧을 받는다.
   2. 5x 사용자는 매달 100달러의 API 크레딧을 받는다.
   3. Claude Code에서 Haiku나 Sonnet을 사용하는 앱을 만들고 친구에게 배포해도 이 크레딧으로 API 비용을 지불할 수 있다.
   4. Claude Code SDK와 Agent SDK 통합을 망치지 않도록 Anthropic이 사용자들의 의견을 듣고, 문제가 될 수 있었던 정책을 실제로 유용한 기능으로 바꾸었다는 평가를 받았다.

5.2. Python·TypeScript SDK의 브라우저 기능

1. Claude Python SDK와 TypeScript SDK가 컴퓨터 사용과 브라우저 사용을 지원하도록 업데이트된다.
2. T3 Code 같은 도구가 이 기능을 활용하면 단순 코딩을 넘어 브라우저를 조작하는 에이전트로 확장될 가능성이 있다.
3. Haiku 5.5가 Grok 4.7보다 사용하기 편할 것이라는 낙관적인 비교도 나왔다.

6. Opus가 Haiku를 지휘하는 병렬 서브에이전트

Haiku 5.5의 가장 강한 사용 방식은 모델을 직접 선택하는 것이 아니라, 고성능 모델이 필요한 순간에 호출하게 만드는 것이다.

6.1. 안전한 달걀 낙하 실험

1. Opus 단독 구성

   1. Anthropic은 달걀 낙하 역학을 흉내 낸 에뮬레이션에서 Opus 5.5 하나로 안전한 달걀 낙하 장치를 설계하게 했다.
   2. 단일 스레드로 한 번에 하나씩 시도했기 때문에 성공까지 3분 30초가 걸렸다.
   3. 25번 시도했고 비용은 47센트였다.

2. Opus + Haiku 10개 구성

   1. Opus 5.5가 지휘하고 Haiku 5.5 서브에이전트 10개가 동시에 다양한 설계를 시도했다.
   2. 1분 이내에 성공했고, 총 86번의 시도를 수행했다.
   3. 비용은 14센트에 불과했다.
   4. 대부분의 시도가 틀리는 문제에서는 하나의 똑똑한 시도보다 열 개의 값싼 시도와 검증이 더 유리하다.

6.2. Haiku가 특히 강한 작업

1. 병렬 탐색

   1. 코드베이스에서 ripgrep만으로 바로 찾을 수 없는 파일 하나를 찾는 작업처럼, 여러 후보를 확인해야 하는 작업에서 Haiku를 동시에 많이 띄울 수 있다.
   2. 무작위 시도의 정답률과 똑똑한 모델의 신중한 시도 사이의 간격이 작고, 결과를 자동 검증할 수 있다면 Haiku가 비용과 속도에서 압도한다.

2. 서브에이전트로서의 역할

   1. 파일 검색, 변경 사항의 삼중 확인, 코드베이스 탐색, 문서 수집, 여러 앱과 오픈소스 프로젝트 비교, 데이터 분류에 적합하다.
   2. 최종 코드를 쓰는 과정 자체는 입력 컨텍스트가 이미 캐시되어 있다면 생각보다 싸다.
   3. 값비싼 부분은 필요한 컨텍스트를 모으고, 결과가 제대로 작동했는지 검증하고, 테스트를 만들고, GitHub 풀 리퀘스트를 감시하고, 실패하면 다시 생성하는 과정이다.

3. 모델 선택의 조건

   1. 계획을 똑똑한 모델로 매우 자세히 세운 뒤 단순 구현만 맡기는 경우에는 Haiku도 일부 역할을 할 수 있다.
   2. 그러나 계획 자체를 이미 비싼 모델로 만들었다면 구현 부분만 아끼는 효과는 제한적이다.
   3. 계획의 이론을 네 가지 방식으로 검증하거나, 외부 사례 여덟 개를 찾아 비교하거나, 문서를 대량으로 읽어 사실을 확인하는 단계에서 Haiku의 가치가 커진다.

7. 생성 결과 데모: 영상·프런트엔드·Fish Slap

저렴한 모델이 낼 수 있는 결과는 완벽하지 않지만, 비용을 고려하면 놀랄 만큼 쓸 만한 수준에 도달했다.

7.1. 프로그램으로 만든 영상

1. 커뮤니티의 Arshan이 Haiku 5.5로 프로그램 방식의 영상을 만들었다.
2. 제작에는 20분도 걸리지 않았고 API 비용은 60센트였다.
3. 시각적 완성도에 비해 비용이 매우 낮았으며, Anthropic 모델이 가진 디자인 감각과 좋은 레퍼런스 데이터가 결과에 기여했다.
4. Anthropic이 디자인 데이터를 많이 다듬어 모델에 좋은 기준점을 제공한 것 같다는 해석이 나왔다.

7.2. 프런트엔드 디자인과 Claude 디자인 스킬

1. Dara의 Which AI를 활용한 프런트엔드 결과물은 Grok보다 압도적으로 나았다.
2. 텍스트가 나타나는 작은 애니메이션, 마우스 오버에 반응하며 내부를 바꾸는 다이어그램, 블루프린트 스타일 등 새로운 시각적 시도가 보였다.
3. 모든 시안이 마음에 든 것은 아니지만, 선택한 글꼴이 덜 진부하고 예전 모델처럼 일부러 유치한 폰트를 고르는 일이 줄었다.
4. 디자인 스케일을 끄면 전형적인 “LM 디자인”으로 돌아갔고, 새 Claude 디자인 스킬이 현재 모델의 프런트엔드 결과를 크게 개선한다는 점이 드러났다.
5. Grok 4.7은 디자인 스킬을 끈 상태에서 더 나빴고, 초등학교 때 순수 HTML로 만든 사이트가 더 나아 보였을 수 있다는 농담이 나왔다.
6. 비용 때문에 Haiku를 선택한 사용자, 또는 Open Code 같은 8달러 플랜에서 사용하는 사용자에게는 충분히 쓸 수 있지만, 모든 프런트엔드 작업을 맡길 수준은 아니다.
7. 20달러 Claude 구독만으로 코딩이 가능해질 수 있다는 점 자체가 인상적인 변화다.

7.3. Fish Slap 게임

1. 새 Fish Slap 빌드는 마우스 이동이 없고, 스페이스·Shift·WASD로만 움직이며, 방향 전환을 직접 해야 했다.
2. 소리가 없었고 음소거 때문인지 확인했지만 실제로 사운드가 구현되지 않은 상태였다.
3. 전체 수준은 Grok 버전과 비슷했으며, 즉시 공격적일 정도로 틀린 결과는 적었지만 인상적인 결정도 적었다.
4. GPT-6 Astra는 시각적으로 놀라운 결과를 만들었지만 마우스 이동이 지나치게 느리고 조작감이 나빴으며, 게임 핵심 루프와 버그에 문제가 있었다.
5. Haiku는 Astra보다 최저점이 낮지 않았지만 최고점은 Astra의 10분의 1 정도였다.
6. 모서리 처리 방식이 나빴고, 두 번째 외계인 공격의 타이밍이 너무 빨랐으며, 원작의 의도를 충분히 따르지 못했다.

8. T3 Code의 대규모 풀 리퀘스트 감사

Haiku는 수천 건을 훑는 감사 작업에 유용했지만, 감독 없이 중요한 워크플로를 맡기면 곤란한 상태에 빠질 수 있었다.

8.1. 성능 관련 PR 감사

1. 작업 범위

   1. T3 Code에는 당시 거의 1,500개에 달하는 열린 PR이 있었다.
   2. Haiku 5.5는 성능 관련 변경 PR을 감사하고, 다른 스레드에서는 모든 PR을 분류해 결과를 HTML 페이지로 만들도록 설정되었다.
   3. 처음에는 서브에이전트에 Haiku 6개를 사용하라고 잘못 지시했다가 뒤에서 수정했다.

2. 첫 번째 결과

   1. 성능 관련 열린 PR 40개를 찾았고 대부분 서버 또는 모바일 수정이었다.
   2. 실제 영향이 크면서 깔끔한 PR은 몇 개뿐이었다.
   3. GitHub가 상태를 “clean”으로 표시하자 Haiku는 충분히 감사하지 않고 병합 준비가 된 것으로 판단했다.
   4. 명령을 다시 실행했을 때 서버가 더 이상 멈추지 않았고, 재시도 시간은 18초 이상에서 6밀리초로 줄었다.

3. Opus의 최종 판단

   1. Theo는 의심스러운 PR을 Opus에 붙여 넣고 “병합할 가치가 있는지 판단하고, 필요한 부분을 고치고, 확신이 들면 병합하라”고 지시했다.
   2. 이른바 “full send” 지시와 “full stop” 조합이 실제 개발 방식을 바꿨으며, 최종 병합 판단은 더 똑똑한 모델에 맡겼다.

8.2. Fish Slap 비용 분석

1. 전체 Fish Slap 생성에는 사용량 기준 약 1달러가 들었다.
2. 캐시 읽기는 973만 토큰으로 매우 많았다.
3. 매번 1시간 캐시 쓰기가 발생했으며, 이 방식이 다소 불편하다고 지적했다.
4. 새 입력은 지속적으로 캐시되어 약 102토큰에 불과했다.
5. 출력 토큰 비용은 약 30센트였다.
6. 51개 요청 중 47개가 100k 입력 토큰을 넘어서 Haiku의 높은 가격 구간을 적용받았다.
7. 컨텍스트를 강제로 제한했다면 게임 결과는 훨씬 나빠졌겠지만 비용은 줄었을 것이다.

8.3. 소형 모델이 직접 코딩 모델이 되면 안 되는 이유

1. LLM 코딩 비용의 핵심은 프롬프트에서 실행 가능한 JavaScript 파일을 한 번 생성하는 일이 아니다.
2. 필요한 컨텍스트를 모으고, 그 컨텍스트를 모델에 넣고, 결과가 작동하는지 검증하고, 모든 경계 조건을 테스트하고, GitHub PR을 감시하는 일이 훨씬 비싸다.
3. 처음 일곱 번 틀린 결과를 여덟 번째에 다시 생성하는 것도 큰 비용이다.
4. 따라서 코드를 직접 쓰는 한가운데 단계는 가장 비싼 모델이 맡아도 대체로 몇 센트 수준이며, 굳이 둔한 모델로 대체할 이유가 없다.
5. Haiku는 고성능 모델이 필요한 자료를 모으고 검증하는 도구로 쓸 때 가치가 크다.

8.4. GitHub API 한도에 걸린 실패

1. PR 데이터를 병렬로 가져오는 작업이 시간당 5,000회 GitHub 요청 대부분을 소모했다.
2. 스크립트가 API 오류 응답 본문을 정상 데이터처럼 저장했고, jq가 배열이 아닌 오류 문서를 처리하다 실패했다.
3. 결과적으로 T3 Code의 GitHub 통합을 최소 50분 동안 사용할 수 없게 되었다.
4. PR별 JSON 파일은 전체적으로 파싱되었지만, 181개 PR을 한도 초기화 후 다시 가져오고 JSON 배열이 아닌 응답을 거부하도록 스크립트를 고쳐야 했다.
5. 에이전트는 한도가 풀릴 때까지 기다리겠다고 했지만 실제 대기 트리거를 걸지 않았고, UI에 대기 작업이 표시되지도 않았다.
6. 사용자가 직접 다시 지시할 때까지 스레드가 멈춘 상태가 되었다.
7. 작은 모델은 이런 식으로 자신뿐 아니라 사용자의 작업 환경도 막다른 길로 몰 수 있으며, 이번 사례에서는 T3 Code 사용 경험을 적어도 50분 망가뜨렸다.

8.5. Opus가 Haiku를 오케스트레이션하는 개선안

1. 같은 PR 작업을 다시 실행하되, 많은 서브에이전트와 워크플로를 활용하고 모든 서브에이전트에 Haiku 5.5를 사용하라고 지시했다.
2. Opus는 실제 데이터 수집과 서브에이전트 오케스트레이션 외의 작업을 스스로 최소화해야 한다는 조건을 받았다.
3. 1,495개의 열린 PR은 큰 작업이므로 Haiku 에이전트 하나가 약 15개씩 처리하면 약 100개의 에이전트가 필요하다고 계산했다.
4. 일반적인 소규모 워크플로 지침을 넘어서는 규모지만, “많은 서브에이전트”라는 사용자 요구를 따르기 위해 배치 규모를 판단했다.
5. Opus는 rate limit에 부딪히더라도 우회 방법을 찾을 가능성이 더 높아, 단순히 Haiku를 직접 실행하는 것보다 안전한 감독자가 된다.

9. 언제 Haiku를 쓰고 언제 Opus·Soul을 쓸 것인가

가격표만 보면 Haiku가 매력적이지만, 실패 비용과 모델 간 역할 분담까지 함께 봐야 한다.

9.1. Haiku와 Opus의 실제 비용 격차

1. Opus 5 Low는 작업당 약 20센트, Haiku 5.5 Max는 약 55센트로 나타나 둘의 차이가 생각보다 작다.
2. Opus가 10만 토큰으로 해결할 문제를 Haiku가 해결하지 못해 100만 토큰을 태우면, 소형 모델이 오히려 더 비싸진다.
3. Haiku가 할 수 없는 작업에 계속 매달리면 비용뿐 아니라 사용자의 시간과 외부 API 한도까지 잃는다.
4. 복잡한 계획, 코드 작성, 중요한 검증에는 Opus를 쓰고, Opus가 필요로 하는 대량의 사전 작업을 Haiku에 맡기는 구성이 합리적이다.

9.2. Soul은 더 싼 중간 모델이 아니라 다른 관점이다

1. GPT-6.1 Soul은 Haiku보다 똑똑하고 Opus보다 싸다는 단순한 중간 단계로만 볼 필요가 없다.
2. 매일 같은 일을 함께하는 팀이 어려운 문제의 해결책에 합의하는 것과 달리, Soul은 다른 회사에서 일하는 친구에게 의견을 묻는 것처럼 다른 사고방식을 제공한다.
3. OpenAI 모델은 코드 감사에서 특히 꼼꼼하고 독특한 관점을 주는 경향이 있다.
4. Opus가 코드를 작성하고 Soul이 PR 전에 의견을 내도록 설정하면 Opus가 놓친 어리석은 문제를 잡아내어 병합 속도가 빨라진다.
5. Theo는 개인적으로 Opus와 Soul 조합을 계속 사용하되, Opus가 대량 데이터 수집·읽기·분류를 할 때 Haiku를 호출하도록 할 계획이다.

9.3. Anthropic 라인업의 재평가

1. Opus와 Haiku만 사용해도 Anthropic 모델에서 필요한 기능 대부분을 놓치지 않을 수 있다.
2. Sonnet 5.5는 캐시 읽기 가격 인하로 좋아졌지만, 최신 차트의 Pareto 선에서는 거의 제공하는 것이 없다는 평가를 받았다.
3. Anthropic 전용 환경에서는 Opus가 최종 사고와 실행을 담당하고 Haiku가 값싼 탐색·검증·분류를 맡는 구성이 충분히 강하다.

주요 발언 모음

“Anthropic에는 지금 쓸 만한 소형 모델이 없다.”

“Haiku 4.5는 모든 비용을 들여 피해야 한다. 쓸모가 없고 그다지 좋지 않다.”

“Haiku 5.5는 지금까지 출시한 모델 중 가장 싸고, 빠르고, 능력 있는 소형 모델이다.”

“무작위로 시도한 둔한 모델의 결과와 신중하게 시도한 똑똑한 모델의 결과 사이의 간격이 크지 않다면, Haiku 5.5가 압도한다.”

“코딩 자체가 비싼 것이 아니다. 필요한 컨텍스트를 모으고, 작동을 검증하고, 주변의 테스트와 자동화를 만드는 일이 비싸다.”

“Haiku를 코드 에이전트에서 직접 고르지는 않겠지만, Opus가 적절한 때 호출할 것이라고 믿는다.”

“Anthropic은 이제 가끔 쓸 만한 소형 모델 하나를 갖게 되었다. 아주 좋은 변화다.”

“지금 Anthropic은 전방위로 지배하고 있으며, 내가 OpenAI라면 매우 두려워하고 다음 Astra 학습 결과가 믿을 수 없을 만큼 좋기를 기도할 것이다.”

핵심 데이터 & 수치

• Haiku 5.5 평균 비용 절감: Haiku 4.5 대비 약 75% 저렴하다.
• Haiku 5.5 요금(100k 토큰 이하): 캐시 읽기 $0.01/백만 토큰, 캐시 쓰기 $0.125/백만 토큰, 입력 $0.10/백만 토큰, 출력 $0.50/백만 토큰이다.
• 100k 초과 요금: 입력과 출력 가격이 각각 5배가 되어 입력 $0.50, 출력 $2.50/백만 토큰이 된다.
• Sonnet 5.5 캐시 읽기: $0.20에서 $0.10/백만 토큰으로 인하되었다.
• 처리 속도: 제공업체에 따라 초당 100~200 토큰이며, 개인 실험에서는 약 180 TPS였다.
• Terminal Bench: Haiku 4.5의 0점에서 Haiku 5.5가 거의 40%로 상승했다.
• GPT-6 Luna 코딩 점수: 16.4%로 Haiku 5.5의 거의 절반이다.
• 안전한 달걀 낙하: Opus 단독은 3분 30초·25회 시도·$0.47, Opus+Haiku 10개는 1분 이내·86회 시도·$0.14였다.
• 프로그램 영상 데모: 20분 이내 제작에 API 비용 약 $0.60이 들었다.
• Fish Slap: 총 사용량 약 $1, 캐시 읽기 973만 토큰, 출력 비용 약 $0.30, 51개 요청 중 47개가 100k 입력 토큰 초과였다.
• T3 Code PR 감사: 성능 관련 열린 PR 40개를 찾았고, 전체 열린 PR은 약 1,495~1,500개였다.
• GitHub rate limit: 병렬 수집으로 시간당 5,000회 요청 한도를 소진했고, 약 50분 동안 통합 기능을 사용하지 못했다.
• Haiku·Opus 가격 비교: Opus 5 Low는 작업당 약 $0.20, Haiku 5.5 Max는 약 $0.55였다.
• 구독자 API 크레딧: 20x($200) 플랜은 월 $200, 5x 플랜은 월 $100의 API 크레딧을 받는다.
• 다른 가격 대비 성능 모델: GPT-6.1 Soul은 Haiku와 거의 비슷한 비용에서 더 높은 지능을 보였고, Mimo V26 Pro는 저평가된 오픈 웨이트 모델로 언급되었다.

결론 및 시사점

1. Haiku 5.5는 드디어 조건부로 쓸 만한 Anthropic 소형 모델이다. Haiku 4.5처럼 비싸고 약한 모델이 아니라, 짧은 컨텍스트에서 매우 빠르고 값싸며 성능도 충분하다.
2. 가장 좋은 역할은 직접 코딩이 아니라 값싼 보조 작업이다. 파일 검색, 대량 문서 읽기, 분류, 변경 사항 확인, 여러 후보의 병렬 시도처럼 정답 후보를 많이 만들거나 확인해야 하는 작업에 배치한다.
3. 고성능 모델이 감독해야 한다. Opus가 작업을 분해하고 Haiku를 호출하며 결과를 검증하게 만들면, 달걀 낙하 실험처럼 더 빠르고 싸게 더 많은 시도를 할 수 있다.
4. 100k 토큰 자동 압축을 설정해야 비용을 통제할 수 있다. 이 경계를 넘으면 입력·출력 요금이 5배가 되므로 장시간 서브에이전트에 적용할 모델별 압축 창을 명시하는 편이 안전하다.
5. 추론을 끈 Haiku는 별도 검증이 필요하다. 빠른 분류 용도로는 Jev가 더 나을 수 있고, Haiku는 추론을 켠 에이전트 보조 작업에서 장점이 더 크다.
6. 최종 코드 작성은 Opus나 동급 모델이 맡는 편이 낫다. 코드 생성 자체의 가격은 작지만, 실패를 반복하는 소형 모델은 컨텍스트·검증·외부 API 한도를 낭비한다.
7. Soul은 Haiku와 경쟁하는 단순한 중간 가격대 모델이 아니다. Opus가 만든 코드를 다른 관점에서 감사하는 역할이 강하므로 Opus+Soul과 Opus+Haiku는 서로 다른 목적의 조합이다.
8. Anthropic의 가격 구조가 처음으로 일관성을 갖췄다. Opus는 사고와 실행, Haiku는 탐색과 반복, Soul은 독립적인 감사라는 역할 분담이 가능해졌다.
9. 다음 관찰 대상은 Fable 5.5다. Opus·Sonnet·Haiku 5.5가 세운 기준을 Fable이 충족한다면 Anthropic의 5.5 라인업은 대형·중형·소형 전반에서 강력해진다.
10. 최종 평가는 “항상 필요한 모델”이 아니라 “가끔 반드시 필요한 모델”이다. Anthropic은 이제 쓸 만한 소형 모델을 하나 보유하게 되었고, 그 자체가 Haiku 4.5에서의 큰 개선이다.

핵심 요약 (20줄)

1. Anthropic은 Opus와 Sonnet처럼 큰 코딩 모델을 잘 만들었지만 Haiku 4.5는 비싸고 성능이 낮았다.
2. Haiku 5.5는 Anthropic이 처음으로 조건부 실사용을 권할 만한 소형 모델이다.
3. Haiku 5.5의 평균 실행 비용은 Haiku 4.5보다 약 75% 낮다.
4. 100k 토큰 이하에서 캐시 읽기 가격은 백만 토큰당 1센트다.
5. 100k 토큰 이하에서 일반 입력은 10센트, 출력은 50센트다.
6. 100k 토큰을 넘으면 입력과 출력 가격이 5배로 상승한다.
7. Haiku 5.5는 제공업체에 따라 초당 100~200토큰을 처리한다.
8. Haiku 4.5에서 0점이던 Terminal Bench 점수가 Haiku 5.5에서 거의 40%로 올랐다.
9. Haiku 5.5의 GPT-6 Luna 코딩 점수는 Luna의 16.4%보다 두 배 이상 높다.
10. 컴퓨터 사용 벤치마크에서 Haiku 5.5는 GPT-6 Luna보다 약 40% 앞섰다.
11. 추론을 끈 Haiku 5.5는 통과율이 낮고 실패율이 높아 자동화 품질이 나빠질 수 있다.
12. Haiku 5.5는 Opus가 호출하는 파일 탐색·분류·검증 서브에이전트로 가장 적합하다.
13. Opus 단독 달걀 낙하는 25회 시도에 47센트가 들었고 3분 30초가 걸렸다.
14. Opus와 Haiku 10개 조합은 86회 시도에 14센트가 들었고 1분 이내에 성공했다.
15. Haiku로 만든 프로그램 영상은 20분 이내 제작에 60센트가 들었다.
16. Fish Slap 생성에는 약 1달러와 캐시 읽기 973만 토큰이 사용되었다.
17. Haiku가 직접 복잡한 코딩을 맡으면 실패 반복으로 Opus보다 비싸질 수 있다.
18. Opus는 복잡한 판단과 최종 코드를 맡고 Haiku는 값싼 대량 사전 작업을 맡는 편이 안전하다.
19. GPT-6.1 Soul은 다른 관점의 코드 감사자로서 Opus와 좋은 조합을 이룬다.
20. Anthropic은 이제 항상 쓸 모델은 아니지만 필요할 때 확실히 가치가 있는 소형 모델을 갖게 되었다.