Jev: 문장 대신 판단만 돌려주는 System One 모델

고객 문의 하나를 어느 팀에 넘길지 정하는 데 긴 글을 쓸 줄 아는 모델까지 필요할까요? 지금은 이런 단순 판단도 LLM에 맡기고, JSON 응답을 파싱하고, 형식이 깨지면 재시도하는 경우가 많아요.

Jev(제브)는 이 지점을 겨냥한 모델이에요. 미국의 TypeSafe AI가 2026년 9월 15일 얼리 액세스로 공개했고, 스스로를 System One 모델이라고 불러요. 빠르고 직관적인 판단을 뜻하는 '시스템 1' 사고를 떠올리게 하는 이름이에요. 일반적인 LLM이 사람이 읽을 문장이나 코드를 생성한다면, Jev는 입력받은 상태(State)에 대해 소프트웨어가 바로 처리할 수 있는 구조화된 확률적 판단만 돌려줘요.

1. 핵심 특징

• 문장 생성 없음: 요약, 번역, 대화, 코드 작성은 하지 않고 판단 결과만 출력
• 짧은 응답 시간: 공식 수치 70~500ms (자체 보고)
• 낮은 비용: 입력 토큰 100만 개당 $0.042, 출력 토큰 무료
• 타입이 정해진 응답: 미리 정의한 선택지나 척도 안에서만 답을 반환
• 한 번에 여러 질문: 호출 한 번으로 같은 상태에 대한 독립적인 판단을 병렬 평가

응답 시간은 외부 측정 결과도 참고할 만해요. 달레 님의 테스트에서는 질문 3개짜리 요청을 10번 보냈을 때 최소 197ms, 중앙값 298ms, 최대 531ms가 나왔어요. 공식 범위의 하단까지는 내려가지 않았지만 수 초가 걸리는 LLM과는 자릿수가 달라요.

타입이 정해진 응답은 없는 선택지를 지어내거나 JSON이 깨지는 문제를 막아 줘요. 다만 판단 자체가 틀리는 것까지 막지는 못해요. 형식 오류는 구조적으로 없앨 수 있어도 정확도는 별개의 문제이고, 그래서 뒤에 나오는 신뢰도 활용이 중요해요.

2. 질문 형태 세 가지

Jev의 API는 choice, score, noul 세 가지 질문 형태로 구성돼요.

• Choice: 가장 유력한 옵션과 옵션별 확률 분포, 신뢰도를 함께 반환
• Score: 0부터 마지막 단계 번호까지의 기대값을 소수로 반환. 예를 들어 3단계 척도라면 0~2 사이 값이고, 0.67처럼 단계 사이의 값도 가능
• Noul: 0~1 사이의 확률 하나만 반환. confidence 필드가 따로 없고, 값이 0.5에 가까울수록 모델이 확신하지 못한다는 뜻

이미지 안의 대상 위치를 찾는 Box 질문도 Jev 1.14부터 생겼어요. 다만 공식 문서가 "Dreamer-ready"로 분류한 실험 기능이라 운영 환경용으로 권장되지 않아요. 요청마다 TypeSafe-Danger-Zone-Images: true 헤더를 보내야 하고, 형식이 릴리스 사이에 바뀔 수 있어요. 대상이 없다는 답을 낼 수 없고 항상 상자를 반환한다는 점도 주의할 부분이에요.

3. 호출해 보기

공식 빠른 시작의 고객 문의 분류 예제예요. 문의 하나에 담당 팀, 불만 정도, 긴급 여부를 한 번에 물어요. SDK는 npm install @typesafe-ai/sdk로 설치하고, API 키는 TYPESAFE_API_KEY 환경 변수에서 읽어요.

import { choice, noul, score, TypeSafeClient } from "@typesafe-ai/sdk";
 
const ticket =
  "Our API integration started returning 500 errors on every request " +
  "about 20 minutes ago, and we can't process any customer orders " +
  "until this is fixed.";
 
const client = new TypeSafeClient({ defaultModel: "jev-latest" });
 
const response = await client.systemOne({
  state: ticket,
  questions: {
    department: choice("Which team should handle this", {
      billing: "Payment or subscription issues",
      technical: "Bugs or integration problems",
      sales: "Pricing or account questions",
    }),
    frustration: score("How frustrated the customer appears", [
      "Calm, just stating facts",
      "Frustrated but civil",
      "Very angry, strong language",
    ]),
    is_urgent: noul("The message conveys urgency or time-sensitivity"),
  },
});
 
console.log(response.answers.department.choice);
console.log(response.answers.frustration.score);
console.log(response.answers.is_urgent.noul);

문서의 예시 응답은 이렇게 생겼어요. 질문 이름이 그대로 answers의 키가 되고, 파싱할 문장이 없어요.

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "technical",
      "confidence": 1.0,
      "probabilities": { "technical": 1.0, "billing": 0.0, "sales": 0.0 }
    },
    "frustration": {
      "type": "score",
      "score": 0.67,
      "confidence": 0.5,
      "legend": {
        "0": "Calm, just stating facts",
        "1": "Frustrated but civil",
        "2": "Very angry, strong language"
      },
      "probabilities": { "0": 0.33, "1": 0.67, "2": 0.0 }
    },
    "is_urgent": { "type": "noul", "noul": 0.99 }
  },
  "usage": { "input_tokens": 428, "output_tokens": 73 }
}

TypeScript SDK는 질문 정의에서 답의 타입까지 추론해요. response.answers.department.choice의 타입이 "billing" | "technical" | "sales"가 되기 때문에, 분기 코드에서 오타나 빠진 경우를 컴파일 단계에서 잡을 수 있어요.

4. LLM과 비교

LLM을 대체하는 모델이라기보다 역할이 다른 모델로 보는 편이 정확해요. Jev는 사람이 읽을 답을 만들지 않고, 프로그램의 다음 분기를 결정해요.

5. 신뢰도로 사람과 LLM에 넘기기

Jev를 쓸 때 가장 눈여겨볼 값이 confidence예요. Choice와 Score 답에 붙는 0~1 사이 값으로, 확률이 한 답에 몰리면 1에 가깝고 고르게 퍼지면 0에 가까워요. 공식 문서는 이 값을 구간으로 나눠 다음 동작을 정하라고 권해요.

Jev 판단
  ├─ 높은 신뢰도 → 자동 처리
  ├─ 중간 신뢰도 → 주의해서 진행, 추가 확인
  └─ 낮은 신뢰도 → 프론티어 LLM이나 사람에게 위임

문서 예제는 confidence < 0.5면 사람에게 넘기고, 삭제처럼 되돌리기 어려운 작업은 0.9를 넘을 때만 자동 실행해요. 이 숫자는 예시일 뿐이고, 위험도에 맞춰 보수적으로 시작한 뒤 자기 데이터로 조정해야 해요.

이 구조를 쓰기 좋은 곳은 이런 업무예요.

• 고객지원 티켓 자동 분류와 담당 부서 라우팅
• 콘텐츠 모더레이션의 위해성 판단
• LLM 출력에 대한 안전성 검사(가드레일)
• 에이전트 워크플로의 저비용 판단 계층

6. 알아 둘 한계

• 세계 지식 없음: 전달받은 상태만 판단하고 외부 정보 조회 불가
• 복잡한 논리에 약함: 다단계 추론, 숫자 세기, 산술, 숫자 비교, 날짜·기간 계산에서 정확도 하락
• 문장을 곧이곧대로 읽음: 부정문, 이중 부정, 암시가 섞인 지시문을 잘못 해석할 가능성
• 언어별 편차: 주요 학습 언어가 영어라 영어 정확도가 가장 높고, 한국어는 상대적으로 낮을 가능성. 1.14에서 다국어 개선
• 고객별 파인튜닝 없음: 고객 데이터로 모델을 미세 조정할 수 없음
• 컨텍스트 제한: 기본값은 요청당 64k, 질문당 32k 토큰. 긴 컨텍스트 옵션은 262k까지 늘어나지만 더 느리고 정확도 하락

달레 님의 테스트에서도 이런 약점이 드러났어요. 목록 속 과일 수를 세게 했을 때 항목이 늘수록 신뢰도가 떨어졌고, 32개 항목에서는 11개를 10개로 답했어요. 한국어와 영어로 같은 티켓을 물으면 애매한 문의에서 한국어 신뢰도가 낮아지는 경우도 있었어요(예: 0.74 대 0.26).

한국어 서비스에 적용한다면 공식 문서의 조언대로 자기 데이터로 먼저 검증하고, 신뢰도를 라우팅 기준에 꼭 넣는 편이 안전해요. Choice에 "해당 없음" 옵션을 넣는 방식도 잘 동작하지 않을 수 있다고 문서에 적혀 있으니 함께 시험해 보세요.

마무리

Jev의 핵심은 모델이 잘하는 일을 판단 하나로 좁혔다는 데 있어요. 답을 코드가 바로 읽을 수 있고, 불확실하면 그 정도까지 숫자로 알려 주니 자동화의 분기점에 넣기 좋아요. 처음에는 티켓 분류처럼 틀려도 되돌리기 쉬운 업무에 붙이고, 신뢰도가 낮은 건만 LLM이나 사람에게 넘기는 구성으로 시작해 볼 만해요.

참고 자료

• TypeSafe AI 공식 문서
• Jev 빠른 시작
• TypeSafe AI 블로그: Jev 1.14
• Eigent: TypeSafe AI Jev와 System One 모델
• 달레 코드: Jev 사용기
• 나무위키: Jev