Jev.
Browser Use × TypeSafe AI의 알고리즘
모델은 그대로 두고 알고리즘만 바꾸면 LLM도 빨라지는가. Browser Use와 TypeSafe AI가 함께 내놓은 jev-ultrafast에서 페이지를 번호표로 바꾸는 스냅샷 알고리즘만 떼어 와, 같은 오퍼스로 같은 과제를 같은 시각에 돌린 12쌍에서 20~48% 단축했습니다.
1. 정확히 무엇을 가져왔나
jev-ultrafast는 브라우저 에이전트 회사 Browser Use가 2026년 9월 16일 자사 깃허브에 공개한 오픈소스(MIT)로, 배너에 "Browser Use × TypeSafe"를 단 협업작입니다. 코드와 번호표 알고리즘은 Browser Use가 썼고, TypeSafe는 판단 모델 Jev를 댑니다. 이 에이전트는 취리히에서 런던 가는 항공권을 7.1초에 찾습니다. 그 속도의 절반은 모델이, 절반은 페이지를 읽는 방식이 만듭니다. 우리가 가져온 것은 뒤쪽입니다.
가져온 것과 두고 온 것
가져온 것: 알고리즘 한 조각. 페이지 안에서 한 번 실행되는 스크립트가 지금 누르거나 입력할 수 있는 요소를 전부 훑어 번호를 매기고, 화면 글자와 함께 돌려줍니다. 그다음부터 에이전트는 셀렉터가 아니라 그 번호로 말합니다. 우리 쪽에서 더한 것은 같은 출처 iframe 읽기, 가려진 요소 제외, 화면 밖 요소, 그리고 조작마다 무엇이 바뀌었는지 돌려주는 보고입니다.
두고 온 것: 모델과 루프. 원본은 TypeSafe의 Jev라는 판단 전용 유료 모델을 동작마다 부릅니다. 그 모델은 글을 쓰지 않고 "무엇을, 어디에"만 고르며 입력 토큰 10억 개당 42달러, 아직 초대제라 대기자 명단에만 올려 두었습니다. 그 모델도, "한 동작마다 모델 한 번" 구조도 가져오지 않았습니다(2장에서 재 보고 버렸습니다).
이 실험이 말하는 것과 말하지 못하는 것
말하는 것. 모델을 바꾸지 않고 페이지를 읽는 알고리즘만 바꿔도 같은 에이전트가 더 빨리 끝냅니다. 양쪽 다 오퍼스 하나, 과제 문구도 같고, 다른 것은 도구 설명 한 덩어리뿐입니다. 두 방식을 같은 시각에 나란히 돌려 기계 부하까지 같게 했고, 12쌍 모두 번호 방식이 이겼습니다. 줄어든 것은 도구의 응답 시간이 아니라 모델이 생각한 횟수입니다.
말하지 못하는 것. 오퍼스 하나로 잰 값이라 모든 모델에 그대로 옮겨진다고 말할 수 없습니다. 비교 상대는 일반적인 "LLM 브라우징"이 아니라 우리 기존 CLI 방식입니다. 과제 넷은 우리가 골랐고, 과제당 3회·기계 한 대·하루 안에서 잰 값입니다. 그리고 번호표만이 아니라 "조작할 때마다 무엇이 바뀌었는지 돌려주는 보고"도 같이 들어갔으므로, 이득을 번호 하나에만 돌릴 수는 없습니다.
기존 방식: 매번 페이지를 뒤진다
에이전트가 자바스크립트를 직접 써서 "제목 입력칸이 어디 있지?"를 찾습니다. 화면이 바뀌면 다시 씁니다.
새 방식: 번호 붙은 목록을 한 번에 받는다
페이지 안에서 스크립트를 한 번 실행해, 지금 누를 수 있고 입력할 수 있는 요소를 번호와 함께 전부 받습니다. 그다음은 번호로 조작합니다.
2. 첫 시도: 작은 모델로 대체
원본 구조를 그대로 옮기고 Jev 자리에 하이쿠를 넣었습니다. 동작 하나마다 모델을 새로 부르고, 매번 맥락을 지우는 방식입니다.
같은 과제를 오퍼스 에이전트 하나가 기존 방식으로 하면 25.9초였습니다. 결론은 기각입니다. 원본의 속도는 "동작마다 모델을 부르는 구조"가 아니라 "그 호출이 1초 안에 끝나는 모델"에서 나옵니다. 하이쿠는 한 번에 2.7초가 걸립니다.
실패한 회차는 더 나빴습니다. 맥락을 지우는 설계 탓에 "메일을 이미 읽었다"는 사실을 잊고 받은편지함으로 되돌아갔고, 이전 회차가 저장한 메일을 보고 "완료"라고 잘못 판정했습니다.
여기서 방향을 틀었습니다. 모델을 잘게 부르는 대신, 능력 있는 에이전트 하나에게 좋은 도구를 쥐여 주는 쪽입니다.
3. 도구를 세 번 깎다
실제 사이트에서 막힐 때마다 고쳤습니다. 원본에 없던 것들입니다.
| 판 | 더한 것 | 계기 |
|---|---|---|
| v1 | 같은 출처 iframe 읽기, 가려진 요소 제외 | 메일 본문 칸이 목록에 없었다 |
| v2 | find, 화면 밖 요소, 변화 보고, 새 탭 추적 | 조용히 실패한 클릭을 장바구니를 열어 보고서야 알았다 |
| v3 | 입력된 칸 정확히 보고, 로딩 대기 read, 가려진 대상 재조준 | 엉뚱한 칸 값을 알려 줘 에이전트가 헤맸다 |
| v3.1 | 밀집 페이지에서 목록 줄이기 | 아마존 검색 한 페이지가 항공권 폼의 여섯 배 넘게 길었다 |
한 번은 잘못 깎았습니다
처음에는 "글자 수가 같으면 같은 모양"으로 보고 접었습니다. 그랬더니 달력 날짜와 검색 결과 제목까지 접혀 버렸습니다. 그 목록 자체가 내용인데 말입니다. 구글 항공권이 28초에서 69초로 느려졌고, 되돌린 뒤 조건을 "글자가 완전히 같을 때만"으로 좁혔습니다.
4. 측정이 세 번 거짓말했다
중간 수치들이 계속 어긋났습니다. 원인은 셋 다 도구가 아니라 측정 설계였습니다.
| 덫 | 어떻게 드러났나 | 조치 |
|---|---|---|
| 아마존 배송지가 한국 | 양쪽 모두 명령의 절반 이상을 "배송지를 미국으로 바꾸기"에 썼다 | 두 방식 모두 미국 주소가 설정된 세션에서 출발 |
| 프롬프트 문구가 한쪽에만 유리 | "명령을 이어서 치라"는 안내가 새 방식에만 있었다. 그 줄을 빼자 같은 도구가 70초로 느려졌다 | 두 방식 프롬프트를 도구 설명만 빼고 동일하게 고정 |
| 성공을 실패로 보고 | 패널이 접히듯 글자가 사라지기만 하는 변화를 "변화 없음"으로 알렸다. 에이전트가 성공한 동작을 되돌렸다 | 사라진 글자도 변화로 보고 |
이 셋을 걷어내기 전 수치는 전부 버리고, 24회를 처음부터 다시 쟀습니다.
5. 1차 결과: 실험 도구 대 기존 방식
과제 4개 × 방식 2개 × 3회. 회차마다 새 오퍼스 에이전트와 새 브라우저 세션을 썼습니다. 이 결과로 "정식 명령으로 올린다"를 결정했습니다.
| 과제 | 기존 | 새 방식 | 차이 |
|---|---|---|---|
| 네이버 메일 | 44.3 | 39.4 | -11% |
| 아마존 | 50.0 | 38.7 | -23% |
| 11번가 | 108.4 | 80.3 | -26% |
| 구글 항공권 | 103.1 | 56.8 | -45% |
단위는 초, 3회 중앙값입니다. 이 라운드는 중간에 맥이 저전력 모드로 도는 구간이 섞였습니다. 비율은 믿을 만했지만 초 단위 값이 흔들렸고, 그래서 7장에서 고성능 모드로 다시 쟀습니다.
6. 정식 명령으로 올리기
실험 도구는 크롬에 직접 붙어 있었습니다. 정식 경로는 스튜디오 브라우저 패널이 보고 있는 세션을 거쳐야 하므로, 같은 기능을 kuma agent-browser 안에 다시 지었습니다.
옮기면서 보완한 것
같은 기능을 다시 지으니 실험 도구에는 있던 것이 빠지거나, 새로 손볼 곳이 생겼습니다. 측정으로 하나씩 드러났고 모두 고쳤습니다.
| 보완한 것 | 드러난 곳 | 수리 |
|---|---|---|
| 페이지가 멈출 때까지 대기 | 로딩 중 화면을 읽고 답함 | 두 번 연속 같은 화면일 때까지 대기(최대 3초) |
| 새 탭 따라가기 | 11번가 상품이 새 탭으로 열림 | 새 탭 링크를 현재 탭으로 열게 함 |
| 스크롤 뒤 재측정 | 화면 밖 요소 클릭이 빗나감 | 스크롤했으면 한 번 더 측정 |
| 글자 수집 비용 | 밀집 페이지에서 명령이 느림 | 변화 비교가 필요할 때만 수집 |
| 오버레이 뒤 입력 대상 | 구글 항공권 출발지 | 실제 커서가 간 칸에 입력하고 그 칸 이름을 알림 |
| 좌표 클릭 라우팅 | 테스트 스위트 | --x --y는 화면, --n은 번호로 라우팅 |
| 편집기 iframe 순서 | 7장 측정, 네이버 1회 | iframe 요소를 페이지 끝이 아니라 제자리에 끼움 |
fill의 답 | 7장 측정 | 넣은 칸을 다시 읽어 "무엇이 들어 있다"고 답함 |
편집기 iframe 건은 처음에 "늦게 로딩돼서"라고 짐작했지만, 실패한 실행을 그대로 재생해 보니 아니었습니다. 편집기는 목록에 있었는데, iframe 안 요소를 페이지 맨 끝에 붙이는 바람에 사이드바 링크 뒤로 밀려 줄 수 제한에 잘렸습니다.
7. 최종 측정: 정식 명령 대 기존 방식
정식으로 올린 번호 명령을, 같은 CLI의 기존 eval 방식과 비교했습니다. 이번에는 조건을 모두 고정했습니다.
- 전원: AC 전원, 고성능 모드. 부하는 16코어에 5~7.
- 프롬프트: 과제 문구는 5장과 같고, 두 방식은 도구 설명 부분만 다릅니다.
- 동시 실행: 같은 과제의 두 방식을 동시에 돌려 부하를 같게 했고, 쌍은 한 번에 하나씩 돌렸습니다.
- 세션: 회차마다 새 오퍼스 에이전트와 새 세션. 아마존은 두 방식 모두 미국 우편번호 10001에서 출발합니다.
회차별 수치
| 과제 | 방식 | 1회 | 2회 | 3회 | 중앙 | 턴 |
|---|---|---|---|---|---|---|
| 네이버 메일 | 기존 | 34.5 | 40.2 | 38.9 | 38.9 | 8.0 |
| 번호 | 28.1 | 38.8 | 31.2 | 31.2 | 8.3 | |
| 아마존 | 기존 | 44.2 | 52.7 | 46.4 | 46.4 | 9.3 |
| 번호 | 26.8 | 22.4 | 24.0 | 24.0 | 5.7 | |
| 11번가 | 기존 | 51.5 | 53.3 | 82.9 | 53.3 | 14.7 |
| 번호 | 39.2 | 37.7 | 58.5 | 39.2 | 11.0 | |
| 구글 항공권 | 기존 | 95.7 | 52.0 | 68.3 | 68.3 | 15.7 |
| 번호 | 37.7 | 38.5 | 38.1 | 38.1 | 10.0 |
편차: 네 과제 중 셋에서 좁아졌다
11번가 한 쌍은 계정 세션 한도로 기존 방식 에이전트가 중간에 끊겼습니다. 같은 부하에서 짝을 이루지 못했으므로 그 쌍은 통째로 버리고 다시 쟀습니다. 네이버는 모델 턴이 8.0 대 8.3으로 거의 같지만, 턴 하나에 드는 시간이 짧아 여전히 빠릅니다.
8. 왜 빨라지나
도구가 빨라서가 아닙니다. 오히려 명령 하나의 고정 비용은 기존 쪽이 낮습니다.
eval 한 번snapshot 한 번시간을 지배하는 것은 모델이 생각한 횟수입니다. 기존 방식은 에이전트가 "제목 칸이 어디 있지"를 알아내려고 자바스크립트를 짜고, 결과를 읽고, 틀리면 다시 짭니다. 번호 목록은 그 질문을 아예 없앱니다.
9. 도메인 정리: 무엇이 누구 것인가
Jev 이야기와 쿠마 인프라 작업이 한데 섞여 헷갈리기 쉽습니다. 넷으로 나눕니다.
| 영역 | 정체 | 오늘 한 일 |
|---|---|---|
| Jev / jev-ultrafast 남의 것 | Browser Use의 오픈소스와 TypeSafe의 판단 전용 유료 모델 | 번호표 기법 아이디어만 가져옴(MIT, 출처 표기). 모델은 쓰지 않고 대기자 명단에만 등록 |
쿠마 에이전트 브라우저kuma agent-browser | 워커가 스튜디오 내장 브라우저를 조종하는 CLI. 브라우저 패널에 보이는 그 세션 | 번호 명령 정식 추가, 이식하며 8군데 보완, 최종 측정 12쌍 전승 |
| 쿠마피커 | 사용자 크롬 탭에 붙은 확장. 사용자가 찍은 요소 읽기 | 변경 없음 |
| 쿠마 운영 인프라 | 플랜, git 게이트, 서버 | "오케스트레이터 = 플랜 오너" 정리 완료, git 게이트가 team.json 하나 깨지면 전 세션 커밋을 막던 버그 수리, 서버 재시작 때 세션이 사라지던 버그 수리 |
10. 나중에 Jev를 붙인다면
Jev는 "지시(자연어) + 데이터 + 출력 규격"을 받아 규격 그대로 답을 돌려주는 판단 모델입니다. 넣을 자리는 딱 한 곳, "지금 화면에서 다음에 무엇을 누를지" 고르는 한 스텝입니다.
주의할 점도 있습니다. 2장의 하이쿠 실험처럼 작은 모델이 스텝마다 고르면 판단 실수로 오히려 느려질 수 있습니다. 붙일 때는 같은 네 과제로 오퍼스 단독과 비교한 뒤 들입니다.
11. 결론
판정: 정식 명령으로 올렸고, 마지막 측정으로 확인했다
번호 명령은 kuma agent-browser의 기본 사용법이 됐습니다. 고성능 모드에서 조건을 모두 고정한 마지막 측정은 24회 모두 성공했고, 12쌍 모두 번호 방식이 빨랐습니다. 중앙값 기준 20~48% 빨랐고 편차도 줄었습니다. 하나의 인터페이스로 폼, 밀집 목록, 메일 편집기, 한국과 미국 쇼핑몰을 모두 덮었습니다.
측정 범위는 밝혀 둡니다. 기계 한 대에서 하루 동안, 과제당 3회씩 잰 값입니다.