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

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

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

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