한 글자도 쓸 줄 모르는 Jev, 왜 ChatGPT 이후 가장 인기 있는 모델이 되었을까?
핵심 관점
TypeSafe AI가 출시한 Jev는 무 텍스트 생성 능력을 가진 의미적 의사결정 모델로, 고빈도 확정적 판단을 전문으로 하며, 강한 유형 옵션과 신뢰 확률을 출력하고, 속도는 약 200배 빠르며, 비용은 약 400배 낮습니다.최근 이틀 동안 폭발적으로 인기를 끌고 있는 Jev는 대화나 코드 작성을 전혀 하지 않지만 많은 AI 의사결정 비용을 400배 줄일 수 있는 완전히 새로운 모델입니다.
하지만 많은 사람들은 Jev에 대해 여전히 혼란스러워합니다.
저는 자세히 연구해 보았고, 이 글이 여러분이 Jev를 완전히 이해하는 데 도움이 되기를 바랍니다. 오늘 Jev는 모든 직원이 사용할 수 있으니 실습해 보세요.
텍스트 버전을 보고 싶지 않다면, GLM-5.3 flash를 사용해 5분짜리 설명 영상을 만들었습니다. 효과가 꽤 좋으니 영상만 보시면 됩니다.
더 이상 말하지 않고 본론으로 들어가겠습니다.
Jev는 어떤 텍스트 생성 능력도 없습니다.
하지만 출시 이후, 그것이 일으킨 논의의 열기는 ChatGPT 이후 가장 높은 수준입니다.
지난 2년 동안, 사람들은 모든 요구 사항을 일반 대형 모델에 맡기는 것에 익숙해졌습니다.
하지만 실제 비즈니스에서는 소프트웨어 시스템이 매일 마주하는 많은 요청이 긴 글을 작성할 필요가 없습니다.
시스템이 실제로 필요한 것은 종종 아주 작은 확정적 판단입니다:
이 작업 요청은 긴급한가요?
이 명령은 어떤 하위 모델에 배포해야 하나요?
사용자가 입력한 터미널 명령에 데이터베이스 삭제 위험이 있나요?
방금 검색한 이 지식이 사용자 질문에 답할 수 있나요?
이런 판단을 내리기 위해 개발자는 대형 모델이 답변을 한 글자씩 생성하도록 해야 했고, 그 후 코드를 사용해 JSON을 파싱해야 했습니다. 형식 오류가 발생하면 다시 시도해야 했습니다.
이것은 속도가 느릴 뿐만 아니라 비용도 비쌌습니다.
TypeSafe AI가 출시한 Jev는 이러한 의사결정 요구를 해결하기 위해 특별히 설계되었습니다.
그들은 Jev를 "시스템 1 모델"이라고 부릅니다: 비구조화된 데이터를 입력하면 강력한 유형의 옵션과 정확한 신뢰 확률을 직접 출력합니다.
전통적인 대형 모델이 판단을 내리는 것이 왜 너무 무거운가요?
전형적인 에이전트(Agent) 루프에서 시스템은 매 단계마다 결정을 내려야 합니다:
python
while not done:
action = llm(context)
result = run_tool(action)
context += result
이 루프에서 모델은 도구를 선택하고, 실행 결과를 확인하며, 위험이 있는지 판단하고, 작업이 완료되었는지 결정해야 합니다.
최종 결정이 단어 하나, 예를 들어 "finance"일지라도, 전통적인 생성 모델은 하나의 토큰씩 출력합니다.
입력에 대해 비용을 지불해야 할 뿐만 아니라 생성 대기에도 비용이 발생합니다.
Jev의 핵심 논리는 매우 간단합니다:
코드가 모든 가능한 답변을 이미 알고 있을 때, 글자 단위로 텍스트 생성을 사용하는 것은 막대한 자원 낭비입니다.
Jev는 도대체 어떻게 작동하나요?
Jev의 본질은 의미적 의사결정 엔진입니다.
Jev를 호출할 때, 당신은 두 가지를 제공해야 합니다:
상태(State): 현재 상황을 설명하는 텍스트 또는 JSON.
질문(Questions): 이 상태를 기반으로 내리길 원하는 결정.
각 질문은 제출 전에 고정된 출력 유형을 가져야 합니다. Jev는 세 가지 기본 데이터 유형을 기본적으로 지원합니다:
선택(Choice): 정의한 목록에서 하나의 옵션을 선택하고 모든 옵션의 확률 분포를 반환합니다.
점수(Score): 입력을 정의한 순서 등급에 매핑합니다, 예를 들어 낮음, 중간, 높음.
불리언(Noul): 불리언 판단으로, 해당 명제가 참일 확률 값(0에서 1 사이의 소수)을 반환합니다.
전형적인 요청은 다음과 같습니다:
json
{
"model": "jev-latest",
"state": "배포가 두 번 실패했으며, 사용자 측에서 대량의 500 오류가 발생하고 있습니다.",
"questions": {
"urgent": {
"type": "noul",
"instructions": "이 문제는 즉시 처리해야 하나요?"
},
"owner": {
"type": "choice",
"instructions": "이 문제는 어떤 팀에 배정해야 하나요?",
"criteria": {
"engineering": "제품 결함 및 서비스 중단",
"billing": "요금, 청구서 및 환불 문제",
"sales": "가격 상담 및 신규 고객 계좌 개설"
}
}
}
}
Jev는 설명을 반환하는 것이 아니라 확정된 확률 값과 팀 확률 분포를 반환합니다.
여분의 말은 없으며, 존재하지 않는 네 번째 팀을 임의로 만들어내지 않습니다.
비즈니스 코드는 직접적으로 논리 제어를 담당합니다:
python
if urgent > 0.9 and owner == "engineering":
page_on_call()
elif confidence < 0.6:
send_to_human_review()
else:
add_to_queue(owner)
많은 엔지니어들은 이를 "의미 이해 능력을 가진 switch 문"이라고 묘사합니다.
비즈니스 분기는 여전히 전통적인 코드의 손에 확고히 잡혀 있으며, Jev는 코드 자체로는 계산할 수 없는 의미적 판단을 제공하는 역할만 합니다.
핵심 지표: 200배 빠르고, 400배 저렴함
Jev는 단일 요청에서 모든 질문을 병렬로 평가하는 것을 지원합니다.
이는 질문을 직렬로 할 필요가 없으며, 동일한 내용에 대한 모든 독립적인 판단을 한 번에 보낼 수 있음을 의미합니다.
공식 발표된 실측 데이터:
엔드 투 엔드 지연: 70에서 500 밀리초.
가격: 백만 개 입력 토큰당 단 0.042 달러, 출력 토큰은 완전히 무료입니다.
공식에서 제공한 여러 작업 흐름 실측 비교에서, Jev의 종합 실행 속도는 전통적인 대형 모델 작업 흐름의 약 200배이며, 종합 비용은 거의 400배 감소했습니다.
복잡한 비즈니스 환경에서도 이러한 데이터를 이론적 한계로 간주할 때, 그것이 가져오는 효율성 향상은 수치적 차원에서의 것입니다.
확률과 신뢰도, 그것이 핵심 설계
단일 분류 레이블만 주는 것은 종종 안전하지 않습니다.
Jev가 한 작업 요청이 "재무 팀"에 속한다고 판단할 경우, 반환 결과는 다음과 같습니다:
json
{
"choice": "billing",
"probabilities": {
"billing": 0.52,
"technical": 0.46,
"sales": 0.02
},
"confidence": 0.18
}
재무가 가장 높은 표를 얻었지만, 기술 지원이 46%의 확률을 얻었고, 전체 신뢰도는 0.18입니다.
시스템이 자동으로 할당하면 쉽게 오류가 발생할 수 있습니다.
이 확률 분포가 있으면 개발자는 코드에서 명확한 경계를 설정할 수 있습니다:
높은 신뢰도: 자동으로 소규모 위험 논리를 실행합니다.
중간 신뢰도: 더 강력한 대형 모델을 호출하여 재검토하거나 사용자에게 이중 확인을 요청합니다.
낮은 신뢰도: 직접 인력 검토 대기열로 전환합니다.
Jev는 "보정된 의사결정 기반 강화 학습(RLCD)" 훈련 방법을 사용합니다. 모델이 90%의 확률 판단을 내릴 때, 실제 정확도도 90% 근처로 높게 수렴할 수 있습니다.
반드시 명확히 해야 할 사실: Jev는 정말로 환각을 일으키지 않나요?
공식 홍보에서 "Jev는 환각을 생성하지 않는다"고 언급했습니다. 이 주장이 성립하기 위한 전제는 매우 엄격합니다.
Jev는 주어진 스키마 반환 형식 외의 내용을 절대 반환하지 않습니다. A, B, C 세 가지 옵션을 정의했다면, 절대 D를 반환하지 않으며, 잘못된 JSON을 출력하지도 않습니다.
하지만 이것은 그 판단이 항상 정확하다는 것을 의미하지 않습니다.
유형 안전성은 출력 구조가 무너지지 않도록 보장하지만, 비즈니스 판단이 오류를 범하지 않도록 보장하지는 않습니다.
유형 정의에 부합하는 잘못된 판단은 여전히 잘못된 환불이나 잘못된 장애 작업 요청을 발생시킬 수 있습니다.
정확한 이해는 다음과 같습니다: Jev는 코드 계약을 파괴하지 않도록 보장하지만, 여전히 잘못된 옵션을 선택할 확률이 있습니다.
Jev는 시스템의 어떤 위치에 가장 적합한가요?
Jev의 위치는 매우 명확합니다: 대형 모델과 함께 작동하도록 설계되었으며, 대형 모델을 대체할 의도가 없습니다.
대형 모델은 코드를 작성하고, 계획을 세우고, 긴 텍스트 추론 및 커뮤니케이션을 담당합니다.
Jev는 그 주위에서 고빈도, 빠른 경계 제어를 담당합니다.
현재 가장 성숙한 적용 사례는 세 가지입니다:
모델 라우팅(Model Routing)
사용자 요청에 직면했을 때, 먼저 Jev가 작업 난이도를 판단합니다. 간단한 검색 및 수정은 저렴한 소형 모델에 직접 배정하고, 고난이도의 아키텍처 설계는 비싼 추론 모델에 라우팅합니다.
도구 실행 리스크 관리(Tool Risk Gating)
에이전트가 터미널 명령을 호출하기 전에 Jev를 사용하여 명령이 읽기 전용인지, 되돌릴 수 있는지, 파괴적인지 판단합니다. 파괴적인 작업은 자동으로 일시 중지되고, 인가를 기다립니다.
결과 검증 및 감독(Verification)
작업이 끝나기 전에 Jev에게 빠르게 확인하게 합니다: 테스트 케이스가 통과했나요? 에이전트가 반복 호출의 무한 루프에 빠졌나요? 출력이 사전 설정된 규칙을 위반했나요?
언제 절대 Jev를 사용하지 말아야 할까요?
필요하지 않은 곳에서는 강제로 도입하지 마세요:
답변 공간이 불확실할 때 : 글을 쓰거나, 요약하거나, 코드를 생성해야 할 경우, 전통적인 대형 모델을 사용해야 합니다.
결정론적 논리 연산 : 수학 계산, 문자 수 세기, 날짜 비교는 순수 코드로 직접 구현해야 하며, 순수 코드는 항상 모델보다 더 저렴하고, 빠르며, 신뢰할 수 있습니다.
복잡한 긴 추론 체인이 필요할 때 : 다단계 논리 추론은 사고 체인 능력을 갖춘 추론 모델에 맡기거나, 큰 문제를 여러 개의 이산적인 작은 문제로 나누어 Jev에 맡겨야 합니다.
어떻게 시작하나요?
핵심 비즈니스를 바로 재구성하지 마세요.
가장 안전한 접근 방식은:
현재 유지 관리 비용이 가장 높고, 오류가 발생하기 쉬운 정규 규칙을 선택하거나, 대형 모델을 호출하여 단순한 참/거짓 판단을 얻는 노드를 선택합니다.
이 노드의 모든 가능한 옵션 정의를 명확히 작성합니다.
Shadow 모드(그림자 모드)를 활성화하여 Jev와 기존 논리가 병행 실행되도록 하여 데이터를 수집하고 신뢰도 임계값을 조정합니다.
정확도가 기준에 도달한 후, 공식적으로 트래픽을 전환합니다.
현재 TypeSafe는 완전히 접근이 가능하며, 대기 명단을 기다릴 필요가 없습니다. 등록 시 5달러의 크레딧이 제공되며, 이는 약 1.2억 개의 토큰 입력량을 직접 테스트할 수 있는 것과 같습니다.
지난 몇 년 동안 전체 산업은 모든 문제를 해결하기 위해 텍스트 생성을 사용하는 데 익숙해졌습니다.
하지만 많은 엔지니어링 시스템에서는 코드가 필요로 하는 것은 더 많은 아름다운 텍스트가 아니라, 밀리초 수준의 응답, 형식을 손상시키지 않으며, 비용이 극히 낮은 정확한 판단입니다.
이것이 Jev가 개발자 커뮤니티에서 빠르게 폭발적으로 인기를 끌 수 있었던 근본적인 이유입니다.
위험 경고
