고객 문의를 어느 팀에 보낼지, 이 리뷰가 불만인지, 이 거래가 수상한지. 이런 일에 필요한 건 긴 답장이 아니라 결정 하나입니다. 2026년 9월에 나온 Jev는 그 결정만 돌려주는 AI입니다. 끝까지 읽으면 내 업무에서 사람이 반복해서 내리는 판단 하나를 골라, Jev에게 맡길 질문으로 바꿔 적을 수 있습니다.
Jev는 TypeSafe AI라는 회사가 2026년 9월 15일에 공개한 모델입니다. 창업자 중 한 명인 Diogo Almeida는 ChatGPT를 만든 학습법(RLHF)의 공동 발명자로 공식 문서에 소개돼 있습니다. 9월 27일부터는 대기자 명단 없이 누구나 가입할 수 있습니다.
출처를 이렇게 표시합니다. 사실은 TypeSafe 공식 문서와 홈페이지(2026-10-08 확인)에서 가져왔고, 맨 아래에 목록이 있습니다. 속도·가격 비교처럼 회사가 스스로 잰 숫자에는 회사 발표 표시를 붙였습니다. 아직 독립된 곳에서 검증한 결과는 없습니다.
쇼핑몰에 고객 문의가 하루 1만 건 들어온다고 해 봅시다. 문의마다 환불, 배송, 기타 중 하나로 나눠 담당 팀에 보내야 합니다. ChatGPT에 물어도 답은 나옵니다. "이 고객은 상품이 마음에 들지 않아 환불을 원하는 것으로 보입니다" 같은 문장으로요.
그런데 우리 프로그램에 필요한 건 그 문장이 아닙니다. "그래서 어디로 보내지?"에 대한 값 하나입니다. 문장을 받으면 그 안에서 답을 다시 찾아내야 하고, 1만 번 중 몇 번은 형식이 어긋납니다. Jev는 처음부터 값만 돌려줍니다.
숫자는 설명을 위한 예시입니다.
ChatGPT나 Claude 같은 LLM은 사람이 읽을 글을 만듭니다. Jev는 코드가 받을 판단을 만듭니다. Jev도 글을 읽고 뜻을 이해하지만, 답장을 쓰거나 코드를 짜거나 이유를 설명하지는 않습니다.
TypeSafe는 이런 모델을 System One 모델이라고 부릅니다. 이름은 대니얼 카너먼의 책 『생각에 관한 생각』에서 왔습니다. 시스템 1은 빠르고 직관적인 판단, 시스템 2는 느리고 숙고하는 생각입니다. 요즘 추론 모델이 오래 생각하는 쪽으로 가는 것과 반대로, 몇 초 만에 내리는 상식적인 판단을 노렸습니다. 이 가이드에서는 쉽게 "판단 모델"이라고 부르겠습니다.
답장, 요약, 설명, 코드처럼 사람이 읽거나 고칠 결과물을 만듭니다.
분류, 점수, 예/아니오처럼 프로그램이 조건문에 바로 넣는 값을 돌려줍니다.
| 하려는 일 | 일반 LLM | 판단 모델(Jev) |
|---|---|---|
| 이메일·글 쓰기, 코드 생성, 설명 | 잘 맞음 | 하지 않음 |
| 문서 분류, 문의 유형 나누기 | 가능 | 주 용도 |
| 예/아니오 판정 | 가능 | 주 용도 |
| 점수 매기기 | 가능 | 주 용도 |
| 프로그램 안에서 자동으로 갈래 나누기 | 가능(답을 다시 해석해야 함) | 주 용도 |
표에서 LLM 칸에 "가능"이 많은 점을 보세요. LLM이 판단을 못 하는 게 아니라, 만든 목적이 다릅니다. 공식 FAQ도 Jev는 작은 LLM이 아니라 소프트웨어 안의 판단이라는 다른 일을 위해 따로 학습한 모델이라고 설명합니다.
Jev에게 던지는 질문은 셋 중 하나의 모양을 고릅니다. 흔히 쓰는 AI 용어와 짝지어 보면 이렇습니다.
흔한 용어로 분류(classification)입니다.
단계마다 뜻을 적어 두면 그 사이 어디쯤인지 답합니다.
흔한 용어로 이진 분류(binary classification)입니다.
어떤 모양을 고를지는 공식 문서의 기준이 간단합니다.
헷갈리는 예가 하나 있습니다. "이 지원자는 파이썬을 잘하나?"는 Noul처럼 보이지만 Score가 맞습니다. Noul 0.5는 "중간 실력"이 아니라 "예와 아니오가 반반, 모르겠다"는 뜻이기 때문입니다. 실력을 재려면 "경험 없음 · 조금 써 봄 · 매일 씀 · 깊은 전문성"처럼 단계를 적은 Score로 묻습니다.
질문은 한꺼번에 보내도 됩니다. 같은 문의에 대해 유형(Choice), 화난 정도(Score), 상담원 요청(Noul)을 한 번에 물으면 세 질문을 따로따로 동시에 판단합니다. 공식 문서는 질문을 늘려도 응답 시간이 거의 늘지 않는다고 설명합니다.
Jev의 답에는 숫자가 두 종류 붙습니다. 이 둘을 섞어 읽는 것이 처음 쓰는 사람이 가장 흔히 하는 오해입니다.
그럼 0.91이라는 숫자를 얼마나 믿어도 될까요. Jev는 보정(calibration)을 목표로 학습했습니다. 0.8이라고 답한 판단들을 많이 모아 보면 그중 대략 80%가 맞도록 만든다는 뜻입니다. 여러 판단을 모았을 때의 성질이라, 이번 한 건이 맞는다는 보장은 아닙니다. TypeSafe는 이 학습법을 RLCD(보정된 판단을 위한 강화학습)라고 부릅니다.
아래에서 같은 계산을 직접 해 볼 수 있습니다. 공식 문서에 나온 Choice 확신도 공식을 그대로 썼습니다.
갈래 기준: 0.9 이상 자동 처리, 0.5 이상 검토 대기열, 0.5 미만 사람에게. 공식 예제의 출발점이고, 업무마다 다르게 정합니다(10번에서 다룹니다).
"두 후보가 팽팽"을 눌러 보세요. 1등은 여전히 환불이지만 확신도가 0.33으로 떨어지고 사람에게 넘어갑니다. 1등이 무엇인지보다 얼마나 확실한 1등인지를 보고 행동을 바꾸는 것, 이것이 판단 모델을 쓰는 핵심입니다.
여기까지 확인. 세 가지 버튼을 눌렀을 때 확신도와 갈래가 바뀌는 것을 봤다면 다음으로 넘어갑니다.
요즘 LLM도 정해진 JSON 모양으로만 답하게 할 수 있습니다(structured outputs). 답의 모양만 보면 차이가 없습니다. 차이는 다른 곳에 있습니다.
| 비교 | LLM에 JSON 형식 강제 | Jev |
|---|---|---|
| 답의 범위 | 형식을 지키게 강제 | 내가 준 선택지 밖의 답은 구조상 나올 수 없음 |
| 불확실성 | 확신도를 따로 물어야 하고, 과신하기 쉬움 | 모든 선택지의 확률과 확신도가 기본으로 붙음 |
| 만드는 방식 | 글자를 하나씩 이어 붙여 생성 | 여러 질문을 한 번에 병렬로 계산, 대부분 약 0.1초 |
| 값 | 입력과 출력 모두 과금 | 입력 100만 토큰당 0.042달러, 출력 무료 |
공식 FAQ의 설명은 이렇습니다. JSON은 프로그램이 읽을 형식을 줄 뿐이고, 글을 쓰도록 학습한 모델을 그 틀에 억지로 맞추면 실력 일부를 못 쓰게 될 수 있다. 판단 모델은 처음부터 정해진 답과 보정된 확률을 내도록 학습했다. 과신 문제는 회사가 사람 선호를 따르는 학습(RLHF)의 부작용으로 꼽는 부분입니다.
회사 발표 홈페이지는 자사가 고른 작업 기준으로 LLM보다 193.6배 빠르고 444.6배 싸며, 입력 가격이 Claude Fable 5.1보다 238배 낮다고 내세웁니다. 회사가 직접 고른 작업으로 잰 숫자이고, 출시 발표에서도 실제 현장 이득의 상단에 가깝다고 인정했습니다. 내 업무에서는 직접 재 봐야 합니다.
프로그램은 조건문으로 갈래를 나눕니다. "VIP 고객이면 영업팀으로"는 쉽습니다. 고객 등급은 데이터베이스에 있으니까요.
if customer.is_vip:
send_to_sales(message)
그런데 "고객이 화가 났으면 팀장에게"는 다릅니다. 화가 났는지는 데이터베이스에 없고, 문장을 읽어야 알 수 있습니다. 바로 이 자리에 Jev를 넣습니다.
angry = client.system_one(
state=message,
questions={"angry": Noul(instructions="고객이 화가 난 상태다")},
).answers["angry"].noul # 0~1, 예일 확률
if angry > 0.8:
send_to_manager(message)
send_to_manager는 원래 있던 우리 프로그램의 함수입니다. Jev가 하는 일은 0과 1 사이 숫자 하나를 만드는 것까지입니다.
공식 문서는 이것을 "똑똑한 if문"이라고 부릅니다. 이렇게 판단만 따로 맡는 층을 판단 계층(decision layer)이라고도 합니다. 기존 프로그램을 갈아엎지 않고, 사람 눈이 필요했던 조건 하나만 바꿔 끼우는 방식입니다.
앞의 조각을 모아 1번의 쇼핑몰 문의 분류를 처음부터 끝까지 설계합니다.
들어온 문의를 환불, 배송, 기술지원, 기타 중 하나로 나눠 담당 팀에 보낸다. 이것을 작업 정의(task definition)라고 합니다.
Jev에 넣는 입력을 state라고 부릅니다. 여기서는 고객 메시지입니다. 주문 내역이 필요하면 함께 넣되, 질문과 관계없는 내용은 빼는 편이 정확합니다.
선택지(criteria)마다 한 줄 설명을 붙입니다. 이름만 주는 것보다 경계가 분명해집니다.
response = client.system_one(
state="상품을 받았는데 마음에 들지 않습니다. 환불하고 싶어요.",
questions={
"type": Choice(
instructions="이 문의는 어떤 유형인가?",
criteria={
"환불": "환불이나 반품을 원함",
"배송": "배송 상태, 지연, 분실",
"기술지원": "앱 오류, 로그인, 결제 화면 문제",
"기타": "위 셋에 해당하지 않음",
},
),
},
)
Jev가 답을 내는 과정을 추론(inference)이라고 합니다. 돌아오는 값은 이런 모양입니다.
{
"type": {
"choice": "환불",
"probabilities": {"환불": 0.94, "배송": 0.03, "기술지원": 0.01, "기타": 0.02},
"confidence": 0.92
}
}
a = response.answers["type"]
if a.confidence < 0.5:
hand_to_human(message) # 애매하면 사람에게
elif a.confidence >= 0.9:
create_ticket(team=a.choice) # 확실하면 자동 배정
else:
send_to_review(message, a.choice) # 중간이면 사람이 확인
Jev는 시스템 전체가 아닙니다. 판단을 맡은 부품 하나입니다. 공식 문서는 AI를 쓰는 소프트웨어를 세 가지 구조로 나눕니다.
| 구조 | 누가 다음 일을 정하나 | 특징 |
|---|---|---|
| 전통적인 코드 | 코드 | 믿을 수 있지만, 문장의 뜻을 읽는 판단은 못 함 |
| 에이전트 | 모델이 다음 행동을 스스로 고름 | 사람이 지켜볼 때는 잘 맞지만, 반복할 때마다 탈선할 기회가 생김 |
| AI를 품은 소프트웨어 | 코드가 흐름을 쥐고, 모델은 좁은 판단만 | Jev가 겨냥하는 구조 |
TypeSafe는 Jev가 코드를 생성하지도, 다음 행동을 스스로 고르지도 않는다고 밝힙니다. 그래서 LLM과 같이 쓸 때도 역할이 선명하게 나뉩니다. 공식 패턴 중 하나인 의도 라우팅을 보면 이렇습니다.
비싼 LLM은 정말 글을 써야 하는 문의에만 부릅니다. 공식 활용 사례에는 에이전트 안에서 어느 모델에 보낼지 고르는 라우터, LLM의 입력과 출력을 검사하는 안전장치도 들어 있습니다. 정리하면 이렇습니다.
답장, 요약, 설명을 씁니다.
분류, 점수, 예/아니오를 냅니다.
흐름을 쥐고 실제 일을 합니다.
Jev가 잘 맞는 일은 "입력, 판단, 행동"의 모양입니다. 그 판단이 이런 조건을 갖출수록 좋습니다.
예를 들면 "이 리뷰는 부정적인가", "이 리드를 영업팀에 넘길까", "이 문서는 계약서인가", "이 거래는 사기 의심인가", "LLM이 단 인용이 원문과 맞는가" 같은 질문입니다.
반대로 글쓰기, 요약, 코드 고치기는 LLM의 일입니다. 복잡한 수학이나 체스처럼 여러 수를 내다보는 계획은 추론 모델이 낫다고 공식 FAQ가 직접 말합니다. 회사가 공개한 jev-1.13의 약점 목록(2026-10-02 검토판)도 미리 알아 두면 좋습니다.
| 약한 곳 | 대신 이렇게 |
|---|---|
| 계산, 개수 세기 | 코드로 계산하고, Jev에는 뜻을 판단하는 질문만 |
| 날짜 비교(어느 쪽이 먼저인가) | 날짜 조각만 뽑게 하고 비교는 코드로 |
| 쓴 그대로 읽음(속뜻을 짐작하지 않음) | 조건과 경계 사례를 질문에 그대로 적기 |
| 이중 부정, 여러 단계 꼬인 지시 | 질문을 직접적으로, 쪼개서 |
| 관계없는 내용이 많은 긴 입력 | 코드로 먼저 걸러 필요한 부분만 |
한국어 업무라면 꼭 시험부터. 공식 Models 문서는 영어가 주 학습 언어이고 정확도도 가장 높으며, 한국어 같은 다른 언어도 처리하지만 같은 수준은 아니라고 밝힙니다. 내 데이터 수십 건으로 먼저 돌려 보고, 확신도 기준을 영어보다 엄격하게 잡으세요.
이제 직접 해 볼 차례입니다. 지금 누군가 반복해서 내리고 있는 판단 하나를 떠올리세요. 아래 칸을 채우면 설계 한 장과 호출 코드 초안이 만들어집니다.
기준은 하나의 숫자로 끝나지 않습니다. 같은 시스템 안에서도 틀렸을 때 피해가 큰 행동일수록 높게 잡습니다. 공식 패턴의 음성 뱅킹 예에서는 잔액 조회는 확신도 0.6이면 충분하지만, 이체 승인은 0.85를 넘어야 자동으로 처리하고 그 아래면 사용자에게 한 번 더 확인합니다. 처음에는 보수적으로 잡고, 내 데이터로 돌려 보며 조정합니다.
여기까지 확인. 설계 한 장에 입력, 질문, 선택지, 기준, 애매할 때 처리 다섯 줄이 내 업무 내용으로 채워졌다면 이 가이드의 목표에 도달했습니다.
확신도가 늘 낮게 나와요
선택지 설명이 서로 겹치거나, 입력에 판단 근거가 없는 경우가 많습니다. 헷갈리는 두 선택지에는 "여기에 해당하는 것, 해당하지 않는 것, 예시"를 나란히 적어 경계를 분명히 합니다.
질문 하나에 너무 많은 걸 담았어요
"이 사업 아이디어를 평가해 줘"는 판단 여러 개를 하나로 숨깁니다. 시장 크기, 기술 가능성, 차별성처럼 따로 묻고, 합치는 비중은 코드에서 정합니다. 공식 문서가 가장 중요하다고 꼽는 원칙입니다.
질문은 맞는데 엉뚱한 답이 나와요
Jev는 쓴 그대로 읽습니다. 틀린 답을 보며 "원래 뜻은 이거였는데" 하고 설명하고 싶어진다면, 그 설명이 질문에서 빠진 절반입니다. 질문에 적어 넣습니다.
어제와 결과가 달라졌어요
모델 이름 jev-latest는 새 버전이 나오면 자동으로 옮겨 갑니다. 기준을 맞춰 둔 판단이라면 jev-1.13.0처럼 버전을 고정하고, 새 버전은 시험한 뒤에 옮깁니다.
| 용어 | 쉬운 말 |
|---|---|
| 판단 모델 · System One 모델 | 글 대신 정해진 모양의 판단값을 돌려주는 AI |
| state | 판단할 재료. 문장, JSON, 글 목록 |
| instructions · criteria | 묻는 말과, 답이 될 수 있는 선택지나 단계 |
| Choice · Score · Noul | 고르기 · 척도 · 예/아니오 |
| probability | 선택지마다 붙는 확률. 다 더하면 1 |
| confidence | 확률이 한쪽으로 쏠린 정도. 0부터 1 |
| calibration(보정) | 0.8이라 답한 판단을 모으면 대략 80%가 맞는 성질 |
| threshold · fallback | 자동 처리 기준 · 애매할 때 넘기는 곳 |
| human-in-the-loop | 애매한 건을 사람이 확인하는 구조 |
가입하면 코드 없이 Playground에서 문장을 붙여 넣고 질문을 바로 시험할 수 있습니다. 프로그램에서 부르는 법은 공식 Quick start(Python, JavaScript, HTTP)에 있습니다.