LLM이 판단하면 되는데, 왜 Jev가 필요한가?

Jev를 한 문장으로 말하면

Jev는 TypeSafe AI가 만든 System One 모델이다. 사람과 긴 대화를 나누거나 문장을 길게 생성하기보다, 프로그램 안에서 반복되는 판단을 Choice, Score, Noul 같은 typed decision으로 반환하도록 설계됐다.

예를 들어 고객 문의를 받았을 때 Jev에게 다음처럼 물을 수 있다.

문의: 주문한 상품이 아직 도착하지 않았다.
분류: 배송, 환불, 기술지원
긴급 여부: 예, 아니오

그러면 프로그램이 사용할 수 있는 분류와 확률을 돌려받는다.

{
  "category": "배송",
  "category_probability": 0.91,
  "urgent": false,
  "urgent_probability": 0.84
}

여기서 실제 환불 처리나 담당자 배정은 일반 코드가 한다. Jev가 모든 업무를 혼자 수행하는 구조가 아니다.

LLM에게 JSON을 시키면 되지 않을까?

가능하다. LLM에게 JSON 스키마를 주면 refund, exchange, delivery 같은 값을 정해진 필드에 넣도록 만들 수 있다. 이때 JSON 스키마는 출력의 문법과 구조를 제한한다.

그러나 구조가 맞는 것과 판단이 맞는 것은 별개의 문제다.

{
  "decision": "refund",
  "confidence": 0.99
}

이 결과는 JSON으로는 완벽하지만, 실제 문의가 환불 대상이라는 보증은 아니다. Jev의 차이는 JSON을 만들 수 있다는 데 있지 않다. 처음부터 자유로운 문자열 생성보다 정해진 판단 문제와 그 확률을 중심으로 모델과 API를 설계했다는 데 있다.

TypeSafe는 Jev를 소프트웨어가 바로 사용할 수 있는 typed decision 모델로 설명한다. 가능한 출력 구조를 미리 정의하므로 일반적인 텍스트 파싱 단계가 줄어든다. 다만 Jev의 확률도 정답 보증서는 아니다. 확신도가 높아도 틀릴 수 있고, 운영 코드는 임계값과 사람 검토 경로를 함께 가져야 한다. (TypeSafe 공식 소개)

System One은 무슨 뜻인가?

System One은 TypeSafe가 Jev 같은 모델을 부르는 분류명이다. 이름은 Daniel Kahneman의 빠른 직관적 판단과 느린 숙고형 판단의 구분에서 영감을 받았다.

Jev가 System One 모델로 불리는 이유는 긴 계획을 문장으로 생성하는 역할보다, 현재 상태를 보고 다음 분기나 선택을 빠르게 판단하는 역할에 맞춰졌기 때문이다. 이는 AI 업계의 표준 분류가 아니라 TypeSafe가 만든 제품군 이름이다.

Jev가 잘 맞는 선택 문제

Jev에 맞는 작업은 답의 형태를 미리 정할 수 있고, 같은 종류의 판단을 반복하는 작업이다.

상황	Jev가 맡을 수 있는 판단	실행을 맡는 부분
고객 문의	배송, 환불, 기술지원 중 분류	상담 시스템과 담당자 큐
코딩 에이전트	명령 허용, 거부, 사람 검토	셸 실행기와 권한 코드
브라우저 자동화	클릭, 입력, 뒤로 가기와 대상 요소 선택	브라우저 드라이버
문서 처리	문서 유형, 위험도, 승인 필요 여부	저장소와 업무 시스템
게임	정해진 행동 중 다음 행동 선택	게임 엔진

반대로 긴 보고서, 소설, 자유로운 코드 생성, 처음부터 계획을 만들어 설명하는 일은 LLM의 역할에 더 가깝다.

LLM, Jev, 코드의 역할을 나누기

실제 에이전트는 세 역할을 조합하는 편이 자연스럽다.

LLM  → 사용자의 목표를 이해하고 큰 계획을 세움
Jev  → 현재 상태에서 다음 선택과 분기 조건을 판단함
코드 → 도구를 실행하고 권한, 검증, 재시도를 관리함

예를 들어 브라우저 에이전트가 항공권을 검색한다고 하자. LLM은 “서울에서 도쿄로 가는 항공권을 찾아줘”라는 목표를 해석한다. Jev는 현재 화면의 요소 목록에서 다음에 누를 요소와 동작을 고른다. 브라우저 코드는 실제 클릭을 실행하고 URL이나 화면의 변화를 검사한다.

이렇게 나누면 매 클릭마다 긴 텍스트를 생성하는 대신 작은 판단만 빠르게 반복할 수 있다. Jev가 LLM을 완전히 대체한다기보다 LLM이 담당하던 반복적인 분류와 라우팅을 별도 계층으로 분리하는 방식이다.

활용 사례는 어디까지 나왔나?

공개된 Jev 사례에는 브라우저 자동화, 코딩 에이전트의 안전 검사, 문서와 이메일 분류, 도구 라우팅, 게임 에이전트가 있다.

브라우저 자동화에서는 접근성 트리나 요소 목록을 입력하고 다음 동작과 대상 요소를 고른다. 텍스트를 입력해야 하는 순간에만 작은 언어 모델을 호출하고, 클릭과 이동은 Jev로 처리하는 구조도 공개됐다.

코딩 에이전트에서는 셸 명령이나 도구 호출 전에 위험도를 판단하게 할 수 있다. 허용, 거부, 검토 중 하나를 고르고, 실제 실행은 코드가 담당한다.

게임에서는 왼쪽, 오른쪽, 공격, 이동처럼 합법적인 행동 목록을 정한 뒤 매 순간 하나를 고른다. Doom, Tetris, Pac-Man, StarCraft 관련 커뮤니티 데모가 이런 구조를 보여준다. 이런 사례는 장시간 반복되는 판단과 낮은 지연 시간이 왜 중요한지 보여주지만, 모든 공개 데모가 상용 서비스에서 검증됐다는 뜻은 아니다.

활용마다 모델을 따로 학습해야 할까?

대부분의 경우 새 모델을 학습하는 것이 아니라 상태와 질문, 선택지를 설정한다.

state: 현재 문의 내용
question: 문의 유형을 골라라
options: 배송, 환불, 기술지원

브라우저 자동화에서는 같은 모델에 화면 요소 목록과 행동 선택지를 전달하고, 문서 분류에서는 문서 본문과 분류 목록을 전달한다. 활용 사례가 바뀌어도 모델을 매번 새로 훈련하는 것은 아니다.

다만 회사의 전문 규칙이나 특수한 용어가 많으면 예시와 평가 데이터가 필요하다. 사람 검토를 시작할 확률 임계값, 실패 시 대체 경로, 실제 정답률도 업무별로 조정해야 한다. 이것은 모델을 새로 학습하는 일과는 다르지만, 서비스에 넣기 위해 반드시 필요한 설계 작업이다.

병렬 샘플링과 병렬 쿼리

일반적인 LLM은 문장을 한 토큰씩 순서대로 생성한다.

첫 토큰 → 두 번째 토큰 → 세 번째 토큰 → ...

Jev는 긴 문장을 만들지 않고, 선택지의 확률과 여러 typed question의 결과를 한 번에 계산하는 방향을 택한다. 예를 들어 문의 하나에 대해 유형, 긴급성, 위험도를 한 요청으로 묶을 수 있다.

문의 유형       → 배송 0.91
긴급 여부       → 아니오 0.84
사람 검토 필요  → 아니오 0.78

서로 독립적인 질문을 한 번에 처리하면 API 왕복과 대기 시간을 줄일 수 있다. 하지만 두 번째 질문이 첫 번째 결과에 의존하면 순차 처리가 필요하다.

1차: 문의 유형 판정
2차: 유형에 맞는 담당 부서 결정

병렬 처리는 무한하지도 않다. 질문 수, 각 질문의 선택지 수, 입력 상태의 길이, GPU 메모리, API 요청 크기, 계정별 동시성 제한이 모두 영향을 준다. TypeSafe는 공식 소개에서 Jev의 Choice 선택지 수를 최대 255개로 설명하고, 더 많은 후보는 점수화 후 다시 선택하는 2단계 방식으로 처리한다고 밝혔다. (공식 발표)

결과가 정말 고정되는가?

고정되는 것은 출력의 타입과 범위에 가깝다. refund, exchange, delivery 중 하나처럼 프로그램이 받을 수 있는 형태를 정해 둘 수 있다는 뜻이다.

판단 결과가 항상 같고 반드시 정답이라는 뜻은 아니다.

• 같은 입력도 설정과 서비스 상태에 따라 달라질 수 있다.
• 높은 confidence도 정답 보증서가 아니다.
• 낮은 confidence에서 사람에게 넘길 기준을 코드로 정해야 한다.
• 응답 오류나 네트워크 실패를 대비한 재시도와 안전한 기본 경로가 필요하다.

따라서 Jev를 넣었다고 자동화가 저절로 안전해지는 것은 아니다. Jev가 선택하고, 일반 코드가 임계값을 적용하며, 결과를 검증하는 구조가 필요하다.

지금 써보려면

공식 Jev는 현재 호스팅 API 방식이다. TypeSafe의 early access에 신청해 API key를 발급받은 뒤 state와 typed question을 보내는 방식으로 사용한다. 모델 가중치를 내려받아 로컬에서 실행하는 공식 경로는 공개되어 있지 않다.

OpenRouter에도 Jev Latest와 Jev 1.13이 제공되어 게이트웨이 API로 시험할 수 있다. OpenRouter는 Jev를 자유로운 텍스트 생성 모델이 아니라 구조화된 판단 모델로 설명하며, 현재 안내하는 컨텍스트 길이는 32K 토큰이다. (OpenRouter의 TypeSafe 모델 안내)

처음에는 고객 문의 분류처럼 작고 명확한 문제로 시작하는 편이 좋다. 입력 상태, 선택지, 기대 결과를 정하고, 같은 문제를 LLM과 Jev에 각각 보내 정확도, 지연 시간, 비용, 낮은 확률에서의 실패를 비교하면 된다.

Jev를 선택하는 기준

질문	더 맞는 선택
긴 글이나 코드를 생성해야 하는가?	LLM
정해진 선택지 중 하나를 반복해서 골라야 하는가?	Jev
결과를 반드시 정확한 계산으로 얻을 수 있는가?	일반 코드
판단 결과에 따라 위험한 작업을 실행하는가?	Jev + 코드 검증 + 사람 검토
선택지가 계속 바뀌고 계획 자체가 필요한가?	LLM이 계획, Jev가 반복 판단

Jev를 이해하는 가장 좋은 방법은 LLM의 경쟁자로 보는 것이 아니라, 프로그램 안에서 반복되는 판단을 별도 함수로 분리하는 모델로 보는 것이다. LLM이 목표와 계획을 표현하고, Jev가 다음 선택을 빠르게 고르고, 코드가 실행과 검증을 맡을 때 각 도구의 장점이 가장 분명해진다.