AI에게 문의를 보여주고 답변을 받는 일은 익숙하다. 그런데 프로그램을 만들다 보면 필요한 것은 긴 설명보다 “어느 경로로 처리할지”라는 작은 판단인 경우가 많다. Jev는 이런 질문에서 출발한 모델이다.
이 글에서는 Jev의 질문 유형과 출력 구조를 먼저 이해하고, 발표 수치를 읽는 방법과 실제 검토 기준까지 연결한다. 어려운 학습 알고리즘이나 API 설치보다 무엇을 맡길지 판단하는 데 집중한다.
작성 기준일: 2026년 9월 29일. 공식 자료 기반 소개이며 가격·접근 조건은 사용 전에 다시 확인해야 한다. [공식 발표]
- Jev는 코드가 사용할 작은 판단을 반환하는 모델이다.
- Noul·Choice·Score는 질문과 결과의 모양이 다르다.
- 출력 형식의 보장과 판단 정확도는 구분한다.
- 확신도·가격·속도는 조건과 검토 기준을 함께 읽는다.
1. Jev와 System One 모델은 무엇일까
고객 문의를 읽고 담당 부서를 정하는 프로그램을 생각해보자. 필요한 것은 긴 답변보다 어느 부서로 보낼지 판단한 결과다. 사람이 읽을 문장을 잘 만드는 능력과 코드가 소비할 판단을 안정적으로 내놓는 능력은 서로 다른 사용 목적을 가진다.
Jev는 TypeSafe AI가 소개한 판단형 모델이다. 개발자가 평가할 상태(state)와 질문을 주면, 정해진 형식의 판단 결과를 받는다. TypeSafe는 이런 사용 목적을 System One 모델이라고 부른다. 이는 회사가 제시한 모델 범주이며, 모든 AI 제품에 통용되는 인증 등급이나 표준을 뜻하지 않는다. [TypeSafe Introduction]
2026년 9월 15일 공식 발표에서는 Jev를 초기 접근(early access) 형태로 소개했다. 사용 가능 여부는 작성 시점의 콘솔과 안내에서 확인해야 한다. 이 글은 직접 사용 후기보다 공식 자료로 개념과 도입 기준을 정리하는 입문 글이다. [Jev 공식 발표]
문의 접수 담당자에게 “답장을 써줘” 대신 “이 문의가 어느 부서에 해당하는지 골라줘”라고 요청하는 방식에 가깝다. 다만 비유 속 담당자와 달리 모델은 제공한 상태와 질문에 의존한다. 누락된 정보까지 알고 있다고 가정하면 안 된다.
Jev가 선택한 결과를 보고 부서를 배정하거나 검토 대기열에 넣는 일은 주변 코드가 맡는다. 모델의 판단, 코드의 실행, 사용자의 권한을 분리하면 어디에서 오류가 났는지도 확인하기 쉬워진다.
2. Noul·Choice·Score는 어떻게 다를까
Jev의 기본 질문 유형은 세 가지다. 먼저 “이 문장은 긴급한가?”, “어느 부서에 해당하는가?”, “문제의 심각도는 어느 단계인가?”처럼 받고 싶은 결과의 모양을 정한다. 같은 문장을 읽더라도 질문마다 필요한 판단은 다르다. [Primitives]
| 유형 | 쉬운 질문 예시 | 주요 결과 | 읽을 때 주의할 점 |
|---|---|---|---|
| Noul | 문의에 긴급성이 드러나는가? | noul: 참이라고 판단하는 확률, 0~1 |
0.5는 중간 수준의 긴급도가 아니라 참·거짓이 비슷하게 예상된다는 뜻이다. |
| Choice | 기술·결제·일반 문의 중 어디에 속하는가? | choice, probabilities, confidence |
후보가 실제 입력을 충분히 포괄해야 한다. |
| Score | 업무에 미치는 영향은 어느 단계인가? | score, legend, probabilities, confidence |
단계의 설명과 순서를 개발자가 정의한다. |
Noul에는 별도의 confidence 필드가 없다. 이 값은 질문이 참일 확률로 읽는다. “좋은 고객인가?”처럼 판단 기준이 모호한 문장보다 “문의에 서비스 중단이 명시되어 있는가?”처럼 조건을 좁히는 편이 해석하기 쉽다. [Noul 문서]
Choice는 순서 없는 후보 중 하나를 선택한다. “기타” 후보가 필요한지 함께 검토하자. 현실의 문의가 기술과 결제에 동시에 걸칠 수 있다면, 가장 높은 후보 하나만 보지 않고 다른 후보의 확률도 확인할 수 있다. [Choice 문서]
Score는 설명을 붙인 순서 있는 단계에서 위치를 평가한다. 예를 들어 “화면만 어색함 → 일부 기능 실패지만 우회 가능 → 핵심 업무가 중단됨”처럼 정의한다. 세 단계면 위치는 0~2이고, 사이의 값도 나올 수 있다. 점수 1.4를 곧바로 “피해 사용자 70%”로 해석하면 안 된다. [Score 문서]
같은 상태를 평가하는 질문은 한 요청에서 함께 보낼 수 있다. 질문들은 같은 상태를 보며 독립적으로 평가된다. 앞 질문의 답이 뒤 질문의 입력으로 필요하다면, 그 의존성은 코드에서 따로 처리해야 한다.
아래는 질문 구조를 보여주는 요청 본문 예시다. 실제 API를 호출해 얻은 결과가 아니며, 한국어 입력의 품질도 자신의 데이터에서 확인할 항목이다. [Quick Start]
{
"model": "jev-latest",
"state": "로그인 후 화면이 멈춰 오늘 업무를 시작하지 못했습니다.",
"questions": {
"department": {
"type": "choice",
"instructions": "이 문의를 어느 부서로 전달해야 하는가?",
"criteria": {
"technical": "오류와 연동 문제",
"billing": "요금과 결제 문제",
"other": "위 두 부서에 해당하지 않는 문의"
}
},
"is_blocked": {
"type": "noul",
"instructions": "문의에 업무를 시작할 수 없다고 명시되어 있는가?"
}
}
}state는 평가 대상, instructions는 실제 질문, criteria는 선택 후보의 뜻이다. 이 예시에서 기대할 판단은 기술 문의 분류와 업무 중단 여부다. 실제 선택과 확률은 실행해 확인해야 하므로 숫자를 실측값처럼 제시하지 않는다.
3. LLM의 구조화된 출력과 무엇이 다를까
일반 언어 모델(LLM, Large Language Model)에도 정해진 구조로 결과를 받는 기능이 있다. 따라서 Jev의 차이를 “JSON이 가능하다” 한 가지로 설명하면 핵심을 놓친다. 살펴볼 것은 어떤 질문에 어떤 출력을 내놓도록 설계했는가다.
TypeSafe는 Jev를 자유로운 텍스트 생성 대신 작은 판단과 확률을 반환하도록 설계한 모델로 설명한다. 회사가 부르는 확률 보정 판단 강화학습(RLCD, Reinforcement Learning for Calibrated Decisions)도 이 목표에 맞춘 접근이다. 범용 모델을 모두 대체한다는 의미로 읽기보다, 코드가 반복해서 사용할 판단을 어디에 맡길지 판단하는 자료로 보자. [AI Primer]
| 확인할 것 | 생성 결과를 소비하는 작업 | Jev를 검토할 판단 작업 |
|---|---|---|
| 필요한 산출물 | 설명문·답장·코드처럼 새 내용을 작성 | 정해진 후보·기준에 따른 분류와 평가 |
| 후속 처리 | 필요한 구조·내용을 확인하고 사용 | 반환된 값과 분포를 읽어 코드에서 분기 |
| 공통 검증 | 내용이 맞는지, 권한에 맞는지 확인 | 판단이 맞는지, 권한에 맞는지 확인 |
예를 들어 담당 부서 값이 허용된 후보 중 하나여도, 문의를 잘못 이해해서 틀린 부서로 골랐을 수 있다. 출력 계약을 지킨다는 설명을 사실 정확도 100%나 업무 무오류 보장으로 확장하지 않는다.
확률 보정(calibration)은 많은 예측을 모아 모델이 준 확률과 실제 발생 비율의 관계를 살피는 개념이다. 공식 문서도 이 설명이 개별 답 하나의 정확성을 보장하는 것은 아니라고 밝힌다. [확률 보정 설명]
그래서 설계 예시는 문의 분류에는 Jev를 검토하고, 고객에게 보낼 자연스러운 답장 초안은 생성 모델을 검토하는 형태가 된다. 이는 역할 분담을 설명하는 제안이지, 두 도구를 연결해 성능이 향상됐다고 측정한 사례는 아니다.
4. 빠르고 저렴하다는 수치는 어떻게 읽을까
TypeSafe 홈페이지는 특정 System One 워크플로를 기준으로 193.6배 빠르고 444.6배 저렴하다는 수치를 제시한다. 이 값은 회사가 공개한 평가의 결과다. 내 문의 분류기에서도 같은 배수가 나온다고 가정하지 말고, 평가 대상과 비교 설정을 함께 읽어야 한다. [TypeSafe 발표 수치]
공식 평가 페이지는 여러 작은 질문과 코드 규칙으로 업무를 나누고, 강한 외부 모델들의 합의 응답을 참조하는 방법을 설명한다. 참조 응답에 가까운 정도를 평가한 결과를 독립적으로 판정된 모든 업무의 정답률과 동일하게 표현하면 안 된다. [워크플로 평가 방법]
| 확인 항목 | 왜 필요한가 | 직접 비교할 때 기록할 것 |
|---|---|---|
| 입력과 질문 | 문서 길이와 질문 구성이 다르면 작업 자체가 달라진다. | 같은 입력, 같은 선택 후보와 기준 |
| 비교 모델과 설정 | 추론 설정과 실행 방식이 결과에 영향을 준다. | 모델·버전·추론 설정·호출 방식 |
| 지연의 범위 | 모델 호출 시간과 전체 업무 완료 시간은 다르다. | 통신·조회·검토·재시도를 포함한 범위 |
| 실패와 재시도 | 평균 비용만 보면 실패한 입력이 가려질 수 있다. | 실패율·추가 호출·검토에 든 시간 |
작성일에 공식 홈페이지가 표시한 입력 가격은 10억 토큰당 42달러다. 단위를 바꾸면 100만 입력 토큰당 0.042달러다. 호출하기 전에는 실제 계정의 가격과 사용량 조건을 다시 확인하자. [공식 입력 가격]
요청당 입력 1,000토큰을 10,000번 사용한다고 가정하면 입력은 총 1,000만 토큰이다. 위 표시 단가로 계산한 입력 비용은 0.42달러다. 재시도, 다른 모델, 저장·서버 운영, 사람 검토에 드는 비용은 이 계산에 포함하지 않았다.
이 숫자는 입력 단가를 이해하는 산술 예시다. 자동화의 총비용을 판단하려면 틀린 분류를 고치는 시간과 검토 대기열의 양도 함께 측정해야 한다. 한 번의 호출이 빠르다는 이유만으로 전체 업무가 같은 배수로 빨라지는 것은 아니다.
5. 실제 자동화에 넣을 때 무엇을 검증할까
처음부터 고객 답장 발송이나 금전 처리를 연결하기보다, 담당 부서 추천을 기록하는 작은 작업으로 판단 품질을 확인해보자. 입력을 읽고 후보를 제안하는 단계와 실제로 업무를 변경하는 단계를 나누면 검토 기준을 만들기 쉽다.
Choice와 Score의 confidence는 반환된 확률 분포가 얼마나 한쪽에 모였는지 요약하는 값이다. 이를 “이 요청의 정답률”과 같은 값으로 읽지 않는다. 공식 문서가 제시하는 검토 경로 역시 도메인과 오류의 영향을 고려해 기준을 정하라는 안내다. [Confidence 문서]
| 단계 | 작은 시작 방법 | 확인할 결과 |
|---|---|---|
| 평가 데이터 | 이미 담당 부서를 알고 있는 비식별 문의를 준비한다. | 평범한 문의뿐 아니라 애매하거나 정보가 부족한 문의도 포함 |
| 분류 기록 | 추천 부서·확률 분포·검토 여부를 기록한다. | 어떤 후보끼리 혼동하는지 |
| 검토 기준 | 오류 비용에 맞는 검토 조건을 자체 평가로 정한다. | 검토를 줄였을 때 잘못 처리되는 문의의 변화 |
| 실패 처리 | 호출 오류·시간 초과·정책 충돌 시 처리를 중단하거나 검토로 보낸다. | 누락된 문의가 없이 다시 확인할 수 있는지 |
| 행동과 권한 | 분류 결과가 고객 연락이나 데이터 변경으로 이어지면 권한과 승인 절차를 별도로 둔다. | 높은 확신이 사용자 권한을 대신하지 않는지 |
판단 시각, 모델 식별자, 질문·기준의 버전, 반환된 값과 확률, 처리 경로, 검토 결과를 남긴다. 실제 문의에 개인정보가 있으면 모델에 보낼 내용과 로그에 남길 내용을 최소화한다. 이 목록은 이 글의 설계 제안이다.
자주 묻는 질문
Jev만으로 고객 답장까지 만들 수 있을까?
공식 기본 인터페이스는 선택·점수·참거짓 판단이다. 자연어 답장 작성이 필요하면 그 작업에 맞는 생성 도구를 따로 검토한다.
확신도가 높으면 사람 검토를 없애도 될까?
높은 확신은 권한이나 정확성 보장을 뜻하지 않는다. 실제 오류 사례, 작업 영향, 조직의 승인 기준으로 검토 범위를 정한다.
어디에서 시작할까?
공식 Playground와 Quick Start에서 접근 조건을 확인하고 작은 입력으로 질문의 모양부터 익힐 수 있다. 이 글에는 API를 직접 실행한 지연·정확도 측정값을 넣지 않았다. [시작하기]
6. 핵심 정리
Jev를 이해하는 핵심은 판단의 모양을 미리 정하고, 결과를 코드와 검토 절차에 연결하는 것이다. 도입을 검토한다면 제품 발표의 배수보다 자신의 작은 업무에서 어떤 질문과 기준이 필요한지 먼저 적어보자.
| 기억할 것 | 실무에서 확인할 것 |
|---|---|
| Noul·Choice·Score | 참거짓·후보 선택·순서 있는 평가 중 필요한 결과를 고른다. |
| 출력 계약 | 형식이 맞는지와 판단이 맞는지를 각각 확인한다. |
| 확률과 확신도 | 분포와 검토 조건을 읽고, 정답률이나 권한으로 바꾸어 해석하지 않는다. |
| 속도와 비용 | 같은 입력·설정·실패 처리 범위에서 비교한다. |
| 다음 단계 | 작은 분류 작업에서 실제 오류와 검토 결과를 기록한다. |