그래프로

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 는 못 한다.
  • 결정을 내려야 할 때 → 이쪽이다. 조건 셋이 겹치면 확실히 이득이다.
    1. 나올 수 있는 답을 미리 적을 수 있다
    2. 속도가 중요하다
    3. 같은 일이 계속 반복된다

나는 지금 쓸 일이 없다

내가 하는 일에 "판단을 대량 반복" 하는 구간이 없다. 그래서 당장은 안 쓴다.

다시 꺼낼 시점은 정해뒀다. 챗봇이나 간단한 답변을 받는 웹/앱을 만들 때. 그때 인텐트 라우팅과 입력 필터링을 처음부터 LLM 으로 짜면, 느리고 비싼 걸 나중에 갈아끼우게 된다.

그때 확인할 것

  • 독립적인 벤치마크가 나왔나 (지금은 만든 쪽 수치뿐)
  • 웨이팅리스트가 풀렸나, 가격이 유지되나
  • 판단 근거를 남기는 방법이 생겼나

참고

형식은 PKM — 기록으로 나를 디버깅하기 에서 정한 Input / Problem / Output 을 따랐다.