693 ／ 694
문장을 만들지 않고 확률로 판단하는 AI, Jev
대규모 언어 모델은 질문에 문장으로 답한다. TypeSafe AI가 공개한 Jev는 이 익숙한 방식을 버렸다. 미리 정한 선택지와 확률, 신뢰도 점수를 반환한다. 글쓰기나 코딩보다 분류, 점수화, 라우팅처럼 소프트웨어 안에서 반복되는 판단에 맞춘 모델이다.
처음 접하면 Jev도 챗GPT처럼 무엇이든 묻는 AI라고 생각하기 쉽다. 그러나 둘은 맡은 일이 다르다. 챗GPT나 Claude가 “답변을 써 주는 AI”에 가깝다면, Jev는 “정해진 보기 안에서 판단하는 AI”에 가깝다.
핵심만 먼저 정리하면 다음과 같다.
- Jev는 긴 답변을 쓰지 않는다. 정해진 선택지와 각 선택지의 확률을 반환한다.
- 결과 형식이 고정돼 있어 프로그램의 조건문과 연결하기 쉽다.
- 문장을 생성하지 않으므로 판단 중심 작업에서는 빠르고 저렴할 수 있다.
- 형식이 안전하다고 판단까지 항상 옳은 것은 아니다. 낮은 확신도의 결과를 다시 검토할 장치가 필요하다.
Jev는 무엇을 다르게 하는가
일반적인 LLM은 앞서 만든 토큰을 바탕으로 다음 토큰을 하나씩 생성한다. 결과가 JSON처럼 보여도 결국 문자열이므로, 프로그램에서 사용하려면 파싱하고 형식을 검사해야 한다. 모델이 약속한 스키마를 벗어날 가능성도 남는다.
Jev는 가능한 출력과 구조를 요청 전에 정한다. 예를 들어 고객 문의를 읽고 환불 요청, 배송 문제, 사용법 질문 가운데 하나를 고르거나, 각 범주에 해당할 확률을 돌려주는 식이다. 여러 질문의 답도 한 번의 질의에서 병렬로 계산한다. TypeSafe는 이런 모델을 ‘System One Model’이라고 부른다. 대니얼 카너먼이 구분한 빠르고 직관적인 ‘시스템 1’ 사고에서 이름을 가져왔다.
| 구분 | Jev | 일반적인 LLM |
|---|---|---|
| 주된 출력 | 미리 정한 값, 확률, 신뢰도 | 자유 형식의 문장과 코드 |
| 생성 방식 | 여러 판단을 병렬로 출력 | 토큰을 순차적으로 생성 |
| 잘 맞는 일 | 분류, 점수화, 라우팅, 검증 | 대화, 설명, 글쓰기, 코딩 |
| 프로그램 연결 | 정해진 스키마를 바로 사용 | 파싱과 형식 검증이 필요 |
이 차이를 ‘환각이 없다’는 말과 혼동하면 안 된다. Jev가 보장한다는 것은 정해진 타입을 벗어나지 않는다는 뜻이다. 모델이 선택한 답이 언제나 옳다는 뜻은 아니다. 판단 자체는 틀릴 수 있으므로 확률 임계값과 재검토 절차가 필요하다.
고객 문의 한 건으로 이해하기
온라인 쇼핑몰에 다음과 같은 문의가 들어왔다고 가정해 보자.
어제 도착한다고 해서 기다렸는데 아직 오지 않았어요. 내일까지 못 받으면 주문을 취소하고 싶습니다.
범용 LLM에 이 문장을 보내면 사과와 안내가 담긴 고객 응대 문장을 작성할 수 있다. 사람이 읽을 답변이 필요하다면 적절한 선택이다. 그러나 프로그램이 당장 알고 싶은 것이 “어느 부서로 보낼 것인가”라면 긴 문장은 오히려 다시 해석해야 할 대상이 된다.
Jev에는 선택지를 먼저 정해 줄 수 있다. 아래 값은 작동 방식을 설명하기 위한 가상 예시다.
{
"intent": {
"delivery_delay": 0.82,
"refund_request": 0.15,
"product_question": 0.03
},
"urgent": 0.74,
"needs_human_review": 0.61
}
프로그램은 이 결과를 곧바로 조건문에 넣을 수 있다. 배송 지연 확률이 높으므로 물류 상담 대기열로 보내고, 긴급도가 일정 기준을 넘었으므로 우선순위를 올리는 식이다. 마지막 답변 문장이 필요할 때만 범용 LLM을 호출하면 된다.
이때 Jev가 업무 규칙 전체를 대신하는 것은 아니다. 어떤 항목을 판단할지, 확률이 얼마일 때 자동 처리할지, 언제 사람에게 넘길지는 개발자와 업무 담당자가 정한다. Jev는 그 규칙 사이에서 자연어의 의미를 읽는 부분을 맡는다.
확률과 신뢰도는 어떻게 읽어야 하는가
Jev의 특징 가운데 하나는 판단과 함께 불확실성을 내놓는다는 점이다. TypeSafe는 RLCD(Reinforcement Learning for Calibrated Decisions)라는 학습 방법으로 확률을 보정했다고 설명한다.
‘보정됐다’는 말은 확률의 크기와 실제 정답률이 맞아야 한다는 뜻이다. 어떤 유형의 사례 100건에 모두 90%라는 확률을 줬다면 그중 약 90건이 맞아야 잘 보정된 모델이라고 할 수 있다. 한 사례의 답이 반드시 맞는다는 보장은 아니다. 여러 사례를 모아 봤을 때 90%라는 숫자가 과신이나 과소평가 없이 작동해야 한다는 의미다.
이 확률을 이용하면 처리 단계를 나눌 수 있다. 예를 들어 다음과 같은 기준을 둘 수 있다. 이 수치는 설명을 위한 예시이며, 실제 기준은 오류가 초래할 피해와 업무 특성에 맞춰 정해야 한다.
| 반환 확률 | 처리 예시 |
|---|---|
| 0.95 이상 | 위험이 낮은 작업을 자동 처리 |
| 0.70~0.95 | 더 큰 LLM으로 한 번 더 검토 |
| 0.70 미만 | 사람에게 보내 판단 보류 |
광고 문구의 분위기를 분류하는 일과 금융 거래를 사기로 판정하는 일에는 같은 기준을 쓸 수 없다. 잘못 분류해도 쉽게 되돌릴 수 있는 업무는 자동화 범위를 넓힐 수 있지만, 채용·금융·의료처럼 사람에게 큰 영향을 주는 결정은 별도의 검증과 책임 체계가 필요하다.
속도와 비용 수치는 조건과 함께 봐야 한다
TypeSafe가 공개한 Jev의 종단 간 응답 시간은 70~500밀리초다. 입력 가격은 100만 토큰당 0.042달러이며 출력 토큰은 따로 과금하지 않는다. 회사의 워크플로 평가에서는 최대 193.6배 빠르고 444.6배 저렴한 결과가 나왔다.
다만 이 수치를 모든 LLM 작업에 일반화할 수는 없다. 평가는 Jev에 맞는 판단 중심 워크플로를 대상으로 했고, TypeSafe의 모델 역량 팀이 구성했다. 회사도 해당 수치가 현실에서 얻을 수 있는 개선 폭의 상단에 가까울 수 있다고 밝혔다. 비교 기준은 GPT-6 Astra와 Fable 5.1이 낸 확률의 평균이었으며, 기존 LLM에는 TypeSafe가 만든 구조화 판단용 래퍼를 사용했다.
짧고 정보 밀도가 높은 입력을 쓴 시연도 Jev에 유리한 조건이었다. 공개된 속도는 서비스가 위치한 미국 서부에서 회사 구성원의 노트북으로 측정했다. 실제 도입 전에는 자신의 데이터와 네트워크 환경에서 정확도, 지연 시간, 비용을 다시 재야 한다.
글 37편을 0.7초 안에 검사한 실험
Every의 Mike Taylor는 Jev로 글 37편을 검사했다. 실제 글 27편과 의도적으로 AI 문체를 넣은 글 10편에 21개 기준을 적용했다. 같은 내용을 근거 없이 반복하는지, 억지로 양쪽 입장을 대칭시키는지, 단순한 요점을 지나치게 설명하는지 등을 물었다.
모두 777건의 판단이 0.7초 안에 끝났고, 추정 비용은 0.25센트였다. 코드 파일 찾기, 고객 지원 답변 평가, 위험한 에이전트 행동 표시 등을 포함한 11개 실험에서는 1,709건을 판단했으며 추정 비용은 1센트 미만이었다.
속도가 정확도를 대신하지는 않았다. 합성 문단 12개를 대상으로 Jev와 Fable 5.1을 비교한 별도 검사에서 Jev는 의도적으로 넣은 결함 7개 중 6개를 찾았고, Fable은 7개를 모두 찾았다. 문단당 처리 시간 중앙값은 각각 0.35초와 8.83초였다. Jev는 빠른 1차 검사에 유용했지만, 더 느린 모델이 잡은 문제 하나를 놓쳤다.
이 실험이 보여주는 활용법은 최종 결과를 한 번 심사하는 데 그치지 않는다. 에이전트가 문단이나 작업 단계를 끝낼 때마다 저렴한 검사를 반복하고, 문제가 표시된 부분만 큰 모델이나 사람이 다시 살피는 방식이다.
어디에 쓸 수 있는가
Jev가 맡기 좋은 일은 답의 범위를 미리 정할 수 있고 같은 판단을 자주 반복하는 업무다.
- 고객 문의의 의도와 긴급성을 분류하고 담당 부서로 보낸다.
- 검색 결과의 관련성을 점수화하고 RAG에 넣을 문서를 추린다.
- 요청의 난도와 위험을 판단해 사용할 LLM이나 에이전트를 고른다.
- 프롬프트 주입, 정책 위반, 민감 정보 노출, 도구 호출 오류를 검사한다.
- 코드와 글이 팀의 규칙을 따르는지 의미 단위로 확인한다.
- 체계적 문헌 고찰의 기준에 따라 논문을 포함하거나 제외한다.
- 리뷰와 상담 기록에서 구매 의도, 불만, 이탈 가능성 같은 특징을 추출한다.
제어 흐름은 코드가 맡고, 문맥을 읽어야 하는 좁은 판단만 Jev에 넘기는 구성이 핵심이다. 결과를 곧바로 실행하기보다 신뢰도에 따라 처리 경로를 나눌 수도 있다. 확률이 높으면 자동 처리하고, 중간이면 큰 LLM에 보내며, 낮거나 위험이 크면 사람이 검토하는 식이다.
반대로 문서 작성, 코드 생성, 긴 대화, 새로운 설계처럼 자유로운 표현과 긴 추론이 필요한 일에는 맞지 않는다. Jev와 범용 LLM은 경쟁 관계라기보다 역할이 다르다. Jev가 앞단에서 빠른 판단과 검사를 맡고, 생성과 깊은 추론이 필요할 때만 큰 모델을 호출하는 조합이 자연스럽다.
초심자는 Jev를 독립된 챗봇보다 AI 시스템의 부품으로 이해하는 편이 쉽다. 전형적인 흐름은 다음과 같다.
- 사용자의 요청이나 문서가 들어온다.
- Jev가 의도, 위험도, 난도처럼 미리 정한 항목을 판단한다.
- 일반 코드는 반환된 확률과 업무 규칙을 비교한다.
- 단순한 일은 자동 처리하고, 생성이 필요한 일은 LLM으로 보낸다.
- 불확실하거나 위험한 사례는 사람이 검토한다.
이 구조에서는 모든 요청을 가장 크고 비싼 모델에 보낼 필요가 없다. Jev가 앞에서 요청을 분류하고 필요한 경우에만 큰 모델을 호출한다. 여러 전문 에이전트 가운데 적합한 하나를 고르는 라우터, 검색한 문서 가운데 실제 질문과 관련된 자료를 추리는 재정렬기, 생성된 답변이 규칙을 지켰는지 확인하는 검사기로도 쓸 수 있다.
도입 전에 확인할 조건
반복적인 판단이 있다고 해서 모두 Jev에 맡길 수 있는 것은 아니다. 먼저 업무를 좁고 측정 가능한 단위로 나눠야 한다.
- 선택지와 판단 기준을 사전에 정의할 수 있는가
- 과거 사례나 사람이 판정한 정답 데이터로 정확도를 확인할 수 있는가
- 틀렸을 때 생기는 피해와 되돌리는 비용을 알고 있는가
- 낮은 확신도의 사례를 LLM이나 사람에게 넘길 경로가 있는가
- 실제 운영 데이터에서 확률 보정이 유지되는지 계속 측정할 수 있는가
예를 들어 “좋은 글인가”처럼 기준이 넓은 질문 하나를 던지는 것보다 “주장이 출처의 내용과 일치하는가”, “같은 요점을 반복하는가”, “정해진 금칙어가 문맥상 부적절하게 쓰였는가”처럼 판단을 나누는 편이 낫다. Every의 글쓰기 실험도 한 편의 글에 21개 질문을 따로 적용했다.
정확도를 평가할 때는 전체 정답률만 보면 부족하다. 자동 처리한 사례 중 틀린 비율, 사람이 검토하도록 보낸 사례의 비율, 분야나 문서 길이가 바뀌었을 때 성능이 떨어지는지도 함께 봐야 한다. 비용을 줄였더라도 잘못된 자동 판단을 바로잡는 일이 늘었다면 좋은 자동화라고 보기 어렵다.
아직은 얼리 액세스 단계다
Jev는 2026년 9월 공개된 초기 서비스다. 공개된 성능과 활용 사례의 상당수는 TypeSafe가 제시한 자료이거나 초기 사용자의 실험이다. 장기간 운영했을 때 확률이 얼마나 잘 보정되는지, 분야가 달라져도 정확도가 유지되는지, 가격이 지속 가능한지는 더 확인해야 한다.
그래도 방향은 선명하다. 지금까지는 모호한 판단이 필요하면 범용 LLM에 문장을 생성하게 한 뒤 결과를 다시 파싱하는 경우가 많았다. Jev는 그 가운데 반복적이고 범위가 좁은 판단만 떼어 별도의 모델로 처리한다. 중요한 질문은 “큰 모델보다 좋은가”가 아니라 “이 단계에서 문장이 정말 필요한가”에 가깝다.
출처
- TypeSafe AI, Introducing System One Models & Jev · GeekNews 경유
- TypeSafe AI, Example use cases · GeekNews 경유
- Mike Taylor, Mini-Vibe Check: TypeSafe’s Jev Judged Everything I’ve Written in 0.7 Seconds · GeekNews 경유
- 임대준, “문장 생성 버렸다”…판단 전용 AI ‘제브’에 개발자 반응 폭발, AI타임스
- kyu_ios_dev, Jev가 뭐냐, Velog