TypeSafe AI의 Jev는 사람에게 읽힐 문장을 만드는 모델이 아니라, 소프트웨어 내부에서 빠르고 구조화된 판단을 내리도록 설계된 첫 System One 모델이다. TypeSafe AI는 2026년 9월 15일 Jev를 얼리 액세스로 공개했다. 이 회사는 전 OpenAI 연구원 디오구 알메이다(Diogo Almeida)가 에릭 가프니(Erik Gafni), 사샤 셩(Sasha Sheng)과 함께 세운 샌프란시스코 기반 스타트업이다. 216

핵심은 ‘텍스트 생성’이 아니라 ‘결정 반환’

일반적인 대규모 언어 모델(LLM)은 다음에 올 텍스트 토큰을 순서대로 생성한다. 그래서 설명문 작성, 기획, 코드 작성, 대화처럼 개방형 작업에 유연하다. 반면 애플리케이션이 LLM의 결과를 자동으로 처리하려면 생성된 문장을 해석하거나, JSON 형식을 검증하는 단계를 거쳐야 하는 경우가 많다.

Jev는 이보다 범위가 좁고 명확한 일을 겨냥한다. 애플리케이션이 문자열·JSON 객체·텍스트 배열 형태의 상태(state) 와 타입이 정해진 질문을 보내면, 모델은 질문별로 구조화된 답을 돌려준다. TypeSafe의 API 문서는 이를 ‘상태를 타입화된 질문 맵에 대해 평가하고 질문마다 하나의 구조화된 답을 반환하는 방식’이라고 설명한다. 17

지원하는 결정 형식은 다음과 같다.

• 불리언(Boolean): 예를 들어 특정 명령어를 실행해도 안전한지처럼, 어떤 명제가 참일 확률을 추정한다.
• 선택(Choice): 개발자가 미리 제시한 후보 가운데 하나를 고른다.
• 점수(Score): 정렬된 기준표나 수치 척도에 따라 대상을 평가한다.

따라서 Jev는 챗봇보다는 라우팅, 분류, 검색 결과 필터링, 위험 점수화, AI 에이전트 가드레일 같은 작업을 위한 ‘결정 프리미티브’에 가깝다. TypeSafe 문서는 모델 라우팅, 의미 기반 검색, 실행 로그 분류, 다른 AI의 출력 점검 등을 활용 사례로 든다. 18

‘System One’이라는 이름의 뜻

System One은 심리학자 대니얼 카너먼(Daniel Kahneman)이 구분한 빠르고 직관적인 ‘시스템 1’ 사고와, 느리고 숙고적인 ‘시스템 2’ 사고에서 가져온 표현이다. TypeSafe는 이를 개방형 추론이나 글쓰기보다 빠르고 범위가 한정된 판단에 집중하는 모델군을 설명하는 데 쓴다. 16

이는 Jev가 범용 추론 문제를 해결했다는 뜻은 아니다. 관련 상태와 명확히 정의된 판단 문제를 입력하면, 문단이 아니라 확률 분포를 포함한 제한된 결과를 돌려주는 인터페이스에 최적화됐다는 의미다.

제약된 출력이 자동화에 유리한 이유

Jev에서는 애플리케이션이 출력 형태를 사전에 정의한다. 선택형 질문이라면 허용되는 답도 애플리케이션이 지정한다. 프로그램이 정해진 값만 받아야 할 때, 모델이 예상 밖 필드를 추가하거나 존재하지 않는 도구 이름을 만들거나 자유 형식 설명문을 내놓는 통합 문제를 줄일 수 있다.

다만 이는 구조적 보장이지, 답의 진실성을 보장하는 것은 아니다. 제약된 결정 모델도 허용된 선택지 중 잘못된 답을 고를 수 있고, 문맥을 오해하거나 실제 업무에서 잘 보정되지 않은 확신도를 제시할 수 있다. Vercel도 스키마 준수는 답의 구조에 관한 것이며, 의미적 정확성은 별도 평가가 필요하다고 명시한다.

운영 환경에서는 확신도 임계값을 신뢰성의 자동 증명이 아니라 검증해야 할 정책 변수로 다루는 편이 바람직하다. 실무적으로는 확신도가 높고 위험이 낮은 판단만 자동 처리하고, 애매하거나 영향이 큰 사례는 LLM·규칙 엔진·사람 검토로 넘기는 방식이 가능하다.

학습과 보정: TypeSafe의 설명

TypeSafe는 Jev를 전적으로 합성 데이터로 학습했고, 보정된 의사결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions·RLCD) 을 사용했다고 밝힌다. 목표는 사람이 선호하는 문장을 만드는 것이 아니라, 모델이 제시한 확률이 실제 정답률에 더 가깝게 맞도록 하는 데 있다는 설명이다.

보정이 제대로 작동한다면 자동화에서 특히 유용할 수 있다. 가령 0.9의 확률이 실제로 의미 있는 검토 임계값을 설정할 근거가 될 수 있기 때문이다. 다만 RLCD는 폭넓은 독립 검증을 통해 확립된 방법론으로 공개된 상태가 아니며, 제공된 자료에는 Jev의 보정 성능·적대적 입력에 대한 견고성·도메인별 정확도를 포괄적으로 감사한 제3자 결과도 없다. 따라서 이런 주장은 실제 도입하려는 조직의 데이터와 판단 정책으로 직접 평가할 필요가 있다.

가격, 컨텍스트 길이, 속도

TypeSafe는 Jev 1.13의 가격을 입력 토큰 100만 개당 0.042달러(10억 개당 42달러)로 제시하며, 출력 토큰은 무료다. 이 요율 기준으로 5달러는 세금이나 계정별 계약 조건을 제외하면 입력 토큰 약 1억 1,900만 개를 처리할 수 있다. 모델 문서상 요청당 컨텍스트 길이는 6만 4,000토큰이며, 상태에는 최대 3만 2,000토큰과 가장 긴 질문의 토큰 수가 포함된다.

회사와 초기 보도는 작업에 따라 지연 시간이 약 70~500밀리초 수준이라고 언급한다. 다만 실제 지연 시간은 요청 크기, 질문 설계, 리전, 서비스 상태에 따라 달라진다. 이 수치는 도입 검토의 출발점으로는 쓸 수 있지만, 자체 부하 테스트를 대체하지는 않는다.

Vercel AI Gateway에서의 초기 도입

Vercel은 AI Gateway에 Jev를 추가했고, 실험적 평가 API를 통해 typesafe-ai/jev 모델을 호출할 수 있도록 했다.

Vercel에 따르면 Jev는 AI Gateway 출시 후 24시간 내 유료 팀의 약 13%에 도달했다. 이는 같은 기간 이전의 어떤 모델 출시보다도 두 배 이상 많은 유료 팀이 사용한 수치다. 개발자들의 높은 초기 관심과 실험을 보여주는 신호이지만, 장기 유지율·대규모 운영 신뢰성·모든 작업에서의 우수성을 입증하는 자료는 아니다.

초기에는 명령 실행 안전성 분류와 이메일 분류 실험도 보고됐다. 이는 Jev가 겨냥하는 범위가 명확한 작업의 예시로 참고할 수 있지만, 독립적이고 통제된 벤치마크를 대신할 수는 없다. Jev와 LLM을 비교하려는 팀은 대표 데이터셋에서 정확도, 확률 보정, 오류의 심각도, 지연 시간, 전체 워크플로 비용을 함께 점검해야 한다.

Jev가 잘 맞는 곳과 맞지 않는 곳

애플리케이션이 필요한 판단을 이미 알고 있고, 답의 범위를 명확히 정의할 수 있다면 Jev가 적합할 수 있다. 예를 들면 다음과 같다.

• 에이전트가 계속 진행할지, 재시도할지, 추가 질문을 할지, 중단할지 선택하기
• 명령어나 도구 호출을 분류해 안전성 검토로 보내기
• 긴급도·관련성·위험도를 점수화하기
• 결정론적 코드가 미리 추출한 후보 값 중 하나를 선택하기
• 더 비싼 모델 호출 전에 대량의 텍스트를 필터링하거나 라벨링하기

반대로 개방형 글쓰기, 설명, 브레인스토밍, 코드 생성, 폭넓은 계획 수립, 사전 선언된 스키마로 표현할 수 없는 답이 필요한 제품이라면 Jev는 LLM의 대체재가 아니다. Jev 적용 품질은 질문 문구, 입력 선택, 후보 옵션, 임계값, 테스트 전략에도 크게 좌우된다. TypeSafe 역시 조건을 정확히 명시하고, 가능하면 컨텍스트를 먼저 필터링한 뒤 보내며, 통합을 충분히 시험하라고 권고한다.

지원 입력과 향후 모달리티

현재 Jev는 문자열, JSON 객체, 텍스트 배열 등 텍스트 기반 상태만 입력으로 받는다. 이미지·오디오·비디오는 지원하지 않는다. TypeSafe는 해당 모달리티를 ‘아직 지원하지 않음’으로 표기했지만, 제공된 문서에는 멀티모달 모델의 공개 출시 일정이 제시되지 않았다.

정리: ‘모든 AI가 글을 쓸 필요는 없다’는 제안

Jev의 주장은 모든 AI가 언어 생성을 그만둬야 한다는 것이 아니다. 많은 소프트웨어 워크플로에는 애초에 언어 생성이 필요하지 않을 수 있다는 것이다. 범위가 정해진 분류·라우팅·정책 판단이라면, 타입화된 확률 응답이 챗봇식 답변보다 통합하기 쉽고 비용이 낮으며 더 빠르게 다음 동작으로 이어질 수 있다.

그러나 구조화된 출력은 출력 형식 오류를 줄일 뿐, 판단 오류를 없애지는 않는다. Jev의 실질적 가치는 정확도와 확신도 추정이 독립적으로 검증된 도메인별 업무에서도 유지되는지에 달려 있다. 그때까지 Jev는 LLM 전반을 대체하는 모델이라기보다, 잘 정의된 소프트웨어 의사결정에 쓰일 가능성이 있는 특화 도구로 보는 편이 적절하다.

TypeSafe AI의 Jev는 사람에게 읽힐 문장을 만드는 모델이 아니라, 소프트웨어 내부에서 빠르고 구조화된 판단을 내리도록 설계된 첫 System One 모델이다. TypeSafe AI는 2026년 9월 15일 Jev를 얼리 액세스로 공개했다. 이 회사는 전 OpenAI 연구원 디오구 알메이다(Diogo Almeida)가 에릭 가프니(Erik Gafni), 사샤 셩(Sasha Sheng)과 함께 세운 샌프란시스코 기반 스타트업이다. 216

핵심은 ‘텍스트 생성’이 아니라 ‘결정 반환’

일반적인 대규모 언어 모델(LLM)은 다음에 올 텍스트 토큰을 순서대로 생성한다. 그래서 설명문 작성, 기획, 코드 작성, 대화처럼 개방형 작업에 유연하다. 반면 애플리케이션이 LLM의 결과를 자동으로 처리하려면 생성된 문장을 해석하거나, JSON 형식을 검증하는 단계를 거쳐야 하는 경우가 많다.

Jev는 이보다 범위가 좁고 명확한 일을 겨냥한다. 애플리케이션이 문자열·JSON 객체·텍스트 배열 형태의 상태(state) 와 타입이 정해진 질문을 보내면, 모델은 질문별로 구조화된 답을 돌려준다. TypeSafe의 API 문서는 이를 ‘상태를 타입화된 질문 맵에 대해 평가하고 질문마다 하나의 구조화된 답을 반환하는 방식’이라고 설명한다. 17

지원하는 결정 형식은 다음과 같다.

• 불리언(Boolean): 예를 들어 특정 명령어를 실행해도 안전한지처럼, 어떤 명제가 참일 확률을 추정한다.
• 선택(Choice): 개발자가 미리 제시한 후보 가운데 하나를 고른다.
• 점수(Score): 정렬된 기준표나 수치 척도에 따라 대상을 평가한다.

따라서 Jev는 챗봇보다는 라우팅, 분류, 검색 결과 필터링, 위험 점수화, AI 에이전트 가드레일 같은 작업을 위한 ‘결정 프리미티브’에 가깝다. TypeSafe 문서는 모델 라우팅, 의미 기반 검색, 실행 로그 분류, 다른 AI의 출력 점검 등을 활용 사례로 든다. 18

‘System One’이라는 이름의 뜻

System One은 심리학자 대니얼 카너먼(Daniel Kahneman)이 구분한 빠르고 직관적인 ‘시스템 1’ 사고와, 느리고 숙고적인 ‘시스템 2’ 사고에서 가져온 표현이다. TypeSafe는 이를 개방형 추론이나 글쓰기보다 빠르고 범위가 한정된 판단에 집중하는 모델군을 설명하는 데 쓴다. 16

이는 Jev가 범용 추론 문제를 해결했다는 뜻은 아니다. 관련 상태와 명확히 정의된 판단 문제를 입력하면, 문단이 아니라 확률 분포를 포함한 제한된 결과를 돌려주는 인터페이스에 최적화됐다는 의미다.

제약된 출력이 자동화에 유리한 이유

Jev에서는 애플리케이션이 출력 형태를 사전에 정의한다. 선택형 질문이라면 허용되는 답도 애플리케이션이 지정한다. 프로그램이 정해진 값만 받아야 할 때, 모델이 예상 밖 필드를 추가하거나 존재하지 않는 도구 이름을 만들거나 자유 형식 설명문을 내놓는 통합 문제를 줄일 수 있다.

다만 이는 구조적 보장이지, 답의 진실성을 보장하는 것은 아니다. 제약된 결정 모델도 허용된 선택지 중 잘못된 답을 고를 수 있고, 문맥을 오해하거나 실제 업무에서 잘 보정되지 않은 확신도를 제시할 수 있다. Vercel도 스키마 준수는 답의 구조에 관한 것이며, 의미적 정확성은 별도 평가가 필요하다고 명시한다.

운영 환경에서는 확신도 임계값을 신뢰성의 자동 증명이 아니라 검증해야 할 정책 변수로 다루는 편이 바람직하다. 실무적으로는 확신도가 높고 위험이 낮은 판단만 자동 처리하고, 애매하거나 영향이 큰 사례는 LLM·규칙 엔진·사람 검토로 넘기는 방식이 가능하다.

학습과 보정: TypeSafe의 설명

TypeSafe는 Jev를 전적으로 합성 데이터로 학습했고, 보정된 의사결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions·RLCD) 을 사용했다고 밝힌다. 목표는 사람이 선호하는 문장을 만드는 것이 아니라, 모델이 제시한 확률이 실제 정답률에 더 가깝게 맞도록 하는 데 있다는 설명이다.

보정이 제대로 작동한다면 자동화에서 특히 유용할 수 있다. 가령 0.9의 확률이 실제로 의미 있는 검토 임계값을 설정할 근거가 될 수 있기 때문이다. 다만 RLCD는 폭넓은 독립 검증을 통해 확립된 방법론으로 공개된 상태가 아니며, 제공된 자료에는 Jev의 보정 성능·적대적 입력에 대한 견고성·도메인별 정확도를 포괄적으로 감사한 제3자 결과도 없다. 따라서 이런 주장은 실제 도입하려는 조직의 데이터와 판단 정책으로 직접 평가할 필요가 있다.

가격, 컨텍스트 길이, 속도

TypeSafe는 Jev 1.13의 가격을 입력 토큰 100만 개당 0.042달러(10억 개당 42달러)로 제시하며, 출력 토큰은 무료다. 이 요율 기준으로 5달러는 세금이나 계정별 계약 조건을 제외하면 입력 토큰 약 1억 1,900만 개를 처리할 수 있다. 모델 문서상 요청당 컨텍스트 길이는 6만 4,000토큰이며, 상태에는 최대 3만 2,000토큰과 가장 긴 질문의 토큰 수가 포함된다.

회사와 초기 보도는 작업에 따라 지연 시간이 약 70~500밀리초 수준이라고 언급한다. 다만 실제 지연 시간은 요청 크기, 질문 설계, 리전, 서비스 상태에 따라 달라진다. 이 수치는 도입 검토의 출발점으로는 쓸 수 있지만, 자체 부하 테스트를 대체하지는 않는다.

Vercel AI Gateway에서의 초기 도입

Vercel은 AI Gateway에 Jev를 추가했고, 실험적 평가 API를 통해 typesafe-ai/jev 모델을 호출할 수 있도록 했다.

Vercel에 따르면 Jev는 AI Gateway 출시 후 24시간 내 유료 팀의 약 13%에 도달했다. 이는 같은 기간 이전의 어떤 모델 출시보다도 두 배 이상 많은 유료 팀이 사용한 수치다. 개발자들의 높은 초기 관심과 실험을 보여주는 신호이지만, 장기 유지율·대규모 운영 신뢰성·모든 작업에서의 우수성을 입증하는 자료는 아니다.

초기에는 명령 실행 안전성 분류와 이메일 분류 실험도 보고됐다. 이는 Jev가 겨냥하는 범위가 명확한 작업의 예시로 참고할 수 있지만, 독립적이고 통제된 벤치마크를 대신할 수는 없다. Jev와 LLM을 비교하려는 팀은 대표 데이터셋에서 정확도, 확률 보정, 오류의 심각도, 지연 시간, 전체 워크플로 비용을 함께 점검해야 한다.

Jev가 잘 맞는 곳과 맞지 않는 곳

애플리케이션이 필요한 판단을 이미 알고 있고, 답의 범위를 명확히 정의할 수 있다면 Jev가 적합할 수 있다. 예를 들면 다음과 같다.

• 에이전트가 계속 진행할지, 재시도할지, 추가 질문을 할지, 중단할지 선택하기
• 명령어나 도구 호출을 분류해 안전성 검토로 보내기
• 긴급도·관련성·위험도를 점수화하기
• 결정론적 코드가 미리 추출한 후보 값 중 하나를 선택하기
• 더 비싼 모델 호출 전에 대량의 텍스트를 필터링하거나 라벨링하기

반대로 개방형 글쓰기, 설명, 브레인스토밍, 코드 생성, 폭넓은 계획 수립, 사전 선언된 스키마로 표현할 수 없는 답이 필요한 제품이라면 Jev는 LLM의 대체재가 아니다. Jev 적용 품질은 질문 문구, 입력 선택, 후보 옵션, 임계값, 테스트 전략에도 크게 좌우된다. TypeSafe 역시 조건을 정확히 명시하고, 가능하면 컨텍스트를 먼저 필터링한 뒤 보내며, 통합을 충분히 시험하라고 권고한다.

지원 입력과 향후 모달리티

현재 Jev는 문자열, JSON 객체, 텍스트 배열 등 텍스트 기반 상태만 입력으로 받는다. 이미지·오디오·비디오는 지원하지 않는다. TypeSafe는 해당 모달리티를 ‘아직 지원하지 않음’으로 표기했지만, 제공된 문서에는 멀티모달 모델의 공개 출시 일정이 제시되지 않았다.

정리: ‘모든 AI가 글을 쓸 필요는 없다’는 제안

Jev의 주장은 모든 AI가 언어 생성을 그만둬야 한다는 것이 아니다. 많은 소프트웨어 워크플로에는 애초에 언어 생성이 필요하지 않을 수 있다는 것이다. 범위가 정해진 분류·라우팅·정책 판단이라면, 타입화된 확률 응답이 챗봇식 답변보다 통합하기 쉽고 비용이 낮으며 더 빠르게 다음 동작으로 이어질 수 있다.

그러나 구조화된 출력은 출력 형식 오류를 줄일 뿐, 판단 오류를 없애지는 않는다. Jev의 실질적 가치는 정확도와 확신도 추정이 독립적으로 검증된 도메인별 업무에서도 유지되는지에 달려 있다. 그때까지 Jev는 LLM 전반을 대체하는 모델이라기보다, 잘 정의된 소프트웨어 의사결정에 쓰일 가능성이 있는 특화 도구로 보는 편이 적절하다.