Puppeteer 24.16 리뷰: 크롤링 오케스트레이션 없이 Chrome 중심으로 동작하는 브라우저 자동화

Puppeteer는 JavaScript로 실제 Chrome을 제어할 수 있게 해 주는 Google의 Node 라이브러리입니다. 직접 자동화 로직을 짜면 Chrome DevTools Protocol이 명령을 전달하고, 브라우저 전체가 페이지를 렌더링한 뒤에야 그 결과를 읽어 올 수 있습니다. GitHub의 puppeteer/puppeteer에 올라와 있고, Apache-2.0 라이선스로 배포되며 TypeScript로 작성되었습니다. 제가 스냅샷을 뜬 시점에는 약 95.3k 스타, 정확히 95,307개를 기록하고 있었습니다. 공식 소개 문구도 일부러 범위를 좁게 잡습니다. "Chrome(실험적으로 Firefox도) 를 제어하는 JavaScript API"라고 설명하는데, 이 한 줄만 봐도 이 도구가 무엇인지, 그리고 무엇이 아닌지가 또렷하게 드러납니다.

저는 Puppeteer 24.16.0을 다른 브라우저 자동화 라이브러리와 똑같은 기준으로 평가했습니다. 정적 카탈로그와 페이지네이션, 기사, JavaScript 렌더링 카탈로그, JSON API, 500 에러를 반환하는 경로, 작은 크롤 그래프, 그리고 Books to Scrape와 Quotes to Scrape까지 모두 같은 fixture 서버와 공개 데모로 테스트했습니다. 결과는 깔끔했고 군더더기 없었습니다. 다만 제 책상 위에는 다른 헤드리스 브라우저 라이브러리처럼 딱 하나의 과제도 남았습니다. 그 빈칸을 솔직하게 짚어 내는 일이야말로, 진짜 쓸 만한 리뷰와 홍보성 보도자료를 가르는 가장 큰 차이입니다.

수치보다 더 눈에 들어온 건 하나였습니다. 데이터가 JSON 엔드포인트에서 내려오는 페이지에서 Puppeteer는 DOM을 굳이 스크래핑하지 않고도 8개 레코드를 전부 가져왔습니다. 페이지 안에서 fetch를 실행한 뒤 응답 객체를 직접 읽어 온 겁니다. 여기에 작동하는 스크린샷과 자연스러운 네이티브 렌더링까지 더해지면, 이 도구의 성격은 분명해집니다. 이것은 성숙한 Chrome 렌더러이지 크롤러 프레임워크가 아니며, 그 차이는 코드를 한 줄 쓰기도 전에 중요해집니다.

Puppeteer는 실제로 무엇이며, 무엇과 경쟁하는가

이 도구를 이해하려면 먼저 카테고리부터 정리해야 합니다. Puppeteer는 브라우저 자동화 라이브러리입니다. Chrome을 띄우고, 페이지를 열고, 페이지의 JavaScript가 실행되도록 둔 다음, 렌더링된 결과를 읽거나 캡처할 수 있게 해 줍니다. 서버가 처음 보내는 빈 껍데기가 아니라 스크립트가 다 돌아간 이후의 페이지가 필요할 때 HTTP 클라이언트와 HTML 파서 대신 이 도구를 쓰는 이유가 바로 여기에 있습니다.

형태상으로는 Scrapy 같은 크롤러 프레임워크나 LLM-Markdown 도구가 아니라, Playwright와 Selenium처럼 실제 브라우저를 다루는 계열의 라이브러리와 경쟁합니다. Puppeteer에 수천 개의 URL을 던져 놓고 큐잉, 중복 제거, 공손한 속도 조절, 데이터셋 저장까지 기대한다면, 렌더러를 크롤링 문제에 얹어 놓은 셈입니다. 페이지는 예쁘게 렌더링하겠지만 오케스트레이션은 해 주지 않습니다. 이건 버그가 아니라 범위의 경계입니다. 그리고 이 지점이야말로 도구를 고르기 전에 반드시 이해해야 할 가장 중요한 포인트이기도 합니다.

Puppeteer는 Google Chrome 팀에서 시작한 도구라서 설계 자체가 Chrome 우선입니다. API도 브라우저의 디버깅 프로토콜 위에 얇고 정교하게 덧댄 장갑처럼 느껴집니다. 좋은 의미에서 오래되고 덜 요란한 도구이기도 합니다. 필요한 메서드는 수년째 안정적으로 유지되고 있고, 문서도 탄탄하며, 주변 생태계도 깊습니다.

네이티브 렌더링과 페이지 내부 fetch 패턴

결과 표에서 특히 눈여겨볼 만한 동작은 두 가지입니다. 실제 사용 방식을 가장 잘 보여 주기 때문입니다.

첫째는 네이티브 렌더링입니다. JavaScript로 상품 그리드를 페이지 로드 후 클라이언트 측에서 만드는 카탈로그는 8/8을 그대로 가져왔고, 전체 페이지 스크린샷도 디스크에 저장되었습니다. 설정은 단순했지만 goto 이후 대상 콘텐츠를 기다리는 과정은 포함했습니다. 공개된 Quotes to Scrape JS 페이지도 같은 방식으로 10개의 인용문을 모두 반환했습니다. 다만 이건 fixture 기반 결과이므로, 일반적인 렌더링 재현율 점수로 보면 안 됩니다.

둘째는 JSON API fixture입니다. /api/dynamic-products에서 상품 데이터를 불러오도록 되어 있었고, page.evaluate 안에서 동일 출처 fetch를 실행하자 렌더된 행을 파싱하지 않고도 8개 레코드를 모두 얻을 수 있었습니다. 이건 Puppeteer만의 특수 기능이라기보다 일반적인 브라우저 평가 패턴에 가깝습니다. 엔드포인트와 요청 계약을 이미 알고 있다면 추출 과정을 크게 단순화할 수 있지만, 인증 헤더, 런타임 토큰, 자격 증명 정책, CORS/CSP, 서비스 워커, 페이지네이션 같은 요소 때문에 실제 애플리케이션 요청은 여전히 달라질 수 있습니다.

마지막으로 꼭 남길 핵심 프레이밍은 숫자가 아니라 이 한 문장입니다. Puppeteer는 성숙한 Chrome 렌더러이지, 크롤러가 아닙니다. 이 두 말은 모두 사실이고, 많은 글이 두 번째 사실을 건너뜁니다.

Puppeteer가 Chrome과 대화하는 방식

Chrome에서 Puppeteer는 Chrome DevTools Protocol(CDP)을 사용합니다. 이 프로토콜은 브라우저 DevTools가 사용하는 WebSocket 기반 JSON 채널입니다. puppeteer.launch()가 Chrome을 실행하고 프로토콜 연결을 열면, goto, $$eval, screenshot 같은 호출이 더 높은 수준의 API를 통해 브라우저 작업을 노출합니다. 아래에서 설명할 Firefox 지원은 WebDriver BiDi 경로를 따르기 때문에, Puppeteer의 모든 동작이 CDP 명령과 1:1로 대응되는 건 아닙니다.

page.evaluate는 페이지 컨텍스트 안에서 함수를 실행하므로, 상대 경로 fetch('/api/...')는 그 페이지의 origin을 사용하고 조건이 맞으면 쿠키와 세션 상태를 재사용할 수 있습니다. 하지만 애플리케이션이 만든 인증 헤더, 요청 옵션, 토큰, 서비스 워커 동작까지 자동으로 똑같이 재현해 주지는 않습니다. 이 동일 출처 fixture에서는 JSON을 바로 반환했지만, 실제 프로덕션 요청은 반드시 계약을 직접 확인해야 합니다.

이 점이 Puppeteer가 무거운 이유이기도 합니다. 각 페이지는 실제 렌더링 엔진을 얹은 진짜 브라우저 탭입니다. JavaScript가 많은 페이지에서는 정확도가 높아지지만, HTTP 전용 fetch보다 메모리와 시작 비용은 더 듭니다. 공짜 렌더링은 없습니다. CDP는 그 비용을 더 선명하게 보이게 할 뿐입니다.

엔진 이야기를 정확히 하자면

Puppeteer는 "Chrome 전용"이라고 단순하게 말하는 경우가 많습니다. 제가 테스트한 버전 기준으로는 그 말이 맞지 않고, 이 점을 바로잡아야 비교 기준도 정확해집니다.

Chrome for Developers와 Mozilla는 Firefox 지원이 추가됐을 때 이를 따로 소개했습니다. 제가 실행한 빌드는 24.16.0이라 v23보다 한참 뒤 버전이므로, "Chrome 전용"이라고 표현하면 실제 제공 범위를 과소평가하는 셈입니다. WebKit 미지원과, Playwright에 비해 아직 덜 성숙한 멀티 엔진 지원 스토리가 Puppeteer의 진짜 한계입니다. 핵심은 "한 엔진 대 세 엔진"이 아닙니다.

Firefox/BiDi 경로는 제가 테스트한 버전에서 문서화되어 있고 사용 가능하지만, 제 fixture는 그 경로로 돌리지 않았기 때문에 측정값이 아니라 기능 여부만 적습니다. Firefox 렌더링이 여러분의 대상 사이트에서 중요하다면, 실제 페이지로 직접 검증한 뒤 도입을 결정하세요. 엔진과 언어 범위를 함께 비교하고 싶은 독자는 Playwright-vs-Puppeteer 비교 글에서 같은 테스트를 두 라이브러리에 적용한 결과를 볼 수 있습니다. 여기서는 Puppeteer만 다룹니다.

설치와 셋업의 현실: 무거운 건 브라우저다

기본적인 npm install puppeteer 경로는 호환되는 Chrome for Testing 빌드를 함께 내려받습니다. 이 동작은 설정으로 건너뛰거나 다른 위치로 바꿀 수 있고, 사용자는 Puppeteer가 다른 실행 파일을 가리키게 할 수도 있으므로 버전 매칭은 배포 방식에 따라 달라집니다. 이번 설치에서 가장 무거웠던 부분은 바로 브라우저 다운로드였습니다. 그리고 패키지 관리자 감사 스냅샷 하나를 영구적인 보안 속성처럼 보면 안 됩니다.

이 자동 번들링은 정말 편리한 장점이자, 동시에 실제 무게도 있는 선택입니다. 장점은 호환 브라우저를 따로 찾거나 버전을 손으로 맞출 필요가 없고, npm install만으로 바로 동작하는 조합을 얻는다는 점입니다. 단점은 브라우저 자체를 내려받아야 하니 디스크와 대역폭을 그만큼 고려해야 한다는 것입니다. 특히 CI 환경에서는 캐시가 비어 있을 때마다 새 러너가 이 비용을 다시 치르게 됩니다.

Playwright와의 차이도 분명합니다. Playwright는 라이브러리 설치와 브라우저 설치를 분리합니다. 먼저 라이브러리를 설치한 뒤, 별도로 npx playwright install을 실행해 브라우저 빌드를 받아오는 방식입니다. 둘 중 어느 쪽도 불편하다고 할 정도는 아니지만, 실패하는 방식은 다릅니다. Puppeteer는 한 번의 명령으로 끝나서 편하지만, 네트워크가 느린 환경에서는 크기로 놀랄 수 있고, Playwright는 두 번째 단계를 깜빡하기 쉽습니다. 무엇을 하는지 알고 시작하는 게 중요합니다.

직접 돌려본 결과

모든 테스트는 Node v22.22.3, macOS arm64 환경에서, 127.0.0.1의 로컬 fixture 서버와 두 개의 공개 연습 사이트를 대상으로 수행했습니다. Puppeteer 24.16.0과 번들 Chrome을 사용했습니다. 각 fixture의 정답은 실행 전에 미리 기록해 두었기 때문에, 재현율은 Puppeteer가 우연히 출력한 값이 아니라 고정된 기대값과 비교해 측정했습니다.

공개 연구 패키지에는 fixture 서버, 테스트 러너, 그리고 정답 데이터가 포함되어 있습니다. 다만 엄격한 보안 검토에서 dependency lock 데이터와 환경 종속 엔드포인트 자료가 거절되었기 때문에, 의존성 잠금 파일과 원시 실행 요약은 공개 번들에서 제외했습니다. 안전한 로컬 fixture를 재현하려면 tools/puppeteer/tests 안에서 npm install 후 node run_puppeteer_material_tests.mjs를 실행하고, 결과를 공개된 정답 데이터와 비교하면 됩니다. 공개 데모 페이지는 바뀔 수 있으므로, 기대 개수 검증의 안정적인 기준은 로컬 fixture입니다.

정확한 과거 의존성 구성을 복원하려면, 공개되지 않은 lock 파일을 공적 증거처럼 보지 말고 로컬에서 새로 생성해 감사해야 합니다.

이 중 몇 가지는 표만으로는 부족하니 한 문장씩 덧붙이겠습니다.

직접 작성한 페이지네이션 코드는 기대했던 카탈로그 항목 12개를 모두 복구했습니다. 기사 셀렉터는 제목과 기대한 본문 3문단을 가져왔고, 주변 boilerplate도 DOM에는 그대로 남아 있었습니다. Puppeteer는 렌더링된 DOM을 제공했을 뿐, 무엇을 기사 본문으로 볼지는 Puppeteer가 아니라 셀렉터 로직이 정했습니다.

테스트한 HTTP 500 경로에서는 goto가 500 상태를 가진 응답 객체를 돌려줬고, 예외는 발생시키지 않았습니다. 하지만 이것이 timeout, DNS 실패, 브라우저 크래시, 분리된 frame, 그 밖의 네비게이션 오류까지 다 커버한다는 뜻은 아닙니다. 그런 경우는 여전히 별도로 처리해야 합니다.

크롤 그래프는 이 도구의 본질을 가장 잘 보여 주는 사례입니다. fixture 내부 링크를 따라 12페이지를 방문하고, 이미 방문한 URL을 다시 보지 않도록 깊이를 추적하는 일은 직접 작성한 breadth-first search로 처리했습니다. 왜냐하면 Puppeteer에는 기본 크롤 큐가 없기 때문입니다. 그 결과 깊이 {0:1, 1:4, 2:7}에서 12페이지를 모두 찾았고, 즉 BFS는 잘 동작했습니다. 하지만 BFS는 제가 만든 것입니다. Puppeteer는 페이지를 렌더링했을 뿐이고, 사이트를 돌아다니는 로직은 제가 쓴 코드였습니다. 12페이지 정도는 고작 몇 줄이면 충분하고 별문제가 아닙니다. 하지만 수천 개 URL에 대해 중복 제거, 재시도, 예의 있는 지연까지 넣어야 한다면, 그 몇 줄은 곧 프로젝트가 됩니다.

한 가지 경고는 반복해서 말할 만합니다. 아티팩트에는 테스트별 실행 시간이 들어 있지만, 그것은 단일 실행·단일 머신의 관찰값일 뿐 벤치마크는 아닙니다. 노트북 하나와 실행 한 번만으로 Puppeteer의 속도를 다른 도구와 순위 매기듯 비교하지 않습니다. 이 수치가 말해 주는 것은 8가지 서로 다른 페이지 유형에서의 재현율과 동작입니다. 스톱워치 성능 주장까지는 아닙니다.

테스트하지 않은 것

결과를 과장해서 읽지 않도록, 이번 실행 범위 밖에 있었던 항목들을 아래에 정리합니다. 따라서 이 수치들에도 포함되지 않았습니다.

이 항목들은 약점이 아닙니다. 한 번의 fixture 실행이 정직하게 주장할 수 있는 범위의 경계일 뿐입니다.

장단점

장점:

• 명시적인 콘텐츠 대기와 함께하는 네이티브 JavaScript 렌더링: 동적 fixture 8/8, 공개 데모 10개 인용문 모두 성공, 스크린샷 포함
• 직접 작성한 페이지네이션과 기사 셀렉터가 기대한 fixture 항목을 정확히 복구
• 페이지 내부 fetch로 알려진 동일 출처 엔드포인트에서 DOM 파싱 없이 8개 레코드 획득
• 테스트한 HTTP 500 응답이 예외 없이 확인 가능한 응답 객체로 반환됨
• 기본 설치만으로 호환되는 Chrome for Testing 빌드 다운로드, 필요 시 다른 실행 파일 지정 및 다운로드 생략도 가능
• CDP 위에 구축된 성숙한 Chrome 중심 API, 깊은 생태계, 탄탄한 문서, Apache-2.0 라이선스
• 평판보다 범위가 넓음: v23부터 WebDriver BiDi를 통한 Firefox 지원이 문서화됨

단점:

• 기본 내장 크롤 큐, 데이터셋 작성기, 속도 제한 기능 없음 — 크롤 규모 작업은 별도 코드나 래퍼가 필요
• WebKit 엔진 미지원, 멀티 엔진 이야기는 Playwright보다 여전히 덜 성숙함
• 실제 브라우저의 무게: 번들 Chrome 다운로드와 HTTP 전용 도구 대비 페이지당 메모리 비용
• Node 기반이므로 다른 언어에서 쓰려면 브리지를 직접 만들고 유지해야 함
• 제가 실행한 버전(24.16.0)은 npm 최신(25.3.0)보다 메이저 버전 하나 뒤처짐 — 현재 버전에서 다시 검증하는 것이 안전함

누구에게 맞고, 누구는 피해야 하는가

Node를 쓰고 있고, 대상 페이지가 Chrome에서 잘 렌더링되며(대부분 그렇습니다), JavaScript 실행 이후의 페이지를 읽고 스크린샷까지 남길 수 있는 성숙하고 집중도 높은 라이브러리를 원한다면 Puppeteer가 잘 맞습니다. 동적 페이지 묶음을 웹 스크래핑하거나, 페이지 자신의 세션으로 JSON API를 가져오거나, 렌더링 증거용 스크린샷을 캡처해야 한다면 부담이 적은 기본값으로 꽤 강력합니다. 필요하다면 Firefox를 BiDi 경로로 확장할 수도 있고, 생태계가 깊어서 대부분의 문제는 이미 누군가 한 번쯤 겪어 봤을 가능성이 큽니다.

하지만 문제가 렌더링이 아니라 크롤 오케스트레이션이라면 한 번 더 생각하세요. 수백 또는 수천 개 URL을 중복 제거, 재시도, 속도 제한과 함께 탐색해야 한다면, Puppeteer만으로는 결국 크롤러를 직접 다시 만들어야 합니다. 그건 이 도구가 놓인 올바른 높이가 아닙니다. 페이지가 실제로 JavaScript 없이도 데이터를 드러내는 경우라면 헤드리스 브라우저 자체를 건너뛰는 편이 좋습니다. HTTP 요청과 파서만으로 충분하다면, 실제 브라우저는 메모리와 셋업 시간만 잡아먹는 비싼 과잉 장비입니다. 그리고 WebKit 수준의 일치가 필요하거나 JavaScript가 아닌 언어 클라이언트가 필요하다면, 이 축에서는 맞는 도구가 아닙니다.

대안, 그리고 Thunderbit의 위치

먼저 가장 솔직한 프레임부터 말하면, Puppeteer는 무료이고 Apache-2.0이며 셀프호스팅입니다. 브라우저 팜, 덧붙여야 하는 크롤 코드, 끊임없는 안티봇 대응까지 전부 사용자가 책임져야 합니다. 많은 프로젝트에서는 바로 그 소유 구조가 정답이며, 이미 가지고 있는 브라우저보다 더 싸게 인증된 페이지를 렌더링해 주는 관리형 서비스는 없습니다.

오픈 소스 안에서의 비교는 브랜드가 아니라 역할 기준으로 하는 것이 맞습니다. 크롤 규모가 중요하다면 Crawlee가 자연스러운 파트너입니다. 그 안의 PuppeteerCrawler는 Puppeteer에 빠져 있는 request queue, dataset, throttling을 감싸 주므로 렌더링은 유지하면서 오케스트레이션을 얻을 수 있습니다. 출력 목표가 렌더링된 DOM이 아니라 LLM 파이프라인용 깔끔한 Markdown이라면, Crawl4AI가 실제 브라우저를 돌리면서 그 형식에 맞는 결과를 만들어 줍니다. 페이지가 브라우저를 전혀 필요로 하지 않는다면 Scrapy 같은 HTTP 우선 프레임워크가 더 가볍고 적합한 범주입니다. 여러 도구를 한 번에 비교하고 있다면, 오픈 소스 스크레이퍼 총정리에서 카테고리를 나란히 볼 수 있습니다.

Thunderbit 같은 관리형 서비스는 브라우저 운영과 추출을 API 뒤로 숨깁니다. 이번 Puppeteer fixture 테스트에는 포함되지 않았기 때문에, 렌더링, 차단 회피, 추출 품질, 비용에 대해 이 리뷰가 직접 비교한다고 말할 수는 없습니다. 선택의 경계는 운영 책임입니다. 브라우저와 크롤 코드를 직접 유지할 것인지, 아니면 그 계층 일부를 제공자에게 맡길 것인지의 문제입니다.

Puppeteer를 쓸 경우 벤더 사용료는 없지만, 컴퓨트, 대역폭, 브라우저 유지보수, 오케스트레이션, 운영은 모두 여러분의 몫입니다. 관리형 방식은 사용량에 따라 비용을 지불하는 대신 일부 책임을 제공자에게 넘깁니다. 이번 실험은 그 결과를 비교하지 않았습니다.

웹 데이터 추출을 위해 Thunderbit 사용해 보기

최종 판단

Node를 쓰고 Chrome 우선 브라우저 자동화가 필요하다면 Puppeteer 24.16.0은 충분히 검토할 가치가 있습니다. 직접 작성한 fixture 코드는 정적 항목 12개, 동적 항목 8개, 공개 데모 인용문 10개를 모두 복구했고, 알려진 동일 출처 API는 page.evaluate를 통해 8개 레코드를 반환했으며, 스크린샷도 정상 작동했고, 테스트한 HTTP 500도 여전히 확인 가능한 상태로 남았습니다. 다만 이 결과는 특정 fixture와 다소 오래된 메이저 버전에 대한 것이지, 일반적인 추출 재현율을 뜻하지는 않습니다.

하지만 주장 범위는 정확히 잡아야 합니다. Puppeteer는 렌더러이지 크롤러가 아닙니다. 12페이지를 훑는 작업에도 수동 BFS가 필요했는데, 내장 큐가 없기 때문입니다. 규모가 커지면 그 공백은 실제 작업량입니다. Crawlee 같은 래퍼에 맡기거나, 직접 그 기계를 짜야 합니다. Chrome 우선이고 BiDi를 통한 Firefox 지원은 있지만 WebKit은 없으므로, 멀티 엔진 폭을 원하는 도구도 아닙니다. 실제 브라우저의 무게를 그대로 안고 있고, 제가 테스트한 24.16.0은 최신 25.3.0보다 한 메이저 버전 뒤에 있었습니다. 이 네 가지를 알고 시작하면 Puppeteer는 훌륭한 Chrome 자동화 라이브러리입니다. 반대로 사이트를 대신 크롤링해 주길 기대한다면, 결국 다운로드한 게 아니라 직접 만들어야 할 크롤러를 만들고 있게 될 것입니다.

웹 데이터 추출을 위해 Thunderbit 사용해 보기 Get Started Free

자주 묻는 질문

Puppeteer는 JavaScript 페이지를 렌더링하나요, 아니면 플러그인이 필요한가요? 네이티브로 렌더링합니다. 플러그인은 필요 없습니다. 제가 테스트한 동적 fixture에서는 클라이언트 측에서 만든 상품 8개를 8/8로 가져왔고 전체 페이지 스크린샷도 저장됐으며, 공개된 Quotes to Scrape JS 페이지도 같은 방식으로 인용문 10개를 모두 반환했습니다. 일반적인 goto를 실행한 뒤, 렌더링된 DOM을 읽으면 됩니다. Puppeteer는 DevTools Protocol로 실제 Chrome을 제어하므로, 페이지 스크립트가 실제로 실행된 다음에야 내용을 읽을 수 있습니다.

Puppeteer는 HTML을 파싱하지 않고 JSON API를 스크래핑할 수 있나요? 네, 엔드포인트와 요청 계약이 맞는 경우 가능합니다. page.evaluate는 페이지 origin에서 요청을 보낼 수 있고 조건이 맞으면 쿠키를 재사용할 수 있지만, 애플리케이션 헤더, 토큰, 옵션, 서비스 워커 동작까지 자동으로 재현하지는 않습니다. 동일 출처 fixture에서는 DOM 파싱 없이 8개 레코드를 모두 반환했습니다.

Puppeteer는 웹 크롤러인가요? 아니요. 브라우저 자동화 라이브러리이지 크롤러 프레임워크가 아닙니다. 기본적인 request queue, dataset writer, throttle 기능이 없기 때문에, 제가 수행한 12페이지 크롤(depth {0:1, 1:4, 2:7})에는 직접 작성한 breadth-first search가 필요했습니다. 이것은 결함이 아니라 범위의 경계입니다. 크롤 규모가 필요하다면, Puppeteer가 빠뜨린 큐와 데이터셋 기능을 더해 주는 Crawlee의 PuppeteerCrawler 같은 래퍼와 함께 쓰면 됩니다.

Puppeteer는 Chrome 전용인가요? 이제는 아닙니다. CDP 기반의 Chrome 우선 도구이긴 하지만, v23부터 WebDriver BiDi를 통한 Firefox 지원이 문서화되어 있고, 제가 테스트한 버전(24.16.0)은 그보다 훨씬 뒤입니다. 다만 WebKit은 제어하지 않으며, 멀티 엔진 스토리는 Playwright보다 덜 성숙합니다. 정확한 표현은 "Chrome 전용"이 아니라 이 한계입니다. 이번 리뷰에서는 Chrome만 사용했기 때문에, Firefox via BiDi는 측정값이 아니라 문서화된 기능으로만 언급합니다.

Puppeteer를 설치하면 실제로 무엇이 다운로드되나요? 기본적으로 npm install puppeteer는 호환되는 Chrome for Testing 빌드를 다운로드합니다. 이 다운로드는 건너뛰거나 다른 대상으로 바꿀 수 있고, 다른 실행 파일도 설정할 수 있으므로 버전 일치는 배포 선택에 따라 달라집니다. 브라우저 자체의 디스크와 대역폭을 반드시 고려하세요. 특히 캐시가 없는 CI 러너에서는 더 그렇습니다. 이번 리뷰는 24.16.0을 테스트했습니다. 공개 시점의 최신 릴리스에서 핵심 fixture를 다시 실행해 보는 것이 좋습니다.