Jev란 무엇인가? 글을 쓰지 않고 ‘판단’하는 AI가 주목받는 이유

AI 커뮤니티에서 며칠 사이 Jev라는 이름이 자주 보이기 시작했습니다. “LLM보다 훨씬 빠르다”, “환각이 없다”, “에이전트의 판단을 맡길 모델” 같은 표현도 따라붙습니다.

그런데 Jev를 새 챗봇이나 ChatGPT·Claude의 직접 경쟁자로 보면 핵심을 놓치기 쉽습니다. Jev는 문장을 잘 쓰기 위해 만들어진 모델이 아니라, 소프트웨어가 바로 사용할 ‘판단’을 빠르게 내리기 위해 만들어진 모델입니다.

TypeSafe AI는 2026년 9월 15일 Jev를 첫 System One 모델로 공개했습니다. 입력으로 상황을 주고 미리 형태를 정한 질문을 던지면, 긴 설명 대신 선택·점수·확률을 돌려줍니다. 생성형 AI가 하던 일 중에서 “이 상황이면 어느 쪽인가?”에 해당하는 부분을 따로 떼어낸 셈입니다.

이미지 출처: TypeSafe AI의 Jev 공식 발표 제목 화면 캡처. 이 이미지는 제품 발표의 출처를 보여 주기 위한 인용이며, 아래 비교 도식은 이 글을 위해 따로 만들었습니다.

이 차이를 이해하면 Jev가 왜 갑자기 주목받는지, 그리고 “환각이 없다”는 말도 어디까지 맞는지 훨씬 선명해집니다.

Jev는 답변을 쓰지 않고 결정을 반환합니다

일반적인 LLM에 고객 문의를 하나 넣는다고 생각해보겠습니다.

“이 문의는 결제 문제인가, 기술 문제인가, 계정 문제인가?”

LLM도 물론 답할 수 있습니다. “이 문의는 결제 문제로 보입니다”라는 문장을 만들거나, JSON처럼 구조화된 형태로 결과를 내게 할 수도 있습니다. TypeSafe의 비교표도 기존 LLM이 타입이 맞는 구조화 값을 낼 수 있다는 점 자체는 인정합니다.

Jev는 여기서 출발점 자체가 다릅니다. 처음부터 문장을 생성하는 대신 정해진 선택지 안에서 판단하도록 설계됐습니다. TypeSafe 문서에서 Jev의 질문은 세 종류로 나뉩니다.

Choice와 Score에는 선택 결과만 오는 것이 아니라 각 후보의 확률 분포와 confidence도 같이 옵니다. 여러 질문은 같은 상황을 보고 병렬로 평가할 수 있습니다.

예를 들어 에이전트가 작업 중이라면 “다음 도구를 무엇으로 고를지”, “사용자에게 다시 물어봐야 할지”, “이 결과를 사람에게 넘길지” 같은 판단을 각각 질문으로 만들 수 있습니다. TypeSafe는 이런 구조를 smart if-statements, 말하자면 ‘AI가 들어간 if 문’에 가깝게 설명합니다.

핵심은 모델이 모든 작업을 대신하는 게 아닙니다. 애매해서 규칙으로 쓰기 어려웠던 분기만 AI에게 맡기고, 나머지 흐름은 코드가 잡습니다.

두 흐름을 나란히 놓으면 차이가 더 분명합니다. 일반 LLM도 구조화된 결과를 낼 수 있지만 생성한 출력을 읽고 확인하는 단계가 필요합니다. Jev는 애초에 선택지와 출력 형태를 정하고 판단값을 받습니다. 이 도식은 타입과 데이터 흐름의 차이이지, Jev가 언제나 더 정확하다는 성능 비교가 아닙니다.

왜 이름이 ‘System One’일까요?

TypeSafe는 이 모델 계열의 이름을 Daniel Kahneman의 《Thinking, Fast and Slow》에서 가져왔다고 설명합니다. 오래 고민하는 System 2와 달리, System 1은 빠르고 직관적인 판단을 가리킵니다.

Jev도 비슷한 역할을 노립니다. 긴 추론 과정을 써 내려가는 대신, 주어진 상황에서 하나의 작은 판단을 빠르게 내립니다. TypeSafe 문서도 “한 질문에는 하나의 잘 정의된 판단만 넣고, 여러 요소가 필요하면 질문을 쪼갠 뒤 코드에서 조합하라”고 권합니다.

예를 들어 “이 스타트업은 투자할 만한가?”를 한 번에 묻는 대신,

• 시장이 충분히 큰가
• 기술적으로 가능한가
• 경쟁 제품과 차별점이 있는가

처럼 나눠 판단하게 하고, 최종 가중치는 코드에서 정하는 방식입니다.

이 지점은 요즘 에이전트와 꽤 잘 맞습니다. 에이전트는 한 번의 거대한 답변보다 도구 선택 → 결과 확인 → 재시도 여부 → 위험도 확인처럼 작은 판단을 반복하는 경우가 많기 때문입니다.

속도와 가격은 확실히 눈에 띕니다. 다만 숫자는 조건을 봐야 합니다

Jev가 화제가 된 가장 직접적인 이유는 속도와 가격입니다.

2026년 9월 20일 기준 공식 문서의 안정 모델은 Jev 1.13입니다. 입력 100만 토큰당 가격은 0.042달러이고 출력 토큰은 별도 과금하지 않습니다. 요청당 문맥 길이는 64k이며 현재는 텍스트 입력만 지원합니다.

TypeSafe는 출시 글에서 end-to-end 응답 시간이 70~500ms이고, System One 형태의 질의에서는 비슷한 수준의 frontier LLM보다 40~200배 빠를 수 있다고 주장합니다. 자체 workflow 평가에서는 최대 193.6배 빠르고 444.6배 저렴하다는 수치도 제시했습니다.

다만 이 최대 숫자를 Jev의 보편적인 성능으로 읽으면 안 됩니다. TypeSafe도 직접 조건을 붙였습니다. 최대 workflow 수치는 실제 환경에서 얻을 수 있는 이득의 높은 쪽에 가까울 것으로 예상하며, 평가 workflow를 자사 model capabilities 팀이 만들었기 때문에 편향 가능성도 있다고 밝혔습니다.

즉 “Jev는 언제나 LLM보다 200배 빠르다”가 아니라, 생성이 필요 없는 작은 판단을 반복하는 구조에서는 autoregressive LLM을 호출하는 비용이 매우 비효율적일 수 있다는 쪽이 더 정확한 설명입니다.

출시 직후의 반응은 실제로 빨랐습니다

단순히 회사 발표만 화제가 된 것은 아닙니다.

Vercel은 9월 18일, Jev가 자사 AI Gateway 역사상 가장 빠르게 채택된 모델이라고 공개했습니다. Gateway에 추가된 뒤 24시간 만에 유료 팀의 약 13%가 Jev를 사용했고, 이전 모델 출시보다 빠른 초기 확산이었다고 설명했습니다.

물론 이 수치는 장기 사용률이 아닙니다. Vercel도 “이 초기 채택이 유지되는지가 다음 시험”이라고 적었습니다. 새롭고 저렴한 모델을 개발자들이 한 번씩 시험해본 효과가 섞였을 수 있습니다.

그래도 적어도 “커뮤니티에서만 이름이 돌 뿐 실제 개발자들은 안 쓰는 모델”이라고 보기는 어렵습니다. 출시 직후 실제 API 사용으로 이어진 속도 자체는 이례적이었습니다.

TypeSafe의 창업자 이력도 관심을 키웠습니다. 회사는 CEO Diogo Almeida를 RLHF와 InstructGPT의 공동 발명자로 소개하고 있고, 투자사 DCVC는 TypeSafe의 4천만 달러 Series Seed 투자를 주도했다고 같은 날 발표했습니다. Jev가 완전히 무명 팀의 실험 모델로 받아들여지지 않은 배경입니다.

그런데 정말 ‘환각이 없는 AI’일까요?

여기가 Jev를 소개할 때 가장 조심해야 할 부분입니다.

TypeSafe의 출시 글에는 Jev가 “can’t hallucinate”라고 적혀 있습니다. 아주 강한 표현입니다. 하지만 문서를 더 읽으면 이 말의 범위를 구분할 필요가 있습니다.

Jev는 가능한 출력의 형태와 선택지를 미리 정합니다. 결제·기술·계정 중 하나를 고르게 했다면 갑자기 “배송”이라는 네 번째 값을 만들어내지 않습니다. TypeSafe는 이런 type error가 구조적으로 불가능하다는 점을 보장하고, hallucination과 type-safety를 연결해 설명합니다. 회사가 그래프에 넣은 0% 수치도 실측 결과가 아니라 이 schema matching guarantee에서 나온 값이라고 밝힙니다.

하지만 정해진 세 선택지 중 틀린 것을 고를 수는 있습니다.

공식 confidence 문서도 calibration은 많은 예측을 묶어 봤을 때 확률과 실제 정확도가 잘 맞는다는 성질이지, 개별 답변이 맞다는 보장은 아니라고 설명합니다. Jev 1.13의 한계 문서에는 실제로 잘못 판단하기 쉬운 조건들이 따로 적혀 있습니다.

그래서 Jev의 “무환각”은 이렇게 읽는 편이 안전합니다.

엉뚱한 형식의 자유로운 출력을 만드는 문제를 구조적으로 없앴지만, 의미상 잘못된 판단까지 없앤 것은 아닙니다.

이 구분이 꽤 중요합니다. 자동화 시스템에서는 “예상하지 못한 형식의 답”과 “형식은 맞지만 내용이 틀린 답” 모두 문제이지만, 두 오류는 대응 방법이 다릅니다.

Jev는 앞의 문제를 모델 구조로 줄이고, 뒤의 문제는 확률과 confidence를 이용해 다루려는 접근에 가깝습니다. confidence가 낮으면 사람이나 더 느린 추론 모델로 넘기는 식입니다.

Jev도 잘 못하는 일이 꽤 분명합니다

흥미로운 점은 TypeSafe가 Jev 1.13의 약점을 별도 문서로 꽤 구체적으로 공개했다는 것입니다.

현재 버전은 계산기처럼 쓰면 안 됩니다. 정확한 숫자 계산, 카운팅, 날짜의 앞뒤나 기간 비교에 약합니다. 복잡하게 몇 단계를 건너가야 하는 간접 추론도 정확도가 떨어질 수 있습니다. 필요한 내용과 상관없는 정보가 state에 너무 많이 들어가면 성능이 나빠지고, adversarial content에도 주의가 필요합니다.

그리고 가장 명확한 한계가 하나 있습니다.

Jev는 글을 쓰는 모델이 아닙니다.

설명문을 만들고, 코드를 생성하고, 아이디어를 길게 전개하는 작업은 기존 생성 모델의 영역입니다. TypeSafe 문서도 generation이 필요하면 generative model을 쓰라고 명시합니다.

그래서 Jev와 GPT·Claude를 “누가 더 똑똑한가”로 한 줄 비교하는 것부터 조금 어색합니다. 쓰임이 겹치는 구간은 있지만 목표 함수가 다릅니다.

실제 테스트에서는 ‘만능 대체재’보다 좋은 zero-shot 판단기로 보였습니다

TypeSafe 밖의 테스트도 하나 나왔습니다.

검색 인프라 회사 Parallel은 Jev를 자사 실무 작업에 직접 넣어봤습니다. 검색 결과의 순서를 다시 매기는 reranking에서 Jev는 NDCG@10 0.7을 기록해 자체 커스텀 reranker 하나와 비슷한 수준이었고, 큰 내부 모델들과 latency도 경쟁력이 있었다고 보고했습니다.

반면 주제 분류와 “이 검색어가 최신 정보가 필요한가”를 판단하는 freshness classification에서는 Parallel의 전문 내부 모델이 더 잘했습니다. 비용도 자체 인프라를 이미 갖춘 Parallel 기준으로는 Jev가 문서당 더 비쌌습니다.

Parallel의 정리가 현실적인 기준점이 됩니다.

Jev의 속도·비용 비교 대상은 주로 autoregressive LLM이지, 모든 전용 classifier가 아닙니다. 특정 업무에 맞춰 데이터도 모으고 모델도 학습해 둔 조직이라면 기존 전문 모델이 더 빠르고 저렴할 수 있습니다.

대신 그런 모델이 없는 곳에서는 이야기가 달라집니다. Jev는 별도 학습 없이 질문과 선택지를 바꿔 새로운 분류·점수화 작업을 바로 시도할 수 있습니다. Parallel도 이 zero-shot 출발점을 Jev의 강점으로 꼽았습니다.

Jev의 특징을 살리려면 ‘작은 판단 여러 개’로 써야 합니다

Jev를 가장 Jev답게 쓰는 방법은 긴 업무 하나를 통째로 맡기는 것이 아닙니다. 코드가 전체 흐름을 잡고, 사람이 읽어야만 알 수 있던 좁은 판단만 Jev에 맡기는 방식입니다.

공식 가이드도 날짜 계산, 데이터베이스 조회, 파일 저장처럼 답이 정해진 일은 코드에 남기라고 권합니다. Jev에는 필요한 맥락만 보내고, 같은 내용을 보는 독립적인 질문은 한 요청에 묶습니다. 결과는 코드가 조합하며 confidence가 낮으면 자동으로 밀어붙이지 않고 사람이나 더 비싼 추론 모델로 넘깁니다.

이 원칙을 실제 업무에 대입하면 다음과 같은 모양이 됩니다.

이 블로그의 Research Card 후보 정리에 대입한다면, Jev가 글을 대신 쓰는 게 아니라 수집된 자료의 주제·관련성·검토 필요도를 한꺼번에 판단해 사람이 먼저 볼 순서를 만드는 역할이 더 잘 맞습니다. 최종 주제 선정과 글 작성은 여전히 사람과 생성 모델의 몫입니다.

효율을 더 끌어올리려면 질문을 한 번씩 따로 보내기보다 같은 state를 보는 Choice·Score·Noul을 한 요청에 묶는 편이 좋습니다. 반대로 “이 자료를 분석해서 가장 좋은 다음 행동을 정해줘”처럼 여러 판단과 실행을 한 문장에 섞으면 Jev의 장점이 흐려집니다.

직접 써보고 싶다면 Playground부터 시작하면 됩니다

처음부터 코드를 만들 필요는 없습니다. 공식 Quick Start의 가장 짧은 경로는 다음과 같습니다.

1. TypeSafe Playground에 로그인하고, 실제로 분류해보고 싶은 문의나 문서 한 건을 state에 붙여 넣습니다.
2. 먼저 이 글은 긴급한가?처럼 답이 비교적 분명한 Noul 질문 하나를 만듭니다.
3. 이어서 Choice로 주제를 나누고, Score로 중요도나 관련성의 단계를 정합니다. 한 질문에는 한 가지 판단만 넣습니다.
4. 사람이 직접 내린 판단과 결과를 몇 건 대조합니다. 처음에는 자동 실행 기준을 보수적으로 잡고, confidence가 낮은 결과는 사람 검토로 보냅니다.

쓸 만하다고 판단되면 그때 API로 옮기면 됩니다. 대시보드에서 API 키를 발급받아 POST /v1/systemone을 호출하거나, Python 3.10 이상 환경에서 pip install typesafe-sdk로 SDK를 설치할 수 있습니다. SDK는 TYPESAFE_API_KEY 환경변수를 읽고 기본적으로 jev-latest를 호출합니다.

코딩이 부담된다면 공식 Quick Start에 안내된 TypeSafe agent skill을 설치하고, 코딩 에이전트에게 “이 문서들을 여러 기준으로 평가하는 간단한 도구를 만들어 달라”고 요청하는 경로도 있습니다. 다만 어떤 방식이든 먼저 판단 기준과 사람이 다시 볼 조건을 정해야 합니다. API 연결 자체보다 그 기준을 설계하는 일이 더 중요합니다.

Jev가 흥미로운 건 ‘LLM 이후’라서가 아니라 역할을 나누기 때문입니다

Jev를 보면서 “이제 LLM이 끝나는 건가?”라고 생각할 필요는 없어 보입니다. 오히려 반대에 가깝습니다.

지금까지는 AI가 필요한 일이 생기면 일단 거대한 생성 모델에 문장을 보내는 방식이 흔했습니다. 분류도 LLM, 점수도 LLM, 라우팅도 LLM, 최종 설명도 LLM이 맡았습니다. 하나의 범용 모델이 너무 많은 역할을 한 셈입니다.

Jev가 던지는 질문은 그 모든 단계에 정말 생성 모델이 필요한가입니다.

에이전트가 계획을 세우고 글을 쓰는 일은 큰 생성·추론 모델이 맡고, 그 사이에서 반복되는 도구 선택·위험도 평가·결과 검증·사람 검토 여부 판단은 훨씬 작고 빠른 decision model이 맡을 수 있습니다.

이것이 언제나 더 좋은 구조라고 아직 단정할 수는 없습니다. Jev는 공개된 지 며칠밖에 되지 않았고, 장기 운영 데이터와 독립 평가도 더 필요합니다. 현재 모델의 약점도 명확합니다.

그럼에도 Jev가 흥미로운 이유는 분명합니다. “AI 모델은 무엇을 생성할 수 있는가?”에서 “소프트웨어 안에서 어떤 판단을 얼마나 싸고 빠르게 반복할 수 있는가?”로 질문을 바꿨기 때문입니다.

에이전트와 자동화가 실제 제품 안으로 더 깊게 들어갈수록 이 구분은 꽤 중요해질 수 있습니다.

기억할 네 가지

• Jev는 챗봇이 아니라 판단 모델입니다. 텍스트를 생성하지 않고 Choice·Score·Noul 같은 정해진 형태의 판단과 확률을 반환합니다.
• 빠르고 저렴하다는 수치는 워크로드를 봐야 합니다. TypeSafe의 최대 수치는 자체 System One workflow 기준이며, 전문 classifier가 이미 있는 조직에서는 Jev가 항상 더 싸거나 빠르지 않습니다.
• ‘환각이 없다’는 말은 의미상 오답이 없다는 뜻이 아닙니다. 타입 밖의 출력을 만들지 않는 구조적 보장과 판단의 정확성은 구분해야 합니다.
• 가장 흥미로운 위치는 LLM 대체보다 분업입니다. 생성·추론 모델 사이에서 반복되는 route·score·verify 같은 결정을 맡는 레이어로 볼 때 Jev의 특징이 가장 잘 드러납니다.

참고 자료

• TypeSafe AI, Introducing System One Models & Jev, 2026-09-15
• TypeSafe AI Docs, Introduction
• TypeSafe AI Docs, System One
• TypeSafe AI Docs, Confidence
• TypeSafe AI Docs, Models
• TypeSafe AI Docs, Jev 1.13 jaggedness, last reviewed 2026-09-17
• TypeSafe AI Docs, Quick start
• TypeSafe AI Docs, How to build with TypeSafe
• TypeSafe AI Docs, Example use cases
• Vercel, Jev is the fastest-adopted model in AI Gateway history, 2026-09-18
• Parallel, Testing out Jev: real-world developer experience, 2026-09-18
• TypeSafe AI, Team
• DCVC, TypeSafe emerges from stealth with a new way of doing AI, 2026-09-15