선택지만 고르는 AI 모델 Jev, 구조화 출력의 재발견

출처: Sean Goedecke 블로그 (seangoedecke.com)
원문: https://www.seangoedecke.com/jev-means-structured-output-is-interesting-again/
작성자: 팔복소프트-김팔복

한눈에 보기

• typesafe.ai가 공개한 Jev는 자연어로 답하지 않고, 주어진 선택지 중 하나를 고르는 구조화 출력만 내놓는 'System One' 모델입니다.
• 토큰을 하나씩 생성하지 않고 한 번의 forward pass로 답하므로 응답 시간이 가장 빠를 때 약 70ms, 가장 느릴 때도 약 500ms 수준으로 일정합니다.
• 실시간으로 Doom을 플레이하는 데모가 나왔고, 게임 전용이 아닌 범용 모델이라는 점을 내세웁니다.
• 원문 필자는 기존 오픈 LLM에 prefill과 단일 토큰 제약 생성을 적용해도 비슷한 효과를 낼 수 있다며, 기술적 해자는 크지 않다고 봅니다.
• 추론(test-time compute)을 쓸 수 없는 구조라 지능 자체는 non-reasoning LLM 수준에 머물 가능성이 큽니다.
• 한국 팀이라면 Jev 도입보다 "LLM을 빠른 분류기로 쓰는 패턴"을 기존 스택에서 먼저 시험해 보는 편이 현실적입니다.

배경

LLM은 토큰 하나를 만들 때마다 모델 전체를 한 번씩 돌리는 autoregressive 방식으로 동작합니다. 그래서 {"answer": "blue"} 같은 짧은 JSON도 중괄호, 따옴표, 키 이름을 차례로 만들어야 합니다. OpenAI의 Structured Outputs나 vLLM·SGLang의 guided decoding은 스키마에 맞지 않는 토큰을 샘플링 단계에서 걸러내는 방식(grammar-constrained decoding)이라, 형식은 보장해도 속도는 일반 생성과 크게 다르지 않습니다.

주요 내용

Jev는 "고르기만" 한다

Jev의 입력은 상황 설명과 선택지 목록이고, 출력은 그중 하나입니다. 자유 서술은 할 수 없습니다. 대신 이 제약 덕분에 여러 질문의 답을 한 번의 계산으로 병렬 처리할 수 있고, 출력 길이에 따라 지연 시간이 들쭉날쭉하지도 않습니다.

속도가 바꾸는 쓰임새

Doom 데모는 게임 상태를 텍스트로 넣고 "방아쇠를 계속 당길지", "지금 목표가 무엇인지", "어떤 키를 누를지" 같은 질문을 동시에 던지는 식입니다. 필자가 주목하는 부분은 게임 자체가 아니라, 100ms 단위의 저렴한 범용 판단을 프로그램 곳곳의 분기점에 끼워 넣을 수 있다는 가능성입니다. 지금까지 LLM 위에 만든 제품이 대부분 챗봇 형태였다면, 빠른 구조화 출력은 챗봇이 아닌 AI 활용을 여는 새로운 기본 연산이 될 수 있다는 기대입니다.

필자의 반론: 이미 비슷하게 할 수 있다

응답을 {"choice": "까지 미리 채워 두고(prefill), 선택지에 해당하는 토큰만 허용한 채 딱 한 토큰만 생성하면 됩니다. 입력 토큰은 병렬로 처리되므로 전체 JSON을 생성하는 것보다 훨씬 빠르고, 여러 질문은 일반적인 배치 추론으로 묶을 수 있습니다. 필자가 Qwen2.5-1.5B-Instruct로 직접 해보니 prefill 없는 구조화 출력보다 2~3배 빨랐다고 합니다. 다만 구조화 출력만을 목표로 최적화한 Jev가 이런 개조형 모델보다는 나을 것이라는 점은 인정합니다.

과장으로 보이는 주장들

• 환각이 없다: 선택지 밖의 답을 지어내지 않을 뿐, 틀린 선택지는 얼마든지 고를 수 있습니다. 실무 신뢰도는 제약 디코딩을 쓴 LLM과 다르지 않다는 것이 필자의 평가입니다.
• 보정된(calibrated) 확률: 일반 logit 확률과 무엇이 다른지 발표에 근거가 부족합니다.
• 비교 방식: 공개된 비교는 LLM이 JSON 전체를 토큰 단위로 생성하게 만든, LLM에 불리한 조건이었다는 지적입니다.

팔복소프트 관점

• 국내 서비스에 쓸 자리가 많습니다. 고객 문의 분류, 커머스 상품 카테고리 매핑, 리뷰·댓글 모더레이션, 검색 쿼리 의도 분류, 게임 봇 행동 결정 같은 작업입니다. 지금은 규칙 엔진이나 BERT 계열 분류기를 따로 학습시켜 쓰는 곳이 많은데, 라벨이 자주 바뀌는 도메인이라면 프롬프트와 선택지만 바꾸는 방식이 유지보수 면에서 확실히 유리합니다.
• Jev보다 prefill 트릭 PoC가 먼저입니다. 원문에는 Jev의 가격, 제공 방식, 한국어 성능 정보가 없습니다. 금융·공공처럼 외부 API 사용이 까다로운 조직은 사내 GPU에 vLLM과 오픈 모델을 올려 이 패턴부터 검증하는 게 맞습니다.
• 한국어에는 함정이 하나 있습니다. 한국어 선택지는 대부분 여러 토큰으로 쪼개지고, 첫 토큰이 겹치면 구분이 안 됩니다. 선택지를 번호 라벨로 매핑하고 그 토큰만 비교하는 방법이 안전합니다.

labels = ["1", "2", "3"]  # 1) 배송 2) 환불 3) 기타
ids = [tok.encode(l, add_special_tokens=False)[0] for l in labels]
prompt = chat_prompt + '{"choice": "'   # 응답 앞부분을 미리 채움
logits = model(**tok(prompt, return_tensors="pt")).logits[0, -1]
probs = logits[ids].softmax(-1)          # 선택지 토큰끼리만 비교

• 확률값을 임계치로 쓰려면 자체 검증셋으로 보정 여부를 확인해야 합니다. "환각 없음"이라는 문구만 믿고 사람 검수를 빼는 건 위험합니다.
• 한계도 분명합니다. 여러 단계의 추론이 필요한 판단에는 맞지 않습니다. 빠른 모델이 앞단에서 대부분을 걸러내고, 확률이 애매한 건만 추론 모델로 넘기는 2단 구조가 가장 현실적인 그림입니다.

정리

Jev에서 기억할 것은 모델 자체보다 "LLM에게 고르게만 시키면 빠르고 예측 가능해진다"는 인터페이스 아이디어입니다. 이 패턴은 지금 가진 오픈 모델로도 오늘 시험해 볼 수 있습니다. 대형 연구소들이 구조화 출력 전용 모델을 내놓는지가 앞으로 지켜볼 지점입니다.

• LLM
• 구조화출력
• Jev
• 추론최적화
• vLLM