Show GN: OpenChrome - 크롬 브라우저를 위한 병렬 자동화 MCP 서버
(github.com/shaun0927)Playwright은 어떻게든 크롤링을 하거나
프로덕션 환경에서 E2E 테스트를 하고 싶을 때
브라우저에서 클릭 등의 액션을 조작해 주는 유용한 웹자동화 툴입니다.
2020년에 출시되었지만,
여전히 대부분의 개발자들이 사용하는 툴이죠.
하지만 한 세션만 켜도 RAM 소모가 2GB가 넘고, 무겁고 느리며 잘 깨집니다.
AI 시대에는 이 도구의 혁신이 필요하며,
특히 병렬 작업에서도 안정적으로 돌아가는 브라우저 자동화 도구가 필요합니다.
우린 더 이상 직접 QA를 하거나 사이트를 배회하길 원치 않습니다.
OpenChrome은 이 문제를 해결하고자 하는 의지에서 출발한 프로젝트입니다.
병렬로 빠르고 센스 있게 브라우저 병렬 자동화를 달성하는 MCP 서버입니다.
제 개인 작업에서 최근 가장 많이 사용하는 도구이기도 합니다.
크롬 브라우저 로그인을 이용하며,
여러 계정을 사용할 경우 사용할 계정명을 작업 때 지시해 주시면 됩니다.
기본적으로는 로그인 되어 있는 크롬 브라우저를 기준으로 작동합니다.
20개 이상의 브라우저에서 병렬 작업이 가능하며, RAM 사용량을 약 300MB로 줄였습니다. 크롬 로그인이 된 상태로 작업을 하며, 사실상 Bot 탐지를 전면 무력화합니다. Openclaw와도 연동 가능합니다.
사용 예시는 아래와 같습니다.
"트위터 유명인사 20명의 최신 글을 oc로 크롤링해줘."
(claude code 기준 벤치마크 3분 30초 소요 - 대부분 LLM 추론 시간입니다)
사실 playwright의 고질적인 문제는 헛발질을 하는 "LLM 배회"입니다.
로그인 같은 작업을 지시해도 한참 사이트를 뒤적이면서 이것저것 시도해 보고,
결국에는 30분 이상 걸려 실패했다는 알림이 오곤 합니다.
Openchrome은 이걸 추측 방식이 아닌 Guided 방식으로 해결합니다.
크롬에 바로 로그인하고, 링크를 주면 바로 링크에 접속합니다.
스크린샷은 최소한으로 찍고, 버튼 등의 위치를 빠르게 잡아냅니다.
작업에 문제가 생기면 기억을 되짚어 같은 실수를 반복하지 않습니다.
MCP 서버이기에 기존 Playwright 대신 모든 환경에서 바로 사용할 수 있습니다.
MAC-claude code 개발이나 Windows, Linux 등 타 운영체제는 물론
codex cli, cursor 등에서도 동작합니다.
설치 :
npx openchrome-mcp setup
매우 복잡하고 용량이 많이 소모되는 대규모 프로덕션 안정성은 추가 검증이 필요하며,
피드백이나 제안이 있으시면 GitHub Issues에 올려주시면 바로 반영하겠습니다.
감사합니다.
기존 playwright이 정형화된 방법론으로 웹사이트에 접근해 토큰 소모가 심했다면,
openchrome은 llm 친화적으로 접근해 llm이 직접 웹사이트 동작 제어에 빠르게 관여하게 하는 개념으로 보시면 될 것 같아요. e2e 솔루션을 직접 실행할 수 있습니다.
예를 들어 구글 로그인이 필요한 프로덕션에서 관리자 계정으로 로그인한 상태로 QA 작업을 시킬 수 있습니다. 스크롤을 하거나 엣지 케이스들을 알아서 클릭하게 하거나 등등 상상하시는 대부분의 작업이 모두 가능합니다. playwright이 자율적으로 멍청한 작업을 하게 놔두지 않고, LLM이 바로바로 관여해 동작을 제어하는 방식이기 때문입니다.
토큰 사용량만 보면 정형화 된 방법은 E2E 테스트 케이스를 LLM 개입 없이 돌리는 것이기 때문에 더 적지 않나요?
테스트 방법론에 보면 TC 외 QA 가 자율적으로 테스트 하는 것도 포함되어 있는데
그 부분에 대해서 효율이 좋다고 판단하면 좋을까요?
구체적으로 질문 주셔서 좀더 테크니컬한 답변을 드리자면,
기존 playwright MCP는 아래 3단계 추상화로 작동합니다:
LLM → MCP 서버 → Playwright Node.js 서버 → CDP/Juggler → 브라우저
반면 OpenChrome은 아래 1단계 추상화로 작동합니다:
LLM → MCP 서버 → CDP → 브라우저
추상화 레이어가 적을수록 빠르고 제어가 정밀하고,
playwright은 범용 도구인 반면, openchrome은 특화 도구를 사용합니다.
수학 문제로 치면 20줄짜리 풀이과정을 4줄로 압축한 느낌으로 보시면 될 것 같아요.
playwright은 접근성 트리라는 텍스트 기반 방식으로 피드백을 받기에
(이론적으로는 우수하나 대부분의 사이트에서 깨지는 이유입니다)
맥락 파악이 굉장히 제한적이기도 합니다.
따라서 접근성이 잘 구현된 사이트(google 등 유명 도메인)에서는 여전히 playwright이 유용하지만,
대부분의 사이트나 프로덕션에서는 openchrome이 압도적으로 낫습니다.
또한 "도구 설계의 밀도"와 "LLM이 실수할 기회를 줄이는 것"이 결국 실전 성능을 좌우하기에,
이론적인 성능이 아닌 real-world task로 측정하는 것이 맞다고 생각됩니다.
감사합니다. 제가 본문을 충분히 읽지 않았네요.
프로덕션 환경을 대상으로 했다는 부분에 대해서 간과했습니다.
저도 꼭 써보도록 하겠습니다.
잘못된 질문에 충실히 답변 주셔서 감사합니다~
chrome devtools mcp 는 large context 경고가 안뜨는데 성능이 엇비슷한 느낌이었어서 전 이거로 쓰고 있었어요! 벤치마크 결과가 기대되네요 :D