4,682
AI 기능을 만든다고 해서 반드시 챗봇부터 만들어야 할까요? 고객 문의를 담당 팀에 배정하거나 장애 보고를 분류하는 서비스에는 긴 설명보다 프로그램이 바로 처리할 수 있는 판단 결과가 필요할 때가 많습니다.
TypeSafe AI의 Jev는 이 지점을 겨냥합니다. 자연어 답변을 생성하는 대신, 미리 정의한 질문에 대해 선택지·점수·확률을 반환하는 System One 모델입니다. 이 글은 Nomad Coders의 Jev 해설을 출발점으로 공식 발표와 API 문서를 대조해, 개발자가 무엇을 맡기고 무엇을 코드에 남겨야 하는지 살펴봅니다.[1][2][3]
💡 💡 핵심은 “더 짧게 답하는 챗봇”이 아니라 비정형 입력을 타입이 정해진 확률적 판단으로 바꾸는 모델입니다. 단, 출력 형식이 유효하다는 것과 판단이 옳다는 것은 별개의 문제입니다.[1][2]
TypeSafe는 빠르고 구조화된 결정을 소프트웨어에 제공하는 모델 계열을 System One이라고 부릅니다. 이름은 빠른 직관과 느린 숙고를 구분하는 System 1·System 2 개념에서 가져왔으며, Jev는 이 계열의 첫 공개 모델로 소개됐습니다. 이는 제공사가 제안한 제품·모델 계열 명칭이지, 업계 전체의 공인 분류라고 받아들일 필요는 없습니다.[2]
Jev의 인터페이스는 대화 이력을 이어 가는 방식보다 **현재 상태(state)와 평가할 질문(questions)**을 전달하는 방식에 가깝습니다. 상태는 문자열 또는 구조화된 객체가 될 수 있고, 질문별 결과는 요청자가 정한 ID 아래 반환됩니다.[3]
자유 형식의 답장, 코드, 설명문을 작성하는 용도는 아닙니다. “어느 부서로 보낼까?”에는 적합할 수 있지만, “고객에게 보낼 공감 어린 답장을 써 줘”는 다른 생성 모델의 역할입니다. 여기서 문자열을 생성하지 않는다는 말은 응답에 선택지 이름이나 JSON 키가 없다는 뜻이 아니라, 임의의 문장을 자유롭게 작성하지 않는다는 뜻입니다.[1][2][3]
따라서 Jev를 LLM 대체재로 보기보다는 애플리케이션 안에 넣는 판단 컴포넌트로 이해하는 편이 정확합니다. 소프트웨어가 맡길 일의 경계가 분명할수록 이 인터페이스의 장점을 평가하기도 쉬워집니다.
일반적인 생성형 LLM은 토큰을 순차적으로 생성하며, Structured Outputs는 그 출력이 정해진 구조를 따르도록 제약하는 방식입니다. Nomad Coders의 해설은 이를 “텍스트가 필요 없는 작업에 텍스트 생성 모델을 사용하는 것”이라는 관점으로 설명합니다. 이는 Structured Outputs가 쓸모없다는 뜻이 아니라, 자동화에 필요한 인터페이스를 어디서부터 설계할 것인가의 차이입니다.[1][2]
TypeSafe는 Jev에 새로운 모델 architecture, parallel sampler, RLCD(Reinforcement Learning for Calibrated Decisions)를 사용했다고 설명합니다. 목적은 사람이 선호하는 설명문보다, 소프트웨어가 쓸 수 있는 판단과 보정된 확률을 제공하는 것입니다. 다만 공개 발표를 읽은 것만으로 내부 구현 전체나 학습 효과를 독립적으로 검증했다고 말할 수는 없습니다.[2]
개발자가 체감할 차이는 단순합니다. 응답 문장에서 결론을 추출하는 대신 Choice·Score·Noul의 정해진 결과를 읽고 분기합니다. 그러나 네트워크 실패, API 오류, 업무 규칙 위반까지 사라지는 것은 아니므로, 애플리케이션의 오류 처리와 검증은 그대로 필요합니다.[3]
💡 ⚠️ Type safety는 semantic correctness가 아닙니다. 허용된 선택지만 반환하더라도 틀린 팀을 선택할 수 있습니다. “환각이 없다”는 홍보 문구를 “업무 판단이 틀리지 않는다”로 확대하면 안 됩니다.[1][2]
Choice는 담당 부서, 문서 종류, 요청 의도처럼 정해진 범주 중 하나를 고르는 질문입니다. criteria는 선택지 이름과 설명을 매핑하며, 응답에는 가장 높은 확률의 choice, 전체 probabilities, confidence가 포함됩니다.[5]
예를 들어 담당 팀을 묻는다면 billing은 결제·청구 문제, technical은 오류·연동 문제처럼 경계를 설명합니다. 실제 입력을 모두 포괄하지 못한다면 other 같은 선택지를 두어, 모델이 억지로 부적절한 범주를 고르지 않도록 설계할 수 있습니다. 공식 문서는 Choice에 최대 255개 옵션을 지원한다고 설명합니다.[5]
한 티켓이 반품과 이중 결제를 함께 언급한다면, 가장 높은 확률의 팀만 읽고 나머지를 버리는 것이 항상 좋은 정책은 아닙니다. 공식 예제는 담당 팀을 하나 배정하면서 다른 팀에도 의미 있는 확률이 있으면 알림을 보내는 패턴을 보여 줍니다. 이는 복수의 확률을 어떻게 행동으로 바꿀지가 모델이 아니라 코드의 책임임을 보여 줍니다.[5]
Score는 심각도·관련성처럼 순서가 있는 기준을 평가합니다. criteria에 낮은 단계부터 높은 단계까지 설명을 넣으며, 공식 문서상 단계는 2개부터 10개까지입니다. 응답은 score, 단계별 probabilities, confidence, 단계 설명을 담은 legend를 제공합니다.[4]
예를 들어 버그 심각도를 “기능 영향 없는 외관 문제 / 기능이 고장 났지만 우회 가능 / 우회 방법 없는 차단 문제”로 정의할 수 있습니다. 세 단계의 인덱스는 0·1·2이며, score는 단계 인덱스의 확률 가중 평균이므로 정수가 아닐 수도 있습니다.[4]
공식 예제처럼 단계별 확률이 0·0.7·0.3이면 score는 1.3입니다. 이는 “대체로 우회 가능한 장애지만 차단 문제일 가능성도 있다”는 분포의 요약이지, 고객의 30%가 장애를 겪는다는 뜻이 아닙니다. 같은 평균도 서로 다른 분포에서 나올 수 있으므로 score만 저장하지 말고 probabilities도 함께 보는 편이 좋습니다.[4]
“보통 / 심함 / 매우 심함”처럼 추상적인 단어만 나열하기보다 실제 상황을 설명해야 합니다. 심각도와 고객 감정, 보고서 충실도를 한 Score에 섞지 말고 각각 평가한 뒤 코드에서 결합하는 것이 공식 문서의 권장 패턴입니다.[4]
Noul은 “사람 상담원을 요청했는가?”, “이 메시지에 개인정보가 있는가?” 같은 예·아니요 질문을 평가합니다. noul은 yes일 확률을 나타내는 0~1 값이며, Choice·Score와 달리 별도의 confidence 필드는 없습니다.[7]
값이 1에 가까우면 강한 yes, 0에 가까우면 강한 no이고, 0.5 부근은 불확실한 상태입니다. 중요한 점은 이것이 정도의 점수가 아니라는 것입니다. “긴급한가?”의 확률을 “긴급도 자체”로 해석하지 말고, 정도를 구분해야 한다면 별도 Score 기준을 정의해야 합니다.[7]
하나의 Noul에 “화가 났고 환불도 요구하는가?”를 모두 넣기보다 두 질문으로 나누고 코드에서 조합할 수 있습니다. 공식 문서는 각 Noul이 하나의 조건을 평가하도록 질문을 설계할 것을 권장합니다.[7]
공식 Quick start의 호출 경로는 POST https://api.typesafe.ai/v1/systemone이며, Python·JavaScript·TypeScript SDK도 안내합니다. 요청의 핵심은 state, model, questions이고, 같은 상태를 기준으로 여러 질문을 한 번에 평가합니다.[3]
다음은 고객지원 시스템을 위한 설계 예시입니다. 아래 흐름을 직접 구현하거나 Jev API로 실행한 결과가 아니라, 공식 primitive를 애플리케이션에 배치하는 방법을 설명하는 시나리오입니다.
💡 입력·검증 → Jev의 typed 판단 → 코드의 정책 gate → 담당자 배정 또는 검토 대기. 환불·계정 변경 같은 민감 작업에는 별도의 권한·승인 gate를 둡니다. 이 흐름은 구현 제안이며 실제 배포 사례가 아닙니다.
이 경계가 중요합니다. 모델에게 “모든 것을 알아서 해결하라”고 맡기는 대신, 애매한 의미 판단만 맡기고 금액 제한·권한·업무 순서·승인 규칙은 테스트할 수 있는 코드에 남기는 것입니다.
TypeSafe는 한 요청의 질문을 병렬 평가하므로 독립적인 질문을 추가해도 응답 시간이 거의 변하지 않는다고 설명합니다. 하지만 질문과 선택지를 늘리면 토큰 비용은 추가됩니다. “거의 같은 지연”을 “무제한·무비용”으로 받아들여서는 안 됩니다.[2][5]
또한 병렬로 평가한다는 것과 질문 A의 답을 질문 B가 받아서 추론한다는 것은 다릅니다. 공식 문서는 각 질문을 같은 상태에 대해 개별 평가한다고 설명합니다. 앞선 판단 결과나 외부 조회가 다음 판단에 꼭 필요하다면, 단계 사이의 조합과 추가 호출은 애플리케이션이 설계해야 합니다.[3][5]
probabilities는 선택지나 단계에 대한 확률 분포입니다. confidence는 그 분포를 요약해 코드에서 gate를 만들기 편하도록 제공하는 값입니다. 공식 문서에 따르면 분포가 한 결과에 몰리면 높고, 고르게 퍼지면 낮습니다. 모델이 자연어로 “저는 확신합니다”라고 말하는 것과는 다른 인터페이스입니다.[6]
특히 confidence를 “정답일 확률”과 같은 숫자로 읽으면 안 됩니다. 공식 Choice 예시에서 확률 분포가 0.6·0.3·0.1이면 confidence는 0.4입니다. 둘 다 0~1이지만 같은 값을 뜻하지 않습니다. 어느 필드에 threshold를 걸었는지 로그와 정책에 명시해야 합니다.[6]
Calibration은 또 다른 차원입니다. 비슷한 예측을 충분히 모았을 때 모델이 부여한 확률과 실제 정답 빈도가 얼마나 맞는지를 보는 성질입니다. TypeSafe는 이를 위한 RLCD 학습을 강조하지만, 이 글은 한국어 고객지원 데이터에서 calibration을 측정하지 않았습니다. 제공사의 학습 목표를 특정 도메인에서 검증된 보장으로 바꿔 읽지 않아야 합니다.[1][2]
실무에서는 자신감이 높아도 잘못된 판단이 있는지 확인해야 합니다. 선택지 설계가 빠졌거나 입력에 필요한 사실이 없다면, 타입이 맞는 결과가 나와도 실제 업무에는 부적절할 수 있습니다.
공식 confidence 문서는 결과를 자동 처리, 확인·정보 보강, 사람 또는 다른 시스템으로 이관하는 경로로 나누고, 오판의 영향에 따라 경계를 달리 둘 것을 권장합니다. 예시 숫자를 그대로 운영 기본값으로 복사하기보다 자체 데이터로 조정해야 합니다.[6]
Noul도 마찬가지입니다. yes를 잘못 판단해 실행하는 비용이 크면 기준을 높이고, 위험 신호를 놓치는 비용이 크면 기준을 낮추는 방향을 검토할 수 있습니다. 가운데 구간을 사람에게 보내는 정책도 가능합니다. 낮은 값이 무조건 불확실한 것은 아닙니다. 0에 가까운 값은 강한 no입니다.[7]
설계 의견: 담당 팀 추천과 환불 실행은 같은 threshold와 권한으로 묶지 않는 편이 안전합니다. 잘못된 배정은 되돌릴 수 있어도 금전·계정 작업은 피해가 다르므로, confidence가 높아도 승인·권한 검사를 생략하지 않습니다.
Nomad Coders 글의 제목에는 “190% 더 빠르고, 440% 더 저렴”이라는 표현이 있지만, TypeSafe 공식 발표의 대응 수치는 workflow 평가에서 193.6배 빠르고, 444.6배 저렴하다는 주장입니다. 배수와 퍼센트는 같은 표현이 아니므로 혼용하지 않습니다. 여기서는 공식 발표에 적힌 배수를 인용하되, 독립적으로 재현한 수치가 아니라는 점을 분명히 합니다.[1][2]
공식 발표는 System One 형태의 작업에서 응답 시간이 약 70500ms이며, 비교에 따라 40200배 빠를 수 있다고 주장합니다. 동시에 자체 평가는 주로 서비스가 위치한 미국 서부에서 진행했고, 가장 큰 개선 배수는 실제 이득의 상단에 가까울 것으로 예상한다고 명시합니다. 이를 한국 리전 서비스의 p95 지연 보장으로 바꿀 수는 없습니다.[2]
평가 방법도 살펴봐야 합니다. 공개된 workflow 평가는 사람이 확정한 정답 분류만을 기준으로 삼는 방식이 아니라, 외부의 대형 모델들이 예측한 확률의 평균을 reference로 사용한다고 설명합니다. 따라서 그 결과를 “현실 업무에서 같은 정확도를 보장한다”는 증거로 해석하면 범위를 벗어납니다.[2]
또한 비교 LLM은 TypeSafe API에 맞는 구조화된 판단과 확률을 내도록 하는 wrapper를 사용했습니다. 제공사는 확률 없이 결론만 생성하는 호출보다 이 방식이 느리고 비쌀 수 있다고 밝힙니다. 긴 추론을 생략한 단순 분류 baseline과 비교하면 격차가 달라질 수 있다는 점을 함께 봐야 합니다.[2]
도입 판단 의견: “어느 모델보다 몇 배 빠른가”보다 우리 요청의 입력 길이·네트워크·정확도·검토율을 포함한 결과가 중요합니다. 사용 중인 Structured Outputs 방식, 더 작은 분류 모델, 단순 규칙과 같은 조건으로 비교해야 합니다.
TypeSafe는 Doom 데모를 통해 코드와 빠른 판단 모델을 결합하는 모습을 소개합니다. 다만 입력은 게임 화면 이미지가 아니라 텍스트를 포함한 구조화된 게임 상태였다고 명시합니다. 이 데모를 “Jev가 화면을 보고 플레이한다”는 멀티모달 성능 증거로 소개하면 안 됩니다.[2]
제공사는 비 AI 봇이 게임을 더 잘할 수도 있다고 덧붙입니다. 이 데모의 의미는 최강 게임 AI가 아니라, 상태 표현과 지시에 반응하는 빠른 판단을 프로그램에 연결하는 가능성에 있습니다.[2]
Wikiracing은 위키피디아의 한 페이지에서 실제 링크만 따라 목표 페이지에 도달하는 데모입니다. 자유롭게 URL을 만들어 내는 대신 후보 중 고르게 하는 인터페이스의 장점을 보여 줍니다. 후보가 Choice 한도를 넘으면 독립 점수 평가 뒤 선택하는 두 단계 방식을 사용했다고 설명합니다.[2]
다만 이 데모에서도 비교 모델의 reasoning 설정과 작업별 조건이 속도·성공 경로에 영향을 줍니다. 공식 데모가 존재한다는 것과 실제 고객 환경에서 효과가 검증됐다는 것은 구분해야 합니다. 이 글에서는 두 데모를 제공사 공개 사례로만 다룹니다.[2]
다음은 실무 적용 제안이며, Jev 고객 도입 성과나 직접 측정한 결과가 아닙니다. 공통점은 명확한 선택지나 기준이 있고, 최종 실행을 코드로 제한할 수 있다는 것입니다.
여기서 얻어야 할 답은 “모델이 멋진가”가 아니라 같은 품질 조건에서 전체 시스템이 더 단순하고 안전해지는가입니다. 검토 대기가 너무 늘거나 오판 비용이 크다면 더 빠른 추론만으로 도입을 정당화할 수 없습니다.
Jev는 자유 문장 생성, 긴 설명, 다단계 숙고를 모두 맡기는 범용 대화 모델이 아닙니다. 공식 발표도 early access 제품으로 소개합니다. 현재 읽은 문서의 기능과 특정 시점·계정의 실제 사용 가능 범위가 같다고 가정하지 말고 도입 시 확인해야 합니다.[1][2]
외부 API에 보내는 데이터의 보관·학습 사용·리전·삭제 정책은 별도 검토 대상입니다. 이 글은 관련 계약·보안 심사를 수행하지 않았습니다. 결제 기록이나 사내 로그를 전송하기 전에 데이터 최소화와 조직 정책 준수 여부를 확인해야 합니다.
빠른 판단 모델이어도 입력의 사실성을 보증하지는 않습니다. “두 번 청구됐다”는 고객 메시지에서 그런 주장을 감지하는 일과, 결제 원장에서 중복 거래를 확정하는 일은 다릅니다. 후자는 authoritative source를 조회하는 애플리케이션의 책임입니다.
더 단순한 대안도 먼저 확인해야 합니다. 규칙 몇 개로 충분한 작업에는 규칙을 쓰고, 안정적인 라벨과 학습 데이터가 충분하면 기존 분류기도 비교합니다. 설명 생성까지 필요하고 현재 Structured Outputs 호출로 요구사항을 충족한다면, 새 의존성을 추가하지 않는 선택도 합리적입니다.
Jev의 핵심은 “AI가 사람처럼 말해야 하는가?”라는 전제를 바꾸는 데 있습니다. 비정형 입력을 이해하되 결과는 Choice·Score·Noul로 제한하고, 확률과 불확실성을 코드가 처리할 수 있게 노출합니다.[1][2][3]
개발자가 가져갈 설계 원칙은 세 가지입니다. 첫째, 모델의 판단 단위를 작고 명확하게 나눕니다. 둘째, 확률·confidence·정확도를 구분합니다. 셋째, 실행 권한과 비즈니스 정책은 코드와 승인 절차에 남깁니다.
Jev를 평가할 이유는 화려한 속도 배수 하나가 아닙니다. 애매한 판단만 모델에 맡기고 나머지는 읽고 테스트할 수 있는 소프트웨어로 유지할 수 있는가가 더 중요한 기준입니다.
💡 🔎 검증 범위: 표시 발행일은 2026-10-18이며, 본문 작성과 자료 확인은 2026-10-19에 수행했습니다. Nomad Coders 해설과 TypeSafe 공식 발표·문서를 읽고 대조했으며, Jev API 호출·SDK 설치·성능 재현·한국어 정확도 측정은 수행하지 않았습니다. 문서의
jev-latest는 고정 버전이 아니며, Quick start 응답 예시에는jev-1.13.0이 등장하지만 이는 이 글이 해당 버전을 직접 시험했다는 뜻이 아닙니다. 성능 수치는 제공사 주장이고, 적용 흐름은 별도로 표시한 설계 제안입니다.[2][3]
[1] https://nomadcoders.co/ax/reports/jev — Jev – AX School
[2] https://typesafe.ai/blog/introducing-system-one-models-and-jev — Introducing System One Models & Jev - TypeSafe AI Blog
[3] https://docs.typesafe.ai/introduction/quickstart — Quick start - TypeSafe
[4] https://docs.typesafe.ai/primitives/score — Score - TypeSafe AI
[5] https://docs.typesafe.ai/primitives/choice — Choice - TypeSafe AI
[6] https://docs.typesafe.ai/confidence — Confidence - TypeSafe
[7] https://docs.typesafe.ai/primitives/noul — Noul - TypeSafe