Jev 활용 프로젝트 정리

LLM에게 버튼 하나까지 생각하게 해야 할까?

Jev 오픈소스 프로젝트 8개로 살펴본 AI Agent의 다음 구조

AI 에이전트를 만들다 보면 이상한 순간을 자주 만나게 된다.

파일을 읽고, 검색하고, 브라우저 버튼 하나를 누르고,
수백 개의 Skill 중 하나를 고르는 모든 순간에 거대한 LLM을 호출한다.

“이 버튼을 누를까, 저 버튼을 누를까?”

“이 로그를 남길까 버릴까?”

“수백 개의 Skill 중 어떤 것을 사용할까?”

사람에게 물어본다면 그리 어려운 문제가 아니다.

하지만 AI 시스템에서는 이런 작은 판단에도
Claude나 GPT 같은 대형 모델을 호출하는 경우가 많다.

결과적으로 에이전트는 느려지고,
비용은 증가하며,
컨텍스트는 계속 커진다.

최근 등장한 Jev는 이 문제를 조금 다른 방향에서 바라본다.

“모든 AI 작업이 새로운 문장을 만들어야 하는 것은 아니다.
많은 순간에 필요한 것은 단지 선택이다.”

생성하는 AI와 결정하는 AI

우리가 익숙한 LLM은 기본적으로 다음 토큰을 계속 생성한다.

사용자가 질문하면 모델은 문장을 만들어 답한다.

하지만 에이전트 내부에서 일어나는 작업을 자세히 보면
의외로 생성이 필요하지 않은 경우가 많다.

예를 들어 브라우저 에이전트가 있다고 해보자.

화면에는 다음 세 개의 버튼이 있다.

A. 로그인
B. 회원가입
C. 비밀번호 찾기

사용자의 목표가

“내 계정으로 로그인해줘.”

라면 AI가 긴 문장을 만들 필요가 없다.

필요한 것은 사실 이것뿐이다.

로그인 94%
회원가입 3%
비밀번호 찾기 3%

즉 Generation 문제가 아니라 Decision 문제다.

Jev는 이런 종류의 문제를 위해 만들어진
TypeSafe AI의 System One Model이다.

자유로운 문장을 생성하는 대신,
주어진 상태에 대해 구조화된 선택과 확률을 반환하는 것을 목표로 한다.

복잡한 추론과 계획은 기존 LLM에게 맡기고,
반복적으로 발생하는 작은 의사결정은
빠른 Decision Model에게 맡기는 것이다.

출처:

• TypeSafe AI, "Introducing System One Models & Jev"
• TypeSafe AI 공식 Jev 발표 자료

1. fast-jev-compaction

AI의 기억을 무조건 요약하지 않는다

Claude Code 같은 코딩 에이전트를 오래 사용하면
가장 먼저 문제가 되는 것이 Context Window다.

몇 시간 동안 코딩하다 보면

파일 내용,
검색 결과,
빌드 로그,
테스트 결과가 계속 쌓인다.

기존 방법은 보통 이것을 다시 LLM에게 요약시키는 것이다.

하지만 요약에는 문제가 있다.

원래 중요했던 정보가 사라질 수 있기 때문이다.

fast-jev-compaction은 조금 다른 접근을 사용한다.

Claude Code의 Tool Call과 Tool Result를 평가한 뒤
오래됐거나 필요성이 낮은 내용을 제거하거나 줄인다.

개념적으로 보면 다음과 같다.

KEEP
TRUNCATE
DROP

예를 들어 긴 빌드 로그는 잘라내고,
더 이상 필요하지 않은 Tool Result는 제거하고,
현재 작업에 중요한 내용은 유지한다.

이 프로젝트에서 중요한 특징은
남겨야 한다고 판단한 메시지를 새로운 요약문으로 바꾸는 것이 아니라
가능하면 원문 그대로 유지한다는 점이다.

그래서 이 프로젝트는 단순한 Context Summarizer보다는

“Agent Memory Garbage Collector”

에 가깝다.

앞으로 몇 시간 혹은 며칠 동안 지속되는
장기 실행형 에이전트가 많아진다면
이런 Context 관리 레이어는 상당히 중요해질 수 있다.

출처:

• GitHub — tamaratran/fast-jev-compaction
• 프로젝트 README 및 Claude Code Plugin 설명

2. jev-browser

LLM은 계획하고 Jev는 클릭한다

브라우저 에이전트에서 반복적으로 발생하는 작업 중 하나가

“다음에 어떤 행동을 해야 하는가?”

를 결정하는 것이다.

페이지를 보고

어느 버튼을 클릭할 것인가?
어느 입력창에 값을 넣을 것인가?
작업은 끝났는가?
오류가 발생했는가?

를 계속 판단해야 한다.

jev-browser는 Planning과 Action Decision을 분리하려는 프로젝트다.

구조를 단순화하면 다음과 같다.

사용자
↓
LLM
↓
계획
↓
Jev
↓
클릭 / 입력 / 선택
↓
Browser

LLM은 큰 목표를 처리한다.

예를 들어

“사이트에 로그인한 뒤 주문 내역으로 이동한다.”

와 같은 계획을 만든다.

반면 실제 페이지에서

어떤 요소를 선택할지,
어떤 액션을 수행할지,
현재 단계가 완료되었는지

같은 반복적인 판단은 Jev에게 넘길 수 있다.

이 프로젝트는 Library뿐 아니라 CLI와 MCP 형태의 사용도 염두에 두고 있다.

흥미로운 것은 LLM을
에이전트의 모든 행동에서 조금씩 분리하기 시작한다는 점이다.

LLM이 두뇌라면,

Jev는 빠르게 반응하는 반사신경에 가까워진다.

출처:

• GitHub — Ying-Kai-Liao/jev-browser
• 프로젝트 README
• Awesome Jev Projects의 jev-browser 소스 검토 자료

3. jev-search

검색도 사실 수많은 선택의 연속이다

AI 검색 역시 비슷하다.

사용자가

“요즘 로컬 AI Agent 프로젝트 찾아줘.”

라고 했다고 해보자.

AI는 먼저 여러 가지를 결정해야 한다.

어떤 검색어를 사용할 것인가?

local AI agent
open source AI agent
local LLM agent framework

어느 정보원을 사용할 것인가?

Google
GitHub
Reddit
Hacker News
arXiv
YouTube

그리고 검색된 수많은 문서 중
어떤 것이 사용자의 질문과 가장 관련 있는지도 판단해야 한다.

jev-search는 이런 과정에 Jev를 활용한다.

Jev가 사용자의 검색 요청을 해석하고,

검색어,
검색 소스,
검색 기간

등을 선택한다.

그다음 검색엔진에서 결과를 가져온 뒤
각 결과의 관련도를 다시 평가한다.

중요한 점은
검색 결과를 다시 LLM으로 길게 생성해서
하나의 답변으로 만드는 것이 핵심이 아니라는 것이다.

기본적으로 링크와 스니펫을 제공하면서
Jev가 검색 과정의 의사결정을 담당한다.

구조적으로 보면

“Search Router + Relevance Ranker”

에 가깝다.

AI 에이전트 시대에는
검색 엔진 자체만큼이나

“어디를 검색하고 무엇을 가져올 것인가”

를 판단하는 검색 오케스트레이션 레이어가 중요해질 수 있다.

출처:

• GitHub — superagents-lab/jev-search
• 프로젝트 README
• Search1API 기반 Jev Search 구현 설명

4. Reticle

AI가 “완료했습니다”라고 말한다고 정말 완료된 걸까?

코딩 에이전트를 사용하다 보면 흔히 보는 문장이 있다.

“수정했습니다. 정상적으로 동작합니다.”

하지만 실제 브라우저를 열어보면
에러가 발생하거나 기능이 제대로 동작하지 않는 경우가 있다.

Reticle은 이 문제를 다룬다.

Agent가 자신이 만든 코드에 대해
“잘 작동한다”고 판단하는 것만 믿지 않고,

실제로 실행 중인 애플리케이션을 관찰한다.

예를 들어 Agent가

“결제 기능을 수정했습니다.”

라고 말했다고 하자.

Reticle은 실행 중인 앱에서

DOM,
Network,
Console,
애플리케이션 상태

등 실제 런타임 정보를 확인할 수 있도록 설계되어 있다.

API 요청에서 오류가 발생했다면

PASS가 아니라

FAIL

이라는 증거를 에이전트에게 돌려주는 것이다.

Reticle이 지향하는 것은 단순한 테스트 실행기가 아니다.

“Agent가 했다고 말하는 것과
실제로 애플리케이션에서 일어난 일이 같은가?”

를 검증하는 Proof Layer에 가깝다.

다만 한 가지 중요한 점이 있다.

Reticle은 현재 TypeSafe Jev를 실제 Verification Routing에
사용하고 있는 상태는 아니다.

프로젝트 README에서는
Verification 과정의 작은 판단들을 향후 Jev로 Routing하는 방식을
로드맵으로 설명하고 있으며,

현재는

“Nothing ships against it yet.”

이라고 명시하고 있다.

즉 현재는 Jev 연동 프로젝트라기보다는
Jev 스타일의 Runtime Verification 프로젝트에 가깝다.

출처:

• GitHub — reticlehq/reticle
• Reticle README
• Reticle README의 "On the roadmap" — TypeSafe AI Jev 연동 계획

5. NanoJev

Jev 같은 모델을 직접 만들어본다면

앞의 프로젝트들이 Jev API를 활용하는 사례라면
NanoJev는 조금 다르다.

Jev와 유사한 종류의 Decision Model을
직접 구현하고 학습하는 프로젝트다.

NanoJev는 약 0.6B 규모의 작은 모델을 이용해

State와 Question을 입력받고
완전한 Probability Distribution을 출력하는 구조를 실험한다.

입력은 개념적으로 다음과 같다.

현재 상태
+
질문
+
후보

그리고 결과는 긴 문장이 아니라

A 71%
B 22%
C 7%

같은 확률 분포다.

또는

True 86%
False 14%

같은 결과를 만들 수 있다.

프로젝트는 이것을

“zero output-token decoding”

방식의 Parallel Decision Model로 설명한다.

이 프로젝트가 흥미로운 이유는
작은 언어 모델을 바라보는 방향을 바꾸기 때문이다.

최근까지 작은 LLM의 목표는 대체로

“큰 LLM처럼 얼마나 잘 이야기할 수 있는가?”

였다.

하지만 NanoJev에서는 질문이 다르다.

“말을 잘하지 않아도 된다.
결정을 잘하면 되는 것 아닌가?”

AI Agent가 점점 복잡해질수록
작은 모델을 이런 Decision Engine으로 활용하는 방식은
흥미로운 연구 방향이 될 수 있다.

출처:

• GitHub — TianyuCodings/NanoJev
• NanoJev README
• NanoJev 프로젝트의 0.6B Parallel Decision Model 설명

6. open-alternative-jev

기존 오픈 모델을 Decision Engine으로 바꾼다면

NanoJev가 작은 Decision Model 자체를 만드는 접근이라면
open-alternative-jev는 조금 다른 길을 택한다.

이미 존재하는 Open-Weights LLM을 활용한다.

하지만 일반적인 Chat 모델처럼
긴 문장을 생성시키는 것이 목적이 아니다.

주어진 선택에 대한 확률을 이용해
구조화된 결정을 만드는 방식이다.

예를 들어 Agent가 사용할 도구 후보가

A = Search
B = Browser
C = File

이라고 하자.

모델에서 얻은 확률을 이용해

A 0.12
B 0.74
C 0.14

와 같은 분포를 만들고
가장 적절한 후보를 선택할 수 있다.

프로젝트는 Hugging Face Transformers와
vLLM 같은 기존 Open-Weights 생태계를 이용해

System One 스타일의
Typed Decision Layer를 구현하려 한다.

이 접근의 가장 큰 매력은

“Jev 같은 아이디어를 로컬 GPU에서도 실험해볼 수 있다.”

는 것이다.

별도의 상용 Decision API 대신
자신이 가지고 있는 Qwen 등의 오픈 모델을 사용할 수 있다.

물론 이것이 TypeSafe의 Jev 자체를 복제한 것은 아니다.

모델의 Probability Calibration 문제도 고려해야 한다.

하지만 로컬 AI 시스템을 만드는 사람에게는
상당히 흥미로운 접근이다.

출처:

• GitHub — ikermoel/open-alternative-jev
• 프로젝트 README
• Open Alternative to Jev의 System One / Open-Weights 구현 설명

7. pi-jev

코딩 에이전트의 행동을 한 번 더 판단한다

Pi 같은 Coding Agent는

Bash 실행,
파일 수정,
코드 작성

같은 Tool Call을 계속 수행한다.

그런데 에이전트에게 Tool 권한을 많이 줄수록
새로운 문제가 생긴다.

“이 명령을 정말 실행해도 될까?”

pi-jev는 Pi Coding Agent와
Jev Decision Layer를 연결하는 프로젝트다.

프로젝트에는 크게 세 가지 역할이 있다.

첫 번째는 Tool Gate다.

bash,
write,
edit

같은 Tool이 실행되기 전에
그 작업을 평가한다.

두 번째는 Tool Output Judge다.

Bash 명령 등이 끝난 후
출력 결과를 분석해
어떤 종류의 문제가 발생했는지 판단한다.

세 번째는 jev_ask다.

Coding Agent가 필요할 때
Jev에게 Typed Decision을 직접 요청할 수 있도록 한다.

구조를 단순하게 표현하면 다음과 같다.

LLM
↓
Decision Gate
↓
Tool
↓
Output Judge

즉 LLM이 Tool Call을 생성한다고 해서
곧바로 실행하는 것이 아니라

그 사이에 하나의 Decision Layer를 추가한다.

에이전트가 앞으로

파일 시스템,
서버,
브라우저,
데이터베이스

등 더 많은 권한을 갖게 된다면
이런 Tool Decision Layer의 중요성은 더욱 커질 수 있다.

출처:

• GitHub — y0usaf/pi-jev
• pi-jev README
• Tool Gate / Tool Output Judge / jev_ask 구현 설명

8. hermes-jev-skills

Jev를 Agent Runtime으로 확장한다

8개의 프로젝트 가운데
Jev를 가장 다양한 영역에 적용하려는 프로젝트 중 하나가
hermes-jev-skills다.

이 프로젝트의 아이디어는 간단하다.

Agent가 사용하는 거대한 LLM에게
모든 작은 판단을 시키지 말자는 것이다.

예를 들어 에이전트에
수백 개의 Skill이 설치되어 있다고 해보자.

사용자가 질문할 때마다
모든 Skill 설명을 LLM Context에 넣는 대신,

“현재 요청에 필요한 Skill은 무엇인가?”

라는 선택 문제를 Jev에게 맡길 수 있다.

이 프로젝트는 이 원리를
다양한 영역에 적용한다.

Model Routing

Memory Filtering

Compaction

Skill Selection

Message Triage

Computer Use

Browser Use

등이다.

예를 들어 Model Routing에서는

현재 요청에 최고급 모델이 필요한지,
더 저렴한 모델로 충분한지를 선택한다.

Memory에서는

검색한 기억 중 어떤 내용을
실제 Context에 넣을지를 판단한다.

Skill Selection에서는

설치된 수많은 Skill 중
현재 요청에 필요한 Skill만 선택한다.

Computer Use와 Browser Use에서는

이미 안전하다고 정의된 Action 후보 가운데
다음 행동을 선택한다.

흥미로운 점은 이 기능들이
Hermes만을 위한 전용 코드로 묶여 있지 않다는 것이다.

프로젝트의 여러 기능은
일반적인 SKILL.md 형태로 제공되어

Hermes뿐 아니라
Claude Code나 Codex 같은
Skill 기반 Agent 환경에서도 활용할 수 있도록 설계되어 있다.

이 프로젝트가 보여주는 가장 큰 그림은

Jev가 단순히 하나의 API 호출이 아니라

“Agent 내부의 Decision Runtime”

역할을 할 수 있다는 것이다.

출처:

• GitHub — kerpopule/hermes-jev-skills
• Hermes Jev Skills README
• Model Routing / Memory / Skill Selection / Browser & Computer Use 측정 자료

결국 에이전트 구조가 달라지고 있다

현재 많은 AI Agent는 사실 이런 구조다.

User
↓
Huge LLM
↓
Everything

계획도 LLM이 한다.

검색도 LLM이 결정한다.

Skill도 LLM이 선택한다.

브라우저 클릭도 LLM이 결정한다.

메모리 관리도 LLM이 한다.

심지어

“작업이 끝났는가?”

도 LLM에게 묻는다.

하지만 Jev 관련 프로젝트들이 보여주는 방향은 조금 다르다.

             LLM
      Reasoning / Planning
             │
             ▼
      Decision Layer
             │
  ┌──────────┼──────────┐
  │          │          │
Skill      Search      Memory
  │          │          │
  ├──────────┼──────────┤
  │
Browser
  │
Tools
  │
  ▼

Execution
│
▼
Verification

거대한 LLM은
정말 생각해야 하는 문제에 집중한다.

작고 반복적인 판단은
빠른 Decision Model에게 맡긴다.

그리고 실제 실행 결과는
별도의 Verification Layer가 확인한다.

어쩌면 앞으로 AI Agent의 발전은

더 큰 LLM 하나를 만드는 경쟁만이 아니라,

“서로 다른 종류의 AI를 어떻게 조합할 것인가”

의 문제가 될지도 모른다.

System One과 System Two

TypeSafe가 Jev를 설명하면서 사용하는
System One이라는 이름은

Daniel Kahneman의
System 1 / System 2 구분에서 영감을 받았다.

System 1은 빠르고 즉각적인 판단,

System 2는 느리지만 복잡한 사고를 의미한다.

AI Agent에 이를 비유해 보면

System 2 역할은

Claude
GPT
Gemini
같은 대형 모델이 맡을 수 있다.

계획,
추론,
코딩,
복잡한 문제 해결이 여기에 해당한다.

반면 System One 역할은

선택,
분류,
라우팅,
관련도 판단,
확률적 의사결정

같은 작업이다.

Jev는 바로 이 영역을 겨냥하고 있다.

출처:

• TypeSafe AI, "Introducing System One Models & Jev"

내가 특히 흥미롭게 보는 부분

이 프로젝트들을 살펴보면서
가장 흥미로웠던 것은
Jev라는 특정 제품 자체만은 아니었다.

AI 시스템을 바라보는 방식의 변화였다.

지금까지 우리는 AI에게 무언가를 시키면
자연스럽게 LLM 하나를 먼저 떠올렸다.

하지만 실제 Agent 시스템이 커지기 시작하면
필요한 것은 하나의 AI가 아니다.

생각하는 AI

결정하는 AI

기억을 관리하는 시스템

행동하는 Tool

결과를 검증하는 시스템

이들이 함께 움직이는 구조가 필요하다.

그리고 지금 등장하는 Jev 관련 오픈소스 프로젝트들은
그 구조의 각 부분을 하나씩 실험하고 있다.

fast-jev-compaction은
Context를 관리한다.

jev-search는
검색 과정의 선택을 담당한다.

jev-browser는
Browser Action을 결정한다.

pi-jev는
Tool 실행 전후의 판단 계층을 만든다.

Reticle은
실제 실행 결과를 검증한다.

NanoJev는
작은 Decision Model 자체를 만들어본다.

open-alternative-jev는
기존 Open-Weights 모델을
System One 스타일 Decision Engine으로 활용한다.

그리고 hermes-jev-skills는

Model,
Memory,
Skill,
Browser,
Computer Use

등 Agent 내부의 여러 판단을
하나의 Decision Layer로 확장하려 한다.

각각은 아직 작은 오픈소스 프로젝트일 수 있다.

하지만 이 프로젝트들을 한곳에 놓고 보면
꽤 선명한 그림이 나타난다.

“미래의 AI Agent는
하나의 거대한 LLM이 모든 일을 처리하는 구조가 아니라,

여러 종류의 지능과 도구가
각자의 역할을 맡는 시스템이 될 가능성이 높다.”

그리고 Jev는 그중에서

‘빠르게 판단하는 작은 두뇌’

라는 자리를 노리고 있다.