Selenium 덕분에 커리어에 큰 변화를 겪었음. 진심으로 고마움을 전함
요즘은 Playwright를 쓰고 있지만, Vibium의 새로운 접근이 궁금함
Playwright는 WebSockets+JSON 기반의 빠른 브라우저 제어로 큰 진전을 이뤘음. Vibium은 이에 대응하는 W3C WebDriver BiDi 표준을 사용 중임. 목표는 Playwright처럼 “클릭 몇 번이면 끝나는” 멋진 개발 경험을 제공하는 것임
이미 Playwright를 쓰고 있다면 Stagehand를 써보길 추천함. API는 유사하지만 테스트용이 아닌 자동화용으로 설계됨
Vibium이 JS 주입, DOM 수정, 네트워크 요청 감시·변경을 지원하는지 궁금함. Playwright를 쓸 때 거의 항상 이 기능들을 사용함
아직은 지원하지 않지만, 로드맵에 포함되어 있음. Playwright의 장점을 받아들이고 그 이상을 확장하는 것이 목표임
개인적으로는 네트워크 요청 모니터링만 있어도 충분함. Flutter + Amazon AppSync 앱은 디버깅이 너무 어려움
흥미로움. 최근 dev-browser를 사용해 컨텍스트 절약과 속도 향상을 얻고 있었음. Vibium도 꼭 시도해볼 예정임
Vibium에서도 이런 skill 기반 확장성을 지원할 계획임
10년 넘게 UI 자동화로 생계를 이어온 입장에서 Selenium에 감사함. 지금은 Playwright가 사실상 표준이지만, Selenium이 원조 브라우저 드라이버였음. Vibium은 Playwright와 어떻게 다른지 궁금함
Playwright가 “속도” 면에서는 앞서지만, Selenium은 여전히 전 세계적으로 깊게 뿌리내린 생태계를 가짐. Vibium은 Selenium 사용자들이 자연스럽게 미래형 에이전트 코딩으로 넘어갈 수 있는 다리를 만들 계획임
예전에 Selenium으로 Atlassian의 테스트 확장을 도왔던 사람임. 13~15년 전쯤 대화했던 기억이 있음. 여전히 이 분야에서 활동 중이라 반가움
오래된 Selenium 스크립트를 Vibium으로 옮기면 테스트 실패 시 자가 복구(self-heal) 기능을 활용할 수 있을지 궁금함
비유하자면, 나는 지금 섬 리조트를 짓는 중임. 다리(마이그레이션 경로)는 나중에 만들 예정임. 우선 리조트가 매력적이면 다리를 놓을 이유가 생길 것임. 지금은 리조트 건설에 집중 중이지만, 다리도 꼭 만들고 싶음
에이전트가 browser_screenshot으로 화면을 캡처한 뒤 클릭하려면 CSS 셀렉터를 어떻게 찾는지 궁금함. 스크린샷만으로는 요소 타입을 알기 어려움
현재 MCP 서버는 완전한 자율 탐색 기능이 부족함. 내 포크에서는 browser_evaluate 도구를 추가해 JS로 접근성 트리를 가져오고 이를 기반으로 탐색 가능하게 했음. 자세한 내용은 V2 로드맵 참고 바람
Claude 같은 도구가 브라우저 자동화를 자유롭게 쓰게 하려면, 특정 URL만 허용하는 브라우저 잠금 기능이 필요함. 이런 기능이 로드맵에 있는지 궁금함
Claude Code를 쓴다면 browser_navigate 훅으로 간단히 제어 가능함. 화이트리스트용 스크립트는 5분이면 설정 가능함. 더 복잡한 정책은 cupcake와 Rego로 구현 가능함. 참고: Claude Code Hooks 문서
Claude의 “blast radius” 위험성을 잘 알고 있음. 나도 Vibium 개발은 UTM VM 안에서 함. 네트워크 규칙 추가도 고려 중임. 이미 V2 로드맵을 올렸고, V3 초안도 준비해야 할 듯함
가장 확실한 방법은 방화벽이 있는 컨테이너 안에서 짧은 화이트리스트만 허용하는 것임
Skyvern과 비슷한 걸 만들 생각이었는데, 왜 Selenium 확장이 아니라 새로운 Vibium을 만든 이유가 궁금함
Vibium v1 발표문에 일부 설명했음. Selenium이나 Playwright는 AI 중심 설계가 아니었음. Vibium은 처음부터 AI 기반 “vibe coding” 을 위해 최적화된 구조로 설계됨
브라우저와 LLM 간의 컨텍스트 부하(context bloat) 문제를 어떻게 처리하는지 궁금함. Playwright처럼 트레이싱 파일을 노출하거나 JS 실행을 허용할 계획이 있는지도 물음
브라우저 노출은 점차 확대할 예정임. 컨텍스트 부하는 아직 완벽히 해결된 곳이 없음. 장기적으로는 “MCP를 쓰지 않는 방향”이 답일 수도 있음. 현재 Vibium은 MCP 서버와 JS/TS API 두 가지를 제공함. JS/TS API에서는 임의의 JS 실행이 가능함. 에이전트가 Vibium 스크립트를 작성해 실행하도록 하는 방식이 컨텍스트 부하를 줄이는 우회로가 될 수도 있음
Hacker News 의견들
Selenium 덕분에 커리어에 큰 변화를 겪었음. 진심으로 고마움을 전함
요즘은 Playwright를 쓰고 있지만, Vibium의 새로운 접근이 궁금함
Vibium이 JS 주입, DOM 수정, 네트워크 요청 감시·변경을 지원하는지 궁금함. Playwright를 쓸 때 거의 항상 이 기능들을 사용함
흥미로움. 최근 dev-browser를 사용해 컨텍스트 절약과 속도 향상을 얻고 있었음. Vibium도 꼭 시도해볼 예정임
10년 넘게 UI 자동화로 생계를 이어온 입장에서 Selenium에 감사함. 지금은 Playwright가 사실상 표준이지만, Selenium이 원조 브라우저 드라이버였음. Vibium은 Playwright와 어떻게 다른지 궁금함
예전에 Selenium으로 Atlassian의 테스트 확장을 도왔던 사람임. 13~15년 전쯤 대화했던 기억이 있음. 여전히 이 분야에서 활동 중이라 반가움
오래된 Selenium 스크립트를 Vibium으로 옮기면 테스트 실패 시 자가 복구(self-heal) 기능을 활용할 수 있을지 궁금함
에이전트가
browser_screenshot으로 화면을 캡처한 뒤 클릭하려면 CSS 셀렉터를 어떻게 찾는지 궁금함. 스크린샷만으로는 요소 타입을 알기 어려움browser_evaluate도구를 추가해 JS로 접근성 트리를 가져오고 이를 기반으로 탐색 가능하게 했음. 자세한 내용은 V2 로드맵 참고 바람Claude 같은 도구가 브라우저 자동화를 자유롭게 쓰게 하려면, 특정 URL만 허용하는 브라우저 잠금 기능이 필요함. 이런 기능이 로드맵에 있는지 궁금함
browser_navigate훅으로 간단히 제어 가능함. 화이트리스트용 스크립트는 5분이면 설정 가능함. 더 복잡한 정책은 cupcake와 Rego로 구현 가능함. 참고: Claude Code Hooks 문서Skyvern과 비슷한 걸 만들 생각이었는데, 왜 Selenium 확장이 아니라 새로운 Vibium을 만든 이유가 궁금함
브라우저와 LLM 간의 컨텍스트 부하(context bloat) 문제를 어떻게 처리하는지 궁금함. Playwright처럼 트레이싱 파일을 노출하거나 JS 실행을 허용할 계획이 있는지도 물음