고객 문의를 어느 부서로 보낼지, 에이전트의 도구 호출을 허용할지, 어떤 모델에 작업을 맡길지. AI를 서비스에 붙이다 보면 긴 답변보다 이런 짧은 판단이 필요한 순간이 많다. TypeSafe AI가 2026년 9월 15일 공개한 Jev는 여기에 초점을 맞춘 ‘결정 모델’이다. 소프트웨어가 바로 받아 쓸 수 있도록 선택·점수·확률을 반환한다.
Jev 공개 이후에는 Laya, DiffusionGemma 기반 OpenJev 등 비슷한 기능을 제공하는 오픈소스 프로젝트가 잇따랐다. 흔히 ‘Jev 클론’으로 묶이지만 구현 방식은 제각각이다. 모델을 따로 학습한 프로젝트도 있고 기존 모델에서 답을 읽어 오는 방식이나 API만 바꾼 도구도 있다. 어느 쪽도 TypeSafe가 내놓은 공식 오픈소스판은 아니다.
이 글은 2026년 9월 21일 확인한 공개 자료를 바탕으로 각 프로젝트의 차이와 도입할 때 살펴볼 점을 정리했다.
Jev는 어떤 일을 하나
Jev에는 판단에 필요한 정보와 개발자가 정한 질문을 함께 보낸다. 그러면 Choice, Score, Noul 등 정해진 타입에 맞춰 결과와 확률을 돌려준다.
예를 들어 고객 문의에 환불, 기술지원, 영업이라는 선택지를 붙여 보내면 각 선택지의 확률을 받는다. 애플리케이션은 가장 높은 확률이 기준을 넘을 때만 담당 부서를 자동 배정하고 애매한 문의는 사람이나 더 큰 LLM에 넘길 수 있다.
TypeSafe AI는 병렬 샘플링과 ‘확률 보정 결정 강화학습(RLCD)’을 사용했다고 설명한다. 공개한 가격은 입력 100만 토큰당 0.042달러이며 응답 시간은 70~500밀리초다. 속도는 회사의 초기 자체 평가 결과이므로 실제 업무에서도 같은 수준이 나오는지는 따로 확인해야 한다.
일반 LLM으로도 이런 판단을 할 수 있다. 다만 생성된 텍스트를 애플리케이션이 해석하고 형식을 검사하는 과정이 뒤따른다. 하루에도 수천 번 반복하는 분류나 승인 작업에서는 그만큼의 지연과 처리 비용도 무시하기 어렵다.
물론 요약, 설명, 코드 작성처럼 답을 자유롭게 만들어야 하는 작업에는 여전히 생성형 모델이 필요하다. Jev의 대안을 고를 때도 맡기려는 일이 단순한 분류인지 설명까지 필요한 판단인지부터 정해야 한다.
질문과 선택지를 설계하는 일도 중요하다. 선택지가 서로 겹치거나 판단에 필요한 정보가 빠지면 확률이 높게 나와도 답은 틀릴 수 있다. ‘환각이 없다’는 설명 역시 정해진 출력 형식을 벗어나지 않는다는 뜻으로 읽어야 한다. 판단의 정확성까지 보장하는 말은 아니다.
주요 대안 비교
각 도구가 답을 만드는 방식과 활용하기 좋은 상황을 비교하면 다음과 같다.
| 선택지 | 작동 방식 | 잘 맞는 상황 | 주의할 점 |
|---|---|---|---|
| Jev | 미리 정한 질문에 선택·점수·확률 반환 | 짧은 판단을 빠르게 반복하는 자동화 | 초기 접근 단계이며 성능은 자체 평가 중심 |
| LLM 구조화 출력 | GPT·Claude 등 일반 LLM이 JSON 스키마에 맞춘 결과나 도구 인자를 생성 | 판단과 설명·코드·멀티모달 처리를 함께 할 때 | 생성 비용과 지연이 발생하며 답의 내용도 검증해야 함 |
| Laya | 인코더 기반 모델을 학습해 선택지별 확률을 계산 | 직접 학습·보정할 수 있는 로컬 결정 모델 | 기본 모델과 업무별 튜닝 모델의 성능 차이가 큼 |
| DiffusionGemma 기반 OpenJev | 고정된 답변 위치의 토큰 확률을 병렬로 읽음 | Jev 호환 API와 공개 가중치로 결정 서버 운영 | 추론 엔진 수정이 필요하며 Jev와 내부 구조가 같다는 뜻은 아님 |
| Bespoke Nimble·kev | Qwen 계열에 LoRA 등을 적용해 결정 작업에 맞춤 | 학습 레시피를 활용한 업무별 모델 실험 | 초기 연구 구현으로 일반화·확률 보정을 따로 검증해야 함 |
| SemIf | 기존 공개 모델에서 선택지별 확률을 읽음 | 추가 학습 전 비교 기준 마련 | Jev의 비공개 학습법을 재현한 것은 아님 |
| jevlike | 선택지 수가 달라져도 처리할 수 있는 작은 점수 모델을 학습 | 경량 모델 연구, 프로토타이핑 | 직접 학습하고 평가해야 하는 초기 구현 |
| LocalJev | 일반 채팅 API에서 확률 JSON을 생성해 Jev 응답으로 변환 | 기존 로컬 추론 서버와 Jev SDK 연결 | 모델이 적어 낸 확률이며 토큰 확률을 직접 읽는 방식과 다름 |
| GLiClass | 제로샷 라벨 분류를 한 번의 추론으로 수행 | 라벨이 자주 바뀌는 텍스트 분류 | Jev와 같은 확률 보정이나 API 계약은 별도 검증 필요 |
| scikit-learn 분류기 | 라벨 데이터로 분류기를 학습해 로컬 추론 | 업무 범주가 안정적이고 데이터가 충분할 때 | 새 질문과 선택지를 즉시 처리하려면 재학습 필요 |
TypeSafe가 공개한 system-one-adapter-python으로는 OpenAI나 Anthropic 모델을 같은 평가 인터페이스에서 호출할 수 있다. Jev 접근 권한을 기다리는 중이거나 모델을 직접 운영하기 어렵다면 이 어댑터로 기존 LLM부터 시험해 볼 수 있다.
Laya: 직접 학습할 수 있는 오픈소스 결정 모델
Laya는 Convai Innovations가 개발한 독립 프로젝트다. 영어용 모델은 ModernBERT-large 기반으로 파라미터가 4억 2,100만 개다. 다국어용은 mmBERT-base를 바탕으로 하며 3억 2,200만 개다. 둘 다 문장을 생성하지 않고 choice, score, noul 질문에 답한다. 개발진은 RLCD로 학습했다고 설명하며 가중치를 Apache 2.0 라이선스로 공개했다.
Laya를 검토한다면 기본 모델과 업무에 맞게 추가 학습한 모델을 구분해야 한다. 저장소의 typed-decisions 평가에서 기본 모델의 정확도는 약 34~36%였지만 파인튜닝한 laya-typed-decisions는 76.6%를 기록했다. 작은 모델도 업무에 맞춰 학습하면 성능이 크게 달라질 수 있다는 결과다. 곧바로 모든 업무에 적용할 수 있다는 뜻은 아니다.
개발진이 T4 GPU에서 측정한 질문 하나의 응답 시간은 영어용 39.5밀리초, 다국어용 32.8밀리초다. 비교 대상으로 실은 Jev 수치는 외부 자료에서 가져왔으며 프롬프트와 표본 수가 다르다고 밝혔다. 같은 조건에서 맞붙인 결과로 보기는 어렵다.
선택지가 많아지면 각 선택지에 배정할 수 있는 토큰 수가 부족해지는 제약도 있다. 확률 보정 여부에 따라 수치가 달라지는 만큼, 한국어 업무에 쓸 때는 다국어 모델로 직접 평가하는 과정이 필요하다. 가중치를 무료로 쓸 수 있어도 서버 운영비와 학습 비용은 든다.
DiffusionGemma를 결정 모델로 쓰는 방법
DiffusionGemma를 Jev처럼 쓰는 구현은 추론 방식을 바꾼 사례다. Matt Mastracci가 올린 vLLM PR #57250은 답변 템플릿의 위치를 고정한 뒤, 선택지에 해당하는 토큰의 확률을 읽도록 한다. 여러 질문의 답을 병렬로 읽고 결과가 불확실하면 추가로 샘플링할 수 있다. Jev용 가중치를 새로 학습해 공개한 것은 아니다. 자료를 확인한 시점에는 이 PR이 아직 병합되지 않았다.
이 방식을 서버로 구현한 것이 razorback16/OpenJev다. DiffusionGemma 26B-A4B와 수정된 vLLM을 사용하며 Jev의 /v1/systemone 요청·응답 형식을 지원한다. TypeSafe SDK의 접속 주소를 바꿔 시험해 볼 수 있어 기존 코드에 연결하기 쉽다. 다만 허용하는 선택지 수 등 세부 지원 범위에는 차이가 있다. API가 호환되더라도 정확도와 확률 보정은 별도로 평가해야 한다.
GitHub Next의 LocalJev도 DiffusionGemma를 쓰지만 접근법이 다르다. 일반 채팅 API에 확률을 JSON으로 작성하도록 요청하고 그 결과를 검증·정규화해 Jev 형식으로 돌려준다. 여기서 확률은 모델이 텍스트로 적어 낸 숫자다. 개발진 역시 토큰 확률을 직접 읽는 OpenJev와 수학적으로 같지 않다고 설명한다.
그 밖의 클론: Nimble·kev·SemIf·jevlike
Bespoke Nimble은 모델을 추가 학습한 사례다. Bespoke Labs는 Qwen3.5-9B에 LoRA를 적용하고 모델, 데이터, 학습 방법을 공개했다. Jev에서 증류한 모델은 아니라고 밝혔다. 텍스트와 선택지 또는 참거짓 질문을 받으면 후보 토큰의 점수로 답을 정하므로 JSON 문장을 생성할 필요가 없다.
현재 Nimble의 입력 상한은 2,048토큰이며 한 질문의 답을 다른 질문에 반영하지 못한다. 확률을 해석할 때도 주의가 필요하다. 개발진의 설명처럼 후보 확률의 합이 1이 되도록 맞췄다고 해서, 0.9로 표시된 답이 실제로 90%의 확률로 맞는 것은 아니다.
Jared Palmer의 kev-0.5b는 Qwen2.5-0.5B에 LoRA와 포인터 헤드를 결합한 경량 연구 모델이다. 포인터 헤드는 선택지의 위치에 점수를 매기는 역할을 한다. 로컬에서 Jev형 API를 시험하기에 적합한 작은 모델이지만 개발자는 실제 서비스용으로 소개하지 않는다. 공개한 모델이 학습 데이터의 출처를 벗어난 자료에서도 잘 작동하는지는 아직 측정하지 않았다고 밝혔다.
SemIf는 기존 공개 모델에서 선택지별 확률을 읽는 프로젝트다. 처음에는 OpenJev라는 이름으로 공개됐다가 이름을 바꿨다. 앞서 살펴본 razorback16/OpenJev와는 별개이므로 관련 자료를 찾을 때 저장소 소유자도 확인하는 편이 좋다.
jevlike는 작은 점수 모델을 직접 학습해 보려는 개발자를 위한 초기 구현이다. 문맥과 선택지를 받아 한 번에 확률을 계산하며 선택지 개수가 달라져도 처리할 수 있다. 기본 구성은 바이트 임베딩부터 학습하고 이미 학습된 Hugging Face 인코더를 고정해 쓰는 방법도 제공한다.
‘클론’이라는 이름만으로는 이런 차이가 잘 드러나지 않는다. 도입을 검토할 때는 학습된 가중치가 있는지 직접 추가 학습해야 하는지 확률을 어떻게 계산하는지부터 확인해야 한다.
내 업무에는 무엇이 맞을까
에이전트를 운영한다면 도구 호출 전 위험도를 검사하거나 작업을 맡길 모델을 고르는 단계부터 따로 떼어 볼 수 있다. 판단 결과와 확률을 로그에 남겨 두면 어느 수준까지 자동으로 처리하고 언제 사람에게 넘길지 정하는 데 도움이 된다.
분류할 항목이 잘 바뀌지 않고 라벨 데이터도 충분하다면 기존 로컬 분류기가 더 간단한 선택일 수 있다. 규칙이 자주 바뀌거나 긴 문맥을 읽고 이유까지 설명해야 한다면 구조화 출력을 지원하는 LLM이 편하다. Jev와 오픈소스 결정 모델은 이 가운데 반복되는 판단의 비용과 지연을 줄일 수 있는지 살펴볼 만하다.
한계와 주의할 점
공개된 초기 벤치마크만으로 어느 모델이 더 낫다고 단정하기는 어렵다. TypeSafe의 속도·비용 비교는 회사가 만든 작업 흐름과 자체 기준을 사용했다. 회사도 지금의 가격을 장기적으로 유지할 수 있을지는 더 지켜봐야 한다고 밝혔다.
자동 환불이나 계정 잠금, 의료·금융 심사처럼 오판의 대가가 큰 업무에서는 확률 기준 하나만으로 자동화 범위를 정하기 어렵다. 판단을 보류할 구간과 사람이 다시 검토할 절차가 필요하다. 입력에 악의적인 지시나 서로 모순되는 조건이 섞였을 때도 시험해 봐야 한다.
오픈소스 모델은 데이터와 운영 환경을 직접 관리할 수 있다는 장점이 있다. 그만큼 모델 라이선스, 필요한 GPU 메모리, 업데이트 방법도 직접 챙겨야 한다. 데모가 잘 돌아가는 것과 실제 서비스에서 꾸준히 쓸 수 있는 것은 다른 문제다.
앞으로 확인할 것들
앞으로는 같은 질문과 조건으로 모델을 비교한 독립 평가가 중요해질 것이다. Jev와 오픈소스 결정 모델, 구조화 출력 LLM, 기존 분류기를 놓고 응답 시간과 비용뿐 아니라 정확도와 확률 보정까지 함께 볼 필요가 있다.
개발 도구가 얼마나 갖춰지는지도 관건이다. SDK와 연결 도구가 늘면 결정 모델을 기존 에이전트에 붙이기 쉬워진다. 한편 일반 LLM의 병렬 분류와 구조화 출력 기능이 개선되면 판단만을 위한 모델을 따로 운영할 이유가 줄어들 수도 있다.
자주 묻는 질문
Jev는 ChatGPT 같은 챗봇의 대체재인가?
Jev는 선택지를 고르거나 점수를 매기고 처리 방향을 정하는 데 맞춰져 있다. 설명이나 요약도 필요하다면 생성형 LLM과 함께 쓰는 편이 좋다.
Jev의 가장 가까운 대안은 무엇인가?
직접 학습할 모델을 찾는다면 Laya·Nimble·kev를, Jev 호환 서버가 필요하다면 DiffusionGemma 기반 OpenJev를 살펴볼 수 있다. 기존 모델로 먼저 실험하려면 SemIf도 후보가 된다.
Laya는 Jev의 공식 오픈소스판인가?
아니다. Laya는 독립 프로젝트다. 비슷한 질문 타입을 지원하지만 Jev의 가중치나 내부 구현을 공개한 모델은 아니다.
DiffusionGemma 기반 구현은 전부 파인튜닝 모델인가?
이 글에서 소개한 OpenJev는 추론 방식을 바꿔 토큰 확률을 읽는다. LocalJev는 채팅 API가 작성한 확률 JSON을 변환한다. 둘 다 새 가중치를 학습한 사례와는 구분해야 한다.
오픈소스 대안이 Jev와 같은 성능을 내나?
현재 자료만으로는 같다고 말하기 어렵다. 비슷한 입력과 출력을 지원해도 학습 데이터와 구현이 다르므로 실제로 맡길 업무의 데이터로 비교해야 한다.
라벨 데이터가 있다면 Jev가 꼭 필요한가?
분류 항목이 일정하고 라벨이 충분하다면 scikit-learn 같은 기존 분류기나 업무 전용으로 학습한 모델이 더 저렴하고 관리하기 쉬울 수 있다.
실제 도입은 어떻게 시작해야 하나?
처음에는 결과만 기록하면서 기존 LLM이나 분류기와 비교하는 편이 좋다. 잘못 판단했을 때의 비용, 응답 시간, 판단을 보류한 비율을 확인한 뒤 자동 처리 범위를 정할 수 있다.
작은 업무 하나부터 비교해 보기
Laya, Nimble, kev, DiffusionGemma 기반 구현이 등장하면서 직접 운영할 수 있는 결정 모델의 선택지도 늘었다. 다만 추가 학습에 시간을 쓸 수 있는지 어떤 장비를 쓸지, 얼마나 복잡한 판단을 맡길지에 따라 맞는 도구는 달라진다.
처음부터 전체 작업을 바꾸기보다는 자주 반복하는 판단 하나를 골라 Jev와 대안 두 가지 정도를 비교해 보는 편이 낫다. 같은 데이터에서 얼마나 자주 틀리는지 틀릴 때도 높은 확률을 내놓는지 살펴보면 자동화를 맡길 수 있는 범위가 한결 분명해진다.