"Playwright vs Puppeteer" 류의 글은 보통 승자를 정해놓고 시작해요. 저는 그 전제를 의심해서, 두 라이브러리에 완전히 같은 페이지 세트를 돌려 직접 확인해봤어요. 정적 카탈로그, JS로 그려지는 카탈로그, 기사 페이지, 깨진 500 오류, 작은 크롤 그래프, 공개 연습 사이트 두 곳. 결과물은 구분이 안 될 정도로 겹쳤어요. 뽑아낸 항목 수, 렌더링 결과, 스크린샷, 부딪히는 한계까지 모두요.
그러니 이 글에서 승자는 안 나와요. 브라우저 자동화가 페이지를 제대로 긁는지 가르는 결정적 테스트에서 둘은 우열이 없었거든요. 대신 실제로 선택을 가르는 지점, 두 도구가 똑같이 손 놓고 있는 부분, 제가 비교한 버전 차이(기준일 2026-07-09)를 정리할게요.
왜 이 비교라면 믿을 만한가
흔한 비교 글의 함정은 도구마다 다른 페이지로 테스트한다는 거예요. 그러면 결과 차이가 도구 때문인지 페이지 때문인지 알 수 없어요. 그래서 Playwright와 Puppeteer 모두 같은 로컬 서버, 같은 공개 데모(Books to Scrape, Quotes to Scrape)로 돌려서 조건을 완전히 맞췄어요.
조건이 같아야 "무승부"라는 결론에 무게가 실려요. 애초에 다른 걸 비교했다면 무승부는 그냥 우연이지만, 완전히 동일한 조건에서 같은 결과가 나온다면 그건 도구 자체의 성격을 보여주는 신호예요.
두 라이브러리의 정체
Puppeteer는 Chrome DevTools Protocol 위에서 Chrome을 조종하는 JS API예요. 공식 문서 표현을 빌리면 Chrome과 실험적으로 Firefox까지 다루는 자바스크립트 API고요. 역사가 길고 Chrome에 뿌리를 두며 Node 위에서 돌아가요.
Playwright는 스스로를 웹 테스트·자동화 프레임워크로 정의해요. Chromium, Firefox, WebKit을 API 하나로 묶고, JS뿐 아니라 Python·Java·.NET 클라이언트를 정식으로 지원하죠. 사실 이 둘은 남남이 아니에요. Playwright 팀이 원래 Google에서 Puppeteer를 만들다 Microsoft로 넘어가 세운 프로젝트라서, 경쟁 관계라기보단 갈라져 나온 형제에 가까워요.
그런데 스크래핑에 실제로 써보면 동작은 사실상 같아요. 브라우저를 띄우고 → 페이지를 열고 → 스크립트가 다 돌 때까지 기다렸다가 → 완성된 DOM을 읽는 순서죠. 단순 HTTP 파서 대신 이 둘을 쓰는 이유는 딱 하나, JS 실행이 끝난 뒤의 페이지가 필요하기 때문이에요. 지금부터 나오는 얘기는 전부 이 공통 구조에서 갈라져 나온 것들이라, 겹치는 부분이 많을 수밖에 없어요.
결과표: 나란히 놓으니 똑같았다
"하나가 확실히 낫다"는 통념이 여기서 흔들려요. 대상도, 수치도, 결과도 전부 겹쳐요.
| 테스트 | 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개 인용문 |
설정을 따로 건드리지 않아도 둘 다 JS를 네이티브로 그려냈고, 전체 페이지 스크린샷도 똑같이 잘 찍었어요. 500 응답을 만나도 예외를 던지는 대신 나중에 살펴볼 수 있는 response 객체로 돌려준 것도 같았고요. 별거 아닌 듯해도 대량 스크래핑에서는 중요한 차이예요. 상태가 나쁜 페이지 하나 때문에 전체 배치가 죽으면 안 되니까요.
다만 짚어야 할 게 있어요. 이건 노트북 한 대에서 한 번 돌린 결과일 뿐, 벤치마크로 부르기엔 부족해요. "어느 쪽이 몇 밀리초 빠르다"를 말할 자료가 아니라는 뜻이에요. 제가 자신 있게 말할 수 있는 건 훨씬 좁은 범위예요. 여덟 가지 페이지 유형에서 추출 재현율과 렌더링 동작이 동일했다는 것. 큰 격차를 기대했다면 그런 격차는 없었어요.
진짜 갈림길: 범위의 차이
숫자로는 안 갈려요. 갈리는 건 커버 범위예요.
Playwright 쪽 강점은 Chromium·Firefox·WebKit을 API 하나로 다루고, JS 외에 Python·Java·.NET용 정식 클라이언트까지 있다는 거예요. 다만 정직하게 밝히자면, 이번 테스트에서는 Chromium만 실제로 돌려봤어요. 그래서 3엔진 지원은 제가 검증한 게 아니라 공식 문서에 적힌 스펙으로만 언급할게요. Safari 계열 WebKit에서 다르게 보이는 사이트를 다뤄야 하거나 팀이 Python 스택이라면 이 부분이 결정적일 수 있어요.
반대로 Puppeteer는 Chrome 중심이에요. 다만 "Chrome 전용"이라는 통념은 이제 틀렸어요. Puppeteer v23부터 WebDriver BiDi로 Firefox를 실제로 쓸 수 있는 수준까지 지원하기 시작했고, Chrome은 기존 방식 유지 차원에서 여전히 CDP를 씁니다. Chrome for Developers와 Mozilla 둘 다 이 내용을 공식 발표했어요. 제가 쓴 24.16.0은 v23을 한참 지난 버전이라, 정확히는 "Chrome 대 3엔진" 구도가 아니라 "Chrome(CDP)+Firefox(BiDi) 대 3엔진" 구도이고, 교차 엔진 지원 이력도 Playwright 쪽이 더 길어요. Puppeteer에 없고 Playwright에만 있는 엔진, 그게 WebKit이에요.
결국 관건은 속도나 정확도, 렌더링 품질이 아니에요. 그건 이미 비슷하다고 확인했으니까요. 관건은 "WebKit이 필요한가", "JS 말고 다른 언어 클라이언트가 필요한가", 혹은 "Node + Chrome + Firefox만으로 충분한가"예요. 웬만한 스크래핑 작업은 셋 중 마지막 조건만으로도 해결돼요. 그렇다면 남는 건 기능 격차가 아니라 우리 스택과의 궁합이에요.
둘 다 손 놓고 있는 부분: 크롤링
두 도구가 똑같이 사용자에게 떠넘기는 일이 있어요. 크롤 오케스트레이션이요. 요청 큐도, 결과 저장소도, 속도 자동 조절 기능도 기본으로는 없어요. 내부 링크를 따라가며 깊이를 세고 중복 방문을 막는 크롤 그래프 테스트를 직접 짜봤는데, Playwright든 Puppeteer든 BFS 로직을 손수 써야 했어요. 12페이지, 깊이 {0,1,2}까지 두 쪽 다 수작업이었죠.
몇 페이지 정도면 크게 문제 될 게 없어요. 열두 줄짜리 BFS면 끝나니까요. 문제는 URL이 수백, 수천 개로 늘어나서 중복 제거·재시도·요청 간격 조절까지 챙겨야 할 때예요. 그때는 직접 그 레이어를 짜거나 엔진 위에 얹는 도구를 써야 하는데, Crawlee가 정확히 그 자리를 채워줘요.
이건 결함이 아니라 원래 역할 구분이에요. Playwright와 Puppeteer는 크롤러가 아니라 브라우저 자동화 도구라서, 큐가 빠진 건 설계상 경계선이지 버그가 아니에요. 스크래퍼를 "페이지를 읽는 절반"과 "사이트를 도는 절반"으로 나눠보면, 이 도구들은 앞쪽만 맡고 뒤쪽은 사용자나 별도 래퍼의 몫으로 남아요.
설치와 버전 차이
설치 경험은 크게 다르지 않아요. npm install 한 번으로 라이브러리와 브라우저 바이너리가 같이 내려오고, 용량은 대부분 브라우저 쪽이에요. Puppeteer는 Chrome 다운로드가 자동으로 딸려오고(제 환경에서는 설치도 깔끔했고 취약점 경고도 없었어요), Playwright는 npx playwright install을 따로 실행해야 브라우저 빌드가 준비돼요. 설치 난이도보다 눈여겨볼 건 다운로드 시간이에요. HTTP 전용 도구와 달리 렌더링을 택한 순간 브라우저 용량과 페이지당 실행 비용은 피할 수 없어요.
버전도 밝혀둘게요. Playwright는 1.56.0으로, Puppeteer는 24.16.0으로 테스트했고, 이 글을 쓰는 시점 최신은 각각 1.61.1과 25.3.0이었어요(기준일 2026-07-09). Puppeteer 쪽이 메이저 버전 하나만큼 뒤처져 있었지만, 제가 쓴 API 범위에서는 그 간격이 결과에 영향을 주지 않았어요. 다만 이 글을 시간이 한참 지나 읽는다면 숫자를 그대로 믿지 말고 현재 버전으로 재확인하세요. 그리고 다시 강조하지만, Chromium 외 엔진에 대한 얘기는 제가 직접 확인한 게 아니라 문서 기준이에요.
장단점 요약
무승부라는 결론은 이 목록이 승패가 아니라 방향을 알려준다는 뜻이에요.
Playwright
- 장점: Chromium·Firefox·WebKit 세 엔진을 하나의 API로 공식 지원; JS 외 Python·Java·.NET 정식 클라이언트; 네이티브 JS 렌더링에서 재현율 100%; 지원 범위가 꾸준히 확장 중
- 단점: 크롤 큐 기본 내장 안 됨; 브라우저 용량과 페이지당 실행 비용 부담; 이번 테스트는 Chromium만 실제 검증; 테스트 버전이 최신보다 살짝 뒤처짐
Puppeteer
- 장점: CDP 기반의 검증된 Chrome 자동화; 네이티브 JS 렌더링에서 재현율 100%; 500 응답도 예외 없이 response 객체로 처리; 두텁고 오래된 생태계; v23부터 WebDriver BiDi로 Firefox 지원 문서화
- 단점: Chrome·Node 중심이라 WebKit 엔진 부재; 크롤 큐 기본 내장 안 됨; 브라우저 용량 부담; 테스트 버전이 npm 최신보다 메이저 버전 하나 뒤처짐
결국 뭘 골라야 하나
Node 스택이고, 대상 사이트가 Chrome에서 무난히 렌더링되며(대부분 그렇죠), 오래 검증된 집중형 라이브러리를 원한다면 Puppeteer가 맞아요. WebDriver BiDi로 Firefox까지 확장할 여지도 있고요.
WebKit까지 커버해야 하거나, Python·.NET으로 스크래퍼를 짜야 하거나, 더 넓은 엔진·언어 범위가 필요한 프로젝트라면 Playwright예요. 실제로 언어 궁합 하나 때문에 Playwright를 고르는 Python 팀이 정말 많아요.
비교 글들이 자주 빠뜨리는 세 번째 답도 있어요. 페이지에 애초에 JS가 필요 없다면 이 둘 중 아무것도 고를 필요가 없다는 거예요. 단순 HTTP 요청과 파서로 충분한 콘텐츠라면 헤드리스 브라우저는 과한 지출이에요. 그럴 땐 HTTP 우선 도구로 브라우저 무게를 통째로 빼버리세요.
관리형 API라는 세 번째 선택지, Thunderbit
웹 데이터 추출을 위해 Thunderbit 사용해 보기
Playwright와 Puppeteer는 무료 오픈소스라서 실행과 유지보수를 전부 스스로 떠안아야 해요. 브라우저 환경 관리, 업데이트, 그 위에 짤 크롤 코드, 봇 차단과의 끝없는 싸움까지요. 많은 프로젝트에는 이게 딱 맞는 방식이라, 이 글이 그 선택을 부정하려는 건 아니에요.
다만 실제 스크래핑 업무의 상당 부분은 이 라이브러리들 바깥에 있어요. 페이지 렌더링은 잘하지만 URL 큐 관리, 차단 우회, 구조화된 JSON 반환, 브라우저 팜 운영은 별개 과제로 남죠. build냐 buy냐를 고민하는 개발자에게는 이게 또 다른 층의 문제고, 저희 Thunderbit 개발자 스택은 바로 그 층을 겨냥해요. POST /distill은 페이지를 LLM 친화적 Markdown으로, POST /extract는 지정한 스키마대로 구조화 JSON을 돌려주고, JS 렌더링·봇 차단 대응·CAPTCHA 처리는 서버 쪽에서 알아서 처리돼요. 에이전트나 코딩 보조 도구를 위한 Thunderbit MCP 서버도 있어서 thunderbit_suggest_fields는 비용 없이 먼저 돌려볼 수 있고, CI·cron용으로 npx @thunderbit/thunderbit-cli CLI도 준비돼 있어요.
뭐가 무조건 낫다는 얘기는 아니에요. 그냥 성격이 다른 선택이에요. Playwright·Puppeteer는 렌더링과 주변 로직을 전부 손에 쥐는 대신 요청당 비용이 없고, 관리형 API는 렌더링·봇 차단·크롤링 인프라를 넘기는 대신 요청당 비용을 내요(Thunderbit는 distill 1크레딧, extract 20크레딧이고 행 단위 과금은 아니에요). 소규모로 브라우저까지 직접 다루고 싶다면 라이브러리 쪽이, 규모가 커져서 브라우저 팜·크롤러·차단 회피까지 직접 굴리고 싶지 않다면 관리형 쪽이 부담을 덜어줘요.
참고로 저희 팀은 Crawlee의 이중 엔진 방식과 여러 HTTP 우선 프레임워크도 같은 테스트로 돌려본 적이 있으니, 풀 브라우저가 꼭 필요한지 가늠할 때 같이 참고하세요.
정리
Playwright냐 Puppeteer냐. JS 렌더링만 보면 둘 다 괜찮아요. 결정적인 항목에서 무승부였으니 다른 기준으로 골라도 기능을 손해 보지 않아요. Node에 Chrome·Firefox만으로 충분하고 안정성이 중요하면 Puppeteer, WebKit이나 비-JS 언어가 필요하면 Playwright예요.
비교 글들이 잘 안 다루는 두 가지만 기억하세요. 하나, 실제 스크래핑 성능은 사실상 동률이라 여덟 개 테스트에 안 잡힌 미세한 속도 차이에 매달릴 이유가 없어요. 둘, 이 둘은 크롤러가 아니에요. 렌더링까지만 해주고 그다음은 직접 짜거나 Crawlee 같은 래퍼로 채워야 해요. 이 둘을 인정하고 스택에 맞춰 고르면 결정은 단순해져요. 엔진 선택보다 중요한 건 이 도구들이 대신해주지 않는 나머지 절반이에요.
더 알아보기
웹 데이터 추출을 위해 Thunderbit 사용해 보기 Get Started Free
자주 묻는 질문
Playwright와 Puppeteer, 스크래핑에서 어느 쪽이 더 빠른가요?
같은 조건에서는 사실상 동률이었어요. 정적 페이지(12/12), 동적 페이지(8/8), JSON API 모두 재현율이 똑같았고 렌더링과 500 처리 방식도 같았어요. 다만 한 대의 머신에서 한 번 돌린 결과라 밀리초 단위 속도 측정으로 쓰기엔 부적합해요. 속도보다 커버 범위와 언어 궁합으로 판단하세요.
둘의 실질적인 차이는 뭔가요?
엔진과 언어의 커버 범위예요. Playwright는 Chromium·Firefox·WebKit을 API 하나로, Python·Java·.NET 클라이언트까지 지원해요. Puppeteer는 CDP 기반 Chrome 중심이고, v23부터 WebDriver BiDi로 Firefox까지 문서화된 지원이 생겼지만 WebKit은 없고 Node 전용이에요. JS 네이티브 렌더링은 둘 다 되고, 크롤 오케스트레이션은 둘 다 없어요.
둘만으로 사이트 전체를 크롤링할 수 있나요?
기본 기능만으로는 부족해요. 요청 큐, 결과 저장소, 속도 조절이 둘 다 없어서 제 크롤 그래프 테스트에서도 BFS를 직접 짰어요. URL이 늘어나면 Crawlee 같은 크롤링 레이어를 얹으세요. 두 엔진 위에서 실제 크롤링을 대신해줍니다.
브라우저 자동화가 스크래핑에 항상 필요한가요?
아니요. 데이터가 JS 실행 없이도 보인다면 필요 없어요. 단순 HTTP 요청과 파서로 될 일이라면 헤드리스 브라우저는 불필요한 비용이니, 그때는 HTTP 우선 도구를 쓰세요.
Python 팀이라면 뭘 고르나요?
Playwright예요. 정식 Python 클라이언트가 있으니까요. Puppeteer는 Node 전용이라 Python에서 쓰려면 브리지를 직접 만들고 관리해야 해서, 언어 궁합만으로도 Playwright 쪽이 확실히 유리해요.
