Jev: 문장 대신 판단을 돌려주는 AI

“결제가 두 번 됐어요. 빨리 취소해주세요.”

이 문장을 받은 고객지원 시스템에 필요한 것은 그럴듯한 답장 초안보다 먼저 어느 팀에 보낼지, 환불을 요청했는지, 얼마나 긴급한지라는 판단입니다. 일반적인 LLM에게도 JSON을 요청할 수 있지만, 출력 형식을 맞추는 일과 그 판단을 잘하도록 만드는 일은 같은 문제가 아닙니다.

TypeSafe AI가 2026년 9월 공개한 Jev는 후자에 초점을 맞춘 System One 모델입니다. System One이라는 이름은 대니얼 카너먼이 『생각에 관한 생각(Thinking, Fast and Slow)』에서 구분한 빠르고 직관적인 System 1 사고에서 따왔습니다. 긴 문장을 생성하는 대신, 입력 state를 읽고 미리 정의한 질문에 대한 타입이 있는 판단과 확률 분포를 반환합니다. 아직 early access 단계라 우리 계정으로 Jev를 실행하지는 못했습니다. 이 글의 코드는 공식 문서에 기반한 설계 예시이고, 뒤에서는 같은 인터페이스를 재현한 오픈 구현을 노트북에서 돌려 확인한 결과를 따로 표시했습니다. TypeSafe AI 공식 발표

문장을 생성하는 일과 판단하는 일을 나눈다

업무 자동화에서 LLM이 하는 일은 크게 두 가지입니다. 하나는 이메일·보고서·코드처럼 새로운 내용을 만드는 일이고, 다른 하나는 이미 있는 내용을 읽고 분류·평가·검사하는 일입니다. 전자는 어떤 문장을 만들었는지가 중요하지만, 후자는 그 결과를 시스템이 바로 쓸 수 있는지가 더 중요합니다.

가장 짧게 줄이면 이렇습니다. LLM은 답을 만드는 AI이고, Jev는 답을 만들지 않고 판단만 하는 AI입니다. 둘의 차이는 문장 대신 JSON을 준다는 데 있지 않습니다. 무엇을 돌려주고, 누가 그 결과를 읽고, 틀릴 때 어떻게 틀리는지가 다릅니다.

Jev의 입출력을 단순화하면 다음과 같습니다.

입력  state: 판단할 문장이나 구조화된 데이터
질문 questions: 우리가 알고 싶은 원자적 판단들
출력 answers: 질문별 결과, 확률 분포, 확신도

핵심은 “무슨 생각을 했는지 설명해 달라”가 아니라, 우리 시스템에 필요한 판단의 경계를 먼저 정의하는 것입니다. 모델은 판단과 불확실성을 반환하고, 자동 처리할지 사람에게 넘길지는 코드가 결정합니다.

한 번의 입력에 세 가지 판단을 묻는다

위의 고객 메시지를 다음과 같이 판단한다고 해봅시다. 아래 TypeScript는 공식 JavaScript SDK의 사용 형식을 고객지원 사례로 바꾸어 쓴 설명용 코드입니다.

import { choice, noul, score, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const result = await client.systemOne({
  state: { ticket: "결제가 두 번 됐어요. 빨리 취소해주세요." },
  questions: {
    department: choice("어느 팀이 처리해야 하나요?", {
      billing: "결제, 청구, 환불 문제",
      technical: "버그, 장애, 연동 문제",
      other: "위 두 범주에 들지 않는 문제",
    }),
    asksForRefund: noul("고객이 환불이나 결제 취소를 요청했나요?"),
    urgency: score("요청이 얼마나 긴급한가요?", [
      "일반 문의, 즉시 처리 필요 없음",
      "지연 시 고객에게 실질적 불편이 생김",
      "금전 손실이나 업무 중단으로 즉시 확인 필요",
    ]),
  },
});

state는 한 번 전달하고, 서로 다른 질문을 같은 요청에 묶습니다. TypeSafe 문서에 따르면 각 질문은 같은 state를 보지만 독립적으로 평가됩니다. “고객이 화가 나서 billing일 것”처럼 한 판단이 다른 판단을 지레 결정하지 않게 하는 구조입니다. TypeSafe 질문 타입 문서

이 구조는 바깥에서도 확인됐습니다. Archer Hume은 9월 17일 공개한 분석에서 API를 약 1만 번 호출해 Jev의 동작을 계측했습니다. 관찰에 따르면 Jev는 state를 한 번 처리한 뒤 질문마다 격리된 부분을 붙여 평가하고, 답은 토큰을 이어 만드는 대신 선택지 위의 확률로 한꺼번에 내놓습니다. 약 3만 토큰짜리 state는 중앙값 218ms, 짧은 state에 질문 1,500개를 붙인 요청은 중앙값 610ms에 돌아왔다고 합니다. 응답의 output_tokens는 실제 생성량이 아니라 응답을 직렬화한 뒤 세는 과금용 숫자라는 점도 짚었습니다. 개발사가 내부 구조를 공개하지 않았으므로 이 설명은 계측에서 추론한 것이고, 저자도 백본 구조나 MoE 여부 같은 부분은 추정이라고 밝힙니다. Jev's Architecture Unmasked

같은 분석에서 실무에 바로 닿는 관찰이 하나 더 나옵니다. 질문에 관련 없는 선택지를 하나 추가하자, 기존 두 선택지 사이의 확률비(로그 오즈)가 열 번의 반복 모두에서 줄었습니다(평균 +0.38 → +0.11). 선택지는 하나씩 따로 점수가 매겨지는 것이 아니라 목록 전체가 한 번에 읽힙니다. other를 두라는 조언이 공짜가 아닌 이유입니다. 선택지를 더하고 빼는 일은 기존 후보의 확률까지 바꾸므로, 선택지 목록도 프롬프트처럼 버전을 관리하고 바뀔 때마다 다시 평가해야 합니다.

Choice·Score·Noul은 같은 숫자가 아니다

Choice: 정해진 후보 중 하나를 고른다

Choice는 부서, 카테고리, 처리 유형처럼 서로 배타적인 후보 중 하나를 고를 때 씁니다. 선택된 값뿐 아니라 모든 옵션의 확률과 분포 모양에서 계산한 confidence를 받습니다. billing 0.55, technical 0.43라면 1위는 billing이어도 두 후보가 경쟁하고 있음을 알 수 있습니다.

옵션이 현실을 다 덮지 못한다면 other나 none을 두어야 합니다. 그렇지 않으면 모델은 잘못된 후보 중에서도 하나를 고를 수밖에 없습니다. 타입이 올바른 JSON이라도 의미가 틀릴 수 있는 이유입니다.

Score: 순서가 있는 기준을 스펙트럼으로 읽는다

Score는 엄중도, 관련성, 고객 불만처럼 낮음에서 높음으로 연결된 판단에 씁니다. 기준을 “낮음·중간·높음”이라고만 쓰기보다, 각 단계에서 실제로 관찰할 수 있는 상황을 적어야 합니다.

결과는 정수로만 나오지 않습니다. 예를 들어 0·1·2 세 단계에서 레벨 1에 70%, 레벨 2에 30%가 배정되면 score는 1.3이 될 수 있습니다. 같은 1.0이어도 레벨 1에 모든 확률이 모인 경우와, 레벨 0·2에 반씩 나뉜 경우는 다릅니다. 그래서 score만 저장하면 불확실성을 잃어버립니다. Score 공식 문서

다행히 Score의 confidence는 이 둘을 구분합니다. 뒤에서 볼 정의로 계산하면 레벨 1에 전부 모인 경우는 1.0, 레벨 0과 2에 반씩 나뉜 경우는 0입니다.

Noul: “예”의 확률을 묻는다

Noul은 환불을 요청했는지, 개인정보가 있는지, 특정 정책을 위반했는지처럼 yes/no 경계에 씁니다. 결과는 noul 0~1 값으로 반환됩니다. 1에 가까울수록 yes, 0에 가까울수록 no입니다.

Noul에는 Choice·Score와 별도의 confidence가 없습니다. yes 0.51은 중간 단계를 뜻하는 것이 아니라, yes와 no의 경계에 가깝다는 뜻입니다. 위험한 작업이라면 그 값을 바로 실행 신호로 쓰지 말고, 코드에서 보수적인 기준과 확인 절차를 두어야 합니다. Noul 공식 문서

판단 다음은 평범한 if문이 맡는다

Jev가 billing을 골랐다고 해서 환불을 실행하게 두면 안 됩니다. 모델은 문장을 읽고 판단하고, 시스템은 위험과 정책을 계산해 행동을 고릅니다.

const department = result.answers.department;
const refund = result.answers.asksForRefund.noul;
const urgency = result.answers.urgency;

if (department.confidence < 0.7) {
  return requestHumanReview();
}

if (department.choice === "billing" && refund > 0.8) {
  return createBillingReview({ priority: urgency.score });
}

return routeToQueue(department.choice);

여기서 0.7과 0.8은 Jev의 공통 정답이 아닙니다. 설명을 위한 임의의 값입니다. 실제 기준은 우리 데이터에서 각 행동의 잘못이 만드는 비용을 측정한 뒤 정해야 합니다. 동일한 확신도라도 화면 이동과 결제 승인에 같은 기준을 쓸 수는 없습니다.

확신도는 정답률이 아니다

Choice와 Score의 confidence는 각 후보의 확률이 얼마나 한곳에 모였는지를 하나의 숫자로 압축한 통계량입니다. 공식 문서는 정의를 말로만 설명하지만, TypeSafe가 다른 LLM과 비교하라고 공개한 System One Adapter 코드에 그 정의가 있습니다. 선택지가 K개인 Choice의 확신도는 다음과 같습니다.

confidence = (p_max − 1/K) / (1 − 1/K)

1위 확률이 균등 분포(1/K)에서 얼마나 위로 떨어져 있는지를 0~1로 늘린 값입니다. 정의가 단순한 만큼 두 가지를 같이 알아야 합니다. 첫째, 같은 1위 확률도 선택지 수에 따라 다른 확신도가 됩니다. 1위가 0.55일 때 선택지가 2개면 0.10, 3개면 0.33, 10개면 0.50입니다. 선택지 수가 다른 질문끼리 같은 임계값을 쓸 수 없는 이유입니다. 둘째, 1위 확률만 봅니다. 세 후보가 0.55·0.45·0인 경우와 0.55·0.225·0.225인 경우는 확신도가 0.33으로 같습니다. 2위가 바짝 붙었는지는 확신도로는 알 수 없고 probabilities를 봐야 합니다. Score의 확신도는 확률이 최빈 레벨에서 평균적으로 얼마나 떨어져 있는지를 재는 다른 정의를 씁니다. Jev 서비스가 내부에서 정확히 이 코드를 쓰는지는 개발사가 확인해 주지 않았습니다.

어느 쪽이든 모델이 자신의 분포를 명확하게 만들었다는 신호이지, 현실의 정답과 반드시 일치한다는 보증은 아닙니다.

TypeSafe는 발표에서 모든 답에 보정된(calibrated) 확률과 확신도가 함께 나온다고 설명합니다. 보정이 잘 되어 있다면 확신도가 높은 판단일수록 실제로도 더 자주 맞아야 합니다. 앞의 제3자 분석은 이 주장을 독립적으로 재봤습니다. MMLU 문항 1,200개에서 10구간 기대 보정 오차(ECE)는 0.0313이었고, 학습 데이터에 없었을 새로 만든 세 자리 곱셈에서는 정답률 86.7%에 평균 확신도 83.0%, 두 단계 서술형 문제에서는 정답률 32%에 평균 확신도 30.4%로 두 값이 붙어 다녔습니다. 못 푸는 문제에서는 확신도도 같이 낮아졌다는 뜻입니다. 저자는 이 구간이 표본 오차만 반영하며 벤치마크 선택이나 학습 노출은 배제하지 못한다고 단서를 답니다. 우리 데이터에서도 그런지는 직접 확인해야 합니다. TypeSafe AI 공식 발표, Archer Hume의 분석

운영에서 더 위험한 것은 낮은 확신도보다 높은 확신도의 오판입니다. 검증 데이터에서 다음을 따로 봐야 합니다.

• 정답을 맞힌 비율이 아니라, 확신도 구간별 정답률
• 자동 처리 비율과 사람에게 보낸 비율
• 오판으로 발생한 비용과 복구 가능성
• 없던 카테고리, 정보 부족, 모순된 문장에서의 거동

TypeSafe도 공식 문서에서 임계값은 도메인과 위험에 따라 달라져야 하며, 자체 데이터로 보수적으로 조정하라고 권고합니다. Confidence 공식 문서

오픈 구현을 노트북에서 직접 돌려봤다

Jev는 early access라 우리 계정이 없습니다. 대신 같은 인터페이스를 재현한 오픈 구현이 있습니다. SemIf(옛 이름 OpenJev)는 학습 없이 오픈 모델의 로짓을 읽고, NanoJev는 Qwen3-0.6B 위에 판단 헤드를 붙여 학습한 모델입니다. 둘 다 Jev의 모델이 아니라 인터페이스를 재현했다고 밝힙니다. 우리는 NanoJev를 골랐습니다. 학습된 판단 헤드가 있어서 “답을 만들지 않고 판단만 하는 모델”이 실제로 어떻게 행동하는지 볼 수 있기 때문입니다.

M3 Pro 맥북에서 저장소의 인코딩과 모델 코드를 그대로 쓰고 디바이스만 MPS(fp32)로 바꿔 돌렸습니다. 요청 형식은 Jev와 같습니다. state 하나에 Choice·Boolean·Score 질문을 붙입니다. 미리 알아둘 점이 있습니다. 이 체크포인트는 미로와 스네이크 게임 상태(영어)로 학습됐고, 고객 문의 같은 텍스트는 학습 데이터에 없습니다. 그래서 이것은 정확도를 재는 실험이 아니라, 학습 범위 밖의 입력에서 판단 모델이 어떻게 행동하는지 보는 실험입니다. NanoJev 모델 카드

{
  "states": [{
    "id": "ticket1",
    "state": "고객 문의: \"결제가 두 번 됐어요. 빨리 취소해주세요.\"",
    "questions": {
      "department": { "type": "choice", "instructions": "어느 팀이 처리해야 하나요?",
        "criteria": { "billing": "결제, 청구, 환불 문제", "technical": "버그, 장애, 연동 문제", "other": "위 두 범주에 들지 않는 문제" } },
      "asksForRefund": { "type": "boolean", "instructions": "고객이 환불이나 결제 취소를 요청했나요?" },
      "urgency": { "type": "score", "instructions": "요청이 얼마나 긴급한가요?",
        "criteria": ["일반 문의, 즉시 처리 필요 없음", "지연 시 고객에게 실질적 불편이 생김", "금전 손실이나 업무 중단으로 즉시 확인 필요"] }
    }
  }]
}

글에서 쓴 문의 세 건을 결제·기술·기타로 분류하게 했습니다. 확신도는 앞에서 본 어댑터 정의로 계산했습니다.

세 문의 모두 1위는 결제팀이지만 분포의 모양이 다릅니다. 첫 문의는 한곳에 몰렸고, 두 번째는 결제와 기타로 갈렸고, 세 번째는 셋에 퍼졌습니다. “지난번이랑 똑같아요”처럼 정보가 없는 문의에서 모델은 모른다는 것을 분포로 표현합니다. 1위 값만 저장했다면 세 문의가 모두 그냥 결제 문의가 됐을 것입니다. 첫 문의에 함께 물은 Boolean은 환불 요청 확률 0.62, Score는 긴급도 1.64(레벨 2에 0.65)를 돌려줬습니다.

선택지 설계가 결과를 바꾼다는 것도 그대로 나타났습니다. 범주 밖 문의로 “채용 공고 보고 연락드려요. 지원 절차가 어떻게 되나요?”를 넣어 봤습니다. 기타 옵션이 있을 때는 기타를 0.86으로 골랐습니다. 기타를 빼자 같은 문의를 버그·장애로 0.68에 보냈습니다. 학습된 판단 모델에서도 없는 답을 고르라고 하면 있는 것 중에서 고릅니다. 타입이 올바른 답과 의미가 맞는 답이 다르다는 말이 이렇게 드러납니다. 이때 유일한 신호는 분포였습니다. 확신도가 0.79에서 0.35로 떨어졌으니까요.

게임으로 학습한 0.6B 모델이 한국어 문의에서 이 정도 방향을 잡는 것은 백본의 사전학습 덕입니다. 같은 문의를 영어로 넣어도 결제 0.83으로 비슷했습니다. 그러나 보정은 되어 있지 않았습니다. “메시지에 파란 자전거가 나오나요?”처럼 답이 뻔히 아니오인 질문에 0.21, 환불 요청 여부처럼 뻔히 예인 질문에 0.62를 돌려줬습니다. 방향은 맞지만 그 숫자를 임계값에 걸 수는 없습니다. 학습 범위 밖에서 판단 모델을 쓰면 이렇게 됩니다. 우리 데이터로 검증하라는 말의 실체가 여기에 있습니다.

구조에서 오는 성질도 확인됐습니다. 확률은 우리가 준 후보 위에만 놓입니다. 판단 헤드가 후보들 사이에서만 softmax를 하므로 형식이 어긋난 답은 애초에 나올 수 없습니다. 속도는 질문 10개, 후보 경로 23개를 forward 한 번으로 처리해 노트북에서 중앙값 485ms였습니다(30회, p95 613ms). 질문 하나에 50ms꼴입니다. Jev가 발표한 수백 ms와 같은 급이지만 모델도 하드웨어도 다르므로 비교할 수 있는 수치는 아닙니다.

이 실험이 말해주는 것은 여기까지입니다. 판단을 확률로 받는 구조가 어떻게 동작하고, 학습 범위 밖에서 무엇이 무너지는지입니다. NanoJev는 Jev가 아니고, 0.6B이며, 게임으로 학습됐고, 한국어를 배운 적이 없습니다. 위 수치는 우리 노트북에서 한 번 돌린 결과일 뿐 Jev의 정확도나 한국어 품질을 대신 말해주지 않습니다.

속도는 Jev를 둘 수 있는 위치를 바꾼다

TypeSafe가 발표에서 가장 앞세우는 숫자는 속도입니다. 발표에 따르면 최신 LLM의 end-to-end 응답 시간은 3~329초인 반면 Jev는 70~500ms이며, System One 형태의 질문에서는 같은 수준의 판단을 40~200배 빠르게 처리한다고 설명합니다. 가격은 입력 토큰 100만 개당 0.042달러이고, 출력 토큰은 과금하지 않습니다. TypeSafe AI 공식 발표, Jev 모델 문서

이 숫자는 조건과 함께 읽어야 합니다. TypeSafe는 공개 평가를 대부분 서비스가 있는 미국 서부의 노트북에서 실행했다고 밝혔습니다. 한국에서 호출하면 태평양을 오가는 네트워크 시간이 더해지므로, 실제 지연 시간은 우리 위치와 입력 길이로 다시 측정해야 합니다. 가격에 대해서도 개발사는 보조금 없이 유지되는 가격인지는 장기적으로 증명해야 한다고 적었습니다.

속도가 중요한 이유는 Jev를 둘 수 있는 위치가 달라지기 때문입니다. 호출 하나에 수 초가 걸리면 사용자 요청을 처리하는 경로 안에서 매번 판단하기 어렵고, 검색된 문단마다 여러 질문을 던지는 설계는 문단 수만큼 호출이 늘어납니다. 발표대로 호출이 수백 ms 안에 끝나고 출력 토큰이 무료라면, 판단을 한 번에 몰아서 하는 대신 필요한 지점마다 작은 질문을 두는 설계가 현실적인 선택지가 됩니다.

제3자가 공개한 데모에서 이 차이를 볼 수 있습니다. Browser Use의 jev-ultrafast는 매 단계 페이지의 요소 목록을 Jev에 넘기고, 어떤 조작(클릭·입력·선택 등)을 어느 요소에 할지 고르게 하는 브라우저 에이전트입니다. 도시 이름처럼 실제로 글자를 써야 하는 순간에만 작은 LLM을 부릅니다. 뒤에서 볼 “함수 선택” 사례와 같은 구조입니다. 아래 영상은 Google Flights에서 취리히→런던 편도 항공편을 찾는 과정을 배속 없이 녹화한 것입니다. Jev 요청 17번, LLM 텍스트 생성 2번, 중간의 페이지 로딩 대기를 모두 포함해 7.073초에 끝났고, Jev 판단 한 번의 중앙값은 178ms였습니다. Browser Use가 자기 환경에서 측정한 한 번의 실행이며, 측정 조건은 저장소의 성능 문서에 공개되어 있습니다.

Jev가 들어갈 수 있는 네 가지 위치

공식 케이스를 시스템 설계의 관점으로 다시 읽으면, Jev는 대체로 자유로운 문장과 결정적 코드의 사이에 들어갑니다.

RAG 사례가 특히 중요합니다. 검색 유사도가 높은 문서라고 해서 답변에 쓰기 좋은 문서는 아닙니다. 사용자의 잘못된 전제를 반박하는 문서는 표현이 다르고, 검색된 커뮤니티 문장에는 답변 모델을 속이는 지시가 숨어 있을 수 있습니다. 공식 RAG 케이스는 문단마다 네 가지 Noul 질문을 던진 뒤, 어떤 문단을 유지·표시·제거할지 코드가 결정하는 구조를 보여줍니다. Classifying RAG passages

인용 검증에서도 모델에게 모든 것을 맡기지 않습니다. 원문에 인용문이 존재하는지는 문자열 검사로 먼저 확인하고, 존재하는 인용의 맥락이 주장을 받치는지만 모델에 묻습니다. 정확한 검사는 코드에, 의미 판단은 모델에 두는 좋은 분리입니다. Double-checking citations

지금 쓰는 방식을 바꾸면 무엇이 달라지나

Jev의 자리를 정했다면 다음 질문은 “지금 그 일을 하고 있는 것을 왜 바꾸는가”입니다. 분류를 이미 하고 있는 방식마다 얻는 것과 잃는 것이 다릅니다.

가장 덜 알려진 차이는 세 번째 줄입니다. LLM에게 JSON을 받으면 confidence: 0.8도 결국 모델이 써낸 문자열입니다. 반면 Choice의 0.8은 후보들에 배분된 확률에서 계산한 값입니다. 앞의 실험에서 본 것처럼, 1위 값만 보면 멀쩡해 보이는 판단도 분포를 열어보면 망설인 흔적이 남아 있습니다. 자동 처리 여부를 그 숫자로 가르려면 이 차이가 중요합니다.

Jev를 써도 되는 곳과 안 되는 곳

Jev가 유용한 곳은 업무의 분기가 반복되고, 그 분기를 명시적인 기준으로 설명할 수 있으며, 결과를 코드가 소비하는 경우입니다. 반대로 세상에 없던 초안을 쓰거나, 긴 해설을 만들거나, 복잡한 코드를 작성하는 일은 생성 모델의 영역입니다.

또한 아래 제약을 먼저 봐야 합니다.

• 구조화 출력이 정확도를 보장하지는 않습니다. 스키마 오류를 줄여도 판단 오류는 남습니다.
• 영어가 주요 학습 언어입니다. 공식 문서는 CJK를 처리하지만 영어와 동일한 성능은 아니므로, 한국어 업무는 자체 데이터로 확인하라고 명시합니다.
• 입력은 텍스트입니다. 이미지·음성·영상은 먼저 텍스트나 구조화 필드로 바꿔야 합니다.
• 모델 별칭은 변경될 수 있습니다. 2026년 9월 19일 기준 jev-latest는 jev-1.13.0을 가리키지만 새 버전으로 이동할 수 있습니다. 임계값을 조정한 서비스는 버전 ID를 고정하고 응답의 모델 ID를 기록하는 편이 안전합니다.

모델 카드에 공개된 현재 Jev 버전은 텍스트만 받고, 64k 요청 예산과 32k state+최장 질문 제약을 둡니다. 다수의 질문을 한 state에 묶는 설계는 요청 수를 줄이지만, 질문을 무한정 넣을 수 있다는 뜻은 아닙니다. Jev 모델 문서

도입 전에는 성능표보다 분기표를 먼저 그린다

Jev를 검토할 때 첫 질문은 “기존 LLM보다 몇 % 좋은가”가 아닙니다. 우리 업무에서 어떤 판단이 반복되고, 어떤 오류는 복구할 수 있으며, 어떤 오류는 사람이 반드시 막아야 하는지를 먼저 그려야 합니다.

1. 최근 업무 데이터에서 사람이 어떤 근거로 판단했는지 정리합니다.
2. 하나의 복합 점수 대신 Choice·Score·Noul의 작은 질문으로 나눕니다.
3. 모델 출력이 아니라 코드가 최종 정책과 임계값을 소유하게 합니다.
4. 확신도 구간별 정답률과 오류 비용을 검증한 뒤, 낮은 위험의 분기부터 자동화합니다.
5. 모델 버전·질문·옵션·기준을 함께 기록해 변경 시 다시 평가합니다.

이 절차를 거치면 Jev를 쓰지 않는 결론이 나올 수도 있습니다. 규칙이 명확한 문제는 여전히 일반 코드가 더 싸고 예측 가능합니다. 반대로 개방형 답안이 필요하면 생성 모델이 맞습니다. Jev의 자리는 사람은 문장을 읽고 의미를 판단해야 하지만, 결과는 안정적인 시스템 분기로 연결되어야 하는 그 사이에 있습니다.

결국 Jev에서 눈여겨볼 점은 JSON을 반환한다는 사실 자체가 아닙니다. 생성 중심의 사고에서 벗어나, 판단 단위·후보·순서·불확실성을 API 계약으로 옮겼다는 점입니다. 이렇게 하면 프롬프트 문장 안에 숨어 있던 정책을 코드 리뷰와 지표의 영역으로 가져올 수 있습니다.

여기서부터는 우리 해석입니다. 판단 한 번이 수백 ms이고 출력 토큰에 돈이 들지 않는다면, 지금은 비싸서 한 번만 부르던 자리에 여러 번 부르는 설계가 늘어날 것입니다. 에이전트가 다음 행동을 고르는 자리, 검색된 문단을 하나씩 거르는 자리, 로그와 이벤트를 들어오는 대로 분류하는 자리, 생성한 답을 내보내기 전에 검사하는 자리가 그렇습니다. 앞에서 본 브라우저 에이전트가 매 단계 조작을 고르는 방식이 그 예입니다. 공개 나흘 만에 모인 사례들도 같은 모양입니다. 옷장 메타데이터로 620ms마다 코디를 고르는 가상 피팅, 판단마다 150ms로 로봇팔의 다음 동작을 정하는 시뮬레이션, 키를 누를 때마다 100ms 안에 파일을 추려 주는 런처처럼요. 수치는 각 제작자가 밝힌 값입니다. Jev 사례 20가지 정리 (@choi.openai)

두 번째는 인터페이스입니다. 같은 형태의 질문과 응답을 오픈 모델로 재현한 프로젝트가 이미 공개되어 있고, 우리도 그중 하나를 노트북에서 돌려볼 수 있었습니다. 그렇다면 판단 레이어는 특정 회사의 API가 아니라 갈아 끼울 수 있는 부품으로 두는 편이 안전합니다. 질문과 선택지, 임계값을 우리 코드에 남겨두면 모델이 바뀌어도 업무 규칙은 그대로 남습니다.

다만 타입이 있는 답은 시작일 뿐입니다. 좋은 판단 시스템은 모델이 잘 고르는 시스템이 아니라, 모델이 모를 때를 알아차리고 그 불확실성을 안전한 행동으로 연결하는 시스템입니다.

참고 자료

• TypeSafe AI, Introducing System One Models and Jev
• TypeSafe AI, Primitives: Choice, Score, Noul
• TypeSafe AI, Confidence
• TypeSafe AI, Models
• TypeSafe AI, JavaScript SDK
• TypeSafe AI, Classifying RAG passages
• TypeSafe AI, Double-checking citations
• Browser Use, jev-ultrafast
• TheoLeeCJ, SemIf (formerly OpenJev)
• TianyuCodings, NanoJev
• TypeSafe AI, System One Adapter (Python) · confidence_metrics.py
• Archer Hume, Jev's Architecture Unmasked (2026-09-17)
• GeekNews, Jev 아키텍처 분석 토론
• @choi.openai, Jev로 만든 사례 20가지 (Threads)