2026. 9. 24. 04:06ㆍAI
Jev는 TypeSafe AI가 2026년 9월 15일에 공개한 모델로 텍스트를 토큰 단위로 생성하는 기존 LLM과 달리
상태(state)와 질문(question)을 입력받아 확률, 신뢰도가 붙은 구조화된 답변을 반환하는 모델입니다.
이렇게만 말하면 무슨 말인지 모르니 천천히 알아가 보겠습니다.
생성형 AI의 아쉬운 점
지금까지의 생성형 AI는 사람이 읽기 좋은 자연스러운 답변을 만드는 데는 뛰어나지만, 소프트웨어 안에서 반복적으로 판단을 내려야 하는 자동화 작업에는 몇 가지 근본적인 한계가 있습니다.
- 속도와 비용: 답을 토큰 단위로 하나씩 순차 생성하다 보니, 단순히 "예/아니요"나 "이 중 하나 골라줘" 같은 판단 하나를 받기 위해서도 전체 응답을 다 생성할 때까지 기다려야 하고, 그만큼 비용도 커집니다.
- 파싱의 번거로움: 텍스트로 답이 나오기 때문에, 코드에서 쓰려면 결국 그 텍스트를 다시 파싱 해서 원하는 타입(boolean, enum, score 등)으로 변환해야 합니다. 이 과정에서 모델이 스키마를 벗어난 형식으로 답하는 할루시네이션 위험도 따라옵니다.
(사실상 스키마를 벗어난 형식으로 답하는 할루시네이션은 요즘에는 없다고 해도 무방함) - 신뢰도 정보의 부재: 답을 주긴 주지만 이 답이 얼마나 확실한지를 명시적으로 알려주지 않기 때문에 애매한 판단과 확실한 판단을 로직에서 구분해서 처리하기가 어렵고 이는 자동화 시스템에서 치명적입니다.
Jev는 이 문제를 어떻게 풀었을까
Jev는 텍스트 생성 자체를 포기하는 대신, 상태와 타입이 정해진 질문을 한 번에 병렬로 평가해서 확률과 신뢰도 점수가 붙은 답을 바로 돌려주는 방식을 택했습니다. TypeSafe는 이런 방식의 모델을 "System One" 모델이라고 부릅니다.
System One 모델은 일반 LLM처럼 자연어를 이해하는건 똑같지만, 텍스트를 생성하는 대신 미리 정해둔 답변 후보들 중에서 답을 고르고 각각에 확률을 매겨서 돌려줍니다.
즉, "답을 생성"하는게 아니라 미리 정의된 답변 공간 안 "답을 고르는"모델인 셈입니다.
Jev의 구성
상태(State)
State는 System One 모델에게 평가를 요청하는 컨텐츠입니다.
그냥 문자열로 "카드가 두 번 결제됐어요"와 같은 메시지 한 줄일 수도 있고, {"message": "...", "order_id": "A-104"}처럼 JSON을 넣어 어떤 상태인지를 담은 것 일수도 있습니다.
요청 하나마다 state는 하나이고 그 state에 대해 Choice/Score/Noul 형을 섞어서 질문을 던질 수 있는데
모든 질문은 같은 state를 바라보고 각자 독립적으로 답합니다.
주의할 점은, Jev가 지금은 이미지, 오디오, 영상은 아직 되지 않고 텍스트만 받는다는 겁니다.
그리고 학습 데이터가 영어 위주라서 한국어를 포함한 CJK 언어는 아직 정확도가 상대적으로 떨어진다고 문서에도 명시돼 있습니다.
state에는 판단할 재료만 담고, "무엇을 기준으로 판단할지"는 다음에 설명할 질문(primitive, question)쪽에 넣는 게 원칙입니다.
질문(Question)
TypeSafe의 질문 유형은 Choice, Score, Noul 3가지로 정해져있습니다.
즉, Jev가 받는 질문은 방금 말한 저 세 종류뿐이며, 각각 다른 형태의 답을 반환합니다.
| 타입 | 묻는 것 | 예시 | 반환값(추후 설명) |
| Choice | 이 중 어느 옵션인가? | 이 문의는 배송팀/결제팀/기술지원팀중 어디로 보내야하나? → choice: "배송팀" |
choice, probabilities, confidence |
| Score | 어느 레벨인가? | 이 버그가 얼마나 심각한가? → score: 1.4 |
score, legend, probabilities,confidence |
| Noul | 이게 참인가 | 이 메세지가 환불 요청 메시지인가? → noul: 0.92 |
noul (0 ~ 1) |
선택(Choice) - 여러 후보 중 하나 선택하기
Choice는 정해진 옵션 중에서 하나를 고르게 하고 싶을 때 씁니다.
요청 예시 json
{
"state": "러닝화가 잘못된 사이즈로 왔어요. 265로 교환 가능한가요?",
"questions": {
"department": {
"type": "choice",
"instructions": "어느 팀이 처리해야 하는가?",
"criteria": {
"returns": "교환, 오배송, 파손 상품",
"shipping": "배송 상태, 지연, 분실",
"billing": "결제, 청구, 환불 문제"
}
}
}
}
요청에는 모델이 답해야 하는 질문 내용(instructions)과 답변 선택지들(criteria, 옵션 이름: 설명)을 넣습니다.
응답 예시 json
{
"model": "jev-1.13.0",
"answers": {
"department": {
"type": "choice",
"choice": "returns",
"confidence": 1.0,
"probabilities": {
"shipping": 0.0,
"returns": 1.0,
"billing": 0.0
}
}
},
"usage": {
"input_tokens": 328,
"output_tokens": 34
}
}
리턴되는 주요 값은 choice, confidence, probabilities 3가지가 있습니다.
- choice: 가장 확률이 높은 옵션
- probabilities: 전체 옵션의 확률 분포
- confidence: 이 확률 분포가 한쪽으로 얼마나 쏠려 있는지를 0~1 사이 숫자 하나로 요약한 값
위 예시에서는 누가 봐도 사이즈 교환 얘기라 확률이 returns에 100% 몰려 있으니 confidence도 1.0이 나옵니다.
반대로 티켓 내용이 "사이즈도 잘못 왔는데 결제도 두 번 된 것 같아요"처럼 애매했다면 아마 returns랑 billing에 확률이 나뉘어서,
choice는 여전히 둘 중 하나로 나오겠지만 confidence는 뚝 떨어졌을 겁니다.
그러니까 자동화 작업을 처리할 때 choice만 보고 '아 그냥 returns구나' 하고 끝나는 게 아니라 confidence까지 같이 봐서, 자동화 처리 기준을 좀 더 세밀하게 잡을 수 있게 됩니다.
점수(Score) - 어느 정도인가
답이 딱 떨어지는 선택지가 아니라 어느 정도인가를 물어볼 때 사용합니다.
버그가 심각한지가 아니라 버그가 얼마나 심각한지, 고객이 화났는지가 아니라 고객이 얼마나 화났는지와 같은 것들을 말합니다.
요청 예시 json
{
"state": "PDF로 내보내기를 누르면 크롬에서는 되는데, Safari에서만 화면이 멈춰요. 저희 고객 중 몇 명은 Safari만 쓰는데, 그분들은 아예 이 기능을 못 쓰고 있어요.",
"questions": {
"bug_severity": {
"type": "score",
"instructions": "이 이슈가 얼마나 심각한가?",
"criteria": [
"경미함, 기능에 영향 없음",
"기능이 깨졌지만 우회 방법 있음",
"차단 이슈, 우회 방법 없음"
]
}
}
}
요청에는 질문 내용(instructions)과 낮은 단계부터 높은 단계 순서로 레벨 설명 배열(criteria, 2~10개)을 넣습니다.
응답 예시 json
{
"model": "jev-1.13.0",
"answers": {
"bug_severity": {
"type": "score",
"score": 1.43,
"confidence": 0.35,
"legend": {
"0": "경미함, 기능에 영향 없음",
"1": "기능이 깨졌지만 우회 방법 있음",
"2": "차단 이슈, 우회 방법 없음"
},
"probabilities": {
"0": 0.0,
"1": 0.57,
"2": 0.43
}
}
}
}
리턴되는 주요 값은 score, legend, probabilities, confidence 4가지가 있습니다.
- score: 레벨 번호와 확률을 가중평균한 값 (0×0.0 + 1×0.57 + 2×0.43 = 1.43)
(딱 떨어지는 레벨이 아니라 레벨 사이의 위치라서 소수점이 나올 수 있음) - legend: 각 레벨 번호와 실제 뜻
- probabilities: 각 레벨에 대한 확률 분포
- confidence: 이 분포가 한 레벨에 몰려있는지, 여러 레벨에 퍼져있는지를 요약한 값
위 예시는 score가 1.43이 나왔으니 레벨 1과 2 사이에서 1 쪽에 좀 더 가깝다는 뜻이고, confidence가 0.35라는 건 모델이 레벨 사이에서 확률을 꽤 갈랐다는 신호입니다.
실제로 이 버그는 Safari에서만 발생하고 크롬에서는 정상 동작하기 때문에, 크롬으로 갈아탈 수 있는 유저에게는 우회 방법이 있는 셈입니다. 다만 Safari를 쓸 수밖에 없는 일부 고객에게는 우회 방법이 없는 상황이라 애매하고, 그래서 이 결과가 꽤 납득이 갑니다.
레벨을 쓸 때 중요한 게 하나 있는데, 추상적으로 쓰면 안 된다는 겁니다. "중간 정도의 심각성" 같은 표현보다는 "기능은 깨졌지만 우회할 방법은 있음"처럼 구체적인 상황으로 적어야 모델이 판단할 근거가 생깁니다.
그리고 한 질문에는 한 가지 기준만 담아야 합니다. "성실하고 똑똑하고 경험도 많은가"처럼 여러 걸 한꺼번에 물으면 confidence도 떨어지고 점수 자체의 의미도 흐려집니다.
반올림의 충동
나온 score값이 불편해서 반올림을 해서 사용하고 싶을 수 있습니다.
| 문의 | score | 반올림 | probabilities | confidence |
| 언제쯤 처리되나요? | 0.46 | 0 | {0: 0.55, 1: 0.45} | 0.54 |
| 며칠째 답이 없네요 | 0.91 | 1 | {0: 0.09, 1: 0.91} | 0.91 |
첫 번째 문의를 반올림했을 때 값은 0인데, 확률 분포를 보면 거의 반반인데 이는 거의 절반의 가능성을 그냥 버리게 되는 셈입니다.
반면에 두 번째 문의는 반올림했을 때 잃는 것이 거의 없습니다.
반올림을 사용해도 되지만 위와 같은 경우를 생각해서 반올림 여부를 결정할 때는 confidence를 참고해서 결정하는 게 좋습니다.
누울(Noul) - 예/아니오를 확률로 판단하기
Noul은 예/아니오로 답할 수 있는 질문에 씁니다.
"이 메시지가 환불을 요청하고 있는가" 같은 걸 말하는데, 돌아오는 답이 참/거짓이 아니라는데에 낯선 점이 있습니다.
요청 예시 json
{
"state": "3번이나 얘기했는데요. 실제 상담원과 통화할 수 있을까요?",
"questions": {
"is_human_escalation": {
"type": "noul",
"instructions": "고객이 사람 상담원을 요청하고 있는가?"
}
}
}
응답 예시 json
{
"model": "jev-1.13.0",
"answers": {
"is_human_escalation": {
"type": "noul",
"noul": 0.99
}
}
}
리턴되는 값은 noul 딱 하나입니다.
noul이 1에 가까우면 "예"일 확률이 높고, 0에 가까우면 "아니요"일 확률이 높습니다.
당연하지만 결과가 예/아니오 둘 뿐이라서 confidence가 없습니다.
Noul은 "정도"를 재는 척도가 아니라는 점을 기억해 두면 좋습니다.
값이 0.5라고 해서 "반쯤 그렇다"는 뜻이 아니라, 그냥 그 명제가 참일 확률이 반반이라는 뜻입니다.
정도 자체를 알고 싶다면 Score를 쓰는 게 맞습니다.
위 링크에서 부정문은 어떻게 다루는지와 criteria에 대한 내용도 있어서 읽어보면 좋을 것 같습니다.
출처
https://wikidocs.net/book/21376
https://docs.typesafe.ai/introduction
'AI' 카테고리의 다른 글
| 하네스 엔지니어링 (0) | 2026.04.03 |
|---|---|
| 바이브 코딩 체험기 (1) | 2025.09.25 |
| LLM (0) | 2025.09.24 |
| RAG (0) | 2025.09.24 |