main-logo

판단만 하는 AI, Jev 알아보기

판단하는 AI 모델 Jev. 어떻게 동작하고 어디에 쓰면 좋을까?

profile
BR
2026년 09월 30일 · 0 분 소요

들어가며

요즘 스레드나 유튜브에서 Jev라는 AI 모델 이야기가 자주 보입니다. 챗봇처럼 대화하는 게 아니라 판단만 하는 AI인데, 그 대신 엄청 빠르고 싸다는 반응이 많았습니다.

대화하지 않는 AI가 어떻게 판단을 내린다는 것인지, 기존 LLM에게 JSON으로 답하게 하는 거랑은 뭐가 다른지, 실제 프로젝트에서는 어디에 쓸 수 있을지 궁금해서 좀 더 찾아봤습니다.

이번 글에서는 Jev의 동작 원리와 사용법, 장단점, 그리고 어디에 적용하면 좋을지를 정리해보았습니다.

Jev란?

Jev는 TypeSafe AI라는 회사가 2026년 9월에 공개한 AI 모델입니다. 가장 큰 특징은 답을 글로 만들지 않는다는 점입니다. TypeSafe는 이런 모델을 '시스템 원(System One) 모델'이라고 부르는데, 사람이 깊이 생각하지 않고 빠르게 직관적으로 판단하는 '시스템 1' 사고에서 따온 이름이라고 합니다.

ChatGPT에게 질문하면 문장으로 답이 돌아오죠. Jev는 다릅니다. 미리 정해둔 보기 중 하나를 고르거나, 예/아니오의 확률을 알려주거나, 점수를 매겨줍니다. 쉽게 말하면 똑똑한 if문이라고 생각하면 됩니다.

코드로 if (price > 100)은 쉽게 쓸 수 있지만, "이 메시지가 화난 메시지라면" 같은 조건은 코드로 쓰기 어려운데요. Jev는 바로 이런 판단을 대신 해줍니다. 판단 결과를 보고 무엇을 할지는 우리 코드가 정하게 됩니다.

참고로 이름은 경제학자 제번스(Jevons)에서 따왔다고 합니다. 판단 비용을 아주 싸게 만들면, 지금까지 AI를 쓰지 않던 곳에서도 쓰게 될 거라는 뜻을 담았다고 합니다.

Jev는 어떻게 동작할까?

Jev에게는 두 가지를 보냅니다. 판단할 데이터(state)와 그 데이터에 대한 질문(questions)입니다. 보기 중에서 고르는 질문이라면 그 보기까지 질문 안에 같이 넣어야 합니다. 예를 들어 "어느 팀 문의인가?"라고 물으면서 결제·기술·영업이라는 보기를 함께 주면, Jev는 이 셋 중에서만 고르고 보기에 없는 답은 만들어내지 않는 것입니다.

질문은 세 종류가 있습니다.

종류 이런 질문에 돌아오는 값
Noul 예/아니오 0~1 사이 확률
Choice 보기 중 하나 고르기 고른 보기, 확률, 확신도 (confidence)
Score 단계별로 점수 매기기 점수, 확률, 확신도 (confidence)

예를 들어 고객 문의 하나를 보내면서 "환불 요청인가요?"(Noul), "결제·기술·영업 중 어느 팀 문의인가요?"(Choice), "얼마나 급한가요?"(Score)를 한 번에 물어볼 수 있습니다.

그럼 LLM에게 JSON으로 답하라고 하는 것과 뭐가 다를까요? LLM은 JSON으로 답할 때도 결국 글자를 한 토큰씩 순서대로 써 내려가는 방식이라 느리고, 중간에 형식이 깨질 수도 있습니다. 하지만 Jev는 답을 써 내려가는 게 아니라, 우리가 준 보기 하나하나가 정답일 확률을 한 번에 계산해서, 그중 확률이 가장 높은 보기를 골라주기 때문에 훨씬 빠르고, 보기 밖의 답이 나올 수가 없습니다.

Jev 사용법 알아보기

API 키는 TypeSafe 콘솔에서 받을 수 있는데요. 콘솔의 Playground에서 코드 없이 먼저 테스트해볼 수도 있습니다.

먼저 SDK를 설치합니다. (Node.js 20 이상)

npm install @typesafe-ai/sdk

환경변수 TYPESAFE_API_KEY에 키를 넣고, 아래처럼 사용하면 됩니다.

import { choice, noul, score, TypeSafeClient } from '@typesafe-ai/sdk'

const client = new TypeSafeClient()

const ticket = 'Safari에서 내보내기 버튼을 누르면 페이지가 멈춰요. 크롬에서는 잘 됩니다.'

const { answers } = await client.systemOne({
  state: { ticket },
  questions: {
    category: choice('`ticket`은 어떤 문의인가?', {
      bug: '무언가 고장 났음',
      feature: '새 기능을 요청함',
      billing: '결제, 환불',
      other: null,
    }),
    severity: score('`ticket`의 문제는 얼마나 심각한가?', [
      '보기에만 문제가 있음',
      '기능이 안 되지만 다른 방법이 있음',
      '다른 방법 없이 아예 안 됨',
    ]),
    hasSteps: noul('`ticket`에 재현 방법이 적혀 있는가?'),
  },
})

console.log(answers.category.choice) // 'bug'
console.log(answers.severity.score)  // 예: 1.4
console.log(answers.hasSteps.noul)   // 예: 0.82

질문 이름(category, severity)은 코드에서만 쓰는 이름이고 Jev에게는 전달되지 않습니다. 그렇기 때문에 질문 내용은 반드시 문장으로 적어주어야 합니다. 또 Choice에는 예시 코드처럼 other 같은 예비 보기를 넣어두는 게 좋습니다. 보기에 없는 문의가 들어와도 Jev는 반드시 하나를 고르기 때문입니다.

또한, 복잡한 판단은 하나의 큰 질문으로 묻지 말고 작은 질문 여러 개로 쪼개는 게 좋습니다. "이 티켓을 어떻게 처리해야 할까?"라고 묻기보다 위 예제처럼 종류, 심각도, 재현 방법 유무를 따로 묻고, 최종 결정은 코드에서 조합하는 식으로 말입니다. 질문을 여러 개 보내도 거의 느려지지 않으니 필요할 것 같은 질문은 한 번에 묶어 보내면 되고, 판단 기준을 바꿀 때도 프롬프트 대신 코드 몇 줄만 고치면 됩니다.

참고로 예시 코드는 읽기 쉽게 한국어로 적었는데요, Jev는 영어에서 가장 정확하다고 하니 실제로 쓸 때는 이 부분도 테스트해보는 게 좋을 것 같습니다.

애매할 때는 사람에게 넘기기

Choice와 Score 결과에는 확신도 (confidence)도 함께 옵니다. 이 값이 낮으면 Jev도 헷갈린다는 뜻이므로, 사람이 확인하도록 넘기면 됩니다.

const { category } = answers

if (category.confidence < 0.5) {
  sendToHuman(ticket) // 애매하면 사람이 확인
} else if (category.choice === 'bug') {
  createIssue(ticket)
}

기준값(여기서는 0.5)은 정해진 답이 없어서, 실제 데이터로 테스트해보면서 맞춰가야 합니다.

Jev의 장점

빠릅니다
TypeSafe에 따르면 응답 시간은 0.07~0.5초 정도입니다. 같은 질문에 LLM이 3초에서 수 분까지 걸린 것과 비교하면 실시간 기능에도 쓸 수 있는 속도입니다.

저렴합니다
입력 100만 토큰에 0.042달러, 출력은 무료입니다. LLM 입력 가격(100만 토큰에 0.2~10달러)과 비교하면 5배에서 240배 가까이 싼 셈입니다. 스레드나 유튜브에서도 저렴한 것이 장점이라는 평이 많습니다.

형식이 깨지지 않습니다
LLM에게 JSON을 요청하면 가끔 형식이 깨지는데, Jev는 정해둔 보기 안에서만 답하기 때문에 이런 걱정이 없습니다. 다만 형식이 맞는 것과 판단이 맞는 것은 다른 이야기입니다. TypeSafe가 말하는 "환각 없음"도 보기 밖의 답이 안 나온다는 뜻이지, 틀린 보기를 자신 있게 고를 수는 있습니다.

확신도를 믿을 수 있습니다
LLM에게 "몇 % 확신해?"라고 물어도 그 숫자가 정확하다는 보장은 없죠. 하지만 Jev는 확률이 실제 정답률과 맞도록 학습되어서, 확신도가 높으면 자동으로 처리하고 낮으면 사람이 확인하도록 나누기 좋습니다.

Jev의 단점

글을 못 씁니다
답변 작성, 요약, 코드 생성은 안 되고, 입력도 텍스트만 받습니다. 글이 필요하면 결국 LLM을 같이 써야 합니다.

정확도는 LLM보다 낮습니다
TypeSafe 자체 평가에서도 Jev의 정확도는 67.8%로, GPT-5.6 솔(74.1%)이나 클로드 오퍼스 5(73.1%)보다 낮았습니다. 그래서 복잡한 판단보다는 분류처럼 정해진 답을 고르는 작업에 주로 쓰입니다.

질문을 잘 써야 합니다
Jev는 질문을 적힌 그대로만 이해하기 때문에 질문이 애매하면 답도 애매해집니다. 숫자 계산이나 날짜 비교도 믿기 어려우므로, 이런 건 코드로 처리하고 결과만 넘겨주는 게 좋습니다.

아직 검증이 필요합니다
영어 중심으로 학습되어 한국어는 정확도가 떨어질 수 있다고 공식 문서에 나와있습니다. 2026년 9월 기준 나온 지 2주밖에 안 되어 참고 자료가 적고, 데이터가 외부 API로 전송되니 고객사 프로젝트에 쓰기 전에는 꼭 확인이 필요합니다.

어디에 써볼 수 있을까?

Jev는 LLM을 대신하기보다는 LLM과 함께 쓸 때 더 좋아 보였습니다.

LLM 호출 줄이기
예를들어 고객 문의가 들어오면 Jev가 먼저 분류하게 합니다. 주문 조회처럼 간단한 건 바로 처리하고, 답변을 써야 하는 것만 LLM에게, 까다로운 건 사람에게 보내는 식으로요. 비싼 LLM은 꼭 필요할 때만 쓸 수 있게 됩니다.

LLM 결과 검사하기
반대로 LLM이 쓴 요약이 원문과 맞는지 Jev로 한 문장씩 확인할 수도 있습니다.

정규식 대신 쓰기
키워드나 정규식으로 처리하던 부분에 넣어볼 수 있습니다. 예를 들어 제목에 "긴급"이 들어가면 우선 처리하는 식의 키워드 규칙을, 실제로 급한 내용인지 Jev가 판단하는 방식으로 바꿔보는 것입니다.

데이터 분류하기
수천 건의 데이터를 분류할 때도 좋습니다. 공식 문서에도 기업 연례 보고서를 75개 산업군으로 나누거나, 특허와 상품을 분류하는 예제가 소개되어 있습니다.

공식 문서에서는 처음 도입할 때 기존 로직은 그대로 두고, Jev는 판단 결과만 기록하게 해서 둘이 얼마나 일치하는지 비교해보라고 권장하고 있습니다. 이렇게 시작해서 충분히 믿을 만하다 싶을 때, 틀려도 크게 문제 되지 않는 부분부터 Jev로 바꿔보면 좋을 것 같습니다.

마치며

처음에는 판단만 하는 AI가 어떻게 동작하는지, 그리고 어디에 쓸 수 있을지 궁금해서 알아보기 시작했는데요. 원리를 알고 나니 왜 다들 주목하는지 조금은 알 것 같았습니다. 판단 하나하나를 빠르고 믿을 만하게 내려준다는 점이 큰 강점이라고 느껴졌기 때문입니다.

Jev를 도입하기로 결정했다면, 중요한 건 LLM이 잘하는 일과 Jev가 잘하는 일을 나눠 쓰는 것 같습니다. 답변 작성이나 복잡한 추론은 LLM에게 맡기고, 분류나 판단처럼 빠르게 결정하면 되는 일은 Jev에게 맡기는 거죠. 이렇게 역할을 잘 나누면 비싼 LLM은 꼭 필요할 때만 쓰게 되니, 프로젝트도 더 빠르고 효율적으로 돌아갈 수 있지 않을까 싶습니다.

오늘도 읽어주셔서 감사합니다. 🙇‍♀️

 

참고문헌

TypeSafe Docs
Introducing System One Models & Jev (TypeSafe AI Blog)
AI 매터스 뉴스레터 #199 - 더 이상 새로울 게 없었던 AI 시장에서 등장한 Jev 열풍 (AI매터스)
A deep dive into Jev, TypeSafe's System One model (flaviocopes.com)