Jev가 0.9를 반환하면 자동 실행해도 될까: 확률 보정과 오판 비용

TypeSafe AI는 2026년 9월 15일 빠른 판단을 위한 System One Model인 Jev를 공개했다. 공식 발표에서 제시한 193.6배의 속도 향상과 444.6배의 비용 차이는 제공자가 구성한 작업에서 얻은 수치로, 일반적인 LLM 성능 비교가 아니다.

Jev는 글을 생성하는 대신 미리 정의된 형식의 값을 반환한다. 형식이 맞아도 판단 자체는 틀릴 수 있으므로 두 항목은 따로 검증해야 한다. 불확실한 결과를 사람이 확인하게 할지, 실행을 중단할지는 애플리케이션이 정한다.

TypeSafe AI는 Jev를 조기 접근 형태로 공개하면서 새로운 모델 구조, 병렬 샘플러, Reinforcement Learning for Calibrated Decisions(RLCD)를 사용했다고 밝혔다. 그러나 공개 자료에는 내부 구조의 세부 사항이나 모델 가중치, RLCD 알고리즘, 학습 데이터가 없다.

공식 발표에 따르면 전체 응답 시간은 70~500ms, 가격은 입력 100만 토큰당 $0.042이다. 40~200배의 속도 향상과 워크플로 기준 193.6배의 속도 향상·444.6배의 비용 차이도 함께 제시됐다. TypeSafe AI는 이 평가가 미국 서부의 노트북에서 서비스를 호출한 결과이며, 큰 배수는 현실적인 개선 폭의 상단에 가깝다고 설명한다. 다른 지역이나 네트워크, 요청 부하에서도 같은 결과가 나온다는 뜻은 아니다.

Jev는 현재 정보인 상태(state)와 정형 질문을 입력으로 받는다. 상태에는 고객 문의, 계정 기록, 도구 호출처럼 판단에 필요한 정보를 담는다. 질문 유형은 세 가지다. Choice는 정해진 선택지 중 하나와 확률 분포를, Score는 순서가 있는 평가 척도상의 위치와 분포를 반환한다. Noul은 질문의 답이 ‘예’일 확률을 0~1 값으로 돌려준다.

같은 상태를 참조하는 질문은 한 요청에 묶을 수 있지만 서로 독립적으로 평가된다. 고객 문의를 예로 들면 요청 유형은 Choice, 불만의 정도는 Score, 환불 요청 여부는 Noul로 동시에 묻는다. 결과를 받은 코드는 확률을 읽고 자동 처리, 추가 확인, 사람 검토 중 하나를 고른다. 한 질문이 다른 질문의 답에 의존한다면 코드가 새 상태를 만든 뒤 두 번째 요청을 실행한다.

여기서 확률과 confidence는 구분해야 한다. Choice와 Score의 confidence는 확률 분포가 한쪽에 얼마나 집중됐는지를 요약한 값이다. 정답일 확률 자체가 아니며, Noul에는 별도의 confidence 필드가 없다. 따라서 높은 confidence를 곧바로 높은 정확도로 해석해서는 안 된다.

일반적인 JSON mode가 생성된 문자열의 형식을 제한한다면, Jev는 가능한 답을 먼저 정의하고 그 집합의 확률을 반환하도록 설계됐다. 다만 스키마 밖의 값을 만들지 않는다는 보장과 정답을 고른다는 보장은 다르다. 선택지에 정답이 없거나 입력 정보가 불완전하면 형식상으로는 완전해도 틀린 답이 나올 수 있다.

TypeSafe AI의 워크플로 평가는 보안 사고, 에이전트 실행 기록 관측, 송장 처리, 고객 응대의 네 가지 작업을 다룬다. 각 작업을 긴 프롬프트 하나로 풀지 않고, 작은 판단 여러 개와 정해진 규칙을 실행하는 코드로 나눈다. 평가 기준은 사람이 확정한 정답이 아니라 GPT-6 Astra와 Fable 5.1을 높은 추론 설정으로 실행해 얻은 응답 확률의 평균이다.

193.6배와 444.6배는 같은 작업 절차와 기준 답을 바탕으로 얻은 제공자 측 성능·비용 비교다. 실제 업무 정확도나 독립 벤치마크를 뜻하지는 않는다. 작업 역시 TypeSafe AI의 모델 역량 팀이 만들었으며, 회사도 공식 글에서 편향 가능성을 인정한다.

모델 교체에 앞서 살펴볼 것은 작업 구조다. 공개 평가에서는 모든 논리를 긴 프롬프트로 처리하는 방식보다 작은 질문과 코드로 분해하는 방식이 대체로 유리했다. 기존 LLM 자동화부터 판단과 실행 규칙으로 나눠 비교해 볼 이유가 있다. 다만 이를 모든 개별 작업과 모델 조합에서 반드시 개선된다는 보장으로 확대 해석해서는 안 된다.

zero hallucination 주장도 좁게 읽어야 한다. TypeSafe AI가 제시한 0%는 실측 오류율이 아니라 스키마 일치가 보장된다는 이유로 넣은 값이다. Jev도 허용된 선택지 안에서 잘못된 값을 고를 수 있다. 형식의 안전성이 판단 내용이 옳다는 증거는 아니다.

Jev는 가능한 답을 요청 전에 정의할 수 있고, 자연어 입력에서 짧은 판단을 반복하는 작업에 맞다. 문의 분류, 사용할 모델 선택, 에이전트 도구 호출 점검, 콘텐츠 검토, 검토 우선순위 지정 등이 그 예다. 반면 글쓰기, 코드 생성, 긴 추론처럼 새로운 문자열을 만들어야 하는 작업은 일반 LLM의 영역이다.

도입 전에는 실제 업무에서 정답을 확인한 자료로 확률 보정 상태를 평가해야 한다. 예를 들어 ‘예’일 확률이 0.9인 예측 묶음에서 실제 ‘예’의 비율이 그에 가까운지 확인하는 식이다. 이는 confidence가 0.9인 경우와는 다른 검사다. 실행 임계값을 높였을 때 자동 처리 비율과 오판 비용이 어떻게 바뀌는지도 함께 측정한다. 새로운 상품, 한국어 표현, 정책 변경, 공격성 입력에서도 결과가 유지되는지 확인하고, p50뿐 아니라 p95 지연 시간과 대체 처리 비용도 기록해야 한다.

행동 정책은 모델 밖에 둔다. 모델이 강한 확신을 보여도 결제, 계정 정지, 데이터 삭제처럼 되돌리기 어려운 작업은 코드의 권한 검사와 사용자 확인을 거친다. 불확실한 결과는 입력 정보 보강, 사람 검토, 명시적 중단으로 연결할 수 있다. 반대로 규칙 기반 처리만으로 충분한 구조화 입력이라면 굳이 Jev를 추가할 이유가 없다.

가상 검증 자료에서 Noul이 0.9를 반환한 요청 100개 중 실제 ‘예’가 70개라면, 해당 묶음의 관측 비율은 0.7이다. 높은 출력값만 보고 90개가 맞을 것으로 처리하면 20개의 차이를 놓치게 된다. 반대로 실제 ‘예’가 90개여도 이 묶음 하나로 모든 확률 구간과 새 고객군의 보정 상태를 보장할 수는 없다. 같은 검사를 구간별·업무별로 반복하고 표본 수를 함께 기록한다. 이 100개는 Jev의 실제 평가 결과가 아니라 보정 개념을 설명하기 위한 예시다.

실행 임계값에는 비용이 반영된다. 가정상 잘못 자동 처리할 때의 비용이 100, 사람 검토 비용이 5이고 사람이 오류 없이 판단한다면, 정답일 확률 p에서 자동 처리의 기대 오류 비용은 100×(1−p)다. 이 값이 5보다 작아지는 p>0.95가 이 단순 모형의 기준이 된다. 여기에 검토 오류나 지연, 서로 다른 오판 피해를 넣으면 기준은 달라진다. 실제로 보정되지 않은 출력 0.96을 이 식의 p에 그대로 대입해서는 안 된다.

Choice의 선택지가 ‘환불’과 ‘교환’뿐인데 문의 내용이 배송 주소 변경이라면 어느 쪽을 골라도 틀린다. 따라서 ‘해당 없음’ 선택지와 추가 정보 요청 경로를 설계하고, 이 경우를 별도로 시험한다. 허용 형식 안에 들어왔다는 이유만으로 실행 권한을 주면, 정형화가 오히려 오답을 정상 처리처럼 보이게 만든다.

검토 시점 기준 Jev는 조기 접근 단계이며 독립 재현과 공개 벤치마크가 부족하다. 공개 평가의 기준 답도 모델 간 합의여서 공통 편향을 포함할 수 있다. 한국어 성능·국내 서비스 지역·데이터 처리 조건은 도입 전에 확인해야 한다. 제공자가 말하는 확률의 신뢰성도 각자의 업무 데이터로 다시 검증해야 한다.

먼저 현재 LLM 워크플로를 작은 판단과 실행 코드로 나눠 비교하는 편이 좋다. 그다음 Jev를 같은 질문에 연결해 업무 정답률, 자동 처리 비율, 오판 비용을 함께 측정하면 작업 분해의 효과와 모델 교체의 효과를 구분할 수 있다.

참고 자료

Introducing System One Models & Jev (새 창)

· TypeSafe AI, 2026-09-15

TypeSafe AI documentation: Introduction (새 창)

Primitives (Questions) (새 창)

Confidence (새 창)

Workflow evals (새 창)