Jev — 생성하는 LLM 옆에 판단 모델을 두는 이유
Jev의 구조화된 판단과 확률 출력을 이해하고, 일반 LLM·Serena·pi-jev·oh-my-jev·Pi Durable의 역할과 활용 경계를 구분한다.
Jev를 Pi에서 처음 접하면 “판단·분류·도구 탐색을 보조하는 확장” 정도로 이해하기 쉽다. 하지만 그것은 Jev를 붙인 pi-jev의 사용 맥락이다. Jev 자체는 TypeSafe AI가 제공하는 판단 모델이며, Pi 없이도 소프트웨어의 분류·라우팅·평가에 사용할 수 있다.
핵심 질문은 단순하다.
코드가 필요한 것은 긴 답변이 아니라 선택 하나인데, 매번 텍스트를 생성해야 할까?
Jev는 이 질문에 상태와 질문을 넣고, 타입이 정해진 값과 확률을 받는 방식으로 답한다. 일반 LLM을 대체하기보다, 생성 모델 옆에서 반복적인 판단을 맡기는 접근이다. 이 글은 설치 매뉴얼이 아니라 그 분업의 의미와 도입 기준을 정리한다. 제품 기능과 문서는 2026-10-04에 확인했다.
생성과 판단을 분리하는 이유
LLM(Large Language Model, 대규모 언어 모델)은 글과 코드를 생성할 수 있고 분류도 수행한다. Structured Outputs를 사용하면 스키마에 맞는 결과도 받을 수 있다. 따라서 “LLM은 분류하지 못하고 Jev만 가능하다”는 구분은 맞지 않는다.
차이는 소프트웨어가 소비할 작은 판단을 주된 작업으로 설계했는가에 있다.
예를 들어 고객 문의를 처리하는 시스템에는 서로 다른 작업이 섞여 있다.
- 문의가 결제 문제인지 배송 문제인지 고른다.
- 사람이 검토해야 할 상황인지 판단한다.
- 고객에게 보낼 답변을 작성한다.
앞의 두 작업은 선택과 분기이고, 마지막은 생성이다. 모두 하나의 생성 모델로 처리할 수도 있지만, 판단을 별도로 분리하면 코드가 실행 조건과 검토 경로를 직접 관리할 수 있다.
아래 화살표는 데이터와 판단 결과의 전달을 뜻한다. 외부 행동의 허용 여부는 정책 코드가 결정한다.
1
2
3
4
5
6
7
8
9
10
11
12
입력 상태 + 범위가 정해진 질문
↓
Jev의 판단
↓
값 + 확률 / confidence
↓
정책 코드
┌──────┼──────┐
↓ ↓ ↓
자동 분기 추가 확인 사람 검토
↓
필요하면 생성 LLM으로 답변·코드 작성
판단 모델의 출력은 행동 그 자체가 아니다. 환불 실행, 파일 삭제, 배포 같은 작업은 여전히 별도의 권한·검증·승인 규칙을 통과해야 한다.
Jev와 System One은 무엇인가
TypeSafe는 빠르고 구조화된 판단을 위한 모델 계열을 System One Models라고 부르며, Jev를 첫 공개 모델로 소개한다. System One이라는 이름은 『Thinking, Fast and Slow』의 빠른 직관적 판단과 느린 숙고의 구분에서 가져왔다. 인간의 사고 체계를 그대로 구현했다는 뜻은 아니다.
공식 소개에 따르면 TypeSafe는 새로운 모델 아키텍처, 병렬 sampler, RLCD(Reinforcement Learning for Calibrated Decisions, 확률이 실제 판단 정확도에 맞도록 학습하는 방식)를 사용한다. 이는 공급자가 설명하는 설계 방향이며, 여기서 내부 구현을 독립적으로 검증한 것은 아니다.
Jev의 이름은 William Stanley Jevons에서 가져왔다. 판단 비용이 낮아지면 기존 작업이 싸지는 데 그치지 않고, 이전에는 비용 때문에 하지 못했던 판단까지 더 많이 사용하게 된다는 기대를 담고 있다.
이 관점에서 중요한 것은 “더 작은 챗봇”이 아니라 프로그램에서 자주 호출할 수 있는 판단 인터페이스다.
입력과 출력 — state와 questions
공식 API의 기본 입력은 두 부분이다.
state: 판단에 필요한 상황. 텍스트나 구조화된 데이터를 넣는다.questions: 무엇을 판단할지와 허용된 답의 범위를 정의한다.
지원하는 질문의 핵심 형태는 세 가지다.
| 질문 타입 | 묻는 것 | 공식 문서의 반환값 |
|---|---|---|
choice | 정해진 후보 중 무엇을 고를까? | choice, 후보별 probabilities, confidence |
noul | 이 명제가 참일까? | 참일 확률인 noul, 0~1 |
score | 기준표의 어느 수준에 해당할까? | score, 수준별 probabilities, confidence |
score는 기준 없이 임의의 숫자를 만드는 질문이 아니라, 수준별 설명을 가진 rubric으로 평가하는 질문이다. noul은 별도의 confidence를 반환하지 않는다.
다음은 담당 팀을 고르는 질문의 최소 예시다. 설치·인증을 포함한 실행 코드가 아니라 요청 구조를 보여준다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
"state": {
"message": "이번 달 요금이 두 번 결제됐습니다."
},
"questions": {
"team": {
"type": "choice",
"instructions": "이 문의를 처리할 팀을 고르세요.",
"criteria": {
"billing": "결제와 환불 문제",
"shipping": "배송 문제",
"other": "위 분류에 해당하지 않거나 정보가 부족한 문의"
}
}
}
}
여기서 코드는 billing 같은 선택과 확률을 받아 분기한다. 결과에 대한 설명문을 다시 파싱할 필요가 없다. 실제 응답 필드와 SDK 사용법은 공식 문서를 기준으로 확인한다.
여러 질문을 한 요청에 넣을 수도 있다. 공식 문서는 각 질문이 같은 state를 대상으로 병렬·독립 평가된다고 설명한다. 따라서 한 질문의 결과를 다음 질문의 근거로 써야 한다면, 코드에서 결과를 조합하거나 후속 호출에 명시적으로 전달해야 한다.
확률, confidence, calibration은 다르다
확률을 반환한다는 점보다 중요한 것은 그 숫자를 어떻게 해석하고 검증하는가다.
- 확률은 후보나 명제에 대해 모델이 부여한 값이다.
confidence는 Choice·Score의 확률 분포를 요약한 통계량이다.- Calibration은 예측 확률과 실제 정답 빈도가 얼마나 맞는지를 평가하는 성질이다.
Calibration이 잘 맞는 모델이라면, 비슷한 조건에서 약 0.8의 확률을 준 예측들이 장기적으로 약 80% 맞는 것이 기대된다. 개별 답 하나가 반드시 맞는다는 보장은 아니다.
또한 confidence = 0.8을 “정답일 확률 80%”로 읽으면 안 된다. 예를 들어 공식 Choice 공식은 후보가 세 개이고 최고 확률이 0.8이면 다음처럼 계산한다.
1
2
3
confidence = (최고 확률 - 1 / 후보 수) / (1 - 1 / 후보 수)
= (0.8 - 1/3) / (1 - 1/3)
= 0.7
확률과 confidence가 다른 숫자인 이유다. 임계값을 만들 때 무엇을 기준으로 삼았는지 구분해야 한다.
실제 도입에서는 대표 데이터로 정확도와 calibration을 함께 측정하고, 잘못된 자동 실행의 비용에 따라 기준을 정한다. 문서 분류와 결제 취소에 같은 임계값을 적용할 이유는 없다. 정확한 규칙으로 검사할 수 있는 조건은 모델 판단 대신 코드로 검사한다.
왜 관심을 가질 만한가 — 생성 중심에서 판단 중심으로
Jev에서 흥미로운 지점은 기능 이름보다 다음 변화다.
- 작은 판단을 분리한다. 라우팅·필터링·평가 때문에 매번 긴 응답을 생성하는 구조를 다시 볼 수 있다.
- 불확실성을 코드에서 처리한다. 결과 하나를 무조건 실행하지 않고, 확률에 따라 추가 확인과 검토로 보낼 수 있다.
- 판단 기준을 조합한다. 여러 요소를 한 문장으로 뭉뚱그려 평가하기보다, 질문별 결과를 코드에서 가중·조합한다.
이는 주목할 설계 방향이지, 모든 작업에서 성능 우위가 입증됐다는 뜻은 아니다. TypeSafe는 큰 속도·비용 개선을 발표했지만, 발표 글에서도 짧은 입력의 유리함, 평가 구성의 편향 가능성, 실제 환경에서 개선 폭이 달라질 수 있음을 설명한다.
이 글에서는 자체 벤치마크를 수행하지 않았다. 공급자 데모의 배수를 그대로 도입 효과로 예상하기보다, 실제 데이터와 네트워크 지연을 포함한 전체 흐름으로 검증해야 한다. 커뮤니티 프로젝트가 등장했다는 사실과 대규모 도입이 검증됐다는 주장도 구분한다.
LLM·Serena·MCP와는 어떤 관계인가
비교축을 기능 수가 아니라 시스템에서 맡는 역할로 잡으면 혼동이 줄어든다.
| 대상 | 주된 역할 | Jev와의 관계 |
|---|---|---|
| 일반 생성 LLM | 설명·답변·코드 생성과 범용 추론 | 판단을 분담할 수 있지만 기능이 완전히 배타적이지는 않다 |
| Jev | 범위가 정해진 질문의 구조화된 판단 | 판단 결과를 정책 코드에 전달한다 |
| Serena | 심볼 기반 코드 탐색·참조 검색·수정 도구 제공 | Jev가 도구 선택을 보조하고 Serena가 코드 작업을 수행할 수 있다 |
| MCP(Model Context Protocol) | 외부 도구·리소스를 연결하는 프로토콜 | 모델이나 코드 분석 도구 자체가 아니다 |
따라서 “Jev도 Serena 같은 MCP인가?”라는 질문에는 에이전트 능력을 보강할 수 있다는 점은 비슷하지만, 판단 모델과 코드 작업 도구는 역할이 다르다고 답하는 편이 정확하다. Jev 연동이 반드시 MCP를 통해야 하는 것도 아니다.
생태계 — Jev, pi-jev, oh-my-jev
이름이 비슷해도 모델, 연동 확장, 실험 도구킷을 나눠서 봐야 한다.
pi-jev — Pi에 판단을 연결하는 확장
TheoOliveira/pi-jev는 Jev를 Pi 코딩 에이전트에 연결한다. 대표 도구는 다음과 같다.
jev_find_tools: 등록된 비활성 도구 중 작업에 필요한 도구를 찾아 추가 활성화한다.jev_find_skill: 작업에 맞는SKILL.md를 추천한다.jev_evaluate: 선택·예/아니오·점수 형태의 판단을 요청한다.
도구 탐색은 인터넷에서 새 도구를 찾아 설치한다는 의미가 아니다. 이미 등록된 후보를 평가해, 현재 모델에 제공할 도구를 고르는 맥락이다.
현재 프로젝트 문서에는 선택적으로 켜는 자동 라우팅, 도구 호출 검사, compaction 보조, 서브에이전트 연동 등도 설명돼 있다. 그러므로 위 세 도구가 Jev나 확장의 모든 기능이라고 단정하면 안 된다. 일부 기능에는 로컬 heuristic도 쓰이므로, 확장 기능 전체가 매번 Jev 호출이라는 해석 역시 피한다.
oh-my-jev — 판단 모델을 비교하고 학습하는 작업대
iamupd/oh-my-jev는 Jev-style 판단 모델을 실행·테스트·벤치마크·파인튜닝하는 독립 프로젝트다. TypeSafe 호환 /v1/systemone 인터페이스와 웹 playground를 제공하며, 정확도뿐 아니라 calibration 평가를 다룬다.
여기서 Jev-style은 TypeSafe의 Jev 모델 자체라는 뜻이 아니다. README에 따르면 로컬 모델은 한 번의 forward pass에서 선택지 label의 logits를 읽는다. 인터페이스가 호환돼도 아키텍처·학습 방법·확률 품질이 같다는 보장은 없다. 해당 프로젝트도 TypeSafe와의 비제휴를 명시한다.
또한 apetcu/oh-my-jev라는 동명 프로젝트가 있다. 이쪽은 oh-my-pi에 Jev 기반 도구 호출 gate 등을 붙이는 플러그인이다. 링크를 공유할 때 이름만 적지 말고 저장소 소유자까지 확인해야 한다.
자가호스팅 관점에서 보면 Jev는 LSP(Language Server Protocol) 서버와 비슷하게 이해할 수 있다. 에디터가 코드 완성·진단을 별도 LSP 서버에 질의하듯, Pi는 작은 판단을 별도 판단 서버에 질의한다.
1
2
3
4
5
기본 구조:
Pi → pi-jev → TypeSafe hosted Jev API
자가호스팅 구조:
Pi → pi-jev → PI_JEV_BASE_URL → oh-my-jev /v1/systemone
이 구조에서 달라지는 것은 판단을 맡는 대상이다. 기본 TypeSafe 연동은 외부 API와 통신한다. 반면 oh-my-jev를 mock이나 로컬·내부망 GPU 모델로 실행하면 TypeSafe API 호출 없이 같은 형식의 판단 endpoint를 제공할 수 있다. 단, oh-my-jev의 백엔드를 typesafe로 잡으면 결국 서버가 다시 TypeSafe API를 호출하므로 외부 통신을 없앤 것이 아니다.
따라서 oh-my-jev의 실용성은 환경에 따라 다르다. macOS 단독 환경에서는 로컬 실모델 운용이 CUDA 요구 때문에 제한적이고, mock은 연결 테스트용에 가깝다. 실제 대체 효과는 NVIDIA GPU가 있는 로컬 머신이나 내부망 서버에서 omj serve를 띄우고 PI_JEV_BASE_URL로 연결할 때 생긴다. 그 전까지는 생산성 도구라기보다 Jev-style 모델의 품질·비용·calibration을 비교하는 실험장에 가깝다.
Pi Durable — 판단이 아니라 실행의 지속성
Pi Durable은 다른 축이다. 대화·모델 호출·도구 호출·상태를 저장하고, 프로세스가 중단된 뒤 작업을 이어갈 수 있게 하는 하네스다. 공식 README는 API가 예고 없이 바뀔 수 있는 실험적 패키지라고 명시한다.
Jev가 어떤 분기를 택할지를 다룬다면 Pi Durable은 실행 상태를 어떻게 보존하고 복구할지를 다룬다. 함께 사용할 여지는 있지만, Jev의 하위 기능이나 필수 의존성은 아니다.
복구 가능하다는 말이 모든 외부 행동을 안전하게 다시 실행한다는 뜻도 아니다. Pi Durable은 중단된 도구 호출의 재실행을 replay-safe 선언에 따라 구분한다. 결제나 배포처럼 부작용이 있는 작업은 별도의 멱등성과 복구 설계가 필요하다.
언제 쓰고, 언제 쓰지 않을까
Jev를 검토할 만한 조건은 다음과 같다.
- 허용된 답의 범위가 분명한 판단이 반복된다.
- 단순 문자열·정규식·조건문만으로 처리하기에는 의미 해석이 필요하다.
- 낮은 확신의 결과를 보낼 추가 확인·검토 경로가 있다.
- 대표 데이터로 정확도, calibration, 지연, 비용을 평가할 수 있다.
반대로 다음 경우에는 기존 코드나 생성 LLM이 더 자연스럽다.
- 스키마·권한·테스트 결과처럼 결정적으로 검사할 수 있는 조건이다.
- 긴 설명, 새로운 코드, 자유로운 답변을 생성해야 한다.
- 여러 단계의 조사·계산이 필요한데 필요한 상태가 아직 없다.
- 오류를 허용할 수 없는데 판단 모델만으로 승인하려 한다.
질문 설계도 중요하다. “이 변경은 좋은가?”보다 보안·호환성·테스트 여부를 나눠 묻는 편이 기준을 관리하기 쉽다. 다만 테스트 통과 여부는 실제 테스트 결과를 확인해야 한다. 모델에게 diff만 보여주고 테스트 통과를 추측하게 해서는 안 된다.
TypeSafe의 “환각 없음” 표현 역시 범위를 좁혀 읽어야 한다. 허용된 출력 타입과 후보 밖의 값을 만들지 않는 것과, 허용된 후보 중 틀린 답을 고르지 않는 것은 다르다. 높은 confidence도 권한 검사나 보안 경계를 대체하지 않는다.
결론
Jev의 핵심은 “판단·분류·도구 탐색 보조”라는 기능 목록보다 생성과 판단을 분리하고, 불확실성을 코드의 실행 정책에 연결하는 방식이다.
Pi에서는 도구와 스킬 선택으로 이 구조를 접할 수 있고, oh-my-jev 같은 작업대에서는 판단 모델의 품질을 비교할 수 있다. 그러나 좋은 출력 형식만으로 좋은 자동화가 완성되지는 않는다. 질문의 범위, 실제 데이터에서의 확률 품질, 행동별 임계값, 실패 시 검토 경로가 함께 설계돼야 한다.