Opus 5.5 + Jev Might Be the Ultimate AI Combo

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Opus 5.5와 Jev의 조합은 단순 분류를 Jev에 맡기고 답변 작성에 Opus를 호출하는 방식으로, 영상의 고객 요청 처리 시연에서 시간과 모델 호출 수를 줄였다.

📌 핵심 요점

1. 역할 분담이 핵심이다. 발표자는 Jev를 빠른 판단에 특화된 비LLM 기술로 소개하며, 긴급도·후속 조치·승인 필요 여부를 분류하고 답변 초안이 필요한 요청은 Opus에 넘긴다.
2. 결제 장애 단일 요청에서는 Jev가 Opus를 호출하지 않고 분류를 끝냈다. 상세 수치는 293ms 대 1.85초로, 이 사례의 처리 시간은 약 84% 줄었다.
3. 동일한 12개 요청을 같은 순서로 처리한 시연에서 Opus 단독은 33.9초·12회 호출, 결합 방식은 19.7초·4회 호출이었다. 처리 시간은 약 42%, Opus 호출 수는 약 67% 감소했다.
4. 답변 생성은 여전히 Opus가 담당한다. 소규모 웹사이트 견적 문의에서는 Jev가 초안 작성 필요성을 판단하고 Opus가 답변을 작성했으며, 발표자는 양쪽 초안이 동일하다고 설명했다.
5. 구축 과정은 Claude Code에 Zapier MCP를 연결하고 Jev와 업무 도구를 추가하는 흐름이다. 후반에는 같은 분류·전달 방식을 개인 비서 Jarvis에 적용한 사례와 무료 프롬프트 자료 접근 방법을 소개한다.

🧩 배경과 문제 정의

이메일, 웹사이트 문의 양식, 고객 불만이 들어오는 지원 업무에서는 요청의 성격과 긴급도를 판단하고 담당 부서로 보내야 한다. 일부 요청은 분류와 작업 등록만으로 끝나지만, 견적 문의처럼 문장 형태의 답변이 필요한 요청도 있다.

발표자는 모든 요청을 Opus 5.5에 맡기는 방식과 Jev가 먼저 분류한 뒤 필요한 경우에만 Opus를 호출하는 방식을 비교한다. 고객 요청 대시보드에서 처리 시간, Claude 호출 수, 개별 처리 경로를 확인한 다음 Claude Code·Zapier MCP 연동과 개인 비서 적용 사례를 설명한다. 아래 수치는 영상에 제시된 시연 결과이며 독립적으로 검증된 벤치마크는 아니다.

🕒 시간순 섹션별 상세정리

1. 조합의 가능성과 비교 실험 설정

• 도입부에서는 Jev와 Opus를 함께 쓰는 쪽이 요청을 더 빨리 처리하는 장면을 보여주고, ‘10배 빠르고 저렴하게 만들 수 있는가’를 검증 질문으로 제시한다. [00:15]
• 고객 요청 12건을 두 경로에 넣고 속도, Claude 호출 수, 요청별 처리 방식을 비교하겠다고 보여준다. [00:36]
• 이메일·웹 문의·고객 불만을 적절한 부서로 보내는 지원 업무를 사례로 삼고, Jev는 빠른 결정에 특화된 비LLM 기술이라고 보여준다. [01:41]

2. 결제 장애 요청으로 단순 분류 비교

• 매장 결제 시스템이 멈춰 고객이 대기 중이라는 요청을 첫 사례로 선택하고 양쪽 처리 경로를 실행한다. [02:38]
• 결합 경로는 약 0.3초, Opus 단독은 약 1.9초가 걸렸다고 제시한다. 이 요청의 핵심은 긴급도와 후속 조치 필요성을 판단하는 것이다. [03:02]
• Jev가 직접 분류해 Opus를 호출하지 않았으며, 상세 수치는 293ms와 1.85초였다. 요청은 긴급한 후속 조치 대상으로, 승인 불필요·최우선 작업으로 처리됐다고 보여준다. [03:52]

3. 12개 요청으로 비교 범위 확대

• 단순 분류 요청이 대량으로 들어오면 Opus API 호출과 처리 시간, 비용을 줄일 수 있다고 주장한다. [04:19]
• 도메인 갱신 영수증, 환불, 빈 문의 양식, 관리자 접근 권한, 사이트 장애 등 다양한 요청 12개를 양쪽에 같은 순서로 배치한다. [04:56]
• 비교를 실행하면 일부 요청은 Jev만으로 끝나고, 다른 요청은 Opus와 함께 처리하므로 소요 시간이 길어진다고 보여준다. [05:24]

4. 전체 처리 시간과 호출 수 확인

• Opus 단독 경로는 12건 처리에 33.9초가 걸렸고 Opus를 12번 호출했다. 결합 경로는 19.7초가 걸렸으며 Opus 호출은 4번이었다. [05:59]
• 결합 경로의 초기 요청들은 Jev만으로 처리됐지만, 일부 요청에서는 Claude로 작업을 넘기는 과정이 표시된다. [06:29]
• 개별 처리 경로의 예로 Opus와 함께 처리한 건은 3.57초, Jev만 처리한 건은 246ms라고 제시한다. 서로 다른 요청의 예시이므로 동일 작업의 직접 비교와는 구분해야 한다. [06:39]

5. 답변 초안이 필요한 요청의 역할 분담

• 배관 업체가 약 5페이지짜리 웹사이트의 비용과 제작 기간을 묻는 사례에서는 실제 답변 작성이 필요하므로 Claude를 사용한다. [07:06]
• Jev는 초안이 필요하고 긴급하지 않으며 승인이 불필요하다고 분류하고, Opus가 초안을 작성한다. 발표자는 양쪽 초안이 동일하다고 보여준다. [07:38]
• 해당 사례는 결합 경로 약 3.5초, 단독 경로 약 5초였다고 보여준다. 이어 온라인 상점 추가·업무시간 외 유지보수 요청과 작업·초안·검토별 필터를 보여준다. [08:20]

6. Claude Code와 업무 도구 연결 준비

• 발표자는 고객 지원 외 업무에도 적용할 수 있다고 주장하며, 무료 프롬프트 자료와 Claude Code를 이용한 구축 안내로 넘어간다. [09:02]
• 데스크톱 앱에서 모델을 선택하는 과정을 설명하지만, 이 대목의 전사에는 앞선 Opus 5.5와 다른 Opus 3.5·Sonnet 3.5 표기가 등장한다. [09:33]
• 이메일·웹 문의·Zendesk 같은 업무 도구에 접근하려면 연결이 필요하다고 보여준다. Jev를 포함한 도구 연결 수단으로 Zapier를 제안한다. [10:59]

7. Zapier MCP에 Jev 추가

• Zapier 계정과 MCP 화면에서 필요한 앱을 검색하고 권한을 지정하는 흐름을 보여준다. Gmail·Slack·Zendesk 등을 연결 예로 든다. [11:52]
• Jev 앱을 추가하고 예·아니요, 선택지, 텍스트 점수 평가 기능을 보여준다. 초기 분류를 이 도구가 담당하도록 구성한다. [12:38]
• Jev 계정의 API 키를 생성해 연결 창에 붙여넣고 계정을 선택한 다음, 도구를 MCP 서버에 추가한다. [13:43]

8. 개인 비서 Jarvis로 적용 범위 확장

• 발표자는 자신이 사용하는 Jarvis에도 Jev를 넣어 질문을 분류한 다음 Opus 5.5를 활용한다고 설명하고, 커뮤니티를 여는 요청을 시연한다. [14:23]
• 분류 항목에는 발화가 끝났는지, Jarvis를 부르는지, 도구 사용이 필요한지, 개인 지식 저장소와 관련된 질문인지 등이 포함된다. [14:41]
• Jev가 질문을 분류하고 전달해 모든 입력을 Opus로 처리하지 않도록 하는 것이 효율 개선의 원리라고 보여준다. [15:12]

9. 연결 활성화와 무료 프롬프트 자료 안내

• Claude Code에서 Zapier 연결을 활성화하고 프롬프트 가이드를 사용하는 과정을 보여준다. 자료는 고객 지원 대시보드 구축과 다른 업무 적용을 돕는 것으로 묶인다. [16:00]
• 설명란의 무료 커뮤니티 링크로 가입한 뒤 강의실과 유튜브 자료 항목에서 프롬프트 묶음을 내려받으라고 안내한다. 제공된 전사에는 실제 링크나 프롬프트 본문이 없다. [16:30]

10. 유료 Jarvis 배포와 마무리

• Jarvis 전체 버전은 유료 커뮤니티의 AI 비서 관련 강의실에서 ZIP 파일로 받을 수 있다고 별도로 안내한다. [16:51]
• 발표자는 이 조합으로 추가 사례를 만들겠다고 밝히고, 앞으로 더 빠르고 효율적이며 저렴하게 구축할 수 있으리라는 기대를 표현한다. [17:12]
• 후속 영상 구독과 댓글 질문을 요청하며 영상을 마친다. [17:25]

🧾 결론

• 이 영상의 핵심은 모든 요청에 대형 모델을 호출하는 대신, 분류와 문장 생성을 나눠 처리하는 설계다.
• 제시된 12건 시연에서는 속도와 호출 수 개선이 관찰됐지만, 도입부의 ‘10배 빠르게’라는 질문을 전체 처리 결과가 입증하지는 않는다. 전체 소요 시간 기준 속도 향상은 약 1.72배다.
• 호출 수 감소는 비용 절감의 가능성을 보여준다. 다만 Jev·Zapier 비용과 실제 토큰 사용량을 합산한 총비용은 제시되지 않았다.

📈 투자·시사 포인트

• 업무 자동화의 효율을 평가할 때 모델 자체 성능과 함께 어떤 요청을 어느 도구로 보내는지 살펴볼 필요가 있다. 이 시연에서는 단순 요청의 Opus 호출을 생략하는 설계가 차이를 만들었다.
• 고객 지원처럼 분류가 반복되는 업무는 적용 후보가 될 수 있다. 다만 실제 효과는 전체 요청 중 분류만으로 끝나는 비중과 답변 생성이 필요한 비중에 따라 달라진다.
• MCP와 Zapier 같은 연결 계층은 분류기를 이메일·문의 양식·지원 도구와 묶는 구현 수단으로 제시된다. 도입 판단에는 연결 비용과 운영 부담도 포함해야 한다.
• 영상은 업무 효율화 사례이며 기업 실적이나 투자 수익률 자료를 제공하지 않는다. 이를 특정 기업의 투자 매력으로 바로 연결할 근거는 부족하다.

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

• 모델명이 일관되지 않는다. 제목과 대부분의 설명은 Opus 5.5이지만, 설치 안내에서는 Opus 3.5와 Sonnet 3.5가 등장한다. 정확한 사용 모델과 가격 비교는 이 전사만으로 확정할 수 없다.
• Jev 관련 표기도 ‘Typeform Jev’, ‘Type Safe Jev’, ‘typesave.ai’로 혼재한다. 실제 서비스명·앱명·접속 주소는 별도 확인이 필요하다.
• 12개 요청의 단일 시연이며 반복 횟수, 네트워크 조건, 캐시, 동시 처리 설정, 프롬프트와 토큰 사용량이 공개되지 않는다. 관찰된 속도 차이를 일반적인 성능 보장으로 해석하기 어렵다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 사용할 모델명, Jev 서비스명, 연동 앱명과 요금표를 확인한다.
• 현재 고객 요청을 분류만 필요한 건, 답변 초안이 필요한 건, 검토·승인이 필요한 건으로 나누고 각 비중을 집계한다.
• 같은 요청과 같은 조건으로 단독 처리와 결합 처리를 반복 비교하고, 처리 시간·모델 호출 수·분류 정확도·답변 품질을 함께 기록한다.
• Opus 토큰 비용뿐 아니라 Jev와 Zapier 사용료까지 합산해 요청당 총비용을 계산한다.

❓ 열린 질문

• 실제 운영 요청에서 Jev만으로 처리할 수 있는 비중은 얼마이며, 그 비중이 줄면 결합 방식의 이점은 얼마나 남을까?
• 긴급도나 승인 필요 여부를 잘못 분류했을 때 이를 발견하고 사람이 검토하는 절차는 어떻게 구성할까?
• Opus가 답변을 작성하는 요청에서도 시간이 줄어든 이유는 무엇이며, 프롬프트·입력량·실행 조건을 맞춰도 같은 결과가 나올까?