Jev는 정말 놀랍다 — 초고속 구조화 결정 엔진

---

source: t3dotgg title_original: Jev is incredible video_id: F3YXg7AaKWE video_url: https://www.youtube.com/watch?v=F3YXg7AaKWE drop_date: 2026-09-21 channel: t3dotgg (Theo)

URL: https://www.youtube.com/watch?v=F3YXg7AaKWE
날짜: 2026-09-21
채널: t3dotgg

📌 핵심 질문 / 핵심 논점

==Jev는 범용 LLM을 대체하는 모델이 아니라, 구조화된 데이터를 빠르게 분류·정렬·검증하고 항상 약속된 JSON 형태로 반환하는 ‘System 1’ 함수다.==

• 텍스트를 길게 생성하거나 코드를 작성하는 대신, 입력된 상태에서 곧바로 타입이 지정된 확률적 결정을 반환한다.
• 형식은 결정론적으로 지키면서도 내용의 정답 여부는 확률과 불확실성으로 표현하므로, 자동화 파이프라인이 실패 가능성을 감안해 다음 경로를 선택할 수 있다.
• 입력 토큰 비용이 약 100만 토큰당 0.04달러 수준이고 출력 토큰은 사실상 무료이며, 전통적인 분류 작업보다 40~200배 빠르다.
• 32k 토큰 문맥과 얕은 판단 능력 때문에 복잡한 추론, 코드베이스 탐색, 다른 LLM의 결과를 종합하는 심사, 컨텍스트 압축에는 부적합하다.

Jev의 가치는 이전에는 비용과 지연 시간 때문에 포기했던 수많은 작은 판단을 소프트웨어의 조건문처럼 실행 가능하게 만드는 데 있다. 사람이나 에이전트가 직접 호출해 대화하는 모델이 아니라, 애플리케이션이 상태를 넘기면 타입 안전한 결정을 받아 다음 로직으로 이어가는 라이브러리 또는 함수로 이해해야 한다.

1. Jev가 기존 LLM과 다른 이유

Jev는 ‘조금 더 코딩을 잘하는 새 LLM’이 아니라 데이터 처리와 구조화된 의사결정 자체를 목표로 삼는다.

1.1. 생성 모델이 아닌 분류 모델

1. 일반적인 신형 모델과의 차이

   1. 생성 중심이 아님: 텍스트 작성, 코드 생성, 긴 대화 같은 현재 LLM의 대표 기능을 목표로 하지 않는다.
   2. 분류 중심임: 데이터를 조직하고 분류하는 작업에 특화되며, 지정한 형식에 맞는 JSON을 정확하게 반환한다.
   3. 대체 대상이 다름: Fable이나 Astra 같은 범용 모델을 대체하는 도구가 아니다. 그런 모델이 이미 할 수 있는 구조화 작업에 비싼 범용 모델을 쓰는 경우에만 비용·속도 측면의 대안이 된다.

2. 초기 데모가 보여준 범위

   1. iOS 시뮬레이터: 컴퓨터 사용(computer use)을 번개처럼 빠르게 수행하는 데모가 화제를 모았다.
   2. Minecraft: 게임 상태를 빠르게 읽고 행동을 선택해 게임을 진행했다.
   3. 컨텍스트 압축: 기존에 몇 분 걸리던 압축을 1초 미만에 수행하는 사례가 공유됐다. 다만 빠르다는 사실이 적합성을 뜻하지는 않으며, 뒤에서 컨텍스트 압축 사용을 강하게 비판한다.

1.2. System 1과 System 2

1. 두 종류의 사고

   1. System 1: Daniel Kahneman의 『Thinking, Fast and Slow』에서 가져온 개념으로, 셔츠가 파란색인지 즉시 알아보는 것처럼 빠르고 직관적이며 노력 없이 작동하는 판단이다.
   2. System 2: 문제를 천천히 분해하고 숙고하는 추론이다. 기존 추론 모델은 이 역할을 맡는다.

2. Jev라는 이름의 뜻

   1. Jevons의 역설: 증기기관이 효율적이 되자 석탄 소비가 줄기는커녕 오히려 늘어난 현상에서 이름을 따왔다.
   2. 효율성이 여는 수요: Jev도 새 능력을 만들어내기보다 기존에 가능했지만 너무 느리거나 비싸서 쓰지 못했던 분류·판단을 더 많은 곳에서 실행 가능하게 한다.

2. 개발 배경과 자동화 지향 스택

Jev는 대화형 모델의 확장판이 아니라 소프트웨어 자동화 안에 직접 삽입되는 프론티어 결정 모델이다.

2.1. Typesafe AI와 Dio의 문제의식

1. 창업자의 배경

   1. Dio: OpenAI에서 일했으며 ChatGPT와 RLHF의 공동 발명에 기여한 인물로 소개된다.
   2. RLHF의 한계: 인간 선호에 맞춰 대화·행동을 만드는 RLHF는 모델 행동에는 효과적이지만, Dio가 중요하게 본 분류 작업을 충분히 개선하지 못했다.

2. 자동화가 부족했던 이유

   1. 지난 4년의 질문: 언어 모델은 오랫동안 채팅에서 인간을 능가했는데, 왜 그만큼의 자동화가 현실에 배치되지 않았는가가 핵심 문제였다.
   2. 새로운 방향: 텍스트 생성과 범용 사용을 덜 중시하고 분류에 집중하면 훨씬 빠르고 저렴한 모델을 만들 수 있다.
   3. 개발 기간: 2년간의 스텔스 개발, 수많은 기술적 난제와 연구 돌파 끝에 Typesafe AI가 첫 System 1 모델을 공개했다.

2.2. ‘함수처럼 호출되는 모델’의 구조

1. 호출 흐름

   1. 트리거: 사람의 질문이 직접 모델을 깨우는 것이 아니라, 사람이나 다른 시스템이 코드를 실행한다.
   2. 입력: 코드가 애플리케이션 상태 또는 구조화 가능한 텍스트 데이터를 모델에 넘긴다.
   3. 출력: Jev가 정의된 스키마를 따르는 JSON을 반환하고, 프로그램이 그 결과에 따라 다음 분기와 작업을 선택한다.

2. 새로 만든 기술 스택

   1. 모델 아키텍처: 자동화를 목표로 설계한 새로운 구조를 사용한다.
   2. 병렬 샘플러: 여러 입력을 최대 효율로 동시에 처리한다.
   3. 보정된 결정을 위한 강화학습: 정답만 흉내 내는 대신 확률과 불확실성을 일관되게 제공하도록 학습했다.
   4. 접근 방식: 최초 공개 버전은 얼리 액세스·초대 전용이며 OpenRouter, Vercel AI Gateway 등에서 접근할 수 있다.

3. 핵심 계약

   1. 문자열 생성 포기: 자연어를 길게 뽑는 기능을 희생하고 구조화된 출력에 최적화했다.
   2. 형식의 비환각성: JSON 스키마가 정해지면 모델이 필드나 형식을 바꾸거나 만들어내지 않는다.
   3. 프론티어 지능 함수 호출: 정형화되지 않은 상태를 넣고, 타입이 지정된 확률적 결정을 받는 함수에 가깝다.

3. 타입 안전성과 BAML 비교

언어 모델의 비결정성을 코드의 계약과 결합하는 문제를 이해해야 Jev의 위치가 분명해진다.

3.1. BAML이 해결하는 문제

1. 에이전트와 실제 코드 사이의 인터페이스

   1. 타입 정의: 예를 들어 감정 분류기의 label 타입에 positive, negative, neutral만 허용하고, verdict에 label과 부동소수점 confidence를 지정한다.
   2. 함수 계약: classify가 텍스트를 입력으로 받아 verdict를 출력하도록 정의하고, TypeScript 코드에서 정해진 응답을 호출한다.
   3. 모델 연결: OpenAI 모델을 클라이언트로 지정해 프롬프트와 특수 포맷을 전달한다.

2. BAML의 실용성

   1. 언어 간 접점: 에이전트가 이해하기 쉬운 문법으로 정의하면서도 다른 프로그래밍 언어와 잘 연결되는 인터페이스를 제공한다.
   2. 런타임 보정: 모델이 잘못 만든 JSON을 런타임에서 고쳐 계약된 형식으로 맞춘다.
   3. 사용 사례: GPT-OSS-120B로 스폰서가 언급된 댓글을 찾을 때는 잘 작동했지만, BAML 없이 같은 모델을 사용하자 JSON 형식이 절반가량 틀리는 경험을 했다.

3.2. Jev의 결정론적 범위

1. 코드와 LLM의 차이

   1. 코드: 이름을 포맷하는 함수나 name: string, age: number인 사용자 객체를 반환하는 함수는 같은 입력에 언제나 같은 형식을 준다.
   2. 일반 LLM: 이름 필드를 망가뜨리거나 정수여야 할 나이에 실수를 넣는 등 내용뿐 아니라 형식도 틀릴 수 있다.
   3. Jev: 코드처럼 빠르게 호출하면서 출력의 모양은 항상 계약대로 지킨다.

2. 결정론의 두 층위

   1. 형식: 완전히 결정론적이다. 정의한 JSON 형태와 필드를 매번 지킨다.
   2. 내용: 결정론적이지 않지만 높은 신뢰도와 함께 결과를 반환한다. 어떤 판단이 불확실한지도 매번 알려주므로, 개발자가 임계값을 정해 사람 검토나 다른 경로로 보낼 수 있다.
   3. 병렬성: 여러 입력을 한 번에 처리할 수 있어 대규모 맵-리듀스 작업에도 적합하다.

4. 비용·속도·정확도

Jev의 경제성은 단순히 벤치마크 점수가 높은 것보다 작은 결정을 대량으로 상시 실행할 수 있게 만든다는 데 있다.

4.1. 수치로 본 차이

1. 비용과 지연 시간

   1. 입력 비용: 약 100만 토큰당 0.04달러로, Fable 같은 모델의 약 10달러와 비교하면 압도적으로 낮다.
   2. 출력 비용: 출력 토큰은 ‘측정할 필요가 없을 만큼(too cheap to meter)’ 저렴해 사실상 무료로 취급된다.
   3. 처리 시간: 전통적인 LLM의 분류가 3초에서 300초 이상 걸릴 때 Jev는 약 70~500밀리초에 처리해 40~200배 빠르다.

2. 실제 비교 사례

   1. 27개 질문: 데이터에 관한 27개 질문에 대해 올바른 형식, 순위, 타입, 신뢰도를 한꺼번에 반환하는 데 0.114초가 걸렸고 비용은 반올림하면 0이었다.
   2. Terra와의 비교: Terra는 완료까지 약 9초, 비용 1.3달러가 들었으므로 약 170배 비싸고 70배 이상 느렸다.
   3. 분류 성능: 공개된 예시 워크플로에서 Jev보다 높은 분류 점수를 낸 모델은 Soul과 Opus 5뿐이었다. Fable과 Astra는 비용이 너무 높아 이 작업의 비교 대상으로 보기 어렵다.
   4. 검색·순위 작업: DSV4 Flash보다 순위 매기기에서 앞서는 사례와 PTO Frontier를 거의 두 자릿수 배 차이로 앞선 사례가 제시됐다.

4.2. 신뢰도와 검증

1. 확률을 말하지 못하는 기존 모델

   1. 일반 모델은 95%의 확률로 잘하는 작업에서도 자신이 나머지 5%에 해당하는지 알려주지 않는 경우가 많다.
   2. 이런 모델로 자동화하면 실패 순간을 감지할 수 없지만, Jev는 모든 출력에 신뢰도와 불확실성을 붙여 보정 가능한 자동화를 만든다.

2. 구조화 출력 오류

   1. Jev: 정의한 JSON을 지키는 구조화 출력 오류율이 0%로 제시됐다.
   2. 기존 모델: Astra는 다른 여러 모델보다 구조화된 도구 출력 오류가 많았고, Haiku는 45.5%의 오류율 사례로 비판받았다.
   3. 도구 호출과의 차이: 도구 호출 오류율로 측정하면 Anthropic 계열이 상대적으로 좋아지고 OpenAI 계열이 더 많은 문제를 보이는 등 순위가 달라지지만, Jev는 여전히 0%를 유지한다.

3. 벤치마크 해석의 주의점

   1. 홈페이지 수치: ‘193.6배 빠르고 444.6배 저렴하다’는 수치가 제시됐지만, Typesafe AI는 이것이 현실에서 기대할 수 있는 높은 쪽의 이득이라고 설명한다.
   2. 참조 정답: GPT 계열 Astra와 Fable 5.1의 평균을 참조 답으로 사용했으므로, 그 모델 자체가 틀렸을 가능성까지 포함한다.
   3. 워크플로 선택: 특정 모델이 잘 보이도록 일부러 만든 문맥이 아니라고 설명했지만, 사용된 벤치마크 전문은 공개되지 않았다.
   4. 비교 래퍼: 다른 LLM에는 System 1 래퍼를 적용해 구조화 결정을 강제했다. 이 방식은 정확하지만 확률 없이 답하게 하는 방식보다 느리고 비싸다.

5. 적합한 사용처: 조건문처럼 작동하는 지능

Jev는 복잡한 계획가가 아니라 상태와 상태 사이에서 다음 경로를 고르는 빠른 분기문이다.

5.1. 분류·정렬·검증

1. 대량 분류

   1. YouTube 데이터: 채널의 동영상을 주제별로 정리한다.
   2. 이메일: 중요도를 판단하고 카테고리로 분류한다.
   3. 안전·모더레이션: 메시지가 안전한지, 위험하다면 무엇 때문에 위험한지 판별한다.
   4. 맵-리듀스: 거대한 데이터 묶음에 결정을 병렬로 적용한 뒤 통계와 인사이트를 모은다.

2. 실시간 애플리케이션

   1. 응답성: 최악의 경우에도 500밀리초 조금 안 되는 응답으로 실시간 UI나 검색에 넣을 수 있다.
   2. 색상 팔레트: 단어를 입력하면 그 개념에 맞는 색상 팔레트를 선택하고 막대 값을 거의 즉시 움직이는 데모가 있었다.
   3. 게임 상태: 체커처럼 보드 상태를 데이터로 전달해 다음 수를 선택하게 할 수 있다.

3. 검증과 방어선

   1. 평가: 점수 매기기, 판정, 검증, 가드레일에 활용할 수 있다.
   2. 공격 탐지: LLM 프롬프트·추론 흔적·출력에서 탈옥(jailbreak) 시도를 탐지할 수 있다.
   3. 단순한 기준: 모든 정보가 들어온 뒤 사람이 10초 안에 답할 수 있는 문제라면 Jev에 잘 맞을 가능성이 높다. 10초 넘게 생각해야 하는 문제라면 부적합할 가능성이 높다.

5.2. 게임과 웹 자동화 데모

1. 체커

   1. 입력 방식: 이미지가 아니라 보드 상태를 데이터 구조로 전달한다. Jev는 현재 비전 기능이 없다.
   2. 동작 방식: 예를 들어 B6에서 C5로 옮기라는 JSON 결정을 반환하고, 프로그램이 그 결정을 실제 수로 실행한다.
   3. 한계: 응답은 매우 빨랐지만 추론하지 않으므로 플레이어가 거의 집중하지 않아도 쉽게 이길 수 있었다.

2. Doom

   1. 비용: 초당 10번 결정을 내려도 시간당 7달러 미만으로 실행할 수 있다.
   2. 비전 부재: 화면을 보는 것이 아니라 게임 애플리케이션 상태와 다음 행동의 JSON 스키마를 받는다.
   3. 프레임 독립성: 매 프레임 새로 판단하며 직전 선택을 기억하지 않으므로, 왼쪽으로 돌았다가 곧바로 오른쪽으로 도는 진동이 발생한다.
   4. 용도: 장시간의 계획을 스스로 유지하는 에이전트가 아니라, 장기 작업 안에서 순간순간의 결정을 담당하는 부품이다.

3. 위키 레이싱과 브라우저

   1. HTML 기반 탐색: 페이지 내용과 링크 위치를 받으면 어느 링크를 누를지 매우 빠르게 고른다.
   2. 속도 비교: Terra가 실행 중 환각을 일으키는 동안 Jev는 훨씬 빠르게 위키 레이싱을 진행했다.
   3. 항공편 예약: HTML을 현재 상태로 읽고 다음 동작을 고르는 방식으로 7.1초 안에 항공편을 예약하는 사례가 제시됐다.

6. ‘생성’처럼 보이는 활용과 실제 한계

구조화된 선택을 조합하면 생성처럼 보이는 UI를 만들 수 있지만, 그것이 자유로운 텍스트 생성이나 추론을 뜻하지는 않는다.

6.1. JSON 렌더링과 이메일 처리

1. JSON Render

   1. 임의의 JSON을 화면 컴포넌트로 렌더링하면 LLM 출력을 더 눈에 보이고 유용한 UI로 연결할 수 있다.
   2. 일반 모델은 JSON을 생성하는 동안 UI 갱신을 기다려야 하지만, Jev는 텍스트를 스트리밍하지 않고 전체 구조를 한 번에 매우 빠르게 반환한다.
   3. 문자를 생성하는 모델처럼 보이더라도 실제로는 가능한 컴포넌트나 문자를 선택한 결과를 반환하는 방식이다.

2. Ryan의 이메일 배치

   1. 내보낸 이메일 1,500개 중 처음 100개를 워커 8개로 분류했다.
   2. 이메일당 평균 200밀리초, P95 240밀리초, 초당 38개 처리량을 기록했다.
   3. 이미 LLM으로 이메일을 처리할 수는 있지만 비용이 큰 반면, Jev는 먼저 저비용 스팸과 단순한 항목을 제거하는 1차 필터에 적합하다.
   4. 너무 싸서 기존 LLM을 정당화하기 어려운 작업, 너무 자주 실행돼 수초를 기다릴 수 없는 작업이 핵심 대상이다.

6.2. 이미지 기능이 추가되면 가능한 일

1. PII 탐지

   1. 영상의 여러 프레임을 넣어 이메일 주소 같은 민감정보나 개인정보가 있는지 확인한다.
   2. 위치까지 반환하게 하면 공개 전에 해당 프레임을 찾아 데이터를 지울 수 있다.

2. 컴퓨터 사용

   1. 화면을 직접 볼 수 있게 되면 컴퓨터 사용의 즉각적인 판단이 더 매력적일 수 있다.
   2. 현재도 HTML을 읽는 브라우저 자동화는 잘하지만, 이미지 기반 상황 인식은 아직 제공하지 않는다.

7. 잘못된 사용: LLM 심사와 컨텍스트 압축

Jev의 속도와 가격이 너무 인상적이어서, 추론이 필요한 문제까지 맡기려는 오해가 빠르게 생긴다.

7.1. 다른 LLM의 결과를 심사하는 용도

1. 잘못된 질문

   1. 여러 LLM에 같은 답을 만들게 한 뒤 Jev에게 최선의 출력을 고르게 하는 발상은 겉으로는 경제적으로 보인다.
   2. 하지만 네 개의 답을 생성하는 비용부터 크고, 사고하지 않는 분류 모델에 사고한 결과의 우열을 판정하게 하는 구조 자체가 맞지 않는다.

2. 범용 LLM이 필요한 이유

   1. 범용 모델은 코드베이스를 도구로 탐색하고, 필요한 맥락을 스스로 늘리며, 서브에이전트로 자신을 재프롬프트할 수 있다.
   2. Jev는 짧은 텍스트에서 즉시 JSON을 고르는 모델이므로, 서로 다른 모델의 복잡한 산출물을 이해하고 비교할 문맥과 추론 능력이 없다.
   3. Braintrust가 에이전트 출력 평가용 LLM 심사기를 Jev로 바꾸라고 권한 사례는 이런 차이를 무시한 나쁜 메시지로 평가된다. 심사 프롬프트를 작성하는 데는 30초도 걸리지 않으며, 그 비용을 아끼려다 잘못된 판단을 얻을 수 있다.

7.2. 컨텍스트 압축이 맞지 않는 이유

1. 압축은 삭제 필터가 아님

   1. 대화 기록에서 중요하지 않은 줄만 골라 지우는 일이 아니다.
   2. 지금까지 일어난 모든 일을 종합해 새로운 요약을 만드는 작업이다.
   3. Jev는 무엇을 판단해야 하는지 알 수 있을 만큼의 문맥, 도구 호출 결과, 전체 상태를 갖고 있지 않다.

2. 추론 흔적이 보이지 않음

   1. Claude나 Codex API에서 모델의 내부 추론을 그대로 받지 못하고, 암호화된 연결 정보나 운이 좋을 때만 요약을 받는다.
   2. 따라서 Jev가 압축할 때 원래 모델이 결정을 내린 이유와 추론 데이터가 포함되지 않는다.
   3. Anthropic이 기록 보존 방식을 바꾸면서 history를 편집하면 해당 문맥의 추론 흔적을 잃게 되는 문제도 있다.

3. 모델 자체가 압축을 학습함

   1. 범용 모델은 학습과 강화학습 과정에서 자신의 컨텍스트를 어떻게 압축해야 하는지 조정된다.
   2. 이미 그 방식에 맞춰 튜닝된 모델의 앞부분을 임의로 잘라내고 Jev에게 요약시키는 것은 모델이 학습한 입력 조건을 망가뜨린다.

4. 캐시와 기록 일관성

   1. 에이전트 작업에서는 캐시 읽기보다 캐시 쓰기가 더 비싼 경우가 많다.
   2. 기록이 1 2 3 4 5 6으로 쌓였을 때 2번을 삭제하면 3번 이후의 접두사가 바뀌어 나머지 전부를 다시 써야 한다.
   3. 앞쪽의 작은 변경도 이후 캐시를 무효화하므로, 적극적인 압축은 캐시 효율을 크게 떨어뜨린다.

5. 도구와 삭제의 위험

   1. “보존하지 않은 것은 영구 삭제하지만 필요하면 도구를 다시 실행할 수 있다”는 식의 지침은 파괴적인 도구가 있는 에이전트 환경에서 안전하지 않다.
   2. 얕은 분류를 반복하면 중요하지 않다고 판단한 것을 이미 다 제거한 뒤 남은 중요한 기록만 계속 처리하는 루프에 갇힐 수 있다.
   3. 실제 시도와 벤치마크에서도 이런 방식의 성능은 좋지 않았다.

7.3. 에이전트 개발에서의 올바른 자리

1. 하네스를 대체하지 않기

   1. 코드를 작성하거나 컨텍스트를 압축하거나 에이전트 하네스의 동작을 바꾸는 데 Jev를 쓰지 않는다.
   2. 이미 수십억 달러가 투입돼 개선된 하네스를 그대로 활용하고, 매번 자체 구현으로 바퀴를 다시 만들지 않는다.
   3. 전체 컨텍스트를 작은 이미지 하나에 욱여넣어 압축하겠다는 발상도 문제를 해결하지 못한다.

2. 대규모 개인 데이터 분석

   1. 한 컴퓨터에서 발생한 T3 코드 채팅 1,118개 스레드와 32,311개 메시지를 Jev로 분류했다.
   2. 작업 비용은 약 0.37달러였고, 버그 수정이 전체 작업의 거의 절반을 차지했다.
   3. PR 검토와 PR 관리도 약 20%의 스레드를 차지했다.

3. 임계값 기반 분석

   1. Jev는 태그 문자열 목록 대신 각 분류값에 대해 0에서 1 사이의 점수를 반환한다.
   2. 각 분류에 적용할 신뢰도 기준을 바꿀 수 있다.
   3. ‘범위 확장’ 분류는 80% 기준에서 스레드의 22%였지만, 90%로 올리자 확실하지 않은 항목이 빠져 6.8%로 줄었다.
   4. 이처럼 분류 결과 자체보다 임계값을 조정해 어떤 데이터를 포함하고 제외할지 결정하는 방식이 강점이다.

4. 복잡한 콘텐츠 선별의 한계

   1. Astra가 만든 간단한 웹 앱은 어떤 대화 스레드를 콘텐츠로 저장할지 찾으려 했다.
   2. Astra는 프롬프트를 여러 번 고쳤지만 여전히 절반가량의 스레드가 콘텐츠로 쓸 만하다고 판정했다.
   3. 어떤 대화가 실제로 좋은 콘텐츠가 될지 판단하는 일은 맥락과 숙고가 필요하므로 Jev의 지능 범위를 넘는다.

8. 체커블한 결론: 사고가 아니라 반사

Jev를 이해하는 가장 간단한 기준은 정보가 들어온 뒤 답을 내는 데 사람에게 몇 초가 필요한지 묻는 것이다.

8.1. 적합성 판단 기준

1. 잘 맞는 작업

   1. 파란 셔츠의 색을 말하거나, 안전/위험 라벨을 붙이거나, 정해진 카테고리 중 하나를 고르는 일처럼 지각 후 10초 안에 끝나는 문제다.
   2. 정렬, 랭킹, 짧은 결정, 검증, 구조화된 JSON 반환, 대량 데이터 분류처럼 조건문 사이에 삽입할 수 있는 작업이다.

2. 맞지 않는 작업

   1. 코드를 읽고 변경 계획을 세우거나, 여러 모델의 답을 비교하거나, 장기 목표를 유지하거나, 대화 전체의 의미를 재구성하는 일처럼 생각이 필요한 문제다.
   2. 긴 문맥, 도구 결과, 숨겨진 추론 과정, 과거 결정의 인과관계를 모두 알아야 하는 컨텍스트 압축도 여기에 해당한다.

8.2. 최종 사용 원칙

1. 제품 안에 설치하는 라이브러리

   1. Jev를 Codex나 Claude, 터미널에서 대화하는 또 하나의 모델로 보지 않는다.
   2. 애플리케이션에 설치해 함수처럼 호출하고, 입력 상태에 따라 다음 동작을 결정하는 부품으로 본다.

2. 범용 모델 대체가 아닌 경제성 혁신

   1. Jev는 이전에 비현실적이었던 구조화 출력 작업을 훨씬 싸고 빠르게 만든다.
   2. 다른 LLM을 잘못 쓰고 있을 때만 대체가 가능하다는 의견에는 대체로 동의할 수 있지만, 구조화 출력이 많은 시스템에서는 독자적인 강점이 있다.
   3. 올바른 기대치를 갖고 if 문처럼 사용하면 엄청난 양의 작은 판단을 자동화할 수 있다.

주요 발언 모음

“이 모델은 생각해야 하는 작업이 아니라 분류해야 하는 작업을 위해 만들어졌다.”

“Jev는 대략 switch 문만큼 똑똑하다. 그것이 멋지지 않다는 뜻이 아니라, 무엇에 써야 하는지를 정확히 이해해야 한다는 뜻이다.”

“형식은 결정론적이지만 내용은 결정론적이지 않다. 정의한 형식은 언제나 지키고, 내용은 신뢰도와 함께 반환한다.”

“Jev를 다른 모델의 복잡한 결과를 심사하는 데 쓰지 말고, 조건문처럼 사용하라.”

“System 2가 어떤 일을 생각하는 것이라면 System 1은 뇌가 먼저 처리한 뒤 반사적으로 반응하는 것이다.”

핵심 데이터 & 수치

• 문맥 길이: 32k 토큰으로, 긴 에이전트 기록과 도구 결과를 모두 이해하기에는 작다.
• 입력 비용: 약 100만 토큰당 0.04달러다.
• 출력 비용: 너무 저렴해 측정하지 않는 수준으로 제시됐다.
• 처리 속도: 기존 분류 작업의 3~300초 이상에 비해 70~500밀리초이며 40~200배 빠르다.
• 실시간 응답: 최악의 경우도 500밀리초 이내에 가깝다.
• 벤치마크 예시: 27개 질문을 0.114초에 처리했고, 비교 모델 Terra는 약 9초와 1.3달러가 필요했다.
• 홈페이지 비교: 193.6배 빠르고 444.6배 저렴하다고 표시됐다.
• 구조화 출력 오류: Jev 0%, Haiku 45.5% 사례가 제시됐다.
• Doom 실행: 초당 10회 판단을 해도 시간당 7달러 미만이다.
• 이메일 배치: 100개를 워커 8개로 처리해 평균 200ms, P95 240ms, 초당 38개였다.
• 개인 채팅 분석: 1,118개 스레드의 32,311개 메시지를 약 0.37달러에 분류했다.
• 범위 확장 분류: 신뢰도 80% 기준에서 22%, 90% 기준에서 6.8%였다.
• 체커블한 기준: 정보를 모두 본 뒤 10초 안에 답할 문제면 적합할 가능성이 크고, 그 이상 생각해야 하면 부적합할 가능성이 크다.

결론 및 시사점

1. Jev의 본질은 텍스트 생성기가 아니라 타입 안전한 구조화 의사결정 함수다.
2. ‘빠른 반사’가 필요한 분류·정렬·검증을 범용 LLM에서 분리하면 지연 시간과 비용을 크게 낮출 수 있다.
3. 출력 형식은 결정론적이지만 내용은 확률적이므로, 신뢰도 임계값과 사람 검토 경로를 함께 설계해야 한다.
4. 이미지 입력이 추가되면 PII 탐지, 프레임 검사, 시각적 컴퓨터 사용 같은 고빈도 작업이 특히 유망하다.
5. 체커와 Doom처럼 매 프레임 상태를 넘기는 게임에서는 이전 결정을 기억하지 못해 진동하거나 계획을 세우지 못한다.
6. 다른 LLM의 결과를 심사하거나 컨텍스트를 압축하는 작업은 긴 문맥과 추론이 필요하므로 Jev에 맡기면 안 된다.
7. Jev는 Codex·Claude·터미널에서 대화하는 모델이 아니라 제품 코드에 설치하는 라이브러리로 다뤄야 한다.
8. 판단에 10초 이상 걸리는 문제는 System 2 모델에 맡기고, 즉시 분류할 수 있는 문제만 Jev로 보내는 경계가 핵심이다.
9. 올바른 사용법은 Jev를 범용 모델의 대체품이 아니라 소프트웨어 내부의 초고속 if 문으로 배치하는 것이다.

핵심 요약 (20줄)

1. Jev는 텍스트와 코드를 생성하는 범용 LLM이 아니라 구조화된 결정을 반환하는 System 1 모델이다.
2. Jev는 입력 상태를 받아 약속된 JSON 스키마와 신뢰도를 갖춘 타입 안전한 결과를 반환한다.
3. Jev의 형식은 결정론적이지만 분류 내용 자체는 확률적이므로 임계값과 검토 경로가 필요하다.
4. Jevons의 역설처럼 효율성이 높아지면 기존에 비싸서 못 하던 자동화를 더 많이 실행할 수 있다.
5. Typesafe AI는 대화형 모델이 아니라 애플리케이션 함수로 호출되는 자동화 전용 스택을 만들었다.
6. 병렬 샘플러와 보정된 결정을 위한 강화학습이 Jev의 처리량과 불확실성 표현을 뒷받침한다.
7. BAML은 잘못된 JSON을 런타임에서 고치지만 Jev는 처음부터 정의한 구조를 지키도록 설계됐다.
8. Jev의 입력 비용은 약 100만 토큰당 0.04달러이고 출력 토큰은 사실상 무료다.
9. Jev는 전통적인 분류 모델보다 40~200배 빠른 70~500밀리초 수준의 응답을 제공한다.
10. 27개 질문을 0.114초에 처리한 반면 Terra는 약 9초와 1.3달러가 필요했다.
11. YouTube 주제 분류, 이메일 중요도 판정, 모더레이션과 탈옥 탐지가 주요 활용처다.
12. 체커와 Doom 데모는 빠른 반응을 보여주지만 이전 결정을 기억하거나 장기 계획을 세우지는 못한다.
13. 현재 Jev는 비전을 지원하지 않아 게임 화면이 아니라 구조화된 게임 상태를 입력으로 사용한다.
14. JSON Render와 웹 탐색은 즉시 구조를 선택하는 능력이 UI와 브라우저 자동화에 유용함을 보여준다.
15. 이메일 100개를 평균 200밀리초, P95 240밀리초, 초당 38개로 처리한 사례가 있다.
16. Jev를 여러 LLM의 결과 심사기로 쓰면 필요한 추론과 문맥을 갖지 못해 잘못된 평가를 내릴 수 있다.
17. 컨텍스트 압축은 삭제가 아니라 전체 기록의 의미를 합성하는 작업이므로 32k 문맥의 Jev에 부적합하다.
18. 추론 흔적과 도구 결과가 API에 완전히 노출되지 않는 점도 외부 압축기의 치명적인 한계다.
19. 1,118개 코드 채팅 스레드와 32,311개 메시지를 약 0.37달러에 분류한 사례는 대규모 데이터 분석의 경제성을 보여준다.
20. 생각이 필요한 문제는 System 2 모델에 맡기고 즉시 분류할 수 있는 문제에 Jev를 소프트웨어의 if 문처럼 사용해야 한다.