선택과 점수로 답하는 AI, Jev: 무엇이 다르고 어디에 쓸까?

먼저 질문: AI가 매번 긴 답을 써야 할까?

고객 문의가 들어올 때마다 필요한 답은 의외로 짧을 수 있습니다.

• 결제 문의인가, 기술 문의인가?
• 지금 사람이 봐야 할 만큼 급한가?
• 환불을 요청했는가?
• 값싼 AI로 처리해도 되는가, 더 강한 AI가 필요한가?

이런 질문에 필요한 것은 설명문이 아니라 선택, 점수, 예·아니오입니다. 그런데 지금의 대규모 언어 모델(LLM)은 기본적으로 문장을 한 토큰씩 만들어 사람에게 읽힐 답을 쓰도록 설계됐습니다. 소프트웨어는 그 문장을 다시 읽고 필요한 값을 꺼내야 합니다.

TypeSafe AI가 2026년 9월 공개한 Jev는 이 순서를 바꾸려는 모델입니다. 긴 문장을 쓰지 않고, 프로그램이 바로 사용할 수 있는 제한된 판단과 확률을 반환합니다.[1][2]

한 문장으로 말하면

Jev는 챗봇이라기보다, 애매한 문장을 읽어 확률이 붙은 체크박스로 바꾸는 ‘똑똑한 if문’에 가깝습니다.

일반 if문은 “결제 금액이 10만 원보다 큰가?”처럼 정확한 규칙을 처리합니다. 하지만 “이 고객이 많이 화났는가?”처럼 말의 의미를 읽어야 하는 판단은 어렵습니다. Jev는 그 애매한 구간을 맡고, 실제 라우팅·승인·실행은 코드가 담당합니다.

무엇을 보내고 무엇을 받을까?

Jev 호출은 크게 두 부분입니다.

1. 상태(state): 판단할 자료입니다. 고객 메시지, 주문 정보, 에이전트 실행 기록처럼 문자열이나 JSON 형태의 텍스트를 넣습니다.
2. 질문(questions): 어떤 판단을 원하는지 미리 정합니다.

공식 문서는 세 가지 질문 유형을 제공합니다.[2]

Choice: 정해진 후보 중 고르기

예를 들어 고객 문의를 결제 / 기술 / 영업 / 기타 중 하나로 분류합니다. 가장 가능성이 높은 선택뿐 아니라 각 후보의 확률과 전체 분포를 요약한 confidence를 함께 받을 수 있습니다.

Score: 순서가 있는 단계로 평가하기

예를 들어 고객 감정을 차분함 / 불만 / 매우 화남으로 평가합니다. 정확한 금액이나 개수 대신, 사람이 만든 등급표에 얼마나 가까운지를 묻는 방식입니다.

Noul: 예에 가까운지 아니오에 가까운지

예를 들어 “환불을 요청했는가?”를 0과 1 사이의 확률로 받습니다. 1에 가까울수록 예, 0에 가까울수록 아니오에 가깝습니다.

여러 질문은 같은 상태를 보면서 한 요청 안에서 각각 독립적으로 평가됩니다. 질문 하나의 답이 다음 질문의 숨은 맥락이 되지는 않습니다. 마지막 결정은 코드가 확률과 규칙을 조합해 내립니다.[2]

아주 쉬운 예: 고객 문의 한 건

고객이 이렇게 썼다고 해보겠습니다.

“카드가 두 번 결제됐습니다. 오늘 안에 환불해 주세요.”

Jev에는 다음처럼 좁은 질문을 함께 보낼 수 있습니다.

• 담당 팀은 결제 / 기술 / 영업 / 기타 중 어디인가?
• 긴급도는 0~3점 중 몇 점인가?
• 환불을 요구했는가?
• 감정 강도는 어느 단계인가?

Jev가 답을 만들면 일반 코드는 이렇게 행동할 수 있습니다.

• 결제 문의이면서 환불 확률이 높으면 결제 담당함으로 이동
• 긴급도가 높으면 위쪽에 정렬
• 확신이 낮으면 자동 처리하지 않고 사람이 확인
• 실제 환불 실행은 권한·금액·정책을 코드로 다시 검사한 뒤 별도 승인을 요청

중요한 점은 Jev가 환불을 실행하지 않는다는 것입니다. Jev는 애매한 의미를 좁은 값으로 바꾸고, 권한과 부작용은 코드와 사람이 관리합니다.

어디에 활용할 수 있을까?

현재 공개된 사례는 대규모 장기 운영 사례보다 초기 구현과 실험이 중심입니다. 그 전제를 두면 다음 활용법이 보입니다.

1. 어떤 AI 모델을 쓸지 고르기

LangChain은 Jev를 에이전트 앞의 라우터로 쓰는 예를 공개했습니다. 간단한 조회는 빠르고 값싼 모델로, 설계나 고위험 판단은 더 강한 모델로 보냅니다. Jev는 모델을 고를 뿐이고, 실제 글쓰기와 복잡한 추론은 선택된 LLM이 수행합니다.[7]

2. 도구를 실행하기 전에 위험을 검사하기

명령줄이나 외부 도구 호출이 위험해 보이는지 먼저 판단하고, 위험한 호출을 막는 중간 장치로 사용할 수 있습니다. 다만 분류기가 막았다는 사실이 곧 안전을 보장하지는 않습니다. 삭제·결제·외부 발송처럼 되돌리기 어려운 행동에는 별도의 사람 승인과 권한 검사가 필요합니다.[7]

3. 브라우저에서 다음 행동 고르기

독립 오픈소스 jev-browser는 현재 페이지의 클릭·입력·선택 후보를 모은 뒤 Jev가 다음 행동을 고르게 합니다. 코드는 단계 수와 시간 예산, 멈춤 조건을 관리하고, 새 검색어나 폼 문장이 필요할 때는 별도의 작은 생성 모델을 사용합니다.[12]

저장소는 Wikipedia의 Coffee 문서에서 Espresso 문서로 약 4초, 약 0.0016달러에 이동한 예를 공개했습니다. 그러나 240개 요소 제한, iframe·shadow DOM·hover 메뉴 미지원 등 초기 소프트웨어의 제약도 함께 명시합니다.[12]

4. 이메일을 분류하고 우선순위 정하기

이메일마다 종류, 답장 필요, 긴급도, 피싱 가능성, 환불 요청 여부를 한 번에 물을 수 있습니다. Jev는 신호를 만들고, 코드는 정렬과 임계값을 적용하며, 실제 답장과 애매한 사례는 사람이나 생성형 AI가 맡습니다.

피싱 이메일 2,000건을 사용한 독립 공개 실험에서는 Jev의 한 번짜리 종합 판정 정확도가 Claude Haiku 4.5보다 낮았습니다. 반면 다섯 개의 좁은 신호를 한 번에 묻고 단순한 회귀 모델이 합치자 높은 성능이 나왔습니다. 다만 이 데이터셋은 간단한 정규식만으로도 91.8%를 맞힐 만큼 URL 패턴이 강했고, Jev와 Haiku의 결합 방식 차이도 통계적으로 확정되지 않았습니다.[9]

이 결과는 “Jev가 언제나 더 정확하다”보다 큰 질문 하나를 맡기지 말고, 여러 개의 좁은 신호를 뽑아 코드로 합치라는 사용법을 지지합니다.

5. AI 에이전트의 결과를 채점하기

LangChain은 다섯 개의 고정된 날씨 에이전트 실행 결과를 각 모델이 100번씩 평가하도록 한 초기 실험을 공개했습니다. Jev는 이 좁은 데이터에서 사람의 통과·실패 판정과 500회 모두 일치했고, 평균 0.44초와 호출당 0.00035달러를 기록했습니다.[11]

유망한 결과이지만 사례가 다섯 개뿐이고, 한 명의 사람이 만든 기준을 반복 평가한 시험입니다. 실제 제품의 다양한 실패를 잘 잡는다는 증거로 확대하면 안 됩니다.

속도와 비용 수치는 어떻게 읽어야 할까?

TypeSafe 홈페이지는 Jev가 193.6배 빠르고 444.6배 저렴하다고 소개합니다. 이 수치는 모든 LLM 작업의 평균이 아니라, 회사가 만든 네 가지 System One형 워크플로 평가에서 나온 높은 쪽 결과입니다.[1]

평가 방식에도 중요한 조건이 있습니다. 보안 사고, 에이전트 실행 기록, 송장, 고객 서비스의 네 워크플로에서 실제 사람 정답 대신 GPT-6 Astra와 Claude Fable 5.1의 고심 모드 판단 평균을 기준으로 삼았습니다. 즉 “현실의 정답을 얼마나 맞혔나?”보다 “두 강한 모델의 판단과 얼마나 비슷한가?”에 가깝습니다.[5]

회사도 이 워크플로를 내부 팀이 만들었으므로 편향 가능성이 있고, 193.6배·444.6배는 실제 이득의 높은 쪽일 것으로 예상한다고 설명합니다.[1]

한 독립 공개 실험은 300개씩의 의도 분류, 긍·부정 판단, 5단계 감정 분류에서 Jev와 GPT-5.6 Terra를 비교했습니다. 기본 설정 기준 Jev의 중앙 응답 시간은 약 5.25.5배 빨랐고, 호출 비용은 비교 모델의 약 2.02.4%였습니다. 정확도는 의도 분류에서 Jev 0.780, Terra 0.847이었고, 이진 긍·부정은 둘 다 0.970, 5단계 감정은 Jev 0.570, Terra 0.593이었습니다.[8]

이 실험도 최근의 소규모 공개 개발자 평가이며 동료심사 연구는 아닙니다. 가장 안전한 결론은 다음 정도입니다.

좁은 분류 과제에서는 Jev가 상당히 빠르고 저렴할 가능성이 보이지만, 정확도와 확률의 신뢰도는 각 데이터·언어·질문 형식으로 다시 측정해야 합니다.

“환각 0”이라는 말은 정확할까?

TypeSafe는 Jev를 설명하며 “환각이 없다”는 표현을 씁니다. 그러나 출시 글의 세부 설명을 보면 0% 수치는 실제 표본에서 오답이 없었다는 측정값이 아니라 스키마에 맞지 않는 출력을 만들 수 없도록 설계했다는 뜻입니다.[1]

예를 들어 선택지가 결제 / 기술 / 영업 / 기타라면, Jev는 갑자기 긴 시를 쓰거나 존재하지 않는 부서명을 반환하지 않습니다. 이 형식 보장은 자동화에 가치가 있습니다.

하지만 결제가 정답인데 기술을 고를 수는 있습니다. 형식 안에서 틀린 선택을 하는 것은 여전히 가능합니다. 따라서 공개 글에서는 이렇게 표현하는 편이 정확합니다.

Jev는 출력 형식을 보장하지만, 판단의 사실적 정확성까지 보장하지는 않습니다.

Jev가 직접 밝힌 약점

Jev 1.13의 공식 약점 문서는 다음 작업을 코드나 다른 모델에 맡기라고 권합니다.[4]

• 개수 세기와 계산, 정밀한 숫자 처리
• 날짜의 선후와 기간 비교
• 여러 단계를 건너가는 간접 추론
• 불필요한 내용이 많은 긴 상태
• 모델을 속이려는 적대적 입력
• 서로 모순되는 지시와 평가 기준
• 자유로운 글과 코드 생성

또한 영어가 주 훈련 언어이며 CJK를 포함한 다른 언어는 처리하지만 같은 수준의 성능을 보장하지 않는다고 밝힙니다.[3] 한국어 업무에 쓰려면 영어 결과를 그대로 가져오지 말고 한국어 실제 문장으로 별도 평가해야 합니다.

확신도는 정답 보증서가 아니다

Jev의 Choice와 Score는 후보별 확률분포와 confidence를 제공합니다. 분포가 한 후보에 몰리면 confidence가 높고, 후보들 사이에 퍼져 있으면 낮습니다.[6]

하지만 0.95라는 한 번의 숫자가 그 사례의 정답을 보장하지 않습니다. 확률 보정은 많은 예측을 모았을 때 0.95라고 한 집단이 실제로도 비슷한 비율로 맞는지 확인해야 하는 통계적 성질입니다. 공식 문서도 임계값을 각 서비스의 데이터와 위험에 맞게 보수적으로 시험하라고 권합니다.[6]

Jev의 모델 별칭인 jev-latest도 새 버전이 나오면 가리키는 대상이 바뀔 수 있습니다. 임계값을 맞춘 서비스라면 jev-1.13.0처럼 버전을 고정하고 새 버전을 별도로 검증해야 합니다.[3]

데이터는 어디로 갈까?

Jev는 호스팅형 API입니다. 판단하려는 고객 메시지·문서·로그는 TypeSafe 서버로 전송됩니다.

TypeSafe는 고객 요청과 응답으로 Jev를 학습하거나 파인튜닝하지 않는다고 밝힙니다.[3][10] 그러나 개인정보처리방침은 프롬프트, 데이터, 지시 등 입력을 수집하며 서비스 제공이나 사업상 필요한 기간 보유할 수 있다고 설명합니다.[10] 기본적인 무저장 서비스와 같은 뜻은 아닙니다. 공식 법률 안내는 제로 데이터 보관(ZDR)을 기업 고객용 선택지로 소개합니다.

따라서 고객 식별정보, 계약서, 의료·금융 자료, 비공개 소스코드를 보내기 전에는 보관 기간, 처리 지역, 하위 처리업체, 삭제 방식, ZDR 조건을 계약 수준에서 확인해야 합니다.

가격과 접근 상태

2026년 9월 21일 공식 모델 문서에서 확인되는 Jev 1.13의 공개 가격과 한도는 다음과 같습니다.[3]

• 입력: 100만 토큰당 0.042달러
• 출력: 과금하지 않음
• 텍스트 입력만 지원
• 요청당 64k 토큰, 상태와 가장 긴 질문 조합은 32k 토큰
• 초당 25만 토큰, 분당 1,200요청

TypeSafe는 수요와 GPU 용량에 따라 이 한도가 예고 없이 바뀔 수 있다고 경고합니다. Jev는 공식 출시 글에서 early access로 소개됐고, 현재 공개 문서는 로그인 뒤 Playground와 API 키 발급 절차를 안내합니다. 하지만 비로그인 상태만으로는 신규 가입자가 즉시 API 권한과 무료 크레딧을 받는지 확인할 수 없습니다.[1][3]

우리에게 맞는 가장 작은 실험

처음부터 메일 발송, 삭제, 결제 같은 행동을 자동화할 필요는 없습니다. 과거 자료로 판단 품질만 확인하는 오프라인 시험이 먼저입니다.

1. 과거 사례 100건과 사람이 정한 정답을 준비합니다.
2. 선택지는 3~5개로 제한하고 모르겠음 / 사람 확인을 넣습니다.
3. 큰 질문 하나 대신 3~7개의 좁은 질문으로 나눕니다.
4. 금액, 날짜, 개수, 권한은 코드가 처리합니다.
5. jev-latest 대신 시험한 정확한 버전을 고정합니다.
6. 낮은 confidence는 자동 처리하지 않습니다.
7. 평균 정확도와 함께 치명적인 오분류 수, 사람 검토량, 비용, 지연시간을 기록합니다.
8. 외부 발송·삭제·결제는 끝까지 꺼 둡니다.

성공 기준은 “빠르게 돌아갔다”가 아니라, 사람이 검토해야 할 양을 줄이면서 중요한 오분류를 늘리지 않았는가입니다.

결론

Jev의 의미는 더 똑똑한 챗봇이 하나 늘었다는 데 있지 않습니다. 글을 생성하는 모델과 결정을 만드는 모델의 역할을 나누자는 제안에 가깝습니다.

잘 맞는 자리는 분명합니다. 같은 자료에서 여러 개의 좁은 판단을 빠르게 뽑고, 코드가 임계값과 권한을 관리하며, 생성형 AI와 사람이 복잡한 설명과 예외를 맡는 구조입니다.

다만 지금은 공개 직후의 early access 제품입니다. 회사의 큰 배수는 내부 워크플로 평가이고, 독립 실험도 아직 작고 최근입니다. 출력 형식 보장은 판단 정답 보장이 아니며, 한국어·민감정보·고위험 행동은 별도 검증이 필요합니다.

그래서 현재의 실용적인 판단은 이렇습니다.

Jev를 ‘자동 결정을 맡길 완성품’으로 보기보다, 과거 사례 100건에서 값싼 판단 신호를 만들어 사람 검토량을 줄일 수 있는지 시험할 후보로 보는 편이 맞습니다.