10 Levels of Jev For Agentic Engineers

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Jev의 10단계 활용법은 에이전틱 엔지니어가 저렴한 판단 모델을 분류·실행 통제·파일 선별·검증에 배치해 에이전트의 비용과 작업 방식을 개선하는 설계 방법이다.

📌 핵심 요점

1. Jev는 JSON으로 질문과 판단 기준을 정의하고 불리언·선택지·점수를 반환한다. 프롬프트 인젝션이나 지원 티켓처럼 경계가 모호한 문제에서는 결과와 신뢰도를 함께 보고, 허용 기준을 용도에 맞게 정해야 한다.
2. 복합 판단은 평가 축을 나누고 코드의 가중치로 결합한다. 티켓 우선순위나 코드 변경 평가에서 작업 차단·보안 위험·변경 규모를 구분하면, 작은 수정에 포함된 위험도 별도로 드러낼 수 있다.
3. 에이전트의 도구 실행 전 훅에 Jev를 연결하면 명령의 파괴성·복구 가능성을 판단해 실행을 제한할 수 있다. 강제 푸시와 세션 삭제를 차단하는 시연이 제시되며, 실제 허용 정책은 개발자가 결정한다.
4. 저렴한 사전 판단은 모델·에이전트 라우팅과 문맥 압축에도 쓰인다. 작업에 맞는 실행 대상을 선택하고, 문맥 크기와 작업 전환을 함께 고려해 압축 시점을 조절하는 방식이다.
5. 파일 질의와 병렬 분류는 강력한 모델이 직접 읽을 대상을 좁힌다. 마지막 단계에서는 에이전트가 Jev 호출을 선택해 실패 원인 분석·수정 위치 탐색·추가 검증에 활용하지만, 품질 동등성과 최적 구성은 실제 작업으로 검증해야 한다.

🧩 배경과 문제 정의

• Jev는 JSON으로 질문과 판단 기준을 지정하는 지능형 질문·응답 시스템이다. 반복적인 분류와 판단을 저렴하고 빠르게 처리해 에이전트의 작업 방식을 바꾸는 것이 핵심 활용 방향이다.
• 프롬프트 인젝션 탐지, 지원 티켓 분류, 코드 위험도 평가처럼 경계가 모호한 문제에서는 결과뿐 아니라 신뢰도를 활용하고, 용도에 맞는 판단 기준을 정해야 한다.
• 장시간 자율적으로 작동하는 에이전트에는 위험한 도구 실행을 제한하고, 적절한 모델을 선택하며, 문맥 압축 시점을 판단하는 제어 장치가 필요하다.
• 비용·속도·성능의 균형을 개선하려면 작업에 맞는 모델을 배치해야 한다. 제공 구간은 기본 판단부터 에이전트 내부 제어까지 다루며, 마지막에는 파일을 문맥에 읽어 들일지 판단하는 활용법으로 확장된다.

🕒 시간순 섹션별 상세정리

1. 예·아니요 판단과 신뢰도로 프롬프트 인젝션 구분하기

• 첫 단계는 상태와 선택지를 입력해 예·아니요를 받는 방식으로, 저렴하고 빠른 지능형 조건문에 해당한다. 기존 지시를 무시하고 시스템 프롬프트를 출력하며 고객에게 환불 이메일을 보내라는 입력은 프롬프트 인젝션으로 분류되고, 신뢰도는 99%로 나온다 [01:33]
• 계정 관리자 역할로 할인 승인 범위를 답하라는 입력은 의심스럽지만 명확하지 않으며, 자막의 신뢰도 표기는 ‘8.2’로 단위가 불분명하다. 동료의 이전 메시지를 무시하고 환불을 처리하라는 입력은 64% 신뢰도로 인젝션 판정을 받는다. 경계 사례의 허용 기준은 사용 목적에 맞게 정해야 한다 [02:38]

2. 다중 선택으로 지원 티켓의 유형과 우선순위 결정하기

• 다중 선택은 정해진 목록에서 하나 이상의 항목을 고르며, 한 번의 호출에 여러 질문을 넣을 수 있다. Safari에서 내보내기를 누르면 앱이 멈추지만 Chrome에서는 작동하는 티켓은 버그이면서 일반 우선순위로 분류된다. 다른 브라우저로 계속 사용할 수 있다는 점이 근거다 [04:04]
• 비용 비교 예시에서는 DeepSeek Flash가 Jev 호출보다 약 4배, 자막상 Fable 5.1은 약 600배 비싸다. 같은 질의를 대량 반복하는 비용도 Jev 약 20달러와 Fable 5.1 약 11,000달러로 대비되며, 저렴한 단가가 반복 분류를 프로덕션에 적용할 수 있는 범위를 넓힌다는 주장으로 계속된다 [04:47]

3. 항목별 점수와 코드의 가중치로 종합 우선순위 계산하기

• 복합 점수화는 명확하게 정의한 척도로 여러 기준을 평가하고 가중 합산하는 방식이다. 항목의 중요도를 조정할 때 프롬프트를 바꾸는 대신 가중치 숫자를 변경할 수 있다 [06:40]
• 엔지니어링 티켓 예시에서는 대안이 없는 작업 차단 문제가 2점 만점에 2점을 받고 높은 신뢰도를 보인다. Jev가 개별 점수를 반환하면 코드에 정의한 우선순위 가중치로 결합하며, 출력 형식은 불리언이나 선택지가 아닌 점수다 [07:19]

4. 코드 변경의 보안 위험과 변경 규모를 별도로 평가하기

• 토큰 만료 검사 수정은 사용자 입력이나 인증을 다루므로 보안 위험이 2점 만점에 1.33점으로 평가된다. 반면 변경 규모는 작고 기존 패턴을 잘 따르며, 공통성 항목은 0.8로 나온다. 서로 다른 평가 축을 분리해야 작은 수정에 포함된 보안 위험도 드러난다 [07:44]
• 평가 기준은 자연어로 정의하므로, 모델에 원하는 판단을 간결하고 정확하게 전달하는 능력이 중요하다. README 수정 예시는 보안 위험이 없는 것으로 평가되며, 분석 입력은 짧은 diff와 커밋 메시지에 한정되지 않고 파일 전체가 될 수도 있다 [08:31]

5. 신뢰도와 명령의 복구 가능성으로 Bash 실행 통제하기

• 신뢰도 게이팅은 잘못된 자동 판단의 비용이 사람에게 도움을 요청하는 비용보다 클 때 활용한다. git push --force origin main 예시는 비가역성 0.99와 파괴적 의도로 판정되며, 에이전트의 도구 실행 전 훅에서 차단할 대상으로 다뤄진다 [09:40]
• 자연어 기준에 따른 명령 분류는 개발자가 미리 열거하지 못한 위험한 명령에도 대응하려는 접근이다. 파일을 대량 삭제하는 낯선 명령도 고려해야 하며, 반대로 소스 디렉터리 목록을 확인하는 명령은 높은 신뢰도로 읽기 전용으로 분류된다 [10:33]

6. 저렴한 사전 판단으로 모델과 에이전트 라우팅하기

• 모델 라우팅은 작업을 수행할 수 있는 가장 저렴한 모델을 선택하고, 에이전트 라우팅은 도구·시스템 프롬프트·실행 환경이 다른 에이전트 중 적합한 대상을 선택한다. 사람의 지속적인 개입 없이 파이프라인을 운영하기 위한 구성 요소다 [12:59]
• 경쟁사의 온라인 사례를 조사하며 대시보드 로그인 흐름을 추가하는 요청은 브라우저 에이전트로 연결된다. 빠른 에이전트는 14%의 차순위 후보로 나온다. 결제 저장소의 불안정한 체크아웃 테스트에 대기를 추가하는 작은 수정은 빠른 에이전트로 분류되지만 일부 모호함이 남는다 [13:37]

7. 실제 도구 호출에 가드레일을 넣어 삭제·강제 푸시·쓰기를 차단하기

• 실제 코딩 에이전트에 Bash 게이트를 넣으면 명령 실행 전에 Jev가 위험을 판단한다. 저장소 정리 요청에서 node_modules와 세션을 함께 삭제하려는 호출은 비가역적이고 파괴적인 것으로 판정되어 차단되며, 테스트 실행은 진행된다 [15:49]
• 현재 브랜치를 원격 main에 강제 푸시하라는 요청도 실행 전 훅에서 차단되어 완료되지 않는다. 이 구조의 목적은 에이전트가 생성한 명령에 별도의 실행 제한을 적용하는 것이다 [16:25]

8. 작업 전환과 문맥 크기를 함께 보고 자기 압축 시점 정하기

• Jev를 에이전트 실행 구조에 넣어 필요한 시점에만 문맥 압축 알림·권고·요청을 전달할 수 있다. 데모에서는 동작을 쉽게 확인하려고 기준을 낮게 설정해 6천 토큰에서 알림, 1만 토큰에서 권고, 1만 4천 토큰에서 압축 요청이 발생하도록 한다 [18:08]
• 큰 파일들을 읽어 문맥이 약 1만 5천 토큰에 도달한 뒤 작업을 바꾸자 턴 종료 시 압축이 트리거된다. 하나의 모델이 다른 모델의 운영 상태를 판단하는 구조이며, 모든 일을 단일 최상위 모델에 맡기기보다 시점·속도·비용·성능에 맞는 모델을 쓰자는 관점과 연결된다 [18:48]

9. 파일을 읽기 전에 문맥에 필요한지 저렴하게 판단하기

• 여덟 번째 활용 방향은 기존 작업 흐름 안에서 시간·비용·성능을 함께 개선하는 것이다. 적절한 용도에 Jev를 배치하면 세 측면의 이점을 함께 얻을 수 있다는 기대가 드러난다 [20:35]
• 구체적인 출발점은 파일을 실제로 문맥에 읽어 들일 필요가 있는지 먼저 저렴하게 판단하는 것이다. 제공 구간은 세 가지 도구가 있다는 언급까지이며, 도구별 구성과 실행 결과는 아직 나오지 않는다 [20:43]

10. 파일 질의와 계층 분류를 위임해 컨텍스트 사용을 줄인다

• ask Jev filebool은 파일 경로와 예·아니요 질문을 받아 토큰 검증 여부나 실제 자격 증명 포함 여부를 판단한다. 시연에서 PI 에이전트는 파일 원문을 직접 읽지 않았고, 표시된 토큰 사용량은 약 2천이었다. 파일 읽기와 질의응답은 Jev에 위임했다 [21:20]
• 하네스 코드가 파일 내용을 전달하고 에이전트는 도구를 호출해 결과를 종합한다. 작은 파일 읽기도 반복되면 비용이 누적되므로, Jev는 기존 에이전트를 확장하는 도구로 활용된다 [22:20]

11. 여러 파일에 같은 질문을 병렬로 적용한다

• 레벨 9는 파일별 질의를 여러 파일로 확장한다. JWT와 라우트 관련 파일에 JWT 관련 여부와 소속 계층을 함께 묻는 시연에서는 도구 호출 한 번으로 0.5초 미만에 세 개의 응답을 얻었다 [24:44]
• 파일을 수정해야 한다면 에이전트가 내용을 읽어야 하지만, 정보 확인만 필요하다면 질문으로 대체할 수 있다. 파일 경로나 glob을 전달해 관련 여부와 계층, 신뢰도 점수를 받는 방식이다 [25:29]

12. 저장소 전체의 후보 선별을 저렴한 사전 검사로 처리한다

• 모든 TypeScript 파일에서 알려진 버그, TODO, 임시방편을 인정하는 내용이 있는지 질의하고, 해당 파일과 확률을 반환하도록 했다. 시연에서는 Jev API로 파일 10개를 거의 즉시 병렬 처리했으며, 이어 도구 호출 7회와 매우 적은 비용을 언급했다 [26:22]
• 이 결과는 더 강력한 모델이 살펴볼 대상을 좁히는 초기 필터다. 단순 분류에서는 기존 에이전트와 같은 답을 더 빠르고 저렴하게 얻었다는 실험 경험이 제시되지만, 실제 동등성을 확인하려면 A/B 비교가 필요하다 [26:57]

13. 같은 에이전트를 늘리는 데서 서로 다른 모델을 조합하는 방향으로 확장한다

• 서브에이전트, 다중 에이전트 오케스트레이션, 에이전트 군집으로 규모를 늘려도 같은 모델의 복제만으로는 충분하지 않다는 주장이다. 결정적 코드부터 빠른 분류 모델, 장시간 작업하는 에이전트까지 서로 다른 처리 수단이 필요하다 [28:00]
• 범용 에이전트가 맡는 작업 중 일부는 단순하고 집중된 전문 모델로 해결할 수 있다. 좁은 범위의 작업에서 이런 모델이 거대 언어 모델보다 좋은 결과를 낼 것이라는 기대가 있지만, 적용 여부는 각 사용 사례와 실제 프로덕션 기준으로 검증해야 한다 [28:34]

14. 에이전트가 Jev 호출을 선택하며 진단·수정·검증을 수행한다

• 레벨 10의 ‘에이전틱 Jev’에서는 에이전트가 Jev에 맡길 일을 결정한다. 여러 매개변수를 갖춘 ask Jev 도구를 하네스에 연결하지만, 최적의 구성 방식은 아직 탐색 중인 새로운 단계다 [29:57]
• 테스트 명령을 실행하고 출력을 분류해 실패 원인을 좁힌 뒤, 단순한 올림 처리 수정으로 해결되는지 가설을 확인한다. 이후 위험 수준과 테스트 통과 여부도 질의해, 적은 비용과 짧은 시간으로 추가 검증을 수행한다 [30:52]

15. 명확한 판단 과제에 활용하고 장기 자율 에이전트와 구분한다

• 효과적인 활용에는 프롬프트 설계, 적절한 도구 제공, Jev가 잘하는 일과 적합하지 않은 일에 대한 이해가 필요하다. 도구를 연결하는 것만으로 활용 방식이 완성되는 것은 아니다 [32:41]
• Jev는 UI 조작, 게임 플레이, 항공기·드론 운용을 맡길 장기 실행 에이전트로 제시되지 않는다. 사람이 판단 조건을 이해하거나 에이전트가 이를 파악하도록 구성할 수 있는 구체적인 엔지니어링 과제가 적용 대상이다 [33:16]

16. 도구의 기본 원리를 이해하고 비용 효율적인 사용법을 설계한다

• 에이전트 사용량이 많은 제품, 특히 소프트웨어 팩토리 같은 아웃루프 시스템에서는 언어 모델 호출 비용을 줄이는 활용 가치가 크다는 주장이다. 적용 가능성을 판단할 자료로 예제 코드베이스와 관련 리소스가 권장된다 [34:14]
• 아웃루프 에이전틱 엔지니어링을 주제로 한 ‘페이즈 3’ 제품은 개발 중이며, 사전 등록과 가능하면 사전 판매를 준비할 계획이다. 제품 구매 여부와 관계없이 ‘Jev의 10단계’ 자료는 무료로 제공된다 [34:46]

🧾 결론

• 핵심은 반복적인 판단을 명확한 질문으로 분해하고, 각 질문에 적합한 처리 수단을 배치하는 데 있다.
• 신뢰도와 점수는 실행 정책을 설계하는 입력이다. 판단 기준, 가중치, 차단 조건을 구체화하는 엔지니어의 역할이 중요하다.
• 파일 정보 확인은 질의로 대체할 수 있지만, 실제 수정이 필요한 파일은 에이전트가 내용을 읽어야 한다.
• Jev는 구체적인 엔지니어링 판단 과제에 적용하는 도구로 제시된다. 장기 자율 에이전트의 모든 역할을 맡기는 사용법은 자료의 적용 범위에 포함되지 않는다.

📈 투자·시사 포인트

• 에이전트 호출량이 많은 제품에서는 반복 분류와 사전 선별의 단가가 누적 비용에 영향을 준다. 도입 효과는 해당 작업의 호출량과 품질 요구에 따라 평가할 필요가 있다.
• 서로 다른 모델을 조합하는 설계에서는 라우팅·실행 통제·문맥 관리가 중요한 운영 기능이 된다. 자료는 같은 모델을 복제해 늘리는 방식만으로는 충분하지 않다는 관점을 제시한다.
• 제품 관점의 판단 기준은 도구 자체의 신기함보다 업무·사업·고객에게 주는 결과다. 비용 절감과 함께 실패율, 처리 시간, 검증 부담을 살펴야 한다.
• 제시된 가격과 응답 속도는 시연 및 비교 사례다. 이를 일반적인 성능 우위나 특정 기업의 투자 매력으로 바로 연결할 근거는 제공되지 않는다.

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

• 비용 비교에 등장하는 ‘Fable 5.1’은 자막상 명칭이며, ‘DeepSeek Flash’와 함께 정확한 모델 식별 및 비교 조건을 확인해야 한다. 약 4배·600배라는 수치는 해당 예시의 주장으로 해석해야 한다.
• 신뢰도 ‘8.2’는 단위가 불분명하다. 다른 예시의 99%·64%와 같은 척도인지 확인되지 않았으며, 신뢰도 수치를 실제 정답률로 해석할 근거도 제시되지 않는다.
• 빠르고 저렴하게 같은 답을 얻었다는 경험은 A/B 검증을 대신하지 않는다. 파일 선별의 누락과 실행 게이트의 오판이 실제 작업에 미치는 영향은 추가 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 반복되는 판단 과제 하나를 골라 입력, 선택지 또는 점수 척도, 판단 기준을 JSON으로 명시한다.
• 경계 사례를 포함한 평가 자료를 만들고 기존 방식과 Jev 적용 방식을 A/B 비교해 정확도·지연·비용을 기록한다.
• 실행 명령을 읽기 전용·복구 가능·비가역적 작업으로 구분하고, 신뢰도가 낮거나 오판 비용이 큰 경우의 사람 확인 조건을 정한다.
• 파일 사전 선별을 적용한 뒤 실제 필요한 파일이 누락되는지 확인하고, 수정 대상 파일은 원문을 읽도록 작업 흐름을 구성한다.

❓ 열린 질문

• 어떤 작업 범위에서 Jev의 사전 판단이 추가 호출 비용을 상쇄하면서 기존 방식과 동등한 품질을 유지하는가?
• 신뢰도에 따라 자동 실행·차단·사람 확인을 나누는 기준을 어떻게 정해야 오판 비용을 줄일 수 있는가?
• 저장소 규모가 커지거나 마이그레이션처럼 관련 파일이 넓게 퍼진 작업에서도 파일 선별의 누락을 충분히 억제할 수 있는가?