텍스트를 생성하지 않는 Jev는 어떻게 브라우저를 조작하고 UI를 구성할까? Browser Use와 json-render 해부

AI가 브라우저를 조작하게 만들 때 가장 직관적인 방식은 보통 이렇습니다. 페이지 스크린샷이나 DOM을 범용 대형 모델에 넘기고, 페이지를 분석해 다음 단계를 계획하게 한 뒤, 클릭 위치나 셀렉터 또는 도구 호출을 생성하게 합니다.

UI를 만드는 방식도 비슷합니다. 사용자가 원하는 내용을 설명하면 모델이 JSON, JSX 또는 프런트엔드 코드를 직접 생성하고, 시스템은 그 결과를 파싱하고 검증하고 렌더링하려고 합니다.

하지만 Browser Use의 Jev Ultrafast와 json-render의 Jev 실험은 다른 길을 택했습니다.

먼저 코드가 모델이 할 수 있는 일을 유한한 집합으로 제한하고, Jev는 그 안에서 선택만 합니다.

Browser Use에서 이 집합은 현재 웹페이지에서 실행할 수 있는 행동과 조작 가능한 요소입니다. json-render에서는 애플리케이션이 미리 준비한 컴포넌트, 속성 설정, 데이터 바인딩, 레이아웃 위치입니다.

Jev는 완전한 작업 계획을 작성할 필요도, UI 전체의 JSON 트리를 생성할 필요도 없습니다. 다음과 같은 질문에만 답합니다.

• 다음 단계는 클릭, 텍스트 입력, 스크롤, 대기 중 무엇이어야 하는가?
• 현재 페이지의 어떤 요소를 조작해야 하는가?
• 어떤 컴포넌트가 UI에 나타나야 하는가?
• 컴포넌트를 어떤 부모 컨테이너, 어떤 슬롯, 어떤 순서에 배치해야 하는가?

이 두 사례가 보여 주는 것은 “텍스트를 생성하지 않는 모델도 무엇이든 할 수 있다”는 주장이 아닙니다. 이들이 보여 주는 것은 다른 소프트웨어 아키텍처입니다. 즉, 열린 생성 문제를 제약되고 검증 가능한 판단의 연속으로 바꾸는 방식입니다.

여기서 Jev가 실제로 하는 일

Jev는 TypeSafe AI가 공개한 System One 모델입니다. 개발자가 정의한 typed questions와 state를 입력받아, 사람이 읽을 긴 텍스트 대신 Choice, Score, Noul 같은 구조화된 결과를 반환합니다.

확률 출력을 가진 판단 함수로 생각할 수 있습니다.

현재 상태
   ↓
개발자가 유한한 후보 집합을 구성한다
   ↓
Jev가 선택, 점수화 또는 판단한다
   ↓
일반 코드가 결과를 검증한다
   ↓
행동을 실행하거나 UI를 렌더링한다

각 항목의 의미는 다음과 같습니다.

• Choice: 주어진 선택지 중 하나를 고릅니다.
• Score: 개발자가 제시한 순서형 단계 중 어디에 해당하는지 평가합니다.
• Noul: 특정 판단이 참일 확률을 반환합니다.

핵심은 응답 형식이 아니라 책임의 경계입니다. Jev는 페이지 문구, 브라우저 셀렉터, JavaScript 또는 완전한 JSON을 자유롭게 생성하지 않습니다. 상태, 제어 흐름, 권한, 실행은 여전히 코드가 담당합니다. TypeSafe는 이 패턴을 “비정형 상태를 입력하고, 타입이 지정된 확률적 결정을 출력한다”고 설명합니다. (typesafe.ai)

이제 Browser Use와 json-render가 이 패턴을 실제 시스템에 어떻게 적용하는지 살펴보겠습니다.

---

Browser Use: 먼저 웹페이지를 유한한 행동 공간으로 바꾸기

Browser Use의 jev-ultrafast 프로젝트는 브라우저 에이전트를 보여 줍니다. 사용자가 자연어로 목표를 주면 프로그램이 현재 페이지를 읽고, Jev가 다음 행동을 선택하며, 브라우저 코드가 이를 실행합니다.

공개 데모의 과제는 Google Flights에서 Zürich에서 London으로 가는 편도 항공편을 찾는 것입니다. 프로젝트가 보고한 녹화 결과는 약 7.1초이며, 여기에는 모델 호출, 텍스트 생성, 브라우저 실행, 페이지 로딩, 오래된 판단으로 인한 재시도가 포함됩니다. 그러나 이는 한 가지 브라우저 설정에서 수행한 한 가지 과제일 뿐이며, 임의의 웹사이트에 대한 일반적인 신뢰성 벤치마크는 아닙니다. (github.com)

1단계: 페이지를 읽는 것은 코드이며, Jev가 단순히 “이미지를 보는” 것이 아니다

각 판단 주기에서 브라우저 코드는 먼저 현재 페이지에서 보이는 컨트롤과 텍스트를 읽고, 번호가 붙은 요소 표를 만듭니다.

단순화하면 다음과 같습니다.

[1] button     항공권 유형 변경 · 왕복
[2] combobox   출발지는?       · San Francisco
[3] combobox   도착지는?       · 비어 있음
[4] textbox    출발일          · 비어 있음
[5] button     검색

이 표에는 요소 유형, 이름, 현재 값, 번호가 들어갑니다. 프로그램은 각 번호에 연결된 실제 DOM 노드도 보관하여 실행 직전에 대상을 다시 확인할 수 있게 합니다.

이 사례에서 Jev는 스크린샷을 직접 보고 버튼이 좌표 (482, 316)에 있다고 추측하지 않습니다. 스크린샷은 주로 데모와 사람이 확인하는 용도로 사용됩니다. 실제 판단을 구동하는 것은 DOM에서 추출한 구조화 상태입니다. 프로젝트도 페이지의 번호 표시가 스크린샷 렌더링 단계에서 추가되며 브라우저를 구동하는 데 쓰이지 않는다고 명시합니다. (github.com)

이 차이는 중요합니다.

모델이 좌표나 CSS Selector를 자유롭게 생성하게 하면 다음과 같은 결과를 반환할 수 있습니다.

• 페이지에 존재하지 않는 셀렉터.
• 이미 오래된 요소 위치.
• 다른 콘텐츠에 가려졌거나 클릭할 수 없는 컨트롤.
• 임의의 동작을 실행할 수 있는 JavaScript.

반면 Jev Ultrafast에서는 모델이 프로그램이 방금 관찰한 요소 번호 중에서만 선택할 수 있습니다.

2단계: Jev가 행동과 대상 요소를 선택한다

프로젝트가 제공하는 행동 집합은 다음과 같습니다.

CLICK
TYPE_TEXT
SELECT
SCROLL_UP
SCROLL_DOWN
WAIT
DONE
BLOCKED

프로그램은 현재 페이지 상태에 따라 그 시점에 실제로 사용할 수 있는 행동과 호환되는 대상만 모델에 제공합니다.

예를 들면 다음과 같습니다.

• 현재 페이지에 드롭다운이 없으면 SELECT 대상을 제공하지 않습니다.
• 텍스트 필드가 세 개면 입력 대상은 그 세 요소로 제한됩니다.
• 클릭 가능한 요소가 열 개면 클릭 대상은 그 열 요소로 제한됩니다.

한 번의 판단은 다음처럼 단순화할 수 있습니다.

질문 1: 다음 행동은 무엇이어야 하는가?
후보: CLICK / TYPE_TEXT / SELECT / WAIT / DONE

질문 2: 행동이 CLICK이라면 어떤 요소를 클릭해야 하는가?
후보: [1] / [5] / [8] / [11]

질문 3: 행동이 TYPE_TEXT라면 어떤 요소에 텍스트를 입력해야 하는가?
후보: [2] / [3] / [4]

이 질문들은 한 번의 요청 안에서 병렬로 판단할 수 있습니다. 실제로 실행되는 것은 선택된 행동과 호환되는 대상뿐입니다. Jev가 CLICK을 선택하면 프로그램은 click_target만 읽고, TYPE_TEXT용으로 미리 계산된 대상은 실행하지 않습니다.

프로젝트는 이를 동적이고 인덱스가 부여된 행동 공간이라고 부릅니다. 이 설계는 각 단계에 필요한 직렬 모델 호출을 줄이고, 모델이 작업 매개변수를 자유롭게 생성하지 못하게 합니다. (github.com)

3단계: 글자를 써야 할 때만 생성 모델을 호출한다

Jev는 “지금 출발지 입력란에 내용을 입력해야 한다”고 판단할 수 있지만, 실제로 입력할 텍스트는 생성하지 않습니다.

행동이 TYPE_TEXT일 때만 시스템이 소형 텍스트 생성 모델을 호출하고, 현재 과제와 대상 필드에 따라 입력값을 만듭니다. 예를 들면 다음과 같습니다.

{
  "text": "Zürich"
}

이 결과도 브라우저가 입력하기 전에 작은 JSON 객체로 파싱되어야 합니다.

따라서 이 브라우저 에이전트는 서로 다른 두 가지 능력을 결합합니다.

작업	담당
다음 단계가 클릭, 입력, 선택, 대기 중 무엇인지 판단	Jev
페이지의 어떤 요소를 조작할지 선택	Jev
입력할 자연어 텍스트 생성	소형 생성 모델
DOM과 페이지 상태 읽기	브라우저 코드
클릭, 입력, 선택 실행	브라우저 코드
목표가 실제로 완료되었는지 확인	독립 검증 코드

따라서 “Jev가 브라우저를 조작한다”는 표현은 Jev가 브라우저 작업 전체를 혼자 완료한다는 뜻이 아닙니다.

더 정확히 말하면, Jev는 브라우저 루프 안의 행동 선택기입니다.

4단계: 실행 전에 코드가 페이지를 다시 확인한다

모델이 선택을 반환해도 프로그램은 곧바로 무작정 클릭하지 않습니다.

Jev Ultrafast는 실행 전에 다음도 확인합니다.

• 현재 페이지가 모델이 판단할 때 본 페이지와 여전히 같은지.
• 해당 DOM 노드가 아직 존재하는지.
• 요소가 다른 콘텐츠에 가려져 있지 않은지.
• 현재 위치와 크기가 여전히 유효한지.
• 폼 값과 주변 문맥이 스냅샷과 일치하는지.
• 텍스트 생성 요청의 입력이 바뀌지 않았는지.

모델 응답이 돌아오기 전에 페이지가 바뀌면 기존 판단은 이미 무효일 수 있습니다. 프로그램은 이를 오래된 판단으로 처리하고 이전 요소를 계속 조작하지 않습니다.

프로젝트는 모델 출력이 직접 될 수 있는 것을 명확히 제한합니다. 모델 출력은 그대로 CSS Selector, 화면 좌표, Shell 명령 또는 실행 가능한 JavaScript가 되지 않습니다. 실제로 실행할 모든 대상은 이전에 관찰한 진짜 DOM 노드로 다시 해석되어야 합니다. (github.com)

이 코드는 그 자체로 “지능적”이지 않지만, 시스템의 신뢰성을 결정합니다.

7초라는 속도를 Jev만의 성과로 볼 수는 없다

프로젝트는 교대로 수행한 여섯 번의 실행에서 두 구현이 각각 세 번씩 과제를 완료했다고 보고합니다. 과제 시간 중앙값은 약 9.450초에서 7.092초로 줄어 약 25% 감소했고, 브라우저 프로토콜 호출은 1,092회에서 101회로 줄었습니다. 동시에 저자는 동일한 과제와 동일한 브라우저 설정에서 구현별로 세 번 실행한 결과일 뿐, 일반적인 신뢰성 테스트가 아니라고 강조합니다. (github.com)

따라서 성능 향상은 모델 속도뿐 아니라 브라우저 구현 전체에서 나옵니다.

• 보이는 컨트롤을 한 번에 읽습니다.
• 브라우저 프로토콜 왕복을 줄입니다.
• 행동과 대상 질문을 같은 판단 요청에 넣습니다.
• 텍스트 입력이 필요할 때만 생성 모델을 호출합니다.
• 실행 후 필요한 페이지 변화만 기다립니다.
• 관련 없는 페이지 본문을 모델 컨텍스트에 넣지 않습니다.

그러므로 “모델을 Jev로 바꾸면 모든 브라우저 에이전트가 7초 안에 과제를 끝낸다”고 결론 내릴 수는 없습니다.

현재 MVP는 shadow DOM, iframe, canvas, 파일 업로드, 팝업 탭, 중첩 스크롤, 임의의 키보드 위젯을 완전히 지원하지 않습니다. 모델이 DONE을 선택해도 시스템은 과제가 실제로 완료되었는지 별도로 확인합니다. (github.com)

---

json-render: 페이지 전체 JSON을 생성하지 않고 Jev가 컴포넌트를 선택하게 하기

json-render는 다른 문제를 다룹니다. 자연어 요구에서 바로 렌더링할 수 있는 UI를 어떻게 구성할 것인가라는 문제입니다.

기존 생성형 UI는 모델에 다음을 직접 출력하게 하는 경우가 많습니다.

• React 또는 Vue 코드.
• 완전한 JSON UI 트리.
• CSS와 레이아웃 속성.
• 이벤트 처리 로직.
• 데이터 바인딩 설정.

이 방식은 유연하지만 모델의 출력 공간도 매우 큽니다. 모델이 컴포넌트 이름을 잘못 쓰거나, 존재하지 않는 속성을 만들거나, 등록되지 않은 행동을 참조하거나, 파싱할 수 없는 JSON을 반환할 수 있습니다.

json-render의 Jev 실험은 문제를 다음처럼 바꿉니다.

애플리케이션이 먼저 유효한 컴포넌트 인스턴스 모음을 준비하고, Jev는 무엇을 사용하고 어떻게 조합할지만 결정한다.

이 기능은 현재도 실험적으로 표시되어 있습니다. experimental_composeSpec와 experimental_createEvaluator는 안정 API로 출시되지 않았으며, 버전이 바뀌면서 이름과 동작이 달라질 수 있습니다. 공식 문서는 정확한 버전을 고정하고 변경 기록을 확인하라고 권장합니다. (json-render.dev)

애플리케이션이 먼저 컴포넌트 카탈로그와 후보를 제공한다

사용자가 다음과 같이 요청했다고 가정해 보겠습니다.

매출 대시보드를 만들어 주세요. 위에는 주문 표를 두고, 그 아래에는 매출, 주문 수, 신규 고객 지표를 한 줄로 배치하며, 마지막에는 주간 매출 그래프를 넣어 주세요.

애플리케이션은 이 문장을 그대로 Jev에 넘겨 UI JSON을 자유롭게 작성하게 하지 않습니다.

대신 먼저 후보를 제공합니다.

Dashboard
OrdersTable
MetricRow
RevenueMetric
OrdersMetric
NewCustomersMetric
RevenueBarGraph

각 후보는 단순한 이름이 아니라 애플리케이션이 구성한 컴포넌트 인스턴스입니다. 다음을 포함할 수 있습니다.

• 컴포넌트 유형.
• 고정 속성.
• 사용 가능한 레이아웃 설정.
• 상태 바인딩.
• 데이터 바인딩.
• 호출이 허용된 행동.
• 모델용 후보 설명.

예를 들어 버튼 후보는 미리 다음처럼 정의할 수 있습니다.

컴포넌트: Button
텍스트: 저장
행동: savePreferences
인수: 현재 /name 상태 읽기

Jev는 이 버튼을 사용할지 선택할 수 있지만, 등록되지 않은 deleteAllUsers 행동을 새로 만들 수는 없습니다.

json-render 공식 설명은 사용 가능한 기능과 디자인 시스템을 플랫폼이 통제한다고 강조합니다. Jev는 애플리케이션이 제공한 컴포넌트, 설정, 행동 바인딩 중에서만 선택할 수 있습니다. 누락된 문구, 데이터, 컴포넌트를 Jev가 자동으로 만드는 것은 아닙니다. (json-render.dev)

1단계: UI에 필요한 컴포넌트를 선택한다

새 UI를 만들 때 첫 번째 판단 묶음은 다음을 처리합니다.

• 어떤 후보를 루트 노드로 삼을지.
• 어떤 컴포넌트를 선택할지.
• 재사용 가능한 컴포넌트가 몇 개 필요한지.
• 같은 리소스에 여러 변형이 있다면 어떤 것을 선택할지.

예를 들면 다음과 같습니다.

루트 컴포넌트: Dashboard

포함:
- OrdersTable
- MetricRow
- RevenueMetric
- OrdersMetric
- NewCustomersMetric
- RevenueBarGraph

선택이 끝나면 일반 코드가 즉시 초기 Spec를 조립하고, 컴포넌트 속성과 행동 인수를 catalog schema에 맞춰 검사하며, 이미 렌더링할 수 있는 미리보기를 스트리밍합니다.

이 시점의 레이아웃은 아직 컴포넌트 카탈로그 순서를 따를 수 있지만, 사용자는 구조적으로 유효한 중간 결과를 이미 볼 수 있습니다.

이는 모델이 전체 JSON을 토큰 단위로 출력하는 방식과 다릅니다. Jev는 직렬화된 JSON을 작성하지 않습니다. 코드가 제한된 선택 결과에서 JSON을 조립합니다. (json-render.dev)

2단계: 부모-자식 관계와 순서를 결정한다

컴포넌트를 선택한 뒤 두 번째 판단 묶음이 레이아웃을 처리합니다.

• 각 컴포넌트가 어느 부모 노드에 속하는지.
• 부모의 어떤 이름 있는 슬롯에 들어가는지.
• 형제 컴포넌트의 순서를 어떻게 정하는지.

최종 구조는 다음처럼 될 수 있습니다.

Dashboard
├── OrdersTable
├── MetricRow
│   ├── RevenueMetric
│   ├── OrdersMetric
│   └── NewCustomersMetric
└── RevenueBarGraph

그다음 코드는 다음을 확인합니다.

• 유효한 루트가 정확히 하나인지.
• 부모-자식 순환이 생기지 않았는지.
• 깊이가 제한을 넘지 않았는지.
• 컴포넌트가 유효한 슬롯에 배치되었는지.
• 각 후보가 허용된 횟수만큼 사용되었는지.
• 모든 속성, 바인딩, 행동 인수가 schema 검증을 통과하는지.

조립된 레이아웃이 일관되지 않으면 시스템은 손상된 UI 트리를 출력하지 않고, 직전에 검증한 미리보기를 유지합니다.

루트가 하나뿐이거나 단일 슬롯에 자식 하나만 있는 단순한 구조라면 두 번째 레이아웃 판단이 필요하지 않을 수도 있습니다. (json-render.dev)

UI 편집도 “선택”이지 전체 재작성은 아니다

json-render는 기존 Spec도 편집할 수 있습니다. 예를 들면 다음과 같습니다.

• 저장 버튼 삭제.
• 주문 표를 그래프 위로 이동.
• 한 그래프 유형을 제공된 다른 후보로 교체.
• 필드 순서 변경.
• 컴포넌트 설정 교체.

이런 편집은 보통 순차적인 절차를 따릅니다.

1. 변경할 요소를 선택합니다.
2. 새 컴포넌트 레시피 또는 이동 대상을 선택합니다.
3. 코드가 변경을 적용합니다.
4. 전체 트리를 다시 검증합니다.

변경되지 않은 컴포넌트 ID, 상태 바인딩, 데이터, 호환되는 자식 노드는 가능한 한 유지됩니다. 입력 Spec 자체를 직접 변경하지 않습니다. (json-render.dev)

버튼을 선택했다고 해서 자동으로 실행되는 것은 아니다

json-render는 “UI 구성”과 “비즈니스 행동 실행”을 명확히 분리합니다.

Jev는 savePreferences에 연결된 버튼을 선택할 수 있지만, composer 자체가 그 행동을 호출하지는 않습니다. 실제 실행은 사용자가 클릭한 뒤에 일어나며, 호스트 애플리케이션의 action handler가 담당합니다.

애플리케이션에는 여전히 다음이 필요합니다.

• 사용자 권한 확인.
• 인수 검증.
• 서버 측 인가.
• 데이터 유효성 검사.
• 멱등성과 감사 로그.
• 위험한 작업에 대한 추가 확인.

공식 문서는 행동을 카탈로그에 등록했다고 해서 임의의 인수를 안전하게 받을 수 있는 것은 아니라고 분명히 경고합니다. composer는 미래의 런타임 상태를 검증할 수 없고, 애플리케이션을 대신해 인가를 수행하지도 않습니다. (json-render.dev)

구조가 유효하다고 UI가 반드시 올바른 것은 아니다

json-render는 출력이 지원하는 구조와 schema를 따른다는 점은 보장할 수 있지만, Jev가 선택한 UI가 완전하고 합리적이며 보기 좋다는 점까지 보장할 수는 없습니다.

공식 문서의 예시는 다음과 같습니다.

상단에 표가 있는 대시보드를 생성해 주세요

이 요청은 지표와 그래프를 명시하지 않았기 때문에 표만 선택할 수 있습니다.

더 구체적인 요청은 다음과 같습니다.

매출 대시보드를 만들어 주세요:
상단에 주문 표를 배치한다;
그 아래에 매출, 주문, 신규 고객 지표를 한 줄로 배치한다;
마지막에 주간 매출 그래프를 배치한다.

이렇게 요청하면 필요한 후보를 모두 선택하고 기대한 순서로 배치할 가능성이 더 높습니다.

여기에는 중요한 경계가 있습니다. Jev는 후보 공간 안에서만 판단할 수 있습니다. 후보 공간을 완전하게 만들고 요구를 명확히 표현하는 책임은 개발자에게 남아 있습니다.

공개 문서의 재사용 API는 기본적으로 최대 32회 평가, 한 배치에서 최대 32개 요소 생성, 최대 깊이 8을 사용합니다. 공개 Playground는 더 엄격하게 한 배치 최대 14개 요소, 14회 평가, 깊이 4로 제한합니다. 호출 수, 요소 수, 깊이 제한에 도달하면 시스템은 부분 Spec를 반환할 수 있지만, “절차가 끝났다”는 사실이 의미적으로 올바르다는 뜻은 아닙니다. (json-render.dev)

---

두 사례는 사실 같은 아키텍처를 사용한다

Browser Use와 json-render를 나란히 놓으면 다루는 문제는 다르지만 구조는 거의 같습니다.

단계	Browser Use	json-render
사용자 목표	항공편 검색, 폼 작성, 페이지 열기	UI 생성 또는 수정
코드가 읽는 상태	보이는 DOM, 컨트롤, 텍스트, 값	현재 Spec, 컴포넌트 후보, 카탈로그, 트리 구조
유한한 후보 공간	클릭, 입력, 선택, 스크롤, 조작 가능한 요소	컴포넌트 인스턴스, 부모, 슬롯, 순서
Jev의 역할	행동과 대상 선택	컴포넌트, 부모-자식 관계, 순서 선택
생성 모델의 역할	입력이 필요할 때만 텍스트 생성	Jev 경로에서는 UI를 자유 생성하지 않음. 새 문구와 데이터는 미리 제공하거나 별도로 생성해야 함
일반 코드의 역할	DOM 스냅샷, 최신성 확인, 실행, 대기, 결과 검증	Spec 조립, schema 검증, 트리 검증, 렌더링, 행동 인가
주요 실패 방식	오래된 페이지 상태, 대상 소실, 미지원 컨트롤	후보 부족, 모호한 요청, 불완전한 레이아웃, 잘못된 선택
최종 검증	과제 목표가 실제로 완료되었는지 확인	Spec가 완전하고 사용 가능하며 제품 요구에 맞는지 확인

두 사례 모두 같은 공식을 따릅니다.

환경을 구조화 상태로 바꾼다
        ↓
할 수 있는 일을 유한한 후보 집합으로 바꾼다
        ↓
Jev가 선택하게 한다
        ↓
코드가 검증하고 실행한다
        ↓
결과를 다시 관찰한다

모델이 다음 단계를 자유롭게 생성하는 방식과 비교하면 일부 유연성을 포기하는 대신 통제 경계가 더 명확해집니다.

---

텍스트를 생성하지 않아도 왜 “지능적”으로 보일까

지능이 반드시 글, 코드, 대화 형태로 표현되어야 하는 것은 아닙니다.

많은 소프트웨어 흐름에서 시스템이 실제로 필요한 것은 판단 하나입니다.

• 지금 어떤 버튼을 눌러야 하는가?
• 이 요소를 어느 영역에 놓아야 하는가?
• 실행을 계속해야 하는가?
• 어떤 컴포넌트 설정이 사용자 요구와 가장 잘 맞는가?
• 현재 결과가 목표를 달성했는가?

범용 LLM은 먼저 설명을 생성하고, 그 답을 JSON으로 감쌀 수 있습니다. 그러나 최종적으로 코드가 하나의 선택지만 필요로 한다면, 중간의 긴 텍스트 생성은 가치가 없을 수 있습니다.

Browser Use와 json-render 실험은 “생각하는 과정”의 상당 부분을 시스템 설계로 옮깁니다.

• 개발자가 상태를 정의합니다.
• 개발자가 후보 공간을 정의합니다.
• 개발자가 실행 규칙을 정의합니다.
• 일반 규칙으로 다루기 어려운 의미 판단만 모델이 채웁니다.

이 아키텍처는 오류를 없애는 것이 아니라 오류의 형태를 바꿉니다.

Jev는 후보 집합에 없는 컴포넌트나 행동을 반환하지 않지만, 여전히 다음과 같은 실수를 할 수 있습니다.

• 잘못된 버튼 선택.
• 잘못된 컴포넌트 선택.
• 너무 이른 완료 선언.
• 여러 합리적인 레이아웃 중 더 좋지 않은 것 선택.
• 요청이 모호해 필요한 내용 누락.

타입 안전성은 인터페이스를 보장할 뿐 진실을 보장하지 않습니다. 제공된 조사 보고서도 제한된 구조가 올바른 비즈니스 판단을 보장하지 않는다고 강조합니다. 질문 설계, 상태 모델링, 임계값, 독립 검증은 프로덕션 시스템에서 여전히 핵심입니다.

---

어떤 작업이 이 패턴에 맞는가

Browser Use와 json-render는 실용적인 판단 기준을 제공합니다.

작업을 “유한한 후보 중에서 선택하기”로 분해할 수 있다면, 그 판단 노드를 Jev에 맡길 수 있습니다.

비교적 잘 맞는 작업은 다음과 같습니다.

• 브라우저와 데스크톱 애플리케이션의 행동 선택.
• 에이전트 도구와 스킬 라우팅.
• 통제된 컴포넌트 카탈로그에서 UI 구성.
• 후보 레이아웃 중 선택.
• 이메일, 지원 티켓, 문서 분류.
• 후보 증거에서 관련 내용 선택.
• 결과를 재시도할지 사람에게 넘길지 판단.

다음 작업은 Jev에 직접 맡기지 않는 편이 좋습니다.

• 긴 글이나 고객 지원 답변 작성.
• 후보 집합에 없는 새 문구 생성.
• 완전히 새로운 시각 시스템을 자유롭게 설계.
• 복잡한 프로그램 작성.
• 다단계 산술이나 날짜 계산.
• 후보 행동이 없을 때 해결책 발명.
• 긴 추론 연쇄와 열린 계획이 필요한 작업.

실제 제품은 보통 여러 모델을 조합해야 합니다.

범용 모델: 목표, 텍스트, 코드 또는 후보 계획 생성
Jev: 후보 판단, 필터링, 라우팅
일반 코드: 검증, 실행, 폴백, 기록

Browser Use의 소형 텍스트 모델은 이 분업을 직접 보여 줍니다. Jev가 “입력해야 한다”고 판단하고, 생성 모델이 “무엇을 입력할지” 결정합니다.

---

진짜 배워야 할 것은 두 데모가 아니라 책임 분리다

Browser Use와 json-render에서 가장 재사용할 가치가 큰 교훈은 “Jev가 웹을 탐색할 수 있다”거나 “Jev가 UI를 생성할 수 있다”는 것이 아닙니다.

더 정확한 결론은 다음과 같습니다.

• Browser Use는 브라우저 조작을 자유 생성에서 실제 DOM 요소에 대한 행동 선택으로 바꿨습니다.
• json-render는 UI JSON 자유 작성을 애플리케이션 자체 컴포넌트 카탈로그의 선택과 정렬로 바꿨습니다.
• Jev는 의미 판단을 제공합니다.
• 코드는 권한을 제한하고 상태를 유지하며 구조를 검증하고 결과를 실행합니다.
• 열린 텍스트가 필요할 때는 생성 모델이 계속 담당합니다.

이 아키텍처에서 AI는 시스템의 유일한 운전자가 아니라 코드가 통제하는 흐름 속의 한 판단 노드가 됩니다.

AI를 실제 프로덕션 소프트웨어에 넣으려는 팀에게는 모델이 한 번에 완전한 답을 만들 수 있는지보다 이 점이 더 중요할 수 있습니다. 시스템의 신뢰성은 모델이 무엇을 선택했는지만이 아니라 다음에도 달려 있습니다.

• 모델에게 어떤 상태를 보여 줬는가.
• 개발자가 어떤 후보를 제공했는가.
• 시스템이 어떤 행동을 허용하는가.
• 잘못된 결과를 차단할 수 있는가.
• 페이지나 UI가 바뀐 뒤 다시 판단할 수 있는가.
• 완료 상태를 독립적으로 검증했는가.

텍스트를 생성하지 않는다고 Jev가 아무것도 못 하는 것은 아닙니다.

그 의미는 모델의 지능이 주로 문자열이 아니라 소프트웨어가 직접 소비할 수 있는 선택의 집합으로 표현되며, 동시에 신중한 검증이 필요하다는 것입니다.