구체적으로 질문 주셔서 좀더 테크니컬한 답변을 드리자면,
기존 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로 측정하는 것이 맞다고 생각됩니다.
감사합니다. 제가 본문을 충분히 읽지 않았네요.
프로덕션 환경을 대상으로 했다는 부분에 대해서 간과했습니다.
저도 꼭 써보도록 하겠습니다.
잘못된 질문에 충실히 답변 주셔서 감사합니다~
토큰 사용량만 보면 정형화 된 방법은 E2E 테스트 케이스를 LLM 개입 없이 돌리는 것이기 때문에 더 적지 않나요?
테스트 방법론에 보면 TC 외 QA 가 자율적으로 테스트 하는 것도 포함되어 있는데
그 부분에 대해서 효율이 좋다고 판단하면 좋을까요?