TypeSafe AI의 Jev - 텍스트를 생성하지 않는 AI 모델
TypeSafe AI가 'System One 모델'이라는 새로운 범주와 첫 모델 Jev를 공개했습니다. 텍스트 대신 타입이 정해진 결정과 확률을 반환하는 이 모델의 구조, 성능, 그리고 '환각할 수 없다'는 주장의 진짜 의미를 정리했습니다.
그동안 이 블로그에서 다룬 GPT-6 Astra나 Claude 계열 모델은 모두 “더 똑똑하게 말하고 더 잘 코딩하는” 방향의 경쟁이었습니다. 이번에 소개할 Jev는 방향이 아예 다릅니다. 텍스트를 한 글자도 생성하지 않는 모델입니다.
TypeSafe AI는 2026년 9월 15일 스텔스에서 나오며 System One 모델이라는 새로운 모델 범주와 그 첫 구현인 Jev를 공개했고, 9월 21일부터는 대기 목록을 없애고 일반 공개로 전환했습니다.
System One 모델이란 무엇인가
이름은 대니얼 카너먼의 System 1(빠르고 직관적인 사고) 에서 왔습니다. LLM이 사람과 대화하기 위해 만들어진 모델이라면, System One 모델은 소프트웨어가 곧바로 받아쓸 수 있는 결정을 내놓기 위해 만들어진 모델입니다.
LLM처럼 자연어 입력은 이해하지만, 출력은 문자열이 아니라 타입이 정해진 값 + 보정된 확률입니다. 공식 문서의 표현을 빌리면 System One 모델은 “답장을 쓰지도, 코드를 만들지도, 설명을 생성하지도 않습니다(do not write replies, produce code, or generate explanations)”. 대신 미리 정의된 선택지 안에서 답을 고릅니다.
| 구분 | 기존 LLM | Jev (System One) |
|---|---|---|
| 출력 형태 | 자유 형식 텍스트 | 타입이 정해진 값 |
| 최적화 대상 | 인간의 선호도 | 보정된 의사결정 |
| 입력 초점 | 순차적인 메시지 | 구조화된 프로그램 상태 |
| 샘플링 방식 | 순차(토큰 단위) | 병렬(단일 쿼리에서 일괄) |
| 타입 오류 | 발생 가능 | 구조적으로 불가능 |
이미지 출처: Panda Blog - Jev를 써보며, AI는 답변보다 판단에 가까워질 수 있겠다고 생각했다
가장 큰 차이는 파싱 단계가 사라진다는 점입니다. LLM은 결국 문자열을 돌려주기 때문에 애플리케이션이 그것을 파싱하고 검증하는 계층을 반드시 거쳐야 하고, 그 지점이 오류의 출발점이 됩니다. Jev는 처음부터 타입이 정해진 값과 확률을 주므로, 코드는 파싱 대신 확률로 분기하는 일만 하면 됩니다.
학습 방식도 다릅니다. RLHF/RLVR 대신 RLCD(Reinforcement Learning for Calibrated Decisions) 라는 자체 방법을 썼는데, 사람 평가자의 선호가 아니라 실제 결과(outcome)에 확률을 맞추는 방향으로 최적화했다고 설명합니다. 그래서 “신뢰도 0.9”가 실제로 90% 정확도에 가깝게 대응하는 것을 목표로 합니다.
회사 배경: 2년 스텔스, 합성 데이터만으로 학습
- 설립: 2024년, 샌프란시스코
- 창업자: Diogo Almeida(CEO), Erik Gafni, Sasha Sheng
- 펀딩: DCVC 주도 시드 4,000만 달러
- 학습 데이터: 2년간 스텔스 상태에서 합성 데이터만으로 Jev 학습
CEO인 Diogo Almeida는 OpenAI에서 약 4년간 RLHF, InstructGPT, ChatGPT, GPT-4 작업에 참여한 뒤 2024년에 퇴사한 인물입니다. RLHF를 만드는 데 기여한 사람이 RLHF와 정반대 방향(사람 선호 대신 결과 보정) 의 학습법을 들고 나왔다는 점이 흥미로운 지점입니다.
세 가지 질문 타입: Choice, Score, Noul
Jev는 “무엇을 물어볼 수 있는가”가 세 가지 원시 타입(primitive)으로 제한되어 있습니다. 이 제약이 곧 타입 안전성의 근거입니다.
| 타입 | 용도 | 출력 |
|---|---|---|
| Choice | 정의된 옵션 중 하나 선택 (최대 255개) | "billing" 같은 선택지 + 확률 분포 |
| Score | 2~10개 레벨로 정의한 스펙트럼상의 위치 | 1.035 같은 연속값 |
| Noul | 참/거짓 판정 | 0.95 같은 0~1 확률 |
모든 응답에는 confidence가 함께 담겨 오기 때문에, 임계값을 기준으로 자동 처리할지 사람이 검토할지 분기하는 설계가 가능합니다.
API 활용 예시
SDK는 Python(3.10+)과 JS/TS(Node 20+) 모두 제공됩니다.
pip install typesafe-sdk
# 또는
npm install @typesafe-ai/sdk
export TYPESAFE_API_KEY="sk-..."한 번의 호출에서 여러 질문을 병렬로 던질 수 있다는 점이 핵심입니다.
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
response = client.system_one(
state={
"ticket": {
"subject": "중복 결제되었습니다",
"messages": [
{
"from": "customer",
"text": "A-104 주문이 두 번 결제되었습니다. 환불해주세요.",
},
],
},
},
questions={
"department": Choice(
instructions="어느 팀이 처리해야 하는가",
criteria={
"billing": "결제나 구독 관련 문제",
"technical": "버그나 연동 문제",
"sales": "가격이나 계정 문의",
},
),
"frustration": Score(
instructions="고객이 얼마나 불만을 느끼고 있는가",
criteria=[
"차분하게 사실만 전달",
"불만스럽지만 예의는 지킴",
"매우 화가 난 상태",
],
),
"refund_requested": Noul(
instructions="고객이 명시적으로 환불을 요구하고 있다"
),
},
)
dept = response.answers["department"]
print(dept.choice, dept.confidence) # billing 0.97
print(response.answers["frustration"].score) # 1.035
print(response.answers["refund_requested"].noul) # 0.98HTTP로 직접 호출할 때는 POST /v1/systemone 엔드포인트에 model: "jev-latest"를 지정합니다. 입력은 텍스트만 지원하며(이미지·오디오·비디오 미지원), 컨텍스트는 state + questions 합쳐 64k 토큰입니다.
워크플로 설계: 큰 업무를 작은 판단으로 쪼갠다
Jev를 제대로 쓰려면 프롬프트를 쓰는 감각이 아니라 함수를 설계하는 감각이 필요합니다. 공식 문서가 제시하는 판별 기준은 단순합니다.
“Can I express the requirement as ‘Given this state, tell me X’, where X is a Choice, Score or probability?” (이 요구사항을 “이 상태가 주어졌을 때 X를 알려줘”로 표현할 수 있는가? 단 X는 Choice, Score, 확률 중 하나다.)
이미지 출처: Panda Blog - Jev를 써보며, AI는 답변보다 판단에 가까워질 수 있겠다고 생각했다
“이 청구서를 처리할까?”처럼 통째로 던지면 답이 안 나오는 업무를, Noul(읽을 수 있는가) · Choice(어떤 유형인가) · Score(위험도는 얼마인가) 같은 원자적 질문으로 쪼갭니다. 그리고 그 결과를 합쳐 최종 행동(지급·보류·반려)을 결정하는 것은 모델이 아니라 코드입니다.
적합성 판정 체크리스트
문서는 질문 하나를 Jev에 맡길지 판단하는 6가지 기준을 제시합니다.
- 판단 — AI가 결정해야 하는 문제인가
- 경계 — 답변 공간을 미리 정의할 수 있는가
- 원자성 — 하나의 초점화된 판단인가
- 문맥 포함 — 필요한 정보를
state에 담을 수 있는가 - 빠른 인식 — 전문가라면 몇 초 안에 판단할 수 있는가
- 기계 소비 — 결과를 소프트웨어가 직접 쓰는가
5~6개 해당이면 좋은 후보, 3~4개면 워크플로를 더 쪼개야 하고, 0~2개면 다른 기술을 써야 한다는 기준입니다.
역할 분담: 코드는 계산, Jev는 판단, LLM은 추론
문서의 표현을 그대로 옮기면 “Code calculates. Jev judges. LLMs reason/create.” 입니다.
| 필요한 일 | 담당 |
|---|---|
| 정확한 계산, DB 조회, 알려진 비즈니스 규칙 | 코드 |
| 빠른 의미 판단, 분류, 점수화, 검증, 관련성 판정 | Jev |
| 복잡한 다단계 추론, 검색, 산문 작성 | LLM |
흐름은 관찰 → 판단(Jev) → (필요시) 추론 → 행동으로 설계하고, 신뢰도에 따라 라우팅합니다. 높은 확실성은 즉시 처리, 중간은 검증이나 사람 검토, 모호한 건은 추론 모델로 넘기는 식으로 deterministic_code / fast_llm / reasoning_llm / human_review 같은 경로를 두는 구성이 권장됩니다.
의미론적 IF문
이 설계를 한 줄로 요약하면 “판단이 들어가는 조건문” 입니다.
# 기존: 숫자로만 가능한 조건 분기
if amount > 10000:
escalate()
# Jev: 의미 판단을 조건문에 직접 넣는다
if safeguarding_risk > 0.95: # Noul이 반환한 확률
escalate()기존에는 코드로 표현할 수 없어서 사람이 처리하거나 LLM에 프롬프트로 떠넘겼던 판단을, 상수 임계값을 가진 조건문으로 내릴 수 있게 된다는 점이 핵심입니다.
주의할 안티패턴
- 질문 간 독립성을 깨지 말 것 — 질문 A의 답이 질문 B의 전제가 되면 안 됩니다. 질문을 추가해도 기존 답이 변하지 않아야 하고, 진짜 정보 의존성이 있을 때만 호출을 나눕니다.
- Score의 레벨을 추상적으로 쓰지 말 것 — “낮음/중간/높음”보다 각 레벨에 해당하는 구체적 상황을 써야 합니다.
- 애매할 때의 기본값을 만들지 말 것 —
other또는 사람 검토 경로를 명시적으로 두고, 불확실할 때 임의의 기본값으로 밀어넣지 않습니다. - 감사(audit) 기록을 남길 것 — 모델 버전, 질문 버전, 확률, 신뢰도, 최종 행동을 함께 저장해야 나중에 원인을 추적할 수 있습니다.
성능과 가격: 이 지점이 진짜 세일즈 포인트
| 항목 | Jev | 기존 프런티어 LLM |
|---|---|---|
| 응답 시간 | 70~500ms | 3~329초 |
| 입력 토큰 | $0.042 / MTok | $0.20~$10 / MTok |
| 출력 토큰 | 무료 | 입력의 약 5배 |
TypeSafe는 자체 워크플로우 평가에서 193.6배 빠르고 444.6배 저렴하다는 수치를 제시했습니다. DataCamp가 정리한 모델별 비교는 다음과 같습니다.
| 모델 | 정확도 | 케이스당 비용 | 지연시간 |
|---|---|---|---|
| Jev | 67.8% | $0.0004 | 0.4초 |
| GPT-5.6 Terra | 67.9% | $0.0304 | 10.1초 |
| GPT-5.6 Sol | 74.1% | $0.0836 | 23.3초 |
| Claude Opus 5 | 73.1% | $0.1761 | 37.8초 |
정리하면 GPT-5.6 Terra와 정확도는 거의 동등한데 비용은 76분의 1, 속도는 25배입니다. 다만 최상위 모델(Sol 74.1%, Opus 5 73.1%)과 비교하면 정확도는 6점가량 낮습니다. “제일 똑똑한 모델”이 아니라 “충분히 정확하면서 압도적으로 싸고 빠른 모델” 이라는 포지션입니다.
”환각할 수 없다”는 주장의 진짜 의미
TypeSafe의 마케팅 문구 중 가장 논쟁적인 부분입니다. 결론부터 말하면 이 주장은 형식(타입)에 대한 보장이지, 판단이 틀리지 않는다는 뜻이 아닙니다.
- ✅ 보장되는 것: 정의하지 않은 선택지를 출력하거나, 스키마에 없는 값을 뱉거나, 파싱이 깨지는 일이 없습니다. 구조화 출력 오류율 0%.
- ❌ 보장되지 않는 것: 허용된 선택지 안에서 높은 확률로 틀린 답을 고를 수 있습니다.
즉 "billing"이 아닌 엉뚱한 문자열이 나올 일은 없지만, 실제로는 technical 건인데 billing이라고 확신하는 상황은 얼마든지 가능합니다. 이 구분을 놓치면 Jev의 신뢰도를 과대평가하게 됩니다.
독립 검증 결과: 속도·가격은 사실, 정확도는 직접 확인 필요
출시 직후 나온 외부 평가들을 정리하면 방향이 일관됩니다. 속도와 가격 주장은 대체로 확인됐지만, 정확도와 캘리브레이션은 조건에 따라 흔들린다는 것입니다.
- Every의 초기 평가: 문서 37개에 대해 판단 777건을 0.7초 내에 처리, 비용 약 0.25센트. Claude Fable 5.1 대비 약 25배 빠름. 단 결함 7개 중 6개만 포착(Claude는 7개 전부).
- 사전 등록 평가(9월 20일): 400개 참조 세트에 5,721회 호출 기준 zero-shot 정확도 95.9%. 그런데 판단 기준(criteria) 설명을 잘못 쓰면 정확도가 16.7%까지 붕괴했습니다.
- 분포 외(OOD) 캘리브레이션 연구(9월 19일): 모델이 본 적 없는 합성 데이터에서 기대 캘리브레이션 오차(ECE)가 0.107로, 완벽 보정 기준(0.024)의 4.4배. 공개 벤치마크에서는 잘 보정돼 있지만 낯선 작업에서는 신뢰도가 헐거워집니다.
벤치마크 자체의 한계도 짚어둘 만합니다. TypeSafe의 핵심 수치는 자사 워크플로우 평가에 기반하며, 참조 정답을 사람이 만든 것이 아니라 GPT-6 Astra와 Claude Fable 5.1의 확률을 평균해 구성했습니다. TypeSafe도 이 방식이 OpenAI·Anthropic 모델 쪽으로 답을 편향시킬 수 있다는 점을 문서에서 인정하고 있습니다. 출시 시점에 세부 논문이나 ablation study도 공개되지 않았습니다.
여기서 중요한 실무 교훈은 criteria를 얼마나 잘 쓰느냐가 성능을 좌우한다는 점입니다. 95.9% → 16.7%라는 진폭은 모델 성능 문제가 아니라 프롬프트 설계 문제이고, 결국 Jev도 프롬프트(기준 설명) 품질에 크게 의존하는 모델입니다.
실사용 후기: Codex와 비교하면
튜링포스트 한국판이 동일한 보도자료 검증 작업으로 비교한 결과입니다.
| Jev | Codex | |
|---|---|---|
| 처리 시간 | 0.20초 | 4.61초 |
| 입력 토큰 | 616 | 15,984 |
약 23배 속도, 26배 토큰 차이입니다. 물론 특정 과제 기준이라 일반화할 수는 없습니다. 이 비교에서 얻을 결론은 “Jev가 Codex보다 낫다”가 아니라, 둘이 애초에 경쟁 관계가 아니라는 것입니다.
어디에 쓰고, 어디에 쓰면 안 되는가
Jev에 적합한 작업
- 수백만 건 단위의 티켓 분류·라우팅
- 제품 리뷰 대규모 감정 점수화, 50만 행 테이블의 정책 위반 검사
- LLM 출력 검증 및 실시간 가드레일(위험한 도구 호출 차단 등)
- 100ms 수준이 필요한 실시간 애플리케이션, 게임·앱 루프 내 반응형 판단
- 요청 복잡도를 평가해 어떤 LLM으로 보낼지 정하는 모델 라우팅
Jev로 할 수 없는 작업
- 코드 작성
- 이메일·요약 등 텍스트 생성
- 설명이 필요한 멀티스텝 추론
- 판단 근거를 자연어로 남겨야 하는 규제 도메인(해석 불가 문제)
위에서 정리한 계층 분리 구조를 그대로 적용하면 됩니다. LangChain도 langchain-typesafe로 TypeSafeClassifier를 제공하고 있어, 기존 에이전트 파이프라인에 판단 계층만 끼워 넣기는 어렵지 않습니다.
개발자에게 의미하는 바
1. “LLM 호출”을 기본값으로 두던 습관을 재검토할 시점
에이전트를 만들다 보면 단순 분기 판단에도 프런티어 LLM을 호출하게 됩니다. 라우팅, 가드레일, 재시도 여부 판단처럼 결과가 열거형(enum)으로 끝나는 결정에 초당 수십 센트를 쓰고 있다면, 그 계층만 떼어내는 선택지가 생긴 셈입니다.
2. 확률을 받는다는 것은 설계가 달라진다는 뜻
기존에는 LLM에 “확신도를 같이 알려줘”라고 부탁해도 그 숫자를 믿기 어려웠습니다. 보정된 확률이 API 응답으로 온다면 신뢰도 임계값을 코드에 상수로 박아 넣는 설계가 가능해집니다. 다만 위의 OOD 결과를 보면, 그 임계값은 자기 데이터로 직접 측정해서 정해야 합니다.
3. 벤더 수치는 여전히 벤더 수치다
40~200배, 444배 같은 숫자는 전부 자사 평가 기준입니다. 반대로 외부 평가들이 공통적으로 확인해준 것은 속도와 가격이었고, 흔들린 것은 정확도와 캘리브레이션이었습니다. 속도·비용은 믿고 도입 근거로 삼되, 정확도는 자기 데이터로 검증하는 것이 현재로선 합리적인 접근입니다.
결론
Jev는 “더 똑똑한 모델” 경쟁에 참가한 모델이 아니라, LLM이 과하게 쓰이고 있던 자리를 떼어내려는 모델입니다. 텍스트 생성을 포기하는 대신 속도와 비용에서 두 자릿수 배수의 차이를 만들었고, 출력 형식만큼은 구조적으로 보장합니다.
다만 “환각 불가”는 타입에 대한 보장일 뿐이고, 정확도는 최상위 LLM보다 낮으며, 판단 기준을 잘못 쓰면 성능이 크게 무너집니다. 지금 시점에서 현실적인 활용법은 LLM을 대체하는 것이 아니라, LLM 앞단의 값싼 판단 계층으로 끼워 넣는 것입니다.
핵심 정리
- 정체: 텍스트 대신 타입이 정해진 결정과 보정된 확률을 반환하는 첫 System One 모델
- 성능: 응답 70~500ms, 입력 $0.042/MTok에 출력 무료 — GPT-5.6 Terra와 정확도 동등에 비용 1/76
- 한계: 최상위 모델보다 정확도 약 6점 낮고, 코드·텍스트 생성과 설명은 불가
- 환각 불가의 의미: 타입 오류가 없다는 뜻이며, 틀린 선택을 하지 않는다는 뜻은 아님
- 검증 상태: 외부 평가가 속도·가격은 확인, 정확도와 OOD 캘리브레이션은 조건부
- 설계 방식: 큰 업무를 원자적 질문으로 쪼개고, 최종 결정은 코드가 확률로 분기
- 활용법: 분류·라우팅·가드레일은 Jev, 생성·추론은 LLM으로 분업
더 자세한 내용은 TypeSafe AI 공식 발표와 공식 문서에서 확인하실 수 있습니다.