Jev 활용 가이드, LLM 비용은 줄이고 3D 캐릭터 반응은 빠르게

9월 15일 TypeSafe AI 가 Jev 를 공개했습니다. OpenAI 출신 연구자 Diogo Almeida 가 세운 회사로, 4천만 달러 투자 소식과 함께 내놓은 첫 모델입니다. 개발자들이 먼저 주목한 건 두 숫자였습니다. 응답까지 0.07~0.5초, 입력 100만 토큰당 0.042달러. 출력 토큰에는 아예 요금을 매기지 않습니다.

이렇게 싸고 빠른 건 하는 일이 좁기 때문입니다. Jev 는 우리가 미리 정해 둔 보기 가운데 하나를 고르고, 그 선택에 확률을 붙여 돌려줍니다. 문장은 만들지 않습니다. TypeSafe 는 이런 모델을 System One 모델이라고 부릅니다. 대니얼 카너먼이 말한 빠르고 직관적인 사고, 시스템 1 에서 따온 이름입니다.

이 글에서는 Jev 가 어떻게 동작하는지 먼저 짚고, 쓸 만한 곳을 도식과 함께 살펴봅니다. LLM 앞에 두어 비용을 줄이는 라우터, 3D 캐릭터와 NPC 의 빠른 반응, 다른 AI 의 출력을 검사하는 일입니다. 마지막에는 쓰기 전에 알아야 할 한계를 정리했습니다.

Jev 는 객관식 문제를 푸는 모델입니다

LLM 에게 판단을 맡기는 건 서술형 문제를 내는 것과 비슷합니다. 답이 문장으로 오고, 코드는 그 문장을 다시 해석해야 합니다. Jev 에게는 객관식 문제를 냅니다. 상황을 설명하는 상태(state)와 질문 몇 개를 보내면, 질문마다 정해진 형식의 답과 확률이 돌아옵니다.

질문은 세 종류입니다.

질문	묻는 것	돌려받는 것	예
Choice	보기 중 무엇인가	고른 보기, 보기별 확률, 확신도	이 문의는 결제·기술·영업 중 어느 팀 일인가
Score	단계 중 어디쯤인가	점수, 단계별 확률, 확신도	고객이 얼마나 화가 났나 (0~2)
Noul	이 문장이 참인가	’예’일 확률 (0~1)	급한 요청인가

Choice 의 보기는 최대 255개까지 둘 수 있습니다. 한 요청에 질문을 여러 개 넣어도 동시에 평가하기 때문에 응답 시간은 거의 늘지 않습니다.

고객 메시지를 상태로 두고 팀 선택, 화난 정도, 긴급 여부 세 질문을 Jev 에 한 번에 보내면 '기술 0.85, 확신도 0.78', 점수 1.0, 긴급 확률 1.0 이 돌아오고, 코드가 그 값으로 기술팀 대기열에 보내는 흐름도. — TypeSafe 문서의 빠른 시작 예제를 한국어로 옮겨 그렸습니다. 숫자는 문서에 실린 응답 그대로입니다.

답의 모양이 미리 정해져 있으니 엉뚱한 형식이 나올 일은 없습니다. TypeSafe 가 “환각이 없다”고 말하는 것도 이 뜻입니다. 그래도 보기 안에서 틀린 답을 고를 수는 있습니다. 그래서 확률과 확신도가 중요합니다. 확신도가 낮은 답은 사람이나 더 큰 모델에게 넘기도록 코드를 짜 두면 됩니다.

숫자로 본 Jev

항목	값
가격	입력 100만 토큰당 $0.042, 출력 무료
응답 시간	0.07~0.5초 (TypeSafe 발표, 미국 서부 기준)
요청 하나의 크기	전체 64k 토큰, 상태와 가장 긴 질문을 합쳐 32k 토큰
요청 한도	초당 25만 토큰, 분당 1,200회 (수요에 따라 바뀔 수 있음)
입력	텍스트만. 이미지·음성·영상은 텍스트로 바꿔서 넣어야 함
언어	영어가 가장 정확. 한국어 같은 다른 언어는 직접 시험해 볼 것

TypeSafe 는 보안 경보 분류, 청구서 처리, 고객 응대 등 업무 네 가지로 자체 평가를 공개했습니다. 같은 좁은 질문들을 여러 모델에게 풀게 해 비교한 결과입니다.

모델	정확도	건당 비용	건당 시간
Jev	67.8%	$0.0004	0.4초
GPT-5.6 Terra	67.9%	$0.0304	10.1초
GPT-5.6 Sol	74.1%	$0.0836	23.3초
Claude Opus 5	73.1%	$0.1761	37.8초

정확도만 보면 Jev 는 큰 모델보다 5~6점 낮습니다. 비슷한 정확도를 낸 GPT-5.6 Terra 와 견주면 비용은 76분의 1, 시간은 25분의 1 정도입니다.

이 표는 TypeSafe 가 직접 잰 것입니다. 정답은 GPT-6 Astra 와 Claude Fable 5.1 의 답을 평균해 만들었고, 대규모 독립 검증은 아직 나오지 않았습니다. TypeSafe 스스로도 평가를 미국 서부의 노트북에서 돌렸다는 점, 지금 가격이 오래 유지될 수 있는지는 시간이 지나야 증명된다는 점을 밝혀 두었습니다.

국내에서 부르면 네트워크 시간이 더해집니다

TypeSafe 의 서비스는 지금 미국 서부에서만 돌아갑니다. 9월 30일 국내 회선에서 API 서버에 인증 없이 요청을 보내 왕복 시간을 재 보니 0.14~0.17초가 걸렸습니다. 서버가 요청을 처리하는 데 쓴 시간은 1~3ms 였으니, 거의 전부 네트워크 시간입니다. 국내 서비스에서 Jev 를 부른다면 발표된 응답 시간에 이만큼을 더해서 설계하는 편이 안전합니다.

활용 1. LLM 앞에 두는 라우터

“쉬운 질문은 Jev 가 답하고, 어려운 질문만 LLM 에 보낸다.” Jev 로 LLM 비용을 줄이는 방법을 한 줄로 줄이면 이렇습니다. 조금 더 정확히 말하면 Jev 가 하는 일은 요청마다 처리할 곳을 고르는 것입니다. 답을 쓰는 건 그다음 단계입니다.

주문 조회처럼 코드로 처리할 수 있는 요청은 LLM 을 부르지 않습니다.
자주 묻는 질문이면 준비해 둔 답 가운데 하나를 고릅니다. 이것도 Choice 질문 하나입니다.
짧은 설명이면 충분한 요청은 소형 LLM 으로 보냅니다.
여러 조건을 따지거나 새 답을 길게 써야 하는 요청만 상위 LLM 으로 갑니다.
확신도가 낮으면 사람에게 넘깁니다.

들어온 요청이 Jev 를 거쳐, 확신도가 0.5 이상이면 코드 처리, 준비된 답, 소형 LLM, 상위 LLM 네 갈래로 가고, 0.5 미만이면 사람이나 상위 LLM 으로 가는 흐름도. 판단 비용은 요청당 약 0.00003달러, 소형 LLM 은 약 0.0002달러, 상위 LLM 은 약 0.0046달러로 표시돼 있다. — 확신도 0.5 기준은 TypeSafe 문서의 의도 라우팅 예제를 따랐습니다.

요청은 이렇게 보냅니다. 문서에 따르면 Jev 의 주 학습 언어가 영어라서, 우리가 직접 쓰는 보기 설명은 영어로 두었습니다.

{
  "model": "jev-1.13.0",
  "state": { "message": "주문한 가방이 아직 안 왔어요. 주문번호 A-1042 예요." },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Where this request should be handled",
      "criteria": {
        "order_lookup": "Asks about an order or its delivery",
        "faq": "One of our prepared FAQ answers fully covers it",
        "small_llm": "Needs a short explanation, but the judgment is simple",
        "large_llm": "Needs several conditions weighed or a long new answer written",
        "human": "Refund dispute, legal issue, or strong complaint"
      }
    }
  }
}

받은 답으로 길을 나누는 코드는 짧습니다.

const { route } = res.answers;

if (route.confidence < 0.5) return sendToHuman(req); // 애매하면 사람에게

switch (route.choice) {
  case 'order_lookup': return lookupOrder(req);   // LLM 없이 처리
  case 'faq':          return answerFromFaq(req); // 준비된 답 중에서 고름
  case 'small_llm':    return askLLM(req, SMALL_MODEL);
  case 'large_llm':    return askLLM(req, LARGE_MODEL);
  default:             return sendToHuman(req);
}

얼마나 아낄 수 있을까

Jev 판단 비용은 무시해도 될 만큼 작습니다. 요청 하나에 입력 800 토큰이면 약 0.00003달러이고, 한 달에 100만 건이어도 33.6달러입니다. 같은 100만 건을 모두 Claude Sonnet 5.5 로 처리하면(출력 300 토큰 가정) 4,600달러가 나오니, 판단 비용은 그 0.7% 수준입니다.

결국 절감 폭은 큰 모델을 거치지 않고 끝나는 요청이 얼마나 되느냐로 정해집니다. 예를 들어 절반은 코드나 준비된 답으로 끝나고, 35%는 GPT-6 Luna 로, 15%만 Sonnet 5.5 로 간다고 가정해 보겠습니다.

구성	한 달 비용 (100만 건)
모두 Sonnet 5.5 로 처리	약 $4,600
Jev 로 나눠 처리 (위 비율 가정)	약 $804 (Jev $34, Luna $81, Sonnet 5.5 $690)

비율은 서비스마다 다르니, 표의 숫자보다 계산하는 방법을 가져가세요.

주의할 점이 하나 있습니다. 작은 모델로 잘못 보낸 요청은 오류 없이 품질만 조용히 떨어집니다. 처음 몇 주는 기존 방식과 나란히 돌리며 결과를 비교하는 편이 좋습니다.

초안을 검사하고 필요할 때만 올려 보내기

순서를 바꾼 방법도 있습니다. 싼 모델이 먼저 답을 쓰고, Jev 가 그 답이 근거 자료로 뒷받침되는지 검사합니다. 통과하지 못한 답만 큰 모델이 다시 씁니다. OpenRouter 가 공개한 예제에서는 50문항 기준으로, 모든 질문을 GPT-6 Astra 에 맡겼을 때보다 틀린 답이 적었고(0개 대 2개) 비용은 7% 수준이었습니다. 문항 수가 적은 예제라는 점은 감안해서 보세요.

활용 2. 3D 캐릭터와 NPC 의 빠른 반응

게임이나 가상 공간에서 캐릭터에게 말을 걸었는데 몇 초 동안 굳어 있으면 몰입이 깨집니다. 대사를 LLM 으로 만들면 그런 틈이 생기기 쉽습니다. 여기서 Jev 의 속도가 쓸모 있습니다.

핵심은 반응과 대사를 나누는 것입니다. 캐릭터가 할 수 있는 동작과 표정은 리깅과 애니메이션 작업으로 미리 만들어 둡니다. 손 흔들기, 고개 끄덕이기, 놀란 표정, 뒤로 물러서기 같은 것들이죠. Jev 는 지금 상황에 맞는 반응을 이 목록에서 고릅니다. 리그가 가진 동작 목록이 그대로 Choice 의 보기가 되는 셈입니다. 캐릭터는 고른 반응을 바로 재생하고, 말이 필요할 때만 LLM 이 뒤에서 대사를 씁니다. 대사 역시 미리 써 둔 문장 가운데서 Jev 가 고르게 할 수도 있습니다.

플레이어가 말을 걸면 0.3초 안팎에 Jev 가 고른 반응(손 흔들기, 놀란 표정, 플레이어 바라보기)을 바로 재생하고, 대사가 필요하다고 판단되면 LLM 이 1~3초 뒤 대사를 완성해 음성과 립싱크로 이어지는 두 갈래 타임라인. 아래에 엔진이 지키는 규칙 세 가지가 적혀 있다. — 시간 축은 예시입니다. 국내에서 부르면 Jev 쪽에 네트워크 왕복 0.14~0.17초가 더해집니다.

질문은 한 요청에 묶어서 보냅니다. 몸짓, 표정, 대사가 필요한지를 한 번에 물으면 답도 한 번에 옵니다.

{
  "model": "jev-1.13.0",
  "state": {
    "npc": "Hans, the village blacksmith. Gruff but kind.",
    "event": "플레이어가 다가와 '칼 좀 고쳐 줄 수 있어요?' 라고 말했다",
    "npc_is_busy": true,
    "relationship": "friendly"
  },
  "questions": {
    "reaction": {
      "type": "choice",
      "instructions": "Hans's immediate body reaction",
      "criteria": {
        "nod": "Acknowledges and agrees",
        "wave": "Greets the player",
        "keep_working": "Keeps hammering and glances up",
        "step_back": "Is startled or wary"
      }
    },
    "face": {
      "type": "choice",
      "instructions": "Hans's facial expression",
      "criteria": { "smile": "Pleased", "neutral": "Calm", "frown": "Annoyed" }
    },
    "needs_line": {
      "type": "noul",
      "instructions": "The player asked Hans something that needs a spoken answer"
    }
  }
}

엔진 쪽에서는 몇 가지 규칙을 지키는 게 좋습니다. 아래에 소개할 커뮤니티 구현과 게임 개발 가이드에서 가져온 방법입니다.

지금 가능한 동작만 보기로 보냅니다. 열쇠가 없으면 ’문 열기’는 보기에서 뺍니다. Jev 가 규칙에 어긋나는 선택을 할 여지를 처음부터 없애는 방법입니다.
매 프레임 부르지 않습니다. 플레이어가 말을 걸었을 때, 위협이 나타났을 때처럼 상황이 바뀔 때만 부릅니다.
늦게 온 답은 버립니다. 요청마다 상황 번호를 붙여 두고, 답이 도착했을 때 번호가 바뀌었으면 무시합니다.
기다리는 동안 멈추지 않습니다. 요청은 비동기로 보내고 하던 동작을 이어 갑니다. 정해 둔 시간 안에 답이 없거나 확신도가 낮으면 기본 동작으로 넘어갑니다.
API 키는 게임에 넣지 않습니다. 게임은 자체 서버를 거쳐 Jev 를 부릅니다.

비용도 감당할 만합니다. 상태가 1,000 토큰이면 결정 한 번에 약 0.004센트이고, NPC 하나가 1초에 한 번씩 판단해도 한 시간에 0.15달러 정도입니다. TypeSafe 가 공개한 Doom 데모는 초당 10번 판단하며 시간당 7달러가 들었습니다. 다만 분당 1,200회라는 요청 한도가 있으니, NPC 가 많다면 서버에서 요청을 모아 보내야 합니다.

실제로 만들어 본 사례도 있습니다.

doom-jev 는 적의 방향과 거리, 체력과 탄약을 글로 바꿔 넣고 여섯 가지 행동 중 하나를 고르게 했습니다. 초당 약 8번, 중간값 0.12초로 판단했고, 길 찾기와 반사 동작은 코드가 맡았습니다.
jev-unreal-statetree 는 Unreal Engine 5.8 의 StateTree 에 Jev 판단 작업을 붙이는 플러그인입니다. 상태에 들어갈 때 한 번만 요청하고, 상황 번호가 바뀐 뒤 온 답은 버립니다.
WorldKit 은 NPC 판단 런타임입니다. 게임 규칙은 엔진이 지키고, Jev 는 지금 가능한 행동만 보고 고릅니다.
jev-npc-interaction-prototype 의 창고 경비원은 대사가 모두 미리 써 둔 문장입니다. Jev 는 경비원의 행동과 ’플레이어의 말이 믿을 만한가’를 판단하고, 출입을 허락하려면 행동 확신도 0.50, 신뢰도 0.55 이상이 필요합니다.

리깅 작업 자체에도 쓸 수 있을까

Jev 가 뼈대를 만들거나 스킨 가중치를 계산하지는 못합니다. 이미지도 읽지 못합니다. 다만 파이프라인 안에 보기가 정해진 판단이 있다면 후보가 됩니다.

여러 툴에서 가져온 캐릭터의 뼈 이름(mixamorig:LeftForeArm, L_lowerarm 같은)을 엔진의 표준 휴머노이드 슬롯에 맞추는 일은 뼈마다 Choice 질문 하나로 바꿀 수 있습니다. 좌우 판정이나 계층 확인처럼 규칙으로 되는 부분은 코드에 남기고요. 애니메이션 클립에 ‘인사’, ‘거절’, ‘놀람’ 같은 용도 태그를 붙이는 일도 비슷합니다. 둘 다 아직 공개된 사례를 찾지 못한 아이디어이니, 작은 표본으로 정확도부터 재 보세요.

활용 3. 그 밖에 써 볼 만한 곳

쓰임	Jev 에게 묻는 것	참고
LLM 입출력 검사	탈옥 시도인가? 그대로 따르면 얼마나 해로운가?	TypeSafe 가드레일 예제
에이전트 도구 호출 검사	실행하기 전에 막아야 할 위험한 호출인가?	LangChain 하네스 글
인용 확인	이 인용이 주장을 뒷받침하나?	TypeSafe 인용 검증 예제
검색 결과 재정렬	이 문단이 질문과 얼마나 관련 있나?	법률 검색 예제: 1위 정확도 5%에서 18%로
게임 채팅 관리	욕설이나 괴롭힘인가? 얼마나 심한가?	TypeSafe 활용 사례 목록
음성 에이전트	이번 턴은 준비된 답, 소형 모델, 대형 모델 중 어디로?	Evalgent 글: 음성 인식이 말 끝을 감지하는 동안 함께 돌려 지연을 숨김

쓰기 전에 알아둘 한계

글을 쓰지 못하고, 판단 이유도 설명하지 않습니다. 확률만 돌려주니, 판단 근거를 남겨야 하는 업무라면 기록 방법을 따로 마련해야 합니다.
숫자와 날짜, 세기에 약합니다. TypeSafe 문서도 계산과 날짜 비교는 코드로 하라고 권합니다. 게임이라면 거리나 체력은 ‘가깝다’, ‘낮다’ 같은 말로 바꿔 넣는 편이 낫습니다.
쓴 그대로 읽습니다. 이중 부정이나 여러 단계를 거쳐야 하는 질문은 정확도가 떨어집니다. 질문은 짧고 직접적으로 쓰세요.
상태가 길고 관련 없는 내용이 많으면 흔들립니다. 필요한 필드만 골라 보내세요.
그럴듯한 문장 한 줄에 결정이 뒤집힐 수 있습니다. 9월 24일 공개된 JevOut 논문은 자연스러워 보이는 짧은 문맥을 덧붙여, 처음에 맞혔던 결정 508개 가운데 312개(61.4%)를 다른 답으로 바꿨습니다. 그중 229건은 틀린 답에 0.7 이상의 확률을 줬습니다. 사용자 입력이 그대로 들어가는 곳이라면 중요한 결정은 한 번 더 확인하세요.
확률은 많은 답을 모아 봤을 때 맞는 값입니다. 0.9 라고 나온 답 하나가 반드시 맞는다는 뜻은 아닙니다.
같은 입력에 늘 같은 답이 나오지는 않습니다. 결정론 모드가 아직 없어서, 모든 플레이어가 같은 결과를 봐야 하는 멀티플레이 판정에는 맞지 않습니다.
미국 서부의 호스팅 서비스뿐입니다. 오프라인 동작이나 국내 데이터 보관이 필요하면 오픈 모델을 검토하세요. Apache-2.0 으로 공개된 Kev 는 TypeSafe 와 같은 API 를 쓰고, 27B 모델이 처음 보는 데이터에서 Jev 와 1점 안팎의 차이(0.848 대 0.857)를 보였다고 합니다.
아직 조기 접근 단계입니다. 대기자 명단이 있고, 요청 한도는 예고 없이 바뀔 수 있습니다. jev-latest 같은 별칭은 새 버전이 나오면 가리키는 모델이 바뀌니, 임계값을 맞춰 둔 뒤에는 jev-1.13.0 처럼 버전으로 고정하세요.

이렇게 시작해 보세요

반복되는 결정 하나를 고릅니다. 문의 분류, NPC 반응, 도구 호출의 위험도처럼 답이 몇 가지로 정해지는 것이면 됩니다.
보기를 구체적으로 씁니다. 보기마다 언제 고르는지 한 문장으로 적고, ‘해당 없음’ 보기를 하나 넣습니다.
지난 기록으로 먼저 채점합니다. 정답을 아는 사례 100~200건을 넣어 보고, 확신도 구간별로 얼마나 맞는지 확인해 임계값을 정합니다.
기존 방식과 나란히 돌립니다. 몇 주 동안 결과를 비교하면서, 작은 모델로 잘못 보낸 요청이 없는지 살핍니다.
확신도가 낮을 때의 출구를 만듭니다. 서비스라면 사람이나 큰 모델, 게임이라면 기본 동작입니다.

endue 에서는

endue 에서 에이전트를 운영한다면 같은 원칙을 모델 설정에 그대로 옮길 수 있습니다. 가볍고 빠른 모델을 에이전트 기본값으로 두고, 어려운 메시지에서만 강한 모델로 바꾸는 식입니다. 정기 작업은 루틴에 모델을 고정해 두면 비용이 일정하게 유지됩니다. 설정 방법은 모델 고르기 문서에, 모델을 고르는 순서는 지난 글에 정리해 두었습니다.

참고 자료

TypeSafe, Introducing System One Models & Jev (2026년 9월 15일)
TypeSafe 문서: Models, Quick start, Intent routing, Smart home assistant demo, Jev 1.13 jaggedness
TypeSafe, 워크플로 평가
Simon Willison, Jev introduces a new shape of LLM (2026년 9월 21일)
Latent Space, Jev: System One models for Prod, not God
The Register, Jev 공개 기사 (2026년 9월 16일)
OpenRouter, Cut LLM cost with a Jev-verified cascade
GuardingPear Software, How to use Jev in game development
Zixiang Xu, JevOut: Natural Context Can Flip Decision Models (arXiv, 2026년 9월 24일)