선택 전문 AI인 Jev와 Haiku 5.5의 대결 결과는?

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

고객 문의 50건을 100회 반복한 비교에서 Haiku 5.5는 정확도 94.5%로 Jev의 91.3%를 앞섰고, Jev는 개별 응답 시간과 비용에서 유리했다.

📌 핵심 요점

1. Jev는 주어진 상황과 선택지를 바탕으로 빠르게 판단하는 AI다. 일반 LLM도 구조화된 선택을 수행할 수 있어, 실제 차별점은 정확도·속도·비용으로 검증해야 한다.
2. 실험은 가상 쇼핑몰 문의 50건을 긴급·일반으로 분류하는 방식이다. 초기에는 정답 기준이 확정되지 않았으나, 사용자가 전체 문항을 직접 라벨링한 뒤 비교를 다시 진행했다.
3. 최종 비교에서는 키워드 규칙을 제외하고 Haiku 5.5와 Jev를 각각 100회 실행했다. 평균 정확도는 Haiku 94.5%, Jev 91.3%로, Haiku가 3.2%포인트 높았다.
4. 평균 응답 시간은 Haiku 1,020, Jev 185로 제시됐지만 단위는 명확하지 않다. Haiku의 비용은 Jev의 약 두 배였으며, 전체 반복 실험의 진행 시간에는 큰 차이가 없었다는 평가가 나왔다.
5. 공손하게 작성된 오배송 문의에서 Jev가 긴급성을 놓친 사례가 나타났다. 표현 방식과 실제 문제의 심각성을 구분하는 맥락 판단이 중요하며, 선택 전문 모델이라는 설명만으로 더 높은 정확도를 기대하기는 어렵다.

🧩 배경과 문제 정의

• Jev는 글 생성보다 주어진 상황에서의 선택에 특화된 AI다. 바이브 코딩과 실제 서비스에서 어떤 판단을 맡길 수 있는지가 핵심 문제다.
• 일반 LLM이나 키워드 규칙도 분류와 선택을 처리할 수 있으므로, Jev의 속도·비용상 이점과 판단 정확도를 함께 비교해야 한다.
• 쇼핑몰 고객 문의에서 긴급 대응이 필요한 요청을 먼저 분류하는 실험을 구상한다. 처리 범위에서는 조사와 실험 설계, 구현 계획까지 진행되며 Jev와 Haiku 5.5의 비교 결과는 나오지 않는다.

🕒 시간순 섹션별 상세정리

1. Jev의 개념과 바이브 코딩 활용처를 함께 탐색한다

• 공식 사이트와 문서를 조금 살펴봤지만 직접 사용한 경험은 부족한 상태에서, Jev가 바이브 코더에게 어떤 도움이 되는지 확인하는 것을 출발점으로 삼는다. [01:42]
• 개념 조사부터 실무 적용까지 연결하기 위해 그록봇에 탐사형 영상 제작 파이프라인을 구성하고, 질문과 답변으로 조사 목적과 사전 지식을 정리한다. [02:41]

2. 브라우저 조사와 코딩 작업을 CLI로 연결한다

• ChatGPT는 개념과 검증할 의문을, Gemini는 공식 문서·요금·성능 주장에 관한 근거와 반례를 조사하도록 역할을 나눈다. [04:15]
• 그록봇은 허브 역할을 맡아 어사이드 브라우저를 제어하고 조사 프롬프트를 전달한다. 브라우저의 MCP와 CLI 지원이 외부 에이전트의 제어를 가능하게 한다. [04:48]

3. Jev는 문장 생성보다 빠른 선택에 특화된다

• Jev의 목적은 글을 작성하는 것이 아니라 특정 상황에서 가장 적절한 선택을 빠르게 반환하는 데 있다. [07:10]
• 이러한 역할을 『생각에 관한 생각』의 시스템 1, 즉 직관적 사고에 비유한다. 상황과 선택지가 주어졌을 때 신속하게 판단하는 기능에 초점을 맞춘다. [07:26]

4. 고객 문의를 선택·점수·참거짓 판단으로 나눈다

• 중복 결제 문의라면 결제 내역을 확인하고 환불 담당 부서로 연결하는 처리가 필요하다. AI가 판단하더라도 실제 행동은 프로그램이 통제한다. [08:28]
• 판단은 정해진 후보 중 담당 업무를 고르는 선택, 긴급성을 평가하는 점수, 승인 필요 여부와 같은 예·아니오 판단으로 구분한다. [09:13]

5. 사용자에게 묻는 도구와 모델의 자동 판단은 주체가 다르다

• Claude Code의 사용자 질문 도구는 선택지를 제공하더라도 최종 판단을 사용자에게 맡긴다. [09:43]
• Jev는 제공된 자료와 상황을 근거로 모델이 직접 판단한다. 환불 업무와 기술 지원 업무 중 어디에 해당하는지 사용자에게 다시 묻지 않고 선택 결과를 반환하는 방식이다. [10:41]

6. 조건문과 일반 LLM도 대안이지만 복잡성과 속도를 따져야 한다

• 금액이 100만 원을 넘으면 관리자 승인을 받는 식의 명확한 규칙은 조건문으로 구현할 수 있다. 다만 판단 상황이 다양해지면 분기가 늘고 시스템이 복잡해질 수 있다. [11:33]
• 자료와 맥락을 활용해야 하는 판단에는 일반 LLM도 사용할 수 있지만, 빠른 응답이 필요한 상황에서는 속도가 문제가 될 수 있다. [12:05]

7. ‘환각 없음’이라는 홍보와 판단 부품으로서의 가치를 구분한다

• 타입세이프 AI는 주어진 상황에서 선택만 한다는 이유로 Jev를 ‘제로 할루시네이션’이라고 홍보한다. 이 시점에서는 해당 문구가 업체의 주장으로 드러난다. [13:00]
• 조사 답변에 등장한 양자 중첩 비유는 아키텍처 이해를 돕기 위한 표현으로 받아들이면서도 과도한 비유일 수 있다고 경계한다. [13:13]

8. 공식 기능과 비용 절감 사례에도 적용 한계가 있다

• 공식 자료를 확인한 조사에서는 한 단계에서 최대 255개 선택지를 처리할 수 있고, 비구조화된 상태 정보와 타입이 지정된 질문을 입력으로 받는다고 정리한다. [14:30]
• 공식 홈페이지의 도입 사례에는 선별 비용을 88% 절감했다는 보고가 있다. 이는 해당 사례의 수치이며, 이번 실험에서 확인한 결과는 아니다. [15:28]

9. API 사용에는 결제와 키 보관 준비가 필요하다

• 직접 확인한 화면에서는 신용카드 정보를 등록하지 않으면 API 키를 만들 수 없는 것으로 보인다. 과거 무료 크레딧 제공 여부와 현재 정책에 대해서는 추정 수준을 유지한다. [17:05]
• 개인적으로 5달러를 결제한 뒤 설치와 몇 차례 호출을 시험했고, 표시된 사용액은 약 0.01달러였다. 이 경험을 근거로 소규모 테스트의 비용 부담은 크지 않을 것으로 본다. [17:28]

10. 낮은 비용과 속도를 정확성 보장으로 해석해서는 안 된다

• 조사 결과에 정확도 67.8%가 제시되며, Jev를 정확성이 보장된 모델로 받아들이지 않는다. 실패 사례가 있다는 점에서 ‘환각 없음’도 홍보 문구로 판단한다. [18:21]
• 활용 후보로 위험한 실행 전 확인과 고객 문의 라우팅을 검토한다. 문의를 여섯 업무로 나누고, 선택지 순서나 한국어·영어 입력에 따라 결과가 흔들리는지도 시험할 수 있다. [19:06]

11. 긴급 고객 문의를 먼저 골라내는 접수함으로 범위를 정한다

• 실제 활용에 가까운 주제를 찾기 위해 유튜브 사례를 조사하고, 바이브 코딩에 적용할 수 있는 실험 후보를 요청한다. [20:02]
• 고객 문의를 자동 분류하고 필요한 답변만 작성하는 AI 접수함을 선택한다. 여기에 클레임·반품·환불 등 긴급 대응이 필요한 상황을 우선 처리하는 방향을 더한다. [21:38]

12. 가상 문의 50건으로 세 가지 분류 방식을 비교한다

• 가상 쇼핑몰 문의함 웹페이지에 약 50건의 고객 문의를 만들고, 환불·배송 사고·불만과 일반 문의를 섞어 두 범주로 분류한다. [23:24]
• 쉽게 구분되는 문의뿐 아니라 애매한 질문도 포함해 Jev의 판단 정확도를 측정할 수 있도록 한다. [24:04]

13. API 연결 확인과 계획 승인을 구현의 선행 단계로 둔다

• Claude Code에 웹페이지 구현뿐 아니라 Jev 연결도 맡긴다. 설정 파일에 API 키를 넣고 실제 연결 테스트를 거친 뒤 프로젝트를 진행하도록 요구한다. [25:11]
• 오르카에 새 프로젝트가 생성되고 Claude Code가 실행된다. 이 세션의 모델은 Opus 5.5이며 추론 설정은 미디엄이다. [26:25]

14. 비교용 일반 LLM으로 Haiku 5.5를 선택한다

• 구현 대상은 긴급·일반 문의가 섞인 약 50건의 데이터를 갖춘 작은 로컬 웹이다. [27:55]
• 분류 방식은 키워드 규칙, 일반 LLM, Jev의 세 가지다. 일반 LLM 비교군에는 Haiku 5.5를 API로 연결하고, Jev도 별도의 API 키로 연결한다. [28:13]

15. 여러 도구를 연결하는 구성은 필수 조건이 아니다

• 그록봇을 중심으로 브라우저 조사와 오르카의 코딩 작업을 연결하는 절차가 꼭 필요한지 검토한다. 여러 도구를 거치는 구성 자체가 별도의 선택 사항이다. [29:20]
• 그록봇을 사용하지 않고 Claude Code에서 바로 실행하는 방식도 가능하다고 인정한다. [29:53]

16. 여러 에이전트를 통솔할 단일 작업 창구

• 사용자는 주력 에이전트 하나에 명령하고, 그 에이전트가 다른 에이전트를 팀원처럼 부리는 작업 방식이 가까워질 것으로 전망한다. 핵심 선택은 사용자와 직접 대면할 주력 에이전트를 무엇으로 정할지에 있다. [30:04]
• 그록의 1년 구독과 남아 있는 토큰, 사용자들의 평가를 고려해 그록봇을 우선 선택한다. 코딩 능력에는 아쉬움이 있지만 에이전트 간 자동화와 다른 에이전트를 부리는 역할에는 가능성이 있다는 판단이다. [31:21]

17. 승인 대기까지 처리해야 하는 자동화

• 클로드 코드가 선택지 입력을 기다리는데도 그록봇이 대응하지 못한다. 사용자 개입을 줄이려면 플랜 모드의 입력 대기 상태를 감지하고 필요한 선택을 처리해야 한다. [32:11]
• 그록봇에 현재 대기를 처리하고 이후에도 상황을 모니터링하도록 요구한다. 여러 에이전트가 PC에서 활용될수록 사용자가 각각을 다루기 어려워지므로, 주력 에이전트의 통제 역할이 중요해진다. [32:56]

18. 고객 문의 분류와 모델 선택으로 확장하는 Jev 실험

• 첫 실험은 고객 문의를 분류하고 필요한 답변만 작성하는 AI 접수함이다. 영수증과 업무 문서를 구분하는 이미지 분류함도 후보지만, 첫 실험과 성격이 비슷해 별도 구현의 필요성은 낮게 본다. [33:47]
• 멀티 에이전트 개발에서는 백엔드·프런트엔드·테스트 작업에 어떤 모델을 연결할지도 선택 문제다. Jev가 작업별로 적합한 모델을 판단하는 용도로 쓰일 수 있다는 가설을 세운다. [34:29]

19. 국내외 활용 사례 수집과 지식 관리 자동화

• Jev의 실제 업무 활용 사례를 국내외에서 수집하고, 유튜브뿐 아니라 X와 레딧 등으로 조사 범위를 넓힌다. 수집한 정보는 사용 중인 지식 관리에 등록하도록 요청한다. [35:35]
• 어사이드에는 조사 결과를 지식 관리의 메모로 저장하는 스킬이 설정돼 있다. 저장할 라벨을 지정하면 해당 라벨로 자동 등록되는 방식이다. [36:32]

20. 코딩·조사와 병행하는 아키텍처 그림 생성

• 클로드 코드가 앱을 구현하고 어사이드가 사례를 조사하는 동안, 그록봇을 통해 ChatGPT에 Jev 아키텍처를 그림 한 장으로 만들도록 추가 작업을 맡긴다. [37:10]
• 그록봇이 어사이드 브라우저에서 ChatGPT에 접속하고 아키텍처 그림을 요청하는 프롬프트를 전달한다. 사용자 명령을 받은 주력 에이전트가 다른 서비스에 작업을 넘기는 과정이 실제로 작동한다. [39:09]

21. 완성된 앱의 테스트 위임과 API 연결

• 앱 구현 이후의 테스트도 그록봇에 맡긴다. 어사이드 브라우저와 개발 도구 양쪽을 CLI로 제어할 수 있다는 점을 바탕으로, 사용자가 직접 입력하지 않고 세 가지 방식의 실험을 진행하려 한다. [39:27]
• Jev 연결은 공식 API 문서와 대조해 구현됐지만, 비교 실험에는 정답 확정과 API 키 입력이 추가로 필요하다. 필요한 키는 앤트로픽과 타입세이프 AI의 API 키다. [40:28]

22. 구조화된 판단 결과와 브라우저 시연 요구

• 생성된 아키텍처 그림은 쇼핑몰 고객 문의를 질문과 선택지로 구조화하고, 문의의 중요도 등을 판단하는 흐름을 담는다. Jev의 반환값은 점수와 정답에 얼마나 가까운지에 관한 정보를 제공하는 것으로 드러난다. [42:01]
• 비교 모델은 하이쿠 5.5로 지정한다. 테스트는 어사이드 브라우저에서 실제 작동 모습을 보여주고, 사용자는 클릭 없이 관찰할 수 있도록 진행하는 조건을 붙인다. [43:07]

23. 활용 사례에서 단체 대화의 문제 추출로 확장

• 조사한 국내외 실무 사례가 지식 관리의 ‘바이브 기획’ 라벨에 저장된다. 사례에는 메시지 판단 계층 교체, 게임 피드백의 여러 신호 분해, 한국어·의료 관련 시험, 가상 고객 환불 판단, 요청별 모델 경로 선택 등이 포함된다. [43:50]
• 운영 중인 단체 대화방의 기록에서 일반 대화를 제외하고, 사람들이 궁금해하거나 해결하려는 문제만 분류해 저장하는 활용안을 구상한다. [44:49]

24. 첫 비교 결과와 정답 기준의 부재

• 약 50개의 가상 질문을 대상으로 키워드 규칙, 일반 LLM, Jev를 비교한다. 정확도를 평가하려면 각 문의가 긴급인지 아닌지에 대한 인간의 모범 분류가 먼저 필요하다. [46:13]
• 초기 결과는 키워드 규칙 58%, 일반 LLM 50건 중 49건으로 98%, Jev 50건 중 47건으로 94%다. 다만 사용자가 문항별 기준을 확정하지 않은 상태이므로, 이 수치만으로 객관적인 우열을 확정하기 어렵다. [47:48]

25. 긴급도 기준표와 앱 내부 라벨링 화면

• 긴급에 해당하는 조건을 문장으로 명확하게 정리한 기준표가 필요하다. 사용자가 긴급과 일반을 구분하는 원칙을 먼저 고정해야 한다. [49:44]
• 정답 입력 방식은 엑셀보다 실험 앱 내부에 라벨링 화면을 만드는 쪽을 선택한다. 사용자가 직접 기준을 설정할 수 있도록 클로드 코드에 구현을 맡긴다. [50:03]

26. 초기 실험에서 나타난 정확도·속도·비용의 교환관계

• 사용자 기준을 확정하기 전의 결과는 키워드 29건, 하이쿠 49건, Jev 47건 정답이다. 하이쿠의 정확도가 더 높으므로 Jev의 실익을 판단하려면 비용과 처리 시간도 비교해야 한다. [51:14]
• 처리 시간에는 약 다섯 배의 차이가 있다는 결과가 나오며, Jev가 더 빠른 쪽으로 평가된다. 다만 한 번 실행한 결과여서 네트워크 상태에 따라 달라질 수 있다는 한계가 붙는다. [52:33]

27. 사용자 판단으로 50건의 정답 라벨 확정

• 직접 라벨링하면서 상품 선택 고민과 재입고 문의는 일반으로, 파손·환불·열흘간 배송 지연·이중 결제는 긴급으로 분류한다. 사용자가 중요하게 보는 문제 상황이 정답 기준에 반영된다. [53:45]
• 50건 전체의 라벨을 확정하고 키워드 규칙, 일반 LLM, Jev의 세 방식을 다시 실험하도록 요청한다. 이후 비교는 사용자가 설정한 정답과의 일치 여부를 기준으로 삼는다. [54:35]

28. 재실험 실행과 반복 측정의 필요성

• 한 번의 실험만으로 신뢰도를 판단하기 어렵다고 보고, 이번 재실험 이후에는 각 방식을 열 번 정도 실행해 평균 결과를 비교할 계획을 세운다. 이 시점에는 반복 실험 결과가 확보되지 않았다. [55:03]
• 도중에 실험이 멈춰 새 탭을 생성한 뒤 다시 진행한다. 일반 LLM과 Jev의 API 호출을 마치고, 키워드 규칙을 포함한 세 방식의 결과를 확인한다. [55:54]

29. 사용자 기준과 모델 판단의 차이 및 재실험 결과

• 사용자는 열흘간 배송되지 않은 문의를 긴급으로 분류했지만 하이쿠와 Jev는 모두 일반으로 판단한다. 검은색 대신 흰색 상품이 도착한 문의도 사용자의 긴급 판단과 다른 결과가 나타난다. [57:18]
• 적립금 미지급 문의는 사용자가 문제 상황으로 보지만, 세 방식 모두 일반으로 판단한다. 사용자에게 중요한 불편과 모델이 적용하는 긴급도 기준 사이에 차이가 드러난다. [57:49]

30. 작은 절대 비용과 기존 구독을 고려한 도입 판단

• 하이쿠의 비용이 약 두 배여도 절대 금액이 매우 작아, 비용 차이가 Jev를 추가로 선택할 충분한 이유인지는 불확실하다. 현재 정확도 결과만 보면 하이쿠를 사용하는 쪽에 무게를 둔다. [58:29]
• 월 100달러 이상 구독에 구독액에 해당하는 API 크레딧이 제공된다는 설명을 전제로, 기존 크레딧을 판단 작업에 활용하는 방안을 고려한다. 크레딧을 모두 쓰기도 쉽지 않을 것이라는 예상 때문에 Jev 추가 결제의 필요성에 의문을 제기한다. [58:53]

31. 정확도·시간·비용을 함께 비교하는 반복 실험

• 초기 결과에서는 하이쿠의 응답이 상대적으로 느려, 정확도뿐 아니라 처리 시간도 비교할 필요가 생겼다. [1:00:22]
• 키워드 규칙 방식은 비교 대상에서 제외하고, 50개 문항을 하이쿠와 Jev에 각각 100회씩 실행해 평균 정답률·소요 시간·비용을 산출하기로 했다. [1:01:32]

32. 공손한 오배송 문의에서 드러난 맥락 판단의 약점

• 검은색 제품을 주문했는데 흰색 제품이 도착한 사례에서, 사용자가 공손하게 표현했더라도 오배송 자체는 신속한 처리가 필요한 문제다. LLM은 긴급하다고 판단했지만 Jev는 이를 제대로 판별하지 못했다. [1:02:21]
• 이 오류는 표현의 공손함과 실제 상황의 심각성을 구분하고 문맥을 파악하는 능력이 중요하다는 근거가 됐다. 다만 원인에 대한 설명은 실험자의 해석이다. [1:02:33]

33. 개별 응답 속도와 반복 실험 진행 속도의 차이

• 비용 상한을 해제하고 100회까지 실험을 계속했다. 첫 회차에서 하이쿠는 50개 중 47개를 맞히는 데 13.3초, Jev는 46개를 맞히는 데 2.4초가 걸렸다. 정답 한 개 차이만으로 우열을 정하기는 어렵지만, 이 회차의 처리 시간은 Jev가 짧았다. [1:04:05]
• 중간 집계에서는 하이쿠 55회, Jev 56회로 완료 횟수 차이가 작았다. 당시 평균 정확도는 각각 94.6%와 91.3%였으며, 개별 응답이 빠른 Jev가 전체 반복 진행에서도 크게 앞서지는 않았다. [1:05:25]

34. 최종 정확도는 하이쿠가 높고 비용은 Jev가 낮았다

• 최종 정확도는 하이쿠 94.5%, Jev 91.3%였다. 평균 응답 시간 수치는 각각 1,020과 185로 제시돼 Jev가 더 짧았지만, 해당 수치의 단위는 자막에서 명확하지 않다. [1:06:57]
• 하이쿠의 비용은 Jev의 약 두 배였지만, 이번 실험에서 지출한 절대 금액은 매우 작다는 평가가 나왔다. [1:07:10]

35. 특화 여부보다 해결할 문제에 맞는 선택이 중요하다

• 선택 전문 모델인 Jev가 이번 정확도 비교에서 뒤졌지만, 50개 문항을 100회 반복한 결과만으로 쓸모를 단정하기는 어렵다. 실제 서비스에서는 정확도·속도·비용·일관성을 함께 따져야 한다. [1:08:45]
• 특화 AI가 반드시 더 뛰어난 것은 아니며, 해결하려는 문제가 무엇인지에 따라 적합한 AI를 고르는 일이 중요하다는 결론이다. [1:09:08]

🧾 결론

• 이번 문의 분류 실험의 정답 일치도는 Haiku 5.5가 더 높았다. 실험자도 정확도와 작은 절대 비용을 고려해 Haiku 사용에 무게를 뒀다.
• Jev는 개별 응답 시간과 호출 비용에서 이점을 보였지만, 이번 규모에서는 그 차이가 추가 도입을 충분히 정당화하는지 불확실했다.
• 적합한 모델은 해결할 문제에 따라 달라진다. 정확도·속도·비용·일관성을 함께 비교해야 하며, 이번 결과만으로 Jev의 모든 활용 가능성을 판단할 수는 없다.

📈 투자·시사 포인트

• 특화 AI의 사업적 가치는 전문성을 내세우는 설명보다 실제 업무에서 검증된 성능과 비용 절감 효과에 달려 있다.
• 호출 비용이 절반이어도 절대 지출이 작으면 도입 유인이 약할 수 있다. 기존에 사용하는 모델과 크레딧까지 포함한 이용 조건을 살펴야 한다.
• 개별 응답이 빨라도 전체 작업 완료 시간이 같은 비율로 줄어들지는 않았다. 서비스 적용에서는 호출 단위 성능과 전체 처리 시간을 함께 측정해야 한다.
• 고객 문의 분류에서는 사용자가 중요하게 여기는 문제를 정답 기준에 반영해야 한다. 긴급도 기준을 명확히 정하고 실제 오분류를 검토하는 과정이 모델 선택의 핵심이다.

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

• 동일한 가상 문의 50건을 반복한 결과이므로, 다양한 실제 고객 문의에서도 같은 정확도 차이가 유지되는지는 확인되지 않았다.
• 최종 평균 응답 시간으로 제시된 1,020과 185의 단위가 명확하지 않다. 이를 밀리초 등 특정 단위로 단정해서는 안 된다.
• 공손한 표현 때문에 Jev가 오배송의 긴급성을 놓쳤다는 설명은 실험자의 해석이다. 해당 사례만으로 오류 원인을 확정하기는 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 긴급·일반을 구분하는 기준표를 작성하고, 모델 실행 전에 사람이 정답 라벨을 확정한다.
• 오배송·장기 배송 지연·이중 결제처럼 중요한 문제와 공손하거나 애매한 표현을 포함해 실제 업무용 평가 데이터를 구성한다.
• 동일한 데이터와 기준으로 두 모델을 반복 실행하고, 정확도·응답 시간·비용·판단 일관성을 함께 기록한다.
• 응답 시간의 단위를 확인하고, 개별 호출 시간과 전체 작업 완료 시간을 구분해 비교한다.

❓ 열린 질문

• 긴급도 기준을 모델 입력에 더 명확히 제공하면 사용자 판단과 모델 판단의 차이가 얼마나 줄어들까?
• 문의 종류와 표현을 다양하게 바꿔도 Haiku의 정확도 우위와 Jev의 응답 시간·비용상 이점이 유지될까?
• 호출량이나 응답 시간 요구가 어느 정도일 때 Jev의 낮은 비용과 빠른 응답이 도입을 결정할 만큼 중요해질까?