The Haiku 5.5 Benchmarks are INSANE, So I Tested It Versus Luna

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Haiku 5.5는 벤치마크에서 강했지만, Luna와의 직접 비교에서는 비용·속도·작업 완주에 약점을 보였고 긴 문맥 검색 정확도에서 뚜렷하게 앞섰다.

📌 핵심 요점

1. Anthropic이 공개한 벤치마크에서는 Haiku가 Luna를 전반적으로 앞섰다. 영상에서 소개한 독립 평가에서도 강점을 보였지만, 자동화·지식 정확도에서는 Luna가 우세했고 긴 문맥 추론·과학 코딩에서는 비슷했다.
2. 토큰 단가가 같아도 작업당 비용은 달랐다. 소개된 지능 지수 평가에서 Haiku는 43점에 약 21센트, Luna는 38점에 약 7센트였다. 발표자는 Haiku의 토큰 소비와 장문 할증을 주요 원인으로 설명했다.
3. 웹사이트 제작에서는 Luna가 더 적은 비용과 시간으로 비슷한 결과를 냈다. 낮은 노력 설정에서는 Haiku의 예약 확인 버튼이 작동하지 않았고, 최대 설정에서는 Haiku가 첫 시도에 실패해 재시도가 필요했다.
4. 높은 노력 설정이 항상 좋은 결과로 이어지지는 않았다. Haiku는 스노보드 게임과 최대 설정의 복셀 애니메이션에서 출력 한계에 걸렸다는 설명과 함께 결과물을 완성하지 못했다. 발표자가 제시한 합산에서는 Luna가 거의 7배 저렴하고 37% 빨랐다.
5. 긴 문맥에서 특정 정보를 찾는 테스트는 Haiku의 확실한 강점이었다. 중간 노력 설정의 정확도는 Haiku 96%, Luna 29%로 제시됐다. 빠른 제작·대량 처리에는 Luna, 정확한 장문 정보 회수에는 Haiku라는 용도별 선택이 영상의 결론이다.

🧩 배경과 문제 정의

영상은 Anthropic의 소형 모델 Haiku 5.5가 공개 벤치마크에서 GPT-6 Luna를 앞섰다는 주장으로 시작한다. 발표자는 두 모델이 같은 기본 토큰 가격대에 있다는 점 때문에 Luna의 경쟁력이 사라진 것처럼 보일 수 있다고 설명한다.

핵심 질문은 벤치마크 점수의 우위가 실제 사용에서도 더 좋은 선택을 뜻하느냐는 것이다. 발표자는 같은 프롬프트와 같은 실행 환경으로 웹사이트, 게임, 애니메이션, SVG, 긴 문맥 검색을 비교한다. 결과물의 품질뿐 아니라 비용·시간·실패 여부를 살펴보고, 업무에 따라 모델을 선택해야 한다는 결론을 제시한다.

🕒 시간순 섹션별 상세정리

1. Haiku의 등장과 직접 비교의 필요성

• 발표자는 Haiku 5.5를 Anthropic의 가장 작고 저렴하며 빠른 모델로 보여준다. Luna와 같은 가격대에서 공개 벤치마크를 앞섰다는 점이 경쟁 구도 변화의 출발점이다. [00:27]
• 같은 프롬프트와 같은 설정으로 직접 비교한 결과는 벤치마크와 다른 모습을 보였다며, 실제 업무에서 어떤 소형 모델을 선택할지 검토하겠다고 보여준다. [00:49]

2. 공개 벤치마크의 강점과 예외

• Anthropic의 공식 평가에서는 터미널 작업, 컴퓨터 사용, 어려운 코딩 문제, 차트 읽기, 실제 업무 과제에서 Haiku가 Luna를 앞섰다고 보여준다. [01:15]
• Artificial Analysis의 AA Briefcase에서는 Haiku가 GPT-6 Astra와 동률이었으며, 환각 비교에서는 Luna가 Haiku보다 약 두 배 많이 틀린 정보를 생성했다고 보여준다. [01:38]
• 모든 평가가 Haiku의 승리는 아니었다. 자동화와 지식 정확도에서는 Luna가 앞섰고, 긴 문맥 추론과 과학 코딩에서는 두 모델이 비슷했다. [01:50]

3. 점수보다 복잡한 작업당 비용

• 소개된 지능 지수의 최대 설정에서 Haiku는 43점에 작업당 약 21센트, Luna는 38점에 약 7센트였다. 점수 차이에 비해 비용 차이가 컸다는 설명이다. [02:43]
• 영상에서 제시한 Haiku 요금은 10만 토큰까지 입력 100만 토큰당 10센트, 출력 100만 토큰당 50센트이며, 10만 토큰을 넘으면 5배로 상승한다. Luna는 27만 2천 토큰을 넘을 때 2배가 된다고 비교한다. [03:12]
• Haiku의 최대 설정 평가에서는 50단계 중 31단계에 5배 요율이 적용됐다고 보여준다. 장문 작업에서는 기본 단가보다 실제 사용량과 할증 구간이 중요해진다. [03:30]

4. 공통 실행 환경과 낮은 노력의 웹사이트 제작

• 두 모델을 Open Code의 같은 실행 환경에서 비교했다. 이미지에는 Higgsfield CLI를 사용했고, 그 외에는 별도 스킬을 적용하지 않았다고 보여준다. [04:32]
• 낮은 노력 설정의 Haiku 웹사이트는 시각적으로 무난했지만 예약 가능 여부 확인 버튼이 작동하지 않았다. 비용은 3.6센트, 시간은 6분 31초, 실행 단계는 13단계였다. [05:40]
• Luna는 1센트와 5분 30초로 비슷한 사이트를 만들었고 예약 확인 버튼도 작동했다. 발표자는 비용과 속도를 고려해 Luna에 우위를 줬다. [06:37]

5. 최대 노력의 웹사이트 제작과 재시도 비용

• Haiku는 첫 시도에 실패해 다시 시도하도록 요청해야 했다. 약 27분과 1.25~1.26달러가 들었고, Luna는 9분 19초와 4.6센트로 결과물을 만들었다. [07:09]
• Haiku의 최대 설정 결과는 예약 확인 기능과 푸터가 개선됐지만, 발표자는 일부 디자인과 글꼴을 선호하지 않았고 비용 증가만큼의 개선인지 의문을 제기했다. [08:00]
• Luna의 최대 설정 결과도 작동하는 날짜 선택 기능을 제공했다. 미관 평가는 주관적이지만 시간과 비용을 포함하면 Luna가 유리하다고 판단했다. [08:58]

6. 외부 이미지 생성 도구 연결

• 웹사이트에 들어간 이미지는 모델의 기본 API만으로 생성한 것이 아니라 Higgsfield CLI를 연결해 만들었다. 화면의 MCP·CLI 메뉴에서 안내 프롬프트를 복사해 실행 환경에 넣는 과정을 보여준다. [09:37]
• 주로 GPT Images 2.5의 flare 옵션을 사용했다고 드러낸다. Higgsfield의 API와 사용량 기반 결제를 소개하며 이미지가 필요할 때마다 이용할 수 있다고 보여준다. [10:08]
• 세 모델 선택 시 최대 75% 할인과 다른 서비스와의 가격 비교를 언급하고, 이미지·영상 생성에는 API 사용을 권한다. 이 부분은 코딩 모델 비교와 별개의 도구 소개에 해당한다. [10:25]

7. 스노보드 게임에서 드러난 높은 노력의 실패

• 좌우 이동, 장애물, 거리와 점수 집계를 갖춘 간단한 3JS 스노보드 게임을 두 모델 모두 extra high 설정으로 제작하도록 요청했다. [11:06]
• Haiku는 출력 한계를 넘으려다 반복적으로 멈췄다고 보여준다. 발표자는 약 12만 8천 토큰의 출력 제한과 작업을 나누지 못한 동작을 원인으로 지목했고, 여러 실행 후에도 결과물을 얻지 못했다. [11:32]
• Luna는 약 13분, 26단계, 5센트 미만으로 게임을 완성했다. 발표자는 Haiku가 높은 노력 설정에서 과도한 추론과 토큰 소비로 실패할 수 있다고 해석한다. [12:01]

8. 긴 문맥 검색에서의 뚜렷한 역전

• 여덟 개의 스노보드 관련 시를 긴 문서에 넣고 특정 시의 특정 행을 찾아내는 eight needle 테스트를 보여준다. 긴 문맥에서 정보를 정확히 회수하는 능력을 평가하는 과제다. [12:35]
• 중간 노력 설정의 Haiku는 전체 정확도 96%, 총비용 약 5달러, 중앙 처리 시간 13초로 제시됐다. 여러 문맥 길이 구간에서 높은 성적을 보였고, 25만 6천~51만 2천 토큰 구간에서는 10문제 중 9문제를 풀었다. [13:01]
• Luna는 정확도 29%였고 처리 시간도 더 길었다. 3만 2천~6만 4천 토큰 구간에서도 10문제 중 3문제만 맞혀, 발표자는 저렴하다는 이유만으로 선택하기 어렵다고 평가했다. [13:18]

9. HTML 애니메이션과 SVG의 엇갈린 결과

• 중간 노력의 라바 램프 제작에서 Haiku는 약 14분과 6센트 미만, Luna는 2분 34초와 1센트 미만을 사용했다. Luna 결과에도 움직임 문제가 보였지만 발표자는 상대적으로 더 나은 모습이라고 평가했다. [14:13]
• 야간 열차 HTML 애니메이션은 Haiku가 5분 11초와 5센트 미만, Luna가 2분 50초와 1센트 조금 넘는 비용으로 만들었다. 발표자는 Luna가 더 빠르고 저렴하며 미관도 나을 수 있다고 봤다. [14:49]
• 자전거를 탄 펠리컨 SVG에서는 Luna의 결과를 부정적으로 평가했다. 이 과제에서는 Luna가 Haiku보다 시간도 더 오래 걸렸다. [15:03]

10. 지뢰찾기·복셀 제작과 합산 성적

• 지뢰찾기는 두 모델 모두 무난하게 만들었다. 비용은 비슷했고, 발표자는 Haiku의 UI를 더 선호했으며 제작 속도도 Haiku가 더 빨랐다고 설명했다. [15:13]
• 복셀 하늘섬 애니메이션에서는 Haiku가 중간 설정으로 좋은 결과를 만들었지만 최대 설정에서 다시 출력 문제로 실패했다. Luna는 중간 설정에서 약 3분의 1 비용으로 더 빨랐고 최대 설정에서도 결과물을 냈다. [15:58]
• 발표자가 제시한 합산에서 Luna는 거의 7배 저렴하고 37% 빨랐으며 모든 프로젝트를 마쳤다. Haiku는 두 과제에서 막혔지만, 긴 문맥 검색에서는 명확한 우위를 보였다. [16:36]

11. 용도별 선택과 남은 비교 과제

• 발표자는 Haiku의 벤치마크 강점을 인정하면서도 높은 노력 설정의 비용을 경계한다. Luna는 빠른 제작, 대량 처리, 비용에 민감한 업무에 적합하다고 제안한다. [17:05]
• Haiku는 정확도가 중요한 긴 문맥 정보 회수에 고려하되 노력 수준을 신중하게 설정해야 한다고 드러낸다. 이 용도에서는 Sonnet과 비교했을 때도 더 저렴한지 확인해야 한다는 질문을 남긴다. [17:36]
• 최종적으로 어느 모델이 좋은지는 업무마다 다르며 Luna에도 경쟁력 있는 영역이 남아 있다고 정리한다. 이후 Chase AI Plus와 강의 안내를 덧붙이고 영상을 마친다. [18:13]

🧾 결론

• 벤치마크 우위만으로 Haiku가 Luna를 모든 업무에서 대체한다고 판단하기 어렵다. 실제 비교에서는 작업 종류에 따라 우열이 달라졌다.
• 이 영상의 제작 과제에서는 Luna의 비용·속도·완주율이 강점이었다. Haiku도 SVG와 지뢰찾기에서 좋은 결과를 보여 개별 과제의 차이를 확인해야 한다.
• Haiku는 긴 문맥 검색에서 높은 정확도를 보였지만, 높은 노력 설정에서는 비용 증가와 실패 가능성을 함께 점검해야 한다.
• 장문 정확도가 필요한 업무에서는 Haiku와 Luna 비교에 더해 Sonnet과의 비용·성능 비교도 남아 있다.

📈 투자·시사 포인트

• 소형 AI 모델 경쟁은 점수뿐 아니라 작업당 비용, 처리 시간, 실제 완성 여부로 평가해야 한다. 동일한 토큰 단가가 동일한 운영비를 뜻하지 않는다.
• 대량 처리에서는 토큰 소비와 장문 할증이 비용을 크게 바꿀 수 있다. 모델 선택과 노력 수준 설정이 함께 운영 효율을 결정한다.
• 긴 문맥 검색처럼 정확도 차이가 큰 업무에서는 저렴한 호출 비용만으로 모델을 선택하기 어렵다. 필요한 정보를 맞게 회수하는 능력이 우선 기준이 될 수 있다.
• 영상의 결과는 OpenAI의 소형 모델이 특정 업무에서 경쟁력을 유지한다는 시사점을 준다. 다만 이 비교만으로 기업 전체의 경쟁력이나 투자 가치를 판단할 근거는 부족하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 출시 시점, 공식 벤치마크, 요금 구간, 출력 한계는 모두 영상에서 전달한 내용이다. 원본 평가표와 요금 문서가 제공되지 않아 독립적으로 확인된 사실과 구분해야 한다.
• 같은 프롬프트와 Open Code 환경을 사용했다고 설명하지만, 전체 프롬프트·실행 로그·반복 횟수·세부 설정은 제공되지 않는다. 결과를 모든 코딩 업무로 일반화하기 어렵다.
• 긴 문맥 검색의 전체 정확도 96%, 구간별 약 99%, 최장 구간 10문제 중 9문제라는 수치가 함께 등장한다. 표본 수와 집계 방식은 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 업무를 빠른 제작, 대량 처리, 긴 문맥 정보 검색으로 나누고 각 업무의 필수 정확도와 완료 조건을 정한다.
• 동일한 프롬프트·도구 환경에서 Haiku와 Luna를 비교하고 비용, 소요 시간, 완료 여부, 기능 작동 여부를 함께 기록한다.
• 낮음·중간·높음 노력 설정을 비교해 추가 비용과 시간이 실제 품질 개선으로 이어지는지 확인한다.
• 장문 요청의 토큰 사용량과 할증 구간을 확인하고, 실패 후 재시도까지 포함한 총비용을 계산한다.

❓ 열린 질문

• Luna의 낮은 긴 문맥 검색 정확도가 다른 문서 형식이나 질문 구성에서도 반복될까?
• Haiku의 높은 노력 설정 실패는 출력 분할이나 작업 지시 변경으로 얼마나 줄일 수 있을까?
• 장문 정보 회수의 정확도가 중요한 실제 업무에서는 Haiku가 Sonnet보다 경제적일까?