“둘 다 브라우저 자동화인데 뭘 쓰지?” “Puppeteer와 Playwright”

들어가며

웹 자동화를 찾아보다 보면 거의 빠지지 않고 등장하는 이름이 있습니다.

바로 Puppeteer와 Playwright입니다.

둘 다 브라우저를 코드로 제어할 수 있게 해주는 도구라서 처음 보면 상당히 비슷해 보입니다.

페이지를 열고, 버튼을 클릭하고, 값을 입력하고, 화면을 캡처하는 것까지 둘 다 할 수 있습니다.

그래서 처음 접했을 때는 이런 생각이 들기 쉽습니다.

“결국 둘 다 똑같은 거 아닌가?”

실제로 간단한 자동화만 해보면 그렇게 느낄 수도 있습니다.

그런데 프로젝트가 조금 커지고 테스트 케이스가 많아지면 차이가 꽤 눈에 들어옵니다.

특히 지원 브라우저, 자동 대기, 테스트 기능, 병렬 실행, 디버깅 방식 등을 살펴보면 어떤 상황에서 Puppeteer를 쓰고 어떤 상황에서 Playwright를 쓰는지 조금씩 구분할 수 있습니다.

Puppeteer는 어떤 도구일까?

Puppeteer는 Google에서 개발한 Node.js 기반 브라우저 자동화 라이브러리로 많이 알려져 있습니다.

특히 Chrome과 Chromium을 자동으로 제어하는 용도로 오랫동안 사용되어 왔습니다.

예를 들어 웹페이지에 접속해서 제목을 가져오는 아주 간단한 코드는 이런 느낌입니다.

const puppeteer = require('puppeteer');

(async () => {
    const browser = await puppeteer.launch({
        headless: true
    });

    const page = await browser.newPage();

    await page.goto('https://example.com');

    console.log(await page.title());

    await browser.close();
})();

코드 흐름이 상당히 직관적입니다.

브라우저를 실행하고,

페이지를 하나 만든 다음,

URL에 접속하고,

필요한 작업을 한 뒤,

브라우저를 닫습니다.

이런 구조가 Puppeteer의 기본적인 사용 방식입니다.

Playwright는 무엇이 다를까?

Playwright 역시 브라우저 자동화를 위한 도구입니다.

Microsoft에서 개발한 오픈소스 브라우저 자동화 및 테스트 프레임워크로 알려져 있으며, Chromium뿐만 아니라 Firefox와 WebKit까지 지원하는 것이 대표적인 특징입니다.

예를 들어,

const { chromium } = require('playwright');

(async () => {
    const browser = await chromium.launch({
        headless: true
    });

    const page = await browser.newPage();

    await page.goto('https://example.com');

    console.log(await page.title());

    await browser.close();
})();

사용 방법만 보면 Puppeteer와 크게 다르지 않습니다.

그래서 처음에는 “이름만 다른 것인가?” 싶습니다.

하지만 실제로 테스트 자동화를 본격적으로 시작하면 Playwright가 제공하는 기능들이 눈에 들어오기 시작합니다.

가장 먼저 느껴지는 차이, 브라우저 지원

Puppeteer와 Playwright를 비교할 때 가장 먼저 확인할 부분 중 하나가 브라우저 지원입니다.

Puppeteer는 Chromium 계열 브라우저 자동화에 강점을 가지고 있습니다.

반면 Playwright는 Chromium, Firefox, WebKit을 지원합니다.

이 차이는 단순히 “브라우저가 하나 더 많다” 정도로 끝나지 않습니다.

웹사이트를 개발하다 보면 Chrome에서는 정상적으로 동작하는데 Safari 계열 브라우저에서 문제가 발생하는 경우가 있습니다.

특히 CSS나 JavaScript 동작 차이 때문에 특정 브라우저에서만 문제가 발생할 수도 있습니다.

이런 부분까지 자동으로 확인하고 싶다면 Playwright의 멀티 브라우저 지원이 상당히 편리합니다.

자동 대기 기능도 중요한 차이

웹 자동화에서 은근히 사람을 괴롭히는 것이 바로 대기 문제입니다.

페이지가 로딩되기 전에 버튼을 클릭하려고 하면 오류가 발생할 수 있습니다.

예전 방식으로 자동화를 작성하다 보면 이런 코드를 넣기도 합니다.

await new Promise(resolve => setTimeout(resolve, 2000));

await page.click('#login');

“2초 정도 기다리면 나오겠지”라는 방식입니다.

처음에는 작동합니다.

그런데 서버가 느려지면 2초가 부족할 수도 있고, 반대로 페이지가 0.5초 만에 로딩됐는데도 무조건 2초를 기다리게 됩니다.

결국 테스트가 불필요하게 느려집니다.

Playwright는 이런 문제를 줄이기 위해 요소의 상태를 확인하면서 필요한 시점까지 기다리는 기능을 적극적으로 활용합니다.

예를 들어,

await page.getByRole('button', {
    name: '로그인'
}).click();

처럼 작성하면 단순히 좌표를 기준으로 클릭하는 것이 아니라 페이지에서 원하는 요소를 찾고 상호작용할 수 있는 상태인지 확인하면서 작업할 수 있습니다.

이런 부분은 실제 E2E 테스트를 많이 작성할수록 체감이 큽니다.

Puppeteer도 자동 대기를 못 하는 것은 아니다

여기서 오해하면 안 되는 부분이 있습니다.

Playwright만 자동 대기를 지원하고 Puppeteer는 아무것도 지원하지 않는다는 뜻은 아닙니다.

Puppeteer 역시 특정 요소를 기다리거나 페이지 상태를 확인하는 여러 기능을 제공합니다.

다만 두 도구의 API와 자동화 철학이 다르기 때문에 코드를 작성하는 느낌에 차이가 있습니다.

결국 프로젝트에서 실제 테스트 코드를 몇 개 작성해보는 것이 가장 빠릅니다.

간단한 페이지 하나만 열어보면 차이를 잘 모르지만 로그인, 검색, 팝업, AJAX 요청, 동적 UI 등을 포함한 테스트를 작성하기 시작하면 차이가 점점 드러납니다.

E2E 테스트에서는 Playwright가 편한 경우가 많다

개인적으로 Puppeteer와 Playwright를 비교할 때 가장 큰 기준으로 보는 부분이 E2E 테스트입니다.

예를 들어 쇼핑몰을 만든다고 생각해보겠습니다.

사용자가 로그인한 뒤 상품을 검색하고 장바구니에 넣고 결제 페이지까지 이동하는 과정을 자동으로 테스트해야 합니다.

사람이 직접 하면 다음과 같습니다.

로그인
↓
상품 검색
↓
검색 결과 확인
↓
상품 선택
↓
장바구니 추가
↓
장바구니 이동
↓
결제 페이지 확인

이런 과정을 브라우저 자동화로 재현하는 것이 E2E 테스트의 대표적인 예입니다.

Playwright는 이런 테스트를 작성하고 관리하는 데 필요한 기능을 비교적 폭넓게 제공합니다.

테스트 실행, 브라우저별 테스트, 병렬 실행, 스크린샷, trace 등을 활용할 수 있기 때문에 웹 애플리케이션 테스트를 목적으로 한다면 상당히 편리합니다.

Puppeteer가 더 적합한 경우도 있다

그렇다고 Puppeteer가 뒤처지는 도구라고 생각하면 안 됩니다.

특정 프로젝트에서는 오히려 Puppeteer가 더 단순하고 편할 수 있습니다.

예를 들어 Chrome 또는 Chromium 환경만 대상으로 하고, 복잡한 테스트 프레임워크보다는 특정 자동화 작업을 간단하게 구현하고 싶은 경우입니다.

페이지를 열고 데이터를 확인하거나 PDF를 만들거나 스크린샷을 생성하는 등 브라우저를 하나의 자동화 도구로 사용하는 상황에서는 Puppeteer가 충분할 수 있습니다.

특히 기존 Node.js 프로젝트에서 Puppeteer를 이미 사용하고 있다면 단순히 “Playwright가 요즘 많이 쓰인다”는 이유만으로 무조건 교체할 필요는 없습니다.

현재 코드가 잘 동작하고 있고 유지보수에 문제가 없다면 그대로 사용하는 것도 충분히 좋은 선택입니다.

Puppeteer와 Playwright를 간단하게 비교하면

항목	Puppeteer	Playwright
브라우저 자동화	가능	가능
Chromium	지원	지원
Firefox	제한적/환경에 따라 다름	지원
WebKit	제한적/환경에 따라 다름	지원
E2E 테스트	가능	강점
스크린샷	가능	가능
PDF 생성	가능	가능
자동 대기	지원	강력한 자동 대기
멀티 브라우저 테스트	상대적으로 제한적	강점
Node.js 사용	가능	가능

다만 이런 표만 보고 선택하는 것은 추천하지 않습니다.

실제로 중요한 것은 내 프로젝트에서 어떤 테스트를 해야 하는가입니다.

어떤 것을 선택하면 좋을까?

간단하게 정리하면 다음과 같습니다.

Chrome 또는 Chromium 중심의 브라우저 자동화가 필요하다면 Puppeteer를 먼저 살펴볼 수 있습니다.

반대로,

웹사이트의 E2E 테스트를 체계적으로 구축하고 여러 브라우저에서 동작까지 확인해야 한다면 Playwright를 우선 검토하는 것이 좋습니다.

특히 새로운 프로젝트를 시작하면서 “앞으로 테스트를 계속 늘려갈 예정”이라면 Playwright의 테스트 관련 기능을 같이 살펴보는 것이 좋습니다.

반면 기존 프로젝트가 Puppeteer로 잘 구축되어 있다면 굳이 도구를 바꾸기보다 현재 구조를 유지하면서 필요한 기능을 추가하는 것이 더 현실적일 수 있습니다.

Headless Browser와도 연결된다

앞서 Headless Browser를 이야기했다면 Puppeteer와 Playwright의 관계도 자연스럽게 이해할 수 있습니다.

둘 다 브라우저를 사람이 직접 조작하지 않고 코드로 제어할 수 있습니다.

특히 서버 환경에서는 브라우저 창을 직접 띄울 필요가 없기 때문에 Headless 모드로 실행하는 경우가 많습니다.

즉,

Headless Browser = 화면 없이 브라우저를 실행하는 방식

Puppeteer / Playwright = 그 브라우저를 코드로 제어하는 대표적인 도구

정도로 연결해서 이해하면 편합니다.

결국 도구보다 중요한 것은 테스트 목적이다

Puppeteer와 Playwright를 비교하다 보면 어느 순간 “그래서 뭐가 더 좋은데?”라는 질문으로 넘어가게 됩니다.

그런데 개발하면서 느끼는 것은 무조건 더 좋은 도구가 있는 것은 아니라는 점입니다.

Chrome 자동화가 목적이라면 Puppeteer로 충분할 수 있습니다.

반대로 여러 브라우저를 대상으로 웹 애플리케이션의 사용자 시나리오를 반복적으로 테스트해야 한다면 Playwright가 더 편할 수 있습니다.

그리고 이미 운영 중인 프로젝트라면 팀에서 익숙하게 사용하는 도구인지, 기존 테스트 코드가 얼마나 쌓여 있는지도 상당히 중요합니다.

새로운 기술을 선택할 때 기능 목록만 보는 것보다 현재 프로젝트에서 어떤 작업을 반복해야 하는지부터 생각하는 것이 오히려 선택하기 쉽습니다.

Puppeteer와 Playwright 모두 결국 목적은 같습니다.

사람이 브라우저를 직접 열고 클릭하던 작업을 코드로 자동화하는 것입니다.

처음에는 버튼 하나 클릭하는 것부터 시작하지만, 테스트가 쌓이고 자동화 범위가 넓어지면 어느 순간 개발 과정에서 꽤 중요한 도구가 됩니다.

특히 웹사이트를 지속적으로 개발하고 있다면 “테스트는 나중에”라고 미루기보다 간단한 사용자 시나리오부터 자동화해보는 것도 좋은 방법입니다.