Jev란 무엇인가? AI 에이전트에 더 많은 챗봇이 아니라 의사결정 모델이 필요한 이유

Jev는 또 다른 챗봇이 아닙니다. TypeSafe AI는 Jev를 더 좁은 목적에 맞게 구축했습니다. 일부 상태를 입력받아 구조화된 결정을 내리고, 소프트웨어가 즉시 실행할 수 있는 결과를 반환하는 것입니다. 문단을 작성하는 대신 Jev는 미리 정의된 선택지, 점수, 확률 및 신뢰도 추정치를 생성합니다.

이는 AI 에이전트의 작업 대부분이 생성이 아니기 때문에 중요합니다. 에이전트는 어떤 도구를 호출할지, 문서가 관련 있는지, 작업이 위험한지, 언제 재시도할지, 언제 상위 담당자에게 넘길지를 끊임없이 결정합니다. Jev는 유용한 아키텍처상의 질문을 던집니다. 소프트웨어에 결정만 필요할 때 왜 대규모 생성 모델을 호출해야 할까요?

Jev란 무엇인가요?

Jev는 TypeSafe AI가 System One Models라고 부르는 제품군으로 출시한 첫 번째 공개 모델입니다. 이 모델은 자유로운 대화보다 소프트웨어 내부에서 빠르게 결정을 내리도록 최적화되었습니다.

TypeSafe는 2026년 9월 Jev를 선보였습니다. 핵심은 간단한 인터페이스였습니다.

비구조화된 상태
        ↓
구조화된 질문
        ↓
타입이 지정된 확률적 결정

기존 LLM은 다음과 같이 생성하여 지원 요청을 분류할 수 있습니다.

"이는 다음과 같은 이유로 결제 문제로 보입니다.
고객이 요금이 두 번 청구되었다고 말합니다."

Jev는 소프트웨어가 실제로 필요로 하는 부분을 반환하도록 설계되었습니다.

billing:     0.87
technical:   0.09
sales:       0.04

핵심 차이는 지능이 있느냐 없느냐가 아닙니다. 인터페이스의 차이입니다. 언어 모델은 생성하고, 결정 모델은 선택합니다.

Jev와 LLM 비교: 결정만 필요할 때 텍스트를 생성하는 이유는?

범용 LLM이 가치 있는 이유는 설명, 코드, 계획, 요약, 이메일 또는 도구 인수 등 거의 무엇이든 생성할 수 있기 때문입니다.

하지만 이러한 유연성은 작업이 다음 항목에 불과할 때 불필요한 오버헤드를 만듭니다.

이 작업은 어떤 도구가 처리해야 할까요?

A. 웹 검색
B. 코드 실행
C. 파일 검색
D. 이메일

기존 모델로도 이 작업을 해결할 수 있지만, 여전히 분류기나 라우터로 사용되는 범용 생성 시스템입니다.

이로 인해 Jev는 특히 실용적인 AI 에이전트 자동화와 밀접한 관련이 있습니다. 모델이 사용자에게 보여 줄 단일 답변을 생성하기 전에 여러 가지 작은 라우팅 및 안전성 결정을 내릴 수 있기 때문입니다.

Jev는 어떻게 구조화된 의사결정을 내리나요?

TypeSafe는 모든 아키텍처 세부 사항을 공개하지 않았지만, 세 가지 중요한 차이점을 설명합니다. 구조화된 의사결정에 최적화된 모델, 병렬 샘플러, 그리고 RLCD 또는 보정된 의사결정을 위한 강화 학습(Reinforcement Learning for Calibrated Decisions)이라는 학습 방식입니다.

개발자 대상 추상화는 다음과 같습니다.

상태
  ↓
의사결정 질문
  ↓
확률 분포
  ↓
애플리케이션 정책

TypeSafe의 공개 워크플로 평가는 세 가지 의사결정 기본 요소를 보여줍니다.

모델은 불확실한 판단을 처리합니다. 각 결정이 수행할 수 있는 작업의 범위는 여전히 코드가 결정합니다.

AI 에이전트에 의사결정 계층이 필요한 이유

에이전트는 본격적인 추론이 필요하기 전에 수십 가지의 작은 결정을 내려야 할 수 있습니다.

• 어떤 도구를 호출해야 하나요?
• 이 문서가 관련 있나요?
• 웹에서 검색해야 하나요?
• 이 작업을 자동으로 실행할 수 있나요?
• 이전 단계가 성공했나요?
• 다시 시도해야 하나요?
• 사람의 승인이 필요한가요?

모든 분기에 가장 큰 가용 모델을 사용하는 것은 간단하지만, 지연 시간과 비용이 모두 증가할 수 있습니다.

사용자 요청
      ↓
의사결정 계층
      ↓
 ┌────┼─────┬─────┐
 ↓    ↓     ↓     ↓
웹  파일  코드  이메일
에이전트 에이전트 에이전트 에이전트

라우터는 파일 에이전트를 선택한 이유를 설명할 필요가 없습니다. 충분한 확신을 바탕으로 올바른 경로를 선택하면 됩니다.

이는 자율 시스템의 중요한 안전 원칙도 강화합니다. 모델 출력은 실행 권한을 자동으로 상속하는 것이 아니라 작업을 제안해야 합니다. 별도의 도구 실행 신뢰 경계에서 코드가 실제로 파일이나 시스템을 변경하기 전에 권한, 인수, 부작용을 검증할 수 있습니다.

AI 에이전트 스택은 사고와 의사결정을 분리할 수 있습니다

초기의 많은 에이전트는 요청 해석, 도구 선택, 결과 평가, 계속 진행할지 여부 결정, 응답 작성 등 거의 모든 작업에 하나의 강력한 모델을 사용합니다.

더 전문화된 아키텍처는 이러한 작업을 분리합니다:

의사결정 계층
      ↓
추론 계층
      ↓
도구 계층
      ↓
데이터 / 스토리지 계층

의사 결정 계층은 반복적인 라우팅, 점수 산정, 관련성 판단, 게이팅을 처리합니다. 더 큰 모델은 종합, 계획 수립, 코딩, 어려운 추론을 처리합니다. 결정론적 소프트웨어가 최종 작업을 수행합니다.

유용한 요약은 다음과 같습니다.

빠른 모델:
"어떤 일이 일어나야 할까요?"

대형 모델:
"어떻게 해야 할까요?"

코드:
"실행해."

이것이 바로 AI 비용을 위한 모델 라우팅이 중요한 또 다른 이유입니다. 가장 저렴한 아키텍처는 하나의 모델이 모든 작업을 처리하는 방식이 아니라, 각 작업을 안정적으로 처리할 수 있는 가장 저렴한 계층으로 작업을 보내는 방식인 경우가 많습니다.

최고 답변보다 확신도가 중요한 이유

소프트웨어가 명확한 사례와 모호한 사례를 구분할 수 있다면, 확률을 고려한 의사 결정이 더욱 유용해집니다.

다음을 생각해 보세요.

청구서:     0.97
계약:       0.02
기타:       0.01

자동 처리가 합리적일 수 있습니다.

이제 다음과 비교해 보세요.

청구서:     0.43
계약:       0.39
기타:       0.18

“청구서”가 여전히 가장 가능성 높은 답이지만, 불확실성에 따라 다음 단계가 달라져야 합니다.

높은 확신
      ↓
자동 작업

중간 확신
      ↓
더 큰 추론 모델

낮은 확신
      ↓
사람의 검토

TypeSafe는 RLCD를 이러한 확신을 후속 의사 결정에 유용하게 만들기 위한 훈련으로 설명합니다. 실제로 중요한 질문은 보정입니다. 시스템이 높은 확신을 보일 때, 그것이 실제 환경에서 더 높은 정확도와 일치하나요?

이는 특히 로컬 파일이나 시스템 작업을 처리하는 에이전트에 유용합니다. 승인 게이트를 통해 위험이 낮은 자동화와 영향이 큰 변경 작업을 구분할 수 있기 때문입니다.

Jev는 정말 “환각이 0”일까요?

이 주장은 정확한 정의가 필요합니다.

Jev의 출력 공간은 미리 정의되어 있습니다. 허용되는 선택지가 다음과 같다면:

청구였을 때
기술
영업

모델은 다음과 같은 예상치 못한 자유 형식 범주를 반환할 수 없습니다.

마케팅

유효한 타입 대신 설명 문단을 반환하는 경우도 있습니다.

이렇게 하면 중요한 오류 모드 하나, 즉 유효하지 않은 출력이 제거됩니다.

또 다른 문제 하나를 없애지는 않습니다.

잘못된 유효 결정을 반환할 수 있습니다.

Jev는 청구였을 때 정답이 기술. 출력은 완전히 타입 안전하면서도 여전히 틀릴 수 있습니다.

따라서 유용한 해석은 다음과 같습니다.

Jev는 스키마를 벗어난 답변을 방지할 수 있습니다. 하지만 스키마 안에 있는 모든 판단이 옳다고 보장할 수는 없습니다.

에이전트가 실제 작업을 수행할 수 있을 때는 이 구분이 더욱 중요해집니다. 구조화된 출력은 모호성을 줄여 주지만, 애플리케이션 수준의 권한과 검증은 여전히 중요합니다.

Jev와 구조화된 출력: 이건 그냥 JSON 모드 아닌가요?

최신 LLM API는 이미 제약된 객체를 반환할 수 있습니다.

{
  "route": "billing",
  "priority": 4,
  "needs_human": false
}

따라서 실제 차이는 단순히 “Jev가 구조화된 데이터를 생성한다”는 데 있지 않습니다.

구조화된 출력 LLM은 여전히 응답이 스키마에 맞도록 제한된 범용 생성 모델입니다. Jev는 구조화된 의사 결정 자체를 워크로드로 삼도록 설계되었습니다.

따라서 더 나은 질문은 둘 다 JSON을 반환할 수 있는지가 아닙니다. 둘 다 가능합니다.

문제는 범용 언어 생성기가 수백만 건의 소규모 분류, 라우팅 및 게이팅 결정을 처리하는 데 가장 효율적인 도구인가 하는 것입니다.

Jev는 얼마나 빠르고 저렴한가?

TypeSafe는 공개된 Jev 워크로드에서 엔드투엔드 응답 시간이 대략 70~500밀리초라고 보고합니다. 또한 일부 의사 결정 작업에서 프런티어 모델 구성과 비교해 대략 40배에서 200배의 속도 향상을 보였다고 보고합니다.

출시 시점에 TypeSafe는 Jev의 가격을 입력 토큰 100만 개당 $0.042로 제시하며, 현재 의사 결정 출력에는 별도의 요금이 부과되지 않습니다.

이 수치는 흥미롭지만, Jev가 일반적으로 “LLM보다 200배 빠르다”는 증거는 아닙니다.

TypeSafe의 자체 벤치마크 노트에 따르면, 가장 큰 워크플로 개선 효과는 사용자가 기대해야 할 범위의 상한선 부근에서 나타날 가능성이 높습니다. 또한 이 회사는 워크플로 평가가 내부적으로 설계되었으며 편향이 포함될 수 있음을 인정합니다.

에이전트가 작은 호출을 많이 수행할 때 중요한 경제성이 나타납니다.

분류
라우팅
관련성 확인
안전성 확인
결과 확인
재시도할지 결정

전문화된 의사 결정 계층이 이러한 단계의 대부분을 처리할 수 있다면, 더 높은 수준의 지능이 실제로 필요할 때만 비용이 많이 드는 추론 모델을 실행하면 됩니다.

Jev는 실제로 어디에 유용할까요?

이 작업들은 한 가지 공통점을 가집니다. 유효한 출력이 이미 알려져 있습니다.

답을 발견하거나 생성하는 것 자체가 작업이라면 Jev는 적합하지 않습니다. 코드 작성, 이메일 초안 작성, 논문 설명, 마이그레이션 계획 수립 또는 창의적인 응답 생성에는 여전히 생성형 모델이 필요합니다.

Jev가 LLM 라우터를 대체할 수 있을까요?

라우팅은 의사결정 우선 모델의 가장 명확한 활용 사례 중 하나입니다.

현재 많은 에이전트 시스템은 더 비싸거나 특화된 모델 앞에 더 작은 LLM을 배치합니다.

사용자
  ↓
라우터
  ↓
 ┌──────┬──────┬──────┐
 ↓      ↓      ↓      ↓
코드   웹   파일   채팅

Jev 방식의 라우터는 확률 및 에스컬레이션 계층을 추가합니다.

사용자 상태
    ↓
의사결정 모델
    ↓
라우팅 확률
    ↓
신뢰도 정책
   ↙             ↘
명확함             불확실함
 ↓                   ↓
도구 / 에이전트      더 큰 LLM

이를 통해 모든 라우팅 결정이 확실하다고 가장하지 않으면서 값비싼 모델 호출 횟수를 줄일 수 있습니다.

Jev가 없어도 동일한 아키텍처는 유용합니다. 규칙이나 소형 모델이 쉬운 결정을 처리하고, 대형 모델이 모호한 경우를 처리하도록 할 수 있습니다.

Jev를 로컬에서 실행할 수 있을까요?

현재는 공개된 Jev 모델을 통해 실행할 수 없습니다.

2026년 9월 현재 TypeSafe는 Jev를 호스팅형 얼리 액세스 서비스로 제공합니다. 공개 자료에는 다운로드 가능한 모델 가중치나 문서화된 셀프 호스팅 추론 경로가 나와 있지 않습니다.

이는 로컬 우선 AI에서 중요합니다.

로컬 파일
    ↓
Jev API
    ↓
의사결정
    ↓
로컬 에이전트

최종 에이전트가 로컬에서 실행되더라도 관련 상태가 Jev의 호스팅 서비스로 전송된다면 워크플로는 여전히 하이브리드입니다.

이는 개인 문서, 고객 기록, 이메일, 회사 지식 베이스, 홈 오토메이션 상태, 코드 또는 NAS 메타데이터에서 특히 중요합니다. 로컬 파일과 함께 클라우드 도구를 사용하는 워크플로는 로컬에서 호스팅되는 에이전트가 모든 데이터를 자동으로 비공개로 유지한다고 가정하지 말고, 어떤 컨텍스트가 네트워크 경계를 넘어가는지 명시적으로 제어해야 합니다.

TypeSafe는 데이터 처리 부록을 공개하고 있지만, 이는 추론을 전부 자체 네트워크 내부에서 실행하는 것과는 여전히 다른 개인정보 보호 모델입니다.

Jev와 유사한 의사결정 계층을 로컬에서 구축할 수 있을까요?

현재 공개 릴리스만으로는 Jev 자체를 셀프 호스팅할 수 없지만, 아키텍처 아이디어는 재현할 수 있습니다.

요청
   ↓
결정론적 규칙
   ↓
로컬 분류기
   ↓
소형 로컬 모델
   ↓
대형 로컬 모델
   ↓
사람

예를 들어 개인 문서 에이전트는 명확한 경우에 규칙을 사용하고, 알려진 범주에는 소형 로컬 분류기를 사용하며, 모호한 라우팅에는 소형 LLM을 사용하고, 어려운 추론에만 더 큰 모델을 사용할 수 있습니다.

NAS의 비공개 AI 어시스턴트는 파일, 검색, 메모리 및 경량 의사 결정 서비스를 데이터 가까이에 유지하면서 선택한 작업만 더 큰 컴퓨팅 리소스로 넘길 수 있습니다.

완전한 오프라인 운영이 중요하다면 모든 종속 요소도 로컬에 있어야 합니다. LAN에서 실행되는 모델만으로는 충분하지 않습니다. 라우팅, 임베딩, 인증 또는 필요한 다른 단계가 여전히 인터넷에 의존한다면 말입니다. 이는 인터넷 중단에도 견디는 AI 워크플로를 뒷받침하는 동일한 엔드투엔드 요구 사항입니다.

로컬 AI 에이전트의 미래에 대해 Jev가 알려 주는 것

Jev의 가장 중요한 아이디어는 Jev 자체보다 오래 살아남을 수 있습니다.

AI 시스템은 전문화되기 시작했습니다.

모든 단계를 하나의 거대 모델로 보내는 대신, 효율적인 로컬 또는 하이브리드 에이전트는 다음 요소를 결합할 수 있습니다.

의사 결정 모델
→ 라우팅, 분류 및 점수화

추론 모델
→ 어려운 문제 해결

생성형 모델
→ 텍스트, 코드 또는 미디어 생성

결정론적 소프트웨어
→ 승인된 작업 실행

로컬 저장소
→ 파일, 메모리 및 상태 보존

서로 다른 워크로드를 서로 다른 하드웨어에서, 서로 다른 개인정보 보호 규칙에 따라 실행할 수 있으므로 셀프 호스팅 인프라에 더 적합합니다.

이는 로컬 AI를 위한 유용한 원칙도 제시합니다.

일상적이고 비공개이며 빈번한 의사 결정은 데이터 가까이에서 처리하고, 더 큰 모델이나 클라우드 서비스가 실제로 필요한 작업만 상위 단계로 넘깁니다.

이 아키텍처는 모든 지능적 단계가 가장 강력한 모델과의 대화여야 한다고 가정하는 것보다 더 탄력적입니다.

Jev는 ChatGPT, Claude, Gemini 또는 로컬 LLM을 대체하나요?

아니요. Jev는 의도적으로 자유로운 언어 생성을 포기합니다.

글쓰기, 설명, 코딩, 종합, 브레인스토밍 또는 개방형 대화가 목적인 모델을 대체할 수는 없습니다.

Jev의 기회는 애플리케이션 로직과 생성형 AI 사이에 있습니다.

따라서 성숙한 에이전트는 여러 종류의 지능을 동시에 사용할 수 있습니다.

의사 결정 계층
→ 선택

추론 계층
→ 해결

생성 계층
→ 생성

정책 계층
→ 승인

도구 계층
→ 실행

Jev가 주는 더 큰 교훈은 채팅 모델이 쓸모없어졌다는 것이 아닙니다. 채팅이 원래부터 언어 생성 문제가 아니었던 많은 작업의 기본 인터페이스가 되었다는 것입니다.