You''re Using Jev + Claude Wrong

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Jev와 Claude를 제대로 활용하려면 Jev에는 확률 기반의 반복 판단을, Claude에는 계획과 복잡한 실행을 맡기고 업무에 맞춰 둘의 연결 방식을 설계해야 한다.

📌 핵심 요점

1. 일회성 설정으로 끝내지 말고 규칙을 개선하는 루프를 만들어야 한다. 발표자는 이메일 분류에서 확신도 90% 미만인 사례를 Opus로 넘기고 규칙 수정을 제안하게 해, 기준을 통과하는 이메일 비율이 첫날 43%에서 10일째 81%로 증가했다고 설명한다.
2. 브라우저 자동화는 업무 복잡도에 따라 구조를 달리해야 한다. 단순하고 반복적인 작업은 Opus가 한 번 계획하고 Jev가 실행하는 방식이 유리했지만, 항공편 검색처럼 변화가 많은 작업은 짧은 계획과 실행을 반복하는 루프가 효과적이었다.
3. 컨텍스트 압축에도 Jev를 활용할 수 있다. 소개된 방식은 새 요약문을 생성하는 대신 대화의 관련성을 판별해 필요한 원문을 남기며, 발표자의 비교에서는 처리 시간이 35초에서 0.5초로 줄었지만 다음 대화의 시작 토큰은 증가했다.
4. 도입 전에 기존 시스템을 감사해야 한다. Claude가 스킬·훅·스크립트·자동화를 살펴보고 작은 반복 판단이 발생하는 지점과 실행 빈도를 찾게 한 뒤, 선택지와 확신도 기준을 구체화하는 접근을 제안한다.
5. AIOS의 모델 라우팅에도 Jev를 배치할 수 있다. 요청의 난이도를 분류해 적절한 모델로 보내는 판단을 담당하게 하고, 실제 요약이나 결과물 생성은 선택된 모델이 수행하도록 역할을 나눈다.

🧩 배경과 문제 정의

영상은 Jev를 일반 챗봇처럼 이해하거나 기존 워크플로에 한 번 삽입하는 것으로 도입이 끝난다고 생각하는 문제를 다룬다. 발표자는 Jev가 질문에 문장 대신 확률을 반환하므로, 반복적인 분류와 선택을 빠르고 저렴하게 처리하는 판단 계층으로 활용해야 한다고 설명한다.

고객 문의를 담당 부서로 보내는 예시가 출발점이다. Opus가 '청구 문제이므로 청구팀으로 보내라'는 문장을 생성하는 대신, Jev가 청구팀에 해당할 확률을 반환하고 워크플로가 그 결과를 이용하는 구조다. 이후 이메일 분류, 브라우저 자동화, 컨텍스트 압축, 시스템 감사, AIOS 모델 라우팅을 통해 다섯 가지 활용상의 실수와 개선 방향을 제시한다. 성능과 가격은 영상에서 주장하거나 시연한 수치이며, 제공된 자막에는 외부 검증 자료가 포함되어 있지 않다.

🕒 시간순 섹션별 상세정리

1. Jev를 챗봇으로 이해하는 출발점의 오류

• 발표자는 Jev가 기존 주요 모델보다 200배 빠르고 400배 저렴하다고 소개하면서, 자연어로 대화하고 문장 답변을 받는 챗봇과는 다르다고 강조한다. [00:19]
• Jev는 질문에 대한 답을 확률로 반환하며, 문장 전체를 생성하지 않는 특성이 빠르고 저렴한 처리의 이유라고 보여준다. [01:01]

2. 고객 문의 분류와 반복 판단의 경제성

• 구독 취소 후 다시 청구됐다는 문의를 예로 든다. Opus는 청구팀으로 보내라는 문장을 생성하고, Jev는 청구팀에 해당한다는 92% 확신도를 반환하는 방식으로 대비된다. [01:55]
• 같은 라우팅 판단을 반복하는 업무라면 속도와 비용 차이가 중요하다고 주장하며, 200배의 속도와 400배의 비용 차이, 10억 토큰당 43달러라는 수치를 제시한다. [02:38]
• 작은 반복 판단이 있는 워크플로를 도입 후보로 제안하고, 접근 경로로 Typesafe API와 OpenRouter를 보여준다. Typesafe의 대기 명단 여부는 확정하지 않는다. [03:10]

3. 첫 번째 실수: 일회성 설정으로 끝내기

• 이메일을 후원 제안·에이전시 관련·개인·불필요한 메일 등으로 분류하는 사례에서, 초기 규칙이 최선일 가능성은 낮으므로 지속적인 개선이 필요하다고 보여준다. [04:25]
• 확신도 90% 이상일 때만 Jev가 분류하고 나머지는 Opus로 보내는 조건에서, 기준을 통과한 이메일 비율이 첫날 43%에서 10일째 81%로 늘었다고 제시한다. [05:04]
• 기준 미달 사례를 받은 Opus가 Jev의 규칙서를 검토하고 수정안을 제안하게 하는 것이 개선 루프의 핵심이다. [05:26]

4. 규칙서·해당 없음·섀도 모드의 구성

• 이메일별 호출에는 이메일 원문, 어느 분류로 보낼지 묻는 질문, 각 분류의 의미를 정의한 규칙서가 들어간다. Opus의 수정 대상은 이 규칙서다. [06:21]
• 선택지에 맞지 않는 입력을 억지로 분류하지 않도록 가능한 경우 '해당 없음'을 포함하라고 권한다. 모든 상황에 적용되는 규칙은 아니라고 덧붙인다. [06:45]
• 초기 도입 방법으로 섀도 모드를 제안한다. 예를 들어 10일 동안 Opus의 이메일 분류를 관찰하고 이를 바탕으로 규칙서를 정리한 뒤 Jev의 처리를 시작하는 방식이다. [07:28]

5. 강좌 홍보와 두 번째 실수의 문제 제기

• Chase AI Plus의 Claude Code·Codex 관련 강좌와 AIOS를 소개하는 자체 홍보 구간이 계속된다. [08:01]
• Doom 제어와 브라우저 제어를 연속적인 판단의 집합으로 설명하며, Jev가 특정 브라우저 자동화에서 속도와 비용을 개선할 수 있다고 주장한다. [08:45]
• 브라우저에서의 실수는 Jev를 쓰는 것 자체보다 구현 전략을 업무에 맞게 선택하지 않는 데 있다고 보여준다. [08:54]

6. 복잡한 브라우저 작업과 단순 작업의 전략 비교

• Google Flights 검색에서 Opus가 전체 계획을 한 번 작성하고 Jev가 실행하는 방식은 실패했다. 짧은 계획과 실행을 반복한 방식은 작업을 완료했고, 기존 방식의 36턴 대신 12턴을 사용했다고 제시한다. [09:46]
• 할 일 앱에 작업 세 개를 만들고 차례로 완료하는 단순한 사례에서는 일괄 계획 후 Jev가 실행하는 방식이 가장 빨랐다. 반복 루프는 Opus 단독 방식과 큰 차이가 없었다고 보여준다. [10:27]
• 단순하고 반복적인 작업에는 일괄 계획을, 복잡하고 변화가 많은 작업에는 긴밀한 계획·실행 루프를 권한다. 항공편 검색 비교 비용은 53센트와 19센트로 드러난다. [11:12]

7. 세 번째 실수: 컨텍스트 압축에 활용하지 않기

• 발표자는 컨텍스트가 커질수록 비용과 성능 문제가 생긴다고 설명하며, 일반적인 /compact가 이전 대화를 요약해 새 컨텍스트에 넣는 방식이라고 보여준다. [11:44]
• 600,000토큰 대화의 압축 사례에서 기존 방식은 35초, Jev를 활용한 방식은 0.5초가 걸렸다고 제시한다. [12:15]
• 자신이 만든 Jev Compaction Plus 스킬을 소개하고, 기존 Fast Jev Compaction을 수정한 버전이며 링크를 제공하겠다고 드러낸다. [12:28]

8. 요약 생성 대신 관련 원문을 보존하는 압축

• 소개된 압축은 대화를 줄 단위로 살피며 관련성이 있는 내용을 남기는 방식이다. 제외된 내용도 디스크에 저장되어 필요하면 다시 확인할 수 있다고 보여준다. [13:02]
• 몇 가지 퀴즈와 테스트에서 일반 요약 방식과 비슷한 정확도를 얻었다고 주장하지만, 구체적인 평가 항목이나 결과표는 자막에 제시되지 않는다. [13:26]
• 후속 대화의 시작 컨텍스트는 기존 16,000토큰 대신 26,000토큰으로 늘어났다고 설명하고, 설정과 실행 방법은 GitHub 저장소를 참고하라고 안내한다. [13:48]

9. 네 번째 실수: 기존 시스템을 감사하지 않기

• 자신의 워크플로에 Jev가 들어갈 자리를 찾지 않는 것을 중요한 실수로 지적하고, Claude 안에서 사용할 감사 프롬프트를 보여준다. [14:22]
• 감사는 스킬·훅·스크립트·자동화를 읽고 반복 판단 지점을 찾는 과정이다. 이메일 분류와 AI 뉴스 필터링을 예로 들며, 현재 판단 방식과 실행 빈도도 살펴본다고 보여준다. [14:49]
• 후보를 선택한 뒤에는 분류 선택지와 실행에 필요한 확신도 기준을 더 구체화해야 한다. 발표자는 같은 감사로 자신의 AIOS 개선 지점도 찾았다고 드러낸다. [15:16]

10. 다섯 번째 실수: AIOS 모델 라우팅에 활용하지 않기

• 기존 AIOS는 요청 성격에 따라 모델을 선택했고, 이 분류를 Luna나 Haiku 같은 작은 모델에 맡겼다고 보여준다. 일부 라우팅에는 최대 5초가 걸렸다고 드러낸다. [16:19]
• Jev 도입 후 분류가 0.1초로 줄었다고 설명하지만, 곧이어 5초에서 3초로 줄었다는 표현도 나온다. 라우팅 규칙은 기본 Obsidian 작업, AI 뉴스 요약, 새로운 프로젝트·결과물 생성의 세 단계로 나눈다. [16:58]
• Jev에는 무엇을 실행하고 어느 모델이 맡을지 결정하는 역할을, Claude나 OpenAI 모델에는 실제 작업 수행을 맡기는 구분을 강조한다. [17:33]

11. 역할 구분을 정리하고 적용 후보를 찾기

• 다섯 가지 실수의 근본 원인을 Jev의 역할에 대한 오해로 정리한다. 무엇을 할 수 있는지 이해하면 AI 워크플로 안에서의 배치가 명확해진다고 보여준다. [17:58]
• 일상 업무의 적용 후보가 불분명하면 앞서 소개한 감사 프롬프트를 활용하라고 권한다. 저비용 실험의 장점을 강조하면서 말미에는 10억 토큰당 42달러라고 언급한다. [18:31]
• Chase AI Plus의 강좌와 AIOS를 다시 안내하며 영상을 마무리한다. [18:40]

🧾 결론

• 영상에서 설명하는 Jev의 핵심은 자연어 답변 생성보다 확률 기반의 분류와 선택이다. 적용 대상을 찾으려면 업무 안의 작은 반복 판단부터 살펴봐야 한다.
• 출력 확률만으로 품질이 보장되지는 않는다. 업무에 맞는 규칙, 확신도 기준, 불확실한 사례를 넘길 경로가 함께 필요하다.
• 계획과 실행을 연결하는 방식에는 단일 정답이 없다. 작업의 단순성·변동성에 따라 일괄 계획과 반복 루프를 비교해야 한다.
• 영상의 성능 수치는 발표자의 주장과 사례다. 실제 도입 효과는 자신의 업무에서 성공률·지연·전체 비용을 함께 측정해야 판단할 수 있다.

📈 투자·시사 포인트

• 반복 분류가 많은 업무에서는 판단을 저렴한 모델로 분리하는 것이 비용 절감의 후보가 된다. 영상의 이메일 사례는 더 많은 요청을 Jev에서 처리하면서 Opus로 넘기는 비중을 낮추는 구조를 보여준다.
• 자동화의 경제성은 모델의 단가뿐 아니라 연결 구조에도 좌우된다. 항공편 검색 사례에서는 반복 루프가 36턴을 12턴으로, 비용을 53센트에서 19센트로 줄였다고 제시된다.
• 컨텍스트 압축은 당장의 처리 속도와 이후 토큰 비용 사이의 교환 관계를 만든다. 소개된 방식은 압축이 빨라지는 대신 다음 대화가 16,000토큰에서 26,000토큰으로 시작했다.
• 기존 스킬과 자동화를 감사하면 새로운 시스템을 만들기 전에 교체 가능한 판단 지점을 찾을 수 있다. 영상은 이메일 분류·AI 뉴스 필터링·모델 라우팅을 그 후보로 제시한다.

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

• 200배 빠르고 400배 저렴하다는 비교에는 기준 모델, 입력 조건, 측정 방법이 충분히 제시되지 않는다. 토큰 가격도 초반에는 10억 토큰당 43달러, 말미에는 42달러로 언급된다.
• 이메일의 43%→81%는 확신도 90% 기준을 통과한 처리 비율이다. 실제 정답률이나 출력 확률의 보정 수준이 같은 비율로 개선됐다는 근거는 제시되지 않는다.
• 브라우저 자동화 결과는 항공편 검색과 할 일 앱 사례에 한정된다. 반복 실험 횟수와 실행 환경이 설명되지 않아 다른 웹사이트에서도 같은 우위가 나타나는지는 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 기존 스킬·훅·스크립트·자동화에서 이메일 분류, 뉴스 필터링, 모델 선택처럼 반복 판단이 발생하는 지점과 실행 빈도를 목록화한다.
• 후보 업무 하나를 골라 입력, 질문, 선택지별 정의를 담은 규칙서를 작성하고, 적합한 선택지가 없을 때의 '해당 없음' 항목을 검토한다.
• 업무에 맞는 확신도 기준과 Opus 등으로 넘길 경로를 정하고, 기준 통과 비율과 실제 분류 정확도를 따로 기록한다.
• 불확실한 사례를 검토하는 모델이 규칙 수정안을 제안하도록 연결하거나, 기존 모델의 처리를 관찰하는 섀도 모드로 초기 규칙을 준비한다.

❓ 열린 질문

• 각 업무에서 확신도 기준을 어디에 두어야 자동 처리 비율을 높이면서 오분류를 감당할 수 있는가?
• Opus가 제안한 규칙 수정이 실제 품질을 높였는지 어떤 검증으로 확인할 수 있는가?
• 일괄 계획으로 충분한 브라우저 작업과 반복 루프가 필요한 작업을 어떤 기준으로 구분할 수 있는가?