Article

Jev는 일반 LLM과 뭐가 다를까 - 판단을 맡기는 AI와 개발자 활용 사례

Jev라는 새 AI 모델이 나왔다는 소식을 듣고 웨이팅 리스트에 이름을 올렸습니다. 그리고 오늘 승인이 났어요. 이제 써보려는 참입니다.

사용기를 쓰기에는 아직 이르고, 먼저 어떤 모델인지부터 찾아봤습니다. 소개를 읽다 보니 GPT나 Claude에 질문하던 방식과는 쓰임새가 꽤 다르더라고요. Jev는 답변이나 코드를 길게 쓰는 대신, 프로그램 안에서 필요한 판단을 정해진 선택지와 확률로 돌려줍니다.

무엇이 다른지, 개발자들은 어디에 붙여보고 있는지 정리했습니다. 아래 성능 수치는 공식 발표나 각 제작자의 공개 자료에서 가져왔고, 제가 직접 측정한 값은 아직 없습니다.

Jev를 첫 공개 System One 모델로 소개하고 AI에 코드의 성질을 부여한다고 설명하는 TypeSafe AI 공식 사이트 — **TypeSafe AI의 Jev 소개 화면**
2026년 9월 19일 TypeSafe AI 공식 사이트 캡처. 대화보다 소프트웨어 안에서의 판단을 강조합니다. 출처: https://typesafe.ai/

Jev는 프로그램 안에서 판단을 맡습니다

TypeSafe AI는 9월 15일 Jev의 얼리 액세스 공개를 발표했습니다. 회사는 이를 System One 모델이라고 부릅니다. 빠르고 직관적인 사고를 뜻하는 심리학의 System 1에서 이름을 가져왔고, Jev라는 이름은 경제학자 윌리엄 스탠리 제번스에서 따왔다고 합니다.

쓰는 방식은 이렇습니다. 먼저 판단할 자료를 state에 넣고, 그 자료에 대해 묻고 싶은 질문을 questions에 정의합니다. 자료는 고객 문의일 수도 있고, 기사 본문이나 프로그램의 현재 상태일 수도 있어요.

예를 들어 고객 문의 하나를 넣고 담당 부서, 문제의 심각도, 긴급 여부를 각각 물을 수 있습니다. Jev는 그 문의에 대한 답장 대신, 코드에서 바로 분기하거나 정렬할 수 있는 값을 반환합니다. 공식 문서의 질문 유형은 세 가지입니다.

질문 유형	묻는 내용의 예	받는 값
Choice	이 문의를 결제·기술지원·영업 중 어디로 보낼까?	선택한 항목, 선택지별 확률, confidence
Score	이 버그가 단순한 표시 문제인지, 우회 가능한 장애인지, 사용을 막는 장애인지?	설명해 둔 단계에 따른 점수, 단계별 확률, confidence
Noul	이 문의가 긴급한 처리를 요구하나?	그렇다고 판단하는 확률을 나타내는 0~1 값

Choice는 미리 정한 항목 중에서 고릅니다. Score는 개발자가 설명한 순서 있는 단계에 따라 평가합니다. Noul은 예·아니요 질문을 확률로 받는 방식입니다. Noul에는 별도의 confidence 필드가 붙지 않습니다.

세 유형을 한 요청에 섞을 수도 있습니다. 공식 문서에 따르면 각 질문은 같은 state를 대상으로 서로 독립적으로 병렬 평가됩니다. 고객 문의를 세 번 보내는 대신, 문의 한 번에 필요한 질문들을 묶어 보내는 구조입니다.

GPT나 Claude의 Structured Outputs와는 뭐가 다를까요?

처음 설명만 보면 이렇게 생각할 수 있습니다. 기존 LLM에도 JSON으로 답하라고 하면 되지 않나 싶습니다.

실제로 어느 정도는 그렇습니다. 더 나아가 OpenAI의 Structured Outputs는 지정한 JSON 스키마를 따르도록 출력을 제한합니다. 필수 키나 enum을 지키게 하는 기능은 기존 LLM에도 이미 있습니다. 그래서 Jev의 차이를 “JSON을 잘 만든다”는 말로만 설명하면 중요한 부분이 빠집니다.

TypeSafe가 내세우는 차이는 판단을 위한 학습과 출력 방식에 있습니다. 회사는 새 모델 아키텍처와 병렬 샘플러, RLCD라는 학습 방법을 사용한다고 설명합니다. RLCD는 Reinforcement Learning for Calibrated Decisions의 약자로, 판단의 정확성과 그 판단에 붙는 확률을 함께 보정하는 데 초점을 둡니다.

비교할 부분	GPT·Claude 같은 생성형 LLM	Jev
주로 맡기는 일	답변, 요약, 번역, 코드 생성, 추론	분류, 선택, 평가, 처리 경로 결정
출력 범위	자유로운 텍스트와 코드, 스키마로 제한한 구조화 출력	미리 정의한 질문 유형에 따른 값과 확률
출력 방식	일반적으로 앞선 토큰에 이어 다음 토큰을 생성	회사 설명상 여러 판단의 출력을 병렬로 계산
불확실성 활용	모델과 API에 따라 별도 설계가 필요	선택지별 확률을 기본으로 제공하고 Choice·Score에는 confidence도 제공
복잡한 작업 구성	모델이 여러 단계의 추론과 생성을 수행할 수 있음	작은 판단으로 나누고 결과를 코드에서 조합하는 사용법을 권장

예를 들어 고객 응대 자동화를 만든다면 Jev가 담당 부서를 정하고, 생성형 LLM이 실제 답장을 쓰게 나눌 수 있습니다. 문장을 만들어야 하는 부분은 그대로 두고, 그 앞뒤에 반복해서 들어가는 판단만 따로 떼어내는 방식입니다.

확률을 준다는 건 어디에 쓸 수 있을까요?

문의의 담당 부서를 고를 때 결제와 기술지원의 확률이 비슷하다면, 곧바로 한쪽으로 보내기보다 추가 정보를 받거나 검토 대상으로 남길 수 있습니다. 한 선택지에 확률이 집중돼 있다면 자동 처리 후보로 삼을 수 있고요.

공식 confidence 문서에 따르면 confidence는 선택지별 확률 분포의 모양을 하나의 수치로 요약한 값입니다. 선택지 하나에 확률이 몰렸는지, 여러 선택지에 퍼졌는지를 표현합니다. confidence 0.9를 정답률 90%로 해석할 수는 없습니다. 실제 정확도와 어떤 관계가 있는지는 적용할 데이터에서 확인해야 합니다.

이런 값이 있으면 모든 입력을 같은 모델에 맡길 필요가 줄어듭니다. Jev가 확실하게 구분한 건 코드가 처리하고, 애매한 건 더 큰 모델이나 사람에게 넘기는 구성을 만들 수 있습니다. 자동 처리와 검토를 나누는 기준은 서비스마다 달라집니다.

다만 형식이 맞는 답과 내용이 맞는 답은 별개입니다. TypeSafe는 공식 사이트에서 ‘환각 0’을 내세우는데, 발표문에서 제시한 근거는 출력 스키마 일치를 보장한다는 설명입니다. 정해 둔 분류 항목 밖의 값을 만들어내지 않더라도, 엉뚱한 항목을 고르는 오판은 생길 수 있습니다. 현재 모델의 오판 사례도 공식 문서에 공개돼 있습니다.

빠르고 싸다는 수치는 조건과 함께 봤습니다

2026년 9월 19일 모델 문서 기준으로 jev-latest는 jev-1.13.0을 가리킵니다. 입력 100만 토큰에 0.042달러 비용이 들고, 출력 토큰은 무료입니다. 입력 10억 토큰당 42달러라는 공식 사이트의 숫자를 익숙한 단위로 바꾸면 이렇습니다.

공식 발표에 나온 응답 시간은 70~500ms입니다. 이 수치는 서비스가 위치한 미국 서부에서 주로 측정했다고 회사가 밝혔습니다. 한국에서 API를 호출했을 때의 지연시간은 직접 확인해야 합니다.

홈페이지의 ‘193.6배 빠르고 444.6배 저렴하다’는 문구는 TypeSafe가 공개한 특정 워크플로 평가에서 나온 결과입니다. 회사도 실제 사용에서 얻을 수 있는 개선 폭 중 높은 쪽에 해당할 것으로 설명합니다. 평가의 기준 답변은 사람이 만든 정답표가 아니라 GPT-6 Astra와 Fable 5.1의 평균 예측을 사용했습니다.

저는 이 숫자보다 제가 쓰는 분류 작업에서 속도와 오답률이 얼마나 나오는지가 더 궁금합니다. 문장을 생성하는 모델과 판단만 반환하는 모델은 맡는 일부터 다르기 때문에, 가격표만 놓고 비교하면 빠지는 부분이 많습니다.

다른 개발자들은 어디에 써보고 있을까요?

찾아본 외부 사례에서는 문서 분류, 글 점검, 브라우저 조작이 눈에 들어왔습니다. 아래는 제작자가 공개한 실험과 데모입니다. 장기간 운영하며 효과를 검증한 사례와는 나눠서 보겠습니다.

1kpapers: 요약은 DeepSeek, 주제 분류는 Jev

개발자 Hassan은 AI 논문 1,018편을 Jev로 분류한 실험을 공개했습니다. 논문 전체를 Jev에 넣은 것이 아니라, DeepSeek V4 Flash가 만든 요약과 제목, 후보 주제 24개를 전달했습니다. Jev는 그중 주제를 고르는 역할을 맡았습니다.

Hassan이 보고한 분류 비용은 전체 0.08달러였습니다. 논문당 종단 간 지연시간 중앙값은 256ms입니다. 요약 비용은 별도로 3.99달러였다고 합니다. 두 모델에 같은 작업을 시킨 가격 비교가 아니라, 요약과 분류를 나눠 맡긴 결과입니다.

논문을 탐색하는 1kpapers.com은 공개돼 있습니다. 다만 제작자는 기존 분류 결과를 Jev 결과로 교체하기 전에 평가 중이라고 밝혔습니다. 공개 사이트의 현재 분류 전체가 이미 Jev로 바뀌었다고 볼 근거는 없습니다.

연구기관과 주제별로 AI 논문을 탐색할 수 있는 1kpapers 사이트의 공개 화면 — **논문 탐색 사이트 1kpapers**
제작자가 Jev 주제 분류 실험에 사용한 논문 탐색 프로젝트. 제작자 발표 시점에는 기존 분류기를 교체하기 전 평가 단계였습니다. 사이트 캡처: https://www.1kpapers.com/

이 사례는 제가 생각한 사용법과도 잘 맞습니다. 글을 잘 요약하는 모델은 요약에 쓰고, 선택지 중 하나를 골라야 하는 작업은 따로 맡기는 방식입니다.

Every: 글을 다시 쓰기 전에 문제부터 찾기

Every의 Mike Taylor는 자신의 글 27편과 의도적으로 AI 문체로 만든 글 10편을 대상으로 실험했습니다. 같은 생각을 근거 없이 반복하는지, 양쪽 주장을 억지로 대칭시키는지, 쉬운 내용을 과하게 설명하는지 등 21개 항목을 물었습니다.

그의 보고에 따르면 문서 37개에 대한 판단 777개가 0.7초 이내에 돌아왔습니다. Jev가 글을 윤문한 것이 아니라, 항목별로 문제의 가능성을 수치로 반환한 결과입니다. 작성자는 실제 운영에 넣기 전에 정확도를 더 확인하고 싶다고 덧붙였습니다.

같은 글에는 Every의 Dan Shipper가 만든 작은 비교 실험도 나옵니다. 의도적으로 넣은 결함 7개 중 Jev는 6개, Fable 5.1은 7개를 잡았다고 합니다. Jev가 빠르고 저렴했던 만큼 놓친 문제도 있었던 셈입니다. 이 역시 Every 팀의 자체 실험 결과입니다.

저처럼 글을 쓰는 입장에서는 이쪽도 궁금합니다. 생성형 모델이 한 문단을 쓰면 Jev가 정해 둔 항목으로 점검하고, 지적된 부분을 생성형 모델이 다시 살펴보게 만들 수 있겠습니다. 여기서 검사하는 것은 특정 문체 패턴이며, 글의 실제 작성자를 확정하는 용도로 해석하기는 어렵습니다.

Stagehand: 브라우저에서 다음 행동 고르기

Browserbase의 Kyle Jeong은 Stagehand와 Jev를 조합한 브라우저 조작 데모를 공개했습니다. 페이지를 관찰한 뒤 접근성 트리와 작업 목표를 Jev에 보내고, 다음 행동과 대상을 고르면 Stagehand가 실행하는 흐름입니다.

화면의 픽셀을 Jev가 직접 보는 대신, 브라우저가 제공하는 구조를 텍스트 상태로 넘깁니다. Choice로 행동을 선택하고, Noul로 완료 여부나 실행 준비 상태를 묻고, Score로 진행 상황을 평가했다고 합니다. 자연어로 길게 설명할 필요가 없는 에이전트 내부 판단에 세 유형을 나눠 쓴 사례입니다.

LangChain도 이 데모를 소개하면서 모델 라우팅과 도구 실행 전 위험도 판정에 Jev를 연결하는 예제를 공개했습니다. 작업에 맞는 모델을 고르거나 위험한 도구 호출을 실행 전에 막는 구성입니다. 브라우저 데모와 LangChain의 통합 예제는 각각의 구현 사례로 볼 수 있고, 모든 웹 작업이나 위험한 명령을 안정적으로 처리한다는 검증은 별도로 필요합니다.

Unclutter: 웹페이지에서 숨길 요소 판단하기

Kitze가 공개한 Unclutter는 브라우저 확장 프로그램입니다. 페이지에서 추린 요소를 Jev에 보내 광고, 뉴스레터 가입 안내, 홍보 요소, 유지할 내용 등으로 분류하고, 그 결과로 화면에서 숨길 요소를 정합니다. 사용자가 자신의 API 키를 연결해 쓰는 공개 구현입니다.

모델이 임의의 CSS나 코드를 만드는 대신, 후보 요소를 정해진 유형으로 분류합니다. 확장은 그 결과를 로컬 규칙으로 저장해 비슷한 페이지에서 재사용하고, 불확실한 요소는 그대로 둡니다. 광고 요소를 화면에서 숨기는 기능과 광고·추적 네트워크 요청을 차단하는 기능은 별개라는 점도 README에 명시돼 있습니다.

공식 데모에서는 둠도 돌립니다

TypeSafe가 직접 공개한 사례도 있습니다. 발표문에는 둠 플레이와 위키레이싱 데모가 나옵니다. 위키레이싱은 위키백과의 한 문서에서 링크만 따라가며 목표 문서에 도착하는 게임입니다.

둠 데모는 게임 화면을 이미지로 읽는 방식 대신, 게임 상태를 텍스트로 표현한 구조화 데이터로 전달합니다. 그 상태에서 행동을 고르게 한 것이죠. 현재 Jev의 입력이 텍스트 전용이라는 점과도 연결됩니다.

위키레이싱에서는 현재 페이지에 있는 링크 후보 가운데 다음에 이동할 항목을 고릅니다. 선택지가 많을 때는 먼저 점수를 매긴 뒤 다시 선택하는 두 단계 구성을 사용했다고 합니다. 두 사례 모두 정해진 후보 중 다음 행동을 빠르게 고르는 용도를 보여주는 개발사 자체 데모입니다.

지금 모델이 어려워하는 것도 있습니다

현재 버전의 한계 문서는 꽤 구체적입니다. 숫자를 정확히 세거나 계산하는 일, 날짜의 선후 관계를 비교하는 일, 여러 단계를 거쳐야 하는 추론에서 약점이 있다고 적혀 있습니다. 조건을 문자 그대로 받아들여 의도와 다른 답을 고르는 경우도 있습니다.

긴 입력도 무조건 유리하지는 않습니다. 질문과 무관한 정보가 많아지면 정확도가 떨어진다고 합니다. 현재 한도는 요청 전체 64k 토큰이며, state와 가장 긴 질문 하나를 합친 크기는 32k 토큰 이내여야 합니다.

보안 용도로 쓸 때도 알아둘 내용이 있습니다. 공식 문서는 입력 데이터 안의 악의적인 지시나, 자기 자신을 특정 항목으로 분류하도록 유도하는 문장이 판단을 흔들 수 있다고 밝힙니다. 가드레일을 만드는 데 활용할 수는 있어도, Jev 자체의 프롬프트 인젝션 위험은 남아 있습니다.

한국어도 확인할 부분입니다. 모델 문서는 영어가 주된 학습 언어이며 정확도도 가장 좋다고 설명합니다. 한국어를 포함한 CJK 문자 입력을 처리하지만, 언어별 성능은 같지 않습니다. 이미지·음성·영상은 직접 받지 않으므로 다른 도구로 텍스트나 구조화된 정보로 바꾸는 단계가 필요합니다.

제 프로젝트에 넣는다면 이런 자리부터 떠오릅니다

제가 만든 Trawling에 대입해보면 기사 요약 앞뒤가 먼저 떠오릅니다. 원문을 읽고 주제를 고르거나, 특정 주제와 관련이 있는지 판단하거나, 요약에 붙인 근거가 원문과 맞는지 확인하는 식입니다.

예를 들어 기사의 주제는 Choice로 고르고, 기술적인 설명이 얼마나 구체적인지는 Score로 평가할 수 있습니다. 그 결과를 받아 어떤 글을 요약할지 결정하고, 한국어 요약문은 생성형 LLM이 쓰도록 나눌 수 있습니다. 아직 연결해 둔 기능은 없고, 문서를 보면서 생각해본 적용 방향입니다.

처음에는 같은 기사 묶음을 넣었을 때 분류가 얼마나 맞는지, 틀리는 입력에서 확신도 낮아지는지부터 보고 싶습니다. 특히 영어 원문과 한국어 요약문에서 결과가 어떻게 달라지는지도 궁금하고요.

일단 승인은 받았으니 이제 직접 써볼 차례입니다. 긴 답변을 얼마나 잘 쓰느냐보다, 작은 판단을 얼마나 빠르고 쓸 만하게 돌려주는지 보려고 합니다.