고객 문의가 하나 들어왔다고 해봅시다. “카드가 두 번 결제됐어요. 추가 결제를 환불해주세요.”

이때 시스템이 제일 먼저 해야 할 일은 예쁜 답장을 쓰는 게 아닙니다. 이 문의는 어느 팀이 맡아야 하는지, 사용자가 환불을 요청한 게 맞는지, 바로 자동 처리해도 되는지 아니면 사람이 한 번 봐야 하는지를 정하는 겁니다. 답장은 그 다음이어도 늦지 않습니다.

Jev는 바로 이 “먼저 정해야 하는 작은 판단”을 맡기기 위해 나온 모델입니다. 글을 쓰지 않습니다. 대신 정해진 선택지 중에서 무엇이 맞는지, 확률과 함께 돌려줍니다.

짧게 말하면 상황을 넣으면 소프트웨어가 바로 쓸 수 있는 결정이 나온다는 아이디어입니다.

Jev를 한 문장으로 말하면

Jev는 TypeSafe AI가 2026년 9월 15일에 공개한 첫 번째 System One 모델입니다. GPT나 Claude처럼 긴 글을 쓰거나 코드를 짜는 모델이 아닙니다.

TypeSafe의 표현을 빌리면 “unstructured state in, typed probabilistic decisions out”, 즉 복잡한 상황을 넣으면 타입이 정해진 확률적 판단이 나온다는 겁니다. 쉽게 말하면 판단 함수에 가까운 모델입니다.

이름도 그 방향을 말해줍니다. System One은 Daniel Kahneman의 생각에 관한 책에서 말하는 빠르고 직관적인 사고에서 따왔고, Jev는 증기기관 효율이 석탄 수요를 늘렸다고 본 William Stanley Jevons에서 따왔습니다. 지능이 싸지고 빨라지면 쓰는 곳이 폭발적으로 늘어난다는 기대가 담겨 있습니다.

Jev는 지금 early access로 제공되고 있고, 입력 토큰 기준 $0.042 / 백만 토큰, 출력 토큰 무료라는 가격을 공개하고 있습니다. 요청 제한은 64,000 토큰 수준이고, 텍스트 입력만 받습니다.

왜 이런 모델이 나왔을까

지금까지 AI를 쓴다고 하면 대부분 채팅창을 먼저 떠올렸습니다. 사람이 질문하면 모델이 문장을 만들고, 사람이 읽는 구조입니다.

그런데 실제 소프트웨어 안에서는 문장이 필요 없는 순간이 훨씬 많습니다. 결제팀으로 보낼지, 검색이 필요한지, 차단할지, 다시 시도할지, 알림을 보낼지 같은 선택입니다. 프로그램이 마지막에 소비하는 건 문단 하나가 아니라 카테고리 하나, 점수 하나, 예/아니오 하나인 경우가 많습니다.

일반 LLM으로도 물론 분류는 됩니다. JSON 스키마를 주고 billing, support, sales 중 하나를 고르게 할 수 있습니다. 문제는 모델 내부에서는 여전히 중괄호를 만들고 키 이름을 만들고 따옴표를 만드는 식으로 다음 토큰을 하나씩 생성한다는 점입니다. 원하는 답이 billing 하나뿐이라면 이 과정은 꽤 비싼 우회로가 됩니다.

Jev의 생각은 단순합니다. 애초에 문장을 만들지 말고, 후보들의 확률을 바로 계산하자는 겁니다.

이 관점이 낯설지 않다면 정상입니다. RAG의 검색과 답변 생성 과정을 볼 때도 결국 “모델이 무엇을 아는가”만큼 “어떤 자료를 찾아 전달했는가”가 중요했습니다. Jev도 비슷합니다. 모델이 글을 얼마나 잘 쓰느냐보다, 앱이 필요로 하는 출력 형태에 모델을 맞추느냐가 핵심입니다.

어떻게 동작하나: 상태 하나, 질문 여러 개

Jev 호출은 생각보다 단순합니다. 크게 두 가지를 보냅니다.

  1. state: 판단할 상황. 문자열, JSON 객체, 텍스트 배열로 넣을 수 있습니다. 고객 문의 내용, 거래 내역, 계정 정보 같은 것들입니다. 따로 기억해두는 메모리는 없고, 매 요청마다 필요한 상황을 함께 보냅니다.
  2. questions: 이 상황에 대해 물어볼 질문들. 답의 형태를 미리 정해둡니다.

질문은 세 종류입니다.

종류 하는 일 반환 예시
Choice 정해진 선택지 중 하나 고르기 billing 97%, support 2%, other 1% + confidence
Score 순서가 있는 기준으로 점수 매기기 긴급도 low / medium / high에 대한 점수와 분포
Noul 어떤 문장이 참일 확률 추정하기 refund requested 0.99 같은 0~1 사이 값

Noul이라는 이름은 Bernoulli 분포에서 왔다고 TypeSafe 쪽에서 직접 밝힌 바 있습니다. 참일 확률을 그대로 숫자로 돌려주는, yes/no용 기본 단위라고 보면 됩니다.

재미있는 점은 여러 질문을 한 번에 보내면 병렬로 평가된다는 겁니다. TypeSafe 설명에 따르면 질문을 추가해도 응답 시간은 거의 그대로이고, 추가 질문 분량의 토큰 비용만 더 듭니다. “어느 팀이 맡아야 하는가?”, “환불 요청인가?”, “자동 처리해도 되는가?” 같은 판단을 한 요청으로 묶을 수 있습니다.

state: "카드가 두 번 결제됐어요. 추가 결제를 환불해주세요."
questions:
  - team: [billing, support, sales]
  - refund_requested: yes/no 확률
  - auto_route_ok: yes/no 확률
answers:
  - team: billing 97%
  - refund_requested: 0.99
  - auto_route_ok: 0.82 + confidence

위 숫자는 이해를 돕기 위한 예시입니다. 실제 값은 입력과 모델 버전에 따라 달라집니다.

학습 방식도 일반 LLM과 방향이 다릅니다. TypeSafe는 Jev를 RLCD(Reinforcement Learning for Calibrated Decisions)로 학습했다고 설명합니다. 사람이 좋아하는 문장을 뽑는 RLHF나, 정답이 명확한 문제를 맞히는 RLVR과 달리, 확률이 실제 결과와 어긋나지 않게 맞추는 데 초점을 둔다는 겁니다. 0.9라고 말한 것들은 실제로도 대략 90% 정도는 맞아야 한다는 뜻입니다. 이게 잘 맞아야 임계값을 걸고 자동 처리를 할 수 있습니다.

LLM과 무엇이 다른가

겉으로 보면 “LLM에 구조화 출력을 씌운 것과 뭐가 다르지?”라는 생각이 들 수 있습니다. 실제로 그 지적은 공개 직후 바로 나왔습니다. Sean Goedecke는 Jev를 다룬 글에서 Jev가 완전히 새로운 종류라기보다, 구조화 출력만 내는 데 특화된 인터페이스라고 봤습니다.

차이를 표로 정리하면 이렇습니다.

비교 일반 LLM Jev
주 출력 문장, 코드, 추론 과정 선택지, 점수, 확률
생성 방식 토큰을 순서대로 생성 여러 판단을 병렬로 계산
잘 맞는 일 글쓰기, 대화, 코딩, 열린 추론 분류, 라우팅, 점수, 검증, 가드레일
확신 표현 물어보면 답은 하지만 과신하는 경우가 많음 매 답변에 확률과 confidence를 함께 반환
지연 시간 수 초에서 수십 초까지 다양 TypeSafe 발표 기준 70~500ms
가격 구조 입력 + 출력 과금, 출력이 더 비쌈 입력 $0.042/백만 토큰, 출력 무료

Sean의 비판도 함께 볼 필요가 있습니다. 일반 LLM도 답변 앞부분을 미리 채우고 실제로 고를 답만 1~2개 토큰으로 제한하면 Jev와 비슷한 빠른 구조를 만들 수 있다는 겁니다. 본인이 Qwen2.5 1.5B로 시험했을 때는 일반 구조화 출력보다 2~3배 빨라졌다고 합니다. 즉 속도 이점 중 일부는 모델 구조가 아니라 판단만 하도록 제한한 추론 방식에서 나올 수 있다는 이야기입니다.

그래서 Jev의 기술적 해자를 과장해서 보면 안 됩니다. 다만 Sean도 Jev 자체는 반긴다고 말합니다. 구조화 판단만을 위해 모델, API, 가격, 확률 출력, 개발 경험을 통째로 설계했다는 점이 중요하다는 겁니다. 이런 인터페이스가 퍼지면 다른 연구소나 오픈소스 쪽에서도 비슷한 결정용 모델이 나올 수 있습니다.

193배 이야기는 어떻게 읽어야 하나

Jev를 검색하면 “193.6배 빠르고 444.6배 싸다”는 숫자가 가장 먼저 눈에 띕니다. 이 숫자는 그대로 믿기보다, 어디서 나온 숫자인지부터 보는 편이 좋습니다.

TypeSafe 설명에 따르면 이 숫자는 자사 System One workflow benchmark에서 나온 것으로, 회사 스스로 실제 이득의 높은 쪽이라고 밝히고 있습니다. 네 개의 워크플로를 TypeSafe 팀이 직접 만들었고, 정답 대신 GPT-6 Astra와 Fable 5.1 두 모델의 평균을 기준으로 삼았습니다. 비교용 LLM은 TypeSafe가 만든 구조화 출력 wrapper를 씌웠는데, 이 방식이 정확도는 높지만 느리고 비싸질 수 있다고 회사도 적고 있습니다.

독립 측정들은 방향은 비슷하되 배율은 제각각입니다. 한 검증에서는 단일 yes/no 질문 하나만 바꾸면 1.7배 수준이었지만, 여섯 단계 판단을 각각 시키는 워크플로를 Jev 한 호출로 묶으면 100배 수준이 나왔다고 합니다. 짧은 분류에서는 기존 소형 모델과 비슷하거나 약간 앞서는 수준이었고, 입력이 길어지거나 라벨이 모호해지면 정확도와 확신이 함께 떨어졌다는 보고도 있습니다.

정리하면 이렇습니다.

  • Jev가 잘 맞는 모양에서는 차이가 크게 벌어질 수 있다.
  • 단일 분류 한 번만 놓고 보면 차이는 생각보다 작을 수 있다.
  • 문장이 한 번이라도 필요하면 그 부분은 다시 LLM 비용과 속도로 돌아간다.

그러니 질문은 “Jev가 몇 배 빠르냐”보다 “우리 일에서 반복되는 판단 호출을 얼마나 묶을 수 있느냐”에 가깝습니다. 모델을 추가 학습시키는 방식과의 차이를 볼 때도 마찬가지였지만, 방법은 먼저 정하지 말고 문제 모양부터 보는 게 좋습니다.

“Zero Hallucinations”는 틀리지 않는다는 뜻이 아니다

TypeSafe는 Jev가 hallucination이 없다고 표현합니다. 이 말은 조심해서 읽어야 합니다.

Jev는 정해진 스키마 밖의 이상한 문자열을 만들어내지 않습니다. blue, red, yellow 중에서 고르라고 하면 갑자기 네 번째 색을 지어내지 않는다는 뜻입니다. 타입 오류를 막는다는 의미에서는 맞는 말입니다.

하지만 blue, red, yellow 중 red를 고르면 형식은 완벽해도 내용은 틀린 겁니다. Sean이 “semantic dodge”라고 비판한 지점이 여기입니다. 정해진 선택지 중 잘못된 답을 고를 가능성은 여전히 있습니다.

TypeSafe도 문서에서 현재 모델이 어려워하는 경우를 따로 적고 있습니다. 셈하기, 세기, 날짜, 적대적 지시, 관련 없는 문맥, 서로 충돌하는 기준, 긴 글 생성 같은 것들입니다. 입력에 필요 없는 정보를 많이 넣으면 정확도가 떨어질 수 있다고도 합니다. 결국 형식은 지켜주지만, 의미가 맞는지는 따로 검증해야 하는 모델이라고 보는 게 정확합니다.

그래서 실무 구조는 어떻게 바뀌나

Jev를 단독으로 쓰기보다, 역할 분담으로 보는 게 현실적입니다. 자주 거론되는 구조는 이렇습니다.

  1. Jev가 먼저 평가합니다. 요청 종류, 위험도, 복잡도를 판단합니다.
  2. 코드가 정책과 자격을 확인하고 라우팅합니다. 환불 요청일 확률이 99%라는 말은 환불 자격이 있다는 뜻이 아닙니다. 결제 기록, 환불 정책, 승인 규칙, 예외 케이스는 코드가 봐야 합니다.
  3. LLM이 마지막에 사람에게 보여줄 문장을 씁니다. 긴 설명이나 설득력 있는 답장이 필요할 때만 호출합니다.
  4. 애매한 케이스는 사람에게 넘깁니다. 확률이 중간에 걸쳐 있으면 붙잡고 있지 말고 에스컬레이션하는 편이 낫습니다.

이 분업이 중요한 이유는 책임이 선명해지기 때문입니다. 모델은 요청의 의미를 읽고, 코드는 결정 가능한 규칙을 집행하고, LLM은 사람이 읽을 문장을 만듭니다.

조금 더 넓게 보면 속도 계층을 나누는 설계도 가능합니다. Sean이 Doom 실험에서 소개한 방식인데, 몇 초에 한 번은 강한 LLM이 상위 목표를 정하고, 100~200ms마다 도는 빠른 루프는 그 목표 안에서 구체적인 행동만 고르게 하는 겁니다. 일반 서비스로 가져오면 느리지만 똑똑한 모델이 전략을 세우고, 빠른 모델이 수많은 미세 결정을 맡는 구조가 됩니다.

또 하나 재미있는 쓰임은 프로토타이핑입니다. 처음에는 데이터가 없으니 Jev 같은 범용 분류기로 프롬프트만 바꿔가며 붙여봅니다. 잘 동작하면 입력과 최종 판단을 저장해두고, 나중에 그 서비스만의 작은 전용 분류기를 학습해서 교체하는 겁니다. 먼저 범용 지능으로 검증하고, 성공한 것만 전용 모델로 옮기는 흐름입니다.

Doom 데모도 같은 맥락에서 보면 이해가 쉽습니다. 화면 이미지를 직접 보는 게 아니라 게임 상태를 텍스트와 구조화된 데이터로 전달하고, 방아쇠를 누를지, 어디로 움직일지, 현재 목표를 무엇으로 할지를 빠르게 반복합니다. TypeSafe도 전용으로 학습한 작은 봇이 더 잘할 수 있다고 말합니다. 데모가 보여주는 건 게임 실력이 아니라, 자연어로 지시할 수 있는 범용 모델이 실시간 루프에 들어갈 정도로 빨라졌다는 점입니다.

어떤 때 쓰면 좋고, 어떤 때 안 맞나

Jev가 어울리는 일에는 공통점이 있습니다. 자주 반복되고, 답의 형태가 정해져 있고, 사람이 매번 규칙으로 다 쓰기에는 애매한 판단입니다.

  • 어떤 모델이나 워크플로로 넘길지 고르는 모델 라우팅
  • 고객 문의 분류와 우선순위, 에스컬레이션 경로 정하기
  • 에이전트가 하려는 행동이 기준에 맞는지 검증하기
  • 정책 조건에 걸리는지 보는 컴플라이언스 검토
  • 대량 레코드의 속성 추출과 점수 매기기
  • 화면과 행동을 보고 다음 옵션을 고르는 실시간 개인화

반대로 처음부터 안 맞는 일도 분명합니다. 긴 글 생성, 코딩, 복잡한 다단계 추론, 열린 대화는 LLM이 맡는 게 낫습니다. 입력이 통째로 긴 문서를 읽어야 하거나, 라벨 자체가 모호하거나, 비즈니스 논리가 많이 얽힌 질문에서는 Jev의 정확도와 확신이 함께 떨어질 수 있습니다. 영어가 아닌 입력에서도 성능을 따로 확인해야 합니다.

운영 관점에서는 세 가지를 꼭 챙기는 게 좋습니다.

  • 확률을 자기 데이터로 검증하기. 90%라고 말하는 숫자가 실제로도 90% 정도 맞는지 봐야 임계값을 걸 수 있습니다.
  • 버전을 고정하기. jev-latest 같은 별칭은 바뀔 수 있으니, 운영에서는 jev-1.13.0 같은 버전 ID를 기록하고 고정하는 편이 안전합니다.
  • 애매한 구간을 비워두지 않기. 확신이 낮으면 코드 분기나 사람 검토로 넘기는 규칙을 미리 정해둡니다.

엔지니어가 가져갈 질문 하나

Jev를 다 보고 나면 남는 질문은 의외로 단순합니다.

내 앱의 다음 단계는 실제로 무엇을 소비하는가?

문단 하나가 필요한가, 카테고리가 필요한가, 점수가 필요한가, 예/아니오 판단이 필요한가. 이 질문에 답하면 어떤 모델을 써야 할지, 그리고 어디까지를 코드가 맡아야 할지가 훨씬 선명해집니다.

모든 AI 호출이 문장 생성일 필요는 없습니다. 다음 단계가 카테고리나 점수, 예/아니오를 소비한다면 굳이 모든 걸 문장 생성으로 시작하지 않아도 됩니다. 모델은 범위가 정해진 판단을 맡고, 코드는 정책과 자격을 맡고, LLM은 최종 언어 생성을 맡는 구조가 현실적인 해답이 될 수 있습니다.

Jev가 그 미래의 승자가 될지는 아직 모릅니다. 기술적 해자가 얼마나 큰지도 불분명하고, 긴 추론에서는 frontier LLM이 훨씬 강합니다. 그래도 Jev가 던진 방향은 지켜볼 만합니다. AI가 화면 속 챗봇이 아니라, 소프트웨어 내부 곳곳에서 돌아가는 작은 판단 레이어가 되는 그림입니다. 결정 모델이라는 제품 카테고리가 생길지, 다른 연구소와 오픈소스가 비슷한 choice-only 저지연 모델을 내놓는지가 앞으로의 신호가 될 겁니다.

핵심 정리

Jev는 글을 쓰는 모델이 아니라, 정해진 형태의 판단을 확률과 함께 돌려주는 모델입니다. 상황을 넣고 Choice, Score, Noul 질문을 던지면 여러 판단을 병렬로 평가합니다. 빠르고 싸게 자주 부를 수 있는 대신, 긴 추론과 문장 생성은 맡지 않습니다.

기억할 점은 세 가지입니다. 속도와 비용 숫자는 문제 모양에 따라 크게 달라지니 자기 데이터로 쟤야 합니다. 타입이 안전하다는 말은 판단까지 맞다는 뜻이 아닙니다. 결국 중요한 건 Jev를 쓰느냐 마느냐보다, 모델이 판단할 일과 코드가 검증할 일을 어떻게 나누느냐입니다.

참고 자료