Jev AI는 무엇이 다른가: 브라우저 자동화와 검색 사례 분석

브라우저에서 항공편을 찾는 AI는 출발지를 입력하고, 자동완성 목록에서 도시를 고르고, 날짜를 바꾼 뒤 검색 결과를 확인합니다. 사용자에게 보여줄 문장은 짧아도 그 과정에는 여러 번의 판단이 필요합니다.

Browser Use가 공개한 jev-ultrafast는 이 과정을 나눠 처리합니다. TypeSafe AI의 Jev가 다음 행동과 대상 요소를 고르고, 입력할 문자열이 필요할 때만 별도 언어 모델을 호출합니다. 프로젝트가 공개한 취리히발 런던행 항공편 검색 기록은 7.1초입니다. Jev가 소프트웨어 안에서 어떤 역할을 맡는지 살펴보기 좋은 사례입니다. Browser Use 공개 저장소

2026년 9월 28일 기준 공식 문서와 공개 구현을 확인해 기존 글을 갱신했습니다. 아래 수치는 각 출처의 공개 기록이며, 루브릭랩스가 Jev API를 실행해 재현한 결과는 아닙니다.

Jev가 돌려주는 것은 프로그램이 사용할 판단값

TypeSafe는 9월 15일 Jev를 공개하면서 System One이라는 모델 계열을 소개했습니다. 개발자가 상태와 질문을 전달하면, Jev는 미리 정한 형식의 판단값을 반환합니다. 회사는 자유로운 문장 생성을 포기하는 대신 여러 판단 결과를 병렬로 산출하는 데 집중했다고 설명합니다. 출시 발표

개발자가 사용할 질문 형식은 세 가지입니다. Choice는 주어진 항목 중 하나를 고르고, Score는 정의한 단계에 따라 평가하며, Noul은 예 또는 아니오로 답할 질문에 확률을 반환합니다. 예를 들어 클릭할 버튼 선택에는 Choice, 문서가 질문에 답할 근거인지 평가하는 데는 Noul을 사용할 수 있습니다. 질문 형식 문서

따라서 도입을 검토할 때는 기존 작업에서 어떤 결정을 반복하는지 찾아보는 편이 좋습니다. 긴 보고서를 작성하는 작업과 수십 개 후보 중 다음 대상을 고르는 작업은 필요한 출력부터 다릅니다.

7.1초 브라우저 데모에서 실제로 한 일

jev-ultrafast는 페이지의 버튼과 입력란을 번호가 붙은 목록으로 만듭니다. Jev가 클릭이나 입력 같은 동작과 그 대상을 고르면 실행 코드가 처리합니다. 기본 반복 과정에서 읽는 자료는 스크린샷이 아니라 페이지에서 추출한 구조화된 상태입니다. 문자열을 입력하는 단계에서는 별도 생성 모델이 내용을 작성합니다. 구현 구조

여기서 실행 코드의 역할도 큽니다. 모델이 선택한 요소가 아직 유효한지, 다른 요소에 가려져 있지 않은지 확인한 뒤 동작합니다. 모델이 완료를 선택해도 목표 달성 여부는 따로 검증합니다. 이 구조를 보면 모델 응답 속도뿐 아니라 페이지를 읽고 실행하는 과정도 자동화 성능에 영향을 준다는 것을 알 수 있습니다. 실행 검증과 한계

7.1초의 범위는 구분해서 읽어야 합니다. 측정은 첫 페이지 관찰이 끝난 뒤 시작하며, 이후 모델 호출과 텍스트 생성, 브라우저 동작, 로딩 대기를 포함합니다. 브라우저 준비와 첫 페이지 이동, 실행 후 별도 결과 검증 시간은 제외합니다. 항공편을 예약한 기록은 아니고 조건에 맞는 검색 결과를 표시한 기록입니다. 같은 환경에서 수행한 소수의 반복 실험이므로 여러 사이트에서의 성공률을 입증하지는 않습니다. 측정 기록

업무 자동화에 응용한다면 기존 화면에서 항목을 찾아 선택하는 과정이 후보가 될 수 있습니다. 다만 조회 성공과 주문 확정은 검증해야 할 결과가 다릅니다. 실제 적용에서는 목표한 화면 상태뿐 아니라 서버에 저장된 처리 결과까지 확인할 절차가 필요합니다. 이는 공개 데모를 업무 시스템에 옮길 때의 구현 제안입니다.

문서 검색에서는 후보를 다시 정렬한다

TypeSafe의 공식 검색 예제는 Jev의 역할을 더 좁게 보여줍니다. 미국 판례 데이터 CLERC의 문단 3,565개에서 질의 40개를 평가합니다. 먼저 키워드 검색 방식인 BM25로 질의마다 후보 30개를 뽑고, Jev가 각 후보가 인용 대상 판례에 해당할 가능성을 평가해 순서를 바꿉니다. 예제 코드의 모델은 현재 모델과 다른 jev-1.12입니다. 공식 재정렬 예제

표는 공식 예제에 표시된 반올림 수치입니다. 이 실험에서는 BM25 후보 30개 안에 정답이 모두 포함돼 있었습니다. 따라서 결과는 이미 찾은 후보의 순서를 개선한 효과이며, 누락된 정답을 새로 찾은 효과가 아닙니다. 질의와 후보의 조합마다 평가해 총 1,200회 호출했습니다. 실험 조건과 결과

이 결과를 읽고 기존 검색 서비스에서 먼저 확인할 것은 오답의 원인입니다. 정답 문서를 가져왔는데 뒤로 밀리는 문제라면 재정렬을 시험할 이유가 있습니다. 정답이 후보에 아예 없다면 수집 범위나 검색 조건부터 살펴야 합니다. 답변 생성 모델만 교체하면서 검색 문제까지 해결되길 기대하면 원인을 놓치기 쉽습니다.

한국어 서비스라면 현재 모델의 한계부터 확인한다

9월 28일 확인한 공식 모델 문서의 안정 버전은 jev-1.13.0입니다. 입력은 텍스트만 지원합니다. 이미지나 스캔 문서를 다루려면 앞에서 텍스트 또는 구조화된 정보로 변환해야 합니다. 학습의 주 언어는 영어이고, 공식 문서도 영어에서 정확도가 가장 좋으며 다른 언어는 자체 데이터로 시험하라고 안내합니다. 영어 데모를 한국어 업무의 성능 근거로 삼기 어려운 이유입니다. 지원 범위와 언어 안내

별도로 공개한 Jev 1.13 한계 문서에는 수 세기, 수치 계산, 날짜 비교의 약점이 나옵니다. 무관한 정보가 많은 입력이나 여러 단계를 거쳐야 하는 판단도 주의 대상으로 적혀 있습니다. 문서는 계산과 비교는 코드로 처리하고, 모델에는 필요한 정보와 명확한 판단 기준을 전달하도록 권합니다. Jev 1.13의 알려진 한계

가령 고객 메시지가 반품 의사를 담고 있는지는 모델로 분류해 볼 수 있습니다. 반품 기한이 지났는지는 주문일과 접수일을 코드로 비교하는 편이 적절합니다. 이처럼 의미를 읽는 작업과 정확한 계산이 필요한 작업을 나누면 어떤 부분을 평가해야 하는지도 분명해집니다.

Choice와 Score에 붙는 confidence도 함께 확인해야 합니다. 이 값은 선택지별 확률 분포를 요약한 것이며, 우리 데이터에서 측정한 정답률 자체는 아닙니다. 자동 처리 기준은 실제 오분류 기록과 함께 정해야 합니다. Noul에는 별도 confidence 필드가 없습니다. Confidence 설명

도입 여부는 같은 작업을 비교해 결정한다

검토 순서는 기존 작업 하나를 고르고, 지금 방식과 Jev를 넣은 방식을 같은 자료로 비교하는 것으로 잡을 수 있습니다. 예를 들어 문서 재정렬이라면 아래 항목을 함께 기록합니다. 다음 표는 이 글에서 제안하는 평가 기준입니다.

TypeSafe의 출시 글에 실린 큰 속도 개선 배수에도 비교 조건이 붙습니다. 일부 평가는 사람이 정한 정답 대신 다른 대형 모델들의 확률을 기준으로 삼았고, 회사도 발표 배수가 실제 환경에서 얻을 효과의 높은 쪽에 해당할 것으로 설명합니다. 비용이나 속도 배수만으로 도입 효과를 계산하기는 어렵습니다. 출시 평가의 조건

브라우저에서 다음 버튼을 고르는 일과 검색 후보의 순서를 매기는 일에는 공통점이 있습니다. 입력과 가능한 결과를 좁게 정의할 수 있고, 같은 판단이 반복됩니다. 기존 서비스에 이런 단계가 있다면 그 지점에 Jev를 넣어 비교해 볼 만합니다. 한국어 데이터에서 품질을 유지하면서 전체 처리 시간이나 비용이 줄어드는지 확인하는 것이 다음 단계입니다.