blog

Jev를 이용하여 AI를 보다 똑똑하게 사용하자

NEXTREE.

• 26 min read
Jev를 이용하여 AI를 보다 똑똑하게 사용하자

서론: 우리는 LLM을 너무 많이 사용하고 있는 것은 아닐까요?

최근 몇 년간 AI 애플리케이션 개발은 사실상 LLM(Large Language Model)을 중심으로 이루어져 왔습니다. 사용자가 질문하면 LLM에게 보내고, 문서를 분석할 때도 LLM에게 보내고, 이메일을 분류할 때도 LLM에게 보내며, Agent가 다음 행동을 결정할 때도 다시 LLM에게 물어봅니다.

LLM은 매우 강력합니다. 자연어를 이해하고 글을 작성하며 코드를 생성하고, 복잡한 내용을 요약하고 추론할 수 있습니다. 문제는 우리가 LLM이 필요하지 않은 곳까지 LLM을 사용하고 있다는 점입니다.

예를 들어 고객으로부터 다음과 같은 이메일이 들어왔다고 생각해 보겠습니다.

"I was charged twice. Please refund the duplicate payment as soon as possible."

우리가 알고 싶은 것이 다음 세 가지뿐이라면 어떨까요?

  • 이 문의는 Billing인가 Technical Support인가?

  • 긴급한 문의인가?

  • 고객의 불만 정도는 어느 수준인가?

전통적인 LLM을 사용하면 다음과 같이 질문할 수 있습니다.

Analyze the following customer message.

1. Determine the category.
2. Determine whether it is urgent.
3. Evaluate the customer's frustration level.

Return the result as JSON.

LLM은 충분히 이 문제를 해결할 수 있습니다. 하지만 우리가 실제로 필요한 것은 긴 설명 문장이 아니라 다음과 같은 값입니다.

category = billing
urgent = 0.91
frustration = 1.7

즉, 생성(Generation)이 아니라 판단(Decision)이 필요합니다. 그런데 우리는 이 작은 판단을 위해 범용 생성 모델을 호출하고, 프롬프트를 작성하고, JSON 형식을 지시하고, 결과를 파싱하고, 스키마를 검증하고, 예외 상황까지 처리합니다.

TypeSafe AI가 2026년 9월 공개한 Jev는 바로 이 지점에서 출발한 모델입니다. TypeSafe는 Jev를 자사의 첫 번째 System One Model이라고 설명합니다. 자연어나 애플리케이션의 상태를 입력으로 받아 긴 문장을 생성하는 대신, 소프트웨어가 바로 사용할 수 있는 typed probabilistic decision, 즉 타입이 정해진 확률 기반 판단을 반환하는 모델입니다.

이 글에서 이야기하고 싶은 핵심은 단순합니다. LLM을 사용하지 말자는 것이 아니라, LLM이 필요하지 않은 판단까지 LLM에게 시키지 말자는 것입니다. 앞으로 AI 애플리케이션을 잘 만드는 개발자는 가장 강력한 모델을 사용하는 개발자가 아니라, 어떤 문제를 어떤 종류의 AI에게 맡겨야 하는지 구분할 수 있는 개발자가 될 가능성이 높습니다.

1. Jev란 무엇인가?

Jev는 TypeSafe AI가 공개한 첫 번째 System One Model입니다. TypeSafe는 System One이라는 이름을 Daniel Kahneman의 『Thinking, Fast and Slow』에서 설명하는 System 1의 개념에서 가져왔다고 설명합니다. 인간의 사고를 빠르고 직관적인 System 1과 느리고 숙고하는 System 2로 구분하는 아이디어에서 착안한 것입니다. Jev라는 이름 역시 경제학자 William Stanley Jevons에서 따왔다고 TypeSafe는 밝히고 있습니다.

일반적인 LLM을 매우 단순화하면 다음과 같이 표현할 수 있습니다.

Input
  ↓
LLM
  ↓
Text Generation
  ↓
"Based on the information provided,
 this customer seems to..."

반면 Jev는 다음에 더 가깝습니다.

State
  ↓
Jev
  ↓
Typed Decision
  ↓
billing : 0.97
urgent : 0.91

TypeSafe의 표현을 빌리면 Jev는 일종의 "frontier-intelligence function call"입니다. 즉 AI를 사람과 대화하는 상대라기보다 하나의 프로그래밍 primitive처럼 사용하자는 접근입니다.

unstructured state
        ↓
      Jev
        ↓
typed probabilistic decisions

이 차이는 생각보다 중요합니다. LLM의 최종 소비자는 보통 사람인 경우가 많지만, Jev의 결과를 소비하는 것은 주로 프로그램입니다.

LLM → Text → Human
Jev → Decision → Code

따라서 Jev의 목적은 멋진 문장을 생성하는 것이 아니라 프로그램이 다음 행동을 결정할 수 있도록 만드는 것입니다.

2. Jev가 제공하는 세 가지 판단

2.1 Choice

Choice는 여러 후보 가운데 하나를 선택합니다. 예를 들어 고객 문의를 다음과 같이 분류한다고 생각해 보겠습니다.

billing
technical
sales
other

Jev에게 "Which department should handle this request?"라고 질문하면 선택된 항목과 함께 각 선택지의 확률을 받을 수 있습니다.

choice = billing

billing 0.93
technical 0.04
sales 0.01
other 0.02

Choice는 문의 분류, 문서 분류, Agent Tool 선택, Model Routing, Intent Detection, 이벤트 Routing과 같은 문제에 특히 유용합니다.

2.2 Score

Score는 순서가 있는 몇 개의 기준을 정의하고 그 사이에서 점수를 계산합니다. 예를 들어 고객의 불만 정도를 다음과 같이 정의할 수 있습니다.

0 = Calm
1 = Frustrated
2 = Very Angry

그리고 "How frustrated is the customer?"라고 묻습니다. 결과가 반드시 0, 1, 2 중 하나일 필요는 없으며, 예를 들어 score = 1.63과 같이 중간값으로 표현될 수 있습니다.

따라서 Score는 긴급도, 위험도, 관련성, 품질, 우선순위, 고객 불만 수준, 문서 중요도와 같은 문제에 잘 맞습니다.

if score > 1.5
    → priority queue
else
    → normal queue

2.3 Noul

가장 생소한 용어가 Noul입니다. Noul은 오타가 아니라 TypeSafe가 실제 API에서 사용하는 primitive 이름입니다. 쉽게 말하면 Yes/No 성격의 질문에 대해 Yes일 확률을 반환하는 방식입니다.

Does this customer require an immediate response?

→ 0.92

단순한 Boolean보다 확률값이 유용한 이유는 애플리케이션 정책을 세밀하게 만들 수 있기 때문입니다.

0.90 이상      → 자동 처리
0.60 ~ 0.90   → 사람이 확인
0.60 미만      → 처리하지 않음

즉 AI가 모든 것을 결정하게 만드는 것이 아니라, AI는 확률을 제공하고 실제 정책은 코드가 결정합니다. 이 부분이 Jev를 개발자 관점에서 특히 흥미롭게 만드는 요소입니다.

3. 그렇다면 LLM과 Jev는 무엇이 다른가?

여기서 중요한 오해 하나를 먼저 정리해야 합니다. "LLM은 문자열만 반환하고 Jev만 구조화된 값을 반환한다"라고 단순화하면 정확하지 않습니다. 최근의 LLM은 Structured Output, JSON Schema, Function Calling, Tool Calling 등을 지원합니다. LLM을 이용해서 Choice와 같은 인터페이스를 만드는 것도 충분히 가능합니다.

차이는 모델의 목적과 구조에 있습니다. Jev는 처음부터 제한된 형태의 판단을 빠르게 반환하는 의사결정 primitive에 초점을 맞추고 있습니다.

구분

LLM

Jev

주목적

생성, 대화, 추론

판단

대표 출력

Text / Code / JSON

Choice / Score / Noul

출력 자유도

매우 높음

미리 정의된 범위

적합한 소비자

사람 + 프로그램

주로 프로그램

자유로운 문장 작성

매우 강함

부적합

분류/판단

가능

핵심 목적

결과 확률

별도 설계가 필요한 경우가 많음

모델 인터페이스의 핵심

Agent의 작은 의사결정

가능하지만 상대적으로 무거울 수 있음

매우 적합

창작/요약/코드 생성

적합

부적합

쉽게 표현하면 LLM은 무엇인가를 만들어 내는 AI이고, Jev는 무엇을 할지 판단하는 AI에 가깝습니다. 물론 실제 LLM의 역할은 이것보다 훨씬 넓지만, 애플리케이션 아키텍처를 설계할 때는 이 정도의 역할 구분만으로도 상당히 유용합니다.

4. Jev가 주목받는 가장 큰 이유 - 속도와 비용

AI 서비스를 운영하다 보면 처음에는 모델의 지능만 보게 됩니다. 그러나 서비스 규모가 커지면 Latency, Cost, Throughput, Reliability와 같은 운영 특성이 중요해집니다. 특히 Agent는 한 번의 사용자 요청을 처리하기 위해 AI를 여러 차례 호출할 수 있습니다.

현재 화면 분석
    ↓
어떤 행동을 할지 판단
    ↓
버튼 선택
    ↓
다음 화면 확인
    ↓
다음 행동 판단
    ↓
...

한 작업을 수행하기 위해 10번, 20번, 50번의 판단이 발생할 수 있습니다. 각 판단마다 고성능 LLM을 호출하면 Token Cost와 Latency가 누적됩니다.

TypeSafe가 2026년 9월 공개한 Jev의 가격은 당시 기준으로 입력 100만 토큰당 0.042달러이며 출력 토큰은 별도로 과금하지 않는 구조였습니다. 회사가 공개한 응답시간 범위는 약 70~500ms였습니다. 다만 이러한 수치는 환경, 입력 길이, 네트워크, workload에 따라 달라질 수 있으므로 모든 상황에서 동일한 성능이 나온다고 해석해서는 안 됩니다.

그래도 구조적인 차이는 분명합니다. 애플리케이션에 billing, 0.92, 1.71과 같은 값만 필요하다면 긴 설명을 생성하지 않는 모델이 더 자연스러운 선택일 수 있습니다. 필요하지 않은 출력을 만들지 않는 것 자체가 최적화입니다.

5. 실제로 Jev는 어디에 사용할 수 있을까?

Jev가 공개된 이후 이메일 분류, Browser Agent, 광고 분석, 논문 분류, 파일 자동 정리 등 다양한 실험이 등장했습니다. 아래의 비용과 속도는 각 데모 제작자가 자신의 환경에서 공개한 결과이므로, 동일한 조건에서 비교한 표준 benchmark로 받아들여서는 안 됩니다.

5.1 이메일 500개 자동 분류

공개된 한 데모에서는 500개의 이메일을 카테고리, 긴급도, 답장 필요 여부 등으로 분류했습니다. 제작자가 공개한 Jev 비용은 약 0.035달러였습니다.

Inbox
  ↓
Jev
  ├─ 중요?
  ├─ 답장 필요?
  ├─ 업무 관련?
  └─ 긴급?
  ↓
Priority Queue
  ↓
필요한 메일만 LLM에게 전달
  ↓
답장 초안 생성

이 구조의 핵심은 LLM을 제거하는 것이 아니라, LLM이 꼭 필요한 곳에서만 사용하도록 호출 횟수를 줄이는 것입니다.

5.2 Browser Agent

Browser Agent는 Jev의 특징을 이해하기 좋은 사례입니다. 공개 프로젝트에서는 웹페이지의 DOM을 분석하여 다음 행동을 Jev가 선택하도록 구성했습니다.

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

흥미로운 점은 텍스트를 실제로 생성해야 하는 TYPE_TEXT 상황에서만 LLM을 사용하는 방식입니다.

Decision        → Jev
Text Generation → LLM
Browser Operation→ Code

공개된 취리히에서 런던으로 가는 Google Flights 검색 데모에서는 전체 실행시간 약 7.1초, Jev 비용 약 0.0039달러가 표시되었습니다. 이 사례는 Agent 전체가 하나의 거대한 LLM일 필요가 없다는 점을 잘 보여줍니다.

5.3 광고 724개 분석

또 다른 공개 데모에서는 37개 브랜드의 724개 광고를 Hook, Format, Offer, CTA, Awareness Stage 등의 기준으로 분석했습니다. 제작자가 공개한 결과는 약 40초, Jev 비용 약 0.09달러였습니다.

AI 판단의 단가가 충분히 낮아지면 일부 샘플만 보는 방식에서 가능한 모든 데이터를 분석하는 방식으로 업무 패턴이 바뀔 수 있습니다. 이는 단순한 비용 절감보다 더 중요한 변화입니다. 이전에는 비용 때문에 시도하지 않았던 문제를 풀 수 있게 되기 때문입니다.

5.4 AI 논문 1,018개 분류

1,018개의 AI 관련 논문을 24개 주제로 분류한 공개 사례도 있습니다. 이 사례에서는 논문 요약은 LLM이 담당하고, 정해진 taxonomy에 따라 분류하는 일은 Jev가 담당했습니다.

Paper
   ↓
LLM
   ↓
Summary
   ↓
Jev
   ↓
24개 Topic 중 하나 선택

제작자가 공개한 Jev 분류 비용은 약 0.08달러였으며 median latency는 논문당 약 256ms였습니다. 다만 전체 파이프라인에는 별도의 LLM 요약 비용이 존재했습니다. 이 사례가 보여주는 핵심은 모든 AI 문제를 하나의 모델로 해결할 필요가 없다는 점입니다.

6. Jev를 코드에서 사용해 보자

TypeSafe는 Python SDK와 JavaScript/TypeScript SDK를 공개하고 있습니다. Python SDK의 패키지 이름은 typesafe-sdk이며, 공식 예제는 state와 questions를 system_one()에 전달하는 구조입니다.

uv add typesafe-sdk

export TYPESAFE_API_KEY="..."

아래는 고객 문의를 분류하고 긴급도와 불만 수준을 판단하는 예시입니다.

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

state = {
    "message": "I was charged twice. "
               "Please refund the duplicate payment today."
}

questions = {
    "category": Choice(
        instructions="What is this customer request about?",
        criteria={
            "billing": "Payment, refund or charge related issue",
            "technical": "Technical problem",
            "sales": "Sales or pricing inquiry",
            "other": "Anything else"
        }
    ),

    "urgent": Noul(
        instructions="Does this request require urgent attention?"
    ),

    "frustration": Score(
        instructions="How frustrated does the customer appear?",
        criteria=["Calm", "Frustrated", "Very angry"]
    )
}

with TypeSafeClient() as client:
    response = client.system_one(
        state=state,
        questions=questions
    )

category = response.choices["category"].choice
urgent = response.nouls["urgent"].noul
frustration = response.scores["frustration"].score

개념적으로 category = billing, urgent = 0.94, frustration = 1.32와 같은 결과가 나왔다고 가정하면, 그다음부터는 평범한 프로그램 코드로 정책을 적용하면 됩니다.

if urgent > 0.90:
    priority = "HIGH"
elif urgent > 0.60:
    priority = "MEDIUM"
else:
    priority = "NORMAL"

여기에서 중요한 점은 Jev가 비즈니스 정책까지 결정하게 하지 않는 것입니다. Jev는 판단에 필요한 신호를 제공하고, 실제 정책은 코드가 담당합니다.

AI   → Probability
Code → Business Rule

7. TypeScript에서는 더 명확하게 보인다

TypeScript SDK에서는 질문의 타입에 따라 반환 결과의 형태도 명확하게 구분할 수 있습니다. 예시는 다음과 같습니다.

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

const client = new TypeSafeClient();

const result = await client.systemOne({
  state: {
    message: "I was charged twice. " +
             "Please refund the duplicate payment today."
  },
  questions: {
    category: choice(
      "Which department should handle this?",
      {
        billing: "Payment and refund issues",
        technical: "Product or technical issues",
        sales: "Pricing and sales",
        other: "Anything else"
      }
    ),
    urgent: noul(
      "Does this request need urgent attention?"
    ),
    frustration: score(
      "How frustrated is the customer?",
      ["Calm", "Frustrated", "Very angry"]
    )
  }
});

개발자 입장에서 보면 String Prompt → AI → String Response → Parsing → Validation → Application 구조보다, Typed Question → Jev → Typed Decision → Application 구조가 훨씬 자연스럽게 느껴질 수 있습니다.

8. Java 개발자는 어떻게 사용할까?

현재 TypeSafe가 공식적으로 공개한 대표 SDK는 Python과 JavaScript/TypeScript이며, Java 쪽에는 community SDK와 Spring AI 연동 프로젝트가 등장하고 있습니다. 그러나 Jev API 자체는 REST 방식이므로 Java에서 반드시 별도 SDK가 필요한 것은 아닙니다.

핵심 API는 POST /v1/systemone 형태이며, 요청에는 model, state, questions가 포함됩니다. Java 개발자라면 HttpClient, Jackson, Spring RestClient 또는 WebClient 등으로 쉽게 wrapping할 수 있습니다.

interface DecisionService {
    TicketDecision classify(CustomerMessage message);
}

record TicketDecision(
        String category,
        double urgentProbability,
        double frustrationScore
) {}

애플리케이션 코드에 Jev API 호출이 직접 퍼지게 하기보다 위와 같이 abstraction을 두면, 뒤에서 Jev를 사용하는지 다른 Decision Model을 사용하는지 애플리케이션이 알 필요가 없습니다. 향후 모델이나 provider를 교체할 때도 유리합니다.

9. Jev를 가장 잘 사용하는 방법 - LLM을 없애려고 하지 마라

Jev와 LLM은 경쟁 관계라기보다 역할이 다릅니다. 예를 들어 고객의 불만에 공감하면서 정중한 환불 안내 메일을 작성하는 일은 문장을 생성해야 하므로 LLM이 적합합니다. 반면 "이 고객에게 답장이 필요한가?", "이 문의를 어느 팀으로 보내야 하는가?"와 같은 질문은 Jev에 더 잘 맞습니다.

Decision   → Jev
Generation → LLM
Execution  → Code
Review     → Human

이 조합이 Jev를 가장 흥미롭게 만드는 부분입니다. 각 도구가 자신이 가장 잘하는 역할을 담당하도록 하는 것입니다.

10. Multi-Agent 시대에는 Model Routing이 더 중요해진다

앞으로 Agent 시스템은 점점 복잡해질 것입니다. 하나의 Agent가 모든 일을 하는 대신 여러 Tool과 Model을 조합하게 될 가능성이 높습니다.

User Request
     ↓
Jev
     ↓
Task Complexity
     │
     ├── Simple → Small Model
     ├── Medium → General LLM
     └── Complex → Frontier Model

모든 질문을 가장 비싸고 강력한 모델에게 보낼 필요는 없습니다. 오히려 AI 시스템 자체가 "이 문제는 어려운가?", "검색이 필요한가?", "Human approval이 필요한가?", "고성능 모델까지 보낼 필요가 있는가?"를 먼저 판단하도록 설계할 수 있습니다.

과거 개발자가 Class, Method, Database, API, Transaction, Event를 설계했다면, AI 시대에는 Decision Architecture도 함께 설계해야 합니다. 즉 어떤 판단을 코드가 하고, 어떤 판단을 Jev가 하고, 어떤 판단을 LLM이 하고, 어떤 판단을 사람이 해야 하는지를 구분하는 능력이 중요해집니다.

11. AI를 거대한 함수 하나로 만들지 말자

LLM을 사용할 때 흔히 발생하는 설계는 하나의 거대한 prompt에 분류, 판단, routing, 생성까지 모두 넣는 방식입니다. 처음에는 편하지만 시스템이 복잡해질수록 어디에서 잘못되었는지 확인하기 어렵고, 정책 수정과 테스트도 어려워집니다.

isSpam()
    ↓
category()
    ↓
urgency()
    ↓
needsReply()
    ↓
route()
    ↓
generateReply()

앞의 판단 단계는 Jev가 담당하고, route()는 코드가 담당하며, 마지막 generateReply()만 LLM이 담당하도록 분리할 수 있습니다. 이 구조의 장점은 단순히 싸고 빠르다는 것만이 아니라 디버깅과 테스트가 쉬워진다는 점입니다.

12. 하지만 Jev도 틀릴 수 있다

Jev가 typed output을 제공한다고 해서 판단 자체가 항상 정확하다는 의미는 아닙니다. 예를 들어 "이 이메일이 사기 메일인가?"라는 질문에 대해 응답 형식이 올바르게 반환되는 것과 실제 사기 여부를 정확하게 판별하는 것은 전혀 다른 문제입니다.

Schema correctness ≠ Semantic correctness

따라서 확률값을 애플리케이션 정책에 포함하는 것이 중요합니다.

High Confidence   → Automatic Action
Medium Confidence → Strong LLM / Additional Check
Low Confidence    → Human Review

확률을 제공하는 모델의 진짜 장점은 AI가 자신 있게 답한다는 데 있는 것이 아니라, 소프트웨어가 불확실성을 정책에 포함할 수 있다는 데 있습니다.

13. Jev를 사용하지 말아야 할 곳

Jev가 주목받는다고 해서 모든 곳에 넣는 것도 좋은 설계는 아닙니다. 보고서·이메일·블로그와 같은 문서 작성, 긴 문서 요약, 코드 생성, 오류 원인 설명, 복잡하고 열린 전략 문제에는 LLM이 훨씬 적합합니다.

반대로 A인가 B인가, 어느 Category인가, 얼마나 중요한가, 어느 Tool을 실행해야 하는가, 어느 Model에게 전달해야 하는가, 사람의 확인이 필요한가처럼 답의 범위가 어느 정도 제한되어 있는 문제라면 Jev를 검토할 가치가 높습니다.

14. 개발자의 관점에서 바라본 Jev의 가장 큰 가치

Jev가 흥미로운 이유를 단순히 낮은 토큰 가격으로만 바라보면 본질을 놓칠 수 있습니다. 더 중요한 변화는 AI가 프로그램 안으로 들어오는 방식입니다.

기존 방식
Application → Prompt → LLM → Text

Decision Model 방식
Application State → Decision Primitive → Probability → Application Logic

개발자에게 후자의 구조는 익숙합니다. 우리는 이미 수십 년간 if (condition) { execute(); }와 같은 코드를 작성해 왔습니다. Jev는 지금까지 코드로 표현하기 어려웠던 fuzzy condition을 프로그램 안으로 가져오는 도구로 볼 수 있습니다.

if (jev("Is this request urgent?") > 0.9) {
    escalate();
}

15. "AI를 잘 사용한다"는 의미도 바뀌고 있다

지금까지 AI를 잘 사용하는 사람이라고 하면 Prompt Engineering을 잘하는 사람을 떠올리는 경우가 많았습니다. 그러나 Agent와 AI Automation이 늘어날수록 중요한 능력도 달라질 가능성이 높습니다.

  • 이 문제는 deterministic code로 해결 가능한가?

  • AI 판단이 정말 필요한가?

  • AI가 필요하다면 생성인가 판단인가?

  • 작은 모델이면 충분한가?

  • Frontier Model이 필요한가?

  • 확률이 낮으면 누구에게 escalation할 것인가?

  • 어떤 판단은 반드시 사람이 확인해야 하는가?

즉 모델 하나를 잘 사용하는 것보다 AI 전체의 orchestration을 잘 설계하는 것이 중요해집니다.

16. 권장하는 AI Architecture

이를 하나의 간단한 원칙으로 정리하면 다음과 같습니다.

LLM   → 생성합니다.
Jev   → 판단합니다.
Code  → 실행합니다.
Human → 중요한 결정을 검토합니다.

이 구조에서는 특정 모델이 시스템 전체를 지배하지 않습니다. 각 도구가 자신이 가장 잘하는 일을 담당합니다.

결론: 가장 강력한 AI가 아니라 가장 적절한 AI를 사용하자

Jev는 아직 매우 새로운 기술입니다. TypeSafe가 Jev를 공개한 것은 2026년 9월이며, 생태계와 API, tooling도 빠르게 변하고 있습니다. 따라서 현재의 가격이나 성능, SDK 상태가 장기간 그대로 유지된다고 가정해서는 안 됩니다.

그럼에도 Jev가 던지는 질문은 상당히 중요합니다. 왜 우리는 모든 AI 문제를 LLM 하나로 해결하려고 할까요?

LLM은 놀라운 도구입니다. 하지만 이메일 하나를 어느 폴더로 보낼지 판단하기 위해 긴 문장을 생성할 필요는 없습니다. Agent가 다음에 어느 버튼을 클릭할지 결정하기 위해 매번 거대한 Frontier Model의 긴 추론을 기다릴 필요도 없습니다.

정해진 후보 중 하나를 선택하면 되는 문제라면 Choice를 사용할 수 있습니다. 예/아니오 성격의 판단이 필요하다면 Noul을 사용할 수 있고, 정도의 차이를 판단해야 한다면 Score를 사용할 수 있습니다. 그리고 정말로 글을 쓰거나 코드를 만들거나 복잡한 문제를 해결해야 할 때는 LLM을 사용하면 됩니다.

Generation → LLM
Decision   → Jev
Execution  → Code
Review     → Human

AI를 똑똑하게 사용한다는 것은 항상 가장 똑똑한 모델을 호출하는 것이 아닙니다. 필요한 문제에 필요한 만큼의 Intelligence만 사용하는 것이 더 중요한 설계 원칙이 될 수 있습니다.

수많은 작은 판단은 빠르고 저렴한 Decision Model에게 맡기고, 정말 어려운 문제에만 강력한 LLM을 사용하는 방식은 Multi-Agent와 AI Orchestration 환경에서 특히 의미가 있습니다.

앞으로 개발자에게 필요한 질문은 "어떤 AI가 가장 좋은가?"가 아니라 "이 판단을 어떤 AI에게 맡기는 것이 가장 좋은가?"일지도 모릅니다. Jev의 등장은 바로 그 질문을 우리에게 던지고 있습니다.

참고문헌

1. TypeSafe AI, "Introducing System One Models & Jev", 2026-09-15. https://typesafe.ai/blog/introducing-system-one-models-and-jev

2. TypeSafe AI Official Website / Jev. https://typesafe.ai/

3. TypeSafe API Reference. https://api.typesafe.ai/docs

4. TypeSafe AI Python SDK. https://github.com/typesafe-ai/typesafe-sdk-python

5. TypeSafe AI JavaScript/TypeScript SDK. https://github.com/typesafe-ai/typesafe-sdk-js

6. TypeSafe Workflow Evals. https://evals.typesafe.ai/

7. Browser Use, jev-ultrafast. https://github.com/browser-use/jev-ultrafast

8. Community Jev Email Classification Demo. https://madewithjev.com/categories/triage-and-routing

9. 1k Papers / Jev Classification Demo. https://jev.gorock.sh/projects/1k-papers

10. 724 Ads Jev Demo. https://systemonemodels.org/examples/discussions/breaking-down-724-ads-from-37-brands-with-jev/

11. Spring AI Community, TypeSafe/Jev integration project. https://github.com/spring-ai-community/spring-ai-typesafe

※ 본문의 가격, latency 및 API 내용은 2026년 9월 24일 기준 공개 자료를 바탕으로 정리한 내용입니다. Jev는 공개된 지 오래되지 않은 서비스이므로 실제 도입 시에는 TypeSafe의 최신 공식 문서, 가격 정책 및 모델 버전을 다시 확인하는 것이 좋습니다.

syhan

Site footer