당신의 AI 에이전트가 버튼이 존재하는지 확인할 때마다, 소켓(socket)을 통해 JSON 메시지를 보내고, 세 개의 프로세스 경계(process boundaries)를 넘나들며, 응답을 기다립니다. 이미 메모리에 있는 DOM 노드를 위해, 당신의 로컬 머신에서 말이죠.
그것이 Playwright입니다. 우리는 이를 해결하기로 했습니다.

기존 브라우저 자동화의 문제점

대부분의 브라우저 자동화 도구는 특정 작업을 위해 설계되었습니다. 사람이 JavaScript 테스트 스위트(test suite)를 작성하면, CI 러너(runner)가 이를 실행하고, 사람이 보고서를 읽는 방식입니다.

AI 에이전트는 근본적으로 다른 형태를 가집니다. 이들은 사전에 스크립트를 작성하지 않습니다. 결정하고, 행동하고, 검증하고, 다시 결정합니다. 타이트한 루프(tight loops), 세션당 수십 번의 반복, 그리고 매번 새로운 DOM 상태가 필요합니다. 단계별로 발생하는 매 밀리초(ms)의 지연 시간(latency)이 누적됩니다.

우리가 첫 번째 벤치마크를 실행했을 때, 우리를 멈춰 세운 숫자는 이것이었습니다: CDP 기반 브릿지(bridge)를 사용할 때 단계당 평균 지연 시간이 580ms였습니다. 10단계 검증 흐름(verification flow)의 경우, 에이전트가 단순히 기다리기만 하는 시간이 6초에 달합니다.

우리는 시간이 어디로 사라지고 있는지 파헤치기 시작했습니다.

내부에서 실제로 일어나고 있는 일

대부분의 도구는 Chrome DevTools Protocol (CDP)을 통해 브라우저와 통신합니다. CDP는 메시지 전달 인터페이스(message-passing interface)입니다. 즉, 테스트 프로세스가 소켓을 통해 JSON 명령을 보내면, 브라우저가 이를 처리하고 다시 JSON 응답을 보냅니다.

모든 동작은 최소 세 개의 프로세스 경계를 넘습니다:

test process → driver → browser process → DOM

CI에서 밤새 실행되는 사람이 작성한 테스트 스위트의 경우, 이는 괜찮습니다. 하지만 결정-행동-검증(decide-act-verify)의 타이트한 루프 안에 있는 에이전트에게 이는 결코 사라지지 않는 구조적 세금(structural tax)입니다.

비동기(async) 모델은 이를 더욱 악화시킵니다. await page.click('#submit')과 다음 줄 사이에서 DOM이 변경되었을 수도 있습니다. 일반적인 해결책은 재시도 로직(retry logic), 타임아웃(timeouts), 그리고 waitFor 헬퍼(helpers)를 사용하는 것이지만, 이들 모두 지연 시간을 추가합니다. 이 중 어느 것도 누구의 잘못도 아닙니다. 이는 아키텍처 자체에 내재된 문제입니다.

통찰: 만약 드라이버가 DOM과 동일한 프로세스 내에 존재한다면 어떨까?

우리의 목표는 chromium.example.com을 대상으로 하는 CI 실행이 아니었습니다. 우리의 목표는 에이전트와 동일한 머신에서 실행 중인 localhost:3000 앱을 검증하는 AI 에이전트였으며, 이 앱들은 대개 해당 에이전트에 의해 5분 전에 생성된 것들이었습니다.

그러한 유스케이스(use case)에서 프로세스 간(cross-process) 아키텍처는 순전한 오버헤드(overhead)일 뿐입니다.

우리는 제로 IPC (zero-IPC) 모델을 중심으로 Alethia를 구축했습니다. 즉, 드라이버와 DOM이 동일한 V8 isolate 내에 존재합니다. document.querySelector('button').textContent를 읽는 것은 네트워크 왕복(round-trip)이 아니라 함수 호출(function call)입니다. CDP 소켓도, 마샬링(marshaling)도, 액션과 DOM 상태 사이의 비동기 경합(async race)도 없습니다.

에이전트와 런타임 사이에는 두 개의 프로세스 경계가 남아 있지만(에이전트 ↔ MCP 브리지, 브리지 ↔ 런타임), 런타임과 DOM 사이에는 경계가 전혀 없습니다.

이 결과는 재현 가능하며, alethia-anvil에 전체 벤치마크 하네스(benchmark harness)를 공개했습니다. 직접 클론(clone)하여 실행해 보십시오.

아무도 해결하지 않았던 안전 문제

벤치마킹을 진행하는 동안 우리는 또 다른 사실을 발견했습니다. 기존의 어떤 브라우저 자동화 도구도 의도 기반의 안전 가드레일(intent-based safety guardrails)이라는 개념을 가지고 있지 않았다는 점입니다.

AI 에이전트는 지침을 잘못 해석할 수 있습니다. 페이지에 주입된 콘텐츠에 의해 조작될 수도 있습니다. 만약 여러분의 테스트 도구가 DELETE /api/users/all을 기꺼이 실행하거나 500달러 결제를 확인해 버린다면, 에이전트는 너무 늦기 전까지 자신이 잘못된 행동을 했다는 사실을 알지 못할 것입니다.

우리는 EA1이라는 정책 게이트(policy gate)를 런타임에 직접 구축했습니다. 모든 단계는 실행되기 전에 의도(intent)에 따라 분류됩니다.

• read (탐색, 단언/assertions) — 항상 허용
• write-low (폼 입력, 초안 작성) — 기본적으로 허용
• write-high (삭제, 구매, 이체) — 기본적으로 차단

게이트(gate)는 실행기(executor)와 동일한 프로세스 내에 존재합니다. 에이전트(Agent)는 이를 우회할 수 없습니다. 파괴적인 동작이 시도되면, 시스템은 기본적으로 차단(fail closed) 상태가 되며 해당 시도를 감사 추적(audit trail)에 기록합니다.

이는 특히 AI 에이전트에게 매우 중요한데, 사용자가 항상 지켜보고 있는 것은 아니기 때문입니다. 안전 보장은 권고(advisory) 수준이 아니라 아키텍처(architectural) 차원에서 이루어져야 합니다.

토큰 비용 문제

우리가 예상하지 못했던 한 가지는, 왕복 스냅샷(round-trip snapshot) 도구들이 시간뿐만 아니라 토큰(token) 측면에서도 비용이 많이 든다는 점이었습니다.

대부분의 MCP 기반 자동화는 매 동작마다 전체 접근성 스냅샷(accessibility snapshot)을 반환합니다. 단순한 앱의 경우 단계당 약 800 토큰이 소모됩니다. 복잡한 접근성 트리(accessibility tree)를 가진 프로덕션 앱의 경우 수천 토큰이 소모됩니다. 10단계의 흐름을 거치면, 에이전트가 대부분 무시하는 컨텍스트(context)를 낭비하게 됩니다.

Alethia는 흐름당 하나의 압축된 응답을 반환합니다. 즉, 가공되지 않은 DOM 덤프(raw DOM dump)가 아니라 화면에 무엇이 있는지에 대한 약 200 토큰 규모의 의미론적 스냅샷(semantic snapshot)을 제공합니다.

접근성 트리로 컨텍스트 윈도우(context window)를 범람시키지 않는 것이 다단계 에이전트 세션의 일관성을 유지하는 비결입니다.

사용 방법

Alethia는 MCP 서버로 제공됩니다. 두 가지 명령어가 있습니다:

npm install -g @vitronai/alethia

사용 중인 MCP 설정(Claude Code, Cursor, Cline 등)에 추가하세요:

{
  "mcpServers": {
    "alethia": {
...

그런 다음 에이전트에게 무언가를 테스트하도록 요청하세요:

http://localhost:3000으로 이동하여 test@example.com으로 로그인하고, 대시보드가 보이는지 확인해줘.

테스트 스크립트도, await page.waitForSelector도, 드라이버 설정도 필요 없습니다. 에이전트는 평범한 영어를 사용하고, Alethia는 이를 동작(actions)으로 컴파일하며, EA1 게이트를 실행하고, 라이브 DOM에 대해 실행한 뒤, SHA-256 체인형 감사 추적(audit trail)과 함께 단계별 결과를 반환합니다.

60초 만에 직접 확인하기

Alethia에는 내장 데모 앱이 포함되어 있습니다. 다음을 Claude Code에 붙여넣으세요:

alethia_serve_demo를 사용하여 데모 서버를 시작하세요. 앱으로 이동합니다. TaskFlow가 보이는지 확인(Assert)합니다. 이메일 필드에 dev@company.com을 입력합니다. Sign In을 클릭합니다. "Signed in as"가 보이는지 확인(Assert)합니다. Delete를 클릭하고 EA1이 무엇을 결정하는지 보고합니다.

에이전트는 localhost 서버를 시작하고, 평이한 영어로 앱을 구동하며, EA1이 삭제 동작을 차단합니다. 각 단계가 화면에 실시간으로 강조되어 나타납니다 — 통과하면 초록색, 차단되면 빨간색입니다. 마지막 단계가 핵심입니다. 여러분의 에이전트가 방금 파괴적인 동작을 시도했고, 런타임(runtime)이 여러분이 손 하나 까딱하지 않아도 이를 중단시켰습니다.

대상 독자

브라우저 자동화(Browser automation)는 인간이 테스트 스크립트를 작성하는 세상을 위해 설계되었습니다. 실시간으로 코드를 생성하고 검증하는 AI 에이전트는 완전히 다른 패러다임입니다. 더 타이트한 루프(tighter loops), 사전 작성된 스크립트의 부재, 그리고 가드레일(guardrails) 없이 에이전트가 행동할 때 발생하는 결과값들이 존재합니다.

AI 에이전트에게는 기존의 것을 변형한 도구가 아니라, 그러한 루프를 위해 구축된 도구가 필요합니다.

그것이 바로 우리가 만든 것입니다. vitron.ai

이 런타임은 특허 출원 중입니다 (U.S. 19/571,437). MCP 브릿지(bridge)는 MIT 라이선스이며 GitHub에서 감사(auditable) 가능합니다. 질문 또는 라이선스 문의: team@vitron.ai