Jev란? 업무 시스템에 판단형 AI를 붙이는 방법

고객이 보낸 문의를 읽고 담당 부서를 고르거나, 검색 요청을 보고 어떤 문서부터 찾을지 정하는 일. 업무 시스템에는 문장을 새로 쓰기보다 주어진 정보에서 다음 행동을 골라야 하는 순간이 많습니다.

TypeSafe AI가 2026년 9월 15일 공개한 Jev는 이런 판단을 소프트웨어에 연결하는 AI 모델입니다. 회사는 이 계열을 System One 모델이라고 부릅니다. 자유로운 답변 문장 대신 미리 정한 형식의 결과를 돌려주도록 설계했습니다. TypeSafe 공식 발표

이 글은 2026년 9월 23일 확인한 공식 문서를 바탕으로 작성했습니다. 아래 업무 예시는 적용 방식을 설명하기 위한 가정이며, 루브릭랩스가 Jev를 구축하거나 성능을 측정한 사례는 아닙니다.

Jev에 넘기는 것은 업무 상태와 질문

Jev에는 판단할 자료인 state와 형식을 정한 질문을 전달합니다. 결과는 코드에서 조건 분기나 정렬에 사용할 수 있는 값으로 돌아옵니다. 질문은 한 번에 한 가지를 판단하도록 좁히고, 여러 결과를 결합하는 규칙은 개발자가 코드로 작성하는 방식입니다. 공식 시작 문서

고객 문의를 처리한다고 가정해 보겠습니다. 긴 답변을 요청하는 대신 담당 부서, 환불 요청 여부, 문의의 긴급도를 각각 묻습니다. 담당 부서를 고른 결과로 작업 목록에 배정하고, 환불 요청은 별도의 확인 절차로 보낼 수 있습니다. 고객에게 보낼 답변 작성까지 필요하다면 그 단계는 사람이 맡거나 텍스트 생성 모델을 연결합니다.

선택, 점수, 참과 거짓을 구분한다

공식 문서가 제공하는 질문 유형은 세 가지입니다. 아래 질문은 이해를 돕기 위해 구성한 예시입니다.

Choice는 정해진 선택지 중 하나를 고릅니다. 선택지마다 포함할 상황을 설명하고, 어느 항목에도 맞지 않는 입력을 받을 수 있도록 기타 항목을 두는 편이 좋습니다.

Score는 순서가 있는 단계별 기준으로 평가합니다. 예를 들어 긴급도를 낮음, 중간, 높음이라고만 쓰기보다 정상 이용 가능, 일부 기능 중단, 업무 전체 중단처럼 상태로 정의합니다. 점수는 단계 번호에 각 확률을 곱해 더한 값이므로 단계 사이의 소수가 나올 수 있습니다. 고객 중 몇 퍼센트가 피해를 봤는지처럼 별도의 비율로 읽으면 안 됩니다.

Noul은 질문의 답이 참일 확률을 반환하며 별도 confidence 필드는 없습니다. 환불 요청 여부처럼 예 또는 아니오로 답할 질문에 사용합니다. 0에 가까우면 아니오 쪽, 1에 가까우면 예 쪽으로 판단했다는 의미입니다. 값이 0.5에 가깝다고 해서 환불 의사가 절반 정도라는 뜻은 아닙니다.

업무 시스템에 붙인다면 문의 배정부터

다음은 의류 쇼핑몰의 고객 문의를 분류하는 가정한 흐름입니다.

1. 문의 본문과 판단에 필요한 주문 상태를 준비합니다. 개인정보 등 불필요한 데이터는 제외합니다.
2. 문의 종류를 고르는 질문과 환불 요청 여부를 확인하는 질문을 분리합니다.
3. 분류 결과와 불확실성을 보고 담당 부서에 배정하거나 수동 검토 목록에 넣습니다.
4. 환불 가능 기간, 결제 취소 권한, 실제 처리 여부는 기존 시스템의 규칙으로 확인합니다.

문의에 배송 지연과 결제 문제가 함께 적혀 있다면 한 부서만 고르는 질문으로 충분한지부터 검토해야 합니다. 부서별 처리 필요성을 각각 묻거나 복합 문의를 따로 받는 방법도 있습니다. AI가 배정한 뒤 담당자가 다시 옮긴 기록을 남기면 어떤 질문이나 선택지가 모호한지 확인하기 쉽습니다.

문서 검색에도 비슷한 구조를 시험해 볼 수 있습니다. 가령 사용자의 질문을 사내 규정, 제품 매뉴얼, 계약 관련 자료 중 어느 검색 범위로 보낼지 분류하는 방식입니다. 이는 이 글에서 제안하는 적용 예시입니다. 검색 대상이 정해진 뒤 실제 문서를 찾고 접근 권한을 확인하는 기능은 별도로 필요하며, 근거를 읽고 답변을 생성하는 RAG 단계도 따로 구성해야 합니다.

confidence를 정답률로 읽지 않는다

Choice와 Score의 confidence는 반환된 확률 분포를 요약한 값입니다. 특정 결과에 확률이 몰리면 높아지고, 여러 결과로 퍼지면 낮아집니다. 공식 문서는 업무의 위험도와 자체 데이터 평가 결과에 따라 자동 처리, 추가 확인, 수동 검토의 기준을 정하도록 안내합니다. Confidence 문서

따라서 confidence가 0.9라고 해서 우리 업무에서 90%의 정답률이 검증됐다고 볼 수는 없습니다. Score 문서도 높은 confidence가 답의 정확성을 보장하지 않는다고 설명합니다. Score 결과 해석

도입을 검토한다면 실제 문의에서 평가용 자료를 분리하고 담당자가 기대하는 처리 결과를 먼저 적어 두는 방법을 권합니다. 잘못 배정한 비율, 사람이 다시 확인한 비율, 판단을 보류한 비율을 함께 보면 자동화 범위를 정하는 데 도움이 됩니다. 질문이나 모델 버전을 바꿨을 때도 같은 자료로 비교해야 합니다.

빠르다는 발표와 실제 도입 판단은 구분해야 한다

TypeSafe는 출시 글에서 속도와 비용의 이점을 강조하지만, 평가 환경과 비교 방식의 제약도 공개했습니다. 짧은 입력이 자사 모델에 유리하게 작용한 데모가 있고, 홈페이지의 개선 배수는 실제 환경에서 얻을 수 있는 효과의 높은 쪽에 해당할 것으로 설명합니다. 발표 수치를 우리 시스템의 예상 성과로 옮겨 쓰기 어려운 이유입니다. 공식 발표의 평가 조건

검토할 때는 API 호출 하나의 응답시간에 더해 자료 준비, 기존 시스템 조회, 재시도, 사람의 확인까지 걸리는 시간을 함께 재는 편이 좋습니다. 명확한 업무 규칙으로 해결되는 항목은 규칙으로 처리하고, 표현이 다양해 규칙을 유지하기 어려운 판단 한 곳을 골라 Jev와 비교해 볼 수 있습니다.

문의 배정부터 시험한다면 자동으로 처리해도 되는 문의와 사람이 확인해야 하는 문의를 먼저 나누면 됩니다. 그 경계를 실제 데이터로 확인한 뒤 주문 변경이나 환불처럼 영향이 큰 업무로 범위를 넓힐지 결정하는 순서가 적절합니다.