Jev AI 사용법: API 연동과 Choice·Score·Noul 활용법 2026
목차
Jev AI 사용법은 ChatGPT처럼 긴 글을 생성하도록 요청하는 방식과 다릅니다. Jev는 입력된 상태를 읽고, 미리 정한 선택지·점수·참거짓 확률 형태의 판단을 반환하는 TypeSafe AI의 개발자용 모델입니다. 따라서 고객 문의 분류, 담당 부서 라우팅, 긴급성 판정, 검색 결과 평가처럼 프로그램의 다음 동작을 결정해야 하는 작업에 적합합니다.
2026년 9월 기준 Jev는 TypeSafe AI의 첫 번째 System One 모델이며 얼리 액세스로 제공되고 있습니다. 공식 문서에 따르면 상태(state)와 타입이 지정된 질문을 보내면 코드에서 사용할 수 있는 구조화된 답을 돌려줍니다. 사용 전에는 공식 문서와 콘솔에서 현재 접근 조건, 모델명, 요금 및 API 정책을 확인해야 합니다.
Jev AI란 무엇인가
생성형 AI와 다른 출력 구조
일반적인 대규모 언어 모델(LLM)은 질문에 자연어 답변을 만듭니다. 반면 Jev는 가능한 결과를 먼저 정해 둔 뒤 그중 무엇이 맞는지 판단합니다. 예를 들어 고객 메시지에 대해 배송 문의인지 환불 문의인지 선택하고, Choice와 Score에서는 결과별 확률 분포와 confidence를 함께 반환하는 방식입니다. Noul은 진술이 참일 확률을 0에서 1 사이 값으로 반환합니다.
JSON 모드와의 차이
JSON 모드는 생성형 모델의 출력 형식을 JSON으로 유도하는 기능입니다. 애플리케이션에서는 여전히 응답 파싱과 값 검증이 필요할 수 있습니다. Jev는 질문의 타입과 가능한 결과를 요청에 정의하고, 그 범위에 맞는 구조화된 답을 반환하도록 설계됐습니다. 다만 형식이 안전하더라도 업무 분류가 항상 옳다는 뜻은 아니므로 실제 데이터로 정확도와 오류 비용을 검증해야 합니다.
Jev는 글쓰기 도구라기보다 비정형 입력을 코드가 사용할 수 있는 타입 지정 판단으로 바꾸는 계층입니다. 결과를 자동 실행에 연결할 때는 확률과 confidence만 믿지 말고 서비스별 검증 규칙과 사람 검토 절차를 함께 두어야 합니다.
Jev AI 사용법: 세 가지 질문 유형
Noul은 참일 확률을 판단합니다
Noul은 특정 진술이 참인지 묻는 질문 유형입니다. 예를 들어 ‘이 문의에 결제 사기 의심 정황이 있는가?’, ‘답변에 개인정보가 포함됐는가?’처럼 예·아니오로 정의할 수 있는 탐지 작업에 사용할 수 있습니다. 반환값은 불리언이 아니라 해당 진술이 참일 확률을 나타내는 0~1 사이의 noul 값입니다. Noul에는 Choice와 Score처럼 별도의 confidence 필드가 없습니다.
법률·의료·보안 조치처럼 위험도가 높은 업무에서는 Noul 값을 곧바로 확정 판정으로 사용하지 말고 사람 검토나 추가 확인 절차를 두는 것이 안전합니다.
Choice는 미리 정한 선택지 중 하나를 고릅니다
Choice는 배송·환불·계정·기술지원처럼 미리 만든 카테고리에서 하나를 선택합니다. 지원팀 자동 배정, 이메일 분류, 상품 문의 라우팅, 다음 도구 선택에 활용할 수 있습니다. 선택지 이름이 겹치거나 범위가 중복되면 결과가 흔들릴 수 있으므로 각 항목의 기준을 짧고 서로 겹치지 않게 정의해야 합니다.
Choice 응답에는 선택된 값, 선택지별 probabilities, confidence가 포함됩니다. 목록이 모든 입력을 포괄하지 못할 수 있다면 other나 none_of_the_above 같은 선택지를 별도로 검토할 수 있습니다.
Score는 순서가 있는 등급을 매깁니다
Score는 낮음·보통·높음처럼 단계가 있는 평가에 적합합니다. 문의의 긴급성, 고객 불만 수준, 문서의 관련도, 리드의 구매 가능성처럼 연속적인 판단을 여러 구간으로 나눌 때 사용할 수 있습니다. 공식 문서에 따르면 Score는 정의한 수준을 기준으로 위치를 반환하며, 경우에 따라 두 수준 사이의 값이 나올 수 있습니다.
점수 구간의 의미를 팀 내부에서 먼저 합의하고 실제 사례로 기준과 임계값을 조정해야 합니다. Score 응답에는 score, legend, probabilities, confidence가 포함됩니다.
- Noul: 위험 여부, 개인정보 포함 여부, 긴급 문의 여부에 대한 참일 확률
- Choice: 의도 분류, 담당 부서 배정, 다음 도구 선택
- Score: 품질·관련도·긴급성·우선순위 평가
API로 Jev 시작하기
API 키와 기본 요청
공식 빠른 시작 문서는 콘솔에서 API 키를 발급한 뒤 https://api.typesafe.ai/v1/systemone에 Bearer 인증으로 POST 요청을 보내는 흐름을 안내합니다. 기본 모델 식별자로는 jev-latest가 예시에 사용됩니다. 계정 접근이나 얼리 액세스 조건은 바뀔 수 있으므로 실제 연동 전 콘솔과 API Reference를 다시 확인해야 합니다.
curl -X POST https://api.typesafe.ai/v1/systemone \
-H 'Authorization: Bearer $TYPESAFE_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"state": "고객이 결제 오류로 환불을 요청했습니다.",
"model": "jev-latest",
"questions": {
"intent": {
"type": "choice",
"instructions": "고객의 주요 요청은 무엇인가?",
"criteria": {
"refund": "환불 요청",
"technical": "기술 문제 문의",
"information": "단순 정보 문의"
}
},
"urgency": {
"type": "noul",
"instructions": "고객 메시지가 긴급성을 나타내는가?"
},
"frustration": {
"type": "score",
"instructions": "고객의 불만 수준은 어느 정도인가?",
"criteria": [
"차분함",
"불편하지만 예의 바름",
"강한 불만 또는 공격적 표현"
]
}
}
}'공식 예시처럼 하나의 요청에서 Noul·Choice·Score를 함께 보낼 수 있습니다. 같은 state를 기준으로 각 질문이 독립적으로 평가되므로, 한 요청에서 여러 판단을 묶어 결과를 받은 뒤 애플리케이션 코드에서 다음 동작을 조합할 수 있습니다.
응답을 코드에서 사용하는 방법
응답의 필드명은 질문 유형에 따라 다릅니다. Choice는 choice와 confidence를 읽고, Score는 score와 confidence를 읽으며, Noul은 noul 값을 읽습니다. 아래 코드는 특정 SDK의 실제 응답 객체를 그대로 재현한 것이 아니라, 공식 응답 구조를 애플리케이션 분기에서 사용하는 개념 예시입니다.
const answer = response.answers.intent;
if (answer.confidence < 0.85) {
return sendToHumanReview(response);
}
if (answer.choice === 'refund') {
return routeToRefundTeam(response);
}
return routeToGeneralSupport(response);Noul을 사용할 때는 confidence가 아니라 response.answers.urgency.noul처럼 참일 확률을 읽고, 그 값의 의미에 맞는 임계값을 별도로 정해야 합니다. 실제 요청 형식·SDK·인증 방식은 공식 API Reference와 계정별 안내를 기준으로 작성해야 합니다.
실전 활용법과 자동화 흐름
문의 분류와 담당자 배정
먼저 state에 고객 메시지, 이전 대화, 계정 상태처럼 판단에 필요한 정보를 담습니다. 그다음 Choice로 문의 유형을 고르고 Score로 긴급성이나 불만 수준을 평가합니다. Noul은 ‘긴급성을 나타내는가?’처럼 참일 확률 자체가 필요한 질문에 사용합니다. 마지막으로 코드가 결과를 읽어 일반 문의는 자동 배정하고, 확률이나 confidence가 낮거나 위험 신호가 있는 건은 검토 대기열로 보냅니다.
- 판단할 업무를 한 문장으로 정의합니다.
- 결과 유형과 선택지 또는 점수 구간을 설계합니다.
- 대표적인 정상 사례와 애매한 사례로 테스트합니다.
- 질문 유형에 맞는 확률 또는 confidence 임계값을 정해 자동 처리·보류·사람 검토를 분기합니다.
- 오분류 사례를 기록하고 선택지와 규칙을 다시 조정합니다.
AI 에이전트와 검증 단계
Jev는 에이전트가 사용할 도구를 고르는 중간 판단에도 활용할 수 있습니다. 예를 들어 문의가 환불인지 배송인지 먼저 Choice로 결정한 뒤 해당 도구를 호출하도록 만들 수 있습니다. 또 다른 생성형 AI가 만든 답변을 발송하기 전에 정책 위반 여부, 개인정보 포함 여부, 담당자 검토 필요성을 Noul이나 Choice로 검사하는 가드레일로 사용할 수 있습니다.
단, 분류 결과가 맞더라도 API 호출 실패, 중복 요청, 오래된 상태 데이터, 권한 오류는 별도로 발생할 수 있습니다. 요청 ID, 재시도 정책, 실행 전 최종 검증, 수동 취소 절차를 함께 설계해야 안정적인 자동화가 됩니다.
속도·비용·확률을 해석하는 법
공식 수치는 비교 조건을 확인해야 합니다
TypeSafe AI는 공식 블로그에서 Jev의 입력 토큰 가격을 100만 토큰당 0.042달러, 즉 10억 입력 토큰당 42달러로 제시하고 출력 토큰은 무료라고 설명합니다. 또한 공식 비교 자료에서 Jev의 종단 간 응답 시간을 70~500밀리초로 제시합니다. 이 수치는 TypeSafe가 공개한 기준이며, 실제 지연 시간은 네트워크·입력 길이·질문 수·서비스 상태에 따라 달라질 수 있습니다.
공식 블로그는 성능 비교가 미국 서부 지역 노트북에서 수행된 평가를 바탕으로 하며, 193.6배 빠르고 444.6배 저렴하다는 홈페이지 수치는 특정 workflow 평가에서 나온 것이라고 설명합니다. 따라서 이를 모든 업무와 모든 모델에 적용되는 일반적인 보장 수치로 해석하면 안 됩니다.
확률과 confidence는 자동화의 경계선으로 사용합니다
Choice와 Score의 confidence는 probabilities 분포가 얼마나 한 결과에 집중됐는지를 요약한 값입니다. Noul은 별도의 confidence 없이 참일 확률을 반환합니다. 어느 값이든 높다고 해서 모든 상황에서 정답이라는 뜻은 아닙니다. 운영 데이터에서 실제 정답률을 확인한 뒤 자동 처리 기준을 정해야 합니다.
예를 들어 낮은 confidence나 불명확한 Noul 확률은 즉시 실패로 처리하기보다 보류하고, 중간 구간은 사람 검토로 보내며, 높은 값만 자동 실행하는 세 구간 정책을 출발점으로 삼을 수 있습니다. 실제 기준은 업무 위험도와 오분류 비용에 맞춰 조정해야 합니다.
| 판단 신호 | 권장 처리 | 확인할 내용 |
|---|---|---|
| 높은 confidence 또는 명확한 확률 | 자동 처리 후보 | 오작동 비용과 예외 규칙 |
| 중간 confidence 또는 0.5에 가까운 Noul | 사람 검토 | 반복되는 애매한 사례 |
| 낮은 confidence 또는 정보 부족 | 보류·재질문 | 입력 정보와 질문 정의의 부족 여부 |
임계값은 모델 설명만으로 정하지 말고 실제 업무의 오분류 비용으로 결정해야 합니다. 환불·보안·계정 잠금처럼 되돌리기 어려운 동작은 더 엄격한 검토 기준과 사용자 확인이 필요합니다.
누구에게 적합하고 무엇이 부족한가
- 매일 많은 문의·문서를 일정한 기준으로 분류하는 개발팀에 적합합니다.
- 자동화 흐름에서 다음 단계 선택이나 점수화만 AI에 맡기고 싶은 조직에 적합합니다.
- 글, 보고서, 이메일 초안을 직접 생성해야 한다면 생성형 AI가 더 적합할 수 있습니다.
- 결과 선택지나 점수 기준을 미리 정의하기 어렵거나 창의적인 문장이 필요한 작업에는 한계가 있습니다.
- 얼리 액세스 단계에서는 접근 승인, API 문서, 요금, 모델 동작이 바뀔 수 있습니다.
개인정보나 민감한 고객 데이터를 입력할 때는 TypeSafe AI의 개인정보 처리방침과 계약 문서를 먼저 검토해야 합니다. 현재 개인정보 처리방침은 서비스 이용 중 프롬프트·데이터·지시문 등 입력을 수집한다고 설명하면서 해당 입력으로 AI 모델을 학습하거나 미세 조정하지 않는다고 밝힙니다. 동시에 서비스 제공업체에 데이터가 공개될 수 있고, 미국에서 서비스가 호스팅된다고 설명하므로 테스트 단계에서는 실제 식별정보를 제거한 샘플을 사용하는 편이 안전합니다.
처음 시작할 때 흔한 실수
첫째, Jev에게 ‘적절한 답변을 작성해 달라’고 요청하는 것입니다. Jev의 강점은 문장 생성이 아니라 결정이므로 ‘환불·배송·계정 중 하나를 선택하라’처럼 출력 공간을 제한해야 합니다. 둘째, 선택지에 ‘기타’를 무분별하게 넣는 것입니다. 기타가 지나치게 많으면 분류 기준이 흐려질 수 있으므로 실제 운영 로그를 보고 선택지를 재설계해야 합니다.
셋째, confidence나 확률만 보고 즉시 외부 시스템을 실행하는 것입니다. API 호출 실패, 중복 요청, 오래된 상태 데이터, 권한 오류는 모델과 별개로 발생할 수 있습니다. 요청 ID, 재시도 정책, 실행 전 최종 검증, 수동 취소 절차를 함께 설계해야 안정적인 자동화가 됩니다.
자주 묻는 질문
Q. Jev는 ChatGPT처럼 무료 채팅으로 사용할 수 있나요?
Jev는 일반 소비자용 채팅 서비스보다 소프트웨어 내부의 판단과 API 연동에 초점을 둔 모델입니다. 공식 문서에는 콘솔 Playground와 API 사용 방법이 안내되어 있지만, 계정 접근 및 얼리 액세스 조건은 현재 콘솔과 공식 공지를 확인해야 합니다.
Q. Jev는 어떤 업무에 가장 잘 맞나요?
문의 분류, 담당 부서 라우팅, 위험 신호 탐지, 우선순위 점수화, AI 답변 검증처럼 결과 형식을 미리 정할 수 있는 업무에 잘 맞습니다.
Q. Jev가 반환한 확률이나 confidence를 그대로 믿어도 되나요?
아닙니다. 확률과 confidence는 자동화 경계를 설계하는 신호로 활용해야 하며, 실제 운영 데이터의 정답률과 업무상 피해 비용을 함께 평가해야 합니다. 고위험 작업은 사용자 확인이나 사람 검토를 추가해야 합니다.
Q. Jev로 이메일이나 보고서를 작성할 수 있나요?
Jev의 핵심 목적은 글 생성이 아니라 구조화된 판단입니다. 이메일 문구나 보고서 초안이 필요하다면 생성형 AI를 사용하고, Jev는 분류·검증·승인 여부 판단에 연결하는 구성이 적절합니다.
