그래서 Jev가 뭔데?

3줄 요약

1. Jev는 주어진 상황에서 선택지·점수·확률을 반환하는 의미 판단 모델이다. (LLM 아님)
2. 반복적인 분류, 행동 선택의 비용을 줄일 수 있음.
3. 허용할 수 있는 오류율로 얼마나 많은 일을 끝낼 수 있는지가 중요함.

---

1. 몇백 배 빠르다는데, 산수는 못한다고?

누구는 기존 모델보다 훨씬 빠르고 저렴하다고 한다.

그런데 “산수도 못한다”는 이야기도 나온다.

 

TypeSafe AI가 2026년 9월 15일 공개한 Jev는 답변 생성보다 바로 사용할 판단을 반환하는 데 초점을 맞춘 모델이다.

회사는 이 계열을 System One이라고 부른다.

“이 고객에게 어떻게 답하면 좋을지 설명해 줘.”

“이 문의를 배송팀과 결제팀 중 어디로 보낼까?”

 

첫 번째는 답변을 작성하는 일이다. -> LLM이 할 일이다.

두 번째는 프로그램의 다음 처리를 위해 선택하는 일이다. -> Jev가 할 일이다.

 

프로그램 곳곳에 넣을 수 있는 의미 판단 함수를 제공하려는 접근이다.

입출력 형식은 함수처럼 다룰 수 있지만, 반환된 판단이 의미상 정답이라는 보장은 없다.

 

2. 고객 문의 하나로 이해해 보자

 

고객이 이렇게 말했다고 하자.

“배송이 늦는 건 괜찮아요. 결제가 두 번 된 것부터 확인해 주세요.”

키워드만 보면 ‘배송’도 있고 ‘결제’도 있지만 지금 먼저 처리해야 할 요청은 결제 문제에 가깝다.

이때 프로그램에 필요한 것은 어느 팀으로 보낼지, 고객이 무엇을 주장하는지, 추가 확인이 필요한지가 더 중요하다.

Jev에는 이 문장과 필요한 참고 정보를 주고 이런 판단을 물을 수 있다.

반환된 결과를 받아 다음 업무로 연결하는 것은 프로그램이다.

 

여기서 한 단계만 더 생각해 보자.

고객이 중복 결제를 주장한다는 것과 실제로 중복 결제가 발생했다는 것은 다르다.

전자는 문장의 의미를 읽는 일이다.

후자는 결제 기록을 조회하고 상태를 대조하는 일이다.

고객의 의도를 잘 분류했다고 곧바로 돈을 돌려주면 안 된다.

이 작은 예시에 Jev의 설계 철학이 거의 다 들어 있다.

의미는 모델이 읽고, 사실은 조회하고, 계산과 실행은 코드가 맡는다.

 

모델에게 맡길 일을 분명하게 나누는 것이다.

3. 개발자가 알아둘 인터페이스는 세 가지다

Jev의 기본 입력은 상태와 질문이다.

state에는 판단할 내용과 참고 사실을 넣고, questions에는 무엇을 판단할지 적는다.

질문의 instructions는 판단할 내용, criteria는 각 답이 뜻하는 바를 설명한다.

HTTP API의 기본 호출 경로는 POST /v1/systemone이다.

질문 타입은 Noul, Choice, Score 세 가지다.

 

타입	쉽게 말하면	예시
Noul	“이 조건이 맞나?”	고객이 환불 실행을 요청했는가?
Choice	“이 후보 중 무엇인가?”	배송·결제·계정·기타 중 어느 업무인가?
Score	“설명된 등급 중 어디에 가까운가?”	영향 없음·일부 기능 장애·서비스 사용 불가 중 어느 수준인가?

 

Noul은 yes에 대한 확률을 반환한다.

Choice는 선택한 항목과 후보별 확률을, Score는 등급별 확률과 그 가중평균을 반환한다.

Choice와 Score에는 분포를 요약한 confidence도 붙는다.

 

다음은 형식을 보여 주기 위해 만든 요청 예시다.

{
  "model": "jev-1.13.0",
  "state": {
    "message": "환불해 달라는 건 아니고, 언제 배송되는지만 알려 주세요."
  },
  "questions": {
    "requested_work": {
      "type": "choice",
      "instructions": "고객이 지금 요청하는 업무는 무엇인가?",
      "criteria": {
        "delivery_schedule": "배송 예정일이나 진행 상황 안내",
        "refund_execution": "실제 환불 처리 요청",
        "other": "어느 쪽에도 해당하지 않거나 판단할 정보가 부족함"
      }
    }
  }
}

 

 

requested_work 같은 질문 ID는 응답을 찾는 코드용 키이며, 모델에 질문의 의미를 전달하는 용도가 아니다.

필요한 뜻은 instructions와 criteria에 적어야 한다.

또한 선택지가 셋이라고 해서 세 가지 중 현실의 정답이 반드시 포함돼 있는 것은 아니다.

 

후보를 잘 만드는 일도 개발자의 책임이다.

어느 후보도 맞지 않거나 정보가 부족한 경우를 처리할 경로도 필요하다.

Jev 문서상 제한은 요청 전체는 64k 토큰, state와 가장 긴 질문의 합은 32k 토큰이다.

Choice는 최대 255개 후보, Score는 2~10개 등급을 사용한다.

여러 질문을 한 번에 보낼 수 있어도 입력과 질문을 무제한으로 늘릴 수 있는 것은 아니다.

4. 왜 이런 모델이 필요해졌을까?

LLM은 사용자 질문 하나에 여러번의 문서를 찾고, 결과를 점검하는 등 tool calling, loop를 도는데 매 단계마다 생성형 모델에 설명과 구조화된 답을 작성하게 하면, 필요한 것은 작은 선택인데도 출력과 왕복에 드는 비용이 누적된다.

TypeSafe가 제안하는 방향은 AI의 결과를 사람이 읽는 문장에서 소프트웨어가 조합하는 작은 판단으로 옮겨 보자는 것이다.

Jev라는 이름에는 판단의 단가가 내려가면 지금까지 비용 때문에 하지 못했던 사용이 늘어날 것이라는 기대가 담겨 있다.

5. 기술적으로는 뭐가 새로운가?

분류 자체가 새로 발명된 것은 아니다

문장을 분류하고, 자연어로 설명한 라벨에 맞추고, 후보별 점수를 계산하는 연구는 Jev 이전에도 있었다.

2025년의 GLiClass는 동적으로 주어진 라벨을 처리하는 분류를 연구했고, 다중 라벨 분류에 PPO 기반 강화학습을 적용하기도 했다.

기존 생성형 LLM도 구조화된 출력을 만들 수 있다.

OpenAI의 Structured Outputs처럼 출력 가능한 토큰을 제한해 스키마를 따르게 하는 방법도 공개돼 있다.

같은 판단을 같은 품질로 얻을 때 드는 시간·비용·운영 복잡도다.

RLCD는 ‘결정과 그 확률’을 학습 목표로 삼는다

TypeSafe는 Jev가 RLCD, Reinforcement Learning for Calibrated Decisions로 학습됐다고 설명한다.

좋은 문장을 작성하는 것에 초점을 맞추기보다 제한된 판단을 내리고 불확실성을 확률로 표현하도록 학습한다는 것이다.

공개 API가 반환하는 것은 임베딩 벡터가 아니라 질문과 기준에 따른 판단이다.

6. ‘확률을 준다’는 것이 왜 중요한가?

분류 결과만 받으면 코드는 일단 그 결과를 믿고 처리하거나, 전부 다시 검사해야 한다.

확률이 쓸 만하다면 추가 확인이 필요한 사례를 구분하는 데 활용할 수 있다.

여기서 등장하는 개념이 확률 교정, calibration이다.

예를 들어 어떤 사건을 참일 확률 80%로 평가한 사례들을 많이 모았을 때, 실제로 참인 비율도 약 80%라면 그 구간에서 확률이 잘 맞는 것이다.

개별 답에 대한 정답 보증이 아니라, 여러 예측을 모았을 때의 성질이다. 

그런데 Jev의 confidence는 정답지를 보고 측정한 정확도가 아니고 반환된 확률분포의 집중도를 요약한 값이다.

따라서 confidence=0.9를 그대로 “90% 맞는다”로 읽으면 안 된다.

네이티브 Noul에는 이 필드가 따로 없고, Noul의 0.5도 강도가 중간이라는 뜻이 아니라, yes와 no의 확률이 비슷하다는 뜻이다.

Score에도 비슷한 함정이 있는데 등급을 0·1·2로 정했을 때 다음 두 분포의 평균은 모두 1이다.

[0,   1, 0  ] → 중간 등급에 확률이 모여 있다.
[0.5, 0, 0.5] → 양쪽 끝 등급 사이에서 갈린다.

 

같은 점수라도 해석은 다르다. Score 하나만 저장하면 그 차이를 잃는다.

병렬 평가가 확률의 일관성을 보장하지는 않는다

질문들을 서로의 답을 참조하지 않고 계산한다는 것은, 그 판단들이 통계적으로 독립이라는 뜻이 아니다.

TypeSafe의 Jev 1.13 한계 문서는 같은 환불 여부를 Noul과 yes/no Choice로 물었을 때 다음처럼 다른 값이 나온 사례를 공개한다.

질문 형태	해당 사례의 반환값
Noul의 yes 확률	0.22
Choice의 yes 확률	0.01
Choice의 no 확률	0.99

 

따라서 Noul에서 조정한 임계값을 Choice에 그대로 옮기거나, 별도로 물은 질문들의 확률이 예상한 수학적 관계를 만족한다고 가정하면 안 된다.

또한 “후보 중 어느 것이 가장 적절한가?”라는 Choice와 “각 후보가 실제로 적절한가?”라는 여러 Noul은 다른 질문이다.

전자는 상대적인 선택이고, 후자는 후보마다 조건이 성립하는지를 묻는다.

모든 후보가 부적절할 가능성이 있다면 그것을 별도로 표현해야 한다.

질문을 나누는 것과, 나뉜 답을 올바르게 조합하는 것은 별도의 설계 문제다.

‘환각이 없다’는 표현도 좁게 읽어야 한다

답을 배송, 결제, 계정으로 제한하면 존재하지 않는 네 번째 부서 이름을 만들어 내는 문제를 줄일 수 있다.

하지만 배송 문의를 결제 문의로 잘못 분류하는 것은 여전히 가능하다.

형식 준수, 의미상 정답, 적절한 확률, 안전한 실행은 다른 문제다.

공식 개발 지침도 타입 보장은 진실의 보장이 아니며, confidence가 실행 권한을 뜻하지 않는다고 구분한다.

7. 어떤 공개 구현과 실험이 나왔나?

브라우저와 컴퓨터 조작: 선택과 실행의 분업

Browser Use의 공개 데모는 항공편 검색을 약 7초의 측정 구간 안에 마친 사례를 보여 준다.

Jev가 행동과 대상을 고르고, Mercury가 도시명 같은 입력 문자열을 생성한다.

측정은 초기 페이지 관측 이후 첫 판단부터 DONE 선택까지다.

브라우저 준비·초기 이동과 별도의 최종 결과 검증은 구간 밖이며, 항공권 예약 완료를 측정한 것은 아니다.

같은 모델과 설정으로 실행 코드를 바꾼 비교도 있다.

같은 작업을 각각 세 번 실행했을 때 중앙 시간은 9.450초에서 7.092초로 줄었다.

모델 교체가 아니라 브라우저 관측·실행 코드를 최적화한 비교다.

다만 한 작업·한 브라우저 프로필에서의 작은 표본이므로 범용 에이전트의 속도나 신뢰도로 일반화할 수는 없다.

Cua의 jev-use는 역할 분담을 더 선명하게 보여 주는 공개 프리뷰 예제다.

페이지를 관측하고 실행 가능한 후보를 만들면 Jev가 하나를 고르고, Driver가 실행한다.

마지막에는 별도의 /state를 확인해 제출 결과를 검증한다.

이 예제는 mock 실행과 실제 Jev 호출도 구분한다.

Mock 검증은 관측·실행·사후조건 확인 흐름을 점검하지만, 실제 Jev 서비스가 같은 판단을 했다는 증거는 아니다.

 

관측 → 후보 구성 → 모델의 선택 → 실행 조건 확인 → 실행 → 실제 결과 검증

 

모델이 완료라고 답했다고 업무가 완료된 것은 아니다.

실행 API가 성공했다고 사용자의 목표가 달성된 것도 아니다.

완료를 무엇으로 입증할지까지 정해야 한다.

8. 한국어를 잘 못 알아듣는다는 말은?

이 우려에는 확인되는 배경이 있다. 공식 문서는 영어가 주 학습 언어이며 현재 정확도도 가장 좋다고 설명한다.

한국어를 포함하는 CJK 등 다른 언어도 처리하지만 동등한 성능은 아니므로 직접 평가하라고 안내한다.

 

“환불해 주세요.”

“환불 가능한지 궁금합니다.”

“환불해 달라는 건 아니고 배송일만 알려 주세요.”

 

각각 실행 요청, 가능 여부 문의, 환불 요청의 부정이다.

분류 기준이 ‘환불 관련 대화인가’인지 ‘지금 환불을 실행해 달라는가’인지에 따라서도 정답이 달라진다.

그래서 한국어 오답을 발견하면 언어 이해 실패, 질문 정의의 모호함, 필요한 문맥의 누락을 나눠 봐야 한다.

 

한국어 원문과 한국어 질문·기준을 기본으로 평가하되, 차이의 원인을 확인하려면 한 번에 한 요소를 바꾸는 편이 좋다.

예를 들어 다음 비교를 설계할 수 있다.

비교 조건	확인하려는 차이
한국어 원문 + 한국어 질문·기준	실제 사용 조건의 성능
같은 한국어 원문 + 영어 질문·기준	질문·기준의 언어에 따른 변화
의미를 검토한 영어 번역문 + 영어 질문·기준	입력 언어를 바꿨을 때의 변화
같은 문항에서 후보 순서만 변경	언어와 별개인 후보 순서 민감도

 

영어로 바꾸면 해결된다고 가정하는 것이 아니라 어느 부분에서 차이가 생기는지 확인하기 위한 비교다.

번역 자체의 의미 변화도 함께 검토해야 한다.

9. 실제로 써 보려면, 다섯 가지부터 지키자

① 이미 정확히 처리할 수 있는 일에는 모델을 넣지 않는다

날짜 비교, 금액 합계, 권한 조회, 중복 주문 방지는 코드가 맡는다.

모델이 필요 없는 단계까지 AI로 바꾸면 지연과 불확실성만 추가할 수 있다.

② 질문을 나누되, 문맥을 부수지는 않는다

각각 평가할 수 있는 조건은 분리한다.

대신 주체·대상·정정·부정 같은 관계를 제거하면 안 된다.

여러 답이 가능하면 복수 판단을 사용하고, 맞는 후보가 없을 가능성이 있으면 그 상태를 표현하게 한다. 

③ 판단값과 실행 허가를 분리한다

가중평균은 서로 보완 가능한 선호를 합칠 때 쓰고, 하나라도 어기면 안 되는 금지 조건은 따로 처리한다.

높은 confidence가 권한·한도·사용자 확인을 대신하게 해서는 안 된다.

④ 실패를 정상 출력 뒤에 숨기지 않는다

필요한 근거가 없는데도 반드시 후보 하나를 고르게 하지 않는다.

적대적 문구가 판단을 움직일 수 있으므로 Jev 하나를 보안 경계로 삼지 않는다.

여러 질문의 확률을 검증 없이 곱해 전체 성공 확률을 만들지도 않는다. 

모델 호출 실패를 정상적인 “문제없음” 판정으로 바꾸지 말고, 오류·보류를 구분하자.

실행 전에는 판단에 사용한 화면이나 주문 상태가 여전히 유효한지 확인해야 한다.

실행 응답이 유실됐다면 이전 행동이 반영됐는지부터 확인한다.

모델을 다시 호출하는 것과 환불·주문 같은 부작용을 다시 실행하는 것은 다른 재시도다.

⑤ 자동 처리율·오류·전체 비용을 함께 본다

몇 개의 쉬운 문항을 맞혔는지보다, 우리 데이터에서 놓치면 안 되는 사례를 얼마나 놓치는지가 중요하다.

‘위험’을 양성으로 정의하면, 안전한 것을 위험하다고 보는 것은 오탐(FP), 위험을 놓치는 것은 미탐(FN)이다.

두 오류의 비용이 같지는 않다.

전체를 사람에게 넘기면 모델이 잘못 자동 실행하는 위험은 줄일 수 있지만 자동화의 효용도 사라진다.

사람의 검토 역시 무오류를 보장하는 것은 아니다. 반대로 전부 자동 실행하면 호출 단가는 싸 보여도 오류 비용이 커질 수 있다.

따라서 같은 입력으로 규칙 기반 처리, 기존 소형 모델, 구조화 출력 LLM, Jev를 비교하자.

임계값을 조정한 자료와 최종 평가 자료는 나누고, 같은 대화에서 나온 유사 사례가 양쪽에 섞이지 않도록 한다.

선택된 자동 처리 범위에서의 오류율과 전체 건당 비용을 함께 보는 것이다.

이는 불확실한 사례를 보류하는 selective classification 관점을 업무에 적용하는 방법이다. 

 

항목	확인할 내용
자동 처리 비율	전체 중 몇 건을 사람 검토 없이 처리했는가?
자동 처리 구간의 오류	처리한 건 중 얼마나 틀렸고, 어떤 치명적인 오류가 있었는가?
전체 처리 시간	전처리·재시도·후처리를 포함한 중앙값과 상위 지연은 얼마인가?
전체 비용	모델 호출뿐 아니라 보류·추가 검토·실패 처리에 얼마가 드는가?

 

실제 완료율은 실행 실패와 사후 검증까지 포함해 따로 측정해야 한다.

모델·질문·기준·정책 버전을 함께 남기고, API 응답에 기록된 실제 모델 버전도 보관하자.

latest가 가리키는 모델은 바뀔 수 있다. 또한 외부 API로 보내는 원문은 실제로 전송된다.

10. 앞으로의 방향

첫째, 큰 모델 하나보다 역할 분담이 중요해질 수 있다

Browser Use에서는 선택과 문자열 생성이 나뉜다.

모든 단계에 가장 큰 모델을 쓰는 대신 각 단계에 필요한 능력을 배치하는 것이다.

다만 큰 모델이 매번 상태를 정리하고 후보를 새로 만들어야 한다면 작은 판단 모델의 절감 효과가 앞단 비용에 묻힐 수도 있다.

둘째, 실제 사용과 평가가 중요하다

선택값과 확률을 반환하는 인터페이스는 여러 방식으로 구현할 수 있다.

그렇다면 차이는 한국어 이해, 경계 사례, 확률 교정, 긴 입력, 운영 안정성, 로컬 실행 조건에서 드러날 가능성이 크다.

더 개선이 되는지 평가는 내 상황에 직접 사용 해봐야 한다.

셋째, 프롬프트보다 입력과 검증 설계가 더 중요해질 수 있다

잘못된 종목의 뉴스를 준다거나 오래된 상태를 주면 지금은 틀린 행동을 고를 수 있다.

앞으로 중요한 개발 역량은 “모델에게 어떻게 말할까?”가 아니라 무엇을 관측했고, 어떤 선택을 허용하고, 언제 결과를 버릴지, 성공의 기준을 어떻게 할지. 이런 질문이 모델 선택만큼 중요해진다.

 

마무리로 하나만 기억한다면...??

이 흐름의 핵심, Jev는 소프트웨어가 사용할 의미 판단을 빠르고 저렴하게 제공하려는 모델이다.

모델 크기만 줄이는 데 있지 않고 모델이 맡는 일을 작고 분명하게 나누는 데 있다.

 

 

 

-------------------------------------------------------------

출처

TypeSafe 공식 문서와 제품 소개

• TypeSafe: System One
• TypeSafe 출시 글
• TypeSafe: State
• TypeSafe 개발 지침
• TypeSafe: API
• TypeSafe: Primitives
• TypeSafe: Models — 모델·가격·제한·데이터 처리
• TypeSafe Manifesto
• TypeSafe: Speculative fan-out
• TypeSafe: RLCD 설명
• TypeSafe: Confidence
• TypeSafe: Score
• TypeSafe: Jev 1.13의 한계
• TypeSafe 공식 개발 스킬

관련 기술 문서와 논문

• GLiClass 논문
• OpenAI: Structured Outputs
• 확률 교정 연구
• KOBEST 논문
• Belebele 논문
• Google: DiffusionGemma 설명
• Selective Classification 논문

공개 평가·구현·모델

• OpenJev: BoolQ 공개 평가 보고서
• Browser Use 성능 보고서
• Cua jev-use README
• json-render: Jev 실험 문서
• Nimble 공개 벤치마크
• Nimble 모델 카드
• djev-spark 저장소
• djev-spark: README와 응답 계약
• classifier.dev 구성
• classifier.dev: 공개 평가값

트레이딩 예제 코드

• jev-trader: 모델 질문과 후보 — src/model.ts
• jev-trader: 실제 주문 코드 — src/market.ts
• jev-trader: 주문 허용·미실행 경로와 손익 집계 — src/trader.ts