Jev — 글자를 포기한 AI
텍스트를 만들지 않고 확률이 붙은 값만 돌려주는 모델. 글을 쓸 땐 필요 없고, 결정을 반복할 때 쓴다.
- Date
- Tags
- #jev#typesafe#ai#llm
Input
Jev 가 뭔가
TypeSafe AI 가 2026-09-15 얼리액세스로 공개한 모델. 만든 사람은 OpenAI 에서 ChatGPT 의 RLHF 를 하던 Diogo Almeida.
"좀 똑똑한 if-statement" 라는 비유가 거의 맞다. 두 가지만 다르다.
- 조건을 코드가 아니라 말로 쓴다 ("이 문의가 급한가?")
- 답이 true/false 가 아니라 확률로 나온다 (0.95)
회사는 이걸 System One 모델이라 부른다. 빠른 직관(시스템1)과 느린 추론(시스템2) 중 LLM 이 시스템2 흉내를 낸다면, Jev 는 시스템1 만 한다.
핵심은 "글자를 포기했다"는 것
LLM 은 토큰을 하나씩 이어 붙여 문장을 만든다. Jev 는 그걸 안 한다. 질문 여러 개를 한 번에 평가해서 값만 돌려준다.
LLM 질문 → 토큰 하나씩 생성 → 문장 → 내가 파싱 → 값
(여기서 실패 가능)
Jev 상황 + 타입 붙은 질문 → 한 번에 → 값 + 확률
(파싱 단계가 없음)
이 포기 하나가 속도와 가격과 타입 보장을 전부 산다.
답은 세 종류뿐
| 타입 | 하는 일 | 돌려주는 것 |
|---|---|---|
choice | 정해둔 보기 중 하나 고르기 | 고른 값 + 보기별 확률 |
score | 순서 있는 등급 매기기 | 점수 + 등급별 확률 |
noul | 예/아니오 판단 | 0 ~ 1 확률 |
셋 다 확신도(confidence) 가 같이 온다. 보기는 최대 255개, 컨텍스트 32k.
요청이 실제로 어떻게 생겼나
state(상황) 한 덩어리 + questions(타입 붙은 질문들). 끝이다. 대화 기록 같은 게 없다.
{
"state": "결제가 3일째 실패합니다. 급해요.",
"questions": {
"is_urgent": { "type": "noul", "instructions": "급한 건인가?" },
"department": { "type": "choice", "criteria": {
"billing": "결제·환불",
"technical": "버그·장애" } }
}
}
{
"answers": {
"is_urgent": { "noul": 0.95 },
"department": { "choice": "billing", "confidence": 0.8,
"probabilities": { "billing": 0.87, "technical": 0.13 } }
}
}
보기를 내가 미리 적어 넣었으니 그 밖의 답이 나올 수가 없다. 이게 "할루시네이션 불가"의 정체다. 대단한 기술이라서가 아니라, 답의 범위를 내가 먼저 닫아놨기 때문이다.
왜 지금 핫한가
숫자가 극단적이라서다.
| Jev | 프런티어 LLM | |
|---|---|---|
| 응답 시간 | 70 ~ 500ms | 데모에서 0.114초 대 8.566초 |
| 입력 가격 | $0.042 / MTok | $2.00 / MTok |
| 출력 가격 | 무료 | $12 / MTok |
| 결정 1건 | $0.0004 | $0.03 ~ $0.18 |
타이밍도 맞았다. 에이전트가 늘면서 "LLM 을 감시할 싸고 빠른 판단기" 수요가 생겼다.
단, 벤치마크는 대부분 TypeSafe 가 만든 것이다. 독립 재현은 아직 없다.
장단점
| 장점 | 단점 |
|---|---|
| 보기 밖의 답이 원천적으로 안 나옴 | 글을 아예 못 씀 — 답장·코드·요약 전부 불가 |
| 파싱 실패, 타입 에러가 없음 | 이유를 말해주지 않음. 확률만 준다 |
| 확신도가 실제 정확도와 맞게 보정됨 | 답 후보를 내가 먼저 다 알아야 함 |
| 싸고 빠름 | 폐쇄형 — 자체 호스팅 없음, 웨이팅리스트 |
두 번째 단점이 크다. 근거를 남겨야 하는 분야에서는 "왜 이렇게 판단했는가"를 못 적으면 그것만으로 못 쓴다.
"할루시네이션이 없다"는 자랑도 한 번 걸러 들을 만하다. 애초에 자연어를 안 뱉으니 비교 자체가 성립하지 않는다는 지적이 있다. 맞는 말이다.
Problem
어디에 쓸 수 있나
기준은 한 줄이다. 답이 이미 정해져 있고, 그걸 고르는 일을 많이 반복하는가.
넷 다 "예" 면 Jev, 하나라도 "아니오" 면 LLM 이다.
- 나올 수 있는 답을 미리 다 적을 수 있다
- 결과를 사람이 읽는 게 아니라 코드가 바로 받아 쓴다
- 같은 판단을 계속 반복한다
- 왜 그렇게 판단했는지 설명이 필요 없다
흔한 예로는 문의 분류, 우선순위 점수, 스팸·어뷰징 판정, 챗봇 인텐트 라우팅이 있다. 전부 보기가 닫혀 있고, 사람이 읽을 문장이 필요 없고, 하루에 수백 번 반복된다.
제일 잘 맞는 자리
LLM 의 대체가 아니라 LLM 앞뒤의 문지기다.
사용자 입력
│
├─ Jev: 우리가 답할 수 있는 질문인가? 위험한 요청인가? (수십 ms)
│
▼
LLM: 실제 답변 작성 (수 초)
│
├─ Jev: 민감한 내용이 들었나? 정책 위반인가? (수십 ms)
│
▼
사용자에게 전송
앞뒤를 LLM 으로 막으면 비용과 지연이 세 배가 된다. 그 자리가 Jev 자리다.
Output
언제 필요하고 언제 아닌가
- 답장을 쓰거나, 코드를 고치거나, 설명을 만들 때 → 필요 없다. 그건 LLM 이 할 일이고 Jev 는 못 한다.
- 결정을 내려야 할 때 → 이쪽이다. 조건 셋이 겹치면 확실히 이득이다.
- 나올 수 있는 답을 미리 적을 수 있다
- 속도가 중요하다
- 같은 일이 계속 반복된다
나는 지금 쓸 일이 없다
내가 하는 일에 "판단을 대량 반복" 하는 구간이 없다. 그래서 당장은 안 쓴다.
다시 꺼낼 시점은 정해뒀다. 챗봇이나 간단한 답변을 받는 웹/앱을 만들 때. 그때 인텐트 라우팅과 입력 필터링을 처음부터 LLM 으로 짜면, 느리고 비싼 걸 나중에 갈아끼우게 된다.
그때 확인할 것
- 독립적인 벤치마크가 나왔나 (지금은 만든 쪽 수치뿐)
- 웨이팅리스트가 풀렸나, 가격이 유지되나
- 판단 근거를 남기는 방법이 생겼나
참고
- Introducing System One Models & Jev — 공식 발표. 타입 세 개와 가격이 여기 있다.
- Jev (AI model) — Wikipedia — 만든 사람, 구조, 비판이 한 페이지에.
- A new kind of AI model from a ChatGPT inventor — 왜 지금 화제인지.
- System One Model That Never Hallucinates — 한계가 제일 솔직하게 적혀 있다.
형식은 PKM — 기록으로 나를 디버깅하기 에서 정한 Input / Problem / Output 을 따랐다.