Jev (판단 전용 AI 모델) 입문 – 발표자료 다운로드

Jev를 쓴다는 말은 모델을 바꾼다는 뜻이 아니라 생성과 판정을 다른 부품에 맡긴다는 뜻이다. 생성형 LLM은 문장을 만들고, 그 문장을 파싱해야 코드가 분기한다. 판단 전용 AI 모델은 선택지 가운데 하나와 확률을 바로 돌려주므로 파싱 단계가 통째로 빠진다.

전체 78장, PDF로 78쪽이다. 1부는 채팅용 LLM을 판단기로 쓸 때 생기는 병목과 Jev의 정의, 이름의 유래를 다룬다. 2부는 state와 questions로 이루어진 입출력 구조와 Choice, Score, Noul 세 판단 유형, 질문 설계 원칙, 요금 구조를 다룬다. 3부는 TypeSafe AI의 창업진과 투자 현황, 제3자 벤치마크를 검증 수준별로 나눠 본다. 4부는 라우팅, 대량 처리, 실시간 판단, 에이전트 가드 네 분야의 적용 설계도를 다룬다. 5부는 공식 문서가 밝힌 약점 아홉 가지와 역할 분담 기준을, 6부는 JevBench 순위와 GPU 메모리 요구량으로 본 오픈소스 대안을 다룬다.

원 자료의 수치 가운데 공식 문서와 어긋난 것은 장마다 정정 표시를 달았다. 확신도가 모든 답에 붙는다는 설명, 합이 147%인 확률 예시, 비용 배수 표기가 그런 경우다. 벤더 자체 평가와 독립 측정, 확인하지 못한 항목도 장마다 구분해 두었다.

사내 검토 자료나 팀 스터디 자료로 바로 쓸 수 있도록 원본 구성 그대로 PDF로 공개한다.

판단 모델을 사내 GPU에 올리려면 GPU 한 장을 여러 워크로드가 나눠 쓰는 방법부터 정해야 한다. 발표자료 6부가 다루는 4B급 오픈 모델은 GPU 메모리 3~5GB면 올라가므로, 카드 한 장을 통째로 주는 방식으로는 대부분이 유휴로 남는다.

아래 영상은 클라우드네이티브TV가 올린 쿠버네티스 DRA 3편이다.

이 영상은 Jev 발표의 녹화본이 아니다. 판단 모델을 자체 호스팅할 때 맞닥뜨리는 GPU 공유 문제를 6분 43초로 정리한 영상이고, 다루는 순서는 다음과 같다.

• 전용 할당, Time-slicing, MPS, MIG 네 가지 GPU 공유 방식
• 기술별 격리 범위와 동시 실행의 차이
• 요청 단위로 고르는 공유 방식 설정
• NVLink와 토폴로지 조건을 배치에 반영하는 방법
• 쿠버네티스 v1.36까지 추가되는 확장 기능

판단 모델의 호출 단가만 보고 자체 호스팅을 정하면 GPU 유휴 비용이 계산에서 빠진다. LLM을 사내에서 서빙할 때의 병목과 비용 구조는 AI LLM 가속 엔진 vLLM에서 먼저 정리했다.

에이전트와 자동화 설계 회의에서 반복해서 나오는 질문을 기준으로 슬라이드를 배치했다.

1. Jev는 LLM과 무엇이 다른가
2. Choice와 Score와 Noul은 언제 갈라 쓰는가
3. 확신도는 모든 답에 붙는가
4. Jev의 요금과 응답 시간은 얼마인가
5. 한국어 업무에 바로 쓸 수 있는가
6. Jev를 보안 가드로 단독 사용해도 되는가
7. 오픈소스 대안으로 바꿀 수 있는가

답이 정해진 판단에 생성형 LLM을 부르면 지연과 비용과 파싱 부담이 한꺼번에 붙는다. 실행하려는 명령이 위험한가, 도착한 문의의 담당은 누구인가 같은 판단은 예와 아니요, 또는 부서 이름 하나면 충분하다. 그런데 LLM에 물으면 매번 정중한 설명 문단이 돌아온다.

원인은 생성 방식에 있다. LLM은 토큰 하나를 만들 때마다 모델 전체를 한 번씩 돌린다. JSON 한 줄을 받으려 해도 토큰 수만큼 반복하고, 다 쓸 때까지 기다린 뒤에야 파싱과 검증을 시작한다. 형식이 깨지거나 설명이 섞이면 재시도 코드까지 필요하다. 원 자료는 한 에이전트에 모든 일을 맡길 때의 병목을 네 가지로 꼽는다. 거대한 컨텍스트 처리 부담, 도구 실행의 불확실성, 모델 선택의 시행착오, 사람의 감사와 승인 대기다. 네 병목의 공통 원인은 생성과 판정을 한 모델이 모두 떠안는 구조이고, 모델을 키워도 비용과 지연과 승인 대기가 함께 늘어난다.

▲ 부서 하나를 고르는 판단에도 LLM은 수십 초와 파싱 코드를 요구한다 (발표자료 6쪽)

Jev는 상황을 담은 state와 선택지가 정해진 questions를 받아 답과 선택지별 확률을 돌려준다. TypeSafe AI는 이런 모델 부류를 System One Model이라 부르고, 비정형 상태를 받아 타입이 정해진 확률적 결정을 단일 병렬 패스로 반환하는 모델이라고 정의한다. Jev가 그 첫 모델이다.

TypeSafe AI 공식 문서에 따르면 현행 모델은 jev-1.13.0이고 요청당 컨텍스트는 64k 토큰이며, 선택지는 최대 255개까지 정의할 수 있다. 입력은 텍스트만 받는다. 이미지와 음성과 영상은 받지 않고, 자유 문자열은 한 글자도 생성하지 않는다. 문자열을 만들지 않으니 파싱 실패나 형식 깨짐이 구조적으로 없다. 대신 선택지 밖의 답은 처음부터 나올 수 없다. 질문 설계가 곧 품질이라는 뜻이다.

여기서 한 가지를 분리해 둔다. 타입이 맞는다고 값이 맞는 것은 아니다. 형식 보장과 정확도 보장은 별개이고, 형식이 맞는 오답은 그대로 업무 흐름에 들어간다. 생성 모델과 판별 모델의 원리 차이는 생성형 AI와 판별형 AI에서 먼저 정리했다.

▲ state와 questions를 넣으면 타입이 정해진 답과 확률만 돌아온다 (발표자료 10쪽)

System One이라는 이름은 대니얼 카너먼이 구분한 빠르고 직관적인 사고에서 왔다. 수학 문제를 풀거나 코드를 짜는 느리고 신중한 사고가 시스템 2이고, 보는 즉시 나오는 판단이 시스템 1이다. 지금까지의 LLM과 추론 모델은 모두 시스템 2 쪽을 흉내 냈고, 반사처럼 즉시 끝나야 하는 판단을 맡길 모델은 없었다.

모델 이름 Jev는 경제학자 윌리엄 스탠리 제번스에서 왔다. 증기기관 효율이 오르자 석탄 소비가 줄지 않고 늘었다는 제번스 역설처럼, 판단이 싸지면 판단을 부르는 곳이 늘어난다는 전망이 이름에 담겨 있다. 호출 단가가 도입 범위를 정하는 변수라는 가설이다.

학습 방식도 방향이 다르다. 채팅 모델은 사람의 선호에 맞추는 RLHF로 학습했고, TypeSafe AI는 예측 확률이 실제 적중 빈도와 맞도록 보정하는 RLCD를 내세운다. 다만 RLCD는 논문과 보상 함수와 데이터셋이 공개되지 않은 벤더 고유 용어다. 보정이 우리 데이터에서도 맞는지는 직접 재 봐야 한다.

▲ 기존 LLM은 느린 숙고를 맡고 Jev는 즉시 끝나는 판단을 맡는다 (발표자료 11쪽)

답에 확률이 붙으면 코드는 신뢰도를 보고 자동 처리와 사람 검토를 나눌 수 있다. 같은 고객 문의를 LLM에 물으면 이런저런 가능성을 적은 긴 글이 오고, 얼마나 확신하는지는 알 수 없다. Jev는 보기 이름과 확률 한 줄을 돌려준다.

신뢰도가 높으면 코드가 곧바로 배정하고, 낮으면 검토 대기열로 보낸다. 임계값은 호출하는 쪽 코드에서 정하며 업무 위험도가 클수록 높게 잡는다. 사람이 모든 건을 보던 루프가 예외 건만 보는 루프로 줄어든다.

낮은 확신도를 더 큰 모델로 넘기는 설계는 근거가 약하다. 고객 문의 분류를 잰 독립 실험에서 확신도가 낮은 건을 큰 모델로 넘기자 정확도가 0.7%p 떨어졌다. 확신도는 사람에게 넘길 시점을 정하는 신호로 쓰는 편이 근거가 있다.

▲ 신뢰도가 높으면 코드가 처리하고 낮은 건만 사람에게 넘긴다 (발표자료 18쪽)

질문 유형은 세 가지이고 유형마다 반환 값의 모양이 다르다. Choice는 어느 것인가를 묻고, 정의한 선택지 전체의 확률 분포를 돌려준다. 코드에서는 후보별 경로로 갈리는 switch 문에 대응하며 담당자 배정이나 모델 라우팅에 쓴다. Score는 어느 단계인가를 묻고, 말로 기술한 루브릭 위의 점수를 돌려준다. 단계는 2~10개로 정의하고 점수를 임계값과 비교해 분기한다. Noul은 그렇다고 말할 수 있는가를 묻고, 명제가 참일 확률 하나를 돌려준다. if 문에 대응하며 실행 허가나 승인 게이트에 쓴다.

중요한 차이는 확신도다. 확신도는 Choice와 Score에만 붙고 Noul에는 없다. 원 자료는 모든 답에 확신도가 붙는다고 설명했지만 공식 문서와 다르다. 그래서 사람에게 넘길 문턱을 하나로 통일할 수 없고, Noul로 게이트를 만들 때는 Yes 확률 자체에 문턱을 걸어야 한다.

Score의 점수는 단계별 확률의 가중 평균이다. 세 단계의 확률이 0.1, 0.2, 0.7이면 점수는 1.6이 된다. 서로 다른 분포가 같은 점수를 만들 수 있으므로 점수와 확신도를 함께 봐야 두 단계 사이에서 갈린 건을 놓치지 않는다.

▲ Choice는 switch 문에, Score는 임계값 비교에, Noul은 if 분기에 대응한다 (발표자료 21쪽)

Score의 0.5는 정도의 크기이고 Noul의 0.5는 판단이 서지 않았다는 뜻이다. Score에서 0.5는 보통과 이르게 사이의 어느 지점이다. Noul에서 0.5는 참인지 거짓인지 반반이라는 뜻이고, 중간 정도라는 의미가 없다. 이 값을 등급처럼 읽으면 임계값 설계가 통째로 어긋난다.

정도를 묻는 판단은 Score로, 참과 거짓을 가르는 판단은 Noul로 묻는다. Noul 질문은 의문문보다 평서 명제로 적는 편이 해석이 분명하다. 우려가 있는가라고 묻기보다 우려가 문의에 명시되어 있음이라고 적는다. 공식 지침도 한 질문에 한 가지 즉답 판단만 담으라고 권한다. 요인이 여럿이면 요인별로 따로 묻고 코드에서 가중치로 결합한다.

▲ Score의 0.5는 정도의 크기이고 Noul의 0.5는 판단이 반반이라는 뜻이다 (발표자료 27쪽)

Jev는 상태와 질문 여러 개를 한 요청으로 받아 모든 답을 동시에 돌려준다. 문의 본문 하나에 담당과 분노 정도와 긴급 여부를 한꺼번에 물으면 한 번 읽고 세 답을 낸다. 원 발표자가 일본어 문의로 잰 예시에서는 담당 technical 0.93, 분노 정도 0.98, 긴급 0.88이 나왔다.

출력 토큰을 과금하지 않으므로 질문을 늘려도 비용은 입력 길이에만 비례한다. 질문을 여러 요청으로 쪼개는 설계보다 한 요청에 묶는 설계가 지연과 비용 모두 유리하다. 입력 종류가 달라도 호출 코드는 같다. Slack 메시지에는 의도와 답장 필요 여부를, 영수증에는 계정 과목을, 코드 변경에는 위험도와 리뷰 필요 여부를 물을 때 바뀌는 것은 state와 questions뿐이다.

질문 설계 원칙은 세 가지다. 한 질문에는 한 판단만 담는다. 같은 입력은 한 요청으로 묶어 보내고 코드로 합성한다. 선택지 설명에는 경계 조건과 다른 선택지로 보낼 경우를 직접 적는다. Jev는 적힌 그대로 읽고 의도를 추론하지 않는다.

▲ 질문 세 개를 한 요청에 담으면 한 번 읽고 세 답을 동시에 돌려준다 (발표자료 29쪽)

TypeSafe AI가 공개한 수치는 종단 응답 70~500ms, 입력 100만 토큰당 0.042달러, 출력 무료다. 자사 홈페이지 워크플로 기준으로 193.6배 빠르고 444.6배 저렴하다는 수치도 있지만, 회사 블로그가 스스로 높은 쪽 수치라고 밝힌다. 요청 한도는 초당 25만 토큰, 분당 1,200 요청이다.

독립 평가는 강점과 약점을 함께 보여 준다. GitHub에 공개된 고객 문의 분류 벤치마크에 따르면 합성 문의 200건에서 Jev의 정확도는 92.9%로 GPT-4.1-mini의 89.9%보다 높았고, 1,000건당 비용은 0.026달러 대 0.308달러, 중앙 지연은 415ms 대 1,496ms였다. 반면 2026년 9월 27일 공개된 의료 벤치마크 예비 결과에서는 PubMedQA가 78.4% 대 78.2%로 대등했지만 진단 추론 문항인 DiagnosisArena-MCQ는 59.8% 대 82.4%로 크게 뒤졌다.

읽는 법은 분명하다. 좁은 분류와 라우팅에서는 LLM 분류기와 대등하면서 더 싸고 빠르다. 여러 단계를 거치는 복합 추론에서는 열세다. 적용 범위를 판정 한 번으로 끝나는 질문으로 한정해야 비용 이점이 유지된다.

벤더가 스스로 잰 수치에 붙는 조건은 모델 종류와 무관하게 같다. 사내에서 오픈웨이트 LLM 도입을 판정할 때도 모델 제공자가 모델 카드에 실은 점수는 측정 주체가 제공자 자신이라는 한 가지 성격을 공유했고, 그래서 자사 워크로드로 다시 재기 전에는 판정 근거로 쓰지 않았다. 판정의 단위도 모델 전체가 아니라 워크로드다. 문의 분류에는 맞고 진단 추론에는 맞지 않는다는 위의 결과처럼, 어느 모델이 더 좋은가를 묻지 않고 어느 판단을 옮길 것인가를 물어야 결론이 난다.

▲ 좁은 분류에서는 대등하면서 싸고 빠르지만 복합 추론에서는 크게 뒤진다 (발표자료 34쪽)

리뷰 한 건에서 다섯 항목을 판정한 제3자 실측에서 Jev는 GPT-5.6 Luna보다 약 2.4배 빠르고 약 4.8배 저렴했다. 공개 저장소 mameli/jev-vs-luna의 2026년 9월 18일 실행 결과에 따르면 유효 응답 중앙값은 0.647초 대 1.556초, 1,000회 환산 비용은 약 0.032달러 대 약 0.154달러였다. 항목별 정답률은 96.13% 대 97.13%로 Luna가 1%p 높았다.

원 발표는 이 실험을 사람이 쓴 리뷰로 소개했지만, 저장소를 확인하면 합성 리뷰 100건에 라벨만 사람이 붙인 데이터다. 실행도 한 번뿐이다. 우리 데이터로 다시 재기 전에는 일반화하지 않는 편이 안전하다.

원 발표자의 손수 검증도 같은 방향을 가리킨다. 일반 5분류 42건은 모두 일치했지만, 경계가 애매하게 만든 5분류 18건에서는 16건만 일치해 88.9%였다. 전체 86건의 작은 가상 데이터라 발표자 스스로 일반화할 수 없다고 적었다. 쉬운 문장에서의 100% 일치는 도입 근거가 되지 못한다.

▲ 제3자 실측에서 2.4배 빠르고 4.8배 저렴했으며 정답률은 1%p 낮았다 (발표자료 43쪽)

TypeSafe AI의 투자 정보는 확정과 보도와 미확인 세 단계로 나눠 읽어야 한다. 확정된 것은 2026년 9월 15일 발표한 시드 4,000만 달러이고, 공식 발표에 이름이 나온 투자자는 리드인 DCVC 한 곳이다. 100억 달러 이상 가치로 10억 달러 넘게 조달한다는 내용은 9월 24일 The Information의 협상 보도다. 라운드가 닫히지 않았으므로 사실로 인용할 수 없다.

회사 규모도 도입 검토의 변수다. 2024년에 창업해 약 2년을 스텔스로 보냈고, 공개 뒤 닷새 만에 Vercel과 OpenRouter와 Cloudflare 세 유통 채널에 올라갔다. 9월 22일에는 수요가 몰려 신규 가입을 중단했고 한때 API 서빙 용량이 소진됐다. 직원 수는 비공개이며 외부 집계로는 20~30명으로 추정된다. CEO인 Diogo Almeida가 OpenAI에서 RLHF와 InstructGPT 작업에 참여했다는 경력은 배경 정보일 뿐 성능의 근거가 아니다. 공급 안정성은 계약 전에 따로 확인해야 한다.

▲ 공식 확인된 투자는 DCVC가 이끈 시드 4,000만 달러 하나다 (발표자료 40쪽)

문의 분류와 라우팅은 Jev가 가장 강한 영역이다. 고객 메시지를 넣으면 담당 부서는 Choice로, 긴급도는 Score로 한 번에 답한다. 확신도가 높고 긴급도가 낮으면 자동 응답 봇으로, 확신도가 중간이거나 긴급도가 높으면 사람 상담원으로, 긴급도가 최고 단계면 우선 대응 큐로 보낸다.

원 자료는 응답 시간이 8.5초에서 0.11초로, 티켓당 비용이 0.01388달러에서 0.000081달러로 준다고 추정한다. 비교 모델과 측정 조건은 적혀 있지 않다. 산술로 되짚으면 티켓당 입력 약 1,930 토큰을 가정한 값이다.

설계 제약도 함께 따라온다. 처리 기한 경과 판정은 코드가 계산한다. 고객에게 보낼 응답 문장은 템플릿이나 LLM이 쓴다. 낮은 확신도는 사람에게 넘긴다. 같은 구조는 장애 1차 대응에도 쓰인다. 긴급도와 담당 팀을 동시에 판정하고, 통상 건은 코딩 에이전트가 수정 PR 초안을 만들며, 병합은 사람 리뷰를 거친다. 모델 호출을 한 관문으로 모으는 구성은 AI 에이전트를 위한 LLM 게이트웨이에서 다뤘다.

▲ 고객 문의 한 건의 담당 부서와 긴급도를 호출 한 번으로 정한다 (발표자료 51쪽)

실시간 판단에 Jev를 넣을 때는 시간 초과 경로를 먼저 설계해야 한다. 결제 버튼을 누르고 100ms 안에 판정하는 이상거래 탐지 설계도에서 Jev는 부정 위험도를 Score로, 봇 공격 여부를 Noul로 판정한다. 금액과 거래 횟수와 최근 시간창은 규칙 엔진이 먼저 계산해 결과만 넘긴다.

원 자료는 판정 지연을 70~100ms로 적었지만 공식 범위는 70~500ms다. 상한이 결제 예산의 다섯 배다. 기본 요청 한도인 분당 1,200건은 초당 20건이므로, 결제 피크가 그보다 큰 서비스는 한도 증액 협의가 도입의 전제다. 시간 초과 시 규칙 엔진 판정으로 돌아가는 폴백이 없으면 Jev가 결제 경로의 새 장애 지점이 된다.

대량 처리에서는 병목이 비용이 아니라 요청 수다. 리뷰 5,000만 건을 리뷰당 200토큰으로 태깅하면 비용은 약 420달러다. 그런데 분당 1,200 요청 한도로는 약 29일이 걸린다. 한 요청에 여러 질문을 묶는 방식이나 한도 증액을 먼저 정해야 일정을 잡을 수 있다.

지연의 값은 업무마다 다르다. 야간 배치로 도는 문서 분류에서는 수백 ms의 차이가 눈에 띄지 않지만, 상담 창구나 결제 화면에서는 앞의 몇 초가 그대로 이탈로 이어진다. 그래서 판단 모델을 어디에 먼저 넣을지는 평균 지연이 아니라 그 업무가 기다려 줄 수 있는 시간으로 정한다.

▲ 공식 지연 상한 500ms는 결제 예산 100ms를 넘으므로 폴백이 필수다 (발표자료 57쪽)

적용 설계도를 한 그림으로 모으면 세 층 구조가 된다. 아래층의 Jev가 대량 판단을 빠르고 싸게 끝낸다. 가운데 코드 층이 확신도 문턱과 금액 계산, 날짜 비교, 차단 목록을 맡는다. 위층의 프런티어 LLM이 깊은 추론과 응답 문장 생성을 맡는다. 판단 대부분은 아래층에서 끝나고 일부만 위로 올라간다.

핵심은 가운데 코드 층이다. 숫자와 날짜와 적대적 입력을 코드가 먼저 받아 주지 않으면 아래층의 속도 이점이 오판으로 사라진다. 에이전트 가드에서도 순서는 같다. 결정적 차단 목록이 먼저이고 Jev는 2차 판정이며, 파괴적 조작은 확률과 상관없이 사람 승인 경로로 고정한다. Claude Code에는 도구 실행 전에 스크립트가 허용과 거부를 결정하는 PreToolUse 훅이 있어 판정을 붙일 자리가 이미 정해져 있다.

확률 가드의 한계는 수치로 확인된다. Anthropic의 Claude Code 자동 모드 분류기는 2단계 재판정으로 오탐을 8.5%에서 0.4%로 낮췄지만, 실제 과잉 행동 52건 가운데 17%를 놓쳤다. 확률 가드는 차단 목록과 사람 승인을 대신하지 못하고 그 부담을 줄여 줄 뿐이다. 에이전트의 구조와 도입 기준은 AI 에이전트란 무엇인가에서 정리했다.

가드 설계는 모델보다 위임 목록에서 시작한다. OWASP Gen AI Security Project는 2025년 12월 9일 OWASP Top 10 for Agentic Applications 2026을 공개하면서 에이전트 시스템이 금융과 의료와 공공 부문에서 시범을 지나 운영으로 옮겨 가고 있다고 정리했다. 운영 단계의 에이전트는 사람의 승인을 매번 거치지 않고 스스로 도구를 부른다. 그래서 도입 심사에서는 어떤 모델을 쓰는지보다 무엇을 위임했는지를 먼저 적는다. 위임 목록이 곧 공격면 목록이기 때문이다. 문서를 읽기만 하는 에이전트와 결재 시스템에 쓰기 권한을 가진 에이전트는 같은 판정 모델을 붙여도 통제 요구가 다르다.

▲ 가운데 코드 층이 계산과 날짜와 차단 규칙을 맡아 Jev의 약점을 받는다 (발표자료 62쪽)

TypeSafe AI 공식 문서는 Jev 1.13의 약점 아홉 가지를 스스로 밝힌다. 문자 그대로 읽어 의도를 추론하지 않는다. 개수 세기 같은 수학과 숫자 판단이 불안정하다. 날짜를 순서 값이 아닌 텍스트로 다룬다. 다단계 추론과 이중 부정에 약하다. 관련 없는 내용이 상태에 늘수록 정확도가 떨어진다. 입력에 주입된 지시에 흔들릴 수 있다. 지시문과 기준이 어긋나면 혼란을 일으킨다. 반대 명제 두 개의 확률 합이 1이라는 보장이 없다. 텍스트 생성은 하지 못한다.

대부분은 다른 수단으로 넘길 수 있다. 계산과 날짜 비교는 일반 코드가 맡고, 생성은 LLM과 조합하며, 흐릿한 문제는 질문과 입력을 좁힌다. 가장 주의할 것은 주입 지시 취약점이다. 중대한 권한 판단에 단독으로 쓰면 안 된다.

한국어도 확인 대상이다. 공식 모델 문서는 영어가 주력 학습 언어이고 한국어 같은 한중일 문자는 지원하지만 정확도가 같지 않다고 밝힌다. 원 발표의 실측은 모두 일본어 데이터였다. 한국어 업무는 운영 전에 자기 데이터로 시험해야 한다.

약점을 어디까지 감수할지는 되돌릴 수 있는가로 가른다. 자료를 찾아 요약만 내놓는 읽기 전용 동작과 파일을 고쳐 쓰고 외부로 메시지를 내보내는 동작은 판정이 틀렸을 때 치르는 비용이 크게 다르다. 검토 질문은 이렇게 잡는다. 사람 확인 없이 수행되는 동작 가운데 되돌리기 어려운 것이 무엇인가. 라벨을 붙이고 후보를 고르는 판단은 틀려도 원문이 남으므로 Jev에 먼저 맡길 수 있고, 삭제와 결제와 외부 발송처럼 되돌리기 어려운 동작은 확률이 아무리 높아도 사람 승인 뒤에 둔다.

▲ 공식 문서가 밝힌 약점 아홉 가지는 대부분 코드로 대신할 수 있다 (발표자료 66쪽)

독립 벤치마크 JevBench v1.5.4 종합 순위에서 Cygnet이 73.7점, Winnow-12B가 73.2점으로 Jev 1.13.0의 72.1점을 넘었다. 다만 1위와 Jev의 차이는 1.6점이고, 이 순위는 판 버전이 바뀔 때마다 1위가 달라졌다. 인용할 때는 판 버전을 반드시 함께 적어야 한다.

종합 점수 하나로 고르면 오판한다. JevBench는 판단력, 보정, 속도, 비용 네 축을 조화평균으로 묶는데, 자체 호스팅 모델의 속도와 비용 축은 실측이 아니라 가정값이다. 판단력 축만 보면 70점 이상은 다섯 개뿐이고 모두 12B 이상이거나 확산 모델이다. 4B 계열은 판단력이 51~56점이며 속도와 비용 점수로 종합을 메웠다. 벤치마크는 영어 전용이고 한국어 문항이 없다.

교체를 막는 항목은 보정된 확률과 입력 한도다. Jev는 64k 토큰까지 받지만 Cygnet은 16k, Laya는 512~1,024 토큰이다. 라이선스는 대부분 Apache-2.0이나 MIT여서 걸림돌이 거의 없다. 장비 조건은 4B 계열이 GPU 메모리 3~5GB, 12B인 Winnow가 양자화 기준 약 13GB, Cygnet이 48GB급이다. 4B 후보 여러 개를 장비 한 대에 올려 같은 문항으로 나란히 비교할 수 있다. 사내 모델 운영의 판단 기준은 프라이빗 sLLM Qwen 3.6 27B에서 다뤘다.

▲ JevBench v1.5.4에서 오픈 모델 두 개가 Jev를 넘었지만 차이는 1.6점이다 (발표자료 71쪽)

판단 전용 AI 모델을 도입할 때 정할 것은 세 가지다. 첫째, 맡길 판단이 정해진 선택지나 단계나 참거짓 명제로 적히는지 확인한다. if 문과 else 문으로 적히는 판단이 후보다. 둘째, 계산과 날짜 비교와 차단 규칙을 코드 층에 먼저 둔다. 셋째, 우리 업무의 경계 사례로 라벨 데이터를 만들어 한국어 정확도를 직접 잰다. 판단을 어느 모델에 맡길 것인가는 결국 조직이 AI에 어디까지 실행 권한을 줄 것인가에 딸린 결정이다. 그 위쪽 그림은 엔터프라이즈 AI란 무엇인가에서 도입 단계별로 정리했다.

도입 범위는 판단 난이도와 반복 빈도 두 축으로 가른다. 난이도가 낮고 빈도가 높은 판단이 Jev의 자리다. 난이도가 낮고 빈도도 낮으면 조건문으로 충분하다. 난이도가 높고 빈도가 낮으면 LLM과 사람 확인이 맞다. 난이도와 빈도가 모두 높으면 Jev가 1차로 가르고 애매한 건만 LLM과 사람에게 넘긴다.

검토를 시작한다면 다음 순서로 30일 안에 결론을 내는 것을 권한다.

1. 운영 로그에서 하루에 반복되는 분기 판단의 종류와 건수를 조사해야 한다.
2. 원문을 고치지 않는 분배, 태그, 후보 선별 업무 하나를 첫 시험 대상으로 결정해야 한다.
3. 그 업무의 경계 사례를 포함한 한국어 라벨 데이터를 100건 이상 준비해야 한다.
4. 질문을 한 판단 단위로 나누고 선택지 설명에 경계 조건을 명시해야 한다.
5. 정답률과 지연과 비용을 현재 쓰는 LLM 분류와 같은 조건으로 비교해야 한다.
6. 확신도 문턱과 사람 검토 경로, 시간 초과 폴백을 운영 투입 전에 확정해야 한다.

Jev는 LLM과 무엇이 다른가

LLM은 토큰을 하나씩 생성해 문장을 돌려주고, Jev는 문자열을 만들지 않고 정해진 선택지 안의 결정과 확률만 돌려준다. 그래서 출력을 파싱할 필요 없이 코드의 분기 조건에 바로 쓸 수 있다. 대신 맥락을 기억하거나 길게 추론하거나 글을 쓰지는 못한다. Jev는 LLM을 대체하지 않고 LLM 루프 사이의 짧은 판단을 맡는다.

Choice와 Score와 Noul은 언제 갈라 쓰는가

여러 후보 가운데 하나를 고르면 Choice, 정도를 단계로 재면 Score, 명제의 참거짓을 가르면 Noul을 쓴다. Choice는 담당자나 모델 라우팅에, Score는 긴급도와 위험도 채점에, Noul은 실행 허가와 승인 게이트에 맞다. 정도를 묻는 판단을 Noul로 물으면 0.5를 중간 등급으로 잘못 읽게 된다.

확신도는 모든 답에 붙는가

아니다. 확신도는 Choice와 Score 답에만 붙고 Noul에는 없다. Noul은 명제가 참일 확률 하나만 돌려주므로 그 확률 자체에 문턱을 걸어 분기한다. 사람에게 넘길 기준도 질문 유형마다 따로 정해야 한다.

Jev의 요금과 응답 시간은 얼마인가

공식 요금은 입력 100만 토큰당 0.042달러이고 출력 토큰은 과금하지 않는다. 공식 종단 응답 시간은 70~500ms이며 이것은 TypeSafe 자체 평가다. 제3자 실측에서는 유효 응답 중앙값이 0.647초였다. 실제 지연은 네트워크 왕복과 입력 길이에 따라 달라지므로 자기 환경에서 다시 재야 한다.

한국어 업무에 바로 쓸 수 있는가

바로 쓰기보다 먼저 시험해야 한다. 공식 문서는 영어가 주력 학습 언어이고 한국어는 지원하지만 정확도가 같지 않다고 밝힌다. 공개된 실측은 일본어와 영어 데이터가 대부분이다. 자기 업무의 경계 사례로 만든 한국어 라벨 데이터로 정답률을 잰 뒤에 투입 범위를 정한다.

Jev를 보안 가드로 단독 사용해도 되는가

안 된다. 공식 약점에 입력 속 주입 지시에 흔들린다는 항목이 있다. 결정적 차단 목록을 먼저 두고 Jev는 2차 판정으로 쓰며, 파괴적 조작은 확률과 상관없이 사람 승인으로 보낸다. 확률 가드는 차단 목록과 사람 승인의 부담을 줄일 뿐 대신하지 못한다.

오픈소스 대안으로 바꿀 수 있는가

질문 형식과 API 호환은 대부분의 후보가 충족하지만 보정된 확률과 입력 한도에서 차이가 난다. JevBench v1.5.4에서 Cygnet과 Winnow-12B가 종합 점수로 Jev를 넘었지만 차이는 1.6점 이내이고 벤치마크는 영어 전용이다. 긴 문서를 통째로 넣는 자리는 그대로 옮길 수 없다. 같은 문항으로 직접 비교한 뒤에 정한다.

AI 모델 선택과 에이전트 설계를 더 깊이 볼 때 함께 읽을 자료다.

• 엔터프라이즈 AI란 무엇인가 — AI 에이전트 시대의 도입 기준
• 생성형 AI와 판별형 AI — 원리 차이와 선택 기준
• LLM이란 무엇인가 — 원리부터 기업 도입 판단까지
• AI 에이전트란 무엇인가 — 정의, 구조, 기업 도입 기준
• AI 에이전트와 챗봇의 차이 — 5가지 기준 비교
• 생성형 AI 진화 4단계 — LLM에서 Agentic까지
• AI 에이전트를 위한 LLM 게이트웨이 — LiteLLM 도입 가이드
• RAG란 무엇인가 — 파이프라인 해부와 도입 체크리스트
• MCP란 무엇인가 — LLM 도구 통합 표준
• AI 에이전트 워크플로우 실무 도입 완벽 가이드
• AI 코딩 자동화 도입, 왜 지금 필요한가
• 프라이빗 sLLM Qwen 3.6 27B — 데이터 주권과 사내 운영
• AI LLM 가속 엔진 vLLM — GPU 병목과 도입 비용 줄이기
• AI도 오픈소스가 답이다 — 공개 LLM과 생태계
• Gemma란? 구글의 경량 LLM, GPU를 덜 쓰는 이유
• LLM 기반 AIOPS — 장애 대응을 바꾸는 7가지 기능과 도입 기준
• AX란 무엇인가 — 정의부터 추진 4단계까지
• TypeSafe AI 공식 모델 문서
• JevBench 저장소

Jev의 작동 원리와 세 가지 판단 유형, 벤더 수치와 독립 평가의 대조, 적용 설계도와 약점, 오픈소스 대안을 정리한 발표자료 78장 전체를 78쪽 PDF로 공개한다. 장마다 붙인 정정 표시와 출처 구분까지 같은 파일에 들어 있어 도입 검토 회의 자료로 그대로 쓸 수 있다.

아래 버튼에서 같은 PDF를 다시 내려받을 수 있다.