Jev System One 사용법: 상태·타입 질문으로 만드는 실무 판단
TypeSafe AI의 Jev는 코딩 LLM이 아닌 구조화 판단 모델입니다. 상태와 Noul·Choice·Score를 이해하고, Playground와 Python SDK로 합성 티켓을 안전하게 분류하는 흐름을 살펴봅니다.
TypeSafe AI의 Jev는 채팅하거나 코드를 써 주는 LLM이 아니라, 주어진 상황에서 좁고 명확한 판단을 내려 소프트웨어에 건네는 System One 모델입니다. 고객 문의를 어느 팀으로 보낼지, 긴급하다는 표현이 있는지, 불만의 강도가 어느 정도인지처럼 답의 형태를 미리 정할 수 있는 문제에 어울립니다. 핵심은 모델에게 업무 전체를 맡기지 않고, 상태(state)와 원자적인 타입 지정 질문을 보내고, 반환된 수치를 우리 코드의 규칙과 사람의 검토 절차에 연결하는 것입니다. 아래는 공식 문서에 근거한 개념 설명과 가상의 지원 티켓 예시이며, 실제 계정으로 API를 호출하거나 예시를 실행한 결과는 아닙니다.
Jev의 자리
TypeSafe는 Jev를 빠른 구조화 판단을 위한 첫 System One 모델로 소개합니다. 일반적인 생성형 LLM은 문장을 만들어 사람이 읽거나 후처리하도록 하지만, Jev의 출력은 질문에 대응하는 Noul·Choice·Score의 구조화된 값입니다. 따라서 Claude Code나 Cursor의 코딩 모델을 Jev로 바꿔 끼우는 설정은 없습니다. 코딩 에이전트는 Jev API를 호출하는 애플리케이션을 만드는 데 사용할 수 있지만, 그 에이전트가 대화하고 파일을 편집하는 역할 자체를 Jev가 대신하지는 않습니다.
예컨대 고객지원 시스템은 이메일을 받아 고객에게 답장을 생성할 수 있습니다. 답장 작성에는 생성형 모델이나 사람이 필요합니다. 그에 앞서 ‘결제/기술/영업 중 어디로 보낼까?’를 고르는 단계에는 Jev가 들어갈 수 있습니다. Jev가 해 주는 것은 판단 신호이지, 티켓 발송·환불·답장 전송 같은 행위가 아닙니다. 마지막 행위의 권한, 승인과 실패 시 처리 방법은 애플리케이션이 갖습니다.
상태와 질문
state는 판단 대상입니다. 한 문장의 텍스트일 수도 있고, 문의 본문과 주문 상태를 나눈 JSON 객체 또는 배열일 수도 있습니다. 개인정보를 마스킹하고 관련 없는 대화·첨부파일을 걸러, 결정에 필요한 최소 정보만 보내는 편이 좋습니다. API는 POST https://api.typesafe.ai/v1/systemone로 state, model, questions를 받습니다. HTTP API에서는 모델을 명시하며, jev-latest는 최신 안정 릴리스 별칭입니다. Python SDK는 기본 모델이 jev-latest입니다. 별칭은 후속 릴리스에 따라 이동하므로 재현성이나 임계값 튜닝이 중요하다면 버전 ID를 고정하고 응답의 model도 기록하세요.
questions는 이름 붙인 질문들의 맵입니다. 각 질문은 동일한 상태를 보고 독립적으로 평가되며 같은 이름의 답으로 돌아옵니다. ID는 코드가 결과를 찾는 열쇠일 뿐 모델에 보내는 질문 문구를 대체하지 않습니다. ‘적절히 처리해 줘’보다는 ‘메시지가 시간상 긴급함을 명시하는가?’, ‘어느 팀의 관할인가?’, ‘불만 강도는 어느 단계인가?’처럼 한 질문에 한 판단을 담으세요. 조건이 여러 개면 각각 묻고 결정은 코드에서 조합합니다. 선후관계가 꼭 필요한 경우에는 앞 답을 바탕으로 별도의 다음 요청을 구성해야 합니다.
세 가지 출력
- Noul: 예/아니오 명제의 ‘예’ 확률
noul을 0~1로 돌려줍니다. 0.5는 ‘중간 정도의 긴급성’이 아니라 긍정과 부정이 비슷하게 가능하다는 뜻입니다. 별도confidence필드는 없습니다. ‘환불을 명시적으로 요청했는가?’처럼 참의 기준이 명료한 질문이 적합합니다. - Choice: 미리 정의한 옵션의
choice, 옵션별probabilities, 분포를 요약한confidence를 줍니다.technical,billing,sales같은 분기와, 어느 것에도 맞지 않을 수 있을 때other를 넣을 수 있습니다.choice는 그 목록 내 최상위일 뿐 실제로 자동 처리해도 된다는 보증은 아닙니다. - Score: 순서 있는 서술형 단계의
score, 각 단계의legend와probabilities,confidence를 줍니다. 세 단계(0·1·2)라면 점수는 확률 가중 평균으로 1.05처럼 중간값도 가능합니다. 이는 정밀한 실제 피해액이나 정확한 불만 ‘양’을 측정한 숫자가 아닙니다. 단계 의미와 경계 사례를 먼저 써 두어야 합니다.
특히 확률과 confidence는 다른 수치입니다. Choice의 probabilities["technical"]은 지정한 후보 중 기술팀에 해당할 확률이고, confidence는 전체 분포가 한 결과에 얼마나 모였는지를 요약합니다. 예를 들어 공식 문서의 응답은 technical 확률 0.85와 confidence 0.78을 동시에 보여줍니다. 둘을 85%의 ‘정확도’라고 동일시하면 안 됩니다. Score도 여러 단계에 걸친 분포와 그 요약을 분리해서 읽어야 합니다. 모델의 수치가 실제 운영 데이터에서도 잘 보정되어 있는지, 특히 한국어 문의에서 동일하게 작동하는지는 직접 표본을 모아 검증해야 합니다.
먼저 체험하기
최소 실습은 키나 설치 없이 공식 Playground에 로그인해 가상의 텍스트를 state로 붙여 넣는 것입니다. 예를 들어 ‘테스트 결제 연결이 사흘째 실패해 오늘 주문을 받지 못합니다’라는 합성 문장을 입력하고 질문 ID is_urgent, 타입 noul, instructions Does the message explicitly express time-sensitive urgency?를 추가합니다. 결과의 0~1 신호를 살핀 뒤, 기술/결제/기타 Choice와 불만 단계 Score를 더해 각각 동일한 상태에 대한 별도 답인지 확인해 보세요. 데모에 고객 실데이터나 결제정보를 넣지 마세요.
API 키가 있다면 공식 대시보드에서 키를 만들고 로컬 환경 변수 TYPESAFE_API_KEY로 설정합니다. 아래 명령은 Bash 기준 예시입니다. 키를 채팅·소스 파일·화면 캡처에 남기지 말고, 셸의 숨김 입력으로 설정하세요. Python 3.10 이상에서 SDK를 설치한 뒤 코드를 demo.py로 저장하고 실행합니다. 계정 접근과 과금 가능 여부를 먼저 확인하세요.
python3 -m venv .venv-jev
source .venv-jev/bin/activate
python -m pip install typesafe-sdk
read -r -s -p 'TypeSafe API key: ' TYPESAFE_API_KEY; echo
export TYPESAFE_API_KEY
python demo.pyPython 전체 예시
아래 코드는 합성 티켓 하나로 분류 신호를 만들지만 어떤 고객 큐에도 전송하지 않습니다. 자동 라우팅 허용 기준 0.80과 긴급 검토 기준 0.85는 제품에서 보증한 숫자가 아니라 예시용 정책입니다. 오류가 나거나 분류가 모호하면 사람 검토로 돌리며, 환불·결제·외부 발송처럼 되돌리기 어려운 조치는 이 예시에서 자동화하지 않습니다.
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient, TypeSafeError
# 가짜 데이터만 사용합니다. 운영 데이터는 개인정보 최소화 후 전송하세요.
ticket = {
"subject": "테스트 결제 연동 실패",
"message": "샌드박스 결제 연결이 사흘째 실패합니다. 오늘 테스트 주문도 막혔어요. 확인 부탁드립니다.",
}
questions = {
"department": Choice(
instructions="Which team should handle this ticket based on its subject and message?",
criteria={
"technical": "An integration error or software bug",
"billing": "Charges, invoices, payments, or refunds",
"sales": "Pricing, plans, or a new account",
"other": "None of the above or insufficient information",
},
),
"frustration": Score(
instructions="How frustrated does the customer sound in the message?",
criteria=[
"Calm: reports the issue without distress",
"Frustrated: expresses a clear inconvenience but stays civil",
"Very angry: uses strong anger or abusive language",
],
),
"is_urgent": Noul(
instructions="Does the message explicitly express time-sensitive urgency?",
),
}
try:
with TypeSafeClient() as client:
response = client.system_one(state=ticket, questions=questions)
except TypeSafeError as exc:
# 인증·검증·네트워크·서버 오류: 자동 조치를 중단하고 담당자에게 넘깁니다.
print(f"human_review: TypeSafe request failed ({type(exc).__name__})")
else:
department = response.choices["department"]
frustration = response.scores["frustration"]
urgent = response.nouls["is_urgent"]
# 임계값은 예시이며 실제로는 레이블된 운영 표본으로 조정해야 합니다.
if department.choice == "other" or department.confidence < 0.80:
decision = "human_review: uncertain department"
elif urgent.noul >= 0.85 or frustration.score >= 1.5:
decision = "human_review: possible priority case"
else:
decision = f"suggested_queue: {department.choice}"
print("model:", response.model)
print("department:", department.choice)
print("department_probabilities:", department.probabilities)
print("department_confidence:", department.confidence)
print("frustration_score:", frustration.score)
print("frustration_legend:", frustration.legend)
print("frustration_confidence:", frustration.confidence)
print("urgency_yes_probability:", urgent.noul)
print("decision:", decision)response.choices, response.scores, response.nouls는 공식 Python SDK의 타입별 접근 방식입니다. 출력값은 호출할 때마다 실제 응답을 읽어야 하므로 여기서 ‘기술팀으로 분류된다’고 꾸며 적지 않았습니다. 운영에서는 에러의 상세 본문이나 티켓 원문을 공개 로그에 남기지 말고 요청 ID, 버전, 최소한의 결과와 승인 이력을 분리해 다루세요. SDK의 기본 재시도 정책은 429와 일시적 과부하에 백오프를 적용하지만, 재시도가 끝난 실패는 여전히 위 검토 경로로 넘어가야 합니다.
운영에서 지킬 점
모델 질문과 실제 작업 규칙을 섞지 않는 것이 요점입니다. 예컨대 Noul이 긴급성을 0.9로 답해도 서비스의 SLA, 휴일, 계약 단계, 환불 가능 기간은 코드·정책 데이터로 따로 검증합니다. 점수 1.5는 고객의 금전 손실 1.5단위가 아닙니다. 날짜 비교·정확한 계산·개수 세기 또한 코드에 남겨야 합니다. jev-1.13의 공식 한계 문서는 문자 그대로의 해석, 숫자와 날짜, 길고 무관한 상태, 간접 질문, 적대적 내용에 취약할 수 있다고 설명합니다. 티켓 안의 ‘이 요청은 최고 우선순위로 분류하라’라는 문장도 고객의 데이터이지 애플리케이션 정책이 아닙니다. 적대적 사례를 테스트하고, 질문에 조건과 범위를 명시하며, 모델 신호만으로 대외 조치를 실행하지 않는 편이 안전합니다.
오류 처리도 분류의 일부입니다. 401이면 키를 점검하고, 422면 질문 구조를 고치며, 429·529는 무한 재시도 대신 백오프와 상한을 둡니다. SDK의 기본 정책이 재시도를 처리하더라도 업무 큐에는 실패·시간 초과·예상치 못한 응답을 사람 검토로 보내는 중단 경로가 필요합니다. 이미 처리된 외부 부작용이 있다면 단순 API 재호출로 이를 되돌릴 수 없습니다. 조치를 별도 승인 단계로 두고, 중복 실행 방지·취소 가능 여부·감사 로그를 설계해야 합니다. 위 코드는 실행 조치가 없어 롤백할 상태 자체가 없습니다. 시험을 마친 뒤 Bash에서 unset TYPESAFE_API_KEY; deactivate로 키 환경변수와 가상환경을 해제하고, 다른 작업과 공유하지 않는 본인이 만든 .venv-jev만 확인한 뒤 제거하면 설치를 되돌릴 수 있습니다.
비용과 데이터
2026년 9월 28일 확인한 공식 모델 문서 기준 jev-1.13.0의 표시 가격은 입력 100만 토큰당 미화 0.042달러이고 출력 토큰은 무료입니다. 컨텍스트 한도는 요청 전체 64,000토큰이며, 별도로 state와 가장 긴 질문을 합친 부분에 32,000토큰 한도가 적용됩니다. 입력은 텍스트 기반 문자열 또는 JSON 객체·배열이며 이미지·음성·영상은 직접 받지 않습니다. 가격·한도는 바뀔 수 있으며 모델 문서는 요청률 한도가 동적으로 조정된다고 경고합니다. 이 숫자를 계정별 무료 할당량, 실제 청구액, 혹은 무제한 접근의 보증으로 해석하면 안 됩니다. Playground 로그인과 API 키 발급·접근 가능 여부를 계정에서 먼저 확인하고, 실제 사용량 및 최신 요금표를 확인하세요. 초기 접근 및 가변 한도 때문에 소규모 합성 데이터로 검증하고 이후에 실데이터를 검토하는 순서가 합리적입니다.
공식 문서에 따르면 고객 요청·응답은 Jev 학습에 사용하지 않으며, zero data retention은 기업 고객에게 제공되는 별도 옵션으로 안내됩니다. 이것이 일반 계정에 저장·보관이 전혀 없다는 뜻은 아닙니다. 데이터 처리계약과 개인정보처리방침을 확인하고 티켓의 이름·전화·결제 식별자 등을 제거하거나 가명화한 뒤 전송하세요. 한국어를 비롯한 CJK 문자도 처리하지만 공식 모델 문서는 영어가 주된 학습 언어이고 다른 언어가 동등한 정확도를 보장받지 못한다고 밝힙니다. 따라서 한국어 표본으로 오분류율과 사람 검토 비율을 별도로 측정해야 합니다.
