LLM에게 글을 쓰게 하지 말고, 판단만 시켜라 (Jev)

Jev가 잘하는 문제와 못하는 문제를 실험으로 살펴봤다

요즘 AI 에이전트를 만들다 보면 대부분 이런 구조를 사용한다.

사용자의 요청을 LLM에게 전달하고,

“지금 무엇을 해야 하지?”

라고 묻는다.

그리고 LLM은 긴 문장으로 답한다.

문제는 여기서 시작된다.

우리가 원하는 것은 긴 설명이 아니라,

“실행해도 되는가?”
“어떤 도구를 사용해야 하는가?”
“위험도는 어느 정도인가?”
“다음 행동은 무엇인가?”

같은 작은 판단인 경우가 훨씬 많다.

그런데 이런 판단 하나를 위해 매번 거대한 생성형 모델을 호출해야 할까?

이 질문에서 흥미로운 접근이 하나 나온다.

바로 Jev다.

---

Jev는 ‘대답하는 AI’보다 ‘판단하는 AI’에 가깝다

Jev는 TypeSafe AI의 System One 계열 모델로 소개되고 있다.

일반적인 LLM처럼 자유롭게 문장을 생성하는 대신,

noul
choice
score

처럼 미리 정해진 형태의 확률적 판단 결과를 반환하도록 설계되어 있다.

즉,

비정형 상태를 입력하고
구조화된 판단을 돌려받는다.

라고 이해하면 쉽다.

예를 들어 AI 코딩 에이전트가 다음 명령을 실행하려 한다고 해보자.

rm -rf ./build

일반 LLM에게 물어보면,

“이 명령은 build 디렉터리를 삭제하기 때문에 상황에 따라 위험할 수 있습니다…”

같은 설명이 돌아올 수 있다.

하지만 실제 프로그램이 필요한 결과는 훨씬 단순하다.

allow

confirm

block

중 하나면 된다.

Jev가 노리는 영역이 바로 이런 곳이다.

---

중요한 것은 모델 성능보다 ‘문제의 모양’이다

mizchi가 진행한 Jev 실험에서 가장 흥미로운 결론은 이것이다.

Jev가 잘 작동하는지는 정확도보다 먼저 문제의 형태에 의해 결정된다.

특히 선택 가능한 답을 미리 나열할 수 있을 때 강점을 보였다.

MOBA 실험의 489개 판단과 체스 37개 수에서 잘못된 행동 선택이 발생하지 않았고, 순서가 있는 판단을 단순 choice 대신 score 형태로 바꾸자 결과가 19/24에서 23/24로 개선됐다. 이름이 있는 목록에서 하나를 선택하는 작업도 이름만 제공했을 때 90%, 한 줄 설명을 추가했을 때 100%를 기록했다.

여기서 중요한 힌트를 얻을 수 있다.

AI에게 좋은 질문을 만드는 것만큼
AI가 답할 수 있는 공간을 잘 설계하는 것이 중요하다.

---

Jev가 잘 맞는 문제 ① 선택지가 명확한 경우

예를 들어 고객 문의가 들어온다고 해보자.

가능한 담당 부서는 세 개뿐이다.

• billing
• technical
• sales

이 경우 모델에게

“이 고객 문의를 분석해서 어떤 부서에서 처리해야 할지 자세히 설명해줘.”

라고 할 이유가 없다.

그냥 세 가지 중 하나를 고르게 하면 된다.

AI Agent에서도 마찬가지다.

사용 가능한 Tool이

• web_search
• database
• send_email
• create_calendar

뿐이라면,

모델이 새로운 Tool 이름을 만들어낼 필요가 없다.

Action Space 자체를 제한하면 존재하지 않는 행동을 선택할 수도 없다.

이것은 AI Agent 설계에서 꽤 중요한 개념이다.

---

Jev가 잘 맞는 문제 ② 순서가 존재하는 판단

보안 시스템을 예로 들어보자.

명령어 위험도를

allow < confirm < block

으로 정의할 수 있다.

또는 코드 리뷰의 심각도를

low < medium < high < critical

처럼 정의할 수도 있다.

이런 문제는 자유로운 카테고리 선택보다 순서가 있는 점수 문제로 표현하는 편이 자연스럽다.

실제 Jev 실험에서도 답의 구조를 문제 구조에 맞추는 것만으로 결과가 크게 개선됐다.

이것은 Jev만의 이야기는 아니다.

LLM을 사용하는 대부분의 시스템에서 적용할 수 있는 원칙이다.

문제에 맞는 모델을 찾기 전에
문제에 맞는 출력 구조부터 설계하라.

---

Jev가 잘 맞는 문제 ③ 하나의 상태를 여러 번 판단해야 할 때

AI 시스템에서는 하나의 데이터에 대해 여러 판단을 내려야 하는 경우가 많다.

예를 들어 코드 하나를 보고

• 보안 문제가 있는가?
• 에러 처리가 부족한가?
• 성능 문제가 있는가?
• 유지보수성이 낮은가?
• 위험한 API를 사용했는가?

를 동시에 판단할 수 있다.

Jev Playground에서는 이런 여러 질문을 하나의 state에 대해 묶어서 평가하는 실험도 진행한다.

이른바 fan-out 구조다.

하나의 입력을 여러 판단에 재사용할 수 있기 때문에 대량 코드 분석이나 Agent Guardrail 같은 구조와 잘 맞는다.

---

그래서 AI 코딩 에이전트와 궁합이 좋다

개인적으로 이 프로젝트에서 가장 흥미로운 부분은 바로 이것이다.

Jev Playground에는 실제로 Claude Code의 PreToolUse 단계에서 Bash 명령 실행 여부를 판단하는 Hook 실험이 포함되어 있다. 또한 ESLint 판정을 Jev가 수행하거나, 변경된 코드에 따라 어떤 테스트를 실행해야 하는지 선택하는 실험도 있다.

구조를 단순화하면 이렇다.

사용자 요청

↓

Claude / Codex

↓

Jev 판단

↓

allow / confirm / block

↓

Tool 실행

이렇게 되면 Jev는 메인 AI가 아니다.

AI를 통제하는 작은 Decision Layer가 된다.

---

반대로 Jev에게 시키면 안 되는 것도 있다

Jev는 만능 모델이 아니다.

오히려 못하는 일을 명확하게 구분해야 한다.

대표적인 것이 문자열 생성이다.

검색어를 새로 만들어야 하거나,

코드를 작성하거나,

메일 내용을 생성하거나,

JSON 속에 새로운 값을 만들어야 한다면,

Jev의 영역이 아니다.

이런 것은 생성형 LLM이 담당해야 한다.

또 하나 중요한 한계가 있다.

특정 API의 세부 동작을 알아야만 판단할 수 있는 문제다.

예를 들어 JavaScript에서 특정 메서드가 어떤 방식으로 동작하는지는 모델의 직관보다

• 타입 시스템
• lint
• 테스트
• 정적 분석

으로 확인하는 것이 훨씬 확실하다.

Jev 원문에서도 이런 영역은 기존 개발 도구를 대체하기보다 보완하는 역할이 적합하다고 정리한다.

---

이것을 AI Agent 구조로 옮기면 재미있어진다

예를 들어 코딩 Agent를 만든다고 해보자.

전체 시스템을 다음처럼 나눌 수 있다.

1. Reasoning Layer

Claude
GPT
Gemini
Codex

복잡한 문제를 이해하고 계획을 세운다.

2. Decision Layer

Jev

작은 판단을 빠르게 처리한다.

• 어떤 Tool을 사용할 것인가
• 명령 실행을 허용할 것인가
• 위험도가 높은가
• 사람이 확인해야 하는가
• 재시도해야 하는가
• 상위 모델로 넘겨야 하는가

3. Deterministic Layer

코드가 처리한다.

• TypeScript type
• ESLint
• 테스트
• Schema validation
• Permission
• Rule engine

4. Execution Layer

실제 행동을 수행한다.

Shell
Browser
GitHub
Database
API

이렇게 역할을 나누면 모든 일을 거대한 LLM 하나에게 맡길 필요가 없다.

---

특히 ‘모델 라우터’로 활용할 수 있다

여기서 한 단계 더 생각해볼 수 있다.

사용자 요청이 들어왔을 때 처음부터 가장 비싼 모델을 호출하지 않는 것이다.

예를 들어

사용자 요청

↓

Jev

↓

simple / normal / complex

↓

simple → 저렴한 모델
normal → 중간 모델
complex → 고성능 Reasoning 모델

이런 구조가 가능하다.

또는 작업 도중에도

continue

retry

escalate

complete

같은 결정을 맡길 수 있다.

Jev가 복잡한 문제 자체를 해결하는 것이 아니다.

복잡한 시스템 안에서 수없이 발생하는 작은 결정을 처리하는 것이다.

바로 이 차이가 중요하다.

---

하지만 경계선 판단은 사람에게 넘겨야 한다

원문에서 특히 주의해야 할 부분도 있다.

판단 기준의 경계에 있는 입력은 작은 표현 차이만으로 결과가 바뀔 수 있다.

따라서

0.9 이상 → 자동 실행

0.1 이하 → 차단

0.4~0.6 → 사람이 확인

같은 구조가 필요하다.

AI를 도입한다고 모든 판단을 자동화할 필요는 없다.

오히려 좋은 AI 시스템은

AI가 판단해야 할 곳과
코드가 판단해야 할 곳과
사람이 판단해야 할 곳을 구분한다.

---

Jev Playground가 보여주는 더 중요한 메시지

이 프로젝트를 단순히 새로운 AI 모델 테스트라고 보면 조금 아쉽다.

더 중요한 메시지가 숨어 있기 때문이다.

지금까지 우리는 AI 성능을 높이기 위해 계속 더 큰 모델을 찾았다.

GPT
Claude
Gemini
그리고 더 강력한 Reasoning Model.

하지만 실제 AI Agent를 만들다 보면 모든 단계가 깊은 추론을 필요로 하지 않는다.

오히려 대부분은 작은 결정이다.

“실행할까?”

“어느 도구를 사용할까?”

“위험한가?”

“재시도할까?”

“사람에게 물어볼까?”

“여기서 끝내도 될까?”

이 수많은 판단에 매번 가장 비싼 모델을 사용하는 것은 비효율적일 수 있다.

그래서 앞으로의 AI Agent 아키텍처에서는

Reasoning Model + Decision Model + Deterministic Code

처럼 역할이 분리될 가능성이 있다.

그리고 Jev는 그중

Decision Model이라는 새로운 위치가 어디에 존재할 수 있는지 보여주는 흥미로운 실험이다.

---

한 문장으로 정리하면

Jev를 잘 사용하는 방법은
Jev에게 더 어려운 질문을 던지는 것이 아니다.

Jev가 답하기 좋은 형태로 문제를 바꾸는 것이다.

자유롭게 말하게 하지 말고 선택지를 주고,

순서가 있다면 점수로 바꾸고,

확실한 규칙은 코드에게 맡기고,

애매한 경계는 사람에게 넘긴다.

어쩌면 앞으로 AI 시스템을 잘 만드는 능력은

“가장 똑똑한 모델을 고르는 능력”보다

“어떤 판단을 어떤 모델에게 맡길지 설계하는 능력”

에 더 가까워질지도 모른다.

---

참고 자료

• mizchi / jev-playground
• docs/fit.md — Jev가 잘 맞는 문제와 맞지 않는 문제에 대한 실측 정리
• Jev Playground README — Jev API, Shell Risk Gate, ESLint, Browser, Task Filter 등 실험 구성