제 자동화 시리즈의 이전 블로그(previous blog)는 다음을 수행하는 방법에 대한 첫 단계였습니다:

• Vibium 설치하기
• 로그인 시나리오 기록하기
• 기록된 테스트 시각화하기

새롭게 다듬어진 Vibium은 Go로 작성되었으며 JS/TS, Python, Java 클라이언트 라이브러리를 갖춘 오픈 소스(open source) 자동화 도구입니다.

이 블로그 게시물에서는 다음 내용을 다룰 것입니다:

목차

• 프로토콜 선택: 왜 WebDriver BiDi인가
• 시스템 아키텍처
• 데몬 모드
• Vibium MCP 및 SKILLs 사용하기
• AI 에이전트의 신뢰성 대 속도
• 마무리

프로토콜 선택: 왜 WebDriver BiDi인가

Vibium의 설계는 CLI(Command Line Interface)를 선택했기 때문이 아니라, 그 밑에서 사용되는 프로토콜 때문입니다.

브라우저 자동화는 세 가지 프로토콜 세대를 거쳐 왔습니다:

WebDriver (2004년–현재): Selenium의 기반입니다. HTTP + JSON을 사용하며 요청/응답 모델로 브라우저를 일방향으로 제어합니다. 즉, 질문을 받았을 때만 브라우저가 응답합니다.

Chrome DevTools Protocol (2017년–현재): CDP는 HTTP를 WebSockets로 교체했으며, 이로 인해 양방향 통신이 가능해졌습니다. 브라우저는 로그, 네트워크 활동, DOM 변경과 같은 이벤트를 실시간으로 보내고 받을 수 있습니다. Puppeteer와 Playwright 모두 CDP를 기반으로 구축되었지만, 이는 Chrome 내부용입니다.

WebDriver BiDi (2021년–현재): W3C가

• Chrome/Chromium은 ChromeDriver를 통해 BiDi를 지원합니다.
• Firefox는 네이티브 지원(native support)을 제공합니다.
• Edge는 Chromium의 지원을 상속받습니다.
• Safari의 지원은 개발 중입니다.

도구 생태계는 단순히 Vibium뿐만 아니라, 이 프로토콜(protocol)로 수렴하고 있습니다.

시스템 아키텍처 (System Architecture)

Vibium은 단일 컴파일된 바이너리(single compiled binary)로 제공됩니다. 이는 다음을 의미합니다:

• CLI에서 직접 호출할 수 있습니다.
• MCP 서버를 사용하고 이를 에이전트 호스트(agent host)에 등록할 수 있습니다.

두 인터페이스 모두 동일한 내부 명령 엔진(internal command engine)으로 모이며, 이 엔진은 내부적으로 관리하는 BiDi WebSocket 연결을 통해 Chrome과 통신합니다.

두 방법 모두 Vibium 바이너리를 대상으로 하며, 이 바이너리는 WebSocket을 통한 WebDriver BiDi를 사용하여 Chrome과 상호작용합니다.

언급할 만한 두 가지 세부 사항:

• Vibium은 CLI 명령, MCP 도구, 그리고 언어 클라이언트(language clients)를 위해 동일한 핵심 엔진을 사용합니다. 클라이언트 라이브러리는 브라우저 자동화 로직을 다시 구축하는 대신 WebSocket을 통해 바이너리에 연결됩니다.

• Vibium은 다음과 같이 에이전트 스킬(agent skill)로 설치할 수 있습니다:
  npx skills add https://github.com/VibiumDev/vibium --skill vibe-check
  이를 통해 AI 코딩 에이전트가 SKILL.md 정의를 통해 이를 발견하고 사용할 수 있으며, 필요한 바이너리를 자동으로 해결(resolve)할 수 있습니다.

데몬 모드 (Daemon Mode)

데몬 모드는 성능을 향상시킵니다. 매 명령마다 새로운 브라우저를 시작하는 대신, 백그라운드 브라우저를 활성화된 상태로 유지하며 모든 명령에 걸쳐 재사용합니다.

vibium go https://example.com
vibium map
vibium click @e1

따라서 브라우저가 한 번만 시작되므로 에이전트 워크플로(agent workflows)를 더 빠르게 유지할 수 있습니다. 데몬은 또한 start, status, stop 명령으로 수동 제어가 가능하며, 이는 CI 환경에서 유용합니다.

Vibium MCP 및 SKILLs 사용하기

Vibium을 이용한 AI 통합으로 넘어가기 전에, 약간의 혼동이 있을 수 있는 MCP와 Skills의 차이점을 명확히 하고 싶습니다.

**MCP (Model Context Protocol)**는 에이전트가 도구(tools)를 실행하는 데 사용하는 런타임 (runtime)입니다. 이는 에이전트와 바이너리 (binaries) 사이의 통신을 제어합니다.

• SKILL.md는 작업 수행 방식에 대한 정의입니다. 이는 MCP에서 사용되는 도구를 설명하는 파일이며, MCP는 스킬 (skill)을 어떻게 노출하고 호출할지 알기 위해 SKILL.md를 읽습니다.

요약하자면: MCP는 스킬을 사용하여 실행하며, 스킬은 MCP에게 어떻게 실행할지를 알려줍니다.

SKILL.md를 통해 정의된 스킬을 사용하려면, 먼저 이를 등록해야 합니다:

npx skills add https://github.com/VibiumDev/vibium --skill vibe-check

추가한 후, 저는 vibe-check 스킬을 사용하여 간단한 시나리오를 자동화했습니다.
저는 에이전트 모드 (agent mode)의 GitHub Copilot 내에서 다음과 같은 프롬프트를 사용했습니다.

vibe-Check 스킬을 사용하여 https://opensource-demo.orangehrmlive.com/web/index.php/auth/login 을 열고
다음 정보를 사용하여 로그인하세요:
Username: Admin
...

AI 에이전트의 신뢰성 vs 속도

AI와 함께 Vibium을 사용하는 것은 매우 흥미롭지만, 이는 **속도 (speed)**와 신뢰성 (reliability) 사이의 균형을 동반합니다.

언뜻 보기에는 매우 빠르고 똑똑해 보입니다. 단순한 단어를 사용하여 사용자가 원하는 것을 이해하고 그에 따라 동작을 실행합니다.
하지만 실제 상황에서는 상황이 복잡해질 수 있습니다.

AI가 더 빠른 설정으로 UI 요소들을 파악할 수 있는 것은 사실이지만, 보시다시피 간단한 로그인 흐름에서도 여전히 어려움을 겪습니다. 에이전트가 막혀서 첫 번째 시도에서 요소를 식별하지 못했습니다.
흥미로운 점은 빠르게 회복하며 동작하는 방식입니다.
이는 더 높은 적응성 (adaptability)을 제공하지만, 동시에 덜 결정론적인 (less deterministic) 동작을 유발하기도 합니다.

마치며

WebDriver BiDi에 투자하는 것은 브라우저 자동화를 위한 교차 벤더 표준 (cross-vendor standard)과 궤를 같이합니다. Vibium은 세 가지 레이어 (layers)로 구축된 완전한 AI 주도 시스템을 향해 나아가고 있습니다:

• Sense (Retina): Chrome 확장 프로그램 (extension)을 통한 브라우저 수준의 관찰 (observation)
• Think (Cortex): 메모리 (memory), 추론 (reasoning) 및 탐색 계획 (navigation planning)
• Act (Vibium): BiDi를 사용한 실행 (execution)

Vibium은 초기 단계에 있으며, 이러한 레이어 (layers)들을 성숙시키는 것은 브라우저 자동화 (browser automation)를 "가끔 작동하는 수준"에서 프로덕션 준비 완료 (production-ready) 수준으로 격상시킬 수 있습니다.

더 깊이 파고들려면 리포지토리 (repo) 내의 CLI 레퍼런스 (CLI reference), BiDi 설명서 (BiDi explainer), 그리고 로드맵 (roadmap)을 살펴보세요.

오늘날 브라우저 자동화 (browser automation)에서 여러분이 겪는 가장 큰 병목 현상 (bottleneck)은 무엇인가요? 여러분의 생각을 남겨주시거나, 리포지토리 (repo)를 확인하여 실험을 시작해 보세요!