JEV · SYSTEM ONE MODEL · AGENTIC AI · DECISION MODEL
AI에게 글쓰기를 금지했더니
판단이 빨라졌다 — Jev는 대체 뭐길래?
ChatGPT, Claude, Gemini 같은 AI에게 우리는 늘 “대답해줘”라고 했다. 그런데 2026년 9월 등장한 Jev는 방향이 꽤 다르다. 얘한테는 멋진 답변을 쓰라고 하지 않는다.
판단만 해.”
Choice · Score · Probability 같은 소프트웨어가 바로 사용할 수 있는 판단을 반환한다.
처음 보면 이런 생각이 든다.
좋은 질문이다. 실제로 Jev의 많은 작업은 겉으로 보면 Classification과 상당히 닮았다.
그런데 Jev가 흥미로운 이유는 단순히 새로운 분류 모델 하나가 등장했기 때문이 아니다. TypeSafe AI가 던진 질문이 꽤 도발적이기 때문이다.
“우리는 왜 소프트웨어의 작은 판단 하나를 시키려고 매번 거대한 언어 모델에게 문장을 쓰게 하고 있을까?”
``` LLM이 “무엇을 말할지” 생성한다면, Jev는 “어느 쪽으로 갈지” 판단하고, 실제 행동과 권한 통제는 Code / Policy Engine이 담당한다.
그래서 Agent 시대에는 의외로 중요한 조합이 될 수 있다.
LLM writes → Jev decides → Code acts. ```
시작은 아주 사소한 문제다: “환불해도 될까요?”
고객센터 AI Agent가 있다고 해보자.
고객이 이렇게 말했다.
지금 당장 환불해주세요.”
Agent는 몇 가지 판단을 해야 한다.
환불? 해지? 이중결제?
일반 / 긴급
Agent / Human
Fraud 가능성?
지금까지라면 LLM에게 이런 식으로 시킬 수 있다.
You are a customer service classifier.
Analyze the following conversation.
Return JSON:
{
"intent": "...",
"urgency": "...",
"route": "...",
"fraud_risk": ...
}꽤 잘 작동한다. Structured Output이나 JSON Schema를 사용하면 출력 형식도 상당히 안정적으로 만들 수 있다.
그런데 TypeSafe가 문제 삼는 것은 그보다 한 단계 아래다.
필요한 결과가 결국
REFUND,
HUMAN_REVIEW,
0.82
같은 값이라면 수십~수백 개의 output token을 autoregressive하게 생성할 필요가 있을까?
LLM은 기본적으로 ‘다음 단어 맞히기 기계’다
여기서 Jev를 이해하려면 LLM이 답을 만드는 방식을 아주 조금만 알아야 한다.
일반적인 생성형 LLM은 대략 이런 식이다.
↓
REFUND → 을 → 추천 → 합니다 → ...
인간과 대화할 때는 이 구조가 훌륭하다. 이메일도 쓰고, 코딩도 하고, 설명도 하고, 농담도 한다.
하지만 프로그램 내부에서는 이야기가 조금 달라진다.
우리가 원하는 것이 단지
route = "refund"
confidence = 0.94뿐이라면 자유로운 문자열 생성 능력은 오히려 필요 이상의 범용성일 수 있다.
그래서 Jev는 아예 문자열 생성을 버렸다
TypeSafe AI는 Jev를 System One Model이라고 부른다. 이름은 Daniel Kahneman의 System 1 / System 2 구분에서 가져왔다.
여기서 중요한 것은 심리학 이론 자체보다 제품의 설계 철학이다.
| 일반 LLM | Jev / System One | |
|---|---|---|
| 주요 목적 | 텍스트 생성·Reasoning | Structured Decision |
| 출력 | String / Token | Typed Value + Probability |
| Sampling | 주로 순차적 생성 | 병렬 Decision |
| 강점 | 범용 생성 | Routing · Scoring · Classification |
| 철학 | “답을 만들어라” | “결정을 내려라” |
가장 쉬운 비유: Jev는 ‘엄청 똑똑한 if문’이다
프로그램에서 가장 오래된 판단 도구는 사실 이것이다.
if amount > 1_000_000:
route = "manual_review"
else:
route = "auto"문제는 현실의 판단이 이렇게 깔끔하지 않다는 것이다.
예를 들어,
“이 요청은 Fraud 가능성이 있는가?”
“이 Agent 실행 결과는 사람이 검토해야 하는가?”
“이 질문은 SQL Agent로 보낼까, RAG Agent로 보낼까?”
이런 것은 규칙으로 모두 표현하기 어렵다. 그렇다고 매번 거대한 LLM에게 에세이를 쓰게 할 필요도 없다.
Jev가 노리는 곳이 바로 이 중간이다.
Jev에게 시킬 수 있는 일은 놀랄 만큼 단순하다
현재 API에서 핵심 질문 형태는 크게 세 종류다.
예를 들어 Agent가 어떤 Tool을 호출하려 한다고 해보자.
state:
user_request: "지난달 거래 전부 취소해줘"
proposed_tool: "cancel_transactions"
account_context: ...
questions:
- Is human review required?
- How risky is this action?
- Which route should handle this?
[AUTO, REVIEW, REJECT]결과의 핵심은 설명문이 아니라 이런 값들이다.
route:
AUTO: 0.03
REVIEW: 0.91
REJECT: 0.06
confidence: high그러면 애플리케이션이 판단을 받아 다음 행동을 결정한다.
if review_probability > 0.90:
require_human_approval()
elif review_probability > 0.60:
run_additional_checks()
else:
continue_workflow()이 구조에서 중요한 변화가 보인다.
AI가 행동을 결정하는 것이 아니다.
AI는 불확실한 현실을 숫자로 해석하고,
최종 행동 규칙은 코드가 소유한다.
Agent Architecture에 넣으면 더 재미있어진다
Jev가 특히 흥미로운 곳은 Agentic AI다.
요즘 Agent 하나를 뜯어보면 생각보다 “판단”이 엄청 많다.
예를 들어 RAG Agent 하나만 만들어도 이런 판단들이 있다.
↓
RAG가 필요한가?
↓
어떤 Retriever를 쓸까?
↓
검색 결과가 충분한가?
↓
다시 검색할까?
↓
Tool을 호출해도 되는가?
↓
결과가 답변하기에 충분한가?
↓
Generate Answer
지금은 이 판단을 Main LLM이 모두 수행하는 경우가 많다.
그런데 각 단계에서 LLM을 다시 호출하면 latency와 cost가 누적된다.
Jev의 주장은 단순하다.
고르기만 하면 되는 순간에는 Decision Model을 쓰자.”
그래서 얼마나 빠르다는 건데?
TypeSafe가 2026년 9월 공개한 자료 기준으로 Jev는 약 70~500ms end-to-end latency를 제시하고 있으며, 입력 가격은 100만 input token당 $0.042다. 별도의 생성 output token을 만들지 않기 때문에 output token 비용은 없다고 설명한다.
회사는 자체 System One workflow 평가에서 기존 LLM 대비 매우 큰 속도·비용 차이를 보고하고 있다. 다만 여기에는 중요한 별표가 붙는다.
공개된 비교는 TypeSafe가 정의한 System One 형태의 workflow를 중심으로 한다. 회사 스스로도 일부 결과가 실제 환경에서 얻을 수 있는 개선 폭의 높은 쪽일 가능성이 있다고 명시한다.
즉 “Jev가 GPT보다 100배 똑똑하다”는 이야기가 아니다. 애초에 서로 최적화한 작업이 다르다.
더 깊게 들어가면: RLHF가 아니라 RLCD
TypeSafe는 Jev에 사용하는 학습 방법을 Reinforcement Learning for Calibrated Decisions, RLCD라고 부른다.
기존 Chat LLM의 RLHF가 대략 “사람이 더 선호하는 답변”을 만드는 방향이라면, TypeSafe가 설명하는 RLCD의 목표는 “판단과 확률을 더 잘 calibration하는 것”에 가깝다.
``` 어떤 모델이 100개의 거래를 보고 모두
“Fraud일 확률 90%”라고 말했다면,
정말 그 그룹에서 대략 90개가 Fraud여야 그 90%라는 숫자를 운영 threshold로 사용할 수 있다.
정답을 맞히는 능력과 자기가 얼마나 확신해야 하는지 아는 능력은 다른 문제다. ```
Agent Automation에서는 이 차이가 상당히 중요하다.
80% 정확한 AI보다 운영하기 어려운 것은 틀릴 때도 항상 99% 확신하는 AI다.
그런데 “Hallucination이 없다”는 말은 조심해서 읽어야 한다
TypeSafe는 Jev를 설명하면서 type-safe output과 함께 “zero hallucinations”라는 강한 표현을 사용한다.
이 말은 정확히 쪼개서 이해할 필요가 있다.
정의되지 않은 option 생성
malformed JSON
schema 밖의 문자열
존재하지 않는 enum 값
틀린 Classification
잘못된 Risk Score
잘못된 Route 선택
과도하거나 부족한 Confidence
즉 output space 밖의 값을 만들어내는 문제와 허용된 선택지 중 틀린 것을 고르는 문제는 다르다.
Jev가 [ALLOW, REVIEW, BLOCK] 중에서 반드시 하나만 반환한다고 해도,
실제로 BLOCK해야 할 거래를 ALLOW라고 판단할 가능성까지 사라지는 것은 아니다.
Jev의 진짜 장점은 “절대 틀리지 않는 AI”라기보다 오류의 공간을 제한하고, 확률을 애플리케이션이 다룰 수 있는 형태로 노출한다는 데 있다고 보는 편이 안전하다.
그런데 진짜 중요한 질문: 이거 그냥 분류 모델 아닌가?
개념적으로 상당 부분 맞는 지적이다.
BERT 계열 classifier도 오래전부터
billing 0.91
technical 0.05
fraud 0.03
other 0.01같은 결과를 빠르게 반환할 수 있었다.
따라서 “AI가 확률로 분류한다” 자체가 새로운 발명은 아니다.
Jev가 새롭게 포지셔닝하는 부분은 이것을 특정 label set에 fine-tuning된 classifier 하나가 아니라, 자연어 state + runtime에 정의한 structured question을 받는 범용 Decision Model로 만든다는 점이다.
| 방법 | 장점 | 약점 |
|---|---|---|
| if / Rule Engine | 빠름 · 결정적 · 감사 쉬움 | 애매한 자연어 판단에 약함 |
| 전용 Classifier | 매우 빠름 · 저렴함 | Task별 학습·운영 필요 |
| LLM Structured Output | 범용성 · 복잡한 Reasoning | 비용 · Latency |
| Jev | 범용 자연어 판단 + Typed Probability | 새 모델 · 제한된 공개 검증 · Vendor 의존 |
반대로 Jev를 쓰면 안 되는 곳도 명확하다
Jev는 문자열 생성을 버렸기 때문에 당연히 못하는 일이 많다.
❌ 이메일 작성
❌ 코드 생성
❌ 문서 요약
❌ 자연스러운 고객 답변
❌ 긴 Multi-step Reasoning 결과 생성
그래서 Jev와 LLM은 경쟁 관계라기보다 역할 분담 관계에 가깝다.
애매한 판단은 Decision Model이 하고,
복잡한 생성과 Reasoning은 LLM이 한다.
금융권에서 보면 꽤 매력적이다. 동시에 꽤 위험하다
금융 AI에서 Jev 같은 Decision Model이 흥미로운 이유는 실제 업무가 생성보다 판단 → 분기 → 승인의 연속인 경우가 많기 때문이다.
고객 문의 Intent Routing
이상거래 Alert Triage
Agent 결과 Human Review Routing
문서 Classification
RAG Answer Quality Gate
Tool-call Risk Scoring
Model Routing
상담 QA Scoring
특히 모든 작은 판단에 비싼 Main LLM을 호출하는 Agent Architecture라면 별도의 Decision Layer는 비용과 latency를 낮출 가능성이 있다.
하지만 여기서 절대로 넘어가면 안 되는 선이 있다.
“이 사용자가 이 문서를 봐도 될 확률 99%”
라고 판단했다고 해서 문서를 보여줘서는 안 된다.
계좌 권한, 문서 ACL, 거래 권한, 고객정보 접근권한처럼 정확하게 검증할 수 있는 권한은 IAM · Policy · Database · Application Code가 결정해야 한다. ```
이 원칙은 RAG에서도 같다.
권한 없는 문서를 검색한 뒤 Jev에게 “이걸 사용자에게 보여줘도 될까?”라고 물어보는 구조는 잘못됐다.
권한 없는 데이터는 Retrieval 단계에서부터 들어오지 않아야 한다.
↓
IAM / Authorization
↓
Jev: Intent · Risk · Route
↓
LLM / RAG / Agent
↓
Jev: Verify · Score · Escalate?
↓
Policy Engine + Approval
↓
Tool Execution
그리고 데이터 경계도 봐야 한다
2026년 9월 현재 TypeSafe의 Privacy Policy는 서비스에 전달된 prompt와 Input으로 AI/ML 모델을 train 또는 fine-tune하지 않는다고 밝히고 있다. DPA에서는 고객 개인정보 처리 시 TypeSafe를 processor/service provider로 정의한다.
다만 금융권 Production 검토에서는 이것만으로 충분하지 않다.
Private Connectivity / VPC·Private Endpoint 지원 범위
Encryption / Key Management
Retention / Deletion
Subprocessor
Audit Log
SLA / DR
Model Version 고정 가능 여부
변경 통지 정책
Regulatory Requirement
같은 항목을 별도로 검증해야 한다. 특히 현재 Jev는 출시 초기 단계이므로, 기존 hyperscaler의 mature enterprise AI service와 동일한 통제 수준이라고 가정해서는 안 된다.
Production에서는 Accuracy보다 Threshold가 더 골치 아플 수 있다
Jev가 0.87이라는 확률을 줬다고 하자.
그러면 질문은 끝난 게 아니라 이제 시작이다.
0.90 이상만 자동화할까?
Fraud에서는 0.70도 Human Review로 보낼까?
고객 불편이 큰 업무는 threshold를 낮출까?
모델 버전이 바뀌면 calibration은 그대로일까?
따라서 Production에서는 단순 Accuracy 하나보다 이런 지표가 중요해진다.
| Metric | 왜 보는가 |
|---|---|
| Accuracy / F1 | 기본 판단 성능 |
| Calibration Error | 확률을 믿을 수 있는가 |
| False Negative | 위험한 것을 놓치는가 |
| Human Escalation Rate | 실제 자동화율 |
| P95 / P99 Latency | Agent 전체 latency 영향 |
| Decision Cost | 판단 1건의 실제 비용 |
그리고 모델을 업데이트했다면 threshold도 다시 검증해야 한다.
0.9라는 숫자의 의미는 모델 버전과 evaluation dataset 없이 존재하지 않는다.
Jev 도입할 때 예상되는 실패 패턴
1. 모든 판단을 Jev에게 맡긴다
금액 계산, 날짜 비교, 권한 확인처럼 코드로 정확히 할 수 있는 것까지 AI에게 맡길 이유가 없다. Deterministic problem은 deterministic code로 푸는 것이 먼저다.
2. Confidence를 진실 확률처럼 사용한다
confidence 0.95가 모든 도메인에서 실제 95% 정확도를 의미한다고 가정하면 안 된다. 자신의 데이터로 calibration을 측정해야 한다.
3. Main LLM을 전부 Jev로 바꾼다
Jev는 글을 쓰지 않는다. 복잡한 reasoning과 생성이 필요한 곳은 여전히 LLM의 영역이다.
4. Decision Model을 Policy Engine으로 착각한다
“위험해 보이는가?”는 AI 판단이 가능하다. “이 고객이 이 계좌를 조회할 권한이 있는가?”는 정책과 데이터로 검증해야 한다.
5. Vendor benchmark만 보고 도입한다
Jev는 매우 새롭다. 공개된 성능 자료 상당 부분이 현재 공급사 자체 평가다. 실제 업무 데이터로 기존 Rule, 전용 Classifier, 작은 LLM, Frontier LLM과 함께 비교하는 것이 맞다.
그래서 언제 Jev 같은 모델이 의미가 있을까?
✓ Agent 안에 작은 판단 단계가 매우 많다.
✓ LLM 호출 latency가 누적되고 있다.
✓ 결과가 자유로운 문장보다 Choice / Score에 가깝다.
✓ Task별 classifier를 수십 개 운영하고 싶지 않다.
✓ Human escalation을 confidence threshold로 제어하고 싶다.
✓ 대량 문서·이벤트에 동일한 판단을 반복해야 한다.
✓ 판단 규칙이 명확한 if문으로 끝난다.
✓ 하루 수십 번 호출해서 latency와 비용이 중요하지 않다.
✓ 복잡한 reasoning 자체가 핵심이다.
✓ 이미 잘 학습된 작은 classifier가 있다.
✓ 규제·데이터 요구조건 때문에 외부 API 사용이 어렵다.
사실 Jev보다 더 재미있는 건 ‘Decision Model’이라는 아이디어다
Jev라는 제품 하나가 앞으로 성공할지는 아직 모른다. 출시된 지 얼마 되지 않았고 독립적인 대규모 Production 검증도 더 필요하다.
그런데 이 제품이 던지는 질문은 꽤 오래 남을 가능성이 있다.
“문장을 생성하는 문제”일까?
지난 몇 년간 우리는 거의 모든 AI 문제를 LLM 호출 하나로 해결하려 했다.
Classification도 LLM.
Routing도 LLM.
Reranking도 LLM.
Evaluation도 LLM.
Tool Selection도 LLM.
Guardrail도 LLM.
LLM이 워낙 범용적이기 때문에 가능한 일이었다.
하지만 Agent가 수백만 번 실행되는 Production 환경에서는 범용성의 가격을 매번 지불하는 것이 맞는지 다시 묻게 된다.
Code가 잘하는 것
Decision Model이 잘하는 것
Generative LLM이 잘하는 것
을 다시 분리하기 시작할지도 모른다.
한 줄 평: LLM을 작게 만든 게 아니라, 문제를 작게 잘랐다
처음 Jev를 보면 “GPT보다 훨씬 빠른 새로운 AI”라는 부분이 눈에 들어온다.
하지만 개인적으로 더 재미있는 부분은 속도가 아니다.
AI가 해야 할 일을 다시 정의했다는 점이다.
GPT에게 “고객의 의도를 분석해서 JSON으로 설명해주세요” 라고 시키는 대신,
Jev에게는 그냥 묻는다.
그리고 확률을 받아 나머지는 코드가 처리한다.
이것이 Jev의 가장 중요한 아이디어다.
Jev는 판단하고
Code는 실행한다.
Agent 시대가 깊어질수록 Main Model이 얼마나 똑똑한가만큼 어떤 판단을 어떤 모델에게 맡길 것인가가 Architecture의 중요한 문제가 될 수 있다.
Jev가 그 정답인지는 아직 검증해야 한다. 하지만 “모든 문제에 LLM으로 문장을 생성할 필요는 없다”는 질문은 꽤 좋은 질문이다.
References
- TypeSafe AI — Introducing System One Models & Jev, Sep. 15, 2026
- TypeSafe AI — System One / Jev Official Product Documentation
- TypeSafe AI — System One API Documentation
- TypeSafe AI — Workflow Evaluations: Customer Service, Invoice Processing, Security Incidents
- TypeSafe AI — Privacy Policy / Data Processing Addendum
- Daniel Kahneman — Thinking, Fast and Slow