나는 틀렸다: 2025년 Selenium vs Playwright

Source: Dev.to

2025년을 되돌아보고 2026년을 바라보면서, 배운 교훈을 나누고 싶습니다.

지난 한 해 동안 저는 Selenium으로 새로운 자동화 테스트를 만든 프로젝트가 단 하나도 없었습니다. 모든 대화는 SaaS 기반 도구를 사용하거나 Playwright로 구축하는 것에 관한 것이었습니다. 예전에는 들어오던 Selenium 프로젝트들은 이제 제가 조용히 유지보수하고 업데이트만 하고 있습니다. 원래 Selenium으로 만든 자동화 테스트 시스템을 말이죠.

누군가 오늘 저에게 “우리는 웹 테스트 자동화를 시작하려고 하는데, 자유롭게 선택할 수 있다면 어떤 테스트 도구나 프레임워크가 좋을까요?” 라고 물으면, 저는 Playwright가 더 나은 선택이라고 답할 것입니다.

1년 전이라면 “상관없어요. 다 똑같은 일을 하니까요.” 라고 말했겠지만, 지금 되돌아보니 그 말이 완전히 틀렸다는 것을 인정해야 합니다. 제가 잘못 판단한 것이었습니다.

새로운 도구를 제대로 탐색할 시간이 부족했기 때문에 치러야 하는 대가라고 생각합니다. 최근 AI 덕분에 Playwright를 다룰 기회가 더 많아졌고, 그래서 제 관찰 결과를 공유하고자 합니다.

왜 전환했을까?

Playwright로의 전환 뒤에는 테스트 자동화 환경의 변화가 있습니다.

• 과거에는 브라우저 간 차이를 감지하는 테스트 요청을 많이 받았습니다:
  “Chrome, Firefox, Edge, Internet Explorer에서 동일하게 동작하는지 확인해 주세요.”

• 이제는 이러한 요청이 드물어졌습니다.

가장 큰 영향은 Internet Explorer의 종료였습니다 (알다시피, 그건 오래전 일입니다!). IE는 자체 렌더링 엔진을 가지고 있었고, 다른 브라우저와의 호환성 문제가 끊임없었습니다. IE가 사라지면서 주요 브라우저는 다음과 같이 통합되었습니다:

• Chromium 기반 (Chrome, Edge)
• Firefox
• Safari

이는 크로스 브라우저 차이를 크게 줄였습니다. Selenium의 큰 강점은 여러 브라우저를 일관되게 제어할 수 있다는 것이었지만, 그 강점이 필요했던 상황은 감소했습니다.

테스트 자동화 분야에서 20년 이상 경험한 결과, Selenium에서 느꼈던 어려움들이 Playwright에 의해 해결되고 있음을 알게 되었습니다.

Selenium 세계

로케이터

// Typical locator strategy in Selenium
driver.findElement(By.id("submit-button"));
driver.findElement(By.cssSelector("#form > div.container > button.primary"));
driver.findElement(By.xpath("//div[@class='modal']//button[contains(text(), 'Submit')]"));

• 선택자 계층 구조를 생각해야 했습니다 – ID를 먼저, 그 다음 name, CSS, 마지막으로 XPath 순으로.
• DOM 구조가 바뀔 때마다 선택자를 업데이트해야 했습니다.
• 개발자가 클래스를 이름 바꾸어서 테스트가 깨지는 경우가 드물지 않았습니다.

대기 처리

// Explicit wait in Selenium
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement element = wait.until(
    ExpectedConditions.elementToBeClickable(By.id("submit-button"))
);

// The common “just wait” anti‑pattern
Thread.sleep(3000);  // Fixed 3‑second wait

• 적절한 대기 조건을 설정하기 어려워서 고정 대기로 되돌아가는 경우가 많았습니다.
• 결과:
  • 불필요하게 긴 실행 시간.
  • 일부 환경에서 불안정한 테스트.
  • 전체 실행 시간이 급증했습니다.

우리는 안정성과 속도 사이의 균형을 지속적으로 고민했습니다.

Playwright 세계

역할 기반 선택자

// Role‑based selectors in Playwright
await page.getByRole('button', { name: 'Submit' }).click();
await page.getByLabel('Email Address').fill('test@example.com');
await page.getByPlaceholder('Enter search keyword').fill('Playwright');

• 요소는 DOM 구조가 아니라 사용자가 인식하는 **역할(role)**과 이름(name) 으로 식별됩니다.
• 버튼의 이름이 “Submit”인 한, HTML이 변경되어도 테스트는 계속 동작합니다.
• 이는 접근성 원칙과 일치합니다; 화면 판독기(screen reader)도 동일한 역할과 ARIA 라벨을 사용합니다.
• AI 시대에서는 더욱 중요합니다: AI 기반 자동화(예: Playwright MCP)는 DOM에서 접근성 트리(ARIA 스냅샷) 로 전환하고 있습니다. 역할 기반 선택자에 익숙해지는 것은 미래에 대한 투자입니다.

자동 대기

// Wait handling is automatic in Playwright
await page.getByRole('button', { name: 'Submit' }).click(); // ← auto‑waits until clickable

• Playwright는 요소가 보이고, 활성화되며, 애니메이션이 끝날 때까지 자동으로 대기합니다.
• 고정된 대기 시간은 거의 필요하지 않습니다.
• 장점:
  • 테스트 실행 시간 감소.
  • 불안정한(flaky) 테스트 감소.
  • 유지 보수 비용 절감.

빠른 비교

* Playwright Test는 TypeScript/JavaScript에서만 사용할 수 있습니다. Java 버전은 JUnit과 같은 별도 프레임워크가 필요합니다.

최종 생각

브라우저 관리와 관련해서 Selenium은 장점이 있습니다. Selenium은 actual browsers installed on your PC를 실행하므로 사용자의 환경과 동일한 환경에서 테스트할 수 있습니다. 반면 Playwright는 자동으로 dedicated browser binaries를 다운로드하여 사용합니다.

Selenium에서 Playwright로

“설정은 더 쉽지만, 엄밀히 말하면 ‘사용자가 실제로 사용하는 정확한 브라우저’는 아니다.”

표에서 볼 수 있듯이 Selenium은 **“브라우저를 자동화하는 메커니즘”**이며, 테스트 관점에서는 별도의 테스트 프레임워크가 필요합니다. 이는 JUnit, TestNG, 대기‑처리 모범 사례, 리포팅 도구 등 다양한 주변 지식이 필요함을 의미했습니다.

반면 Playwright는 그 자체가 테스트 프레임워크입니다. 테스트 전용 기능이 풍부하게 포함되어 있으며, 설정만으로 스크린샷과 비디오를 캡처할 수 있다는 점이 정말 편리합니다.

Selenium은 웹‑브라우저 자동화의 선구자였던 훌륭한 도구입니다. 저는 오랫동안 Selenium에 의존해 왔습니다.

하지만 테스트 자동화 환경은 변하고 있습니다:

• 브라우저 간 차이가 감소하면서 크로스‑브라우저 테스트의 중요성이 상대적으로 낮아졌습니다.
• 역할 기반 셀렉터가 더 안정적인 테스트를 가능하게 합니다.
• 자동 대기가 플레이키한 테스트와 불필요한 대기 시간을 없애줍니다.
• 가장 중요한 점은, Playwright는 “브라우저 자동화 도구”가 아니라 “테스트 자동화 플랫폼”으로 설계되었다는 것입니다.

웹 테스트 자동화를 이제 막 시작하는 분들, 혹은 Selenium에서 마이그레이션을 고려하고 있는 분들에게 Playwright를 강력히 추천합니다.

이 글은 Playwright 시리즈 Part 1 입니다

원문은 Arrangility.com 에서 처음 공개되었습니다.