우리는 브라우저 자동화의 느림이 JavaScript 래퍼 때문이라고 보았습니다. DOM을 밖에서 직렬화하고, 에이전트 런타임이 이를 해석하고, 행동을 다시 주입하는 구조는 각 단계에서 비용을 더합니다.
대신 우리는 Chromium에 additive patch 시리즈로 엔진 드리븐 API를 추가했습니다. 페이지 상태를 시맨틱 구조로 직렬화하는 snapshot 경로가 엔진 안에 있으므로, 스냅숏 비용이 페이지 크기에 비례하지 않습니다. 측정에서 소규모와 대형 픽스처 모두 ~14–16ms 대역에 머물렀습니다.
통제는 속도와 상충하지 않았다는 점이 이 리포트의 핵심입니다. 관찰→분류→파킹→승인→dispatch의 governed cycle이 엔진 시간 기준 25ms 미만이었고, 그중 사람 승인 이후 dispatch까지는 2ms 미만이었습니다. 승인 게이트가 엔진 레벨에 있어도 실시간 상호작용이 가능합니다.
측정 한계를 명시합니다. 이 수치들은 디버그 빌드에서 소규모 픽스처로 얻은 것입니다. 프로덕션 빌드의 최적화, 실제 웹 페이지의 복잡성, 네트워크 변동은 결과를 바꿀 수 있습니다. 우리는 이 수치를 외삽(extrapolation)하지 않고, 프로덕션 측정이 준비되면 별도 리포트로 공개할 것입니다.
측정 조건과 한계
- 시맨틱 스냅숏 지연
디버그 빌드, 소규모 픽스처 페이지 기준 내부 측정치. 프로덕션 빌드·실서비스 페이지에서는 다를 수 있음.
- governed cycle (observe→classify→park→approve→dispatch)
engine time 기준. 네트워크·렌더링 시간 제외. 디버그 빌드 내부 측정.
- approve→dispatch
engine time 기준, 디버그 빌드 내부 측정.