Jev는 글을 쓰는 대신 정해진 선택지와 확률로 판단하는 TypeSafe AI의 System One 모델입니다. 일반 LLM과의 차이, 실제 활용 사례, 결합 방법과 한계를 살펴봅니다.
리서치 기준일: 2026년 9월 18일
목차
2. Jev/System One은 무엇을 다르게 최적화했나
4. Jev가 특히 잘 맞는 업무와 LLM과의 하이브리드 구조
핵심 요약
TypeSafe AI는 2026년 9월 15일 Jev를 공개하면서 이를 첫 “System One Model”이라고 정의했다. 핵심 아이디어는 간단하다. 모델에게 문장을 잘 쓰게 한 뒤 JSON으로 포장시키는 대신, 처음부터 소프트웨어가 소비할 수 있는 제한된 판단 공간에서 답하도록 모델과 추론 스택을 최적화하자는 것이다. TypeSafe의 표현으로는 “unstructured state in, typed probabilistic decisions out”, 즉 비정형 상태를 넣으면 타입이 정해진 확률적 판단이 나온다. 공개 API는 Choice, Score, Noul이라는 세 가지 판단 primitive를 중심으로 구성된다.
여기서 먼저 바로잡을 점이 있다. Jev는 “임의의 JSON Schema를 주면 아무 구조의 JSON 객체든 생성하는 범용 structured-output LLM”과는 다르다. 현재 공개 인터페이스에서 개발자는 “어떤 값 중 하나를 고를 것인가”, “어떤 순서형 척도에서 어디에 놓을 것인가”, “어떤 명제가 참일 확률은 얼마인가”를 미리 정의한다. Choice와 Score에는 전체 분포와 confidence가 붙고, Noul은 참일 확률 자체를 반환하며 별도 confidence 필드는 없다.
이 설계가 매력적인 곳은 대화가 아니라 제어 흐름이다. 티켓 분류, 에이전트 툴 실행 전 위험 판정, 모델 라우팅, 결제·환불 검토, RAG 문서 판별, 브라우저 액션 선택, 품질 루브릭 채점처럼 최종 산출물이 자연어가 아니라 if, switch, threshold, queue, API call의 입력이 되는 경우다. TypeSafe 자체도 intent routing, confidence-gated routing, speculative fan-out, composite scoring을 대표 패턴으로 문서화하고 있다.
다만 “Jev는 hallucination을 할 수 없다”는 문구를 문자 그대로 받아들이면 안 된다. TypeSafe가 보장하려는 것은 가능한 출력의 타입과 범위가 사전에 제한되므로 모델이 존재하지 않는 필드를 만들거나 예상치 못한 산문을 내놓는 종류의 구조적 탈선이 사라진다는 뜻에 가깝다. TypeSafe의 자체 한계 문서에는 Jev 1.13이 숫자·산술·날짜 비교·간접적 추론·불필요한 컨텍스트·적대적 입력·서로 독립된 질문 사이의 일관성에서 실패할 수 있다고 명시돼 있다. 즉 schema hallucination은 막아도 semantic error는 남는다.
또 하나의 중요한 관찰은 “구조화 출력” 자체는 Jev만의 장점이 아니라는 것이다. 예를 들어 OpenAI의 Structured Outputs 역시 지원되는 JSON Schema에 맞도록 constrained decoding을 적용해 구조 준수를 보장한다. 차이는 Jev가 그것을 텍스트 생성기의 부가기능으로 다루기보다, 판단 primitive와 확률 분포, 병렬 출력, calibration을 모델의 중심 계약으로 삼았다는 데 있다.
현재 Jev를 가장 설득력 있게 보는 방법은 “LLM 대체재”가 아니라 “LLM 앞뒤에 배치되는 초저지연 probabilistic control plane”이다. 실제 공개 프로젝트에서도 이 패턴이 반복된다. Browser Use의 jev-ultrafast는 Jev로 브라우저의 operation/target을 고르고 텍스트 입력이 필요한 순간에만 작은 생성형 LLM을 부른다. jev-codex-router는 Jev로 요청 난이도를 판단해 모델을 선택하고, pi-typesafe는 코딩 에이전트의 위험 툴 호출과 코드 diff를 Jev로 검사한다.
제 결론은 이렇다. 출력 공간을 사전에 열거할 수 있고, 판단이 고빈도이며, 수백 ms가 중요한 곳이라면 Jev는 상당히 흥미롭다. 반대로 답을 “만들어야” 하거나 긴 추론·계산·검색·설명·코드 생성이 핵심이면 범용 LLM이 맞다. 고위험 환경에서는 둘 중 하나를 고르기보다 Jev → confidence gate → LLM/사람 fallback 구조가 현시점에서 가장 합리적이다. 이 결론은 TypeSafe가 제시하는 intent/confidence routing 패턴과 최근 선택적 예측 연구가 공통적으로 지향하는 “불확실하면 abstain/escalate” 전략과도 맞닿아 있다.
Jev/System One은 무엇을 다르게 최적화했나
텍스트 생성 모델이 아니라 ‘똑똑한 if 문’에 가깝다
범용 LLM에 다음과 같은 업무를 시킨다고 생각해보자.
“이 고객 문의가 환불, 배송, 기술 문제 중 어디에 해당하는지 JSON으로 답해.”
일반적인 생성 모델은 내부적으로 여전히 다음 토큰을 계속 생성하면서 문자열을 만든다. structured-output 기능이 없다면 JSON이 깨질 가능성까지 처리해야 하고, structured-output 기능이 있다 하더라도 모델의 기본 임무 자체는 여전히 token generation이다. OpenAI의 Structured Outputs처럼 constrained decoding을 사용하는 구현에서는 JSON Schema에 맞지 않는 다음 토큰을 차단함으로써 구조 준수를 강제할 수 있지만, 스키마를 만족하는 잘못된 값까지 제거되는 것은 아니다.
TypeSafe는 이 문제를 반대로 정의한다. “최종 소비자가 소프트웨어라면 왜 먼저 문장을 생성하는가?”라는 질문이다. Jev API에서 개발자는 공통 state와 여러 개의 typed question을 보낸다. 각 질문은 같은 state를 독립적으로 평가하며 여러 질문을 한 요청에 넣을 수 있다. TypeSafe는 이들을 병렬 평가하도록 설계했다고 설명한다.
현재 primitive는 다음 세 종류다.
| Primitive | 질문 형태 | 반환값 | 적합한 예 |
|---|---|---|---|
Choice |
미리 정한 범주 중 하나 | 선택값 + 각 옵션 확률 + confidence | 의도 분류, 담당팀, 다음 액션 |
Score |
순서가 있는 수준 중 위치 | 점수 + 수준별 확률 + confidence | 위험도, 품질, 복잡도 |
Noul |
명제의 참/거짓 가능성 | 참일 확률 0–1 | “환불을 요구하는가?”, “위험 행동인가?” |
특히 probability와 confidence를 혼동하면 안 된다. Choice에서 예컨대 {refund: .55, shipping: .43, other: .02}라면 refund의 확률과 “이 분포가 얼마나 뾰족한가”를 요약한 confidence는 개념적으로 다른 값이다. TypeSafe 문서도 confidence를 Choice와 Score의 전체 확률 분포에서 계산되는 통계량으로 정의한다. Noul은 별도 confidence가 없다.
‘System One’은 업계 표준 용어가 아니라 TypeSafe의 제품·연구 프레이밍이다
TypeSafe가 말하는 System One은 Kahneman의 빠른 직관적 판단에 착안한 명칭으로, 긴 deliberative generation보다 빠르고 제한된 판단에 초점을 둔 자체 카테고리다. 따라서 현재 시점에 “System One Model”을 Transformer, diffusion model처럼 합의된 학술적 모델 계열로 취급하는 것은 이르다. 공개된 증거상 이것은 TypeSafe가 Jev의 설계 공간을 설명하기 위해 만든 분류에 가깝다.
TypeSafe는 Jev에 대해 세 가지 핵심 기술 요소를 공개했다. 새 모델 아키텍처, parallel sampler, 그리고 RLCD(Reinforcement Learning for Calibrated Decisions)다. 회사 설명에 따르면 기존 LLM이 token을 순차적으로 생성하는 데 반해 Jev는 한 query에서 구조화된 출력들을 병렬로 산출하도록 설계됐다.
그러나 중요한 증거 경계가 있다. 2026년 9월 18일 현재 공개 자료만으로는 Jev의 파라미터 수, 구체적인 backbone 구조, attention 구조, 학습 데이터 구성, RLCD objective의 수식, sampler의 상세 알고리즘을 독립적으로 재현할 수 없다. 제3자 분석에서도 모델 가중치와 충분히 상세한 technical paper가 아직 공개되지 않았다는 점이 지적된다. 따라서 “Jev가 encoder-only classifier다”, “한 번의 forward pass만 한다” 같은 구체적 내부 구현을 사실처럼 말하는 것은 현 단계에서는 추측이다.
공개된 현재 사양
2026년 9월 18일 기준 공식 문서의 안정 버전은 jev-1.13.0이며 jev-latest도 이 버전을 가리킨다. 공식 가격은 입력 백만 토큰당 $0.042, 출력은 별도 과금하지 않는다. 문서에는 요청당 64K 전체 예산과 state + 가장 긴 단일 질문에 대한 32K 한도가 적혀 있으며, 입력은 텍스트·JSON 객체·텍스트 배열이고 이미지·음성·영상은 직접 받지 않는다. 영어가 주 학습 언어이고 CJK를 포함한 다른 언어도 처리하지만 동일한 정확도를 보장하지 않는다고 명시한다.
TypeSafe는 출시 글에서 Jev의 end-to-end 지연을 대략 70–500ms, System-One-shaped query에서 동급 판단 성능 대비 40–200배 빠르다고 주장한다. 다만 이것은 현재로서는 공급자 자체 benchmark이며 독립적인 대규모 p95/p99 검증 결과로 받아들이면 안 된다. TypeSafe 자체 평가도 frontier LLM들의 결과 평균을 reference로 만드는 방식 등을 사용하기 때문에 “절대적 ground truth”라기보다 제품 비교 benchmark로 보는 편이 정확하다.
일반 LLM과의 기술적 차이
Jev를 “JSON을 잘 출력하는 작은 LLM”이라고만 보면 핵심을 놓치지만, 반대로 “LLM으로는 불가능한 완전히 새로운 능력”이라고 보는 것도 과장이다. 차이는 출력 계약, inference economics, uncertainty의 취급, 시스템 설계 방식이 한꺼번에 바뀐다는 데 있다.
비교표
아래 표의 “속도”와 “비용”에 대한 Jev의 수치는 TypeSafe가 공개한 현행 제품 사양 및 benchmark를 기준으로 한 것이며, 정확도는 workload에 따라 크게 달라지므로 절대 순위를 부여하지 않았다.
| 속성 | Jev / System One | 일반 생성형 LLM | Structured-output LLM |
|---|---|---|---|
| 핵심 최적화 | 제한된 판단·확률 | 텍스트 생성·추론·대화 | 텍스트 생성 + 구조 제약 |
| 출력 공간 | Choice / Score / Noul로 사전 정의 |
사실상 개방형 문자열 | 개발자 JSON Schema로 제한 가능 |
| 스키마 신뢰성 | primitive 계약상 매우 강함 | prompt-only라면 낮을 수 있음 | strict constrained decoding 지원 모델은 매우 강함 |
| 의미적 정확도 | workload·질문 설계에 강하게 의존 | workload·모델 지능에 의존 | 동일 |
| 생성 능력 | 없음 | 매우 강함 | 구조 내부 문자열 생성 가능 |
| 추론 방식 | 공개 정보상 parallel sampler 중심; 상세 아키텍처 미공개 | 일반적으로 autoregressive token generation | 보통 autoregressive generation + constrained decoding |
| 확률 출력 | primitive의 일급 출력 | 별도 prompting/logprob 처리 필요 | 보통 스키마 필드로 모델에 요구 |
| confidence | Choice/Score 분포에서 직접 제공 |
self-report는 별도 calibration 필요 | 역시 별도 calibration 필요 |
| 지연 시간 | 공식 주장 70–500ms 범위 | 일반적으로 더 길며 output 길이에 영향 | 생성해야 할 JSON 길이에 영향 |
| 출력 비용 | 공식 API상 별도 output 과금 없음 | output token 과금 흔함 | 동일 |
| 개발 난이도 | 문제를 atomic decision으로 재설계해야 함 | 초기 prototype은 쉬움 | schema 및 validation 설계 필요 |
| 최적 업무 | 분류·라우팅·스코어링·검증·guard | 작성·코딩·계획·설명·탐색 | 구조화 추출, 복합 객체 생성 |
| 대표 실패 모드 | 잘못된 선택, miscalibration, literalism | hallucination, format drift, semantic error | schema-valid semantic error |
| 안전의 핵심 | action space + confidence gate + 외부 코드 | policy/model + tool sandbox | schema + policy + tool sandbox |
OpenAI의 Structured Outputs가 보여주듯 지원되는 스키마에 맞는 출력을 강제하는 기능은 범용 LLM에서도 제공된다. 다만 안전상 거절이나 출력 중단 같은 예외는 별도로 처리해야 하고, 형식을 지킨다고 값의 사실성까지 보장되는 것은 아니다. 따라서 Jev의 실질적 가치 제안은 단순 JSON validity보다 “긴 JSON을 token-by-token 생성하지 않고, 정해진 후보에 대한 판단 분포 자체를 native output으로 취급한다”는 쪽에서 찾아야 한다.
Prompting도 다르다
일반 LLM에서 흔히 보게 되는 prompt는 이렇다.
You are a support classifier.
Return ONLY valid JSON.
Do not include markdown.
The schema is ...
Think carefully ...
Jev에서는 문제를 그보다 더 함수형으로 쪼갠다.
state = 현재 관찰 가능한 사실
question A = intent를 refund / status / technical / other 중 선택
question B = 메시지가 긴급한가?
question C = 해결 복잡도를 low / medium / high 척도로 평가
즉 prompt engineering보다 decision-interface engineering의 비중이 커진다. TypeSafe는 한 질문에 여러 개념을 섞지 말고 atomic judgment로 쪼갠 뒤, 최종 정책과 산술은 코드가 담당하도록 권장한다.
Hallucination 완화와 안전은 다른 문제다
Jev가 출력할 수 있는 범주가 ["allow", "review", "block"]뿐이라면 delete_everything() 같은 임의의 명령 문자열을 갑자기 생성할 수는 없다. 이 점은 capability containment 측면에서 상당히 유용하다. 하지만 allow가 틀린 판단일 가능성은 여전히 존재한다. TypeSafe의 공식 jaggedness 문서는 적대적 state가 판단을 흔들 수 있고, 숫자와 날짜 연산이나 서로 다른 질문 사이의 불변식도 자동 보장되지 않는다고 설명한다.
실제 pi-typesafe 프로젝트도 Jev를 코딩 에이전트의 pre-flight safety judge로 사용하면서 동시에 README에서 “coding aid이지 security boundary가 아니다”라고 명시한다. credential을 판별하는 질문을 넣어도 credential 자체가 state로 TypeSafe에 전송되는 것을 막아주지는 않고, prompt injection·불충분한 context·동시 변경 등이 judgment를 무효화할 수 있다고 경고한다.
Confidence가 있다고 곧바로 안전해지는 것도 아니다
Calibration의 이상적 의미는 “특정 사건의 확률을 0.8이라고 예측한 사례들을 많이 모았을 때 그 사건이 대략 80% 발생한다”는 식의 집단적 빈도 정합성이다. 이는 예측 확률에 대한 설명이며, 분포 모양을 요약한 Jev의 별도 confidence 필드에 그대로 적용하는 설명은 아니다. 개별 사례 하나의 0.8이 “이 답은 80% 확실히 맞다”는 보증서는 아니다. TypeSafe도 이를 동일하게 설명한다.
신경망 calibration 자체가 자동으로 주어지는 속성도 아니다. Guo 등은 현대 neural network가 높은 정확도와 별개로 poorly calibrated할 수 있으며 temperature scaling 같은 사후 보정이 유용할 수 있음을 보였다. 최근 reasoning LLM 연구 역시 confidence를 언제·어떤 target으로 학습시키느냐에 따라 ECE와 Brier score가 크게 달라짐을 보고한다.
따라서 Jev를 평가할 때는 단순 accuracy만 볼 것이 아니라 최소한 다음을 따로 봐야 한다.
분류 품질은 accuracy, per-class precision/recall, false-positive/false-negative로 보고, 확률 품질은 reliability diagram, ECE, Brier score 또는 log loss로 본다. 여기에 “confidence threshold를 높일수록 자동화 범위는 줄지만 오류율은 얼마나 떨어지는가”를 보는 risk–coverage curve를 추가하는 것이 좋다. 선택적 분류 연구는 바로 이 coverage와 error의 trade-off를 명시적으로 다룬다.
Jev가 특히 잘 맞는 업무와 LLM과의 하이브리드 구조
Jev를 먼저 고려할 만한 경우
정답 공간이 미리 정해져 있고 시스템이 결과를 곧바로 코드 분기에 사용한다면 좋은 후보가 된다. 예를 들어 “어떤 팀으로 보낼 것인가?”, “실행을 허용할 것인가?”, “이 diff의 task scope 준수도는 어느 수준인가?”, “어떤 tool을 다음에 호출해야 하는가?”와 같은 문제다. TypeSafe의 공식 예제도 customer-service routing, banking intent, resume composite scoring, support-ticket fan-out을 같은 방식으로 구성한다.
특히 다음 조건이 겹칠수록 Jev 쪽의 경제성이 커진다는 것이 현재 공개 자료에서 읽히는 방향이다. 호출량이 많고, 판단 단위가 작으며, 여러 독립적 판단을 같은 state에서 동시에 해야 하고, 생성할 문장이 필요 없으며, 1초 이하 latency가 실제 제품 행동을 바꾸는 경우다. 이는 TypeSafe가 병렬 질문과 낮은 단가를 전면에 내세우는 이유이기도 하다.
반대로 연구 보고서 작성, 코딩, 설명, 새로운 계획 수립, 정보 탐색, 긴 chain-of-thought가 필요한 복합 문제, 사용자가 읽을 응답 작성은 Jev의 목표 범위를 벗어난다. TypeSafe의 모델 한계 문서도 generation이 필요한 일을 일반 생성 모델에 위임하도록 권한다.
가장 유용한 패턴은 ‘Jev 또는 LLM’이 아니라 ‘Jev 그리고 LLM’이다
라우터 패턴
사용자 요청
│
▼
Jev
intent + complexity + confidence
│
├── 단순/확실 ──▶ deterministic code
├── 생성 필요 ──▶ specialist LLM
├── 복잡함 ─────▶ frontier LLM
└── 불확실 ─────▶ human review
이것은 TypeSafe가 공식 Intent routing 문서에서 제시하는 형태와 거의 같다. 고비용 LLM을 모든 요청에 호출하지 않고 필요한 요청에만 호출하는 구조다.
LLM 뒤 verifier 패턴
Input
↓
General LLM
↓
draft / code / proposed tool call
↓
Jev checks
├─ correctness dimensions
├─ safety dimensions
├─ task-scope
└─ confidence
↓
accept / retry / escalate
여기서 Jev가 LLM의 사실을 “증명”해 주는 것은 아니다. 특정 rubric에 대한 독립적인 judge를 하나 더 두는 것이다. pi-typesafe가 코딩 에이전트에서 destructive action, credential handling, repository 외부 쓰기, test weakening 등을 pre-flight로 묻고, 수정 후에는 style·implementation·error handling·task scope를 다시 평가하는 방식이 좋은 예다.
결정은 Jev, 언어 생성만 LLM 패턴
Browser Use의 jev-ultrafast는 이 구조를 꽤 명료하게 보여준다. 현재 DOM에서 가능한 operation과 target을 Jev가 고르고, TYPE_TEXT가 선택됐을 때만 작은 LLM이 실제 입력 문자열을 작성한다. 모델이 만든 문자열을 CSS selector, 좌표, JavaScript 명령으로 직접 실행하지 않고 관찰된 DOM 노드에 action을 제한하는 추가 guard도 둔다.
이를 일반화하면 다음과 같다.
decision = jev_decide(
state=current_state,
choices=["CLICK", "TYPE_TEXT", "WAIT", "DONE"],
)
if decision.choice == "TYPE_TEXT":
text = small_llm.generate(required_text_context)
execute_validated_text_action(text)
else:
execute_predefined_action(decision.choice)
이 코드는 해당 프로젝트의 소스를 복제한 것이 아니라 공개된 architecture pattern을 단순화한 예시다. Browser Use 프로젝트는 단일 Google Flights 실험에서 자연어 생성까지 포함해 약 7.1초 실행을 보고했으며, 소수 반복 실험에서 이전 구성 대비 median task time이 9.45초에서 7.09초로 줄었다고 보고한다. 프로젝트 스스로도 이것이 한 작업·한 환경·소수 반복의 결과이지 일반 reliability benchmark가 아니라고 선을 긋는다.
Jev로 모델 자체를 라우팅하는 패턴
jev-codex-router는 각 Codex turn을 Jev로 분류하고 필요 난이도에 따라 상대적으로 싼 모델과 비싼 모델을 고르는 실험이다. 저자가 공개한 7일·237개 실제 turn replay에서는 full-frontier baseline 대비 약 60% 비용 절감을 보고하지만, 낮은 confidence에서는 무리하게 cheap tier로 내리지 않고 중간 tier로 fallback한다. 프로젝트 역시 현재 상태를 early production experiment로 설명하며 calibration이 더 필요하다고 적고 있다.
이런 구조의 장단점은 비교적 명확하다.
| 하이브리드 패턴 | 장점 | 주요 단점 |
|---|---|---|
| Jev → LLM router | 비싼 모델 호출 감소, latency/cost 제어 | 잘못된 routing이 전체 품질 상한을 낮춤 |
| LLM → Jev verifier | 생성 능력 유지 + 정책 gate | judge도 틀릴 수 있고 추가 latency 발생 |
| Jev controller + small LLM generator | action space가 좁고 빠름 | harness 설계가 복잡 |
| Jev + deterministic rules | 감사·테스트·재현성이 좋음 | 규칙/질문 decomposition에 개발 노력이 큼 |
| Jev → human fallback | 고위험 오자동화 감소 | human queue 비용·지연 발생 |
Jev의 가장 큰 장점이면서 동시에 비용은 harness가 더 중요해진다는 점이다. 자유 생성 모델은 애매한 interface를 언어 능력으로 어느 정도 덮어줄 수 있지만, Jev는 가능한 판단 공간을 개발자가 미리 잘 설계해야 한다. 이는 TypeSafe 공식 문서의 atomic-question 철학과, DOOM 데모를 본 Reddit 사용자들이 “harness가 LLM workflow보다도 중요해 보인다”고 지적한 부분이 정확히 만나는 지점이다.
공개 생태계에서 실제로 어떻게 쓰이고 있나
Jev는 2026년 9월 15일 출시돼 이 글의 기준일인 9월 18일에는 공개된 지 사흘밖에 지나지 않았다. 따라서 지금 확인되는 “real-world usage”는 장기적인 엔터프라이즈 production case study보다는 GitHub prototype, 개인 benchmark, 소셜 실험, 초기 sidecar가 대부분이다. 이것은 현재 증거를 해석할 때 매우 중요한 제약이다.
GitHub: 브라우저 에이전트가 가장 흥미로운 하이브리드 사례
Browser Use의 jev-ultrafast는 Jev가 잘하는 것과 못하는 것을 깔끔하게 분리한다. 페이지에서 가능한 operation과 element target은 bounded choice로 만들고 Jev가 고르게 한다. 실제 도시 이름처럼 새로운 문자열을 작성해야 할 때만 작은 LLM을 호출한다. target 관련 여러 질문은 speculative fan-out으로 한 네트워크 왕복에 넣는다.
이 사례가 중요한 이유는 “Jev가 브라우저 에이전트를 통째로 대체했다”가 아니라 생성형 모델이 필요 없는 control decision에서 생성 모델을 제거했다는 점이다. 따라서 향후 agent architecture에서 planner/generator와 actuator/router/judge를 서로 다른 모델로 분업시키는 패턴의 한 예로 볼 수 있다. 이 해석은 공개 구현과 TypeSafe의 intent-routing 철학에서 도출한 추론이다.
GitHub: coding agent의 ‘사이드카 판사’
pi-typesafe는 bash, write, edit 전에 네 가지 위험 판정을 하고, 쓰기 이후 diff에 네 가지 품질 판정을 한다. 여러 질문을 각 phase의 한 System One 호출에 batch하고, 기본은 advisory이며 blocking과 shadow 모드도 지원한다. 실패하면 툴 실행을 그대로 두는 fail-open 정책을 사용한다.
저자가 2026년 9월 17일 실행한 작은 synthetic smoke test에서는 네 hazard Choice batch가 각각 204/174/94ms, 네 Score critic batch가 110/62/128ms로 기록됐고 jev-1.13.0을 사용했다. 다만 저자 스스로 이 수치가 latency percentile이나 calibration proof, coding-task 성능 향상의 증거는 아니라고 명시한다. 이런 자기 제한 문구가 오히려 이 repo를 초기 실사용 근거로 보기 좋게 만든다.
GitHub: LLM을 Jev API의 비교군으로 만드는 공식 adapter
TypeSafe가 직접 공개한 system-one-adapter-python은 흥미롭게도 반대 방향의 실험 도구다. 일반 OpenAI/Anthropic 모델을 System One과 같은 interface 뒤에 붙여 cost/speed/intelligence를 Jev와 비교할 수 있게 한다. 일반 LLM에서는 native structured-output 기능을 사용하거나 JSON prompting 후 client-side validation과 corrective retry를 할 수 있고, 확률 합이 어긋날 때 normalization하는 옵션도 둔다.
이 repo가 보여주는 핵심은 “LLM도 같은 API 계약을 흉내 낼 수 있다”는 사실이다. 즉 올바른 benchmark 질문은 “Jev만 가능한가?”가 아니라 “동일한 typed decision workload에서 누가 accuracy–latency–cost–calibration Pareto frontier를 더 잘 만드는가?”다. 이는 공식 adapter의 목적에서 자연스럽게 도출되는 평가 관점이다.
X: ‘똑똑한 if 문’이라는 해석이 빠르게 확산
X에서 공개 검색되는 초기 반응 중 Ran Aroussi는 Jev에 대해 “stop abusing LLMs as intelligent if statements”라고 반응했다. 말 그대로 번역하면 “LLM을 똑똑한 if문처럼 남용하는 일을 그만둘 수 있겠다”는 뜻이다. Jev가 받은 초기 관심을 가장 압축적으로 설명하는 문장 중 하나다.
창업자 Diogo Almeida의 9월 15일 X 공개 thread 역시 RLCD, 20–200배 속도, 40–400배 비용 효율이라는 출시 메시지를 전면에 내세웠다. 다만 이 수치는 TypeSafe 측 자체 benchmark claim이며 독립 검증치로 분리해 읽어야 한다.
Reddit: 기대와 동시에 ‘결국 classifier 아닌가?’라는 반론
r/singularity에서 초기 사용자는 Jev를 harmful prompt/generation monitor로 시험해 공개 benchmark 네 개에서 좋은 cost/performance를 봤다고 주장했고, 댓글에는 “범용 LLM을 대체한다기보다 상호보완적일 것”이라는 평가도 등장했다. 이는 개인 실험이므로 제품 성능 증거로 일반화해서는 안 되지만, guard/judge가 개발자들이 가장 먼저 떠올리는 use case라는 점은 보여준다.
반대로 r/LocalLLaMA에서는 “Jev와 비슷한 확률 예측·비자기회귀 아이디어를 이전에도 연구했다”는 비판이 제기됐고, Jev의 내부 설계가 공개되지 않은 상태에서 “완전히 새로운 architecture”라는 홍보를 얼마나 강하게 받아들여야 하는지에 대한 논쟁이 시작됐다. 해당 글은 저자의 과거 모델과 Jev의 실제 내부 구조가 동일하다는 증거를 제시하지 못하므로 우선권 주장 자체는 검증되지 않았다. 그러나 기술 논문·weights·training recipe 공개가 부족하다는 비판은 현재 Jev의 독립 검증 가능성이 낮다는 사실과 맞닿아 있다.
DOOM 데모에 대한 또 다른 Reddit 반응은 더 실무적이다. 한 사용자는 Jev에서 “harness가 훨씬 더 중요해 보인다”고 지적하며, 게임별 구조를 많이 만들어야 한다면 custom game AI와의 경계가 무엇인지 의문을 제기했다. 이 비판은 Jev의 핵심 trade-off를 잘 찌른다. 자유도를 모델에서 제거하면 그 자유도는 사라지는 것이 아니라 schema, state representation, deterministic code, executor 쪽으로 이동한다.
개인 체험 글과 한국어 서비스에 적용할 때의 주의점
Every의 초기 hands-on 글은 Jev를 customer support, invoice matching, fraud 같은 background workflow에서 “smart if-then statement”로 해석했고, 저자는 fuzzy한 글의 감정·스타일을 확률로 평가하는 실험을 진행했다. 동시에 “실제로 얼마나 잘 판단하는지는 아직 열린 질문”이라고 명시했다.
한국어 서비스에 적용할 때는 언어별 성능을 별도로 확인해야 한다. TypeSafe 공식 문서가 영어에서 가장 높은 정확도를 보인다고 직접 명시하기 때문에, 한국어 workload라면 영어 benchmark를 그대로 적용하지 말고 한국어 test set으로 threshold와 calibration을 다시 검증해야 한다.
한계, 위험, 아직 답이 없는 연구 질문
가장 큰 오해: 타입 안전성은 사실 정확성과 같지 않다
아래는 타입 안전성과 판단 정확도의 차이를 설명하기 위한 간단한 가상 스키마 예시다. 실제 Jev API 응답 전체를 그대로 옮긴 것은 아니다. 두 응답은 모두 스키마에 맞지만, 업무상 올바른 판단인지는 별개의 문제다.
{"decision": "allow", "confidence": 0.97}
{"decision": "block", "confidence": 0.97}
둘 중 업무상 올바른 것이 무엇인지는 schema가 말해주지 않는다. Jev의 output contract가 해결하는 것은 무엇을 말할 수 있는가이고, semantic evaluation이 해결해야 하는 것은 그 제한된 답 중 어느 것을 선택했는가다. TypeSafe의 공식 한계 문서가 literalism, numeric reasoning, date ordering, adversarial state 등을 따로 경고하는 이유도 여기에 있다.
따라서 TypeSafe의 “can’t hallucinate”라는 표현은 엄밀히는 “정의되지 않은 자유 텍스트를 만들어내는 유형의 hallucination surface를 제거한다” 정도로 해석하는 편이 안전하다. “Jev의 결정은 사실적으로 틀릴 수 없다”는 의미로 해석하면 공식 한계 문서와 모순된다.
확률의 보정과 confidence 기준은 도메인이 바뀌면 다시 검증해야 한다
모델이 전역적으로 잘 calibrated되어 있더라도 특정 고객군, 한국어, 매우 긴 state, 새로운 fraud 패턴, 특정 법률 문서처럼 distribution shift가 발생하면 calibration이 유지된다고 보장할 수 없다. 현대 모델의 calibration 및 selective prediction 연구에서도 distribution shift와 low-error operating point에서 uncertainty metric이 깨질 수 있다는 문제가 반복적으로 나타난다.
따라서 confidence > 0.9를 “90% 안전”이라는 규칙으로 바로 production에 넣는 것은 위험하다. TypeSafe 역시 threshold는 업무의 stakes에 맞게 자체 데이터에서 시험하고, 고위험 action일수록 더 높은 threshold 또는 확인 절차를 사용하라고 권한다.
독립 질문이 서로 논리적으로 일관된다는 보장은 없다
여러 질문을 병렬로 독립 평가한다는 것은 latency에는 강점이지만, 서로 관계된 명제 사이의 algebraic constraint가 자동 유지된다는 뜻은 아니다. 공식 jaggedness 문서는 사실상 동일한 현상을 다른 primitive로 물었을 때 확률이 논리적으로 정확히 맞물리지 않을 수 있다고 설명한다. 따라서 “A일 확률 + not-A일 확률 = 1”처럼 반드시 지켜야 할 invariant는 모델 여러 호출에 맡기지 말고 하나의 distribution에서 계산하거나 코드가 강제해야 한다.
숫자, 날짜, 계산은 코드로 빼는 편이 낫다
Jev 1.13은 공식적으로 정확한 산술, counting, 수치 크기 비교, 날짜 ordering이 강점이 아니라고 설명돼 있다. invoice workflow 같은 시스템이라면 “총액 두 개를 더한 뒤 같은지 물어보기”보다 코드가 금액을 계산해 difference = 0 같은 feature를 만들어 주고, Jev에는 fraud signal이나 semantic exception처럼 fuzzy한 판단만 맡기는 편이 더 안전하다.
이는 System One의 철학을 가장 실용적으로 요약한다.
정확한 계산은 코드에게, 애매한 판단은 모델에게.
Prompt injection은 없어지지 않는다
텍스트를 “state”라고 이름 붙였다고 그 텍스트가 안전해지는 것은 아니다. 외부 문서나 사용자 메시지 안에 instruction-like content가 들어 있으면 모델 판단에 영향을 줄 수 있다. TypeSafe의 한계 문서는 adversarial content가 답을 steer할 수 있다고 명시하고 있으며, community safety sidecar 역시 Jev를 security boundary로 취급하지 않는다.
대응책은 일반 LLM security와 비슷하다. 신뢰할 수 없는 data와 정책을 구조적으로 분리하고, allowed actions를 코드에서 제한하며, 금전 이동·삭제·credential 사용 같은 고위험 operation은 별도의 deterministic guard와 human confirmation을 둬야 한다. Jev는 이 방어망의 한 층이지 전체 방어망은 아니다. 이 권고는 TypeSafe의 confidence routing과 community 구현의 fail-open/fail-safe 설계를 종합한 것이다.
현재 가장 큰 연구 공백은 reproducibility다
Jev에 관해 공개된 API behavior와 제품 철학은 비교적 명확하지만, architecture와 RLCD training을 재현할 정보는 충분하지 않다. 따라서 아직 외부 연구자가 답하기 어려운 질문들이 많다.
특히 중요한 것은 RLCD가 구체적으로 어떤 proper scoring rule을 최적화하는지, calibration이 어떤 데이터·도메인·shift에서 유지되는지, parallel sampler가 candidate 수 증가에 따라 latency와 accuracy를 어떻게 trade-off하는지, confidence가 epistemic uncertainty와 aleatoric ambiguity를 얼마나 구분하는지, Jev와 잘-calibrated discriminative classifier 또는 작은 LLM head의 Pareto frontier가 실제로 얼마나 다른지다. 현재 공식 문서는 방향성은 설명하지만 이 질문들을 독립적으로 해결할 정도의 training detail이나 공개 benchmark suite를 제공하지 않는다.
그리고 이는 Jev의 장기적 가치 판단에 핵심적이다. 고정된 business task에 충분한 labeled data가 쌓여 있다면 전통적인 classifier가 더 싸고 빠를 수도 있다. Jev의 진짜 경쟁력은 task별 retraining 없이 자연어로 새로운 decision boundary를 선언하고 곧바로 쓸 수 있는 범용성과, 그 범용성을 어느 수준의 calibration과 accuracy로 제공하느냐에 달려 있다. 이 문장은 공개 API 특성과 전통적인 classifier와의 역할 차이에서 도출한 분석이다.
실무 도입 가이드: 언제 선택하고 어떻게 검증할 것인가
먼저 이 결정 흐름부터 보자
최종 결과가 자유형 글·코드·설명인가?
├─ 예 → 범용 LLM 우선
└─ 아니오 → 가능한 답을 미리 정의할 수 있는가?
├─ 아니오 → 범용 LLM 우선
└─ 예 → Jev 비교 평가 후보
긴 추론·검색·정확한 계산이 먼저 필요한가?
├─ 예 → LLM·검색 도구·일반 코드로 먼저 처리
│ └─ 정리된 결과의 분류·검증은 Jev로 평가 가능
└─ 아니오 → Jev에 좁고 명확한 판단 요청
판단 이후의 실행 정책
├─ 기준 미달·정보 부족 → 추가 정보·LLM·사람 검토
├─ 낮은 위험 + 검증된 기준 충족 → 허용된 동작만 실행
└─ 높은 위험 → 권한·규칙·승인 절차를 추가로 확인
이 flow는 TypeSafe가 공식적으로 제시하는 confidence-gated routing과 intent-routing 패턴을 실제 도입 의사결정으로 확장한 것이다.
Jev를 선택하기 좋은 신호
가장 강한 신호는 “지금 LLM을 사실상 classifier로 쓰고 있다”는 것이다. “반드시 {yes:false}만 출력해”, “이 네 라벨 중 하나만 골라”, “0~4점으로 채점해”, “JSON 외의 텍스트 금지” 같은 prompt가 코드베이스에 반복된다면 Jev benchmark를 해볼 가치가 크다. 일반 LLM에서도 Structured Outputs로 format 문제를 상당 부분 해결할 수 있으므로 비교 시에는 prompt-only JSON이 아니라 해당 LLM의 native strict structured-output mode를 baseline으로 잡는 편이 공정하다.
반대로 output이 이메일·SQL·코드·설명·계획서·검색 query·새로운 함수 인자 문자열을 실제로 생성해야 한다면 Jev만으로 끝내려 하지 않는 편이 좋다. 그 경우에는 Jev를 router, gate, scorer, verifier로 두고 생성 부분은 LLM에 맡기는 것이 현재 설계 철학과 공개 사례 모두에 더 잘 맞는다.
통합은 ‘schema’보다 decision ontology 설계가 먼저다
다음은 고객 문의 자동화용 통합 예시다. 공식 primitive 구조에 맞춘 예시이며 production 정책은 별도 검증이 필요하다. SDK 설치와 API 키 설정이 선행되어야 하고, route_to_human, run_refund_policy_checks, route_by_intent는 실제 서비스에 맞게 구현할 애플리케이션 함수다. 그대로 실행이 끝나는 완성 프로그램이 아니라 역할 분담을 보여주는 예시로 읽으면 된다.
from typesafe_sdk import TypeSafeClient, Choice, Score, Noul
client = TypeSafeClient()
state = {
"ticket": {
"subject": "Duplicate payment",
"message": "I was charged twice. Please refund the extra charge.",
},
"account": {
"tier": "business",
"charge_count": 2,
},
"features": {
# 정확한 계산·카운팅은 가급적 애플리케이션이 수행
"duplicate_charge_detected": True,
},
}
response = client.system_one(
model="jev-1.13.0", # threshold를 calibration했다면 버전 pin 권장
state=state,
questions={
"intent": Choice(
instructions=(
"Classify ticket.message by the user's requested outcome."
),
criteria={
"refund": "Requests money or a duplicated charge to be refunded.",
"status": "Only asks for the status of an existing transaction.",
"technical": "Reports a product or integration malfunction.",
"needs_review": "None of the other categories clearly applies.",
},
),
"risk": Score(
instructions=(
"Assess the operational risk of handling this ticket automatically."
),
criteria=[
"Low: no money or irreversible action",
"Medium: reversible account-side action",
"High: money movement or irreversible action",
],
),
"refund_requested": Noul(
instructions=(
"Does ticket.message explicitly or implicitly request a refund?"
),
),
},
)
intent = response.answers["intent"]
if intent.confidence < 0.75:
route_to_human(state)
elif intent.choice == "refund":
run_refund_policy_checks(state)
else:
route_by_intent(intent.choice)
특히 jev-latest 대신 versioned model을 쓰는 이유가 있다. 공식 문서에 따르면 alias는 새 release가 나오면 가리키는 모델이 바뀔 수 있다. 특정 버전에서 threshold를 calibration했다면 version ID를 pin하고 새 버전은 canary evaluation 후 승격시키는 것이 권장된다.
좋은 question 설계 템플릿
Jev에서는 다음과 같은 식으로 “prompt”보다 판단 규칙을 설계하는 편이 낫다. TypeSafe 역시 구체적인 state path, atomic question, 명확한 option definition을 권장한다.
[판단 대상]
`ticket.message`와 `account.status`만 평가한다.
[질문]
고객이 요구하는 다음 조치는 무엇인가?
[선택지]
refund:
이미 지불된 금액의 전부 또는 일부 반환을 요구한다.
cancel:
향후 주문/구독 취소를 요구하지만 기존 결제 반환은 요구하지 않는다.
status:
상태 확인만 요구하며 계정 변경을 요구하지 않는다.
needs_review:
위 정의 중 어느 하나로 명확히 분류하기 위한 정보가 부족하거나
여러 범주가 동시에 핵심 요구사항이다.
[경계 조건]
- 단순히 "refund policy"라는 단어를 언급한 것만으로 refund로 분류하지 않는다.
- 시스템에 없는 사실을 추론하지 않는다.
- 숫자 계산 결과는 `features`에 제공된 값을 사용한다.
Choice의 옵션이 실제 세계를 완전히 덮지 못한다면 other, unknown, needs_review 같은 escape hatch를 넣는 편이 좋다. 그렇지 않으면 모델은 반드시 틀린 후보 중 하나를 골라야 한다. TypeSafe 문서도 선택지가 exhaustive하지 않을 때 “other/none” 범주를 고려하도록 권장한다.
여러 질문이 필요하다면 한 호출에 fan-out하라
예를 들어 agent tool call 하나를 평가하기 위해 다음을 모두 물을 수 있다.
questions = {
"destructive": Noul(...),
"touches_credentials": Noul(...),
"outside_repo": Noul(...),
"weakens_tests": Noul(...),
"intent": Choice(...),
"complexity": Score(...),
}
서로의 답이 입력으로 필요한 질문이 아니라면 먼저 intent를 받고 두 번째 요청을 보내는 것보다 처음부터 함께 보내고 코드가 필요한 답만 쓰는 것이 TypeSafe가 권장하는 speculative fan-out이다. 질문들은 같은 state를 공유하면서 병렬 평가된다.
Confidence threshold는 한 개의 전역 상수로 만들지 않는 편이 좋다
0.8이라는 동일한 confidence라도 “추천 순서 바꾸기”와 “1억 원 송금 승인”은 위험도가 전혀 다르다. TypeSafe의 banking 예제도 낮은 stakes에는 낮은 threshold를, transfer 같은 고위험 action에는 더 높은 threshold 및 confirmation을 둔다.
보다 현실적인 정책은 다음과 같다.
THRESHOLDS = {
"suggest_tag": 0.60,
"route_internal_queue": 0.75,
"send_external_message": 0.90,
"financial_action": None, # model confidence만으로 자동 실행 금지
}
중요한 점은 위 숫자가 보편적인 권장값이 아니라 예시라는 것이다. 실제 threshold는 production-like validation data에서 false-positive cost와 false-negative cost를 반영해 정해야 한다. TypeSafe 역시 문서의 threshold 예시가 도메인별 보장이 아니라고 명시한다.
출시 전 테스트 체크리스트
실제 production gate에서는 단순히 “100개 넣었더니 93개 맞았다”보다 다음 구조가 유용하다. Calibration 연구와 selective classification 연구 역시 accuracy와 uncertainty 품질을 분리해 평가할 필요성을 보여준다.
| 영역 | 반드시 측정할 것 | 실패 시 의심할 부분 |
|---|---|---|
| 정확도 | overall accuracy, class별 precision/recall | option 정의, state 정보 부족 |
| 중대 오류 | high-cost FP/FN 별도 집계 | threshold가 business risk와 불일치 |
| Calibration | reliability diagram, ECE, Brier/log loss | confidence를 그대로 믿기 어려움 |
| Selective performance | threshold별 coverage와 conditional error | 낮은 confidence가 실제 오류를 잘 포착하지 못함 |
| 언어 | 한국어/영어 별 성능 | 영어 중심 학습 영향 |
| Context 길이 | short/medium/long state slice | irrelevant state 또는 context jaggedness |
| Adversarial | prompt injection·모순·누락 데이터 | state 신뢰 경계 취약 |
| Latency | p50/p95/p99, timeout rate | 평균값만으로 capacity 설계 |
| 비용 | request당 실제 input token 및 fallback cost | fan-out/state가 과도하게 큼 |
| Version | model ID별 regression | jev-latest alias drift |
| 복원력 | 429/5xx/timeout 시 동작 | fail-open/fail-closed 정책 오류 |
| 감사성 | state hash, 질문 버전, model version, 결과/확률 기록 | 재현 불가능 |
공식 문서상 Jev의 rate limit은 현재 동적으로 조정될 수 있고 SDK가 기본적으로 retry/backoff를 처리한다. 따라서 성능 테스트에는 정상 latency뿐 아니라 429/overload 상황까지 포함하는 것이 좋다.
Production 모니터링에서 가장 중요한 그래프
첫째는 예측 확률 구간별 실제 결과다. 예를 들어 Choice에서 선택된 라벨의 예측 확률이 0.8–0.9인 사례를 모아 실제 정답률과 비교한다. Noul은 반환된 참일 확률과 실제 참의 빈도를 비교한다. 여기서 별도의 confidence 필드는 확률 분포를 요약한 통계량이므로, confidence = 0.9를 곧바로 “정답률 90%”로 해석하면 안 된다. Confidence는 구간별 오류율을 따로 측정해 운영 기준으로 검증하고, 확률 보정은 예측 확률 자체를 대상으로 평가한다.
둘째는 coverage–error curve다. confidence >= 0.9에서 자동화되는 비율이 30%인데 오류가 0.2%인지, threshold를 0.8로 내려 coverage 70%를 얻었을 때 오류가 3%로 뛰는지를 본다. 이렇게 해야 “자동화율을 높이는 것”과 “오류 비용을 낮추는 것”의 trade-off를 운영 지표로 만들 수 있다.
셋째는 fallback success rate다. Jev가 불확실한 사례를 더 비싼 LLM이나 사람에게 넘겼을 때 실제로 그 경로가 더 잘 해결하는지 확인해야 한다. 그렇지 않다면 confidence routing을 추가했지만 전체 system quality는 좋아지지 않는 역설이 생길 수 있다. TypeSafe의 intent-routing 패턴도 low-confidence case를 별도 handler에 보내는 것을 전제로 한다.
넷째는 model-version segmented metrics다. jev-latest가 이동한 날 accuracy, calibration, option distribution, abstention rate가 갑자기 변하지 않았는지 본다. TypeSafe가 version pinning을 명시적으로 권장하는 것도 threshold가 모델 버전과 결합될 수 있기 때문이다.
최종 평가
Jev가 던지는 가장 중요한 질문은 “이 모델이 GPT보다 똑똑한가?”가 아니다. 오히려 “소프트웨어 내부의 모든 AI 호출이 정말 자연어 생성 문제여야 하는가?”라는 질문이다. 고객 티켓 하나를 세 부서 중 하나로 보내기 위해 수백~수천 토큰의 자연어를 생성한 뒤 JSON parser로 다시 구조화하는 것이 본질적으로 이상한 경우가 분명히 있다. TypeSafe는 바로 그 영역을 모델 category 자체로 떼어내려 한다.
기술적으로도 Jev를 “schema를 지키는 AI” 하나로 설명하면 부족하다. 현재 공개된 차별점은 제한된 typed answer space, 확률 분포가 일급 출력이라는 점, 여러 atomic judgment의 병렬 처리, calibration을 목표로 한 RLCD라는 post-training 방향, 생성 output을 없애 latency와 비용을 줄이려는 설계가 결합돼 있다는 데 있다. 다만 내부 architecture와 RLCD recipe가 충분히 공개되지 않아 이 모든 차이가 정확히 어떤 기법에서 비롯되는지는 외부에서 아직 검증하기 어렵다.
그래서 2026년 9월 18일 시점의 Jev는 매우 흥미로운 시스템 아이디어와 초기 제품 증거는 있지만, 아직 “검증이 끝난 새로운 foundation-model paradigm”이라고 부르기에는 이르다. 출시 후 불과 사흘이어서 공개된 독립 사례가 작은 prototype과 개인 benchmark에 집중돼 있고, 장기간 production drift, 도메인별 calibration, 비영어 성능, 고위험 false-positive rate, 대규모 concurrency에서의 실제 p99 같은 자료는 아직 부족하다.
그럼에도 지금 당장 실용적인 가치가 없는 것은 아니다. 오히려 “LLM에게 JSON 한 줄만 받아서 if 문에 넣고 있는” 시스템이라면 가장 먼저 A/B test해볼 만한 제품이다. 공정한 실험은 Jev를 prompt-only LLM이 아니라 native structured-output LLM과 비교하고, accuracy뿐 아니라 calibration·risk coverage·p95 latency·비용·fallback rate까지 함께 재는 것이다. TypeSafe가 직접 일반 LLM용 System One adapter를 공개한 것도 이런 비교를 가능하게 한다.
그리고 현재 가장 설득력 있는 architecture는 순수 Jev 시스템보다 다음과 같은 분업형 AI stack이다.
┌────────────────────┐
│ Deterministic Code │
│ 계산 · 정책 · 권한 │
└─────────┬──────────┘
│
Input ──▶ Jev ── confidence ───┼──▶ 자동 실행
│ │
│ intent / risk ├──▶ Human review
│ │
└────────────────────┴──▶ General LLM
│
생성 · 추론 · 검색
│
▼
Jev verifier
│
▼
validated action
이 구조에서는 Jev가 “무엇을 할지와 얼마나 확신하는지”를 좁은 공간에서 판단하고, LLM은 “새로운 것을 만들어내야 하는 순간”에만 투입되며, 정확해야 하는 산술·권한·불변식은 코드가 맡는다. Browser Use와 coding-sidecar, model-router 같은 초기 GitHub 프로젝트들이 이미 이 방향을 각각 다른 방식으로 실험하고 있다.
Jev의 장기적 의미가 정말 크다면 아마 “chatbot을 대체해서”가 아닐 것이다. 오늘날 거대한 생성 모델에게 억지로 맡기고 있는 수많은 작은 판단을, 더 작고 빠르고 측정 가능한 probabilistic function call로 분리하는 데 성공해서일 가능성이 더 크다. 현시점의 공개 증거로는 바로 그 가설이 Jev에서 가장 주목할 만하면서도, 앞으로 가장 엄격하게 검증해야 할 부분이다.
출처 및 참고자료
이 글은 2026년 9월 18일을 기준으로 작성된 리서치를 바탕으로 한다. 공식 제품 설명, 공급자 자체 평가, 공개 코드, 개인 경험과 연구 배경 자료를 구분해 정리했다. 소셜 게시물은 로그인이나 접근 제한이 있을 수 있으며, 문서·저장소·가격·모델 alias는 이후 변경될 수 있다.
공식 발표와 API·모델 문서
TypeSafe AI — Introducing System One Models & Jev
2026년 9월 15일 공개. System One의 설계 철학, RLCD 소개, 공급자 자체 성능 비교와 공개 시점의 근거.
공식 출시 글
TypeSafe AI — Introduction / Machine Learning Primer
Jev의 역할, 생성형 모델과의 차이, 학습·추론 접근을 설명하는 공식 문서. 문서 내용은 이후 갱신될 수 있다.
소개 · 머신러닝 배경 설명
TypeSafe AI — Primitives / Choice
Choice·Score·Noul의 질문 형식과 반환값, 선택지 설계에 대한 근거.
Primitives · Choice
TypeSafe AI — Confidence
예측 확률과 별도 confidence 통계량의 차이, 분포와 자동화 기준을 설명하는 근거.
Confidence 문서
TypeSafe AI — Models / API Reference
모델 ID와 alias, 가격·한도·입력 형식·응답 구조의 근거. 요금과 제공 조건은 이용 시점에 재확인해야 한다.
모델 사양 · API 레퍼런스
TypeSafe AI — Jev 1.13 Model Jaggedness
숫자·날짜·문맥·적대적 입력·질문 간 일관성 등 모델의 한계에 대한 공식 설명.
Jev 1.13 한계 문서
TypeSafe AI — Quickstart / Patterns
Python SDK 통합과 질문 설계, 라우팅·병렬 질문·합성 평가 패턴의 근거.
Quickstart · Intent routing · Confidence routing · Speculative fan-out · Composite scoring
TypeSafe AI — Invoice Processing Evaluation
공급자가 공개한 워크플로 평가 예시. 독립적인 운영 성능 보증이 아니라 자체 평가 자료다.
Invoice Processing 평가
공개 코드와 실제 구현 사례
Browser Use — jev-ultrafast
Jev가 브라우저 동작과 대상을 선택하고 작은 LLM이 입력 문구를 만드는 구현. 실행 시간은 작성자가 공개한 제한된 실험 결과다.
GitHub 저장소
0xNatoshi — jev-codex-router
Codex 요청 난이도에 따른 모델 라우팅 실험. 본문의 비용 절감 수치는 프로젝트 작성자의 소규모 replay 보고다.
프로젝트 README
twilwa — pi-typesafe
코딩 에이전트의 실행 전 위험 판정과 수정 후 평가를 수행하는 사이드카 구현. 동명의 다른 패키지와 구분해야 한다.
프로젝트 README
TypeSafe AI — system-one-adapter-python
범용 LLM을 System One 인터페이스로 비교하기 위한 공식 adapter. 구조화 출력·검증·재시도 및 비교 방법의 근거.
공식 adapter 저장소
X·Reddit·개인 사용 후기
Diogo Almeida — X 공개 발표
2026년 9월 15일 출시 맥락의 창업자 발표. 속도와 비용에 관한 표현은 공급자 측 주장으로 구분했다.
X 발표 원문
Ran Aroussi — X 초기 반응
Jev를 LLM에 맡기던 좁은 판단을 분리하는 접근으로 해석한 초기 반응. 독립적인 성능 측정 결과는 아니다.
X 게시물
Reddit r/singularity — Jev 초기 사용 논의
유해 프롬프트·생성물 모니터링 실험과 보완적 사용에 대한 개인 경험. 검증된 일반 성능으로 확대하지 않았다.
사용 경험과 댓글
Reddit r/LocalLLaMA — 아키텍처 신규성 논쟁
기존 분류·확률 예측 접근과의 유사성을 주장하는 토론. 동일 아키텍처나 우선권이 입증됐다는 근거로 사용하지 않았다.
논쟁 원문
Reddit r/accelerate — DOOM 데모 논의
상태 표현과 실행 코드 등 harness 설계의 중요성에 관한 커뮤니티 반응.
DOOM 데모 토론
Every — Mini-Vibe Check: TypeSafe’s Jev Judged Everything I’ve Written in 0.7 Seconds
글의 분위기·스타일을 평가해 본 초기 개인 체험. 측정 결과의 일반화에는 제한이 있다.
개인 체험 글
구조화 출력·확률 보정·선택적 예측의 배경 자료
OpenAI — Introducing Structured Outputs in the API
2024년 8월 6일. JSON Schema 제약, constrained decoding, 구조적 준수와 의미적 오류의 구분에 관한 비교 근거.
Structured Outputs 공식 설명
Guo 외 — On Calibration of Modern Neural Networks
2017년. 신경망의 확률 보정 문제와 temperature scaling에 관한 연구. Jev 자체를 평가한 논문은 아니다.
논문 초록
Geifman·El-Yaniv — Selective Classification for Deep Neural Networks
2017년. 불확실한 예측의 보류와 coverage·오류율의 관계에 관한 연구. Jev 자체의 성능 증거는 아니다.
논문 소개
Entropy Alone is Insufficient for Safe Selective Prediction in LLMs
2026년. 선택적 예측에서 불확실성 지표를 운영 안전성과 동일시하지 않도록 참고한 연구.
논문 초록
CALIBER: Calibrating Confidence Before and After Reasoning in Language Models
2026년. 추론 모델의 confidence 보정과 평가 시점에 관한 연구. Jev의 RLCD를 재현한 자료는 아니다.
논문 초록
'IT > AI' 카테고리의 다른 글
| ChatGPT로 무제한 토큰 코딩하기(WebCodex·DevSpace 등 비교) (4) | 2026.09.15 |
|---|---|
| 카카오 ChatGPT Plus 2개월 무료 이벤트 총정리｜대상·조건·신청방법 (2) | 2026.09.13 |
| 코덱스 팀 플랜, 회사 관리자는 내 활동을 어디까지 볼 수 있을까? Codex 관리자 감시 범위 총정리 (2) | 2026.09.12 |
| OpenAI가 90년 난제 나비에-스토크스를 풀었다? GPT-6 Astra보다 강한 차세대 AI가 이미 있다 (3) | 2026.09.10 |
| Claude Max 집단소송, ‘5배·20배 사용량’은 왜 문제가 됐을까? (3) | 2026.09.10 |
