Jev는 대화 대신 선택한다: 세 가지 데모와 그 이면의 한계

벤더 벤치마크가 아닌 자체 설명 다이어그램입니다. 모델은 정해진 선택지 안에서 판단하고, 권한·검증·실행은 여전히 애플리케이션 코드가 담당합니다.

받은 편지함 분류기는 폴더를 고르기 전에 에세이를 쓸 필요가 없습니다. 브라우저 제어기도 새로운 명령어를 만들어 내기보다 사용할 수 있는 버튼 하나를 선택하는 경우가 많습니다. 이런 작은 판단 영역에서 TypeSafe AI의 첫 System One 모델인 Jev가 가장 흥미로운 가능성을 보여 줍니다.

TypeSafe는 2026년 9월 15일 Jev를 공개했습니다. 중요한 차이는 단순히 빠른 모델이 하나 더 생겼다는 데 있지 않습니다. Jev는 자유 형식의 문장 대신 제약된 판단 결과를 반환합니다. 이 차이는 주변 프로그램을 만드는 방식을 바꾸지만, 잘못된 답을 고를 가능성까지 없애 주지는 않습니다. 벤더의 설명은 공식 출시 글을 참고하세요.

이 안내서는 공개 데모 세 가지를 살펴봅니다. 다운로드할 수 있는 GIF와 영상 증거가 포함된 브라우저 작업, 작성자가 보고한 이메일 1,500건 분류 사례, TypeSafe의 게임 데모입니다. 이어서 이런 사례를 구체적인 평가 계획으로 바꿔 봅니다. 9월 18일에 게시된 티스토리 활용 사례 글이 조사의 출발점이었지만, 그 글에서 제안한 적용 사례를 독립적으로 검증된 고객 배포 사례로 취급하지는 않습니다.

핵심 요약:

• Jev는 텍스트에서 선택·점수화·명제 판단을 할 수 있습니다. 임의의 문장을 작성하는 모델을 대체하는 도구는 아닙니다.
• 타입이 맞는 결과도 의미상 틀릴 수 있습니다. 검증과 최종 권한 부여는 코드에서 처리하세요.
• 브라우저 녹화는 실제 사례지만, 작업 하나가 일반적인 벤치마크는 아닙니다. 이메일 사례는 작성자의 보고이며 공개된 정확도 연구가 아닙니다.
• 되돌릴 수 있는 분류부터 시작하고, 자체 데이터에서 오류를 측정하며, 판단 보류를 가능한 결과로 지원하세요.

답을 작게 만들려면 질문을 명확하게 정해야 한다

API의 핵심 프리미티브는 Choice, Score, Noul 세 가지입니다. Choice는 이름이 붙은 대안 중 하나를 선택합니다. Score는 순서와 설명이 있는 단계로 평가합니다. Noul은 참 또는 거짓으로 답할 명제의 확률을 반환합니다. 값이 중간에 가깝다면 그 명제에 대한 불확실성이 크다는 뜻이지, 심각도가 중간이라는 뜻은 아닙니다. 프리미티브 문서에 각 계약이 설명되어 있습니다.

실용적인 변화는 모델에 판단을 요청하기 전에 가능한 결과를 정의하는 데 있습니다. 수신된 고객 지원 메시지에 관한 문단을 요청하는 대신, 결제, 계정 접근, 제품 결함, 미분류 범주 중 무엇에 관한 메시지인지 물을 수 있습니다. 그런 다음 애플리케이션이 어느 대기열에 표시할지 결정합니다. 이것은 철도 선로의 분기기와 같습니다. 업무의 방향을 정하는 데 도움을 주지만, 업무를 끝내는 데 필요한 모든 기능을 제공하지는 않습니다.

좋은 선택지를 작성하는 것 역시 엔지니어링 작업입니다. 레이블 두 개가 겹치면 자신 있어 보이는 선택 뒤에 분류 체계의 문제가 숨어 있을 수 있습니다. 어떤 선택지도 맞지 않는데 하나를 강제로 고르게 하면 범위 누락을 확실성으로 위장하게 됩니다. 검토 옵션은 범주를 하나 더 세분화하는 것보다 유용한 경우가 많습니다. 판단 계약을 개선해야 하는 지점을 드러내기 때문입니다.

2026년 9월 30일에 확인한 모델 참조 문서에는 jev-1.13.0, 텍스트 전용 입력, 입력 토큰 100만 개당 $0.042의 가격이 기재되어 있으며 출력 토큰은 무료입니다. 이는 모델 토큰 가격이지 에이전트 실행의 총비용이 아닙니다. 브라우저, 추출, 보조 모델, 재시도, 사람의 검토도 운영 예산에 포함해야 합니다.

브라우저 GIF는 실제 검색을 보여 주지만 항공권 예약은 아니다

Browser Use의 공개 jev-ultrafast 저장소에는 취리히에서 런던으로 가는 Google Flights 검색 녹화가 있습니다. Jev는 현재 페이지 표현에서 작업과 대상을 선택합니다. 선택한 작업에 입력이 필요하면 별도의 생성형 보조 모델이 텍스트를 제공합니다. 이는 여러 요소를 조합한 시스템이지, Jev 자체가 모든 문자열을 생성하거나 영상 프레임을 이해한다는 증거가 아닙니다.

Browser Use 작성자가 녹화한 실제 GIF이며 커밋 1231850a0bf1a0c0341fe408ef1668dbbfdfac46에 고정되어 있습니다. 저작권 2026 Browser Use, MIT 라이선스입니다. 검색 흐름을 보여 주며 구매를 진행하지 않습니다. 같은 녹화를 아래에서 재생할 수 있습니다.

작성자가 제공한 MP4이며 녹화 속도 그대로 브라우저 컨트롤과 함께 표시됩니다. 원본 녹화와 측정 기록, 보존된 MIT 라이선스. 공개된 자료를 살펴봤으며 이 벤치마크를 다시 실행하지는 않았습니다.

작성자가 측정한 녹화의 완료 시간은 7.073초입니다. 시간 측정은 새 브라우저를 실행한 시점이 아니라 초기 홈페이지를 관찰한 뒤 처음으로 예측한 시점부터 시작합니다. 설정, 최초 페이지 이동, 실행 후 독립적인 새 검증은 측정 시간에 포함되지 않습니다. 검색 결과를 확인하지만 항공권을 선택하거나 구매하지는 않습니다. 이 수치를 해석하려면 이런 범위를 알아야 합니다.

같은 보고서에서는 런타임별로 세 번씩 번갈아 실행한 총 6회 결과를 비교합니다. 작업 시간 중앙값은 9.450초에서 7.092초로 줄고, 브라우저 프로토콜 호출 중앙값은 1,092회에서 101회로 감소합니다. 두 조건 모두 Jev와 같은 텍스트 보조 모델을 사용하므로, 이는 주로 런타임 비교이지 두 모델 계열의 대결이 아닙니다. 작성자는 성능 보고서에서 표본이 적고 실시간 웹의 변동성이 있다는 점을 명시합니다.

저희가 주목한 점은 브라우저를 둘러싼 반복 실행 과정에도 모델만큼 신경 써야 한다는 것입니다. 페이지를 반복해서 수집하고, 대상을 찾고, 이전 판단을 무효화하는 데 드는 비용은 클릭이 단순해 보여도 상당할 수 있습니다. 더 빠른 판단 엔진이 선택해야 할 버튼을 부정확하게 설명하는 문제를 보상해 주지는 않습니다. 저장소가 독립적인 결과 검증을 유지하는 이유도 모델이 완료됐다고 말하는 것이 실제 완료의 증거는 아니기 때문입니다.

데모의 한계는 오히려 평가에 도움이 됩니다. 문서화된 구현은 모든 프레임, 캔버스, 업로드 흐름, 임의의 키보드 위젯을 지원하지 않습니다. 평가팀은 성공적인 항공편 검색 하나가 일반적인 브라우저 역량을 증명한다고 추론하지 말고, 대표 작업과 실패 경로를 직접 재현해야 합니다. 이 녹화는 검토할 수 있는 하나의 작동하는 조합을 보여 주는 증거로 보세요.

이메일 1,500건 글은 유망한 사례지만 분모가 빠져 있다

2026년 9월 16일, vogel (@ryanvogel)은 X에 자신의 이메일 1,500건에 Jev를 시험해 봤고 분류 결과가 인상적이었다고 게시했습니다. 원 게시물에는 영상도 포함되어 있습니다. 출처가 가정적인 활용 사례를 나열한 익명 글이 아니라 실험을 보고한 당사자이고 작업량도 구체적이어서 유용한 실제 사용자 사례입니다.

하지만 정확도 보고서는 아닙니다. 게시물에는 공개 레이블 테스트 세트, 측정된 오류율, 검토자 간 일치도, 실수의 비용이 제시되어 있지 않습니다. 처리한 메시지 수는 실험 규모를 알려 줄 뿐 정확성을 알려 주지 않습니다. 이 차이를 염두에 두고 원본 X 데모를 살펴보세요. 영상은 재배포 라이선스 없이 복사하지 않고 링크로 연결했습니다.

그렇더라도 이메일 분류는 되돌릴 수 있게 설계할 수 있으므로 평가를 시작하기에 합리적인 영역입니다. 기존 받은 편지함 옆에 제안된 레이블을 표시하고, 원본 메시지는 그대로 두며, 수정 내용을 기록하세요. 청구서와 결제 알림, 취소 요청과 취소라는 말만 언급한 불만처럼 혼동하기 쉬운 쌍을 비교하세요. 이런 사례를 보면 범주가 실제 업무 흐름에 맞는지 알 수 있습니다.

분류 결과가 자신 있어 보인다는 이유만으로 초기 배포에서 메일을 자동 삭제하거나 답장을 보내거나 거래를 승인해서는 안 됩니다. 그런 작업에는 별도의 권한과 결과가 따릅니다. 제안이나 검토 대기열부터 시작하고, 오류 양상을 측정한 뒤에만 범위가 좁은 동작을 추가하세요. 이는 저희가 제안하는 평가 절차이지 X 작성자의 구현에 관한 주장이 아닙니다.

Doom과 Wikiracing은 판단 순환을 눈에 보이게 한다

TypeSafe의 출시 자료에는 Doom 데모와 Wikiracing 데모가 포함되어 있으며, 둘 다 공식 출시 글에서 연결되어 있습니다. 반복적인 판단 과정을 시각적으로 설명하는 데 유용합니다. Jev가 범용 시각 모델이거나 임의의 계획 문제를 풀 수 있다는 증거는 아닙니다.

Doom 사례에서 모델은 스크린샷이 아니라 구조화된 텍스트 상태 설명을 받습니다. Wikiracing에서는 목적지 URL을 새로 만들어 내는 대신 사용 가능한 링크 중 하나를 고릅니다. 핵심 메커니즘은 관찰, 제한된 선택, 행동의 반복입니다. 게임 데모를 보면 이 순환을 쉽게 파악할 수 있지만, 다른 환경에서도 잘 작동하는지는 여전히 열려 있습니다.

TypeSafe의 스마트홈 데모 문서에서도 같은 분리를 볼 수 있습니다. 서로 다른 질문으로 요청의 여러 측면을 분류하고, 다른 구성 요소가 자유 형식의 대화나 복합 요청 분할을 처리할 수 있습니다. 하나의 모델이 언어를 생성하면서 모든 판단도 실행한다고 설명해서는 안 됩니다. 구현이 경계를 명시하지 않으면 assistant나 agent 같은 이름이 이런 역할 구분을 가리기 쉽습니다.

문서화된 fan-out 계약을 바탕으로 만든 자체 다이어그램입니다. 동시에 실행되는 질문은 상태를 공유하지만 서로의 답을 몰래 읽지는 않습니다.

Fan-out 패턴은 여러 질문이 같은 원본에 의존할 때 순차 대기 시간을 줄일 수 있습니다. 예를 들어 메시지의 주제와 콜백을 명시적으로 요청했는지는 서로 독립적으로 평가할 수 있습니다. 새로 선택한 주제에 의존하는 질문은 같은 호출 안에서 그 답이 이미 있다고 가정할 수 없습니다. 의존성을 후속 단계로 나누거나 코드에서 독립된 결과를 결정적으로 조합하세요.

타입이 맞는 답이 정답이라는 뜻은 아니다

제약된 모델을 가장 위험하게 오해하는 방식은 형식이 잘 갖춰진 답은 틀릴 수 없다고 여기는 것입니다. 실제로 틀릴 수 있습니다. 분류기가 허용된 레이블 중 부적절한 것을 고를 수 있고, 동작 선택기가 엉뚱한 양식에 있는 유효한 버튼을 고를 수도 있습니다. 인터페이스에서 형식에 맞지 않는 문장을 없애는 것은 유용하지만, 과제를 잘못 이해하는 문제와는 다른 실패 유형을 다룹니다.

TypeSafe의 Jev 1.13 불안정성 메모는 9월 17일에 마지막으로 검토되었으며 산술, 계수, 날짜 비교, 주의를 흐리는 문맥, 적대적 입력과 관련한 약점을 설명합니다. 정확한 비교가 필요하면 일반 코드로 날짜를 파싱하고 수량을 계산하세요. 모델이 질문을 받을 수 있다는 이유만으로 결정적 규칙을 의미 판단으로 바꾸지 마세요.

신뢰도 문서도 중요합니다. Choice와 Score는 확률 분포 및 여기서 파생된 신뢰도 값을 제공하지만, Noul에는 별도의 신뢰도 필드가 없습니다. 그 숫자가 답이 맞을 보편적인 확률을 뜻하지는 않습니다. 오탐과 미탐의 결과가 다르다면 특히 자체 작업에 맞춰 임계값을 검증해야 합니다.

자체 평가 다이어그램입니다. 한 관문을 통과해도 다음 관문을 통과한다는 뜻은 아닙니다. 허용된 출력도 올바른 해석과 승인된 동작이 필요합니다.

다국어 작업에서는 실제로 서비스하는 각 언어를 시험하세요. 모델 문서에 따르면 영어가 주요 학습 언어이며, CJK 문자를 포함한 다른 언어의 품질은 고르지 않습니다. 따라서 한국어 지원 대기열이나 여러 언어가 섞인 뉴스레터 보관함은 영어 점수의 당연한 연장으로 보지 말고 별도 평가 구간으로 다뤄야 합니다. 번역 과정에서 근거가 달라질 수도 있으므로 번역된 표현을 평가한다면 원문을 보존하세요.

실패를 정직하게 드러내는 시험을 설계하라

유용한 시범 운영은 팀이 일관되게 레이블을 붙일 수 있는 판단부터 시작합니다. 지원 대기열 제안, 중복 가능성 표시, 나중에 검토할 문서 레이블 지정처럼 되돌릴 수 있는 작업을 고르세요. 데모가 매끄러워 보이는지를 성공 기준으로 삼지 마세요. 알아차릴 수 있는 잘못된 결과와 놓칠 수 있는 결과, 각각이 사용자에게 초래하는 비용을 정의하세요.

1. 판단 계약을 작성합니다. 가능한 결과, 필요한 원본 필드, 검토 옵션을 나열합니다. 의미 해석과 계산, 권한을 분리합니다.
2. 평가 세트를 만듭니다. 처리 권한이 있는 자료를 사용합니다. 일반 사례, 경계가 모호한 사례, 혼합 언어, 빈 필드, 원문 안의 악의적인 지시를 포함합니다.
3. 별도 검증용 데이터를 남깁니다. 한 세트에서 기준을 조정한 다음 문구 설정에 쓰이지 않은 자료로 측정합니다. 기대 답을 조용히 다시 정의하지 말고 의견 차이를 기록합니다.
4. 전체 워크플로를 측정합니다. 범주별 오류, 검토율, 종단 간 지연 시간, 재시도, 총비용을 추적합니다. 느린 검색 과정 안의 빠른 모델 호출도 제품 전체로는 느립니다.
5. 제안 모드로 운영합니다. 중대한 동작을 자동 실행하지 않은 채 선택지, 관련 확률, 모델 버전, 사람의 수정 내용을 기록합니다.
6. 범위가 제한된 동작 하나를 추가합니다. 필요한 경우 명시적인 승인을 요구하고 감사 기록을 보존하며 원본이나 모델 버전이 바뀔 때 되돌릴 경로를 마련합니다.

이 절차는 녹화를 보는 것보다 의도적으로 엄격합니다. 어색한 사례까지 포함해 모델이 실제 데이터 분포에서 도움이 되는지 묻기 때문입니다. 검토율이 높아 보이더라도 드물고 조용하게 발생하는 값비싼 실수보다 나을 수 있습니다. 사고를 겪은 뒤가 아니라 임계값을 선택하기 전에 그 균형을 정하세요.

재현 가능한 평가를 위해 버전을 고정하고 각 결과에 반환된 버전을 기록하세요. 이동하는 별칭은 탐색할 때 편리하지만 애플리케이션 코드를 바꾸지 않아도 동작이 달라질 수 있습니다. 평가 자료를 통해 다른 사람이 기준, 입력, 기대 결과, 실행 경계를 재구성할 수 있어야 합니다. 그래야 가능성을 보여 주는 실험이 인상적인 영상 모음이 아니라 유지 관리 가능한 기능이 됩니다.

결론: 판단의 범위와 규칙을 명확히 정하라

Jev는 이미 규칙을 알고 있는 프로그램 안에서 작고 검토 가능한 결정을 내릴 때 가장 흥미롭습니다. 브라우저 영상은 작동하는 조합을 보여 주고, 이메일 게시물은 시험해 볼 만한 구체적인 실험을 제공하며, 공식 데모는 판단 순환을 드러냅니다. 다음 질문은 모델이 답을 고를 수 있는지가 아니라, 그 선택이 중요해지기 전에 시스템이 잘못된 선택을 알아챌 수 있는지입니다.

출처 및 미디어 크레딧

• TypeSafe: Introducing System One Models and Jev, 2026년 9월 15일. 공식 출시 및 게임 영상 관련 내용.
• Browser Use: jev-ultrafast, 2026년 9월 30일에 확인한 고정 소스. GIF와 MP4 저작권 2026 Browser Use, MIT 라이선스. 제휴 관계를 의미하지 않습니다.
• Browser Use: 녹화 및 조건을 맞춘 실행 측정, 2026년 9월 30일 확인. 작성자 측정이며 저희가 재현한 결과는 아닙니다.
• X의 vogel: 이메일 1,500건 분류 실험, 2026년 9월 16일. 원본 영상이 포함된 자기 보고 사례.
• TypeSafe 프리미티브, 모델, 신뢰도, fan-out, 스마트홈 데모. 2026년 9월 30일 확인.
• Jev 1.13 불안정성 메모, 마지막 검토 2026년 9월 17일. 9월 30일 확인.
• 티스토리 Jev 활용 사례 글, 2026년 9월 18일. 조사 출발점이며 배포 검증 자료는 아닙니다.

노트에 근거 자료를 함께 보관하세요

새 모델을 조사할 때는 출처와 날짜, 데모가 실제로 입증하는 내용을 함께 보존하세요. Telli.sh 계정을 만들어 직접 조사 자료와 파생 노트를 정리하면 요약을 원본 근거와 혼동하지 않을 수 있습니다.