대부분의 “playwright vs puppeteer” 글은 둘 중 하나가 반드시 더 좋은 scraper일 거라고 전제하고 시작한다. 그런데 그런 프레임부터 결과를 너무 앞질러 버린다. 나는 두 라이브러리를 똑같은 pages에서 직접 돌려 봤다. 정적인 목록 하나, JavaScript로 렌더링되는 목록 하나, 기사 하나, 깨진 500 응답 하나, 작은 crawl graph 하나, 그리고 공개 practice site 두 개까지. 결과는 거의 구분이 안 됐다. recall도 같고, rendering도 같고, screenshots도 같고, 빈 부분까지도 같았다.
그러니까 이건 승자를 올리는 이야기가 아니다. 실제로 browser automation tool이 web scraping을 할 수 있는지 가르는 작업들에서는 둘 중 어느 쪽도 상대를 앞서지 못했다. 여기서 말할 건 딱 세 가지다. 선택을 좌우할 만한 유일한 실질적 차이, 두 도구가 묵묵히 사용자가 직접 만들어야 한다고 남겨 둔 부분, 그리고 내가 테스트한 version gap에 대한 한 가지 메모다. 기준 시점은 2026-07-09다.
왜 이 비교가 공정한가
비교 글들에는 자주 보이는 나쁜 습관이 있다. 각 도구를 서로 다른 페이지에서 돌려 놓고는 승자를 발표하는 것이다. 그러면 그 결과는 도구보다 페이지에 대해 더 많은 걸 말해 준다. 나는 그걸 피하려고 Playwright와 Puppeteer를 같은 local fixture server와 같은 공개 demo인 Books to Scrape 그리고 Quotes to Scrape에 올려서 돌렸다. 그래야 숫자 하나하나가 줄 단위로 정확히 대응된다.
그래야만 “무승부”라는 말을 할 수 있다. fixture가 다르면 무승부는 그냥 잡음이다. 하지만 byte by byte로 같으면, 같은 결과는 도구 자체를 가리키는 신호가 된다.
각각이 실제로 무엇인지
Puppeteer는 Chrome DevTools Protocol을 통해 Chrome을 제어하는 JavaScript API다. 공식 설명도 거의 그대로다. “Chrome(실험적으로 Firefox도) 제어를 위한 JavaScript API”라는 뜻이다. 성숙했고, Chrome에 집중되어 있으며, Node 기반이다.
Playwright는 조금 다르게 포지셔닝된다. “Web Testing과 Automation을 위한 framework”로, 하나의 API로 Chromium, Firefox, WebKit을 다루고 JavaScript, Python, Java, .NET 공식 client를 제공한다. 두 도구는 DNA도 비슷하다. Playwright는 원래 Google의 Puppeteer 팀에서 출발했고, 이후 Microsoft로 넘어갔다. 그래서 경쟁자라기보다 사촌에 가깝다.
하지만 scraping에서는 둘 다 거의 같은 방식으로 움직인다. 실제 browser를 열고, page를 불러오고, script가 실행되게 둔 다음, rendered DOM을 읽는다. 그래서 HTTP parser 대신 둘 중 하나를 고르는 거다. JavaScript가 실행된 뒤의 page가 필요하지, 실행 전의 빈 껍데기가 필요한 게 아니니까. 아래의 모든 결과는 이 공통 메커니즘에서 나온다. 그렇기 때문에 결과도 그렇게 자주 무승부로 끝난다.
결과를 나란히 보면
바로 여기서 “하나는 분명 더 낫다”는 이야기가 조용히 무너진다. 같은 fixtures, 같은 숫자, 전부 같았다.
| Test | Playwright | Puppeteer |
|---|---|---|
| 정적 목록(12개 제품) | 12/12, recall 1.0 | 12/12, recall 1.0 |
| 기사(제목 + 3개 문단) | 3/3, boilerplate 분리 | 3/3, boilerplate 분리 |
| JS 동적 페이지(native render) | 8/8 + screenshot | 8/8 + screenshot |
| 동적 JSON API | 8/8, recall 1.0 | 8/8, recall 1.0 |
| HTTP 500 처리 | inspectable, throw 없음 | inspectable, throw 없음 |
| Crawl graph(수동 BFS) | 12 pages, depth {0,1,2} | 12 pages, depth {0,1,2} |
| Books to Scrape | 20개 제품 | 20개 제품 |
| Quotes JS(공개) | 10 quotes | 10 quotes |
둘 다 추가 설정 없이 JavaScript를 native하게 렌더링했다. 둘 다 full-page screenshot을 뽑았다. 둘 다 500 응답을 exception으로 터뜨리지 않고 inspectable response object로 돌려줬다. 사소해 보일 수 있지만, 대규모 scraping에서는 이게 꽤 중요하다. 나쁜 status 하나를 기록하면 될 일을, 예외 때문에 전체 실행이 무너지는 걸 막아 주기 때문이다.
하나 짚고 넘어갈 caveat가 있다. 이건 machine 하나에서 한 번 돌린 관찰이지, benchmark가 아니다. laptop에서 page마다 stopwatch를 재는 걸 진짜 speed test라고 부를 수는 없다. 내가 말할 수 있는 건 더 좁고 더 확실한 얘기다. 여덟 가지 서로 다른 page type에서 extraction recall과 rendering behavior는 같았다. 만약 실제 page에서 한쪽이 확 튀어나오길 기대했다면, 그런 일은 없었다.
선택을 가를 유일한 차이
진짜 갈림길은 숫자에 있지 않다. 범위에 있다.
Playwright는 하나의 API로 Chromium, Firefox, WebKit 세 engine을 다루고, JavaScript 외에도 Python, Java, .NET 공식 client를 제공한다. 이건 문서로 확인되는 장점이다. 그리고 나는 “문서로 확인된다”는 말을 정확하게 쓰고 싶다. 이번 pass에서는 Chromium만 테스트했기 때문에, Playwright의 세 engine 지원은 내가 따로 검증한 것이 아니라 문서에 명시된 기능으로 말하는 것이다. 만약 Safari의 WebKit에서 다르게 렌더링되는 site를 scraping해야 하거나, 팀이 Python으로 코드를 짜고 있다면, 이 폭넓은 지원은 Playwright 쪽 장점이 된다.
Puppeteer는 기본적으로 Chrome-first다. 그런데 여기서 흔히 하는 짧은 설명은 이제는 완전히 맞지 않는다. “Chrome만 된다”는 말은 더 이상 사실이 아니다. Puppeteer v23부터는 WebDriver BiDi를 통해 Firefox를 production-ready하게 지원하고 있고, Chrome 쪽은 기존 automation이 깨지지 않도록 계속 CDP를 쓴다. 이 변화는 Chrome for Developers와 Mozilla도 다뤘다. 내가 테스트한 버전은 24.16.0으로 v23보다 한참 뒤다. 그래서 실제 대비는 “Chrome 대 세 engine”이 아니다. Puppeteer는 Chrome(CDP)와 Firefox(BiDi)를 커버하지만 WebKit은 없고, cross-engine tool로서의 역사는 Playwright보다 더 늦게 시작됐다. Playwright가 갖고 있고 Puppeteer가 없는 engine은 WebKit이다.
이게 결정이다. 아주 단순하게 말하면 그렇다. 속도도 아니고, 정확도도 아니고, rendering fidelity도 아니다. 거기서는 무승부다. 결국 범위 문제다. WebKit 지원이 필요한가? JavaScript 말고 Python이나 .NET client가 필요한가? 아니면 Node에서 Chrome과 Firefox 정도면 충분한가? 대부분의 scraping job에서는 둘 다 기준선을 넘고, 선택은 기능보다 stack fit으로 정해진다.
둘 다 해주지 않는 것
두 도구 모두 같은 숙제를 사용자 쪽 책상 위에 남겨 둔다. 바로 crawl orchestration이다. 둘 다 built-in request queue, dataset writer, auto-throttling이 없다. 내가 crawl graph를 테스트할 때도 internal link를 따라가고, depth를 유지하고, 같은 URL을 다시 방문하지 않는 작업을 양쪽 모두 수동 breadth-first search로 처리해야 했다. 12 pages, depth {0,1,2}, 직접 만든 BFS. 둘 다 똑같았다.
몇 개 안 되는 page라면 이건 전혀 문제되지 않는다. 작은 BFS는 코드 12줄이면 된다. 하지만 수백 개, 수천 개 URL을 deduplication, retries, politeness delays까지 포함해서 크롤링하려면, 직접 그 machinery를 짜거나, 이런 engine을 감싸는 도구를 써야 한다. Crawlee가 바로 그런 역할을 한다. Playwright와 Puppeteer 위에 진짜 crawling layer를 얹어 준다.
이건 결함이 아니다. 이 점은 정확히 말해야 한다. Playwright와 Puppeteer는 browser automation framework이지 crawling framework가 아니다. queue가 없는 것은 bug가 아니라 scope의 한계다. 올바른 mental model은 이렇다. 이 도구들은 scraper의 절반, 즉 page를 “보는” 역할을 맡는다. 나머지 절반, 즉 site를 “걷는” 역할은 직접 만들거나 wrapper를 붙여야 한다.
설치와 version 메모
설치는 거의 비슷하다. npm install만 하면 library와 browser binary가 함께 들어오고, 무거운 쪽은 그 browser binary다. Puppeteer는 clean install 기준으로 자동으로 Chrome build를 내려받고, Playwright는 browser build를 위해 따로 npx playwright install을 사용한다. 둘 다 설치가 괴롭진 않지만, 다운로드 크기는 꼭 감안해야 한다. browser 무게와 per-page 비용이야말로 HTTP-only tool보다 rendering을 쓸 때 실제로 내는 세금이다.
이제 내가 빚진 얘기를 하자. 나는 Playwright 1.56.0을 latest release 1.61.1과 비교했고, Puppeteer 24.16.0을 npm latest 25.3.0과 비교했다. 즉, Puppeteer는 major version 하나 통째로 뒤처진 상태였다. 기준 시점은 2026-07-09다. 내가 쓴 API들은 그 간격 안에서 안정적이었기 때문에 결과는 유효하다. 하지만 이 글을 꽤 시간이 지난 뒤에 읽는다면, 정확한 숫자에 기대기 전에 현재 버전으로 다시 돌려 보는 게 맞다. 그리고 다시 한 번 말하면, Playwright는 Chromium만 테스트했기 때문에 Firefox나 WebKit의 동등성까지 내가 주장하는 건 아니다. 다만 그것들은 문서로 보장된 기능이다.
Playwright와 Puppeteer: 장단점
무승부라는 건, 장단점 목록이 어느 쪽이 이기는지보다 무엇에 묶이는지를 더 많이 보여 준다는 뜻이다.
Playwright
- 장점: 하나의 API로 Chromium, Firefox, WebKit 세 engine을 지원한다는 문서화된 점; Python, Java, .NET 공식 client; full recall의 native JS rendering; 계속 확장되는 기능.
- 단점: built-in crawl queue 없음; browser 무게와 per-page 비용; 이번 테스트에서는 Chromium만 사용; 실행한 버전이 latest release보다 뒤처짐.
Puppeteer
- 장점: CDP 위에서 성숙하고 안정적인 Chrome automation; full recall의 native JS rendering; 500을 깔끔하게 response object로 처리하고 throw하지 않음; 깊고 검증된 생태계; v23부터 WebDriver BiDi를 통한 Firefox 지원.
- 단점: Chrome-first이고 Node 기반이며 WebKit 없음; built-in crawl queue 없음; browser 무게 있음; 실행한 버전이 npm latest보다 major 하나 뒤처짐.
무엇을 고를까, 그리고 언제
Node에서 작업하고, 대상 site들이 Chrome에서 제대로 렌더링되며, 성숙하고 집중된 library와 덜 복잡한 축 하나를 원한다면 Puppeteer를 고르세요. 나중에 필요하면 Firefox도 BiDi로 붙일 수 있다.
WebKit 지원이 필요하거나, scraper를 Python이나 .NET으로 쓰고 싶거나, engine과 language 범위가 더 넓은 project에 투자하고 싶다면 Playwright를 고르세요. 특히 Python 팀이라면 이 language fit 하나만으로도 Playwright가 더 자연스러운 선택이 되는 경우가 많다.
그리고 비교 글들이 자주 빼먹는 세 번째 답도 있다. page가 데이터를 드러내는 데 JavaScript가 정말 필요하지 않다면 둘 중 아무 것도 고르지 마세요. HTTP request와 parser만으로 원하는 내용을 얻을 수 있다면, headless browser는 값비싼 overkill이다. 그건 다른 종류의 도구가 맡아야 할 일이고, 굳이 거기 browser를 가져다 놓는 건 메모리와 설정 시간만 태우는 일이다.
managed API, Thunderbit를 포함해 어디에 맞는가
Playwright와 Puppeteer는 둘 다 무료 open-source library다. 직접 돌리고 직접 관리해야 한다. browser environment, updates, 위에 얹을 crawl code, anti-bot arms race까지 전부 사용자가 책임진다. 많은 프로젝트에서는 이 소유 구조가 정확히 맞고, 여기에는 그것을 반대하는 말이 전혀 아니다.
하지만 실제 scraping 작업의 상당 부분이 이 도구 바깥에 있다는 점도 보자. page는 잘 렌더링하지만, URL queue를 돌리지도 않고, block을 관리하지도 않고, structured JSON을 바로 주지도 않으며, browser fleet을 사용자가 계속 살려 둬야 한다. 이건 managed extraction service와는 다른 stack level이다. build versus buy를 고민하는 개발자라면 이 차이를 분명히 알아두는 게 좋다. 우리의 Thunderbit developer stack은 바로 그 다른 레벨에 있다. POST /distill은 page를 깔끔한 LLM-ready Markdown으로 바꾸고, POST /extract는 사용자가 정의한 schema 위에 structured JSON을 돌려준다. JavaScript rendering, anti-bot handling, CAPTCHA는 로컬 laptop이 아니라 server side에서 다룬다. AI agent와 coding assistant를 위한 Thunderbit MCP server도 있고, thunderbit_suggest_fields는 돈을 쓰기 전에 무료로 실행된다. CI와 cron을 위한 CLI는 npx @thunderbit/thunderbit-cli로 쓸 수 있다.
이게 무조건 더 낫다고 말하진 않겠다. 그건 다른 형태의 trade-off다. Playwright나 Puppeteer를 쓰면 rendering과 그 주변을 직접 소유하고, call당 비용 없이 갈 수 있다. managed API를 쓰면 rendering, anti-bot, crawling plumbing을 내려놓는 대신 request마다 비용을 낸다. Thunderbit 기준으로는 call당 과금이다. distill 하나는 1 credit, extract 하나는 20 credits이고, 줄 수 기준이 아니다. 작은 self-hosted project이고 browser를 직접 제어하는 맛이 중요하다면 이런 library가 맞다. 반대로 스케일이 필요하고, headless fleet과 crawler, block rotation layer까지 직접 운영하고 싶지 않다면 managed solution이 그 일을 통째로 덜어 준다.
더 넓은 관점에서 보면, 우리 팀은 같은 fixtures 위에서 Crawlee의 two-engine approach와 몇 가지 HTTP-first framework도 시험해 봤다. 만약 full browser가 page에 비해 너무 무겁다고 판단했다면, 그다음으로 보기 좋은 선택지다.
결론
Playwright와 Puppeteer 중 무엇을 써야 할까? JavaScript가 있는 page rendering이라면 둘 다 충분하다. 여기서 중요한 test들에서는 완전히 비겼고, 따라서 다른 기준으로 골라도 기능을 잃지 않는다. Node에서 Chrome과 Firefox 중심으로 가고 싶고, 성숙하고 집중된 library가 좋다면 Puppeteer를 고르자. WebKit 범위나 JavaScript 외 language client가 필요하다면 Playwright를 고르자.
비교 글들이 자주 빼먹는 두 가지는 꼭 기억할 만하다. 첫째, 실제 scraping task에서는 둘이 사실상 무승부다. 여덟 개 서로 다른 test에서 보이지도 않은 performance gap 때문에 걱정할 필요는 없다. 둘째, 둘 다 crawler는 아니다. page를 렌더링할 뿐이고, crawling은 사용자 몫이거나 Crawlee 같은 wrapper의 몫이다. 이 둘의 역할을 정확히 놓고, scope를 stack과 맞추면 선택은 훨씬 단순해진다. engine 선택보다 더 중요한 건, 이 둘이 대신해 주지 않는 절반의 일을 어떻게 할지다.
더 알아보기
Thunderbit로 웹 데이터 추출을 시작하세요 Get Started Free
자주 묻는 질문
web scraping에서 Playwright와 Puppeteer 중 뭐가 더 빠른가요?
같은 fixtures에서는 사실상 무승부였다. static(12/12), dynamic(8/8), JSON-API extraction 모두 recall이 같았고, native rendering도 같았으며, 500 처리도 같았다. 이건 한 대의 기계에서 한 번 돌린 관찰이지 benchmark가 아니므로, page당 시간 차이를 진짜 속도 측정으로 볼 수는 없다. speed gap이 아니라 scope와 language를 기준으로 고르는 게 맞다.
Playwright와 Puppeteer의 진짜 차이는 무엇인가요?
engine과 language의 범위다. Playwright는 하나의 API로 Chromium, Firefox, WebKit을 다루고, Python, Java, .NET client를 제공한다. Puppeteer는 CDP를 쓰는 Chrome-first tool이고, v23부터 WebDriver BiDi로 Firefox도 지원하지만 WebKit은 없다. 그리고 Node 기반이다. 둘 다 JavaScript를 native하게 렌더링하지만, built-in crawl orchestration은 없다.
Playwright나 Puppeteer로 사이트 전체를 crawl할 수 있나요?
그 자체만으로는 어렵다. 둘 다 request queue, dataset writer, auto-throttling이 없다. 내 crawl-graph test도 양쪽 모두에서 수동 BFS가 필요했고, 12 pages를 depth {0,1,2}로 처리했다. 규모가 커지면 Crawlee 같은 crawling layer를 붙여야 진짜 crawling machinery가 된다.
scraping에 browser tool이 꼭 필요한가요?
page가 데이터를 드러내는 데 JavaScript가 필요한 경우에만 그렇다. HTTP request와 parser만으로 원하는 내용을 얻을 수 있다면, headless browser는 비싼 overkill이다. HTTP-first tool을 써서 browser 부담을 아예 피하는 게 좋다.
Python 팀은 무엇을 고르면 되나요?
Playwright가 낫다. first-class Python client가 있기 때문이다. Puppeteer는 Node 기반이라 Python에서 쓰려면 bridge를 따로 만들어야 하고, 그걸 또 유지해야 한다. 이런 language fit은 Puppeteer보다 Playwright를 고르는 가장 단순하고도 분명한 이유 중 하나다.
