TypeSafe Jev — 문장 대신 타입이 있는 판단과 확률을 반환하는 AI
TypeSafe 홈페이지와 Jev 출시 글, 개발 문서, 자체 평가를 대조한다. Choice·Score·Noul의 차이, confidence의 의미, 타입 안전성과 판단 정확도의 구분, 속도·비용 비교의 조건을 정리한다.
TL;DR
- Jev는 자유형 답변을 쓰는 대신 소프트웨어가 바로 사용할 판단값과 확률을 반환하는 모델이다. 상태와 좁게 정의한 질문을 입력하고 결과의 조합과 행동 결정은 코드에 남긴다. TypeSafe는 이를 System One Models라는 제품 범주로 소개한다.
- Choice는 선택지, Score는 단계별 평가, Noul은 예·아니오의 확률을 다룬다. Choice와 Score의 confidence는 반환된 확률분포에서 계산한 통계량이다. Noul에는 별도의 confidence 필드가 없으며 어떤 값도 개별 정답을 보증하지 않는다.
- 홈페이지의 무환각 주장은 출시 글에서 스키마 일치와 타입 오류 없음으로 설명된다. 정의한 선택지 밖의 형식을 만들지 않는 것과 올바른 선택지를 고르는 것은 다르다. 의미 판단이 틀릴 가능성과 자체 업무에서의 검증은 남는다.
- 입력 가격은 100만 토큰당 0.042달러로 안내된다. 큰 속도·비용 개선 배수는 회사가 만든 네 워크플로 평가의 결과이며 비교 조건이 있다. 초기 접근 단계의 제품을 모든 LLM 작업에서 같은 성능을 내는 대체재로 읽어서는 안 된다.
소프트웨어가 소비할 판단을 직접 반환한다
TypeSafe가 홈페이지에서 소개하는 Jev는 사람에게 읽힐 문장을 쓰는 모델보다 코드 안의 판단 함수를 목표로 한다. 문서와 현재 상태를 입력하고 미리 정의한 질문에 대한 타입이 있는 값을 받는다. 자유형 답변에서 필요한 내용을 추출하는 단계를 줄이고 프로그램이 그 값을 분기·정렬·라우팅에 사용할 수 있게 하는 방식이다. 2026년 9월 15일 공개된 출시 글은 Jev를 첫 공개 System One 모델이자 초기 접근 제품으로 소개한다.[1][2]
공식 문서는 질문을 작고 독립적인 판단으로 나누라고 권한다. 하나의 복잡한 종합평가를 맡기기보다 시장 크기와 기술 가능성, 차별성 같은 요소를 따로 묻고 코드에서 가중치와 규칙으로 결합하는 식이다. 여러 질문은 같은 상태를 기준으로 병렬 평가하며 서로의 답을 차례로 읽는 대화 흐름과 구분된다. 따라서 긴 추론이나 코드·설명문 생성 전체를 맡기는 범용 채팅 모델의 대체재보다는 기존 소프트웨어에 넣는 제한된 판단 기능에 가깝다.[3][4]
Choice·Score·Noul은 서로 다른 질문에 답한다
Choice는 미리 정한 후보 중 하나를 고르는 질문이다. 고객 문의를 배송·환불·결제 중 어느 팀에 보낼지 정하는 경우처럼 순서 없는 범주를 다룬다. 선택한 값과 함께 각 후보의 확률분포, confidence가 돌아온다. 프로그램이 사용할 수 있는 답의 공간을 먼저 정한다는 점이 자유로운 문자열 응답과의 차이다.[3]
Score는 설명이 붙은 순서 있는 단계에 따라 평가한다. 예를 들어 버그의 심각도를 여러 수준으로 나누면 각 수준의 확률과 그 가중평균인 점수를 반환하므로 결과가 정수일 필요는 없다. 공식 예제의 1단계 확률 0.70과 2단계 확률 0.30은 점수 1.30이 된다. 단순히 숫자만 붙이는 대신 단계별 의미를 구별해 작성해야 하며 관련 예시를 추가했더니 confidence가 높아졌다는 사실만으로 정확도가 좋아졌다고 볼 수는 없다.[6]
Noul은 하나의 예·아니오 질문에 대해 예일 확률을 0부터 1 사이로 반환한다. 별도의 confidence 값은 제공하지 않는다. 어떤 역량이 있는지 묻는 Noul의 0.5는 중간 수준의 역량을 뜻하지 않고 예와 아니오에 비슷한 확률을 둔다는 의미다. 역량의 정도를 재려면 Score를 사용하거나 질문을 다시 정의해야 하므로, 세 타입을 모두 같은 숫자 점수처럼 다루면 안 된다.[7]
confidence는 정답률 인증서가 아니다
Choice와 Score의 confidence는 이미 반환한 확률분포의 모양에서 계산한 통계량이다. 모델이 별도로 작성한 자기평가 문장과 구분된다. 확률이 한 선택지나 단계에 몰리면 높아지고 여러 곳에 퍼지면 낮아지는 식이다. 따라서 가장 큰 확률값과 confidence를 자동으로 같은 수치라고 가정할 수 없다. 문서는 전체 확률분포도 제공하므로 업무에 더 적합한 불확실성 지표를 사용할 여지를 남긴다.[5]
TypeSafe가 말하는 보정(calibration)은 여러 예측을 모았을 때의 확률과 결과 사이 관계에 관한 목표다. 공식 문서도 개별 답이 맞는다는 보장은 아니라고 명시한다. 높은 확신에서는 자동 처리하고 중간에서는 확인을 요구하며 낮으면 사람이나 다른 시스템에 넘기는 흐름을 구성할 수 있지만 그 임계값은 자체 데이터와 잘못된 행동의 비용을 보고 검증해야 한다. 모델이 반환한 높은 confidence만으로 송금이나 삭제 같은 업무의 권한 검사와 확인 절차가 대체되는 것은 아니다.[4][5]
타입 안전성과 의미상의 오류를 구분한다
홈페이지는 무환각을 강조하지만 출시 글의 구체적인 근거는 스키마 일치의 보장이다. 회사는 가능한 출력의 구조와 값을 미리 정해 타입 오류가 발생하지 않도록 했으며 그래프의 오류율 0%도 경험적으로 측정한 값이 아니라 이 구조적 보장에서 가져왔다고 설명한다. 정의 밖의 필드나 선택지를 생성하지 않는 것과 업무상 올바른 답을 고르는 것은 별개의 문제다. 형식이 완벽한 분류 결과도 의미상으로 틀릴 수 있다는 구분을 유지해야 한다.[1][2]
TypeSafe는 새 모델 구조와 병렬 샘플러, Reinforcement Learning for Calibrated Decisions(RLCD)를 이 접근의 기반으로 제시한다. 출시 글은 토큰을 순서대로 생성하는 방식과 달리 여러 출력 확률을 병렬로 구하는 데 초점을 맞춘다. 이는 기존 모델에서 JSON 모드를 켜는 것과 다른 모델·학습 설계를 지향한다는 회사의 설명이다. 다만 모델의 전체 구조와 학습 절차를 독립적으로 재현해 확인한 결과는 아니며 이 노트에서도 Jev API를 직접 실행해 검증한 것은 아니다.[2]
속도와 가격 배수에는 워크플로의 조건이 붙는다
홈페이지의 193.6배 빠르고 444.6배 저렴하다는 비교는 네 가지 System One 형태의 워크플로 평가에서 나온 수치다. 공개 평가 페이지는 보안 사고 판단, 에이전트 실행 기록 검토, 청구서 처리, 고객지원 과제를 같은 비중으로 집계한다. 정답 기준은 사람이나 실제 업무 결과 대신 높은 추론 설정의 GPT-6 Astra와 Claude Fable 5.1 응답을 평균낸 참조값이다. 비교 대상 모델은 제공사의 기본 추론 설정으로 실행했다. 따라서 이 평가의 정확도는 그 참조 판단과의 일치도를 뜻하며 실제 업무 성공률과 자동으로 같지는 않다.[2][8]
회사 스스로도 개선 배수가 현실에서 얻을 효과의 높은 쪽에 해당할 것으로 예상한다고 제한한다. 과제는 내부 팀이 만들었고 비교 LLM도 확률을 포함한 구조화된 결정을 반환하도록 래퍼를 사용했으므로, 확률 없이 간단한 결론만 받는 비교와는 비용·시간 조건이 다르다. 짧고 밀도 높은 입력을 쓴 별도의 나란히 보기 데모 역시 Jev에 유리한 입력이라고 명시한다. 서부 해안의 노트북에서 측정한 응답 시간과 서로 다른 추론 설정을 모든 지역·입력 길이·업무의 보장 성능으로 확대해서는 안 된다.[2]
작은 판단을 많이 호출하는 업무가 적용 출발점이다
가격은 입력 10억 토큰당 42달러, 즉 100만 토큰당 0.042달러로 안내되며 출시 글에서는 출력에 별도 요금을 받지 않는다고 설명한다. 하지만 실제 업무의 총비용은 질문 구성과 입력 길이, 호출 수, 재검토·재시도에 따라 달라진다. 회사도 가격이 보조금 없이 장기간 지속 가능한지는 시간으로 입증해야 한다고 인정한다. 낮은 표시 단가와 특정 업무 전체의 비용 우위는 따로 확인해야 한다.[1][2]
공식 데모와 문서는 분류·라우팅·점수화·규칙 판단을 코드로 결합하는 사용에 초점을 맞춘다. Doom 데모는 구조화된 게임 상태를 입력한 사례다. 화면 이미지를 직접 해석한 실험은 아니다. 긴 숙고를 요구하는 과제는 작은 질문으로 나누거나 다른 추론 모델과 함께 처리하는 쪽이 제품의 성격에 맞는다. 첫 적용에서는 예상 답을 아는 자체 사례로 판단 정확도와 확률 보정, 지연·비용, 사람에게 넘기는 비율을 함께 확인하는 편이 타당하다. 핵심은 LLM을 무조건 교체하는 것이 아니라, 반복되는 의미 판단 중 어떤 부분을 명확한 타입과 코드의 통제 아래 옮길 수 있는지 찾는 데 있다.[2][3][4]
참고 자료
[1] https://typesafe.ai — TypeSafe AI — Jev and System One Models
[2] https://typesafe.ai/blog/introducing-system-one-models-and-jev — Introducing System One Models & Jev — Diogo Almeida
[3] https://docs.typesafe.ai/introduction — Introduction — TypeSafe AI Docs
[4] https://docs.typesafe.ai/concepts/system-one — System One — TypeSafe AI Docs
[5] https://docs.typesafe.ai/confidence — Confidence — TypeSafe AI Docs
[6] https://docs.typesafe.ai/primitives/score — Score — TypeSafe AI Docs
[7] https://docs.typesafe.ai/primitives/noul — Noul — TypeSafe AI Docs
[8] https://evals.typesafe.ai — Workflow evals — TypeSafe AI
