대부분의 "Playwright vs Puppeteer" 글은 둘 중 하나가 더 뛰어난 스크래퍼여야 한다는 전제에서 출발합니다. 하지만 그런 식의 프레임은 과하게 해석된 경우가 많습니다. 그래서 저는 두 라이브러리를 똑같은 페이지 묶음에 그대로 적용해 봤습니다. 정적 카탈로그, JavaScript로 렌더링되는 카탈로그, 기사 페이지, 깨진 500 오류 페이지, 작은 크롤 그래프, 그리고 두 개의 공개 연습 사이트까지요. 결과는 거의 구분이 안 될 정도로 비슷했습니다. 재현율도 같고, 렌더링도 같고, 스크린샷도 같고, 한계도 같았습니다.
즉, 이 글은 승자를 선언하는 글이 아닙니다. 브라우저 자동화 도구가 실제로 페이지를 스크래핑할 수 있는지 가르는 핵심 테스트에서는 둘 중 어느 쪽도 앞서지 않았습니다. 대신 이 글에서는 선택을 가르는 진짜 차이, 둘 다 조용히 사용자 몫으로 남겨두는 부분, 그리고 제가 테스트한 버전 간격에 대한 참고 사항을 정리합니다(기준일: 2026-07-09).
왜 이 비교가 공정한가
비교 글들은 각 도구를 서로 다른 페이지에 돌려놓고 승자를 발표하는 경우가 많습니다. 그러면 도구 차이보다 페이지 차이를 더 많이 보게 됩니다. 저는 그 함정을 피하려고 Playwright와 Puppeteer를 같은 로컬 테스트 서버와 같은 공개 데모 사이트, Books to Scrape와 Quotes to Scrape에 각각 적용했습니다. 그래서 모든 수치를 일대일로 비교할 수 있습니다.
이렇게 해야만 "무승부"라는 말에 의미가 생깁니다. 테스트 대상이 다르면 무승부는 그냥 잡음일 뿐입니다. 바이트 단위로 완전히 같을 때 결과가 같다면, 그건 도구 자체에 대한 신호입니다.
각 도구가 실제로 무엇인지
Puppeteer는 Chrome DevTools Protocol을 통해 Chrome을 제어하는 JavaScript API입니다. 공식 소개도 정확히 그렇게 설명합니다. "Chrome(그리고 실험적으로 Firefox)을 제어하는 JavaScript API"라는 뜻입니다. 성숙도가 높고, Chrome 중심이며, Node 기반입니다.
Playwright는 조금 다르게 자신을 정의합니다. "웹 테스트와 자동화를 위한 프레임워크"로, Chromium, Firefox, WebKit을 하나의 API로 제어하며, JavaScript, Python, Java, .NET용 공식 클라이언트를 제공합니다. 두 도구는 뿌리가 같습니다. Playwright는 원래 Google의 Puppeteer 팀에서 출발해 Microsoft로 옮겨온 프로젝트라서, 경쟁자라기보다 사촌처럼 느껴지는 이유가 있습니다.
하지만 스크래핑 관점에서는 두 도구의 동작 방식이 거의 같습니다. 실제 브라우저를 띄우고, 페이지를 열고, 스크립트가 실행되도록 기다린 다음, 렌더링된 DOM을 읽습니다. HTTP 파서 대신 이 둘을 고르는 이유는 딱 하나입니다. JavaScript가 실행된 뒤의 페이지가 필요하지, 그 전에 비어 있는 껍데기가 필요한 게 아니기 때문입니다. 아래 내용은 모두 이 공통 메커니즘에서 나오며, 그래서 두 도구의 결과가 많은 부분에서 서로 비슷할 수밖에 없습니다.
결과를 나란히 보면
여기서 "하나는 확실히 더 좋다"는 이야기가 조용히 무너집니다. 같은 테스트 대상, 같은 수치, 전 항목 동일합니다.
| 테스트 | Playwright | Puppeteer |
|---|---|---|
| 정적 카탈로그(12개 제품) | 12/12, 재현율 1.0 | 12/12, 재현율 1.0 |
| 기사(제목 + 3개 문단) | 3/3, 보일러플레이트 분리 | 3/3, 보일러플레이트 분리 |
| 동적 JS 페이지(네이티브 렌더) | 8/8 + 스크린샷 | 8/8 + 스크린샷 |
| 동적 JSON API | 8/8, 재현율 1.0 | 8/8, 재현율 1.0 |
| HTTP 500 처리 | 확인 가능, 예외 없음 | 확인 가능, 예외 없음 |
| 크롤 그래프(수동 BFS) | 12개 페이지, 깊이 {0,1,2} | 12개 페이지, 깊이 {0,1,2} |
| Books to Scrape | 20개 제품 | 20개 제품 |
| Quotes JS(공개) | 10개 인용문 | 10개 인용문 |
두 도구 모두 별도 설정 없이 JavaScript를 네이티브로 렌더링했습니다. 둘 다 전체 페이지 스크린샷을 캡처했습니다. 둘 다 500 응답을 예외로 던지지 않고, 나중에 확인할 수 있는 response 객체로 돌려줬습니다. 이건 사소해 보여도 대량 스크래핑에서는 꽤 중요합니다. 상태 코드가 나쁜 페이지를 기록하고 끝내야지, 전체 실행이 죽어버리면 안 되니까요.
한 가지 주의할 점을 다시 말하겠습니다. 이건 단일 머신, 단일 실행 결과이지 벤치마크는 아닙니다. 한 대의 노트북에서 페이지별로 시간을 재고 어느 쪽이 몇 밀리초 더 빠르다고 말할 수는 없습니다. 제가 말하는 건 훨씬 좁고, 그래서 더 확실합니다. 추출 재현율과 렌더링 동작 측면에서는 8가지 서로 다른 페이지 유형에서 둘이 같았습니다. 실제 페이지에서 한쪽이 확 벌어질 거라고 기대했다면, 그런 차이는 나오지 않았습니다.
선택을 가르는 진짜 차이
진짜 갈림길은 숫자가 아니라 범위입니다.
Playwright는 하나의 API로 Chromium, Firefox, WebKit을 다루며, JavaScript 외에도 Python, Java, .NET용 1급 클라이언트를 제공합니다. 이건 문서로 분명히 확인되는 강점입니다. 여기서 "문서화된"이라고 굳이 말하는 이유는, 이번 테스트에서는 Chromium만 실제로 사용했기 때문입니다. 그래서 Playwright의 3엔진 지원은 제가 직접 검증한 사실이 아니라 공식 문서에 적힌 기능으로만 말합니다. Safari의 WebKit에서 다르게 렌더링되는 사이트를 다뤄야 하거나, 팀이 Python으로 일한다면 이런 폭넓은 지원이 Playwright의 강점입니다.
Puppeteer는 Chrome 우선입니다. 그리고 여기서 흔히 하는 말은 정확하지 않습니다. 더 이상 "Chrome 전용"이라고만 부를 수는 없습니다. Puppeteer v23부터는 WebDriver BiDi를 통해 Firefox를 실무 수준으로 지원하고 있으며, Chrome에서는 기존 자동화를 유지하기 위해 CDP를 기본값으로 사용합니다. 이 변화는 Chrome for Developers와 Mozilla 모두 문서화했습니다. 제가 테스트한 버전(24.16.0)은 v23보다 훨씬 뒤쪽이라, 실제 비교는 "Chrome 대 3엔진"이 아닙니다. 정확히는 Puppeteer가 Chrome(CDP)과 Firefox(BiDi)를 지원하지만 WebKit은 지원하지 않고, 교차 엔진 지원의 역사는 Playwright보다 짧다는 점입니다. Playwright에는 있고 Puppeteer에는 없는 엔진이 WebKit입니다.
이게 핵심입니다. 속도도 아니고, 정확도도 아니고, 렌더링 충실도도 아닙니다. 그건 비슷합니다. 질문은 범위입니다. WebKit까지 필요하신가요? 아니면 JavaScript가 아닌 언어 클라이언트가 필요한가요? 아니면 Node에서 Chrome과 Firefox만으로 충분한가요? 많은 스크래핑 작업에서는 둘 다 기준을 충족합니다. 그러면 결국 선택 기준은 기능 차이보다 스택 적합성입니다.
둘 다 해주지 않는 것
두 도구가 공통으로 사용자에게 넘겨주는 일이 하나 있습니다. 바로 크롤링 오케스트레이션입니다. 둘 다 기본 제공 요청 큐, 데이터셋 기록기, 자동 속도 조절 기능이 없습니다. 제가 실행한 크롤 그래프 테스트는 내부 링크를 따라가며 깊이를 추적하고, 같은 URL을 다시 방문하지 않는 방식이었는데, Playwright와 Puppeteer 모두에서 직접 BFS를 작성해야 했습니다. 12개 페이지, 깊이 {0,1,2}, 두 번 다 수동 BFS였습니다.
몇 개 안 되는 페이지라면 이 정도는 괜찮습니다. 작은 BFS라면 열두 줄이면 됩니다. 하지만 수백, 수천 개의 URL을 중복 제거, 재시도, 예의 있는 지연과 함께 크롤링해야 한다면, 결국 직접 그 장치를 만들거나 이 엔진들을 감싸는 도구를 써야 합니다. Crawlee는 바로 그런 역할을 하며, Playwright와 Puppeteer 위에 실제 크롤링 레이어를 제공합니다.
이건 결함이 아닙니다. 그리고 정확히 말하면, Playwright와 Puppeteer는 크롤러 프레임워크가 아니라 브라우저 자동화 프레임워크입니다. 큐가 없는 것은 버그가 아니라 범위의 경계입니다. 정확한 이해는 이 도구들을 스크래퍼의 "페이지를 보는" 절반으로 보는 것입니다. 나머지 절반인 "사이트를 도는" 기능은 사용자가 직접 구현하거나, 그 기능을 가진 래퍼를 붙여야 합니다.
설치와 버전 참고 사항
설치는 거의 비슷합니다. npm install로 라이브러리와 브라우저 바이너리가 함께 내려오며, 무게 중심은 브라우저 쪽에 있습니다. Puppeteer는 Chrome 다운로드를 자동으로 포함하고(제가 실행한 환경에서는 깔끔하게 설치됐고, 보고된 취약점도 없었습니다), Playwright는 별도로 npx playwright install을 실행해 브라우저 빌드를 설치합니다. 둘 다 설치가 어렵지는 않지만, 다운로드 시간은 어느 쪽이든 감안해야 합니다. HTTP 전용 도구와 달리, 렌더링을 위해 치르는 진짜 비용은 브라우저 용량과 페이지별 실행 비용입니다.
이제 꼭 밝혀야 하는 점입니다. 저는 Playwright 1.56.0을 최신 1.61.1 릴리스와 비교했고, Puppeteer 24.16.0을 npm 최신 25.3.0과 비교했습니다. 기준일 2026-07-09 시점에서 Puppeteer는 한 주요 버전 정도 뒤처져 있었습니다. 제가 사용한 API는 그 간격에서도 안정적이었기 때문에 결과는 유효합니다. 하지만 이 글을 한참 뒤에 읽고 있다면, 정확한 수치에 베팅하기 전에 현재 버전으로 다시 돌려보는 걸 권합니다. 그리고 한 번 더 분명히 하자면, Playwright에서는 Chromium만 사용했기 때문에 Firefox나 WebKit과의 완전 동등성에 대해서는 "문서상 지원된다" 이상으로 말하지 않습니다.
Playwright와 Puppeteer: 장단점
무승부라는 결론은 장단점 목록이 승부가 아니라 선택의 방향을 알려준다는 뜻입니다.
Playwright
- 장점: 하나의 API로 세 엔진(Chromium, Firefox, WebKit)을 공식 지원; Python, Java, .NET 공식 클라이언트; 네이티브 JS 렌더링에서 완전한 재현율; 계속 넓어지는 지원 범위
- 단점: 기본 내장 크롤 큐 없음; 브라우저 용량과 페이지별 비용 부담; 이번 테스트에서는 Chromium만 사용; 제가 실행한 버전이 최신 릴리스보다 뒤처짐
Puppeteer
- 장점: CDP 기반의 성숙하고 안정적인 Chrome 자동화; 네이티브 JS 렌더링에서 완전한 재현율; 깔끔한 500 처리(response 객체 반환, 예외 없음); 오래 검증된 깊은 생태계; v23부터 WebDriver BiDi를 통한 Firefox 지원 문서화
- 단점: Chrome 우선, Node 기반이며 WebKit 엔진 없음; 기본 내장 크롤 큐 없음; 브라우저 용량 부담; 제가 실행한 버전이 npm 최신보다 한 주요 버전 뒤처짐
누가 무엇을 골라야 하나
Node 환경에서 작업하고, 대상 사이트가 Chrome에서 잘 렌더링되며(대부분 그렇습니다), 성숙하고 집중된 라이브러리와 풍부한 생태계를 원한다면 Puppeteer를 고르세요. Firefox를 WebDriver BiDi로 확장할 여지도 있습니다.
WebKit 지원이 필요하거나, Python 또는 .NET으로 스크래퍼를 작성하고 싶거나, 더 넓은 엔진·언어 범위를 가진 프로젝트를 원한다면 Playwright를 고르세요. 특히 언어 적합성만으로도 Python 팀이 Playwright를 선택하는 경우는 정말 많습니다.
그리고 비교 글들이 자주 빼먹는 세 번째 답도 있습니다. 페이지가 실제로 JavaScript를 필요로 하지 않는다면 둘 다 고를 필요가 없습니다. HTTP 요청과 파서만으로 필요한 콘텐츠를 가져올 수 있다면, 헤드리스 브라우저는 비싼 과잉입니다. 그런 경우엔 HTTP 우선 도구를 쓰는 게 맞고, 브라우저 무게를 굳이 감당할 이유가 없습니다.
관리형 API가 들어갈 자리, Thunderbit 포함
웹 데이터 추출을 위해 Thunderbit 사용해 보기
Playwright와 Puppeteer는 둘 다 무료 오픈 소스 라이브러리이며, 직접 실행하고 유지보수해야 합니다. 브라우저 환경, 업데이트, 그 위에 얹는 크롤 코드, 그리고 봇 차단과의 끝없는 공방까지 모두 사용자가 책임져야 합니다. 많은 프로젝트에서는 그 방식이 정확히 맞습니다. 이 글은 그것에 반대하려는 게 아닙니다.
다만 실제 스크래핑 작업의 많은 부분이 이 도구 바깥에 있다는 점은 분명합니다. 이들은 페이지를 잘 렌더링하지만, URL 큐를 관리하지도 않고, 차단을 우회하지도 않으며, 구조화된 JSON을 바로 주지도 않고, 브라우저 팜도 직접 돌려야 합니다. 이건 직접 구축(build)과 구매(buy)를 고민하는 개발자에게 중요한 다른 층의 문제입니다. 저희 Thunderbit 개발자 스택은 바로 그 다른 층에 있습니다. POST /distill은 페이지를 깔끔하고 LLM 친화적인 Markdown으로 바꾸고, POST /extract는 사용자가 정의한 스키마에 맞는 구조화 JSON을 반환합니다. JavaScript 렌더링, 봇 차단 대응, CAPTCHA 처리는 노트북이 아니라 서버 측에서 처리됩니다. AI 에이전트와 코딩 보조 도구를 위한 Thunderbit MCP 서버도 있으며, 이 경우 thunderbit_suggest_fields는 비용을 쓰기 전에 무료로 실행됩니다. 또 CI와 cron용으로 npx @thunderbit/thunderbit-cli CLI도 제공합니다.
이게 무조건 더 낫다고 말할 생각은 없습니다. 형태가 다른 선택입니다. Playwright나 Puppeteer를 쓰면 렌더링과 그 주변 로직을 전부 직접 소유하는 대신, 요청당 비용은 없습니다. 관리형 API를 쓰면 렌더링, 봇 차단, 크롤링 인프라를 넘기고 요청당 비용을 지불합니다(Thunderbit의 경우 distill은 1크레딧, extract는 20크레딧이며, 행당 과금이 아닙니다). 소규모로 직접 호스팅하고 브라우저를 직접 관리하는 게 좋다면 이 라이브러리들이 맞습니다. 규모가 커지고, 헤드리스 브라우저 팜과 크롤러, 차단 회피 레이어까지 직접 운영하고 싶지 않다면 관리형 방식이 그 부담을 덜어줍니다.
더 넓은 비교로는, 저희 팀이 Crawlee의 두 엔진 접근 방식과 여러 HTTP 우선 프레임워크도 같은 테스트 대상에 돌려봤습니다. 풀 브라우저가 과한지 판단한 뒤 다음 단계로 보기 좋은 자료입니다.
결론
Playwright와 Puppeteer 중 무엇을 써야 할까요? JavaScript 페이지 렌더링 기준으로는 둘 중 아무거나 괜찮습니다. 여기서 중요한 테스트에서는 둘 다 비겼기 때문에, 다른 기준으로 골라도 기능을 잃는 건 아닙니다. Node에서 Chrome과 Firefox만으로 충분하고 성숙도와 집중도가 중요하다면 Puppeteer를 고르세요. WebKit 범위나 비-JavaScript 클라이언트가 필요하다면 Playwright를 고르세요.
비교 글들이 자주 빼먹는 두 가지를 꼭 기억해 두면 좋습니다. 첫째, 실제 스크래핑 작업에서는 이 둘이 사실상 무승부이므로, 8개 테스트에서 드러나지 않은 성능 차이에 너무 매달릴 필요가 없습니다. 둘째, 둘 다 크롤러는 아닙니다. 렌더링은 해주지만 크롤링은 사용자의 몫이거나 Crawlee 같은 래퍼의 몫입니다. 이 두 가지를 분명히 하고, 범위를 스택에 맞추면 선택은 훨씬 단순해집니다. 엔진 선택보다 더 중요한 건, 두 도구가 대신해주지 않는 작업의 절반입니다.
더 알아보기
웹 데이터 추출을 위해 Thunderbit 사용해 보기 Get Started Free
자주 묻는 질문
웹 스크래핑에서 Playwright와 Puppeteer 중 어느 쪽이 더 빠른가요?
동일한 테스트 대상에서는 사실상 무승부였습니다. 정적 페이지(12/12), 동적 페이지(8/8), JSON API 추출 모두 재현율이 같았고, 네이티브 렌더링과 500 처리도 동일했습니다. 이건 한 대의 머신에서 한 번씩 실행한 관찰일 뿐 벤치마크는 아닙니다. 그래서 페이지별 시간 차이를 실제 속도 측정으로 보기는 어렵습니다. 눈에 보이는 속도보다 범위와 언어 적합성으로 선택하세요.
Playwright와 Puppeteer의 실제 차이는 무엇인가요?
엔진 범위와 언어 범위입니다. Playwright는 하나의 API로 Chromium, Firefox, WebKit을 다루며 Python, Java, .NET 클라이언트를 제공합니다. Puppeteer는 CDP 기반의 Chrome 우선 도구이고, v23부터 WebDriver BiDi를 통한 Firefox 지원이 문서화돼 있지만 WebKit은 없고 Node 기반입니다. 둘 다 JavaScript를 네이티브로 렌더링하며, 둘 다 기본 내장 크롤 오케스트레이션은 없습니다.
Playwright나 Puppeteer만으로 사이트 전체를 크롤링할 수 있나요?
기본 제공 기능만으로는 어렵습니다. 둘 다 요청 큐, 데이터셋 기록기, 자동 속도 조절 기능이 없어서, 제 크롤 그래프 테스트에서도 두 경우 모두 직접 BFS를 작성해야 했습니다. 규모가 커지면 Crawlee 같은 크롤링 레이어를 추가하세요. 이 도구는 두 엔진 위에 실제 크롤링 기능을 얹어줍니다.
스크래핑에 브라우저 도구가 꼭 필요한가요?
페이지가 데이터를 드러내기 위해 JavaScript 실행을 필요로 할 때만 필요합니다. HTTP 요청과 파서만으로 원하는 콘텐츠를 얻을 수 있다면, 헤드리스 브라우저는 비싼 과잉입니다. 그런 경우엔 HTTP 우선 도구를 쓰고 브라우저 비용을 아예 없애세요.
Python 팀은 무엇을 선택해야 하나요?
Playwright입니다. 1급 Python 클라이언트가 있기 때문입니다. Puppeteer는 Node 기반이라 Python에서 쓰려면 별도 브리지를 만들어 유지보수해야 합니다. 언어 적합성만으로도 Playwright를 고를 가장 분명한 이유 중 하나입니다.
