“결제가 두 번 됐어요. 빨리 취소해주세요.”
이 문장을 받은 고객지원 시스템에 필요한 것은 그럴듯한 답장 초안보다 먼저 어느 팀에 보낼지, 환불을 요청했는지, 얼마나 긴급한지라는 판단입니다. 일반적인 LLM에게도 JSON을 요청할 수 있지만, 출력 형식을 맞추는 일과 그 판단을 잘하도록 만드는 일은 같은 문제가 아닙니다.
TypeSafe AI가 2026년 9월 공개한 Jev는 후자에 초점을 맞춘 System One 모델입니다. System One이라는 이름은 대니얼 카너먼이 『생각에 관한 생각(Thinking, Fast and Slow)』에서 구분한 빠르고 직관적인 System 1 사고에서 따왔습니다. 긴 문장을 생성하는 대신, 입력 state를 읽고 미리 정의한 질문에 대한 타입이 있는 판단과 확률 분포를 반환합니다. 아직 early access 단계이고, 이 글의 예시는 공식 문서에 기반한 설계 예시이지 플래드랩스의 실제 서비스 측정 결과는 아닙니다. TypeSafe AI 공식 발표
문장을 생성하는 일과 판단하는 일을 나눈다
업무 자동화에서 LLM이 하는 일은 크게 두 가지입니다. 하나는 이메일·보고서·코드처럼 새로운 내용을 만드는 일이고, 다른 하나는 이미 있는 내용을 읽고 분류·평가·검사하는 일입니다. 전자는 어떤 문장을 만들었는지가 중요하지만, 후자는 그 결과를 시스템이 바로 쓸 수 있는지가 더 중요합니다.
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 질문 타입 문서
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 공식 문서
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는 발표에서 모든 답에 보정된(calibrated) 확률과 확신도가 함께 나온다고 설명합니다. 보정이 잘 되어 있다면 확신도가 높은 판단일수록 실제로도 더 자주 맞아야 합니다. 다만 이는 개발사 평가 데이터에서의 이야기이고, 우리 데이터에서도 그런지는 직접 확인해야 합니다. TypeSafe AI 공식 발표
운영에서 더 위험한 것은 낮은 확신도보다 높은 확신도의 오판입니다. 검증 데이터에서 다음을 따로 봐야 합니다.
- 정답을 맞힌 비율이 아니라, 확신도 구간별 정답률
- 자동 처리 비율과 사람에게 보낸 비율
- 오판으로 발생한 비용과 복구 가능성
- 없던 카테고리, 정보 부족, 모순된 문장에서의 거동
TypeSafe도 공식 문서에서 임계값은 도메인과 위험에 따라 달라져야 하며, 자체 데이터로 보수적으로 조정하라고 권고합니다. Confidence 공식 문서
속도는 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는 대체로 자유로운 문장과 결정적 코드의 사이에 들어갑니다.
| 문제 | Jev의 판단 | 코드가 소유할 것 |
|---|---|---|
| 고객지원 라우팅 | 담당 팀 Choice, 환불 요청 Noul, 긴급도 Score | 큐 배정, SLA, 자동 처리 범위 |
| RAG 검색 결과 필터 | 질문과의 관련성, 답변 근거 포함 여부, 전제와의 모순, 프롬프트 인젝션 위험 Noul | 답변 모델에 넘길 문단, 거부·경고 정책 |
| 인용 검증 | 원문이 주장을 지지하는지, 반박하는지, 다루지 않는지 Choice | 문자열 일치 검사, 자동 승인 기준, 사람 검수 |
| 함수 선택 | 사용자 요청에 맞는 함수와 폐쇄형 인자 Choice | 타입 검증, 권한 확인, 실제 함수 실행 |
RAG 사례가 특히 중요합니다. 검색 유사도가 높은 문서라고 해서 답변에 쓰기 좋은 문서는 아닙니다. 사용자의 잘못된 전제를 반박하는 문서는 표현이 다르고, 검색된 커뮤니티 문장에는 답변 모델을 속이는 지시가 숨어 있을 수 있습니다. 공식 RAG 케이스는 문단마다 네 가지 Noul 질문을 던진 뒤, 어떤 문단을 유지·표시·제거할지 코드가 결정하는 구조를 보여줍니다. Classifying RAG passages
인용 검증에서도 모델에게 모든 것을 맡기지 않습니다. 원문에 인용문이 존재하는지는 문자열 검사로 먼저 확인하고, 존재하는 인용의 맥락이 주장을 받치는지만 모델에 묻습니다. 정확한 검사는 코드에, 의미 판단은 모델에 두는 좋은 분리입니다. Double-checking citations
Jev를 써도 되는 곳과 안 되는 곳
Jev가 유용한 곳은 업무의 분기가 반복되고, 그 분기를 명시적인 기준으로 설명할 수 있으며, 결과를 코드가 소비하는 경우입니다. 반대로 세상에 없던 초안을 쓰거나, 긴 해설을 만들거나, 복잡한 코드를 작성하는 일은 생성 모델의 영역입니다.
또한 아래 제약을 먼저 봐야 합니다.
- 구조화 출력이 정확도를 보장하지는 않습니다. 스키마 오류를 줄여도 판단 오류는 남습니다.
- 영어가 주요 학습 언어입니다. 공식 문서는 CJK를 처리하지만 영어와 동일한 성능은 아니므로, 한국어 업무는 자체 데이터로 확인하라고 명시합니다.
- 입력은 텍스트입니다. 이미지·음성·영상은 먼저 텍스트나 구조화 필드로 바꿔야 합니다.
- 모델 별칭은 변경될 수 있습니다. 2026년 9월 19일 기준
jev-latest는jev-1.13.0을 가리키지만 새 버전으로 이동할 수 있습니다. 임계값을 조정한 서비스는 버전 ID를 고정하고 응답의 모델 ID를 기록하는 편이 안전합니다.
모델 카드에 공개된 현재 Jev 버전은 텍스트만 받고, 64k 요청 예산과 32k state+최장 질문 제약을 둡니다. 다수의 질문을 한 state에 묶는 설계는 요청 수를 줄이지만, 질문을 무한정 넣을 수 있다는 뜻은 아닙니다. Jev 모델 문서
도입 전에는 성능표보다 분기표를 먼저 그린다
Jev를 검토할 때 첫 질문은 “기존 LLM보다 몇 % 좋은가”가 아닙니다. 우리 업무에서 어떤 판단이 반복되고, 어떤 오류는 복구할 수 있으며, 어떤 오류는 사람이 반드시 막아야 하는지를 먼저 그려야 합니다.
- 최근 업무 데이터에서 사람이 어떤 근거로 판단했는지 정리합니다.
- 하나의 복합 점수 대신 Choice·Score·Noul의 작은 질문으로 나눕니다.
- 모델 출력이 아니라 코드가 최종 정책과 임계값을 소유하게 합니다.
- 확신도 구간별 정답률과 오류 비용을 검증한 뒤, 낮은 위험의 분기부터 자동화합니다.
- 모델 버전·질문·옵션·기준을 함께 기록해 변경 시 다시 평가합니다.
이 절차를 거치면 Jev를 쓰지 않는 결론이 나올 수도 있습니다. 규칙이 명확한 문제는 여전히 일반 코드가 더 싸고 예측 가능합니다. 반대로 개방형 답안이 필요하면 생성 모델이 맞습니다. Jev의 자리는 사람은 문장을 읽고 의미를 판단해야 하지만, 결과는 안정적인 시스템 분기로 연결되어야 하는 그 사이에 있습니다.
결국 Jev에서 눈여겨볼 점은 JSON을 반환한다는 사실 자체가 아닙니다. 생성 중심의 사고에서 벗어나, 판단 단위·후보·순서·불확실성을 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
