Jev는 LLM이 아니다: 생성형 AI를 ‘결정 엔진’으로 바꾸는 새로운 구조

이 글의 핵심은 Jev를 “JSON 잘 뽑는 빠른 LLM”으로 보면 완전히 잘못 본 것이라는 주장입니다.

저자가 1만 회가 넘는 API 호출과 여러 블랙박스 실험을 바탕으로 추정한 Jev의 구조는 대략 이렇습니다.

LLM처럼 문장을 생성하는 모델이 아니라, LLM의 내부 표현을 이용해 “결정 확률”을 바로 읽어내는 모델

일반 LLM과 비교하면 차이가 선명합니다.

일반 LLMJev로 추정되는 방식

프롬프트 입력	state + 여러 questions 입력
토큰을 하나씩 생성	질문별 확률을 직접 계산
"payments": "91%"라는 문자열 생성	payments = 0.91이라는 분포를 readout
여러 질문을 차례로 처리하기 쉬움	여러 질문을 병렬 처리
같은 긴 context를 반복 처리	state를 한 번 계산하고 공유
confidence를 말로 생성	결과 분포 자체를 학습
decode 비용이 큼	거의 prefill + classifier/readout

가장 중요한 구조를 단순화하면 이런 형태입니다.

                     Shared State
                         │
                  Transformer
                         │
              Shared representations
             ┌──────────┼───────────┐
             │          │           │
          Question A Question B Question C
             │          │           │
          options     options     options
             │          │           │
        probability probability probability
         readout      readout      readout

         0.91/0.06/0.03
         0.42/0.58
         0.08/0.20/0.72

즉,

Input
"결제가 세 번 실패했습니다.
은행에서는 문제가 없다고 합니다."

Questions
1. 어느 부서로 보내야 하나?
2. 긴급 escalation이 필요한가?
3. 긴급도는 어느 정도인가?

일반 LLM이라면 대략

{
  "team": "payments",
  "confidence": 0.91,
  "escalate": false,
  ...
}

를 토큰 단위로 써내려갑니다.

반면 Jev는 저자의 추정대로라면 애초에 문장을 쓰지 않습니다.

team
payments  0.91
account   0.06
other     0.03

escalate
yes       0.42
no        0.58

urgency
low       0.08
medium    0.20
high      0.72

그리고 JSON 만드는 일은 그냥 애플리케이션 코드가 합니다.

---

특히 이 글에서 재미있는 부분은 Shared State입니다.

예를 들어 5만 자짜리 고객 기록을 가지고 50개의 판단을 해야 한다면 일반적인 LLM 호출 구조에서는 사실상 같은 내용을 여러 번 처리하게 되기 쉽습니다.

Jev가 저자의 추정처럼 동작한다면,

긴 고객 기록
   ↓
한 번 encode
   ↓
────────────────────
 ↓    ↓    ↓    ↓
Q1   Q2   Q3 ... Q50

가 됩니다.

더 중요한 것은 질문끼리는 서로 보지 못하게 할 수 있다는 겁니다.

                  STATE
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
   Fraud?       Urgent?       Category?
       ↓            ↓            ↓
    0.78          0.31         Payments

그래서 Fraud?라는 질문을 추가했다고 해서 Category? 판단 자체가 영향을 받아서는 안 됩니다.

저자가 실제로 secret code를 한 질문에 넣고 다른 질문이 그것을 볼 수 있는지 실험했는데,

• sibling question에 넣음 → 거의 못 봄
• shared state에 넣음 → 읽음

이라는 결과를 얻었습니다.

이게 question isolation을 뒷받침하는 중요한 블랙박스 증거입니다.

---

또 하나 중요한 부분은 KV cache 공유 추정입니다.

저자가 생각하는 구현은 대략 이런 겁니다.

STATE
 ↓
Transformer
 ↓
KV Cache
 ├── Question 1 suffix
 ├── Question 2 suffix
 ├── Question 3 suffix
 ├── ...
 └── Question N suffix

LLM serving 쪽에서 이미 Hydragen이나 DeFT 같은 연구가 다루는 shared prefix / tree attention과 상당히 비슷합니다.

그래서 질문이 수십~수백 개라 해도 긴 state를 계속 다시 계산할 필요가 없습니다.

이게 Jev가 단순 classifier보다 흥미로운 이유입니다.

---

그런데 Jev는 그냥 classifier 아닌가?

반은 맞고 반은 아닙니다.

마지막 부분만 보면 확실히 classifier처럼 보입니다.

수학적으로는 매우 단순합니다.

hidden representation h

z = Wh + b

softmax(z)

→ [0.91, 0.06, 0.03]

그런데 앞부분이 중요한 겁니다.

전통 classifier

input
 ↓
encoder
 ↓
고정 label classifier

가 아니라 Jev는

자연어 state
+
자연어 question
+
자연어 options
 ↓
대규모 pretrained transformer
 ↓
decision representation
 ↓
probability

로 보입니다.

그래서 새로운 label에 대해서도 사용할 수 있습니다.

A = 좋은 고객
B = 보통 고객
C = 위험 고객

같은 클래스가 학습 시점에 존재하지 않았더라도 자연어 설명으로 의사결정을 정의할 수 있습니다.

이게 LLM의 범용성 + classifier의 output 구조를 합친 부분입니다.

---

그리고 이 글에서 상당히 중요한 발견이 하나 더 있습니다.

Jev는 옵션을 각각 독립적으로 점수 매기는 것 같지 않습니다.

예를 들어

bank
provider
customer
unknown

이라는 네 옵션에

weather

라는 관련 없는 다섯 번째 옵션을 넣었더니 기존 옵션 사이의 상대 확률까지 변했습니다.

독립적인 logits라면

P(customer) / P(unknown)

의 비율은 그대로 있어야 합니다.

그런데 실제로 변했습니다.

저자는 이것을 근거로 Jev가 옵션을

option A
option B
option C
option D
      ↓
전체 option list를 함께 이해
      ↓
decision

하는 listwise decision 구조라고 추정합니다.

그래서 Jev는 단순히

score(option1)
score(option2)
score(option3)

하는 모델보다 더 복잡할 가능성이 있습니다.

---

그리고 Jev에서 정말 중요한 부분이 Calibration입니다.

LLM에게

이게 사기일 가능성이 얼마나 돼?

라고 물으면

90%입니다.

라고 대답할 수 있습니다.

그러나 이 90이라는 문자열을 생성할 확률과
실제로 **사기일 확률 90%**는 전혀 다른 개념입니다.

Jev가 해결하려는 게 정확히 이 문제입니다.

예를 들어 Jev가

fraud = 0.8

인 사례 1,000개를 만들었다면 실제로 약 800개가 fraud여야 합니다.

이를 calibration이라고 합니다.

예측 확률    실제 발생률

0.1    →     약 10%
0.3    →     약 30%
0.5    →     약 50%
0.8    →     약 80%
0.95   →     약 95%

Jev의 RLCD:

Reinforcement Learning for Calibrated Decisions

가 바로 이것을 학습시키는 접근이라고 TypeSafe는 설명합니다.

다만 정확한 학습 알고리즘은 공개하지 않았습니다.

이 글에서 저자가 계속 강조하는 것도 이 부분입니다.

---

그래서 confidence도 조금 주의해야 합니다.

Jev가 주는 confidence는 또 다른 AI 판단값이 아닙니다.

공식 Python adapter를 보면 Choice의 경우 사실상 수식으로 계산합니다.

예를 들어 3개 선택지가 있고

0.80
0.15
0.05

라면 단순히 가장 높은 확률이 uniform baseline보다 얼마나 떨어져 있는지를 계산합니다.

따라서

probability distribution

과

confidence

를 같은 개념으로 보면 안 됩니다.

이건 Jev를 실제 시스템에 넣을 때 꽤 중요합니다.

---

MoE 부분은 이 글에서 가장 조심해서 봐야 합니다.

저자가 추정하는 전체 구조는

Sparse MoE Transformer
        ↓
Shared state
        ↓
isolated question branches
        ↓
listwise option representation
        ↓
direct probability readout

입니다.

하지만 증거 수준이 다릅니다.

상대적으로 증거가 강한 것

★★★★★ 직접 probability output
★★★★★ autoregressive text generation을 하지 않음
★★★★☆ question isolation
★★★★☆ state 공유
★★★★☆ option들이 서로 영향을 미침

추정이 많이 들어가는 것

★★★☆☆ causal decoder
★★★☆☆ KV cache 구현 방식
★★☆☆☆ pointer head vs fixed slot head
★★☆☆☆ sparse MoE

특히 MoE라는 주장은 상당히 speculative합니다.

속도와 현재 대형 모델 추세를 근거로 추정한 것이지 API 실험으로 증명한 것이 아닙니다.

저자도 이 점은 명확하게 구분합니다.

---

이 구조가 왜 중요한가

제가 보기에 Jev의 의미는 새로운 Transformer 발명보다는 LLM을 사용하는 계산 그래프 자체를 바꿨다는 점에 있습니다.

기존 AI 앱은 대부분:

DATA
 ↓
LLM
 ↓
TEXT / JSON
 ↓
JSON parse
 ↓
if confidence > 0.8
 ↓
ACTION

입니다.

Jev 스타일은:

DATA
 ↓
Decision Transformer
 ↓
Probability Distribution
 ↓
Policy
 ↓
ACTION

입니다.

그래서 AI가 글을 써야 하는 작업과 결정을 내려야 하는 작업을 분리합니다.

예를 들어 고객센터라면 LLM은 여전히 답변 작성에 좋습니다.

고객 메시지
        │
 ┌──────┴──────┐
 ↓             ↓
Jev            LLM
 │              │
분류           답변 생성
fraud          설명
priority       이메일
routing        요약
 │
Policy Engine
 │
자동 처리 / 사람 검토

이런 구조가 됩니다.

---

이게 게임 쪽에서도 상당히 재미있습니다. 예를 들어 NPC AI를 전부 LLM 생성으로 만들지 않고,

STATE
- HP 32%
- 적 3명
- healer 15m
- ammo low
- objective 위험
- squad morale 낮음

QUESTIONS

action?
→ attack 0.17
→ retreat 0.52
→ defend 0.21
→ heal 0.10

target?
→ enemy A 0.12
→ enemy B 0.63
→ enemy C 0.25

use_skill?
→ yes 0.71
→ no 0.29

처럼 게임 AI의 의사결정 엔진으로 활용할 수 있습니다.

그리고 실제 애니메이션이나 행동은 deterministic game logic이 실행합니다.

이 구조라면 수백 NPC가 있는 게임에서도 매 NPC가 매번 몇십 토큰의 행동 문장을 생성하는 방식보다 훨씬 자연스러운 아키텍처가 됩니다.

결국 이 글을 한 문장으로 줄이면:

Jev는 “말 잘하는 LLM을 더 빠르게 만든 것”이라기보다, pretrained LLM의 지식을 유지하면서 생성기를 확률 기반 decision engine으로 바꾸려는 시도에 가깝다.

그래서 Jev가 성공한다면 가장 큰 시장은 챗봇보다는 fraud detection, moderation, routing, risk, recommendation, workflow automation, 게임 AI, agent policy처럼 ‘결정을 계속 내려야 하는 시스템’ 쪽일 가능성이 더 흥미롭습니다.