> ## Content Index
> Fetch the complete content index at: https://blog.jikji.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# Jev 분석: Token Generation이라는 비싼 우회를 끝내는 법
- URL: https://blog.jikji.ai/posts/jev-bunseog-token-generationiraneun-bissan-uhoereul-ggeutnaeneun-beob/
- Published: 2026-09-22T08:20:53.000Z
- Updated: 2026-10-01T23:07:14.000Z
- Author: juyoung
- Tags: Blog

최근 TypeSafe AI가 공개한 Jev의 핵심 질문은 아래와 같습니다.  

> *"LLM 기반 시스템의 절대 다수는 Text Generation이 아니라 Classification/Decision 문제인데, 왜 여전히 Autoregressive Token Sampling이라는 비싼 우회를 택하고 있는가?"*  

현업 아키텍처 관점에서 Jev가 제시하는 **System One Model**의 핵심 아이디어와, 이를 실제 Agent System에 적용할 때 부딪히는 3가지 기술적 한계를 분석합니다.  

## 1\. Paradigm Shift: Autoregressive에서 Parallel Single-Pass로

기존 Router / Guardrail / Tool Picker 방식의 가장 큰 낭비는 Output Space의 엔트로피 차이와 인퍼런스 샘플링 방식에서 옵니다.  

Standard LLM Pipeline (System 2): 

(쿼리) → Transformer Encoder/Decoder → 전체 어휘 집합(Vocabulary Space) 대상 순차 토큰 생성 (Sequential Autoregressive Sampling) → 텍스트 파싱

Jev-style Direct Decision (System 1): 

(쿼리) → Encoder → K차원 서브스페이스 투영 → Parallel Single Forward Pass → Calibrated Logits 직접 출력  

자유 자연어 생성 환경의 답안 공간이 전체 어휘의 조합으로 이뤄진 무한에 가까운 공간인 반면, Guardrail이나 Intent Routing은 보통 20개 미만의 아주 작은 선택지 공간입니다.  
기존 LLM은 이 소수의 선택지를 표현하기 위해 JSON 키값, 괄호, 들여쓰기 토큰을 순차 생성해야 했고, 이는 곧 KV Cache 메모리 점유와 Prefill-to-Decode Latency 비효율로 직결되었습니다.  
Jev는 Output Manifold를 정해진 선택지 차원으로 고정하고 **Parallel Sampling**을 수행함으로써 Autoregressive Loop 자체를 제거합니다. 즉, 단 한 번의 포워드 패스만으로 구조화된 결과와 확률을 동시 계산하여 Latency를 50ms 미만으로 낮추고 Output Token 비용을 사실상 0에 가깝게 만드는("Too cheap to meter") 아키텍처적 이점을 제공합니다.  

## 2\. RLCD의 본질: Preference Optimization vs. Calibration Density

많은 이들이 Jev의 RLCD(Reinforcement Learning for Calibrated Decisions)를 단순한 classification SFT나 RLHF의 변형으로 오해합니다. 하지만 두 접근법은 Optimization Objective부터 다릅니다.  

- **RLHF / RLVR :** 모델 출력이 인간의 선호나 정답 검증 조건에 맞추어 확률을 한곳으로 몰아주는 Mode-seeking 동작을 유도합니다. 이 과정에서 Overconfidence 현상이 극심해집니다.
- **RLCD:** 모델의 Softmax 값이 실제 데이터셋의 정답률과 정확히 일치하도록 확률 분포를 정렬합니다.

Agent System에서 확률값이 보정되지 않은 모델은 치명적입니다. 특정 동작의 확률이 0.89로 나왔을 때, RLHF 모델의 0.89는 "그냥 할 말이 그것뿐이다"라는 뜻일 수 있지만, RLCD 모델의 0.89는 "유사 조건 100번 중 89번은 해당 조치가 옳았다"는 Cost-Benefit 계산의 신뢰할 수 있는 근거가 됩니다.  
결국 RLCD의 핵심 가치는 Decision Entropy를 보정하여 에이전트의 동적 임계값(Dynamic Thresholding $\\tau$) 제어를 가능하게 만든다는 점에 있습니다.  

## 3\. Engineering Reality Check: Jev가 말하지 않는 3가지 한계

기술적 실용성을 극대화하려면 Jev와 같은 Closed Decision Model의 아키텍처적 한계도 명확히 인지해야 합니다.  

### ① Schema Hallucination은 잡지만, Latent Space Shift는 잡지 못한다

Jev는 정해진 타입 범위 내에서의 출력을 100% 보장합니다. 허용되지 않은 문자열이나 포맷을 뱉는 Schema Hallucination은 구조적으로 0%입니다.  
그러나 잘못된 분류와 Distribution Shift에 의한 Calibration Drift는 여전히 남습니다. 학습 트래픽과 다른 Edge Case가 인입될 때 Softmax Score가 치솟는 Overconfidence 현상을 RLCD만으로 완전히 방지할 수 있는지는 독립적인 검증이 필요합니다.  

### ② Local Decision $\\neq$ Long-horizon Policy Optimization

Jev의 Decision 확률은 현재 상태에서의 단기 최적화에 가깝습니다.  
Multi-turn Agent 환경을 예로 들면:  

- **Current Turn Local Score:** 현재 문맥만 보면 즉시 실행을 선택하는 점수가 가장 높을 수 있습니다.
- **Long-term Value:** 하지만 추가 질문을 던져 모호성을 해소하는 것이 전체 미션의 최종 성공률과 가치를 훨씬 더 높일 수 있습니다.

Jev-style Model은 훌륭한 System Guardrail / Router가 될 수 있지만, 그 자체로 Multi-step Sequential Decision Making을 대체하는 Agent Policy를 통째로 대신할 수는 없습니다.  

### ③ Action Space Scalability & Cardinality Limit (Max 255)

Jev는 현재 단일 쿼리당 선택지 상한이 **255개**로 제한되어 있습니다.  
Action Space가 유동적으로 변하거나 수천 개 이상으로 늘어나는 RAG Entity Selection이나 Dynamic Tool Retrieval 문제 환경에서는 단일 Pass 처리가 불가능합니다. 이 경우 "1차 독립 Scoring $\\rightarrow$ 2차 Explicit Selection"과 같은 2단계 파이프라인을 별도로 구축해야 하므로 Jev 고유의 단일 지연 시간 이점이 일부 희석됩니다.  

## 4\. Production Architecture: The Cascade Routing Pattern

실무에서 Jev류 모델을 도입할 때 가장 현실적이고 파급력이 큰 형태는 **3-Tier Cascade Architecture**입니다.  

```
                    [ Incoming User Request ]
                               │
                               ▼
    ┌─────────────────────────────────────────────────────┐
    │ Tier 1: Jev Calibrated Router / Guardrail           │
    │  - Latency: < 20ms ~ 50ms                           │
    │  - Compute: Parallel Single Forward Pass            │
    └──────────────────────────┬──────────────────────────┘
                               │
                 ┌─────────────┴─────────────┐
                 │                           │
     [ High Confidence (p > τ) ]     [ Low Confidence (p ≤ τ) ]
                 │                           │
                 ▼                           ▼
    ┌──────────────────────────┐  ┌──────────────────────────┐
    │ Tier 2: Deterministic    │  │ Tier 3: Frontier LLM     │
    │ Execution / Fast Path    │  │ (Reasoning / Generation) │
    └──────────────────────────┘  └──────────────────────────┘

```

생산성 및 비용 방정식 관점에서 전체 시스템의 기대 비용은 아래와 같이 정의됩니다.  
$$\\text{Cost}\_{\\text{total}} = \\text{Cost}\_{\\text{Jev}} + (1 - r) \\cdot \\text{Cost}\_{\\text{Frontier}}$$여기서 $r$은 자동화 처리율(Automation Coverage, $P(p > \\tau)$)입니다.

  
Jev의 RLCD가 Calibration을 정교하게 잡아줄수록, 우리는 리스크 임계값을 어기지 않으면서 자동화 처리율 $r$을 극대화할 수 있게 됩니다. Enterprise LLM System의 ROI는 바로 이 지점에서 결정됩니다.  

## Conclusion: Decoupling Decision from Generation

Jev가 우리에게 주는 가장 중요한 메시지는 "작은 SFT 모델도 잘 터진다"가 아닙니다.  
우리는 지난 수년간 Perception, Reasoning, Decision, Generation이라는 서로 다른 특성의 계산 과정을 모두 `LLM.generate()`라는 단일 추상화 레이어 안에 강제로 쑤셔 넣어왔습니다.  
Jev는 대니얼 카너먼의 System 1(직관적·초고속 판단)과 **System 2(숙고적·연쇄 추론)** 개념을 AI 인프라 레이어로 분리해낸 시도입니다.  
자연어 생성이 정말로 필요한 순간(Generation)과 깊은 연쇄 추론이 필요한 순간(Reasoning)에만 Frontier Model(System 2)을 호출하고, 그 외의 모든 System Control / Routing / Guardrail은 Fast Calibrated Decision Model(System 1)에 맡기는 것—이것이 Next-Gen AI Infrastructure의 가장 확실한 수순입니다.