← 목록으로 돌아가기
AI & EXPERIMENT
2026-09-2226분 읽기 • 👀 14

Jev란? 193배 빠르고 444배 싸다는 판단형 AI의 원리와 활용 사례

공유하기

최근 Jev라는 조금 독특한 AI가 공개됐다.

ChatGPT처럼 글을 잘 쓰는 AI가 아니다.

오히려 문장을 만들지 않는다.

대신 정해진 선택지에서 답을 고르고, 점수와 확률을 돌려준다.

그런데 Jev를 만든 TypeSafe는 자체 업무 평가에서 기존 비교 모델보다 최대 193.6배 빠르고 444.6배 저렴했다고 발표했다.

말을 하지 않는데 왜 더 쓸모가 있을까?

Jev를 이해하려면 먼저 우리가 AI를 사용하는 방법부터 생각해볼 필요가 있다.

Jev란? 193배 빠르고 444배 싸다는 판단형 AI의 원리와 활용 사례 이미지 1

대화는 이렇게 잘하는데, 자동화는 왜 어려울까?

Jev를 만든 TypeSafe의 창업자 Diogo Almeida는 OpenAI에서 언어 모델이 사람의 지시를 따르고 대화하도록 만드는 연구에 참여했던 인물이다.

TypeSafe는 그를 InstructGPT와 RLHF 연구에 참여했던 연구자로 소개하고 있다.

그가 지난 몇 년 동안 품었다는 질문은 단순하다.

“AI는 이렇게 대화를 잘하는데, 자동화는 어디에 있는가?”

지금의 LLM은 사람과 이야기하기에 좋다.

설명하고, 요약하고, 글을 쓰고, 코드를 만든다.

그런데 소프트웨어가 원하는 답은 조금 다를 때가 많다.

YES인가 NO인가.

A인가 B인가 C인가.

위험도가 높은가 낮은가.

확률이 30%인가 95%인가.

사람에게는 문장이 편하지만,

프로그램에는 판단이 편하다.

Jev는 바로 이 지점을 노린다.

Jev는 어떤 AI인가?

TypeSafe는 Jev를 첫 번째 공개 System One Model이라고 부른다.

이름은 대니얼 카너먼의 《생각에 관한 생각》에 등장하는 빠르고 직관적인 사고 방식인 System 1에서 가져왔다.

기존 LLM이 자유롭게 문자열을 생성한다면 Jev는 미리 정해진 형태의 답을 반환한다.

TypeSafe의 업무 평가에서는 크게 세 가지 판단 방식을 사용한다.

Noul — Yes / No 판단

Choice — 여러 선택지 중 하나를 선택

Score — 일정 범위 안에서 점수를 반환

예를 들어 고객 문의가 들어왔다고 해보자.

“이 문의는 어느 팀으로 보내야 하는가?”

일반적인 LLM은 이런 식으로 답할 수 있다.

“고객의 내용을 분석해보면 환불을 요청하는 것으로 판단되므로 환불 담당 부서에 전달하는 것이 좋겠습니다.”

Jev가 필요한 곳에서는 이런 긴 문장이 필요하지 않다.

환불 92%

결제 5%

기술지원 2%

기타 1%

프로그램은 이 값을 받아 바로 다음 행동을 결정하면 된다.

TypeSafe는 이를 “Decisions, not strings”라고 표현한다.

문장이 아니라 소프트웨어가 바로 사용할 수 있는 판단을 만드는 것이다.

193배 빠르고 444배 싸다?

Jev가 관심을 받은 가장 큰 이유 중 하나는 속도와 가격이다.

TypeSafe는 자체 System One 업무 평가에서 Jev가 비교 모델보다 최대 193.6배 빠르고 444.6배 저렴한 결과를 기록했다고 공개했다.

회사에서 제시하는 응답 시간은 약 70ms~500ms다.

가격은 입력 10억 토큰당 42달러, 즉 100만 입력 토큰당 약 0.042달러이며 출력 토큰에는 별도 비용을 받지 않는다고 설명한다.

이유는 구조에 있다.

기존 LLM은 단어와 문장을 토큰 단위로 하나씩 이어서 생성한다.

반면 Jev는 자유로운 문장을 만드는 대신 정해진 판단을 병렬로 계산하는 데 집중한다.

다만 숫자는 조금 조심해서 봐야 한다.

193.6배와 444.6배는 TypeSafe가 만든 특정 업무 평가에서 나온 최대 수준의 결과다.

회사 역시 이 수치가 실제 환경에서 기대할 수 있는 개선폭 중 높은 편이라고 설명한다.

그래서 더 중요한 질문은 따로 있다.

AI 판단이 충분히 싸고 빨라지면 무엇을 할 수 있을까?

모든 일을 가장 큰 AI에게 맡길 필요는 없다

지금은 하나의 큰 LLM에게 일을 통째로 맡기는 경우가 많다.

“이 고객의 상황을 분석하고 어떤 조치를 해야 하는지 판단해줘.”

Jev가 제안하는 방식은 조금 다르다.

큰 문제를 작은 판단으로 나눈다.

고객이 환불을 원하는가?

긴급한 문제인가?

결제 문제인가?

사람이 확인해야 하는가?

그리고 날짜, 금액, 수량 비교처럼 코드가 확실하게 처리할 수 있는 것은 그냥 코드가 처리한다.

코드가 할 수 있는 것은 코드가 한다.
판단이 필요한 부분만 AI에게 맡긴다.

여기에 confidence를 이용하면 더 재미있는 구조를 만들 수 있다.

90% 이상 확신 → 자동 처리

60~90% → 큰 LLM에게 재판단

60% 미만 → 사람에게 전달

물론 이 숫자는 설명을 위한 예시다.

100만 원짜리 환불과 뉴스레터 분류에 같은 기준을 사용할 수는 없다.

업무의 위험도와 틀렸을 때 발생하는 비용에 따라 기준을 다르게 설정해야 한다.

핵심은 하나다.

모든 판단을 비싼 AI나 사람에게 맡길 필요는 없다.

Jev는 어디에 사용할 수 있을까?

1. 고객 문의 자동 분류

상황

고객이 메시지를 보낸다.

“지난주 결제한 상품을 취소하고 싶은데 어떻게 해야 하나요?”

Jev

어느 팀이 처리해야 하는지 빠르게 분류한다.

환불 96%
결제 2%
기술지원 1%
영업 1%

96% → 자동 처리

환불팀으로 바로 보낸다.

72% → 큰 LLM

전체 대화, 구매 내역, 계정 상태를 함께 보고 다시 판단한다.

계속 애매함 → 사람

예외 정책이나 고객 보상이 필요한 경우 상담원이 확인한다.

Jev → 큰 LLM → 상담원

TypeSafe가 공개한 Customer Service 평가도 고객과의 대화, 계정 정보, 결제와 환불 상태 등을 보고 다음 행동을 결정하는 방식으로 구성돼 있다.

2. 영업 리드 분류

상황

홈페이지에 제품 문의가 들어온다.

직원 2명인 회사의 가격 문의와 직원 3,000명인 기업의 전사 도입 문의는 대응 방법이 달라야 한다.

Jev

구매 가능성이 높은 고객인가?
Enterprise 영업에게 전달해야 하는가?
지금 바로 연락해야 하는가?

95% → 자동 처리

담당 영업에게 즉시 배정한다.

75% → 큰 LLM

회사 규모, 업종, 문의 내용, 과거 활동을 함께 분석한다.

정보가 부족함 → 사람

전략적으로 중요한 고객이라면 영업 담당자가 직접 확인한다.

Jev → 큰 LLM → 영업 담당자

문의가 하루 10건이라면 굳이 이런 시스템이 필요하지 않을 수 있다.

하지만 하루 10만 건이라면 이야기가 달라진다.

3. 인보이스와 비용 처리

상황

회사에 인보이스가 들어온다.

Jev

주문 내역과 일치하는가?
실제 물품이 납품됐는가?
중복 지급 가능성이 있는가?
거래처에 문제가 있는가?

금액 계산과 날짜 비교처럼 정확한 것은 코드가 처리한다.

정상 비용 98% → 자동 승인

정상 비용 78% → 큰 LLM

회사 규정과 거래 내역을 추가로 분석한다.

정상 비용 45% → 사람

회계 담당자가 직접 확인한다.

Jev → 큰 LLM → 회계 담당자

TypeSafe가 공개한 Invoice Processing 평가 역시 인보이스, 주문 내용, 실제 납품 정보를 보고 지급·보류·반려를 결정하는 구조다.

4. AI Agent의 행동을 검증한다

상황

AI Agent가 실제 행동을 실행한다.

이메일을 보낸다.
고객에게 환불한다.
데이터를 수정한다.
파일을 삭제한다.
외부 API를 호출한다.

Jev

“이 행동을 실행해도 안전한가?”

97% 안전 → 자동 실행

74% 안전 → 큰 LLM

사용자의 요청, 이전 대화, Agent의 행동과 시스템 정책을 함께 검토한다.

42% 안전 → 사람

실행을 멈추고 관리자에게 승인을 요청한다.

Jev → 큰 LLM → 관리자

AI가 다른 AI를 검사하는 구조다.

TypeSafe 역시 Jev의 활용 사례로 LLM의 프롬프트와 출력 등을 score, judge, verify, guardrail하는 방식을 제시한다.

5. 보안 경보 분류

상황

기업의 보안 시스템에서 하루에도 수천 건의 경보가 발생한다.

모든 경보가 실제 공격은 아니다.

Jev

정상적인 활동인가?
보안 분석가에게 전달해야 하는가?
즉시 장비를 격리해야 하는가?

정상 활동 99% → 자동 종료

의심 활동 73% → 큰 LLM

로그와 과거 사건, 사용자 활동을 추가로 분석한다.

위험성이 높거나 애매함 → 사람

보안 담당자에게 즉시 전달한다.

Jev → 큰 LLM → 보안 담당자

TypeSafe의 공식 평가에도 Security Incidents 사례가 포함돼 있다.

사람이 1만 건의 경보를 모두 보는 것이 아니라 정말 중요한 경보만 사람이 보는 구조다.

AI의 역할이 층으로 나뉠 수 있다

이런 사례를 보다 보면 앞으로 AI를 선택하는 기준도 조금 달라질 것 같다.

지금까지는 주로

“어떤 AI 모델이 가장 똑똑한가?”

를 물었다.

앞으로는 오히려

“이 일을 처리하는 데 어느 정도의 지능이 필요한가?”

를 물어야 할 수도 있다.

1단계 — Jev

빠르고 저렴한 반복 판단

2단계 — 큰 LLM

넓은 문맥과 복잡한 추론이 필요한 판단

3단계 — 사람

돈, 안전, 법적 책임처럼 틀렸을 때 비용이 큰 판단

AI가 사람을 모두 대체하는 구조와는 조금 다르다.

사람이 꼭 봐야 하는 문제만 사람에게 보내는 구조에 가깝다.

토큰 가격보다 판단 비용을 봐야 할 수도 있다

지금까지 AI 비용을 비교할 때 가장 많이 보는 숫자는 토큰 가격이었다.

입력 100만 토큰에 얼마.

출력 100만 토큰에 얼마.

물론 중요하다.

하지만 실제 서비스를 운영하면 다른 질문이 더 중요해질 수 있다.

고객 한 명을 분류하는 데 얼마가 드는가.

거래 하나의 위험도를 판단하는 데 얼마가 드는가.

Agent의 행동 하나를 검증하는 데 얼마가 드는가.

서비스가 원하는 것은 결국 토큰이 아니다.

판단이다.

물론 Jev도 잘못 판단할 수 있다.

TypeSafe가 강조하는 type-safe output은 정해진 스키마 밖의 엉뚱한 형식을 반환하지 않는다는 의미이지, 모든 판단이 항상 정확하다는 뜻은 아니다.

그래서 확률과 confidence가 중요하다.

확실한 것은 자동화하고, 애매한 것은 더 큰 모델에게 보내고, 중요한 문제는 사람이 확인한다.

싼 판단은 작은 모델이 하고,
애매한 판단은 큰 모델이 하고,
중요한 판단은 사람이 한다.

AI 비용을 보는 기준도 그에 따라 바뀔 수 있다.

“100만 토큰에 얼마인가?”

에서

“좋은 판단 하나를 얻는 데 얼마가 드는가?”

로.

Jev에서 가장 흥미로운 부분은 단순히 새로운 AI 모델 하나가 등장했다는 사실이 아닐지도 모른다.

AI를 어디에, 어떤 비용으로, 어느 수준까지 맡길 것인가.

그 질문에 대한 새로운 방식이 등장하고 있다.

참고 자료

TypeSafe Docs — Introduction

TypeSafe — Introducing System One Models & Jev

TypeSafe — Workflow Evals

#Jev#TypeSafeAI#SystemOneModel#AI자동화#AI비용#AI에이전트#LLM#업무자동화

첫 번째로 도움이 되었어요를 눌러보세요

댓글 (0)

    든든한 실무 조력자가 필요하신가요?

    당장 실행에 옮길 믿음직한 손길이 부족하시다면 연락주세요.

    협업 제안하기
    다른 글 읽어보기
    [에세이] 거절 없는 사업을 의심하라

    [에세이] 거절 없는 사업을 의심하라

    21시간 전1210
    MANAGEMENT
    좋은 팀장이 되는 법 — 팀원의 성과와 성장을 만드는 5가지 역할

    좋은 팀장이 되는 법 — 팀원의 성과와 성장을 만드는 5가지 역할

    4일 전1920
    MANAGEMENT
    일 잘하는 사람의 업무 커뮤니케이션 3가지 — 명확한 지시, 두괄식, 피드백

    일 잘하는 사람의 업무 커뮤니케이션 3가지 — 명확한 지시, 두괄식, 피드백

    4일 전18100
    MANAGEMENT
    거절도 불만도 없다면, 너무 안전하게 사업하고 있는 건 아닐까?

    거절도 불만도 없다면, 너무 안전하게 사업하고 있는 건 아닐까?

    4일 전730
    MANAGEMENT