Jev가 보여준 AI의 분업: 길게 생각할 일과 빠르게 판단할 일

고객이 “결제가 두 번 됐습니다”라고 문의했습니다. 이 문의를 결제 담당 부서로 보낼지, 배송 담당 부서로 보낼지 결정하는 데 긴 보고서는 필요하지 않습니다. 웹사이트에서 다음 페이지 버튼을 고르는 일도 비슷합니다. 기계가 원하는 것은 설명문보다 다음에 실행할 선택입니다.

9월 중순 공개된 TypeSafe AI의 Jev는 이런 작은 판단을 독립된 AI 제품으로 만들었습니다. 상황과 질문, 허용된 답을 주면 문장을 길게 생성하지 않고 선택·점수·확률을 반환합니다. 사람과 대화하는 창보다 소프트웨어 안에서 반복 호출되는 부품에 가깝습니다.2

중요한 변화는 모든 지적 작업을 한 모델에 맡기지 않아도 된다는 점입니다. 큰 언어모델은 목표를 해석하고 새로운 대안을 만들고, 판단 모델은 좁고 반복적인 선택을 처리하는 방식입니다. 다만 빠른 판단은 올바른 판단과 다르고, 출력 형식의 보장은 무오류의 보장이 아닙니다.

자료 기준일은 2026년 9월 19일입니다. 공개일 표기는 TypeSafe 발표문에 9월 14일, Vercel 소개에 9월 15일로 나타납니다. 어느 쪽이든 9월 18일 최초 공개로 쓰기는 어렵습니다. 아래 성능 수치는 회사·개발자의 공개 기록이며 이 글에서 직접 재현한 결과가 아닙니다.111

문장을 만들지 않고, 프로그램이 쓸 답을 돌려줍니다

Jev의 입력은 딱딱한 숫자표에 한정되지 않습니다. 고객 문의, 웹페이지에서 읽은 정보처럼 정리되지 않은 글도 상황으로 넣을 수 있습니다. 대신 출력으로 허용할 답을 미리 정의합니다.2

질문 방식	쉬운 예	프로그램이 받는 답
선택	결제·배송·계정·추가 확인 중 어디로 보낼까?	선택한 항목과 선택지별 확률
점수	이 문의의 긴급도를 정해진 척도에서 평가하면?	점수와 확률 정보
참·거짓 판단	이 문서는 환불 정책에 대한 근거인가?	해당 진술이 참일 확률

여러 질문을 같은 상황에 대해 한 번에 평가할 수도 있습니다. 예를 들어 문의 유형과 긴급도, 사람의 검토가 필요한지를 함께 묻습니다. 여기서 참·거짓 판단은 TypeSafe가 Noul이라고 부르는 형태입니다.2

“LLM은 생각하고 Jev는 판단한다”는 표현은 역할을 설명하는 비유로는 좋습니다. 기술을 완전히 나누는 정의는 아닙니다. 언어모델도 분류와 선택을 수행하고, 엄격한 구조화 출력도 지원합니다. OpenAI는 이미 2024년 8월 개발자가 정한 출력 규격을 따르도록 생성을 제한하는 기능을 발표했습니다.4

그러므로 Jev의 차별성을 “선택지를 고르는 AI를 처음 만들었다”에서 찾으면 안 됩니다. 글을 만드는 과정 없이 판단을 반환하고, 여러 판단의 처리 속도·비용·확률 품질을 제품의 중심에 놓았다는 것이 더 중요한 비교점입니다. TypeSafe는 이를 위해 새 모델 구조, 병렬 처리 방식, 확률 보정을 겨냥한 학습법인 RLCD를 사용했다고 설명합니다. 구체적인 내부 구조와 장기 성능이 독립적으로 검증됐다는 뜻은 아닙니다.3

‘환각 없음’이 없애는 오류와 남겨두는 오류

선택지가 결제, 배송, 계정으로 고정돼 있다면, 규격을 지키는 모델은 존재하지 않는 특별고객행복본부를 새로 만들어 답할 수 없습니다. 없는 도구 이름을 지어내거나 프로그램이 읽지 못할 답을 반환하는 문제를 막는 데 의미가 있습니다.

하지만 결제 문제를 배송 부서로 보내는 오판은 여전히 가능합니다. 문의 내용이 잘못됐거나, 선택지에 필요한 담당 부서가 없거나, 모델이 문맥을 오해할 수 있기 때문입니다. 보기 밖의 답을 만들지 않는 것과 보기 안의 정답을 고르는 것은 다른 문제입니다.

TypeSafe도 발표문에서 자사가 제시한 0%는 실험에서 관찰한 모든 오류의 비율이 아니라 출력 규격을 보장한다는 의미라고 설명합니다.1

더 까다로운 문제는 선택지를 누가 만드는가입니다. 앞단의 언어모델이 잘못된 행동만 후보로 만들어 놓으면, Jev가 그중 가장 그럴듯한 것을 정확히 골라도 전체 시스템은 실패합니다. 따라서 해당 없음, 정보 부족, 추가 확인 같은 출구가 필요합니다. 사실 확인과 후보 검증을 없애고 마지막 선택만 제약해서는 신뢰할 만한 자동화가 되지 않습니다.

시그모이드는 숫자를 압축하지만 진실을 만들어주지는 않습니다

언어 이해와 실행 사이에 ‘판단 계층’ 또는 ‘시그마 계층’을 두자는 구상은 유용합니다. 자유로운 언어를 프로그램이 다룰 수 있는 선택과 확률로 바꾸면, 실행 범위를 명확하게 제한할 수 있습니다.

다만 이를 시그모이드 함수 하나로 환각을 없애는 기술이라고 이해하면 곤란합니다. 시그모이드는 숫자를 0과 1 사이로 바꿉니다. 여러 선택지의 값을 확률분포처럼 정규화할 때에는 소프트맥스 같은 방법도 씁니다. 0.9라는 숫자를 만들었다고 실제로 90% 맞는 것은 아닙니다.

예컨대 정답일 확률을 80% 안팎으로 예측한 사례를 많이 모았을 때 실제 정답률도 그 수준에 가까워야 확률이 잘 보정됐다고 할 수 있습니다. 현대 신경망의 높은 확신과 실제 정확도가 어긋날 수 있다는 문제는 오래전부터 연구돼 왔습니다.5

그래서 판단 계층에 필요한 것은 출력값을 압축하는 함수만이 아닙니다. 어떤 업무에서 무엇을 정답으로 볼지 정하고, 실제 결과로 확률을 점검하며, 틀렸을 때의 피해에 맞춰 자동 실행 기준을 정해야 합니다. 한국어 고객 문의에서 잘 맞는 기준이 법률 문서나 시장 예측에서도 그대로 통할 것이라고 가정해서는 안 됩니다.

Jev의 확률이나 확신도 역시 해당 업무의 실제 결과와 대조해야 합니다. 특히 제품이 반환하는 별도의 확신도 점수를 곧바로 ‘이 행동이 성공할 확률’로 읽으면 안 됩니다. 이 글에서는 Jev의 내부 계산을 시그모이드 기반이라고 단정하지 않습니다.

싸고 빠른 판단은 에이전트의 움직임을 바꿉니다

에이전트가 웹사이트에서 자료를 찾는다고 가정해 보겠습니다. 검색할지, 어느 링크를 열지, 문서가 관련 있는지, 충분한 정보를 모았는지 계속 결정해야 합니다. 각 단계가 짧더라도 생성형 모델의 응답과 화면 변화를 매번 기다리면 시간이 쌓입니다.

판단 모델이 유용한 자리는 이렇게 반복되는 작은 분기입니다. 다만 판단을 모두 직렬로 이어 붙이는 것보다, 같은 관측으로 답할 수 있는 질문을 함께 처리하는 편이 낫습니다.

Browser Use의 공개 구현은 현재 화면에서 행동 종류와 행동별 대상을 함께 고릅니다. 클릭하기로 결정되면 클릭 대상만 사용하고, 실행 후 바뀐 화면을 다시 읽습니다. 아직 나타나지 않은 화면의 판단까지 미리 끝내는 구조는 아닙니다.7

개발자가 공개한 Google Flights 시연은 7.073초 동안 Jev 요청 17회와 별도 텍스트 생성 호출 2회를 사용했습니다. 모델이 버튼은 골라도 도시 이름을 입력할 글까지 만드는 것은 아니어서, 그 부분은 다른 생성 모델이 맡았습니다.7

이 기록에는 중요한 범위가 있습니다. 시간 측정에서 브라우저 준비, 첫 페이지 이동, 실행 후 별도로 하는 결과 검증은 제외됐습니다. 또한 중앙값 9.450초에서 7.092초로 약 25% 빨라졌다는 비교는 Jev와 일반 언어모델의 대결이 아니라 같은 모델을 쓰는 실행 코드의 개선 효과입니다. 비교 실행도 각 3회입니다.7

여기서 읽을 교훈은 특정 숫자보다 분업입니다. 모델의 판단뿐 아니라 화면 읽기, 통신, 재시도, 결과 확인을 함께 설계해야 전체 작업이 빨라집니다.

‘LLM + Jev + Graph + Agent’에는 실행 통제가 더 필요합니다

‘생각하는 LLM, 판단하는 Jev, 기억하는 Graph, 행동하는 Agent’라는 구상은 협업 구조를 떠올리게 합니다. 다만 에이전트는 마지막에 붙는 별도 모델이라기보다 이 부품들을 사용해 일을 수행하는 전체 시스템으로 보는 편이 정확합니다.

권장하는 역할 분담은 다음과 같습니다. 언어모델은 목표를 해석하고 계획과 새로운 선택지를 만듭니다. 판단 모델은 주어진 후보를 빠르게 평가합니다. 기억 저장소는 사실뿐 아니라 출처와 시점, 이전 실행 결과를 보관합니다. 실행기는 도구를 호출하고 실제 결과를 확인합니다.

Graph, 즉 관계를 연결해 저장하는 방식은 기업·인물·계약처럼 연결 관계가 중요한 기억에 유용할 수 있습니다. 그렇다고 모든 기억을 그래프로 만들 필요는 없습니다. 일반 데이터베이스와 문서 검색만으로 충분한 업무도 있습니다. 어떤 형태든 오래된 정보와 확인되지 않은 추정을 사실처럼 재사용하지 않도록 해야 합니다.

이 구조에서 권한·한도·금지 행동·승인 절차는 모델의 확률과 분리해야 합니다. “이 이메일을 보내는 것이 적절할 확률이 높다”는 판단과 “이 수신인에게 보낼 권한이 있다”는 사실은 다릅니다. 고객 정보를 외부 모델에 보낼 수 있는지, 결제를 집행해도 되는지는 별도의 규칙으로 확인해야 합니다.

판단 모델에게 맡길 첫 업무도 이 경계에 맞춰야 합니다. 공개 자료의 관련성 평가, 고객 문의의 담당 부서 제안, 다음 검색 도구 선택처럼 되돌리기 쉽고 정답을 점검하기 쉬운 일부터 시작할 수 있습니다. 불확실하거나 중요한 사례는 더 강한 모델이나 사람에게 넘기는 구조가 합리적입니다.

400배는 모든 토큰과 모든 업무에 붙는 숫자가 아닙니다

TypeSafe의 공개 입력 가격은 100만 토큰당 0.042달러, 즉 10억 토큰당 42달러이며 출력에는 별도 요금을 붙이지 않습니다.13

회당 청구되는 입력이 1,000토큰이라고 가정하면, 요청 100만 회의 입력은 10억 토큰입니다. 따라서 단순 추론 요금은 1,000토큰 × 100만 회 ÷ 100만 토큰 × 0.042달러 = 42달러입니다. 한 번의 요청과 한 번의 업무 완료는 다르며, 추가 호출·검색·브라우저·저장·사람 검토 비용은 이 계산에 들어 있지 않습니다.

회사가 내세운 193.6배 속도와 444.6배 비용 차이는 자체 업무 평가에서 나온 수치입니다. 회사도 실제 개선폭의 높은 쪽에 해당할 것으로 설명합니다. 평가 기준은 별도의 사람 정답집이 아니라 강한 외부 모델들의 평균 예측이며, 비교 언어모델에도 확률을 포함한 구조화 응답을 요구했습니다. 짧은 선택지만 생성하는 모델과의 비용 비교와 같지 않습니다.1

따라서 기업이 계산할 숫자는 ‘토큰당 가격’보다 허용한 오류 수준을 지키며 한 업무를 끝내는 총비용입니다. 가령 판단 호출에서 아낀 금액보다 사람에게 다시 확인받는 비용이 크다면 저렴한 모델로 바꾼 효과는 사라집니다. 기존 규칙 코드로 충분한 일에 AI를 넣는 것도 비용 절감이 아닙니다.

반대로 정확도가 유지되는 범위에서 저렴한 판단을 여러 번 넣을 수 있다면, 예전에는 생략했던 관련성 검사나 재확인을 수행할 수 있습니다. 비용 하락은 단순한 모델 교체를 넘어 어디까지 확인하고 자동화할지를 바꿀 수 있습니다.

언어모델 개발은 답변 생성 외의 목표로 넓어질 수 있습니다

분류 자체는 새로운 발명이 아닙니다. 주어진 문장이 어떤 범주에 속하는지 평가하는 연구와, 별도 학습 없이 새 범주를 설명으로 제시하는 연구도 Jev 이전에 존재했습니다.6

Jev가 보여주는 개발 방향은 ‘무슨 글을 쓸까’뿐 아니라 ‘어떤 선택을 얼마나 믿고 실행할까’를 별도의 최적화 대상으로 삼는 것입니다. 다음의 변화는 이미 입증된 산업 결론이 아니라 이 설계에서 도출되는 전망입니다.

큰 모델은 계획과 학습용 사례를 만들고, 작은 판단 모델은 반복 실행을 맡을 수 있습니다. 예외를 만났을 때만 큰 모델이 다시 개입한다면 모든 단계에 같은 수준의 계산을 쓸 필요가 없습니다. 이는 가능한 개발 경로이지, Jev가 실제로 특정 언어모델을 압축해 만들었다는 주장은 아닙니다.

평가와 학습 데이터의 중심도 달라집니다. 읽기 좋은 답변만으로는 부족합니다. 같은 위험 한도에서 자동 처리할 수 있는 사례가 얼마나 늘었는지, 불확실한 사례를 얼마나 잘 골라냈는지, 실행 결과가 목표에 맞았는지를 측정해야 합니다. 높은 평균 정답률만으로는 위험한 예외를 놓치는 모델을 구별하기 어렵습니다.

전문 모델과 범용 모델 사이의 경계는 고정되지 않을 것입니다. 공개 모델의 선택지 점수를 직접 읽는 SemIf는 이런 인터페이스를 다른 방식으로 구현할 수 있음을 보여줍니다. 다만 Jev의 비공개 모델이나 학습을 재현한 프로젝트는 아닙니다. 작성자의 소규모 비교에서 직접 점수 읽기는 짧은 JSON 생성보다 빨랐지만, 선택이 일치한 것은 21개 중 18개였습니다. 빨라졌다는 것과 같은 품질이라는 것은 별도로 검증해야 합니다.8

그 결과 판단 전용 기업의 경쟁 상대는 다른 판단 전용 기업에 한정되지 않습니다. 짧은 구조화 응답을 내는 범용 모델, 업무별로 학습한 분류기, 공개 모델의 직접 점수 읽기, 때로는 사람이 작성한 규칙도 비교 대상입니다.

VC가 봐야 할 것은 호출량보다 검증된 자동화입니다

초기 반응은 빠릅니다. Vercel은 9월 16일 Jev를 AI Gateway에 추가했고, 9월 18일 발표에서 출시 후 24시간 안에 유료 팀의 약 13%가 사용했다고 밝혔습니다. 다만 이는 Vercel 유료 팀이라는 특정 집단의 첫날 사용 비율입니다. 전체 시장 점유율, 반복 사용, 매출 비중, 장기 고객 유지의 증거로 확대해서는 안 됩니다.1011

이 반응은 전문 모델도 기존 개발 플랫폼을 통해 빠르게 유통될 수 있다는 신호입니다. 동시에 플랫폼이 비슷한 기능을 추가하거나 대체 모델을 쉽게 연결하면, 단순한 인터페이스와 저가 요금만으로 고객을 지키기는 어려워질 수 있습니다.

투자 관점에서 더 강한 자산은 특정 업무의 정답과 실행 결과가 쌓이는 데이터, 고객이 허용할 수 있는 오류를 검증하는 평가 체계, 고객의 실제 업무와 권한 체계에 깊이 연결된 제품입니다. 같은 위험 한도에서 더 많은 일을 사람의 재검토 없이 끝내는 사업자가 더 큰 가치를 가져갈 가능성이 있습니다.

추론 가격이 내려간다고 산업 전체의 AI 지출이 반드시 줄어드는 것도 아닙니다. 호출당 비용은 낮아져도 자동화하는 업무와 점검 횟수가 늘 수 있습니다. 반대로 호출량이 크게 늘어도 요금이 충분히 낮다면 공급자의 매출은 기대만큼 늘지 않을 수 있습니다. 사용량 확대와 수익성은 다른 검증 과제입니다.

공개 가격만으로 TypeSafe의 원가나 장기 이익률을 계산할 수는 없습니다. 현재 가격의 지속성, 고객의 반복 사용, 동일한 업무에서의 정확도와 총비용이 확인되기 전에는 ‘새로운 모델 범주’라는 표현을 곧바로 독점적 사업 지위로 연결하지 않는 편이 맞습니다.

자동거래에서는 빠른 선택보다 맞는 예측이 먼저입니다

정해진 주문 방향을 빠르게 선택하는 인터페이스는 거래 제어에 사용할 수 있습니다. 그러나 그것만으로 수익성 있는 예측이 생기지는 않습니다. 가격 변화를 예측하는 정보가 있는지, 거래비용과 불리한 체결을 감안해도 이익이 남는지, 시장 상황이 달라졌을 때 손실을 제한할 수 있는지는 다른 문제입니다.

공개된 jev-trader도 이 구분을 보여줍니다. README는 기본 모델이 실제 Jev가 아닌 모의 규칙 모델이고, 공개 배포는 모의 실행이라고 밝힙니다. 따라서 해당 시연을 Jev가 실제 시장에서 수익을 냈다는 근거로 사용할 수 없습니다.9

판단 계층의 강점은 위험 통제를 없애는 데 있지 않습니다. 선택 가능한 행동을 제한하고, 실행 전후를 기록하며, 틀렸을 때 중단하거나 검토로 넘기기 쉽게 만드는 데 있습니다.

도입 여부는 같은 위험 한도에서 비교해야 합니다

첫 실험은 하나의 좁은 업무와 고정된 평가 표본으로 시작하는 편이 낫습니다. 정상 사례뿐 아니라 정보 부족, 잘못된 선택지, 한국어 표현 차이, 오래된 자료, 모순된 지시를 포함해야 합니다. 기존 규칙, 저렴한 구조화 출력 모델, Jev를 같은 입력과 같은 기준으로 비교합니다.

평가 지표는 응답 속도 하나가 아닙니다. 잘못 실행한 비율, 사람이 수정해야 하는 비율, 실제로 완료한 비율, 재시도를 포함한 총시간과 총비용을 함께 봅니다. 처음에는 실제 행동을 바꾸지 않고 기존 시스템 옆에서 판단만 기록하는 방식으로 점검할 수 있습니다.

Jev가 제시하는 가능성은 모든 AI를 대체하는 만능 판단기가 아닙니다. 깊게 생각할 때와 빠르게 선택할 때를 구분하고, 각각에 맞는 계산을 쓰는 소프트웨어입니다. 그 가능성이 사업 성과로 이어지는지는 ‘얼마나 싸게 답했나’가 아니라 ‘허용한 위험 안에서 얼마나 많은 일을 끝냈나’로 판단해야 합니다.

---

출처와 확인 범위

[1] TypeSafe AI, Jev 발표문. Introducing System One Models and Jev. 가격, 자체 업무 평가의 비교 조건, 출력 규격 보장의 의미. 검색 수집본의 날짜는 2026년 9월 14일로 표시됩니다.

[2] TypeSafe 공식 문서. Introduction. 상태·질문·Choice·Score·Noul과 병렬 평가 인터페이스.

[3] TypeSafe 공식 제품 소개. TypeSafe AI. 입력 10억 토큰당 42달러, 판단 전용 설계와 RLCD에 대한 회사 설명. 2026년 9월 19일 확인.

[4] OpenAI, 2024년 8월 6일. Introducing Structured Outputs in the API. 생성형 모델의 출력 규격 제약과 내용상 오류의 구분.

[5] Guo 외, ICML 2017. On Calibration of Modern Neural Networks. 모델의 확신과 실제 정확도를 맞추는 확률 보정 문제.

[6] Yin 외, EMNLP-IJCNLP 2019. Benchmarking Zero-shot Text Classification. 새로운 범주의 설명을 활용한 텍스트 분류의 선행 연구.

[7] Browser Use 개발자 기록. jev-ultrafast performance report. 시연의 계측 범위, 동일 모델을 이용한 실행 코드 비교, 별도 텍스트 생성 모델 사용.

[8] 독립 개발 프로젝트 SemIf. README. 공개 모델을 이용한 선택형 인터페이스와 작성자의 비교 실험. Jev 자체의 독립 재현이 아닙니다.

[9] 독립 개발 프로젝트 Jev Trader. README. 모의 모델·모의 실행이라는 공개 배포 조건.

[10] Vercel, 2026년 9월 16일. TypeSafe AI's Jev now available on AI Gateway. 유통 경로와 평가 인터페이스.

[11] Vercel, 2026년 9월 18일. Jev is the fastest-adopted model in AI Gateway history. 첫 24시간 사용 비율과 9월 15일 소개일 표기. 해당 플랫폼의 자체 관측입니다.

도식은 공개 자료를 바탕으로 그린 설명용 그림입니다. TypeSafe의 비공개 내부 구조를 표현하지 않습니다. 가격 계산은 공개 단가에 가정한 입력량을 곱한 값이며 실제 청구·한국 내 응답 시간·거래 성과를 검증한 결과가 아닙니다. 공개 저장소의 main·master 내용은 이후 변경될 수 있습니다.