중국 개발자들은 브라우저 자동화를 어떻게 할까? MCP·CLI·확장·Agent 방식

요즘 AI에게 “이 사이트에 로그인해서 자료를 가져와 줘”라고 지시하면 실제로 브라우저를 열고 클릭까지 할 수 있다. 그런데 이 말을 듣고 내가 궁금했던 것은 자동화로 무엇을 만들 수 있는가가 아니었다.

AI가 브라우저에 어떻게 접속하고, 어떤 방식으로 버튼을 찾고, 로그인 상태를 유지하며, 반복 작업을 실행하는가. 실제 사용 방법이 궁금했다.

그래서 2026년 10월 22일을 기준으로 중국 개발자 커뮤니티 V2EX의 게시물과 오픈소스 프로젝트, 관련 공식 문서를 확인했다. 중국 개발자들이 공개한 글에는 의외로 구체적인 설치 방법과 구조, 그리고 실제 사용 중 부딪힌 문제들이 담겨 있었다.

AI가 중앙 연결 장치를 통해 로컬 컴퓨터의 브라우저와 원격 클라우드 브라우저를 제어하는 개념 삽화

AI와 브라우저의 연결 구조를 설명하기 위해 생성한 개념 삽화다. 실제 제품 화면은 아니다.

먼저 결론: 브라우저를 조작하는 길이 여러 개다

조사한 프로젝트를 구분하는 가장 쉬운 질문은 세 가지다.

AI가 어디에 있는가? Codex·Claude Code처럼 브라우저 바깥에 있는지, 아니면 Chrome 확장 안에서 실행되는지.
브라우저에 어떻게 연결하는가? MCP, CLI, Chrome DevTools Protocol(CDP), 확장 프로그램의 로컬 브리지, 페이지 내부 JavaScript 중 무엇을 쓰는지.
매번 AI가 판단하는가? 페이지를 매번 다시 읽고 클릭하는지, 처음 성공한 절차를 Skill·스크립트로 저장해 재실행하는지.

방식	실제 조작 경로	특징
Playwright MCP	AI → MCP 서버 → 브라우저	자연어 지시에 따라 페이지 구조를 읽고 조작
Playwright CLI + Skill	AI → 터미널 명령 → 브라우저	명령과 스냅샷을 필요할 때만 사용
Chrome DevTools MCP	AI → MCP → 실행 중인 Chrome	기존 Chrome 세션에 직접 연결 가능
확장 프로그램 + 로컬 브리지	AI → MCP·CLI → 확장 → Chrome	여러 Agent가 로그인된 브라우저를 공유
확장 내부 Agent·페이지 JS	브라우저 내부 AI → DOM·탭	별도 외부 Agent 없이 조작 가능
시각 인식 Agent	화면 캡처 → AI 판단 → 클릭·입력	화면 모양을 보고 조작
녹화·학습 후 재실행	사람의 조작 → 스크립트 생성 → 재실행	고정된 절차에서 AI 호출을 줄임

여기서 MCP는 AI에게 조작 도구를 제공하는 연결 방식이다. MCP 자체가 반드시 브라우저를 실행하는 것은 아니다. 반대로 CLI나 브라우저 확장만으로도 자동화는 가능하다.

Playwright CLI, Chrome DevTools MCP, 브라우저 확장, 시각 인식, 녹화 후 재실행 등 여섯 가지 경로를 비교한 생성형 도식

자동화 방식을 한눈에 비교하기 위한 AI 생성 개념도다. 도식 속 브라우저 화면과 예시 코드는 실제 제품을 실행·검증한 캡처가 아니다.

1. Playwright CLI + Skill: 처음만 탐색하고 다음에는 절차를 재사용

가장 인상적으로 본 사례는 V2EX에 2026년 4월 13일 올라온 TechShrimp의 Playwright CLI + Skill 소개였다.

사용하는 구성은 복잡하지 않다.

Claude Code 또는 Codex → Playwright CLI의 명령 실행 → Chrome/Chromium 조작.

Playwright CLI는 AI가 터미널로 브라우저를 제어할 수 있게 해준다. 설치 후에는 다음과 같이 웹사이트를 연다.

npm install -g @playwright/cli@latest
playwright-cli install --skills
playwright-cli open https://example.com --headed
playwright-cli snapshot

설치 예시는 Microsoft의 Playwright CLI 문서에서도 확인할 수 있다. 마지막의 –headed는 브라우저 창을 화면에 표시하는 옵션이다.

여기서 중요한 차이가 있다. AI에게 페이지 전체의 DOM이나 스크린샷을 매번 전달하는 대신, CLI가 남긴 간결한 상태 정보와 스냅샷을 필요한 순간에만 읽게 할 수 있다. 긴 페이지를 다룰 때 컨텍스트 부담을 줄이는 방법이다.

TechShrimp가 설명한 작업 흐름은 다음과 같았다.

처음에는 AI가 웹페이지를 탐색하면서 어떤 버튼을 눌러야 하는지 알아낸다.
성공하면 AI에게 사용한 명령과 실패했던 부분을 정리해 재사용 가능한 Skill로 저장시킨다.
같은 작업을 다시 할 때는 저장한 절차를 참고하므로 탐색과 시행착오를 줄인다.
절차가 완전히 고정됐다면 PowerShell이나 Python 스크립트로 전환해 모델 없이 실행한다.

게시자가 공개한 한 사례에서 첫 실행은 컨텍스트 창의 약 41%를 사용했지만, 성공한 절차를 Skill로 저장한 다음에는 약 5%를 사용했다고 한다. 어디까지나 한 개발자의 특정 작업에서 나온 수치이지, 모든 사이트에서 똑같이 절약된다는 뜻은 아니다.

내가 보기에 이 방식의 핵심은 Playwright CLI라는 프로그램 자체보다도, 한 번 학습한 조작 절차를 계속 처음부터 반복하지 않는다는 생각이다.

2. Chrome DevTools MCP: 내가 쓰는 Chrome에 AI를 직접 연결

두 번째는 Chrome DevTools MCP다.

새 브라우저를 켜는 자동화는 편리하지만, 이미 사용 중인 Chrome과 로그인 상태가 분리되는 일이 문제다. 쇼핑몰이나 커뮤니티에 다시 로그인하고, 2단계 인증을 또 해야 할 수도 있다.

Chrome 144 이상에서는 실행 중인 Chrome에 MCP가 자동 연결하는 경로가 제공된다. Chrome 주소창에서 다음 페이지를 열어 원격 디버깅을 허용하는 방식이다.

chrome://inspect/#remote-debugging

그다음 MCP 클라이언트에 예를 들어 다음 서버 구성을 등록한다.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--auto-connect"
      ]
    }
  }
}

설정 키의 위치는 사용하는 MCP 클라이언트마다 다르다. 핵심은 –auto-connect다. 지원되는 환경에서 지금 실행 중인 Chrome 인스턴스에 연결하라는 의미다.

공식 문서에는 실행 중인 Chrome 연결 절차와 연결 오류 해결 방법이 따로 정리돼 있다.

다만 “현재 Chrome에 연결 가능”과 “어떤 PC·어떤 프로필에서도 무조건 연결”은 다르다. Chrome이 실행 중이어야 하고, 원격 디버깅을 허용해야 하며, 브라우저 프로필과 실행 환경이 맞아야 한다. Windows·WSL처럼 프로그램이 다른 실행 환경에 있을 때도 확인이 필요하다.

로그인한 Chrome을 그대로 쓴다는 것은 편리하지만 동시에 강한 권한을 준다는 의미다. 중요한 계정이라면 AI용 프로필을 별도로 두는 것도 검토할 만하다.

3. Chrome 확장 + 로컬 브리지: 여러 AI가 같은 브라우저를 사용

2026년 10월 18일 V2EX에 공개된 BeatBrowser 소개글은 조금 다른 고민에서 출발했다.

Codex, Claude Code, Cursor를 번갈아 쓸 때마다 브라우저를 따로 준비하고 로그인하는 것이 불편하다는 것이다. AI가 내 탭을 멋대로 바꾸거나, 사람이 작업하는 창과 충돌하는 문제도 있었다.

개발자가 공개한 구조는 이렇다.

Codex / Claude Code / Cursor
        ↓ MCP 또는 CLI
로컬 Node.js 브리지
        ↓ WebSocket
Chrome 확장 프로그램
        ↓ CDP
내가 로그인한 Chrome 프로필

BeatBrowser는 각 자동화 작업에 별도 창을 부여한다. 사람이 그 창을 열어 개입하면 다음 자동화 동작을 잠시 멈추고, 직접 인증을 끝낸 뒤 다시 진행할 수 있다. 개발자가 V2EX에서 설명한 특징에는 작업 기록, 창 정리, 재시작 후 복구, 여러 동작을 한 번에 실행하는 기능도 포함돼 있다.

이 부분은 단순 클릭 자동화보다 현실적인 문제를 해결한다. AI가 브라우저를 조작할 수 있느냐보다, 사람과 AI가 같은 브라우저를 어떻게 안전하게 나눠 쓰느냐의 문제다.

개발자는 원격 서버에 있는 Agent가 Cloudflare Tunnel과 인증을 통해 로컬 Chrome에 접속하는 구성도 소개했다. 단, AI가 클라우드에서 실행된다고 해서 로컬 Chrome까지 클라우드로 옮겨지는 것은 아니다. 이 구성에서는 사용자 PC와 Chrome이 켜져 있어야 한다.

프로젝트: BeatBrowser GitHub

4. Chrome 확장 안에 AI를 넣는다: qz-browser-agent와 Page Agent

앞의 방법들은 주로 외부 AI가 브라우저에 접속하는 형태다. 반대로 Agent 자체를 브라우저 안으로 가져오는 구현도 있다.

2026년 10월 21일 V2EX에 올라온 Alibaba qz-browser-agent 소개가 그 사례다. ‘轻舟(경주, 가벼운 배)’라는 이름의 Chrome 확장 프로그램으로, 브라우저 사이드바에서 AI를 직접 호출하는 방식을 내세운다.

개발자의 설명에 따르면 확장 프로그램에 모델 API를 연결한 뒤 페이지 구조를 읽고, 탭을 넘나들고, JavaScript를 실행하고, 반복 과정을 Skill로 저장할 수 있다. 외부 AI에서 제어하도록 CLI와 MCP 경로도 제공한다.

여기서 주목할 차이는 별도의 Claude Code나 Codex를 먼저 실행하지 않고도 브라우저 안에서 AI 작업을 시작할 수 있다는 점이다.

같은 Alibaba의 Page Agent는 또 다른 형태다. 웹페이지 내부에 JavaScript를 넣어 페이지의 DOM을 읽고 자연어로 UI를 조작한다. 기본 구조에서는 전체 브라우저를 제어하는 별도 MCP 서버나 화면 인식 모델이 필수는 아니다. 다만 페이지 내부 실행 방식은 접근 범위가 다르며, 여러 탭을 조작하는 데는 확장 등 추가 수단이 필요하다.

두 프로젝트는 모두 브라우저 자동화에 속하지만 구조가 같지는 않다. qz는 브라우저 확장 자체가 Agent의 실행 환경이고, Page Agent는 웹페이지 안에서 시작할 수 있다는 점이 다르다.

5. 화면을 보고 클릭하는 시각 인식 방식

지금까지의 방식은 페이지 구조나 개발자 도구를 읽는 경향이 강하다. 하지만 모든 웹사이트의 화면이 깔끔한 HTML 버튼과 입력창으로 구성된 것은 아니다.

이때 쓰는 방식이 시각 인식 기반 자동화다. 브라우저 화면을 캡처해 멀티모달 모델에 전달하고, 모델이 버튼과 입력 위치를 판단하게 한다.

대표적인 프로젝트로 Midscene.js가 있다. Playwright 같은 브라우저 실행기와 결합해 자연어 동작 명령, 화면 상태 확인, UI 검증 등을 구성한다.

원리는 간단하다.

스크린샷 확보 → 모델이 대상 판단 → 클릭·입력 → 새 화면 확인 → 다음 행동.

장점은 복잡한 화면 구조를 사람이 보는 방식으로 접근할 수 있다는 것이다. 반면 매번 이미지를 해석하려면 모델 호출 비용이 늘 수 있고, 좌표 기반 조작은 화면 크기나 배치 변화에 영향을 받는다.

그래서 나는 모든 클릭을 시각 AI에 맡기는 것보다, 구조를 안정적으로 읽을 수 있는 부분은 DOM·선택자를 쓰고 어려운 부분에서 시각 인식을 활용하는 혼합 방식이 더 합리적으로 보였다.

6. 한 번 녹화하고 다음부터는 코드로 실행

이 부분이 이번 조사에서 가장 실용적으로 느껴졌다. AI가 똑똑하게 클릭하는 것보다, 이미 성공한 클릭 과정을 다시 생각하지 않게 만드는 방향이다.

2026년 4월 2일 V2EX에 소개된 OpenClaw RPA는 사람이 실제 Chrome에서 조작한 과정을 기록하고 Playwright Python 스크립트로 만들어 재실행하는 방식을 제시한다.

기본 흐름은 다음과 같다.

사람이 브라우저에서 한 번 시연
            ↓
DOM 선택자와 조작 순서 기록
            ↓
Playwright Python 스크립트 생성
            ↓
다음부터 스크립트 재실행

이 경우 매번 AI가 버튼 위치를 판단할 필요가 없다. 물론 사이트 UI가 바뀌면 스크립트가 실패할 수 있고, 예외 처리·인증 만료 같은 문제는 따로 다뤄야 한다.

9월 20일 V2EX에 등장한 yodo는 여기서 한 걸음 더 나아간다. 사용자가 작업을 한 번 보여주면 조작뿐 아니라 네트워크 요청을 학습해 비슷한 작업에서 직접 재사용할 수 있도록 설계했다.

개발자가 공개한 비교에서는 동일한 크로스사이트 작업에서 browser-use가 9분 45초, agent-browser가 6분 25초, yodo의 학습된 스크립트 재실행이 56초 걸렸다. 다만 프로젝트 README는 각 방식을 한 번씩만 측정한 자체 테스트라고 명시한다. 따라서 이를 전체적인 속도 순위로 받아들이기는 어렵다.

이 숫자보다 더 중요한 것은 설계다. 사람이 한 번 시연하고 AI가 그 경험을 코드로 바꾼 뒤, 이후에는 코드가 실행한다는 것이다.

7. 로컬 브라우저와 클라우드 브라우저는 실행 조건이 다르다

브라우저를 어떻게 제어하는지와 별개로 브라우저 자체가 어디에서 실행되는지도 구분해야 한다.

구분	사용자 PC의 Chrome	클라우드 브라우저
브라우저 위치	내 컴퓨터	원격 실행 환경
로그인 상태	기존 Chrome 세션 활용 가능	원격 세션을 별도로 관리
PC를 껐을 때	로컬 Chrome 자동화 중단	클라우드에서 독립 실행 가능
연결 방식	로컬 MCP·CLI·확장·CDP	원격 API·SDK·MCP
주요 고려 사항	로컬 권한·전원·프로필	서비스 요금·세션·인증·보안

클라우드 서버에 띄운 Codex가 내 PC Chrome을 원격으로 조작하는 경우도 있다. 이것은 클라우드 AI + 로컬 브라우저 구성이므로 PC를 끄면 브라우저 작업이 그대로 이어지지 않는다.

PC 전원과 관계없이 자동화를 실행하려면 브라우저까지 원격 환경에서 실행되는 구조인지 확인해야 한다.

8. 실제 커뮤니티에서 반복해서 나온 문제들

여러 프로젝트의 소개와 댓글을 읽다 보니, 결국 개발자들이 해결하려는 문제가 비슷했다.

기존 로그인 상태를 어떻게 이어받을까?

새 Chromium 프로필을 띄우면 사용자가 평소 Chrome에서 로그인한 상태와 분리될 수 있다. 그래서 Chrome DevTools MCP의 실행 중 브라우저 연결, BeatBrowser의 확장 브리지, qz의 확장 내부 Agent처럼 이미 로그인된 브라우저를 활용하는 설계가 등장한다.

버튼은 눌렀는데 입력이 안 되는 이유는?

V2EX의 WebCLI 관련 토론에는 일반 입력창보다 리치 텍스트 편집기가 더 어렵다는 반응이 있었다. 페이지가 입력 이벤트를 별도로 처리하는 경우가 있기 때문이다. 단순 DOM 값 변경만으로는 성공했다고 판단하면 안 되고, 실제 입력 후 값과 서버 반영 여부를 확인해야 한다.

AI가 너무 자주 판단하지 않도록 할 수 있을까?

동작 하나 실행하고 모델을 호출해 다시 판단하면 느리고 비용이 많이 든다. 이것을 줄이려고 간결한 페이지 스냅샷, 여러 동작의 묶음 실행, Skill, 기록 기반 스크립트가 등장했다.

사람이 중간에 개입할 수 있을까?

로그인, QR 인증, 2단계 인증은 상황에 따라 사람의 개입이 필요하다. BeatBrowser나 ego lite 개발자 소개에서는 사람과 Agent의 작업 공간을 분리하고 필요할 때 제어권을 넘기는 방법을 강조한다.

보안은 어떻게 처리할까?

이미 로그인된 Chrome을 연결하면 AI 도구가 그 계정으로 실행 가능한 행동의 상당 부분에 접근할 수 있다. 특히 모든 URL에 접근하는 확장, 디버깅 권한, 원격 브리지 인증은 주의해야 한다. 계정을 분리하고, 신뢰할 수 있는 서버·확장에만 권한을 부여하고, 결제·삭제·게시 같은 민감한 작업은 사람이 최종 확인하는 편이 안전하다.

내가 직접 구성한다면 어떤 방식을 선택할까?

이번 조사만 놓고 내리는 판단이다. 아래는 실사용 성능을 내가 직접 측정한 순위가 아니라 연결 구조와 반복 실행 방식을 비교한 선택 기준이다.

처음 가는 사이트를 AI가 자유롭게 탐색해야 한다면 Playwright CLI + Skill 또는 Playwright MCP부터 살펴보겠다.
이미 로그인한 내 Chrome을 그대로 제어하려면 Chrome DevTools MCP를 먼저 검토하겠다.
Codex·Claude Code 등 여러 Agent가 Chrome을 함께 사용해야 한다면 BeatBrowser 같은 확장 브리지가 더 맞을 수 있다.
브라우저에서 바로 자연어 명령을 내리고 싶다면 qz 같은 확장 내부 Agent 방식이 간단하다.
표준 DOM으로 처리하기 힘든 화면에서는 시각 인식 Agent를 보조 수단으로 활용할 만하다.
똑같은 작업을 자주 반복한다면 처음 성공한 절차를 Skill로 정리하고, 완전히 고정된 부분은 스크립트로 만드는 쪽을 우선하겠다.
PC가 꺼져도 실행돼야 한다면 내 Chrome을 원격 제어하는 구성이 아니라 브라우저 자체가 클라우드에서 실행되는 방식이 필요하다.

결국 어떤 MCP가 가장 좋으냐는 질문보다 기존 로그인 세션을 쓸 것인지, 사람이 개입할 것인지, 똑같은 작업을 몇 번이나 반복할 것인지부터 결정하는 편이 낫다.

이번에 중국 커뮤니티 사례를 모아 보며 가장 크게 느낀 변화도 이것이었다. 이제는 AI가 브라우저의 버튼을 클릭할 수 있다는 사실 자체보다, 클릭한 경험을 어떻게 재사용하고, 비용을 줄이고, 사람의 작업을 방해하지 않느냐가 더 중요한 설계 문제로 넘어가고 있다.

한 가지를 고르라면 나는 AI가 최초 탐색 → 절차를 Skill로 저장 → 반복 구간을 스크립트로 전환 → 예외 상황에서만 다시 AI를 호출하는 구성이 가장 현실적이라고 생각한다. 이것은 하나의 추천 구조이지 중국 커뮤니티 전체의 점유율 조사 결과는 아니다.

참고한 중국 커뮤니티 글과 공식 자료

관련해서 MCP가 실제 계정과 브라우저를 연결하는 더 넓은 사례는 MCP의 현실: AI가 실제 계정과 컴퓨터로 행동하기 시작했다에서도 다뤘다.

이 글은 2026년 10월 22일까지 공개된 커뮤니티 게시글과 프로젝트 문서를 AI의 조사·정리 도움을 받아 구성했다. 각 개발자의 주장과 자체 테스트 결과는 출처를 표시했으며, 소개한 도구를 모두 직접 설치하거나 동일 조건에서 성능 시험한 것은 아니다. 본문 삽화 2장은 설명을 위해 AI로 생성했다.