월요일 아침, 고객 문의함에 환불 요청 메일이 여러 건 도착했다고 가정해 보겠습니다. 담당자는 각 문의를 어느 팀에 배정할지, 추가적인 환불 검토가 필요한지 빠르게 판단해야 합니다.
일반적인 채팅형 AI에 문의 내용을 전달하면 상황을 설명하거나 답변 초안을 작성할 수 있습니다. 하지만 답변 문장에 포함된 “90% 확신합니다”라는 표현을 그대로 자동화 조건으로 활용하기는 어렵습니다. 문장으로 생성된 숫자와 프로그램이 처리하도록 설계된 확률 데이터는 구분해야 하기 때문입니다.
TypeSafe의 Jev는 이런 상황에서 활용할 수 있는 판단 중심 API입니다. 개발자가 미리 정의한 선택지에 대해 확률을 반환하는 방식으로, 예를 들어 담당 부서를 결제 91%, 계정 6%, 기타 3%처럼 구분할 수 있습니다(이 수치는 설명을 위한 가상의 예시입니다). 핵심 차이는 AI가 자연스러운 문장을 작성하는가가 아니라, 시스템이 판단 결과를 구조화된 데이터로 받을 수 있는가에 있습니다.
이 글에서는 Jev가 채팅형 AI와 어떻게 다른지, 요청이 어떤 구조로 이루어지는지, 세 가지 질문 유형과 확률의 의미는 무엇인지 순서대로 설명합니다. 마지막에는 2025~2026년에 화제가 된 이유와 실무 도입 시 판단 기준을 정리합니다.
채팅 AI와 판단 AI — 개념부터#
LLM(대형 언어 모델)은 일반적으로 다음에 올 토큰을 예측하는 방식으로 텍스트를 생성합니다. ChatGPT와 같은 채팅형 서비스에서는 이 기능을 활용해 설명, 요약, 코드 또는 답변 초안을 작성합니다.
반면 TypeSafe는 System One의 Jev를 ‘구조화된 판단과 확률을 반환하는 API’로 소개합니다. 개발자는 판단에 필요한 정보와 질문의 유형을 정의하고, 애플리케이션은 모델이 반환한 결과를 후속 처리에 활용합니다. 공식 문서는 이 차이를 “생성된 텍스트가 아니라 typed decision과 probability를 반환한다”라고 설명합니다. 이는 TypeSafe가 설명하는 제품의 접근 방식이며, 모든 LLM이 구조화된 출력을 지원하지 않는다는 뜻은 아닙니다.
| 채팅형 LLM | Jev (System One) | |
|---|---|---|
| 주 출력 | 문장, 코드, 설명 | 선택·점수·예/아니오 + 확률 |
| 보기 | 질문 형태에 따라 자유로운 텍스트를 생성할 수 있음 | 개발자가 API에 정의 |
| 전형적 용도 | 초안, 요약, 대화 | 문의 분류, 담당 부서 배정, 승인 전 검토 |
두 방식은 경쟁 제품으로만 볼 필요가 없습니다. Jev가 문의 담당 부서와 긴급도를 분류하고, 별도의 LLM이나 템플릿이 고객에게 보낼 문장을 만드는 것처럼 함께 사용할 수도 있습니다.
Jev API의 두 가지 핵심 요소: state와 questions#
API(Application Programming Interface)는 프로그램이 다른 프로그램과 데이터를 주고받는 데 사용하는 인터페이스입니다. 공개된 Jev 문서의 요청 방식에서는 판단에 필요한 배경 정보인 state와 판단 질문인 questions를 구분합니다. 호출은 클라이언트 SDK 또는 POST /v1/systemone 엔드포인트로 이루어집니다.
state에는 고객 문의, 티켓 정보, 로그처럼 여러 질문이 공통으로 참고할 정보를 담습니다. questions에는 “담당 부서는 어디인가?”, “환불 검토가 필요한가?”, “불만 수준은 어느 정도인가?”처럼 각 판단 항목을 정의합니다.
따라서 하나의 배경 정보를 바탕으로 여러 판단을 요청할 수 있습니다. 이 구조를 이해하면 자연어 답변 생성과 업무 분류용 판단 API가 어떤 점에서 다른지 보다 쉽게 파악할 수 있습니다.
TypeSafe가 공개한 요금 안내에서는 입력과 출력의 과금 방식을 구분합니다. 2026년 10월 18일 기준 공식 Models(새 창) 문서는 입력 토큰당 과금하며 출력 토큰은 무료라고 안내합니다. 다만 가격과 무료 제공 범위는 변경될 수 있으므로, 실제 도입 비용은 공식 요금표를 기준으로 확인해야 합니다. 특히 입력 데이터 길이와 질문 수에 따른 비용 및 응답 시간을 사전에 측정하는 것이 좋습니다.
요청·응답 예시 (개념용)#
아래 JSON은 state와 questions의 역할을 설명하기 위해 단순화한 개념 예시입니다. 실제 응답 필드, 모델 버전, 요청 스키마와 일치한다고 보장하지 않으므로 실행용 코드로 사용하지 마세요. 구현 전에는 공식 API 문서와 SDK 예제를 확인해야 합니다. 참고로 공식 문서의 예시 응답은 choice: "billing", score: 1.4, noul: 0.95처럼 질문 유형별 단일 값 형태입니다.
요청:
{
"model": "jev-1.14.0",
"state": "Subject: Payment failed. Customer asks refund within 24h of charge.",
"questions": {
"route": {
"type": "choice",
"criteria": {
"billing": "Payment, invoice, refund policy",
"account": "Login, profile, credentials",
"other": "Anything else"
}
},
"needs_refund_review": {
"type": "noul",
"question": "Does this message request a refund?"
},
"upset_level": {
"type": "score",
"criteria": {
"0": "Calm, factual tone",
"1": "Frustrated or impatient",
"2": "Very upset, threatening churn"
}
}
}
}응답(개념용 — 필드명은 문서와 다를 수 있음):
{
"answers": {
"route": {
"billing": 0.91,
"account": 0.06,
"other": 0.03
},
"needs_refund_review": {
"yes": 0.88,
"no": 0.12
},
"upset_level": {
"0": 0.08,
"1": 0.67,
"2": 0.25
}
}
}애플리케이션은 반환된 판단 결과에 조건문을 적용할 수 있습니다. 예를 들어 담당 부서가 billing일 확률이 85% 이상이면 자동으로 배정하고, 그보다 낮으면 담당자가 검토하도록 설계할 수 있습니다. 환불 검토 여부나 고객 불만 수준에도 별도의 기준을 적용할 수 있습니다.
여기서 85%는 설명을 위한 임의의 기준입니다. 실제 업무에서는 잘못 분류했을 때의 영향, 검증 데이터, 사람의 재검토 절차를 고려해 임계값을 정해야 합니다.
질문 타입 세 가지 (Primitives)#
TypeSafe는 Jev의 질문 유형을 Choice, Score, Noul로 구분합니다. 각각 선택지 분류, 점수 평가, 예·아니오 판단에 해당합니다.
Choice — 선택지 중 분류: 결제·계정·기타처럼 가능한 항목을 정의하고, 입력 내용이 어디에 해당하는지 판단할 때 사용합니다.
Score — 기준에 따른 점수 평가: 차분함부터 강한 불만까지 일정한 평가 기준을 정의하고, 해당 기준에 따라 상태를 판단할 때 사용합니다.
Noul — 예·아니오 판단: “환불 요청이 포함되어 있는가?”처럼 두 방향으로 구분할 질문에 사용합니다. Noul은 제품에서 사용하는 유형 이름이므로 그대로 표기합니다.
Jev의 판단 결과만으로 고객에게 보여 줄 설명문이 완성되는 것은 아닙니다. 공식 문서도 System One 모델은 답장을 쓰거나 코드를 만들거나 판단 이유를 설명하지 않는다고 명시합니다. 자연어 안내가 필요한 경우 별도의 LLM이나 문장 템플릿과 결합할 수 있습니다.
캘리브레이션 — 「확률」이 무슨 뜻인가#
캘리브레이션(calibration)은 모델이 반환한 확률이 실제 결과와 얼마나 잘 맞는지를 평가하는 개념입니다. 예를 들어 모델이 여러 건의 판단에서 90%의 확률을 제시했다면, 그런 사례가 실제로도 약 90%의 비율로 맞는지 살펴보는 방식입니다. TypeSafe는 System One의 확률이 결과(outcome)에 맞춰 불확실성을 반영하도록 학습됐다고 설명합니다.
다만 한 건의 결과에 91%가 표시되었다고 해서 해당 판단이 반드시 맞는다는 의미는 아닙니다. 공식 문서 역시 캘리브레이션은 여러 예측을 묶어 측정하는 것이며 개별 답이 맞다는 보장은 아니라고 적고 있습니다. 운영 환경에서는 잘못 판단했을 때 발생할 위험에 따라 자동 처리 기준을 설정하고, 불확실한 사례는 담당자의 검토 단계로 넘기는 것이 좋습니다. 공식 문서에서 제공하는 확률·신뢰도 관련 지표도 업무상 정확도를 보장하는 값으로 혼동해서는 안 됩니다.
왜 2025~2026년에 말이 많아졌나#
첫째, 새로운 제품 범주에 대한 관심입니다. TypeSafe는 Jev를 일반적인 채팅형 AI와 다른 ‘판단 중심’ 제품으로 소개합니다. 문장을 생성하는 기능보다 선택과 확률을 활용하는 방식에 초점을 맞췄다는 점이 논의의 출발점입니다.
둘째, 업무 자동화의 비용과 처리 방식입니다. 하나의 배경 정보에 여러 질문을 연결할 수 있다는 점은 문의 분류나 승인 전 검토에 활용할 만합니다. 다만 실제 비용과 처리 속도는 입력량, 질문 구성, 요금 정책을 기준으로 직접 검증해야 합니다.
셋째, 공개되지 않은 내부 구조를 둘러싼 분석입니다. 모델의 전체 학습 과정과 내부 구조가 공개되지 않은 상황에서 일부 개발자는 API 입력과 출력의 패턴을 살펴보며 작동 방식을 추론했습니다. 이런 분석은 관찰 결과를 바탕으로 한 가설이지, 모델의 내부 구현이 확인됐다는 증거는 아닙니다. 이는 상용 API의 응답 패턴을 실험하는 이야기이며, 앱 복제 리버스 엔지니어링과는 검색어만 겹치고 갈래가 다릅니다. → AI RE와 소프트웨어 복제
넷째, 대체 구현과 비교 실험에 대한 관심입니다. 공개 커뮤니티에서는 Jev와 유사한 기능을 구현하거나 기존 모델로 같은 분류 작업을 수행하려는 접근도 논의됐습니다. GitHub에는 Jev 관련 프로젝트와 호환 구현을 모은 awesome-jev 계열 저장소가 여러 개 있습니다. 그러나 외형상 비슷한 API를 구현했다는 사실만으로 성능과 확률의 신뢰도가 같다고 판단할 수는 없습니다.
자주 하는 오해#
“그냥 더 빠른 GPT 아닌가요?” Jev의 핵심은 답변을 짧게 생성하는 것이 아니라, 정해진 유형에 맞는 판단 결과를 반환하도록 설계됐다는 점입니다. 글쓰기나 일반적인 대화 업무와는 사용 목적이 다릅니다.
“Jev가 있으면 RAG나 에이전트가 필요 없나요?” 그렇지 않습니다. 내부 자료 검색, 외부 시스템 호출, 여러 단계의 작업 실행이 필요한 경우에는 별도의 검색·에이전트 구조가 필요할 수 있습니다.
“확률이 높으면 항상 정답인가요?” 아닙니다. 확률은 통계적으로 평가해야 하며, 실제 업무 데이터에서의 오류율과 자동 처리 기준을 별도로 검증해야 합니다. 선택지 문구를 바꾸면 확률도 달라질 수 있으므로 운영 중 재측정이 필요합니다.
정리#
Jev는 TypeSafe가 System One 제품군에서 소개한 판단 중심 API입니다. 개발자가 전달한 배경 정보와 질문에 대해 구조화된 판단 결과를 반환한다는 점에서, 주로 문장을 생성하는 채팅형 AI와 활용 목적이 다릅니다.
실제 적용을 검토한다면 먼저 무엇을 판단할지, 어떤 선택지를 사용할지, 어느 수준에서 사람이 다시 검토할지를 정의하는 것이 좋습니다. 그다음 실제 업무 데이터로 정확도와 비용을 검증해야 합니다.
AI·AX 시스템 설계에서는 답변 생성과 업무 판단을 하나의 기능으로 취급하기보다 각각의 역할을 구분해 설계하는 것이 중요합니다. Jev는 그런 설계 방식을 이해하는 하나의 사례로 볼 수 있습니다.
공식 개념·모델 ID·pricing: docs.typesafe.ai — System One(새 창), Models(새 창).
