Jev란 무엇이며 어떤 LLM 판단 작업을 옮길 가치가 있는가: 평가 해석, 활용 사례, 통합 경계
Jev는 결정론적 코드와 생성형 LLM 사이에 놓입니다. 정확한 규칙은 코드가, 제한된 선택지 안의 의미 판단은 Jev가, 개방형 추론과 콘텐츠 생성은 생성형 모델이 담당합니다. 이 글은 API, 평가, 전체 워크플로 비용, 위험을 기준으로 작업을 옮길 가치가 있는지 판단하는 방법을 설명합니다.
목차
Jev는 텍스트와 구조화된 상태를 이해할 수 있지만, 반환하는 것은 제한된 결정뿐인 의미 함수로 이해하는 것이 가장 적절합니다.
대화를 나누거나 코드를 작성하거나 긴 설명을 생성하지 않습니다. state를 전달하고 여러 질문과 허용 가능한 답을 정의하면, 해당 확률 분포와 함께 Choice, Score, Noul 결과를 반환합니다. TypeSafe는 이런 종류를 System One Model이라고 부릅니다. 긴 추론 사슬을 완성하는 것이 아니라, 경계가 명확한 판단을 빠르고 반복 가능하게 수행하는 데 초점을 둡니다.[1][3]
따라서 Jev를 “더 저렴한 ChatGPT”로 봐서는 안 됩니다. 자연스러운 위치는 결정론적 코드와 생성형 LLM 사이입니다.
- 코드는 금액, 날짜, 횟수, 권한, 상태 머신처럼 정확하게 계산할 수 있는 규칙을 처리합니다.
- Jev는 “이 콘텐츠는 어느 분류에 속하는가”, “이 기록이 관련 있는가”, “이 요청은 얼마나 긴급한가”처럼 모호한 의미 판단을 처리합니다.
- 생성형 LLM은 개방형 답변, 복잡한 계획, 다단계 추론, 코드나 텍스트 생성을 처리합니다.
- 사람은 고위험, 비가역적이거나 모델의 확신이 낮은 예외를 맡습니다.
Jev는 TypeSafe 창업자 Diogo Almeida가 2026년 9월 15일 공개했습니다. TypeSafe의 설명에 따르면 Almeida는 이전에 OpenAI에서 언어 모델이 지시를 더 잘 따르고 대화하도록 만드는 방법 연구에 참여했습니다. System One이라는 이름은 Thinking, Fast and Slow의 “시스템 1”에서 가져왔고, Jev는 제번스의 역설에서 따왔습니다. 지능형 판단 한 번의 비용이 한 자릿수 이상 크게 낮아지면 수요가 같은 비율로 줄지 않고, 이전에는 모델을 호출할 가치가 없던 새로운 활용이 늘어날 수 있다는 의미입니다.[1]
2026년 9월 21일 기준 TypeSafe 문서에 표시된 안정 버전은 jev-1.13.0이었습니다. 직접 API의 입력 가격은 100만 token당 0.042달러였고 출력은 무료였습니다. 공개된 기본 rate limit은 초당 250,000 token, 분당 1,200 request였습니다. 한 request의 상한은 64k token이며, state와 가장 긴 질문을 합친 상한은 32k입니다. 모델은 텍스트만 받습니다. 영어가 주요 학습 언어이며 당시 가장 성능이 좋은 언어도 영어였습니다.[2]
출시 글은 end-to-end 응답 구간을 70500밀리초로 제시했고, System One에 적합한 질의에서는 비슷한 급의 생성 모델보다 40200배 빠를 수 있다고 설명했습니다. TypeSafe는 공개 평가가 대체로 미국 서부 해안의 노트북에서 시작됐다고도 밝혔습니다. 따라서 이 수치는 특정 작업과 네트워크 조건에서 나온 공급자 결과로 봐야 하며, 모든 지역과 입력에서 재현되는 고정 지연 시간으로 받아들여서는 안 됩니다.[1]
이 수치는 매력적이지만, 그 자체로 이전의 가치가 증명되지는 않습니다. 실제 질문은 저렴한 판단이 전체 워크플로의 비용과 오류를 줄이는가, 아니면 오류를 더 비싼 후단 모델, 사람의 검토, 비즈니스 사고로 넘길 뿐인가입니다.
먼저 작업을 올바른 계층에 배치하기: 코드, Jev, 생성형 LLM이 각각 맡을 일
후보 작업은 다음 표로 먼저 걸러볼 수 있습니다.
| 작업 | 가장 적합한 실행 주체 | 이유 |
|---|---|---|
| 환불 금액 계산, 날짜 비교, 횟수 집계 | 결정론적 코드 | 정답이 하나이며 코드가 더 빠르고 저렴하고 테스트하기 쉽습니다 |
| 티켓이 결제, 기술, 계정 문제 중 어디에 속하는지 판단 | Jev의 Choice | 답변 공간은 제한되어 있지만 자연어 이해가 필요합니다 |
| 검색 결과 일부가 현재 작업과 관련 있는지 판단 | Jev의 Noul | 본질적으로 확률이 포함된 “예/아니요” 의미 판단입니다 |
| 불만 강도, 위험 수준, 답변 품질을 단계화 | Jev의 Score | 순서가 있는 척도에 적합하고 설명 생성은 필요하지 않습니다 |
| 답장 이메일 작성, 코드 생성, 다단계 계획 수립 | 생성형 LLM | 출력 공간이 열려 있고 새로운 내용을 구성해야 합니다 |
| 여러 자료를 가로지르는 추론, 복잡한 인과 분석 | 생성형 또는 reasoning model | 하나의 원자적 판단이 아니라 다중 단계 추론에 의존합니다 |
| 자동 환불, 데이터 삭제, 송금 실행 | 코드 규칙에 확인 또는 사람을 추가 | 분류 결과가 승인, 위험 통제, 최종 확인을 대체할 수 없습니다 |
다음 세 조건을 모두 충족하는 작업만 Jev를 우선 시험할 가치가 있습니다.
- 출력을 미리 열거할 수 있다. 예를 들어
billing / technical / account / other처럼 정해져 있어야 하며, 모델이 자유롭게 작성하게 하지 않습니다. - 판단을 원자적인 질문으로 나눌 수 있다. 입력에 필요한 정보가 이미 있고, 긴 추론 사슬이나 정확한 계산을 요구하지 않습니다.
- 오류에 안전한 fallback이 있다. 확신이 낮은 결과를 더 강한 모델이나 사람에게 넘길 수 있어야 하며, 곧바로 비가역적 작업을 실행해서는 안 됩니다.
“선택형 문제만 푼다”는 점이 결함이 아닌 이유도 여기에 있습니다. 소프트웨어에서 자유 텍스트는 결국 파싱, 검증, 재시도가 필요합니다. 범위가 정해진 typed result는 분기, queue, rules engine, monitoring system으로 바로 보낼 수 있습니다.
채팅 인터페이스의 model ID만 Jev로 바꿀 수 없는 이유
Jev의 native interface는 Chat Completions가 아닙니다. 다음 endpoint를 사용합니다.
POST https://api.typesafe.ai/v1/systemoneRequest는 세 가지 핵심 부분으로 구성됩니다.[3]
model: 예를 들어 고정 버전jev-1.13.0.state: 평가할 텍스트, object 또는 array.questions: 호출자가 이름을 붙인 typed question 집합.
답은 동일한 question ID 아래 반환됩니다. 하나의 state에 관한 여러 질문을 한 번에 보내고 병렬로 결과를 받을 수 있습니다. 모델이 먼저 문장을 생성하게 한 다음 그 문장에서 JSON을 추출하는 방식이 아닙니다.[1][3]
Jev에는 세 가지 native question type이 있습니다.
| 유형 | 적합한 질문 | 주요 반환 필드 | 가장 흔한 오용 |
|---|---|---|---|
noul | 어떤 명제가 참인지 | noul, 0~1 | 별도의 confidence 필드가 없습니다. 0.8은 “예”일 확률이 80%라는 뜻이며, 자사 업무에서 80% 정확도가 입증됐다는 뜻이 아닙니다 |
choice | 유한한 선택지에서 하나 선택 | choice, probabilities, confidence | 선택지 사이의 상대적 선택입니다. 이진 Choice의 threshold를 Noul에 기계적으로 적용할 수 없습니다 |
score | 순서가 있는 척도로 평가 | score, legend, probabilities, confidence | 각 단계 확률을 가중한 점수이며, 정확한 금액, 횟수, 물리량을 복원하는 용도가 아닙니다 |
choice는 최대 255개 선택지를 지원하고, score는 2~10개의 순서형 단계가 가능합니다.[3] 답변 공간이 더 크다면 코드로 후보를 먼저 줄이거나 두 단계로 나누는 편이 일반적입니다. 수천 개의 선택지를 한 번에 모델에 넣는 방식은 적절하지 않습니다.
또 하나의 중요한 차이는 confidence가 Choice나 Score의 확률 분포 모양으로 계산된다는 점입니다. 분포가 한 결과에 집중될수록 confidence가 높고, 평평하면 여러 결과가 모두 그럴듯하다는 뜻입니다. Noul은 “예”의 확률만 반환하며 이 추가 필드는 없습니다.[5]
완전한 티켓 라우팅 예제
아래 예제는 한 request에서 담당 부서, 긴급도, 불만 강도, 환불 의도를 함께 묻습니다. Jev는 의미 이해만 담당합니다. 중복 결제 횟수, 환불 자격, 권한, 최종 행동은 계속 코드가 결정합니다.
예제 성격: 편집상 구성한 예시입니다. Request field는 2026년 9월 21일 TypeSafe API 문서를 따릅니다. Threshold는 계층화된 fallback 방식을 보여주기 위한 것으로, 보편적 권장값도 실행 기록도 아닙니다.
from __future__ import annotations
import os
from typing import Any
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry
API_URL = "https://api.typesafe.ai/v1/systemone"
MODEL = "jev-1.13.0" # alias 업데이트로 threshold가 조용히 무효화되지 않도록 버전을 고정합니다
def build_session() -> requests.Session:
retry = Retry(
total=3,
backoff_factor=0.5,
status_forcelist=(429, 529),
allowed_methods=frozenset({"POST"}),
respect_retry_after_header=True,
)
session = requests.Session()
session.mount("https://", HTTPAdapter(max_retries=retry))
return session
def evaluate_ticket(ticket: dict[str, Any]) -> dict[str, Any]:
api_key = os.environ["TYPESAFE_API_KEY"]
payload = {
"model": MODEL,
"state": {
"subject": ticket["subject"],
"message": ticket["message"],
"plan": ticket["plan"],
"account_status": ticket["account_status"],
},
"questions": {
"department": {
"type": "choice",
"instructions": "이 티켓을 처리하기에 가장 적합한 팀은 어디입니까?",
"criteria": {
"billing": "결제, 청구서, 인보이스 또는 환불 문제",
"technical": "장애, API 오류, 성능 또는 통합 문제",
"account": "로그인, 권한, 프로필 또는 계정 상태 문제",
"other": "위 분류 중 어느 것도 적합하지 않음",
},
},
"urgent": {
"type": "noul",
"instructions": "이 티켓을 현재 영업일 안에 우선 처리해야 합니까?",
"criteria": {
"true": "현재도 비즈니스 중단, 금전적 위험 또는 명확한 시간 압박을 일으키고 있음",
"false": "일반 queue에서 처리할 수 있으며 현재 영업일 안의 긴급성이 없음",
},
},
"frustration": {
"type": "score",
"instructions": "고객은 현재 어느 정도 불만을 느끼고 있습니까?",
"criteria": [
"말투가 차분하며 주로 정보를 문의하고 있음",
"명확히 불만이 있지만 문제 해결 과정에는 협조할 의사가 있음",
"불만이 매우 크며 민원, 이탈 또는 escalation 위험이 있음",
],
},
"requests_refund": {
"type": "noul",
"instructions": "고객이 환불 또는 중복 결제 취소를 명확히 요청하고 있습니까?",
"criteria": {
"true": "고객이 돈을 돌려달라거나 환불 또는 중복 결제 취소를 명확히 요청함",
"false": "원인만 문의하거나 문제를 확인 중이며 환불을 요청하지 않음",
},
},
},
}
response = build_session().post(
API_URL,
headers={
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
},
json=payload,
timeout=10,
)
response.raise_for_status()
return response.json()
def route_ticket(ticket: dict[str, Any], evaluation: dict[str, Any]) -> dict[str, Any]:
answers = evaluation["answers"]
department = answers["department"]
urgent_probability = answers["urgent"]["noul"]
refund_probability = answers["requests_refund"]["noul"]
# confidence가 낮은 Choice는 사람의 triage로 보냅니다. threshold는 자체 라벨 데이터로 보정해야 합니다.
queue = department["choice"]
if department["confidence"] < 0.75:
queue = "human_triage"
# Noul에는 confidence 필드가 없습니다. 중간 확률 구간을 업무상 불확실 영역으로 취급합니다.
priority = "normal"
if urgent_probability >= 0.85:
priority = "high"
elif 0.35 < urgent_probability < 0.65:
priority = "needs_review"
tags: list[str] = []
# 정확한 횟수는 모델이 아니라 코드가 계산합니다.
if ticket["duplicate_charge_count"] >= 2:
tags.append("possible_duplicate_charge")
# Jev는 환불 의도를 인식하지만, 실제 환불 여부는 정책, 권한, 확인 절차가 결정합니다.
if refund_probability >= 0.80:
tags.append("refund_requested")
return {
"queue": queue,
"priority": priority,
"tags": tags,
"requires_human_approval": "refund_requested" in tags,
"model_version": evaluation["model"],
}
if __name__ == "__main__":
ticket = {
"subject": "중복 결제입니다. 오늘 안에 해결해야 합니다",
"message": "같은 주문에 두 번 결제됐습니다. 이미 하루를 기다렸으니 초과 결제된 금액을 가능한 한 빨리 돌려주세요.",
"plan": "pro",
"account_status": "active",
"duplicate_charge_count": 2,
}
evaluation = evaluate_ticket(ticket)
decision = route_ticket(ticket, evaluation)
print(decision)이 예제에서 Jev는 “고객에게 99달러를 환불하라”고 직접 반환하지 않습니다. 업무 코드가 필요로 하는 신호만 제공합니다. 어느 queue로 보내야 하는지, 긴급한지, 불만이 얼마나 큰지, 환불을 요청했는지입니다. 금액, 중복 횟수, 계정 상태, 승인 권한은 테스트 가능한 코드가 계속 관리합니다.
Jev가 가장 큰 가치를 내는 조합은 이것입니다. 의미 판단은 모델이 하고, 업무 제약은 코드가 적용하며, 부작용이 있는 작업은 확인 절차가 보호합니다.
먼저 검증할 가치가 있는 세 가지 활용 사례
1. 모델과 도구 라우팅: 먼저 판단하고 실행 주체를 선택하기
많은 Agent는 모든 요청을 먼저 같은 대형 모델에 보내고, 검색, 데이터베이스, 코드 실행, 다른 모델 중 무엇을 호출할지까지 결정하게 합니다. 구현은 간단하지만 매 요청마다 전체 생성 비용이 들고, 한 번의 잘못된 라우팅이 여러 추가 호출로 이어질 수 있습니다.
Jev에 더 적합한 설계는 라우팅을 원자적 판단으로 나눕니다.
intent: 검색, 코딩, 번역, 데이터 분석, 일반 Q&A 중 무엇인가?complexity: 단순, 보통, 깊은 추론 필요 중 어느 수준인가?requires_realtime_data: 현재 정보가 필요한가?risk_level: 쓰기 작업, 금전, 권한, 민감 데이터를 포함하는가?
Jev가 판단을 반환하면 코드가 모델 capability table, 예산, 지역별 이용 가능성, 도구 권한과 결합해 후단 실행 주체를 고릅니다. 분류와 승인을 섞지 않는 구조입니다.
Fallback도 미리 설계해야 합니다. confidence가 낮은 Choice는 범용 모델에 재검토를 맡길 수 있습니다. 고위험 쓰기 작업은 분류 confidence가 높아도 권한 확인과 사용자 확인을 거쳐야 합니다. 평가에서는 라우팅 정확도뿐 아니라 잘못된 경로로 인한 추가 호출, 총 지연 시간, 총비용도 봐야 합니다.
커뮤니티 프로젝트 pi-jev는 비슷한 아이디어를 turn 단위 모델 라우팅으로 구현했습니다. Jev가 요청 난이도를 평가하고 threshold에 도달하면 더 저렴하거나 더 강한 모델로 전환하며, confidence가 낮거나 예외 상황이면 기존 모델을 유지합니다.[12] 이 구조를 코드로 구현할 수 있음을 보여주지만, 저장소의 기본 threshold와 예시 결과는 해당 구현에만 적용되며 다른 시스템의 이익 예측으로 사용할 수 없습니다.
2. 컨텍스트와 검색 조각 필터링: 줄인 token이 아니라 작업 완료율 측정하기
긴 대화, RAG, Agent trajectory에서는 과거 내용의 상당 부분이 현재 작업에 더 이상 중요하지 않을 수 있습니다. Jev는 각 조각에 대해 다음을 판단할 수 있습니다.
- 이 정보가 현재 목표와 관련 있는가?
- 사실, 제약, 사용자 선호, 이미 무효가 된 중간 과정 중 무엇인가?
- 버리면 이후 tool call이 깨질 가능성이 있는가?
컨텍스트 압축을 “관련 확률이 낮으면 삭제”로 단순화해서는 안 됩니다. 코드는 구조적 무결성을 유지해야 합니다. tool call과 tool result는 쌍으로 보존하고, 시스템 제약, 현재 목표, 미완료 작업을 따로 삭제해서는 안 됩니다. 불확실 구간의 조각은 유지하거나 더 강한 모델에 재검토를 맡길 수 있습니다.
fast-jev-compaction은 참고할 만한 초기 구현입니다. tool call과 결과를 계속 보존할지 판단하고, 남길 내용은 가능한 한 원문을 유지하며, Jev가 실패하거나 압축 이득이 충분하지 않으면 기존 요약 흐름으로 fallback합니다.[11] 이런 보수적 fallback은 “모델이 지우라고 했으니 지운다”보다 production system의 안전 경계에 가깝지만, 자체 작업 완료율로 검증해야 합니다.
TypeSafe도 관련 없는 정보가 많은 state는 Jev의 정확도를 낮출 수 있다고 경고합니다. 파일 유형, 기간, 권한 범위, 알려진 ID처럼 코드로 판별할 수 있는 부분은 결정론적 전처리로 먼저 거르고, 남은 의미적 관련성을 Jev에 맡겨야 합니다.[4]
최종 합격 기준도 “token을 70% 압축했다”가 되어서는 안 됩니다. 압축 후에도 Agent가 원래 작업을 완수하는지, 핵심 제약이 남아 있는지, 오류 복구 횟수가 늘지 않는지, 후단 비용 절감이 필터링과 fallback 비용을 넘는지 확인해야 합니다.
3. 티켓 분류와 사람의 triage: 의미는 모델이, 실행은 규칙이 담당하기
고객 지원과 운영 티켓에는 담당 부서, 의도, 긴급도, 민원 위험, 사람의 개입 필요 여부, 환불 관련 여부처럼 제한된 결정이 자연스럽게 많이 존재합니다. 이들은 한 request 안에서 병렬 평가할 수 있습니다.
경계는 명확합니다.
- “사용자가 환불을 요청하는가?”는 Noul에 맡길 수 있습니다.
- “어느 부서가 담당해야 하는가?”는 Choice에 맡길 수 있습니다.
- “escalation 위험이 얼마나 높은가?”는 Score에 맡길 수 있습니다.
- “얼마를 환불할지”, “7일 조건을 충족하는지”, “담당자에게 권한이 있는지”는 코드가 결정해야 합니다.
- 실제 환불, 정지, 삭제, 송금 전에는 계속 승인 또는 확인이 필요합니다.
이 분해의 장점은 낮은 지연 시간뿐이 아닙니다. 각 질문에 독립된 라벨, 오류 유형, threshold가 생깁니다. 문제가 발생하면 “환불 의도를 잘못 인식했는지”, “rules engine이 잘못 실행됐는지”를 분리해 확인할 수 있으며, 모든 로직이 담긴 거대한 Prompt 하나를 디버깅할 필요가 없습니다.
하나의 배수에 끌려가지 않고 Jev 평가를 읽는 법
TypeSafe는 보안 사고, Agent trajectory 관측, 인보이스 처리, 고객 서비스의 네 가지 workflow 평가를 공개했습니다. 공통 방식은 전체 업무를 좁은 질문과 코드 규칙으로 분해한 뒤, “하나의 큰 Prompt가 모든 것을 처리하는” 방식과 비교하는 것이었습니다.[6]
이 평가에서는 두 가지 유용한 방향을 볼 수 있습니다.
- 같은 모델이라도 구조화된 workflow 안에 넣으면 모든 로직을 혼자 수행하게 할 때보다 안정적인 경우가 많습니다.
- 여러 독립 판단을 병렬로 처리하고 출력이 바로 코드로 들어가는 작업 형태에서 Jev의 장점이 가장 잘 나타날 가능성이 큽니다.
하지만 TypeSafe의 reference label은 고성능 외부 모델의 평균 예측에서 나온 것이며, 독립적인 사람의 gold standard가 아닙니다. 출시 글의 최대 193.6배 속도 향상과 444.6배 비용 절감도 공급자 스스로 실제 이득의 상단 범위라고 설명했고, 평가가 자사 model capabilities 팀에서 만들어져 편향이 있을 수 있다고 인정했습니다.[1]
따라서 이 숫자는 가설을 세우는 데는 유용하지만, 자체 ROI 예산에 그대로 넣기에는 적절하지 않습니다.
2026년 9월 20일 LangChain은 독립적이지만 매우 제한적인 Jev Evaluator 실험도 공개했습니다. 날씨 Agent 실행 기록 5개를 고정하고 한 명의 사람이 reference label을 부여한 뒤, Jev, GPT-5.6 Luna, GPT-5.6 Terra, Claude Sonnet 4.6이 같은 기록을 각각 100회 판단했습니다. 500개의 이진 판단에서 Jev는 모두 그 사람의 label과 일치했고, 연속 점수에서는 관측 분산이 가장 낮았으며, 판단 1회 비용은 0.00035달러였습니다.[7]
이 결과는 제한된 판단이 생성형 Judge보다 안정적일 수 있다는 추가 신호를 줍니다. 그러나 고정 sample은 5개, domain은 하나, 사람 평가자도 한 명뿐이며, 실험 metadata에 Jev의 정확한 서비스 버전도 기록되지 않았습니다. LangChain은 낮은 비용이 지속적으로 틀리는 evaluator도 대규모로 확장할 수 있으므로, production system에는 사람과의 정렬과 검토가 여전히 필요하다고 명확히 경고했습니다.[7]
더 신중한 해석은 다음과 같습니다. Jev는 시험할 가치가 있는 성능 형태를 이미 보여줬지만, 현재 규칙이나 모델보다 우수한지는 자체 데이터, 오류 비용, fallback chain으로만 판단할 수 있습니다.
유용한 평가는 한 번의 API 호출이 아니라 전체 워크플로를 비교한다
Jev를 시험할 때는 최소 세 가지 비교군을 유지해야 합니다.
- 현재 규칙 또는 keyword baseline.
- 현재 사용하는 저비용 생성 모델.
- 버전을 고정한 Jev.
고위험 작업은 사람의 label도 유지해야 합니다. Dataset에는 일반 sample, 소수 class, 경계 표현, 부정문, 긴 텍스트, prompt injection, 실제 사용하는 중국어·러시아어·영어가 포함되어야 합니다. 세 언어는 각각 측정해야 하며, 영어 threshold로 중국어나 러시아어 성능을 추론해서는 안 됩니다.
품질 지표
분류에서는 전체 accuracy만으로 충분하지 않습니다. 다음 지표가 더 유용합니다.
- 각 class의 precision, recall, F1.
- 고위험 쓰기 작업을 저위험으로 분류하는 것 같은 비용이 큰 오류.
- 자동 처리 coverage와 자동 처리 error rate의 관계.
- 확률 calibration: 0.8 근처로 예측된 sample 가운데 실제 업무 데이터에서도 약 80%가 참인가?
- 언어, 고객 유형, 텍스트 길이, adversarial sample별 결과.
Choice와 Score는 confidence를 기준으로 fallback을 설정할 수 있습니다. Noul에는 이 필드가 없으므로 자체 calibration 결과로 확률 구간을 정해야 합니다. 예를 들어 0.5 부근은 검토로 보내고, 0.5에서 충분히 먼 결과만 자동 분기할 수 있습니다. 구체적인 경계는 오류 비용으로 정해야 하며 문서 예제의 숫자를 복사해서는 안 됩니다.[5]
시스템 지표
Jev의 공급자 지연 시간은 특정 네트워크와 서비스 위치에서 측정된 값입니다. 자체 시스템은 다음을 기록해야 합니다.
- 순수 API latency와 네트워크, queue, retry, parsing을 포함한 end-to-end P50, P95, P99.
429,529, timeout, retry 비율.- 낮은 confidence 결과가 생성형 모델 또는 사람에게 fallback되는 비율.
- fallback 후 최종 작업 성공률.
- 버전, 언어, 질문 template, threshold 변경 전후의 drift.
평균 380밀리초 같은 단일 숫자만 보면 tail latency와 fallback 비용이 가려집니다. 실시간 제품에서는 평균보다 P95가 사용자 경험을 더 잘 반영하는 경우가 많습니다.
전체 비용
업무 판단 한 번의 비용은 다음과 같이 표현할 수 있습니다.
전체 비용
= Jev 호출 비용
+ retry 확률 × retry 비용
+ fallback 확률 × fallback 모델 비용
+ 후단 도구 또는 모델 비용
+ 사람 검토 비용
+ 오분류로 인한 기대 손실Jev가 저렴하더라도 오류 때문에 요청의 15%가 비싼 모델을 다시 호출하거나 많은 사람 검토를 추가한다면 기존 방식보다 절약되지 않을 수 있습니다. 반대로 호출당 가격 차이가 크지 않아도 고위험 오류를 크게 줄이고 tail latency를 안정화한다면 도입할 가치가 있을 수 있습니다.
가장 안전한 rollout은 shadow evaluation으로 시작합니다. Jev는 판단을 기록하지만 실제 흐름에는 영향을 주지 않습니다. Threshold가 안정된 뒤 저위험이고 복구 가능한 분기부터 점진적으로 활성화하며, 고위험 작업에는 항상 승인과 확인을 남깁니다.
현재 Jev에서 가장 주의해야 할 경계
1. 타입이 맞다고 의미 판단도 맞는 것은 아니다
Jev는 파싱할 수 없는 문장이 아니라 사전 정의한 type을 반환하도록 보장할 수 있습니다. 이는 인터페이스 구조 문제를 해결합니다. 하지만 인보이스를 잘못 분류하거나, 부정문을 오해하거나, 입력의 adversarial content에 영향을 받을 수 있습니다. TypeSafe의 제한 문서는 literal interpretation, 모순되는 criteria, 관련 없는 컨텍스트, prompt injection을 명시적인 위험으로 제시합니다.[4]
따라서 “type error가 없다”를 “판단 오류가 없다”로 확대해서는 안 됩니다.
2. 수학, 날짜, 정확한 횟수는 코드에 맡긴다
score는 확률 가중 단계이지 계산기가 아닙니다. 금액 합산, 날짜 순서, 지속 시간, 문자 수, 재고 수량은 코드가 계산해야 합니다. Jev는 문장이 긴급함을 표현하는지 판단할 수 있지만, “마감까지 17시간 남았다”를 계산하게 해서는 안 됩니다.[4]
3. 다단계 추론은 분해한다
이중 부정, 여러 단계를 가로지르는 관계, 한 질문에 여러 판단을 묶는 방식은 신뢰도를 낮춥니다. “이 고객은 환불 비대상 사용자도 아니고 저위험 계정도 아닌가?”라고 묻기보다, 환불 의도, 계정 위험, 권한 상태를 세 질문으로 나누고 코드에서 결합하는 편이 낫습니다.
4. Noul, Choice, Score 사이에서 threshold를 재사용하지 않는다
같은 자연어 질문을 Noul과 이진 Choice로 표현해도 확률이 단순한 보완 관계일 필요는 없습니다. Choice는 “이 선택지 중 무엇이 더 적합한가”를 답하고, Noul은 “이 명제가 성립하는가”를 답합니다. 통계적 의미가 다릅니다.[4]
질문 type이나 모델 버전을 바꾸면 threshold를 다시 calibration해야 합니다.
5. 비영어 작업은 독립적으로 검증한다
공식 문서는 현재 영어 성능이 가장 좋다고 명시합니다. CJK를 포함한 다른 언어도 처리할 수 있지만 성능이 같지는 않습니다.[2] 중국어, 러시아어, 혼합 언어 티켓은 각각 별도의 dataset과 threshold가 필요합니다. 소수의 번역 sample은 실제 현지 표현을 대신할 수 없습니다.
6. 버전을 고정하고 실제 반환 버전을 기록한다
jev-latest는 새 버전 출시와 함께 바뀝니다. Production threshold를 jev-1.13.0에서 calibration했다면 그 버전을 고정하고, 모든 response의 model을 기록해야 합니다. Alias가 자동으로 바뀐 뒤 오래된 threshold를 계속 쓰지 말고, 업그레이드 때 regression set을 다시 실행해야 합니다.[2]
현재 통합 경로와 지역 조건
TypeSafe는 2026년 9월 15일 Jev를 공개하면서 직접 서비스를 early access로 표시했습니다. 개발자는 native /v1/systemone을 쓰거나 Vercel AI Gateway의 AI SDK Evaluation API를 통해 호출할 수 있었습니다. Vercel의 model ID는 typesafe-ai/jev였고 AI SDK 7.0.105 이상이 필요했습니다. 호출은 experimental_evaluate를 사용하며 OpenAI-compatible Chat Completions로 보내는 방식이 아닙니다.[1][8]
TypeSafe는 고객 request와 response를 모델 학습에 사용하지 않고, 기업 고객은 Zero Data Retention을 요청할 수 있다고 밝혔습니다. 실제 로그, 보관 기간, 규정 준수 책임은 이용하는 계정 계약을 기준으로 확인해야 합니다.[2][10]
지역 측면에서 TypeSafe 사이트 약관은 사이트가 미국 방문자를 대상으로 하며 미국 외 지역에서 이용 가능하다고 보장하지 않는다고 명시했습니다. 미국 밖의 팀은 production 통합 전에 계정 자격, 계약, 데이터 이전, 현지 규정을 확인해야 합니다. 문서를 열 수 있다는 사실을 장기적인 production 사용 가능성의 증거로 보면 안 됩니다.[9]
결론: Jev는 약한 채팅 모델이 아니라 새로운 의사결정 인프라 계층이다
ChatGPT의 성공으로 “지능”은 오랫동안 “콘텐츠 생성”과 같은 의미로 받아들여졌습니다. Jev는 다른 형태를 제안합니다. 모델이 답을 작성하는 대신 의미 이해를 소프트웨어가 즉시 실행할 수 있는 제한된 판단으로 압축합니다.
잠재력은 모든 LLM을 대체하는 데 있지 않습니다. 비싼 생성 모델이 처리하지만 실제로는 Yes/No, A/B/C, 1~5점만 필요한 많은 작업을 분리하는 데 있습니다. 라우팅, 필터링, 스코어링, 위험 신호, Agent 평가, workflow 분기는 더 낮은 지연 시간과 더 명확한 관측 가능성을 얻을 수 있습니다.
그러나 production 도입 여부를 결정하는 것은 100만 token당 0.042달러라는 가격이나 특정 100배 속도 주장도 아닙니다. 다음 네 가지가 중요합니다.
- 작업을 명확한 원자적 판단으로 나눌 수 있는가?
- 확률과 confidence를 자체 데이터에서 calibration했는가?
- 낮은 confidence와 고위험 결과에 신뢰할 수 있는 fallback이 있는가?
- retry, fallback, 후단 호출, 사람 검토, 오분류를 모두 포함한 뒤에도 전체 workflow가 실제로 더 나은가?
Jev는 의미 이해 능력을 가진 “super if”로 볼 수 있습니다. 다만 신뢰할 수 있는 자동화는 여전히 모델 판단, 코드 제약, 권한 통제, 사람의 fallback이 함께 작동해야 완성됩니다.
