X 검색에서 JEV는 TypeSafe AI가 2026년 9월 공개한 Jev를 가리키는 결과가 압도적으로 많았다. 이 보고서는 출시 직후의 공식 설명, 사용 가이드, 공개 구현 사례와 초기 평가를 중심으로 다루며, 이름이 같은 다른 대상은 제외했다.
Jev의 핵심은 생성 속도가 아니라 생성 자체를 포기하고 판단 문제만 푼다는 데 있다. 입력 상태에 대해 Noul, Choice, Score 형태의 질문을 던지면 타입이 정해진 답과 확률을 한 번에 반환하므로, 파싱 실패와 자유 형식 출력의 변동성을 줄일 수 있다. 가장 적합한 사용처는 지원 티켓 라우팅, 에이전트 평가, 도구 위험 판정, 후보 선택처럼 선택 공간과 후속 코드 경로가 이미 정해진 작업이다. 반대로 문장 작성, 계산, 날짜 비교, 긴 연쇄 추론과 잡음이 많은 대형 컨텍스트에는 맞지 않는다. 공개된 성능 수치 대부분은 제작사 측 평가이며, LangChain의 초기 실험은 유망하지만 다섯 개 고정 사례와 한 명의 인간 평가자에 기반한 좁은 시험이다. 따라서 Jev를 범용 LLM 대체재로 보는 것보다, 기존 코드와 생성형 모델 사이에 삽입하는 고빈도 의사결정 엔진으로 보는 편이 정확하다.
배경
Jev는 자유로운 문장을 생성하는 대형언어모델을 더 빠르게 만든 제품이 아니다. TypeSafe AI는 이를 소프트웨어가 바로 사용할 수 있는 구조화된 결정을 내리는 System One 모델로 정의한다. 프로그램이 상태와 질문의 형태를 미리 정하면 Jev는 정해진 선택지, 점수 또는 참일 확률을 반환한다. 따라서 핵심 비교 대상은 챗봇의 답변 품질이 아니라 분류, 라우팅, 평가, 안전 판정처럼 코드 속에서 반복되는 판단 작업이다. 출시 직후 X에서는 게임, 브라우저 제어, SEO, 컨텍스트 압축 같은 화려한 데모가 빠르게 퍼졌지만, 실제 적용 가능성을 판단하려면 공식 문서가 밝힌 제약과 작은 규모의 독립 실험을 함께 봐야 한다.
선정 출처 구성
인기도가 아니라 정보 역할을 기준으로 최종 채택한 출처 구성입니다.
핵심 발견
1. Jev는 빠른 챗봇이 아니라 출력 공간이 닫힌 의사결정 모델이다
1차 출처 확인
Jev는 텍스트를 한 토큰씩 생성하지 않는다. 프로그램이 미리 정의한 질문과 선택지에 대해 Noul, Choice, Score 중 하나의 구조화된 답을 반환하며, Choice와 Score에는 확률 분포와 신뢰도도 붙는다. 이 구조 덕분에 결과를 JSON으로 유도하고 다시 파싱하는 단계를 없앨 수 있지만, 애초에 답의 형태를 코드가 정할 수 있는 문제여야 한다.
왜 중요한가 · 도입 여부는 기존 LLM 호출보다 얼마나 빠른가가 아니라, 해당 문제를 닫힌 선택지와 명시적 확률로 표현할 수 있는가를 먼저 따져야 한다.
공식 설계 지침은 정상적인 소프트웨어 흐름을 먼저 만들고, 상식적 판단이 필요한 좁은 지점에만 System One을 삽입하라고 권한다. 브라우저 데모와 Minecraft 사례도 Jev 하나가 전체 계획을 세운 것이 아니라, 별도 계획자나 코드가 만든 후보 중 다음 행동을 빠르게 선택하는 구조였다. Jev를 자율 에이전트처럼 사용하려 하면 모델의 강점보다 한계가 먼저 드러난다.
왜 중요한가 · Jev 도입은 모델 교체 프로젝트보다 워크플로를 결정 단계와 생성 단계로 분해하는 소프트웨어 설계 작업에 가깝다.
TypeSafe는 입력 100만 토큰당 0.042달러와 무료 출력, 약 70~500밀리초의 응답시간을 제시한다. 여러 질문을 같은 상태에 대해 병렬로 평가하므로 질문 수가 늘어도 추가 왕복 호출을 줄일 수 있다. OpenRouter의 Jev 1.13 페이지에서도 단일 제공자 기준 최근 중앙 지연시간이 약 0.26초로 표시되지만, 제공자가 하나뿐이라는 운영상 집중 위험도 함께 존재한다.
왜 중요한가 · 한 번의 복잡한 답변보다 수천·수백만 건의 라우팅, 검사, 평가를 반복하는 시스템에서 경제성이 커진다.
LangChain은 고정된 날씨 에이전트 실행 다섯 건을 여러 평가 모델로 반복 판정했고, 해당 실험에서 Jev가 낮은 비용과 지연시간, 매우 낮은 점수 분산을 보였다고 보고했다. 브라우저 에이전트 구현은 매 화면에서 동적으로 만든 행동 후보 중 Jev가 요소와 동작을 고르고, 텍스트 입력이 필요할 때만 작은 LLM을 호출했다. 두 사례 모두 자유로운 생성보다 제한된 후보 중 반복 판단하는 문제에서 강점이 나온다는 점을 보여준다.
왜 중요한가 · 기존 에이전트의 모든 모델 호출을 바꾸기보다 평가기, 라우터, 행동 선택기부터 시험하는 것이 실패 비용이 낮다.
Jev는 정의되지 않은 문자열이나 스키마 밖 값을 만들지 않지만, 허용된 선택지 중 잘못된 것을 고를 수는 있다. 공식 문서는 문자 그대로의 해석, 숫자와 날짜, 여러 단계의 간접 추론, 잡음이 많은 긴 상태, 적대적 입력에서 성능이 떨어질 수 있다고 명시한다. 따라서 확률 임계값, 인간 검토, 실제 데이터셋 회귀시험이 여전히 필요하다.
왜 중요한가 · 구조화된 출력은 안전장치 하나를 제거해 주지만, 모델 판단 자체를 검증해야 하는 책임까지 없애 주지는 않는다.
프로그램은 문자열이나 JSON 형태의 state를 보내고, 그 상태에 대해 여러 질문을 정의한다. Noul은 어떤 명제가 참일 확률을 0과 1 사이로 돌려주고, Choice는 주어진 후보 중 하나와 후보별 확률을 반환하며, Score는 순서가 있는 기준표 위의 점수와 분포를 제공한다. 질문들은 같은 상태를 공유하지만 서로 독립적으로 병렬 평가된다.
이 방식은 모델이 자유로운 문장을 만든 뒤 프로그램이 의미를 해석하는 흐름을 뒤집는다. 프로그램이 가능한 행동과 데이터 타입을 먼저 정하고 모델은 그 안에서 불확실성을 계산한다. 유연성은 줄지만 출력 검증, 재시도, 파싱과 관련된 실패 지점도 줄어든다.
Noul은 중간값이 아니라 참일 확률이다
Noul의 0.5는 정도가 중간이라는 뜻이 아니라 참과 거짓의 가능성이 비슷하다는 뜻이다. 단계가 있는 정도를 판단하려면 Score를 사용하고, 서로 배타적인 경로 중 하나를 고르려면 Choice를 사용하는 편이 맞다.
공개 데모의 공통 구조는 큰 모델이나 코드가 계획하고 Jev가 자주 반복되는 선택을 맡는 방식이다.
Browser Use의 공개 구현은 현재 DOM에서 가능한 요소와 동작을 표로 만들고 Jev가 그중 하나를 고르게 한다. 텍스트를 실제로 입력해야 할 때만 작은 생성형 모델을 호출한다. Minecraft 사례에서도 Astra가 상위 계획을 만들고 Jev는 이동과 클릭 같은 저수준 제어를 맡았다.
이 분리는 에이전트 루프의 모든 단계를 비싼 생성형 모델에 맡기는 대신, 의미가 제한된 순간 판단을 빠른 모델로 내리는 설계다. 다만 데모 성능은 작업 환경, 후보 구성, 네트워크 위치와 보조 모델에 크게 의존하므로 게시물의 속도 수치를 일반 성능으로 받아들이면 안 된다.
행동 공간을 코드가 잘 만드는 것이 모델만큼 중요하다
브라우저 구현은 매 단계에서 현재 화면의 가능한 동작을 동적으로 인덱싱한다. 후보가 부실하거나 너무 넓으면 Jev의 속도가 빨라도 올바른 행동을 고를 수 없으므로, 상태와 행동 공간 설계가 실제 품질을 결정한다.
LangChain 실험은 동일한 다섯 개 에이전트 실행을 고정하고 각 평가기를 반복 호출해 정확도, 점수 분산, 비용과 지연시간을 비교했다. Jev는 이 작은 데이터셋에서 이진 합격 판정을 인간 평가와 모두 일치시켰고, 연속 점수의 분산도 비교 모델보다 낮았다.
그러나 사례 수가 다섯 개에 불과하고 인간 평가자가 한 명이며, Jev 서비스 버전이 실험 메타데이터에 남지 않았다는 한계가 있다. 이 결과는 Jev가 모든 LLM judge보다 우월하다는 증거가 아니라, 좁은 평가 기준을 대량 반복하는 용도에서 추가 검증할 가치가 있다는 초기 신호다.
일관성과 정확도는 따로 측정해야 한다
같은 답을 반복하는 모델도 일관되게 틀릴 수 있다. LangChain은 인간 판정과의 일치율과 반복 호출의 분산을 분리해 측정했으며, 실제 도입에서도 이 두 축을 따로 관리해야 한다고 강조했다.
Jev는 내용을 새로 요약하기보다 어떤 항목을 보존할지 빠르게 점수화하는 방식에 어울린다.
fast-jev-compaction은 Claude Code 대화의 모든 도구 호출과 결과를 Jev가 평가하게 하고, 오래됐거나 관련성이 낮다고 판단된 항목만 제거하거나 줄인다. 사용자와 어시스턴트의 텍스트는 다시 쓰지 않기 때문에 요약 과정에서 경로, 오류문, 명령어가 변형되는 문제를 피하려는 설계다.
SEO 페이지 분류처럼 수백 개 문서를 같은 기준으로 판정하는 사례도 비슷한 구조다. 다만 X에 게시된 시간과 비용은 작성자의 단일 실행 결과이며 독립 재현이 없고 제품 홍보 목적도 섞여 있다. 대량 분류 자체는 적합하지만, 실제 정확도와 거절 기준은 자체 데이터로 다시 측정해야 한다.
삭제형 압축은 생성형 요약과 다른 실패를 만든다
원문을 다시 쓰지 않는 대신 필요한 항목을 잘못 버릴 위험이 생긴다. 최근 메시지 고정, 임계값 조정, 회귀 데이터셋과 복구 가능한 원본 보존이 함께 필요하다.
공식 문서는 Jev 1.13이 질문을 문자 그대로 읽는 경향이 있고 숫자 계산, 개수 세기, 날짜 비교와 여러 단계의 간접 추론에 약하다고 설명한다. 상태에 관련 없는 정보가 많으면 정확도가 떨어지며, 입력 안의 적대적 문구가 판단을 흔들 수 있다는 점도 명시한다.
또한 영어가 주 학습 언어이고 입력은 텍스트만 지원한다. Choice의 후보 수와 전체 컨텍스트에도 한계가 있다. 운영 측면에서는 OpenRouter에서도 실제 추론 제공자가 TypeSafe 한 곳뿐이므로, 장애 시 다른 독립 제공자로 자동 전환되는 일반적인 다중 제공자 모델과 다르다.
확률은 임계값과 검토 경로가 있어야 의미가 있다
낮은 신뢰도나 경계 구간의 결과를 사람에게 보내고, 확실한 구간만 자동화해야 한다. 임계값은 임의로 정하지 말고 실제 업무 데이터의 비용 구조와 오류 유형을 반영해 조정해야 한다.
정확한 조건, 제외 조건과 예시를 추가하고 실제 오답을 회귀시험에 넣는다. 출처 [W04][W05]
서비스 장애 때 대체 경로가 없다
현재 Jev 추론 제공자가 사실상 TypeSafe 한 곳에 집중돼 있다.
기존 규칙, LLM 분류기 또는 인간 검토로 전환하는 폴백 경로를 유지한다. 출처 [W10]
입력 문구가 판정을 의도적으로 흔든다
state 안의 적대적 콘텐츠를 일반 데이터와 동일하게 처리했다.
판단 기준을 명시하고 공격 예제를 포함해 테스트하며 고위험 실행은 별도 권한 확인을 거친다. 출처 [W05][W11]
불확실성과 검증 과제
제작사가 주장하는 200배 속도와 400배 비용 차이가 일반 업무에도 재현되는가?
현재 확인된 것
TypeSafe는 자체 워크플로 평가의 전체 쿼리와 비교 방식을 공개하고, 해당 수치가 실제 이득의 높은 쪽일 가능성이 있다고 스스로 밝혔다. OpenRouter의 최근 지연시간 표시는 약 0.26초이며 LangChain의 좁은 실험에서도 낮은 지연시간과 비용이 관찰됐다.
아직 모르는 것
서로 다른 지역, 입력 길이, 질문 수, 업무 난이도와 장기간 운영에서 같은 배율이 유지되는지는 아직 독립된 대규모 평가가 없다.
절대적인 배율을 도입 근거로 쓰기보다 자신의 데이터에서 기존 분류기와 같은 조건으로 측정해야 한다. 빠르고 저렴하다는 방향성은 지지되지만 정확한 배율은 사용 사례별 값으로 봐야 한다.
가격, 최근 지연시간, 제공자 수와 Decisions API 특성을 확인할 수 있다. [W10]
시사점
Jev의 등장은 생성형 모델을 더 작고 빠르게 만드는 경쟁과 별도로, 소프트웨어의 반복 판단만을 위한 모델 계층이 성립할 수 있는지 시험한다. 이 접근이 자리 잡으면 하나의 거대 모델이 모든 단계를 처리하는 에이전트보다 코드, 생성 모델, 의사결정 모델이 역할을 나눠 갖는 구조가 늘어날 가능성이 있다.
Aside나 코딩 에이전트 같은 도구에서는 전체 추론 모델을 교체하기보다 작업 분류, 도구 위험 판정, 실행 결과 평가, 컨텍스트 보존 여부처럼 호출 빈도가 높고 출력 공간이 닫힌 지점이 우선 후보가 된다. 특히 저렴한 평가기가 충분히 정확하다면 더 많은 실제 실행을 상시 검사할 수 있지만, 잘못된 판정도 같은 속도로 확대될 수 있으므로 인간 표본 검토가 필요하다.
개발 난이도는 프롬프트 작성에서 워크플로와 기준표 설계로 이동한다. 어떤 상태를 보여줄지, 판단을 몇 개의 원자 질문으로 나눌지, 어떤 확률 구간에서 자동 실행할지가 모델 선택보다 더 중요한 구현 문제가 된다.
현재는 공급자가 한 곳이고 핵심 성능 근거가 제작사와 소수 파트너 실험에 집중돼 있다. 장기 운영에 넣을 때는 Jev 전용 인터페이스를 애플리케이션 전체에 퍼뜨리지 말고, 다른 분류기나 인간 검토로 교체 가능한 얇은 어댑터 뒤에 두는 것이 안전하다.
선정 이유: OpenRouter가 제공 방식, 세 가지 질문 형태, 가격과 적합한 사용 사례를 구체적으로 설명한다.
Jev by @typesafeai is now on OpenRouter, in beta.
Jev is a System One model. Instead of generating text, it takes your app's state plus a typed question and returns a typed decision with a probability attached. There is no JSON prompting, parsing layer, and nothing to validate https://t.co/O860XC55q4
Jev is built for the decisions that software makes millions of times a day. Its pricing is also tuned for that:
- $0.042 per million input tokens, output tokens free - Answers in 70 to 500 ms end to end - On TypeSafe's published workflows, up to 190x faster and 440x cheaper than
The kind of jobs it is built for:
- Route a support ticket to the right team - Decide if a message breaks your content rules - Flag which signups look like fraud - Choose the next step for an agent - Decide if a workflow should pause for a human
And more
You ask in one of three shapes:
1. Noul: yes or no, returned as a probability. "Is this customer about to churn?" 2. Choice: one option from a set you define. "Which of these five queues does this go to?" 3. Score: a number on a scale you define. "How urgent is this, 1 to 5?"
Jev tells you how sure it is. Ask which queue a ticket belongs in and you get "billing 84%, technical 16%", not just "billing".
And you can ask several questions about the same input in one call.
Build something with Jev on OpenRouter and tag @jjacky. We are giving $20 in credits to the top 10 most creative and interesting projects.
선정 이유: Jev와 LLM의 차이가 생성 속도가 아니라 텍스트 생성 여부라는 점을 명료하게 짚는다.
LLMs vs. Jev, clearly explained!
TL;DR
The key difference is not that Jev generates faster.
Jev does not generate text at all.
A traditional LLM receives context and produces an answer one token at a time. Even when the output is a small JSON object, every token depends on https://t.co/kXhL5xRFdo
선정 이유: 정확도, 반복성, 지연시간과 비용을 같은 고정 실행으로 비교한 초기 외부 평가를 연결한다.
We tested Jev against LLM judges on accuracy, repeatability, latency, and cost to see whether System One models could offer a new approach to agent evaluation. https://t.co/hrqdNpm0g8
선정 이유: 대량 페이지 분류의 시간과 비용을 제시한 현장 보고지만 제품 홍보와 독립 검증 부재를 함께 감안했다.
Jev is WILD for SEO audit 🤯
in 45.1 seconds it read all 586 pages on my site and rebuilt the internal link map. 584 links placed, 139 pages it refused to link because nothing honestly fit. total cost $0.21.
Claude Opus 5, same 586 pages, same clock, got through 21 of them and https://t.co/z3O3UBnDKL
coming soon to power your SEO audits at Distribb, try it free today https://t.co/FlSwLS7yEL
선정 이유: 상위 계획 모델과 Jev의 저수준 행동 제어를 분리한 하네스 구조를 후속 글에서 설명한다.
Jev + Astra beats the Ender Dragon in Minecraft in 8 minutes 43 seconds! ⏱️
Cost less than $1 ($0.01 Jev, $0.96 Astra)
I open sourced the code and explain the harness setup below. This type of movement is only possible with Jev's near instant decisionmaking, and some https://t.co/daKubJ8zpU
Harness: I made Jev control the player, has access to WASD, space, click, and mouse movements. Astra is the planner that sends instructions to Jev async.
Learning: Each time the agent would fail, Astra would add skills as mjs files, that it can draw upon in different scenarios,
TypeSafeClassifier의 호출 방식, 세 질문 타입, 에이전트 라우팅과 도구 위험 판정 미들웨어 예제를 제공한다.
조사 한계 · X 검색은 Top과 Latest, 설명·튜토리얼·공식 계정·한계 검색을 조합했지만 검색 API가 각 요청에서 반환한 수량에는 제한이 있다. 영상 중심 게시물은 영상 전체를 전사하지 않고 게시물 본문과 연결된 문서·코드만 분석했다. 출시 후 일주일밖에 지나지 않아 장기 안정성, 독립 벤치마크와 실제 생산 장애 데이터는 거의 없다. 가격과 모델 사양은 2026년 9월 22일 확인 시점 기준이며 이후 변경될 수 있다.