Jev Won''t Replace Claude Code — It''s a New Species of Model

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Jev는 Claude Code를 대체하는 모델이 아니라, 기존 에이전트 옆에서 저렴하고 빠른 판단을 맡는 새로운 종류의 모델이라는 것이 영상의 핵심 주장이다.

📌 핵심 요점

1. Jev의 역할은 판단이다. JSON으로 질문과 기준을 전달하면 답과 신뢰도를 반환하고, 다음 행동은 개발자가 작성한 코드가 결정한다.
2. 모든 문제에 전체 에이전트를 투입할 필요는 없다. 발표자는 결정적 코드, 빠른 판단 모델, 장시간 작업하는 에이전트를 각자 잘하는 일에 배치하자고 제안한다.
3. 파일 탐색은 대표적인 적용 지점이다. Jev가 파일의 관련성이나 역할을 먼저 판별하면 에이전트는 필요한 파일만 읽을 수 있으며, 실제로 수정할 파일은 직접 읽어야 한다.
4. 저렴한 판단을 비싼 호출 앞에 배치한다. 프롬프트 인젝션 탐지, 티켓 우선순위 분류, 코드 리뷰 점수화, 모델·에이전트 선택이 영상의 주요 예시다.
5. 개발자의 전문성은 판단 기준과 시스템 설계에 남는다. JSON에 담는 기준, 코드에 두는 가중치, 작업 배분 방식이 중요하며, 실제 효과는 자신의 저장소에서 비교해야 한다.

🧩 배경과 문제 정의

발표자는 프롬프트 하나에서 에이전트, 하위 에이전트, 팀, 군집으로 확장해 온 흐름이 결국 같은 종류의 큰 모델을 더 많이 사용하는 방식이었다고 본다. 문제는 단순한 통과 여부나 파일 관련성처럼 좁은 질문에도 전체 에이전트를 동원한다는 점이다.

영상이 제안하는 대안은 코드와 에이전트 사이에 빠른 판단 모델을 배치하는 것이다. Jev가 JSON으로 받은 질문에 답과 신뢰도를 반환하면, 코드가 그 결과를 바탕으로 다음 행동을 결정한다. 발표자는 이를 Claude Code 같은 도구의 대체가 아니라 기존 개발 스택에 더하는 역할로 설명한다.

설명은 파일 탐색, 작업 검증, 인젝션 탐지, 티켓 분류, 모델 라우팅 데모를 중심으로 진행된다. 후반에는 Apple 플랫폼 앱을 만드는 솔로 개발자의 관점과 Crafters Lab 소개를 연결하며, 모델보다 개발 시스템의 설계와 소유가 중요하다는 메시지로 마무리한다.

🕒 시간순 섹션별 상세정리

1. 새로운 종류의 모델과 역할 분담

• Jev를 기존 에이전트에 더하는 판단 모델로 보여준다. JSON으로 질문하면 답과 신뢰도를 돌려주며, 이후 행동은 코드가 결정하는 구조라고 보여준다. [00:41]
• 에이전트 수를 늘리는 흐름만으로 모든 일을 해결하려는 접근을 비판한다. 단순한 예·아니요 질문에는 빠른 판단 모델을, 긴 작업에는 전체 에이전트를 쓰는 역할 분담을 제안한다. [01:22]
• 하네스가 작업 변화와 문맥 경계를 확인하는 데모, 테스트 실패를 분류하고 수정 후 위험과 통과 여부를 다시 묻는 데모를 보여준다. 장시간 실행과 UI 조작에는 적합하지 않다고 선을 긋고, 다음 전문 모델은 작업 검증을 맡을 수 있다고 예상한다. [02:48]

2. 파일을 읽기 전에 질문하는 도구

• 발표자는 iOS 개발 경력과 Apple 플랫폼 앱을 에이전트로 만드는 채널의 방향을 보여준다. Crafters Lab을 안내한 뒤, Jev는 코드와 에이전트 옆에 연결하는 도구라는 설명을 반복한다. [03:56]
• 파일 경로와 질문을 받는 도구를 통해 토큰 검증 여부, 실제 자격 증명 포함 여부, 파일의 역할을 판별한다. 여러 파일에 같은 질문을 병렬로 던져 먼저 걸러내고, 에이전트가 해당하는 파일만 읽는 방식도 보여준다. [04:55]
• 수정하려는 파일은 직접 읽어야 하지만, 관련성 확인 같은 탐색은 질문으로 처리할 수 있다고 구분한다. 신뢰하려면 자신의 저장소에서 두 방식을 나란히 비교해야 하며, 작성·수정·어려운 결정은 계속 에이전트가 맡는다고 보여준다. [05:34]

3. 비싼 호출 앞에 배치하는 저렴한 판단

• 수동으로 티켓과 모델을 배분하거나 모든 요청을 가장 큰 모델에 보내는 대신, 호출 전에 저렴한 판단을 두자고 제안한다. 인젝션 예시에서는 명백한 공격, 애매한 요청, 정상적인 주소 변경 요청에 서로 다른 판단과 신뢰도가 나온다. [06:19]
• 티켓 분류에서는 특정 브라우저의 오류, 모든 브라우저의 오류, 앱 사용 불가 상태를 비교한다. 높은 우선순위의 기준을 JSON에 평문으로 적으며, 이런 기준에 개발자의 전문성이 담긴다고 강조한다. [06:54]
• 코드 리뷰는 보안·위험·크기·기존 패턴 준수·커밋 품질로 점수화하고 가중치를 코드에서 조정한다. 경쟁 서비스 조사에는 브라우저 에이전트, 불안정한 테스트 수정에는 빠른 에이전트처럼 작업에 맞춰 배분하는 라우팅도 보여준다. [07:40]

4. 판단 모델의 경계와 하네스의 변화

• 판단 모델과 에이전트의 역할 경계는 아직 확신하지 못한다고 드러낸다. 발표자는 정답이 명확한 질문부터 판단 모델에 맡기는 쪽으로 기울어 있다고 보여준다. [07:52]
• Jev를 하네스 내부에서 저렴한 질문에 답하고, 위험한 호출을 감시하며, 에이전트의 작업 확인을 돕는 계층으로 다시 정리한다. 모든 하네스에 판단 계층이 생길 것이라는 전망과 함께 큰 모델 하나에 모든 일을 맡기는 비용을 지적한다. [08:31]
• 첫 실험으로는 군집 구성보다 파일 질문 도구를 추천한다. 파일을 읽기 전에 필요한 사실을 묻는 방식이 Jev와 에이전트의 보완 관계를 가장 잘 보여준다고 강조한다. [08:45]

5. 모델을 빌리고 개발 시스템을 소유하기

• Crafters Lab을 다시 소개하며, 모델은 빌리지만 앱을 만드는 시스템은 개발자가 소유한다는 관점을 제시한다. 그 시스템은 채팅창 하나나 다른 사람의 설정을 넘어 자신이 구성하는 작업 환경이라고 보여준다. [09:04]
• 도구의 형태가 개발자가 상상하는 앱의 규모를 제한할 수 있다고 주장한다. 혼자 하기 벅차다는 이유로 아이디어를 포기하는 한계를 넘되, 커진 시스템이 여전히 자신의 것처럼 느껴지는지도 질문한다. [09:43]
• 시스템 구축 초기에는 단순 프롬프트보다 느릴 수 있지만 이후에 보상받는다고 드러낸다. 이미 앱을 출시하는 개발자에게 참여를 권하고, 마지막에는 적합한 모델을 적합한 일에 배치하며 저렴한 질문으로 충분한 경우 전체 파일 읽기 비용을 피하라고 마무리한다. [10:09]

🧾 결론

• Jev와 기존 에이전트의 관계는 대체보다 보완에 가깝다. 에이전트는 작성·수정·어려운 결정을 맡고, Jev는 좁은 질문에 답하는 역할을 맡는다.
• 첫 실험 대상으로 발표자가 추천하는 것은 파일 내용을 직접 읽기 전에 질문하는 도구다. 탐색용 읽기를 줄일 수 있는지 확인하기 쉽기 때문이다.
• 모든 하네스에 판단 계층이 들어갈 것이라는 전망은 발표자의 가설이다. 판단 모델과 에이전트의 역할 경계도 아직 확정되지 않았다.
• 영상 후반의 메시지는 개발 시스템의 소유다. 모델은 빌리더라도 앱을 만드는 기준과 작업 흐름은 개발자가 설계하고 통제하자는 주장이다.

📈 투자·시사 포인트

• 에이전트 비용을 검토할 때 모델 자체의 성능뿐 아니라 호출 전 분류와 파일 탐색 방식도 살펴볼 필요가 있다. 영상은 이런 배치가 불필요한 고비용 호출을 줄일 수 있다고 주장한다.
• 판단 기준과 라우팅을 관리하는 하네스가 중요한 설계 지점으로 제시된다. 모델 선택뿐 아니라 어떤 질문을 어떤 도구에 맡기는지가 개발 시스템의 효율을 좌우한다는 관점이다.
• 솔로 개발자에게는 반복 가능한 시스템을 구축하는 초기 부담과 이후 생산성 개선을 함께 고려해야 한다는 시사점이 있다. 발표자는 처음에는 단순 프롬프트보다 느리지만 이후에 보상받는다고 설명한다.
• 투자 판단에 필요한 가격, 매출, 도입률, 독립 성능 비교는 제공되지 않는다. 이 영상은 특정 기업의 투자 근거보다 판단 모델과 에이전트의 역할 분화에 관한 기술적 가설로 읽는 편이 적절하다.

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

• 저렴하고 빠르다는 설명에는 구체적인 가격, 지연 시간, 정확도, 총비용 비교가 없다. 데모의 인상이 실제 저장소에서도 재현되는지는 확인해야 한다.
• 반환되는 신뢰도가 실제 정답률과 얼마나 일치하는지 설명되지 않는다. 애매한 결과를 언제 재검토하거나 에이전트에 넘길지도 별도로 정해야 한다.
• 프롬프트 인젝션 탐지와 실패 분류는 사례로 소개되지만, 누락이나 오분류를 측정한 결과는 없다. 데모만으로 방어 효과나 검증 능력을 확정할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 자신의 저장소에서 기존 파일 읽기 방식과 Jev 질문 방식을 나란히 비교하고, 관련 파일 탐지 정확도·문맥 사용량·지연 시간·총비용을 기록한다.
• 첫 실험은 파일의 관련성이나 역할을 묻는 좁은 질문으로 제한하고, 수정 대상 파일은 에이전트가 직접 읽도록 작업 흐름을 구성한다.
• 티켓 우선순위나 모델 선택에 사용할 판단 기준을 명시하고, 신뢰도가 낮거나 답이 모호한 경우의 재검토 경로를 정한다.
• 인젝션 탐지와 작업 검증에는 정상 사례, 명백한 문제 사례, 경계 사례를 함께 넣어 누락과 오분류를 확인한다.

❓ 열린 질문

• 정답이 분명한 질문과 맥락을 해석해야 하는 질문의 경계는 어디이며, 어떤 조건에서 판단 모델보다 에이전트가 적합한가?
• 파일 탐색 비용을 줄이면서 중요한 파일을 놓치지 않으려면 어떤 신뢰도 기준과 추가 확인 절차가 필요한가?
• 다음 전문 모델이 작업 검증을 맡게 된다면, 에이전트의 자체 확인과 어떤 방식으로 역할을 나누게 될까?