Jev가 뭐냐
Jev가 뭐냐
판단만 빠르게 하는 AI가 나온 이유
최근 AI 모델은 점점 더 많은 일을 할 수 있게 됐습니다.
코드를 작성하고, 웹을 검색하고, Tool을 호출하고, 여러 단계를 거쳐 문제를 해결합니다.
그런데 실제 서비스를 만들다 보면 모든 문제에 이런 큰 모델이 필요한 것은 아닙니다.
예를 들어 이런 판단이 있습니다.
이 문의는 결제 문제인가?
이 요청을 검색으로 보낼까,
DB 조회로 보낼까?
이 메시지는 위험한가?
이 결과를 자동 승인해도 되는가?
이 Agent의 응답을 다시 검토해야 하는가?각각은 AI가 필요한 문제일 수 있습니다.
하지만 GPT나 Claude 같은 Frontier LLM에게 매번 긴 답변을 생성하게 하는 것은 꽤 비싼 방법이기도 합니다.
TypeSafe AI가 2026년 9월 14일 공개한 Jev는 바로 이 지점을 노립니다.
Jev는 대화를 잘하는 모델이 아닙니다.
코드를 길게 작성하는 모델도 아닙니다.
TypeSafe는 Jev를 새로운 System One Model이라고 부릅니다.
핵심은 단순합니다.
문장을 생성하는 대신, 소프트웨어가 바로 사용할 수 있는 판단을 빠르게 반환합니다.
1. Jev는 무엇이 다른가
일반적인 LLM은 기본적으로 문자열을 생성합니다.
Input
↓
LLM
↓
Token
↓
Token
↓
Token
↓
Text결과가 JSON이더라도 기본적으로는 문자열 생성입니다.
{
"category": "billing",
"confidence": 0.96
}Structured Output이나 JSON Schema를 사용하면 결과 형태를 강제할 수 있지만, 내부에서는 여전히 Token을 순차적으로 생성하는 Generative Model입니다.
Jev는 이 방향을 처음부터 다르게 잡았습니다.
Unstructured State
↓
Jev
↓
Typed Probabilistic Decision예를 들어:
사용자 메시지
"카드 결제가 두 번 됐어요."를 넣고
billing
technical
account
other중 하나를 판단하도록 하면 Jev는 긴 설명을 생성하는 대신 각 선택지에 대한 판단과 확률을 반환하는 구조입니다.
개념적으로는:
billing 0.96
technical 0.02
account 0.01
other 0.01처럼 사용할 수 있습니다.
그래서 TypeSafe는 Jev를
“frontier-intelligence function call”
에 가깝다고 설명합니다.
2. 챗봇보다 if문에 가까운 AI다
Jev를 이해하기 가장 쉬운 방법은 챗봇보다 똑똑한 조건문이라고 생각하는 것입니다.
기존 코드라면 이런 식입니다.
if message.contains("결제") {
route = .billing
} else if message.contains("비밀번호") {
route = .account
}문제는 현실의 언어가 이렇게 단순하지 않다는 것입니다.
"결제가 안 된 것 같은데 돈은 빠져나갔어요."
"카드는 정상인데 주문이 두 번 잡혔습니다."
"환불했다고 했는데 아직 입금이 안 됐어요."Rule을 계속 늘리기 시작하면 유지하기 어려워집니다.
Jev가 노리는 영역은 이 사이입니다.
Hard-coded if
↓
Jev
↓
Full LLM Agent규칙만으로 처리하기에는 애매하지만,
GPT나 Claude Agent까지 호출하기에는 과한 판단입니다.
3. TypeSafe는 이것을 System One Model이라고 부른다
이름은 Daniel Kahneman의 《Thinking, Fast and Slow》에서 가져왔습니다.
Kahneman은 인간의 사고를 크게 두 가지로 설명했습니다.
System 1
빠름
직관적
즉각적그리고
System 2
느림
숙고
복잡한 추론TypeSafe는 이 개념을 AI Model Architecture에 적용했습니다.
기존 Reasoning LLM이 상대적으로:
Input
↓
Reasoning
↓
Generation
↓
Answer에 가깝다면,
Jev는:
Input
↓
Decision에 집중합니다.
그래서 모델 이름도 System One Models입니다.
Jev라는 이름은 경제학자 William Stanley Jevons에서 가져왔습니다.
4. Jev는 작은 LLM이 아니다
여기서 가장 쉽게 오해할 부분입니다.
Jev를 단순히
작은 LLM이라고 보면 정확하지 않습니다.
TypeSafe는 Jev를 기존 Language Model을 줄여 만든 모델이 아니라 결정이라는 다른 Task를 위해 새로 만든 Architecture라고 설명합니다.
학습 방식도 RLHF가 아닙니다.
TypeSafe는 자체 학습 방법을:
RLCD라고 부릅니다.
Reinforcement Learning for Calibrated Decisions입니다.
기존 LLM이 주로:
사람이 좋아하는 답변
검증 가능한 정답을 최적화한다면,
Jev는:
정확한 판단
+
그 판단이 얼마나 확실한지를 함께 학습하는 방향입니다.
즉 목표 함수 자체가 다릅니다.
5. 가장 중요한 특징은 Confidence다
자동화 시스템에서 AI가 어려운 이유 중 하나는 AI가 틀릴 때 자신이 틀렸다는 사실을 모르는 것입니다.
예를 들어 실제 정확도가 95%인 모델이 있다고 해보겠습니다.
문제는 나머지 5%입니다.
모델이 모든 결과에:
confidence = 0.99를 내놓는다면 자동화하기 어렵습니다.
반대로 모델의 Confidence가 실제 정확도와 잘 맞는다면 시스템을 이렇게 만들 수 있습니다.
Confidence > 0.95
↓
자동 처리
0.70 ~ 0.95
↓
큰 LLM으로 재검토
< 0.70
↓
사람에게 전달TypeSafe가 Jev에서 특히 강조하는 것이 바로 이 Calibrated Probability입니다.
단순히 답을 반환하는 것이 아니라 불확실성도 같이 반환합니다.
6. 이게 Agent 시스템에서는 꽤 중요하다
최근 Agent Architecture에서 가장 자주 반복되는 작업 중 하나가 Routing입니다.
예를 들어:
User Request
↓
Router
↓
┌───┼─────────┐
Search DB Coding AgentRouter도 LLM으로 만들 수 있습니다.
하지만 요청이 들어올 때마다 Frontier Model을 호출하면 비용과 Latency가 커집니다.
Jev 같은 모델을 Router로 넣으면 구조가 달라집니다.
User Request
↓
Jev
↓
┌──────┼─────────┐
Search DB Agent그리고 Jev의 Confidence까지 사용합니다.
Search Agent 0.87
Database Tool 0.08
Human Review 0.05가 나오면 Search Agent로 보냅니다.
Confidence가 낮다면:
Research Agent 0.42
Database Tool 0.38
Human Review 0.20바로 실행하지 않고 큰 모델이나 사람에게 판단을 넘길 수 있습니다.
7. Multi-Agent에서도 Router 역할로 잘 맞는다
멀티에이전트 시스템을 생각해보면 더 이해하기 쉽습니다.
Main System
│
┌───────────┼───────────┐
│ │ │
Coding Agent Research Security
Agent Agent모든 요청을 Main LLM이 분석하고 적절한 Agent에게 전달할 수도 있습니다.
하지만 요청량이 많다면 Routing 자체가 상당한 비용이 됩니다.
중간에 Jev를 넣을 수 있습니다.
Request
↓
Jev
↓
Agent Routing
↓
선택된 Agent만 호출즉 Jev가 Agent를 대체하는 것이 아닙니다.
Agent가 필요한지를 먼저 판단하는 앞단의 Decision Layer가 되는 것입니다.
8. Skill + MCP 구조와도 잘 맞는다
최근 Agent Architecture는 모든 기능을 Agent로 만들기보다:
Skill
+
MCP Tool을 활용하는 방향으로 가고 있습니다.
예를 들어 사용자의 요청이 들어왔을 때:
Swift Migration Skill
Release Skill
GitHub MCP
Research Agent중 어디로 보낼지 결정해야 합니다.
구조는 이렇게 만들 수 있습니다.
Request
↓
Jev
↓
┌──────┬────────┬────────────┐
Skill MCP Research Agent즉 Jev는 Agent Orchestrator 전체를 대신하기보다 Orchestrator가 반복적으로 하는 작은 판단을 줄이는 역할에 가깝습니다.
9. Moderation과 Guardrail도 대표적인 사용처다
두 번째로 잘 맞는 영역은 Moderation입니다.
기존 구조는:
Input
↓
LLM
↓
위험 여부 판단입니다.
하지만 서비스 요청마다 큰 모델을 호출한다면 부담이 됩니다.
Jev는 이런 형태의 판단에 맞게 설계됐습니다.
Safe 0.96
Harmful 0.03
Uncertain 0.01또는:
Prompt Injection
Yes 0.91
No 0.09처럼 사용할 수 있습니다.
특히 Agent 시스템에서는:
User Input
↓
Guardrail
↓
Agent
↓
Tool Call구조에서 매우 낮은 Latency의 판단 모델이 유용할 수 있습니다.
10. Agent의 출력 검증에도 사용할 수 있다
Jev는 입력만 분류하는 모델로 볼 필요도 없습니다.
Agent가 생성한 결과를 평가하는 Layer로도 사용할 수 있습니다.
예를 들어 Coding Agent가 수정 결과를 만들었습니다.
Coding Agent
↓
Code Change
↓
Jev Verification여기서:
요청을 충족했는가?
YES 0.94
NO 0.06또는:
Security Risk
Low 0.82
Medium 0.15
High 0.03같은 판단을 사용할 수 있습니다.
물론 실제 Build와 Test를 대체하는 것은 아닙니다.
Compiler
Test
Static Analysis처럼 결정적인 검증이 가능한 부분은 코드로 검증해야 합니다.
Jev는 그 사이의 애매한 판단을 담당하는 것이 더 적합합니다.
11. 그래서 검증 가능한 것은 코드로가 중요하다
Jev를 쓴다고 모든 조건문을 AI로 바꿀 필요는 없습니다.
예를 들어:
HTTP Status == 200은 코드로 판단하면 됩니다.
Build Success도 Tool 결과를 보면 됩니다.
Unit Test Passed역시 AI가 필요 없습니다.
반면:
이 리뷰 의견이 blocking issue인가?
이 고객 문의는 긴급한가?
이 검색 결과가 질문과 관련 있는가?
이 요청은 어느 Agent에게 보내야 하는가?같은 것은 Rule로 만들기 어렵습니다.
그래서 좋은 구조는:
Hard Logic
→ Code
Ambiguous Decision
→ Jev
Deep Reasoning
→ LLM / Agent입니다.
12. 일반 LLM의 Structured Output과는 뭐가 다를까
GPT나 Claude도 JSON Schema를 사용할 수 있습니다.
예를 들어:
{
"route": "research",
"confidence": 0.91
}를 반환하도록 만들 수 있습니다.
그렇다면 굳이 Jev가 필요한가라는 질문이 생깁니다.
차이는 Structured Output을 지원하느냐가 아니라 모델이 무엇을 위해 설계됐느냐입니다.
일반 LLM은:
Generative Model
↓
Schema Constraint
↓
Structured Output입니다.
Jev는:
Decision Model
↓
Typed Decision자체가 목적입니다.
그리고 TypeSafe 설명에 따르면 Jev는 모든 결과를 순차 Token Generation이 아니라 병렬로 계산합니다.
문장을 생성하지 않기 때문에 Output Generation Cost도 거의 없습니다.
13. Type Safety라는 이름도 여기에서 나온다
TypeSafe가 특히 강조하는 부분이 Output Type입니다.
일반 LLM에서는 이런 문제가 생길 수 있습니다.
{
"confidence": "very high"
}원래 Double을 기대했는데 문자열이 올 수 있습니다.
또는:
{
"route": "some_new_route"
}처럼 Schema 밖의 값을 생성할 수도 있습니다.
Structured Output 기능을 사용하면 이런 문제를 상당히 줄일 수 있습니다.
Jev는 처음부터 가능한 Output Domain을 정하고 그 안에서 결정을 반환하도록 설계됐습니다.
TypeSafe는 이 특성 때문에 type error가 구조적으로 발생하지 않는다고 설명합니다.
이 부분과 의미적으로 잘못된 판단은 구분해야 합니다.
Wrong Type과
Wrong Decision은 다른 문제입니다.
Jev도 판단 자체는 틀릴 수 있습니다.
14. “Jev는 Hallucination이 없다”는 표현은 조심해서 봐야 한다
TypeSafe 공식 자료에는 Jev가 can't hallucinate, 홈페이지에는 Zero Hallucinations라는 강한 표현이 있습니다.
이건 그대로 받아들이기보다 어떤 의미인지 구분해서 보는 게 좋습니다.
Jev는 자유로운 문자열을 생성하지 않습니다.
따라서:
존재하지 않는 API 이름 생성
없는 Tool 이름 생성
Schema 밖 필드 생성같은 Generative Hallucination Surface는 크게 줄어듭니다.
특히 Type Schema를 벗어나는 Output은 구조적으로 막을 수 있습니다.
하지만:
billing을 technical로 잘못 분류하는 것은 여전히 가능합니다.
즉:
Type Error ❌와
Decision Error 가능을 구분해야 합니다.
이 때문에 Confidence Calibration이 중요합니다.
15. 속도는 Jev의 가장 눈에 띄는 부분이다
TypeSafe 공식 발표에 따르면 Jev의 End-to-end Response Time은 현재 대략:
70ms ~ 500ms범위입니다.
회사는 같은 수준의 System One 작업에서 Frontier LLM 대비:
40x ~ 200x빠를 수 있다고 설명합니다.
Workflow Evaluation에서는 최대:
193.6x faster라는 수치도 제시합니다.
다만 이 숫자는 반드시 맥락을 같이 봐야 합니다.
TypeSafe도 직접 밝히고 있습니다.
해당 Workflow는 System One 형태에 적합한 작업이고, 이 수치가 실제 사용 사례에서 기대할 수 있는 효과 중 높은 편일 가능성이 있다고 설명합니다.
따라서:
Jev가 GPT보다 193배 빠르다라고 일반화하면 안 됩니다.
정확한 표현은:
TypeSafe가 설계한 System One Workflow Evaluation에서는 최대 약 193배 빠른 결과가 나왔다.
정도가 적절합니다.
16. 비용도 같은 방식으로 봐야 한다
현재 공개 가격은:
Input
$0.042 / 1M tokens입니다.
즉:
$42 / 1B input tokens입니다.
TypeSafe는 Output Token은 별도로 과금하지 않는다고 설명합니다.
회사 Workflow Evaluation에서는 Frontier LLM 대비 최대:
444.6x cheaper라는 결과도 공개했습니다.
하지만 이 역시 Jev에 유리한 Decision-oriented Workflow에서 측정된 회사 자체 Evaluation입니다.
실제 비용 효과는 자신의 서비스 Workflow에서 직접 측정하는 편이 안전합니다.
17. 왜 이렇게 빠를까
일반 LLM은 Autoregressive Generation을 사용합니다.
Token 1
↓
Token 2
↓
Token 3
↓
Token 4앞 Token이 생성돼야 다음 Token을 만들 수 있습니다.
문장이 길어질수록 Latency도 늘어납니다.
Jev는 문자열을 생성하지 않습니다.
TypeSafe는 Parallel Sampler를 이용해 필요한 결정을 한 Query에서 병렬로 출력한다고 설명합니다.
예를 들어 질문이:
이 사용자는 이탈할 가능성이 높은가?
이 요청은 사기일 가능성이 있는가?
Human Review가 필요한가?세 개라면 각각의 답변 문장을 순차적으로 만드는 것이 아니라 여러 판단을 동시에 계산하는 방향입니다.
자동화 시스템에서는 이 차이가 큽니다.
18. 실시간 서비스에는 꽤 흥미로운 구조다
100ms 안팎의 판단이 가능해진다면 LLM을 넣기 어려웠던 영역에도 AI를 사용할 수 있습니다.
예를 들어:
게임 상태 판단
실시간 추천
광고 Routing
Fraud Risk
Moderation
Search Ranking
Agent Routing같은 영역입니다.
TypeSafe는 실제 Demo로 Doom 게임 상태를 Jev가 판단하면서 움직이는 사례도 공개했습니다.
이미지 자체를 보는 Vision Model은 아니고, 게임 상태를 구조화된 Text/Data로 전달한 뒤 판단하는 방식입니다.
19. 대량 데이터 처리에도 성격이 잘 맞는다
LLM으로 수백만 개의 Record를 하나씩 처리하면 비용과 시간이 빠르게 커집니다.
예를 들어:
10,000,000 고객
↓
각 고객의 churn 가능성 평가를 Frontier LLM으로 처리하면 꽤 큰 작업입니다.
Jev가 노리는 영역은 이런 Map-style Decision Workload입니다.
Record 1 → Score
Record 2 → Score
Record 3 → Score
...같은 작업입니다.
문장을 생성할 필요가 없기 때문에 Decision Model의 장점이 크게 나타날 수 있습니다.
20. 모든 작업에 Jev가 좋은 것은 아니다
Jev는 의도적으로 문자열 생성을 포기했습니다.
따라서 다음 작업에는 적합하지 않습니다.
코드 작성
문서 작성
이메일 작성
소설 작성
사용자와 긴 대화
복잡한 설명
새로운 설계 생성이건 GPT, Claude, Gemini 같은 Generative Model이 훨씬 자연스럽습니다.
또:
Repository 전체 분석
장애 원인 탐색
Research
Architecture 설계같이 장시간 Reasoning과 탐색이 필요한 작업도 Jev 하나로 해결하려는 문제는 아닙니다.
21. Jev와 LLM을 경쟁 관계로 볼 필요가 없다
실제 Architecture에서는 둘을 같이 쓰는 형태가 더 자연스럽습니다.
예를 들어:
User Request
↓
Jev
↓
┌─────┼──────────┐
Tool Skill Agent
↓
GPT / Claude또는:
Agent Output
↓
Jev
↓
Confidence High?
│ │
YES NO
↓ ↓
사용 재검토입니다.
Jev가 빠른 판단을 담당하고,
큰 LLM은 실제 Reasoning과 Generation을 담당합니다.
이렇게 보면 Jev의 포지션이 훨씬 명확해집니다.
22. 멀티에이전트 비용을 줄이는 앞단 Router로도 볼 수 있다
Agent가 많아질수록 Routing 자체도 중요한 문제가 됩니다.
Main Agent
├─ Coding Agent
├─ Security Agent
├─ Research Agent
├─ Data Agent
└─ Release Agent매번 Main LLM에게:
어느 Agent가 이걸 처리해야 하지?
라고 물어볼 수도 있습니다.
하지만 이 판단이 충분히 정형화됐다면 Jev가 앞에서 처리할 수 있습니다.
Request
↓
Jev Router
↓
Agent이렇게 하면 모든 요청에 Main Reasoning Model을 먼저 호출하지 않아도 됩니다.
특히 Agent 요청량이 많아질수록 의미가 커질 수 있습니다.
23. Confidence Gate가 실무에서 핵심이 될 수 있다
Jev에서 가장 개발자다운 부분은 모델보다 Architecture Pattern일 수 있습니다.
예를 들어:
Jev
↓
Confidence결과를 그대로 사용하는 것이 아니라 Threshold를 둡니다.
> 0.95
자동 실행0.70 ~ 0.95
Frontier LLM 검토< 0.70
Human Review이렇게 구성하면 AI를 Binary Decision Maker가 아니라 Risk-aware Decision Component로 사용할 수 있습니다.
이 패턴은:
Agent Routing
Moderation
Fraud
Approval
Quality Gate전부에 적용할 수 있습니다.
24. Jev가 정말 중요한 이유는 모델보다 인터페이스일 수도 있다
지금까지 AI API의 중심은 대부분 Text였습니다.
String In
↓
Model
↓
String OutSoftware에서는 다시 이 문자열을 해석합니다.
String
↓
Parse
↓
Validate
↓
Business LogicJev가 제안하는 인터페이스는 다릅니다.
State
↓
Model
↓
Typed Decision
↓
CodeAI가 사람에게 말을 잘하는 Component가 아니라 프로그램 내부에서 호출되는 Decision Primitive에 가까워집니다.
이 방향이 실제로 자리 잡는다면 AI Architecture에도 꽤 큰 변화가 생길 수 있습니다.
25. 아직은 Early Access라는 점도 중요하다
현재 Jev는 Early Access입니다.
2026년 9월 14일 처음 공개됐고, TypeSafe는 Waitlist 사용자부터 순차적으로 Access를 제공하고 있습니다.
따라서 아직 확인해야 할 것이 많습니다.
실제 Production Reliability
Traffic이 늘었을 때 Latency
Pricing 지속 가능성
Domain별 Accuracy
Confidence Calibration
Long-term Stability등입니다.
특히 현재 공개된 대부분의 성능 자료는 TypeSafe 자체 Evaluation입니다.
회사는 이 점을 상당히 솔직하게 밝히고 있습니다.
Workflow가 내부 Model Capabilities 팀에 의해 만들어졌기 때문에 Bias가 있을 가능성도 인정하고 있습니다.
26. Benchmark 숫자보다 실제 Workflow 평가가 더 중요하다
TypeSafe는 Standard Benchmark 중심 경쟁에도 비판적인 입장입니다.
공개 Benchmark에 맞춰 반복적으로 Model을 개선하면 결국 Benchmark 자체에 Overfit될 수 있다는 이유입니다.
그래서 Jev는 일반적인 Benchmark Table보다 실제 Automation Workflow를 평가 대상으로 삼고 있습니다.
이 접근 자체는 꽤 흥미롭습니다.
개발자 입장에서 중요한 것도 결국:
Benchmark Score보다
우리 Workflow에서
얼마나 정확한가?
얼마나 빠른가?
얼마나 싼가?
Confidence가 실제로 믿을 만한가?이기 때문입니다.
27. 실제 도입을 검토한다면 이렇게 보는 게 좋다
Jev를 적용할 후보를 찾을 때는 먼저 현재 시스템에서 Frontier LLM이 이런 작업을 하고 있는지 확인하면 됩니다.
분류
점수화
라우팅
검증
Filter
Guardrail그리고 질문합니다.
이 작업에서 실제로 긴 Text Generation이 필요한가?
필요하지 않다면 Jev 같은 Decision Model을 검토할 가치가 있습니다.
반대로:
복잡한 추론
코드 생성
대화
문서 생성이 필요하다면 기존 LLM을 유지하는 편이 맞습니다.
28. 개발자 입장에서 가장 현실적인 구조
현재 기준으로는 이런 Architecture가 가장 이해하기 쉽습니다.
Request
↓
Jev
↓
┌─────────┼─────────┐
│ │ │
Tool Skill Agent
│
GPT / Claude그리고 마지막에 다시 Jev를 붙일 수도 있습니다.
Agent Result
↓
Jev
↓
Verification / Score
↓
Code즉:
Jev
→ 빠른 판단
LLM
→ 깊은 추론과 생성
Code
→ 확실한 규칙으로 역할을 나누는 것입니다.
마치며
Jev가 흥미로운 이유는 GPT나 Claude보다 더 똑똑한 새로운 Frontier Model이 나왔기 때문이 아닙니다.
애초에 목표가 다릅니다.
기존 LLM은:
생각하고
말하고
생성한다.Jev는:
판단한다.에 집중합니다.
TypeSafe가 강조하는 것도 바로 이 차이입니다.
긴 Text를 만들 필요가 없는 Software Decision에 매번 Generative LLM을 사용하는 것이 과한 것은 아닌가라는 질문입니다.
그래서 Jev를 가장 단순하게 표현하면:
빠르고 저렴한 AI 판단 함수
에 가깝습니다.
특히:
Routing
Classification
Scoring
Verification
Moderation
Guardrail같은 영역에서 의미가 있습니다.
반대로:
Coding
Research
Writing
Long-running Reasoning은 여전히 LLM과 Agent의 영역입니다.
결국 앞으로 AI 시스템이 이런 식으로 나뉠 가능성도 있습니다.
확실한 규칙
→ Code
애매하지만 빠른 판단
→ Jev
복잡한 추론
→ LLM
장기적인 작업
→ Agent모든 문제에 가장 큰 LLM을 호출하는 방식에서 벗어나 문제의 성격에 맞는 Intelligence Layer를 선택하는 구조입니다.
Jev가 실제 Production 환경에서도 현재 공개된 속도와 Calibration을 유지할 수 있을지는 더 지켜봐야 합니다.
하지만 방향 자체는 꽤 흥미롭습니다.
AI를 더 크게 만드는 경쟁과 별개로,
AI를 더 작은 Software Primitive로 만드는 경쟁도 시작되고 있습니다.
참고자료
-
TypeSafe AI — Introducing System One Models and Jev
Jev의 Architecture, RLCD, Parallel Sampling, Structured Decision, Confidence, Pricing과 Workflow Evaluation을 설명한 공식 발표입니다.
TypeSafe AI 공식 발표 -
TypeSafe AI — Workflow Evals
Jev와 Frontier LLM을 실제 Decision Workflow에 넣어 Accuracy·Latency·Cost를 비교한 평가 방법과 Query를 확인할 수 있습니다.
TypeSafe Workflow Evals -
TypeSafe AI — System One Models
Jev의 현재 가격, Typed Decision, Calibration과 Automation 중심 설계를 정리한 공식 제품 페이지입니다.
TypeSafe AI 공식 사이트 -
TypeSafe AI — Lies, Damned Lies, and Benchmarks
TypeSafe가 Standard Benchmark Table보다 Workflow Evaluation을 사용하는 이유와 Benchmark Overfitting에 대한 입장을 설명합니다.
TypeSafe AI Benchmark 관련 글
TypeSafe 공식 자료 기준으로 보면, Jev는 2026년 9월 14일 Early Access로 공개된 첫 System One Model입니다. 일반 LLM처럼 문자열을 생성하지 않고 미리 정의된 타입의 판단과 확률을 반환하도록 설계됐으며, 회사는 이를 위해 RLCD와 Parallel Sampler라는 별도 Training·Inference 방식을 사용한다고 설명합니다.
현재 공개 가격은 입력 100만 Token당 $0.042이며 Output Token은 별도 과금하지 않습니다. TypeSafe는 현재 서비스 Latency를 약 70~500ms라고 밝히고 있으며, 자체 Workflow Evaluation에서는 최대 193.6배 빠르고 444.6배 저렴한 결과를 공개했습니다. 다만 회사 역시 이 수치가 실제 효과 중 높은 편일 가능성이 있고 Evaluation 설계에 내부 Bias가 존재할 수 있다는 점을 명시하고 있습니다.
또 하나 주의할 부분은 TypeSafe가 사용하는 Zero Hallucinations 표현입니다. Jev의 Output Schema가 미리 정해져 있기 때문에 Schema 밖의 값이나 Type Error를 생성하지 않는다는 의미에서는 강한 구조적 보장이 가능합니다. 하지만 Model이 잘못된 선택지를 높은 확률로 고르는 Decision Error 자체가 불가능하다는 의미로 받아들이면 안 됩니다. 실제 Production 적용에서는 Calibration과 Confidence Threshold를 반드시 함께 평가하는 것이 중요합니다.
