# Jev란? — 글을 쓰지 않고 ‘판단’만 반환하는 모델을 Claude 사용자의 관점에서 정리하기

> https://bookfactory.kr/board/news/18161
> 게시판: 뉴스
> 작성자: admin
> 작성일: 2026-09-23T04:07:00.348Z

---

2026년 9월 15일, TypeSafe AI가 첫 공개 모델 'Jev'를 발표했다. Jev는 문장을 한 글자도 생성하지 않고, 우리가 준비한 선택지 중에서 답과 확률만을 반환한다. 9월 20일에는 웨이트리스트도 폐지되었다. 새로운 것은 'LLM이 또 빠르고 저렴해졌다'는 점이 아니라, '그 판단에 문장을 쓰는 모델이 정말 필요한가'라는 질문이 실무의 선택지가 되었다는 점이다.

Jev는 Claude Code의 자동 모드가 이면에서 수행하는 ‘실행 전 안전 판단’과 같은 형태의 작업을 담당하는 모델로, Claude로 시스템을 구축하는 측과도 깊은 관련이 있다.

### 무엇이 발표되었는가

TypeSafe AI는 샌프란시스코의 AI 랩으로, 창업자 Diogo Almeida는 OpenAI에서 ChatGPT의 기반이 된 연구에 참여한 인물이다(본인이 발표 글에서 직접 밝힌 바 있다). 약 2년의 스텔스 기간을 거쳐 공개됐으며, 각사 보도에 따르면 DCVC가 주도한 4,000만 달러 규모의 시드 자금 조달 소식도 같은 날 전해졌다.

해당 회사는 Jev를 “System One Model”이라는 새로운 구분의 첫 번째 모델로 규정하고, 모델 구조·병렬 샘플러·학습 기법(RLCD)을 자동화에 맞춰 전면 재설계했다고 설명하고 있다. 발표 기사의 문구는 다음과 같다.

> 
> 
> 비정형 상태 입력, 타입화된 확률적 결정 출력
> 

비정형 데이터를 입력하면, 정해진 형식의 판단이 확률과 함께 출력된다. 채팅 상대라기보다는 코드에서 호출하는 함수에 가깝다.

창업자의 발표 게시글은 여기 있습니다.

> 
> 
> ChatGPT를 공동 발명한 뒤, 저는 계속 스스로에게 물었습니다: 왜 초인급 채팅 모델들은 AGI로 이어지지 않았을까? 지난 2년간 저는 스텔스 모드로 모델을 훈련하는 새로운 방식(RLCD)과 오늘 저희가 공개하는 새로운 유형의 프론티어 AI 모델인 Jev를 개발해 왔습니다. • 20-200배 더 빠름 • 40-400배… pic.twitter.com/JSybNG2BKJ — Diogo Almeida (@CompleteSkeptic) September 15, 2026
> 

9월 20일에는 공식 계정이 웨이팅 리스트 폐지를 알리고, 같은 스레드에서 모든 사용자에게 5달러분(약 1억 2,000만 토큰 상당)의 크레딧을 부여한다고 안내했다.

> 
> 
> Jev가 이제 모두에게 공개되었습니다. 웨이팅 없이 바로 사용해 보세요: https://t.co/5MfN4rIif5 — TypeSafe AI (@typesafeai) 2026년 9월 20일
> 

### LLM과 무엇이 다른가

문자열을 생성하지 않는다

LLM은 토큰을 하나씩 순서대로 생성하고, 앱 측에서 그 문자열을 파싱한다. Jev는 사전에 정의한 질문에 대한 답을 1회의 쿼리로 병렬로 출력한다. 출력 형태는 정해져 있어 정의 외의 값은 반환되지 않는다. 공식 문서에서는 타입 오류는 원리상 발생하지 않는다고 설명하고 있다.

이 부분은 오해하기 쉽다. 보장되는 것은 "답이 스키마에 들어맞는 것"이지, "고른 답이 옳다는 것"이 아니다. 타입 오류율 0%도 실측값이 아니라 구조상의 보장으로 제시된 것이다. 파싱 실패에 대한 재시도는 불필요해지지만, 판단의 오류는 남는다.

질문의 유형은 3가지뿐이다

- Noul: “이것은 참인가”를 묻고, yes의 확률을 0~1로 반환한다
- Choice: 정의된 선택지(최대 255개) 중에서 하나를 선택하고, 선택지별 확률과 확신도를 반환한다
- 점수: 순서가 정해진 단계(루브릭) 중 어디에 해당하는지 평가하고, 점수·단계별 확률·확신도를 반환한다

요청은 판단 자료인 “state”과 질문 묶음인 “questions”으로 이루어져 있다. 에이전트가 실행하려는 명령을 판정하게 하려면 다음과 같은 형태가 된다.

json

반환되는 것은 effect의 선택 결과와 3개의 확률·확신도, explicitly_requested의 yes 확률뿐이며 설명문은 포함되지 않는다. 질문은 모두 동일한 state에 대해 독립적으로 병렬 평가되므로 공식 문서에 따르면 질문을 늘려도 응답 시간은 거의 변하지 않는다. “하나를 묻고 답을 보고 다음을 묻는” 방식이 아니라, 관련 있어 보이는 질문을 처음에 한꺼번에 던지고 어떤 답을 사용할지를 코드로 정하는 방식이 기본이 된다.

확률을 ‘맞을 확률’로 다룰 수 있다

학습 기법인 RLCD(Reinforcement Learning for Calibrated Decisions)는 인간의 선호가 아니라 확률이 실제 결과와 일치하는 것을 목표로 최적화한다. 공식 문서의 예에서는 확신도가 0.6 미만이면 사람에게 넘기고, 송금 승인과 같은 고위험 작업은 0.85를 초과했을 때만 자동 실행하고, 그 외에는 본인에게 확인하도록 하는 분기를 코드에 작성하고 있다.

> 
> 
> 용어 보충｜캘리브레이션(교정) ‘90%’라고 답한 것들이 실제로도 대략 9할 맞는 상태를 말한다. LLM에게 확신도를 답하게 해도 이 성질은 보장되지 않는다. 모니터링의 임곗값과 마찬가지로, 수치가 현실과 대응해야 비로소 ‘0.85 초과면 자동 실행’이라는 규칙이 의미를 갖는다.
> 

리스크 허용도가 프롬프트 문구가 아니라 코드상의 수치로 남으므로 리뷰나 감사에서 다루기 쉽다.

### 요금·속도·제공 형태

공식 모델 사양(Jev 1.13)에서.

- 요금: 입력 100만 토큰당 0.042달러. 출력은 무료
- 응답 시간: 70~500밀리초. 측정은 미국 서해안에서 이루어졌으며, 서비스도 현재 서해안에 있다. 일본에서는 네트워크 왕복 시간만큼 추가된다.
- 속도 제한: 초당 25만 토큰, 분당 1,200 요청. 예고 없이 변경될 수 있다고 명시되어 있다.
- 컨텍스트: 1회 요청당 64K 토큰. 상태와 가장 긴 질문 1개의 합계는 32K까지
- 입력: 텍스트만. 이미지, 음성, 동영상은 불가
- 모델 지정: 현행은 jev-1.13.0이다. jev-latest와 jev-preview는 별칭이다.

앨리어스는 새 릴리스에서 가리키는 대상이 바뀌어 같은 입력이라도 답이 달라질 수 있다. 공식 문서에서도 임계값을 조정했다면 버전 ID를 고정하도록 권장하고 있다. 모델 업데이트로 출력 경향이 바뀌는 문제가 임계값이라는 수치에 직접 영향을 미친다.

직접 API 외에도 Vercel AI Gateway나 Cloudflare Workers AI를 경유하여 호출할 수 있다. 다만 Cloudflare의 모델 페이지에서는 컨텍스트가 32,000토큰으로 표시되어 있으므로, 경로별 상한은 확인할 필요가 있다. SDK는 Python과 JavaScript용으로 제공되며, LangChain 통합도 지원된다.

### Claude와의 관계

Claude Code의 자동 모드와 같은 형태의 ‘판단’

Claude Code의 자동 모드에서는 도구 호출을 실행하기 전에 별도의 모델(분류기)이 위험한 작업인지 여부를 판단한다. 현재 문서에 따르면 Pro / Max / Team 플랜의 시작 모드 기본값은 자동 모드이며, 분류기는 기본적으로 Claude Sonnet 5로 동작한다.

Anthropic의 엔지니어링 블로그(2026년 3월)에 따르면, 분류기는 2단계 구조다. 1단계가 차단해야 할지를 1토큰의 yes/no로 즉답하고, 걸린 것만 2단계가 사고 과정을 이용해 다시 판정한다. 1단계의 역할은 TypeSafe가 말하는 System One형 판단 그 자체다. 문서에는 분류기 호출이 토큰 사용량에 집계되는 경우나 실행 전에 왕복 1회분의 대기가 추가되는 점도 적혀 있다. 판단할 때마다 LLM을 호출하는 비용과 지연은 Anthropic 제품에서도 설계상의 논점이 되고 있다.

LangChain은 이 방식을 모든 에이전트에 도입하는 미들웨어 “AutoModeMiddleware”를 Jev를 이용해 실험적으로 공개했다. 해설 기사는 Claude Code와 Codex, Cursor가 갖춰 온 실행 전 위험 판정이 그동안 하네스의 폐쇄적인 부분에 숨겨져 있었다고 정리하고 있다.

참고로 문서상으로는 Claude Code의 분류기는 Claude 모델로 동작하고 있으며, Jev가 사용되고 있는 것은 아니다. 말할 수 있는 것은 “같은 형태의 문제를 다른 회사가 단일 모델로 분리해 냈다”는 정도까지다.

TypeSafe 평가에서 Claude의 위치

TypeSafe는 보안 알림 대응, 에이전트 로그 감사, 청구서 처리, 고객 서비스의 4개 업무에서 각 모델을 비교한 평가를 공개하고 있다. 기준 라벨은 GPT-6 Astra와 Claude Fable 5.1(높은 추론 설정) 답변의 평균이며, 정답률은 “이 기준과의 일치율”에 해당한다. 판단을 작은 질문들로 분해한 “워크플로” 형식에서의 4개 업무 평균은 다음과 같다.

- Jev: 67.8%, 1건 0.0004달러, 0.4초
- Claude Sonnet 5: 67.8%, 0.1174달러, 78.1초
- Claude Opus 5: 73.1%, 0.1761달러, 37.8초
- Claude Haiku 4.5: 53.6%, 0.0195달러, 12.5초

평균적으로는 Sonnet 5와 동일한 일치율을 보이면서 비용과 시간은 두 자릿수 이상 적다. 다만 업무별로는 차이가 난다. 청구서 처리에서는 Jev가 61.8%인 데 비해 Opus 5가 78.4%였고, 고객 서비스에서는 반대로 Jev가 76.0%, Opus 5가 72.4%였다. 오판정 비용이 높은 업무에서는 추론 비용의 차이보다 일치율의 차이가 더 크게 작용한다. 평균값만으로는 교체를 결정할 수 없다.

Claude 사용 방식에 직접 관련된 수치도 있다. 업무 규칙을 단일 프롬프트로 전달하는 방식과 비교하면, 4개 업무 평균에서는 모든 모델에서 워크플로 형식이 일치율이 더 높고, 더 저렴하고, 더 빨랐다. Opus 5는 64.8%에서 73.1%로, Sonnet 5는 60.4%에서 67.8%로 상승했다. Jev를 사용하지 않더라도 판단을 분해해 코드로 구성하는 설계는 Claude 단독으로도 효과가 있다.

이 평가는 TypeSafe 자체에 의한 것으로, 업무 플로우를 자사 팀이 직접 만들었다는 점과 기준 라벨이 OpenAI와 Anthropic 쪽으로 치우칠 수 있다는 점은 회사 측도 명시하고 있다. 사이트에 내건 “193.6배 빠르고, 444.6배 저렴하다”는 문구 역시 이 평가가 출처이며, 실제 환경에서는 다소 높게 나온 값이라고 회사 스스로 보고 있다.

Claude Code부터 시도해 보기

TypeSafe는 에이전트용 스킬을 공개하고 있으며, Claude Code에는 플러그인 형태로 제공된다.

번역해 드릴 일본어 원문이 포함되어 있지 않습니다. 원문을 붙여 넣어 주세요.

도입 후에는 /typesafe:typesafe-ai로 호출할 수 있다. 공식 문서에서 처음 권장하는 것은 프로젝트를 탐색시켜 깨지기 쉬운 파싱 처리나 복잡한 조건 분기를 '판단'으로 대체할 수 있는 부분을 찾아내게 하는 것이다. 에이전트는 질문 문장 작성에 능숙하지 않으므로, 질문과 임계값을 하나의 파일에 모아 사람이 리뷰할 수 있도록 해두라는 주의사항도 있다.

### 현 시점의 제한

공식 문서의 “Jev 1.13 jaggedness” 페이지에는 알려진 약점 9가지가 명시되어 있다 (2026년 9월 17일 기준).

- 문자 그대로 읽는다: 의도는 헤아리지 않는다. 조건과 경계 사례를 명시한다
- 계산·수치: 수를 확실히 셀 수 없으며, 16진수 컬러 코드의 유사성도 안정적으로 판단할 수 없다. 산술은 코드로 수행한다.
- 날짜·시간 비교: 날짜를 문자열로 읽는다. 추출만 맡기고, 비교는 코드로 한다
- 간접 참조: 이중 부정이나 다단계 참조로 정확도가 떨어진다
- 무관한 정보가 많은 상태는 노이즈가 된다. 먼저 코드로 걸러내야 한다.
- 적대적 콘텐츠: 상태 내 유도 문구에 따라 답이 달라질 수 있음
- 지시사항과 평가 기준의 모순: 의미가 어긋나면 답이 불안정해진다
- 구조적 일관성이 없다: 같은 질문을 Noul과 Choice로 물어도 수치가 일치하지 않는다. ‘환불을 요구하고 있는가’와 ‘환불 이외의 것을 요구하고 있는가’에 대한 Noul 합계가 1.19가 되는 예도 실려 있다
- 문장 생성: 할 수 없다. 후보는 정규표현식이나 LLM으로 만들고, Jev가 선택하게 한다.

실무에서 통하는 것은 2가지다. 1가지는 구조적 정합성으로, Noul에서 조정한 임계값을 Choice에 그대로 가져다 써서는 안 된다(공식에도 명시되어 있다). 질문의 유형이나 버전을 바꾸면 임계값은 다시 구해야 한다.

또 하나는 적대적 콘텐츠다. Claude Code의 분류기는 도구 실행 결과를 의도적으로 입력에서 제외하고, 파일이나 웹페이지에 심어진 지시로 분류기 자체가 조종되지 않도록 하고 있다. Jev로 가드레일을 구축한다면, state에 무엇을 넣는지가 그대로 공격 표면이 된다. 외부 유래 텍스트를 통째로 state에 넘기는 설계는 피하는 것이 좋아 보인다.

**출처:** [note 원문](https://note.com/nao_sync/n/n3d16741c24ed)

*번역: Gemma 3(.44) 초벌 + 교정 43청크*

[원문 보기](https://note.com/nao_sync/n/n3d16741c24ed) | 출처: note.com