구체적으로 질문 주셔서 좀더 테크니컬한 답변을 드리자면,

기존 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로 측정하는 것이 맞다고 생각됩니다.

감사합니다. 제가 본문을 충분히 읽지 않았네요.
프로덕션 환경을 대상으로 했다는 부분에 대해서 간과했습니다.

저도 꼭 써보도록 하겠습니다.
잘못된 질문에 충실히 답변 주셔서 감사합니다~

아니에요 좋은 질문 감사합니다. 저도 설명하면서 스스로 정리가 되었습니다.