이전 기사에서 기존 자동화 프로토콜인 WebDriver 'Classic' 및 Chrome DevTools Protocol (CDP)과 각각의 장점 및 제약 조건에 대해 살펴봤습니다.
브라우저 자동화의 미래, WebDriver BiDi를 만나 보세요. 현재 개발 중인 새로운 표준 브라우저 자동화 프로토콜로, WebDriver 'Classic'과 CDP의 장점을 결합하는 것을 목표로 합니다. WebDriver BiDi는 양방향 통신을 약속하여 기본적으로 속도가 빠르며 낮은 수준의 제어 기능을 갖추고 있습니다.
| 웹 드라이버 BiDi | |
|---|---|
| WebDriver 'Classic' | Chrome DevTools 프로토콜 (CDP) |
| 최상의 브라우저 간 지원 | 빠른 양방향 메시지 |
| W3C 표준 | 하위 수준의 제어 제공 |
| 테스트용으로 빌드 | |
WebDriver BiDi의 비전은 원하는 도구를 사용하여 테스트를 작성하고 모든 브라우저 또는 드라이버에서 테스트를 자동화하여 완전한 유연성을 제공하는 것입니다.
표준화
WebDriver BiDi Working Group은 다양한 브라우저 공급업체, 오픈소스 브라우저 자동화 프로젝트, 브라우저 자동화 솔루션 제공 업체로 구성되어 있습니다. 이러한 협력을 통해 브라우저 자동화의 미래를 보장합니다.
이 작업은 주로 이 GitHub 저장소에서 이루어집니다. 모든 주요 브라우저 공급업체와 매달 회의를 통해 실제 진행 상황을 보고하고 논쟁의 여지가 있거나 알려지지 않은 세부 사항에 대해 논의합니다. 전사적 작업 그룹은 의사결정이 모든 이해관계자와 일치하는지 확인합니다.
새로운 프로토콜을 수립하고 구현하는 것은 간단한 일이 아닙니다. 이를 위해서는 다양한 벤더의 협력과 협력이 필요합니다. 이 프로세스에는 다음 과정이 포함됩니다.
- 사양: 제안서에 대한 의견을 수집하기 위한 의견 (RFC) 프로세스 요청
- 확인: 여러 플랫폼에서 실행할 수 있는 일련의 테스트로, 모든 구현의 정보 소스로 사용됩니다.
- 구현: 브라우저가 사양에 따라 프로토콜을 구현하고 인증 테스트를 통과합니다.
챌린지
이 섹션에서는 호환성, 사용성, 구현 가능성 사이의 균형을 이루고자 하는 WebDriver BiDi 구현의 어려움을 자세히 살펴봅니다.
CDP 클론 이후: 브라우저 간 호환성 수용
CDP는 Chrome 및 DevTools 관련 요소가 있으며 WebDriver BiDi 사양에서 직접 복제할 수 없습니다. 다른 브라우저에서는 CDP를 있는 그대로 구현하는 것이 불가능하며, 그렇게 하는 방법만 문서화하는 사양을 무의미하게 만듭니다.
낮은 지연 시간 보장
WebDriver BiDi는 성능 저하 없이 긴 지연 시간을 처리하도록 설계되어야 합니다. 클라이언트와 서버가 거의 항상 동일한 물리적 머신에서 실행되기 때문에 CDP에서는 지연 시간이 짧지만 WebDriver BiDi에서는 그렇지 않습니다. 따라서 WebDriver BiDi는 클라이언트와 서버 간에 필요한 왕복 수를 최소화해야 합니다.
BiDi의 인체공학에 우선순위 두기
개발자가 WebDriver BiDi 클라이언트를 처음부터 빌드할 필요는 없지만, 프로토콜을 지나치게 복잡하게 만들지 않는 것이 중요합니다. 지나치게 복잡한 BiDi는 구현하기가 어려울 뿐만 아니라 작업하기가 어려워져 채택 및 사용에 지장을 줄 수 있습니다.
BiDi의 구현 가능성 보장
WebDriver BiDi는 다양한 브라우저의 제한사항을 고려하여 현실적으로 구현할 수 있어야 합니다. 예를 들어, BiDi에 의해 클라이언트에 노출된 모든 JavaScript 객체를 유지하면 메모리 누수가 발생할 수 있고, 아무것도 유지하지 않으면 디버깅과 페이지의 JavaScript와의 상호작용에 방해가 됩니다. 성능 저하 없이 효과적인 브라우저 자동화를 가능하게 하는 균형을 유지하는 것이 중요합니다.
문제점 극복
이 섹션에서는 WebDriver BiDi 구현의 문제를 해결하기 위해 사용할 수 있는 전략에 대해 설명합니다.
신속한 프로토타입 제작
BiDi의 성공에는 구현 가능성 문제를 해결하는 것이 매우 중요합니다. 사양 및 테스트의 진전을 가속화하기 위해 Google은 NodeJS를 사용하여 신속한 프로토타입 제작 접근 방식을 채택했습니다. 이를 통해 다양한 솔루션을 실험할 수 있을 뿐만 아니라 웹 플랫폼 테스트를 쉽게 개발할 수 있습니다.
성능을 고려한 디자인
이러한 설계 결정은 경우에 따라 WebDriver BiDi의 지연 시간이 길기 때문에 성능을 근거로 합니다. 예를 들어 브라우저에서 객체 ID와 값을 검색할 때 WebDriver BiDi에는 한 번의 왕복만 필요하지만 CDP에는 두 번의 왕복이 필요합니다. WebDriver BiDi는 단일 응답으로 ID와 값을 모두 반환할 수 있지만 (결과는 JSON 직렬화가 가능해서는 안 됨) CDP는 이를 별도로 반환해야 하기 때문입니다.
웹 플랫폼 테스트 (WPT) 강조
웹 플랫폼 테스트는 BiDi의 작업에서 중요한 역할을 합니다. 현재 WebDriver 'Classic'과 WebDriver BiDi를 다루는 WPT는 모든 구현에 대한 신뢰할 수 있는 참조 역할을 합니다. 이러한 테스트는 다양한 구현에서 실행되고 통과되도록 설계되어 교차 브라우저 프로토콜의 일관된 실행을 보장합니다. 이는 WebDriver BiDi의 성공에 매우 중요합니다. 대시보드에서 최신 WPT 결과를 확인해 보세요.
계획은 무엇이며 현재 진행 상황은 무엇인가요?
WebDriver BiDi 로드맵을 살펴보고 프로젝트의 방향을 파악하세요. 로드맵은 현재 진행 중인 작업이며 끊임없이 진화합니다.
정보 소스 역할을 하는 브라우저 간 구현 상태는 최신 웹 플랫폼 테스트를 참고하세요.
프로젝트 마일스톤을 지속적으로 확인하여 진행 상황을 모니터링합니다.
2023년 달성한 성과를 살펴보고 최신 소식을 확인해 보세요.
WebDriver BiDi 지원: 지원 방법
WebDriver BiDi가 포함된 브라우저 자동화의 미래에 대해 기대하고 계신가요? 후원하는 방법은 다음과 같습니다.
- 초기 테스터 겸 어답터가 되어 WebDriver BiDi의 미래를 함께 만들어 주세요.
- 널리 홍보하기 해시태그 #WebDriverBiDi를 사용하여 소셜 미디어에서 프로젝트를 공유합니다.
- 지원을 요청합니다. 기능 요청을 제출하거나 선호하는 도구에 WebDriverBiDi 채택 계획을 확인하세요.
- RFC에 참여하여 API에 관한 의견을 제공합니다.
자주 묻는 질문
WebDriver BiDi가 Chrome DevTools 프로토콜 (CDP)을 대체할 예정인가요?
아니요. Chromium 기반 브라우저는 계속 CDP를 디버깅 목적으로 사용하는 반면 WebDriver BiDi는 더 인체공학적인 API로 테스트 요구사항을 해결하기 위한 새로운 사양입니다.
Puppeteer가 CDP를 사용하고 있는데 Puppeteer가 지원 중단된다는 의미인가요?
아니요. 하지만 WebDriver BiDi를 사용하면 Puppeteer가 브라우저 간 자동화 도구가 될 수 있습니다.
공개 로드맵이 있나요?
예. GitHub의 로드맵을 방문하세요.