Jev 공개: 글을 쓰지 않고 판단만 돌려주는 모델, 어디에 붙일까

고객 메일을 읽고 담당 부서를 고르는 일에 긴 답변이 꼭 필요할까요? 프로그램이 원하는 것은 ‘이 문의는 결제팀에 전달하는 것이 적절해 보입니다’라는 문장보다, 바로 분기 처리할 수 있는 부서 코드와 판단의 불확실성일 때가 많습니다. Jev는 이런 좁고 반복적인 판단을 소프트웨어 안에 넣기 위해 만들어진 모델입니다.

TypeSafe AI는 2026년 9월 15일 Jev를 첫 System One 모델로 공개했습니다. 자유로운 글 생성을 포기하는 대신, 미리 정한 선택지와 점수처럼 코드가 직접 사용할 수 있는 값을 빠르게 돌려주는 접근입니다. 이 글에서는 출력 구조, 실제 업무에 넣는 방식, 가격과 속도 수치의 조건을 차례로 살펴봅니다. 공식 발표

챗봇의 답변과 프로그램의 판단은 무엇이 다를까

사람이 읽는 설명은 맥락에 맞게 표현을 바꿀 수 있어야 합니다. 반면 자동화 프로그램은 ‘결제’, ‘기술 지원’, ‘기타’처럼 허용된 값이 필요합니다. 출력이 문장이라면 그 안에서 값을 추출하고, 형식이 맞는지 검사하고, 예상 밖의 답이 왔을 때 처리하는 단계가 필요해집니다.

Jev는 입력 상태를 state로 받고, 그 상태에 대해 형식이 정해진 질문을 평가합니다. 공식 문서는 세 종류의 질문을 제공합니다. 여러 질문을 한 호출에 넣을 수 있고, 각 질문은 같은 상태를 바탕으로 독립적으로 처리됩니다. TypeSafe 문서

유형	질문의 형태	반환 정보
Choice	정해진 목록 중 무엇인가?	선택 결과, 선택지별 확률, confidence
Score	정한 기준에서 몇 점인가?	점수, 단계별 확률, confidence
Noul	이 진술이 참인가?	0~1 범위의 noul 값

예를 들어 ‘담당 부서’를 Choice로, ‘불만 강도’를 Score로, ‘즉시 확인이 필요한가’를 Noul로 나눌 수 있습니다. 중요한 점은 질문마다 하나의 판단만 맡기는 것입니다. 담당 부서와 환불 여부와 답장 내용을 한꺼번에 정하라고 하면 서로 다른 업무 규칙이 한 질문 안에 섞입니다.

메일 분류에 넣는다면 이런 흐름이 된다

다음은 이해를 돕기 위한 가상의 설계입니다. 실제 Jev 실행 결과나 제품의 기본 정책이 아닙니다. ‘어제부터 결제가 두 번 처리됐는데 아직 답변을 못 받았습니다’라는 문의가 들어왔다고 가정해 보겠습니다.

1. 입력 준비: 메일 본문과 판단에 필요한 주문 상태를 모으고, 담당 부서의 역할과 분류 기준을 명시합니다.
2. 판단 분리: 문의 유형, 긴급성, 추가 정보 부족 여부를 각각 묻습니다.
3. 결과 해석: 확신이 충분한 건은 해당 검토 대기열로 보내고, 애매한 건은 사람이 확인할 목록에 둡니다.
4. 후속 처리: 답장 작성은 별도 생성 모델이나 템플릿이 담당하고, 환불 같은 실제 실행은 정해진 업무 절차가 처리합니다.

이 구성에서는 Jev가 메일을 분류해도 그 자체로 돈이 환불되지는 않습니다. 모델이 내린 판단과 시스템이 수행하는 행동을 분리했기 때문입니다. 분류 기준이 바뀌면 질문과 후속 규칙을 각각 조정할 수 있고, 오류가 났을 때 어느 단계에서 잘못됐는지도 추적하기 쉽습니다. TypeSafe의 패턴 문서도 의도 분류, 여러 점수의 결합, 신뢰도에 따른 경로 분리를 설명합니다. 설계 패턴

선택지 설계도 성능의 일부입니다. 실제로 기술 문제인데 목록에 ‘결제’와 ‘배송’만 있으면, 모델이 정해진 형식을 잘 지켜도 유용한 분류를 하기 어렵습니다. ‘기타’나 ‘정보 부족’ 경로를 두고, 한 메일에 두 가지 요청이 섞인 경우도 별도 사례로 확인해야 합니다.

‘타입 오류가 없다’와 ‘판단이 틀리지 않는다’는 별개

TypeSafe는 Jev의 출력이 정의한 스키마를 벗어나지 않는다고 설명합니다. 이 주장은 허용하지 않은 값이나 잘못된 자료형이 나오는 문제에 관한 것입니다. 결제 문의를 기술 지원으로 잘못 분류하는 것처럼, 형식은 맞지만 내용은 틀린 판단까지 사라진다는 뜻은 아닙니다. ‘환각이 없다’는 표현도 이런 출력 방식의 맥락에서 읽어야 합니다. 타입 안전성에 대한 설명

비유하자면, 시험 답안에 보기 밖의 문자를 적지 못하게 만드는 것과 정답을 고르는 것은 다른 문제입니다. 형식 보장은 프로그램이 결과를 처리하기 쉽게 만들어 주지만, 업무상 맞는 답인지 확인하는 검증을 대신하지는 않습니다.

또한 Choice·Score의 confidence는 선택지별 확률 분포에서 계산한 요약값입니다. 모든 답에 동일한 신뢰도 필드가 붙는 것은 아니며, Noul에는 별도의 confidence가 없습니다. 신뢰도 0.9라는 숫자를 특정 한 건이 90% 확률로 맞는다는 보증처럼 사용하는 것도 피해야 합니다. 확률과 신뢰도의 차이

가령 부서 선택 확률이 한쪽에 몰린 경우와 두 부서에 비슷하게 나뉜 경우를 다르게 처리할 수 있습니다. 그러나 임계값은 업무별 데이터로 정해야 합니다. 알림의 우선순위를 한 단계 틀리는 것과 고객 요청을 아예 누락하는 것은 오류 비용이 다릅니다. 같은 신뢰도라도 후속 행동은 달라져야 합니다.

속도와 가격, 큰 배수보다 요청의 조건을 보자

공식 발표가 제시한 응답 시간은 70~500ms이며, 홈페이지의 193.6배 빠르고 444.6배 저렴하다는 수치는 회사 자체 워크플로 평가에서 나온 값입니다. 비교 기준에는 다른 대형 모델들의 답을 사용했고, 평가 흐름은 자사 팀이 만들었습니다. 회사도 이 배수가 실제 개선 폭 중 큰 쪽에 해당할 수 있다고 설명합니다. 평가 조건과 제한

따라서 이 수치를 모든 챗봇 요청의 대체 성능으로 읽기는 어렵습니다. 여러 좁은 판단을 반복하는 업무인지, 긴 설명이 필요한 업무인지에 따라 비교 대상부터 달라집니다. 실제 서비스에서는 입력 전처리, 네트워크, 재시도와 후속 시스템 처리 시간도 사용자 대기 시간에 포함됩니다.

모델 문서의 입력 가격은 100만 토큰당 0.042달러이며 출력 토큰은 무료입니다. 가정 계산: 질문을 포함한 총 입력이 요청당 2,000토큰이고 하루 10만 건을 처리한다면, 입력은 2억 토큰이므로 모델 입력 요금은 하루 8.40달러입니다. 실제 청구 토큰, 재시도, 번역과 전처리 비용 등은 별도로 확인해야 합니다. 모델·가격 문서

비용이 낮더라도 잘못 분류한 문의를 사람이 모두 다시 검토하면 자동화의 효과는 작아질 수 있습니다. API 단가에 더해 자동 처리 가능한 비율, 검토에 걸리는 시간, 놓친 중요 문의 수를 같이 봐야 하는 이유입니다.

한국어 입력과 컨텍스트 제한에서 주의할 점

확인 당시 공개 버전은 Jev 1.13입니다. 요청 전체 한도는 64k 토큰이지만, state와 가장 긴 질문 하나를 합친 길이에는 32k 토큰 제한이 별도로 있습니다. 텍스트·JSON 객체·텍스트 배열을 받으며 이미지·음성·영상은 직접 입력하지 못합니다. 영어가 주 학습 언어이고, 한국어를 포함한 다른 언어는 같은 수준의 정확도를 보장하지 않는다고 안내합니다. 입력·언어·길이 제한

한국어 업무에서는 상품명과 약어, 주어가 빠진 문장, 이전 대화를 가리키는 표현이 문제를 만들 수 있습니다. ‘그건 취소 말고 전에 걸로 해주세요’처럼 현재 문장만으로 판단할 수 없는 요청에는 이전 주문 상태가 필요합니다. 모델을 바꾸는 것보다 필요한 맥락을 추가하는 일이 먼저일 수도 있습니다.

원문과 번역본을 비교하는 실험은 가능하지만, 번역이 반드시 정확도를 높인다고 가정해서는 안 됩니다. 번역 과정에서 날짜·부정 표현·제품명이 바뀔 수도 있기 때문입니다. 두 입력 방식의 분류 오류를 따로 기록하고, 번역 비용과 지연까지 포함해 비교해야 합니다.

처음 시험할 때는 작은 표본으로 오류 유형부터 찾는다

초기에는 사람이 답을 정해 둔 소규모 사례로 질문이 명확한지 확인할 수 있습니다. 다만 20~50건 정도의 탐색만으로 운영 정확도나 드문 사고의 확률을 보장할 수는 없습니다. 실제 분포를 반영한 별도 검증 자료와 애매한 사례, 중요한 예외를 추가해야 합니다.

확인 항목	기록할 내용
분류 품질	유형별 정답·오답, 중요 문의를 놓친 사례
불확실성 처리	검토 대기열로 보낸 비율, 높은 신뢰도에서 발생한 오류
처리 시간	일반적인 응답 시간과 느린 요청, 재시도 횟수
운영 비용	모델 요금, 전처리 비용, 사람의 검토 시간
재현 조건	사용한 모델 버전, 질문 기준, 입력 자료의 구성

Jev는 긴 보고서나 자연스러운 답장을 작성할 모델을 찾는 사람보다, 분류·평가·알림 여부 같은 판단을 제품 안에 반복해서 넣으려는 개발자에게 더 직접적인 소식입니다. 도입의 핵심은 모델 하나에 모든 결정을 맡기는 것이 아니라, 판단을 작게 나누고 그 결과를 코드와 업무 규칙으로 연결하는 데 있습니다.

자료 확인: 2026년 9월 18일. 속도·비용 배수는 개발사 자체 평가이며 독립 실측이 아닙니다. 메일 처리 흐름과 비용 계산은 설명용 예시입니다. 공개 접근은 얼리 액세스·대기 명단 안내를 확인해야 합니다.