# Firefox에 대한 Puppeteer 공식 지원 발표

> Clean Markdown view of GeekNews topic #16222. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=16222](https://news.hada.io/topic?id=16222)
- GeekNews Markdown: [https://news.hada.io/topic/16222.md](https://news.hada.io/topic/16222.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-08-08T10:21:01+09:00
- Updated: 2024-08-08T10:21:01+09:00
- Original source: [hacks.mozilla.org](https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/)
- Points: 6
- Comments: 1

## Summary

Puppeteer가 Firefox를 정식으로 지원하게 되어 Chrome과 Firefox에서 자동화 및 엔드 투 엔드 테스팅을 쉽게 수행할 수 있습니다. WebDriver BiDi 기반의 크로스 브라우저 프로토콜을 사용하여 향후 더 많은 브라우저를 지원할 수 있는 가능성을 열어줍니다. Firefox의 실험적인 CDP 지원이 중단되고 WebDriver BiDi로 전환됨에 따라, 더 표준화된 자동화 기능을 제공하게 됩니다.

## Topic Body

- Puppeteer 버전 23부터 Firefox를 정식으로 지원하게 되어, 이제 Chrome과 Firefox에서 자동화 및 엔드 투 엔드 테스팅을 쉽게 수행할 수 있음   
  - `const browser = await puppeteer.launch({browser: "firefox"});`  
- Chrome과 마찬가지로 Puppeteer는 최신 안정 버전의 Firefox를 다운로드하고 실행 가능  
- Firefox 지원은 Firefox 전용 자동화 프로토콜이 아닌 현재 Gecko와 Chromium에 구현되어 있는 크로스 브라우저 프로토콜인 WebDriver BiDi를 기반으로 함  
  - 크로스 브라우저 프로토콜을 사용하면 향후 더 많은 브라우저를 쉽게 지원할 수 있음  
  
### 기술적 배경  
- 최근까지 브라우저 자동화를 원하는 사람들에게는 두 가지 주요 선택지가 있었음  
  - W3C WebDriver API 사용  
  - 브라우저별 전용 API 사용 (Chrome DevTools Protocol, Firefox Remote Debugging Protocol 등)  
- 두 선택지 모두 상당한 트레이드오프가 있음  
  - 고전적 WebDriver API는 HTTP 기반이며, 브라우저에 명령을 보내고 응답을 기다리는 모델을 가짐  
  - 이는 페이지를 로드하고 요소가 표시되는지 확인하는 등의 자동화 시나리오에는 잘 작동하지만, 브라우저에서 이벤트를 받거나 여러 명령을 동시에 실행하는 등의 고급 사용 사례에는 적합하지 않음  
  - 브라우저별 API는 일반적으로 브라우저 내 개발자 도구의 복잡한 사용 사례를 지원하도록 설계되었기 때문에 WebDriver보다 훨씬 앞선 기능 세트를 제공함  
- 따라서 브라우저 자동화 클라이언트는 단일 프로토콜을 사용하여 여러 브라우저를 지원하고 제한된 기능 세트를 제공하거나, 더 풍부한 기능 세트를 제공하지만 각 지원 브라우저에 대해 별도로 기능을 구현해야 하는 선택을 해야 했음  
- 이는 우수한 크로스 브라우저 자동화를 생성하는 데 드는 비용과 복잡성을 높였음   
- LSP(Language Server Protocol)이 개발되기 전에 상황이 이와 유사했음  
- WebDriver BiDi는 브라우저별 프로토콜로 제한되었던 자동화 기능 세트를 표준화된 프로토콜로 가져와 모든 브라우저와 자동화 툴에서 사용할 수 있도록 함  
  
### Firefox의 실험적인 CDP(Chrome DevTools Protocol) 지원 제거  
- 초기의 크로스 브라우저 테스트 개선 작업의 일환으로, 테스팅 사용 사례를 지원하는 데 필요한 몇 가지 명령과 이벤트로 제한된 CDP의 부분 구현을 제공함  
- 그러나 이것이 크로스 브라우저 자동화의 발전 방향이 아니라는 것이 분명해지면서 이에 대한 노력이 중단되었음  
- 그 결과 유지 관리되지 않고 사이트 격리와 같은 현대적 Firefox 기능과 호환되지 않음  
- 따라서 2024년 말에 지원이 제거될 예정임  
  
### 앞으로의 계획  
- 여전히 지원되지 않는 일부 API가 있음   
  - CDP 전용 API  
  - 추가적인 표준화 작업이 필요한 API  
  - 표준은 있지만 아직 구현되지 않은 API  
- 사용자의 피드백을 통해 우선순위를 정할 예정

## Comments



### Comment 27871

- Author: xguru
- Created: 2024-08-09T08:48:49+09:00
- Points: 1

#### [Hacker News 의견](https://news.ycombinator.com/item?id=41182847)   
- Puppeteer 팀이 Google을 떠나 Microsoft로 가서 Playwright를 계속 개발한 것이 Google에 큰 타격이었음  
  - Google은 브라우저 자동화 도구가 AI 에이전트 전략에 얼마나 중요한지 깨닫지 못했음  
  - Google은 Puppeteer를 포기하고 MS/Playwright에 의존하거나 Puppeteer를 위한 새로운 길을 찾아야 했음  
  - WebDriver BiDi는 Chrome DevTools Protocol(CDP)의 장점을 표준 방식으로 발전시킴  
  
- WebDriver BiDi 프로토콜이 브라우저를 생성하는 프로토콜은 아니지만, 거의 90%는 그 역할을 할 수 있을 것 같음  
  - Gecko는 Servo 이후로 많이 발전했고, 요즘 꽤 성능이 좋음  
  - Chromium 기반 브라우저를 만드는 것이 Gecko 기반 브라우저를 만드는 것보다 훨씬 쉬움  
  - API를 사용해 탐색, 요청 가로채기, 콘솔 읽기, JS 실행 등을 할 수 있음  
  - 브라우저 크롬을 제거하고 맞춤형 브라우저를 만들 수 있으면 좋겠음  
  
- Playwright는 모든 최신 렌더링 엔진(Chromium, WebKit, Firefox)을 지원함  
  
- 접근성 트리에 대해 궁금함  
  - Playwright에서 접근성 트리가 제거된 이유는 엔진별 내부 데이터 구조의 덤프였기 때문임  
  - 접근성 트리는 페이지의 모든 의미 요소를 요약한 것으로, 스냅샷 테스트나 BDD 테스트에 훌륭함  
  - 접근성 트리가 주요 브라우저 엔진에서 표준화되기를 바람  
  - 웹 개발 관점에서 CSS와 DOM 같은 다른 레이어에서도 접근 가능하면 좋겠음