Playwright·Selenium 선택: 속도보다 브라우저 범위

새 E2E 스위트를 만든다면 실행 속도보다 검증해야 할 브라우저를 먼저 정하는 편이 합리적이다. 그 범위를 Playwright가 충족하고 화면 변화에 맞춘 대기 코드가 부담이라면 Playwright가 유력하다. 실제 Safari에서 자동화된 회귀 검사를 해야 하거나 기존 Selenium Grid를 계속 활용해야 한다면 Selenium을 유지하거나 두 도구를 병행할 이유가 있다.

ScrollTest에 공개된 이식 사례에서는 같은 전자상거래 E2E 스위트의 200개 테스트가 Selenium 4.44.0 구성에서 47분, Playwright 1.59 구성에서 19분 걸렸고, 주간 플레이키 테스트 비율은 각각 8.3%와 1.4%였다. 작성자는 두 스위트가 같은 스테이징 환경을 대상으로 병렬 실행됐다고 설명한다. 한 스위트에서 관찰된 결과인 만큼 다른 팀의 실행 시간까지 예측하는 값으로 쓰기는 어렵다.

19분과 47분은 무엇을 비교했나

이 사례는 동일한 목적의 테스트를 다른 도구로 구현한 뒤 얻은 전체 실행 시간이다. 따라서 차이에는 도구 자체뿐 아니라 이식하면서 바뀐 테스트 코드, 대기 방식, 세션 구성, 병렬 실행 설정이 함께 반영됐을 수 있다. 공개된 글에는 실행 장비와 작업자 수, 반복 측정 횟수, 브라우저별 실행 내역이 충분히 제시돼 있지 않다. 속도 차이의 원인을 어느 한 기능에 배분할 근거도 없다.

플레이키 비율은 실행 시간과 별도로 읽어야 한다. 간헐적 실패에는 요소가 준비되기 전의 클릭뿐 아니라 공유 계정, 테스트 데이터 충돌, 외부 서비스 응답, 스테이징 환경의 상태도 관여할 수 있다. 이식 과정에서 인증 절차나 데이터 격리까지 고쳤다면 낮아진 실패율은 그 설계 변경의 효과도 포함한다. 숫자가 보여 주는 것은 해당 구성에서의 결과이지 도구를 교체할 때마다 재현되는 개선 폭이 아니다.

팀의 판단에는 한 번의 전체 실행 시간 외에 실패 조사 시간도 들어간다. 짧게 끝나는 스위트라도 같은 테스트를 자주 재실행해야 한다면 배포 판단은 늦어진다. 반대로 이미 병렬 실행이 잘 조정된 Selenium 스위트라면 이식에 드는 시간에 비해 절약할 실행 시간이 작을 수 있다. 비교 단위는 테스트 이름이 아니라 같은 사용자 흐름, 같은 검증 결과, 같은 브라우저 대상이어야 한다.

자동 대기가 줄여 주는 일과 남기는 일

Playwright의 클릭 전 동작 가능성 검사는 요소가 보이고, 위치가 안정됐으며, 이벤트를 받을 수 있고, 활성화됐는지를 확인한 뒤 클릭한다. 조건이 제한 시간 안에 충족되지 않으면 오류가 난다. 조건이 맞을 때까지 재시도하는 단언도 제공하므로, 화면이 바뀌는 시점을 테스트 작성자가 매번 고정된 지연 시간으로 맞출 필요가 줄어든다.

예를 들어 서버 응답을 기다리는 동안 버튼이 비활성화되고, 응답 뒤 다시 활성화되는 화면을 생각할 수 있다. Playwright는 클릭 시점의 기술적 준비 상태를 기다린다. Selenium에서도 명시적 대기 조건을 작성해 같은 상황을 처리할 수 있다. 차이는 대기를 어디에, 얼마나 반복해서 작성하고 유지해야 하는가에 있다.

기존 Selenium 코드에 고정된 지연 시간과 비슷한 대기 도우미가 곳곳에 흩어져 있다면 Playwright 이식으로 정리할 여지가 크다. 그러나 잘 설계된 Selenium 대기 코드가 이미 안정적으로 작동한다면 자동 대기만으로 큰 개선을 예상하기는 어렵다. 또 클릭할 수 있는 버튼과 결제가 실제로 완료된 상태는 다르다. 어느 도구를 쓰든 주문 번호나 저장된 값처럼 업무상 성공을 뜻하는 결과는 테스트가 명시적으로 확인해야 한다.

WebKit으로 검사할 것인가, 실제 Safari로 검사할 것인가

Playwright의 브라우저 안내는 Chromium, Firefox, WebKit과 설치된 Google Chrome·Microsoft Edge에서의 실행을 설명한다. 여기서 WebKit은 Safari와 관련된 엔진이지만 Playwright용 패치가 적용된 빌드다. Playwright는 브랜드 브라우저인 Safari 자체를 구동하지 않는다. 공식 안내는 Safari에 가까운 동작을 살피려면 macOS에서 WebKit을 실행하라고 권한다.

Selenium의 브라우저별 문서에는 Chrome, Edge, Firefox와 함께 Safari용 기능이 있다. 따라서 합격 기준이 실제 Safari 브라우저의 동작이라면 Selenium의 선택 가치가 높아진다. WebKit에서 통과한 테스트는 유용한 호환성 신호지만, 사용자가 설치해 쓰는 Safari에서 통과했다는 결과와 같은 뜻은 아니다.

반대로 제품 요구사항이 Safari 자체가 아니라 WebKit 계열 화면의 주요 흐름을 살피는 것이라면 Playwright의 범위가 충분할 수 있다. 특히 모든 브라우저에서 같은 회귀 검사를 빠르게 반복하려는 새 스위트라면 이 차이를 먼저 정의해야 도구를 과소평가하거나 과대평가하지 않는다. Chrome과 Edge는 Playwright에서도 브랜드 브라우저를 실행할 수 있으므로, 두 제품을 단순히 오픈소스 엔진 대 실제 브라우저로 나누는 것도 정확하지 않다.

모바일 화면 설정 역시 실제 기기 시험과 구분해야 한다. 브라우저에서 휴대전화 화면 크기와 입력 조건을 흉내 내면 반응형 배치와 일부 상호작용을 검증하는 데 도움이 된다. 그러나 특정 iPhone과 운영체제, 설치된 Safari에서만 나타나는 문제를 합격 기준으로 삼는다면 그 환경을 별도로 시험해야 한다. 브라우저 범위란 이름의 목록만이 아니라 결과를 인정할 실행 환경까지 포함한다.

Grid와 테스트 언어가 이전 비용을 바꾸는 이유

기존 Selenium Grid로 여러 원격 머신에 테스트를 분산해 왔다면 Grid는 이미 운영 중인 자산이다. 노드의 브라우저 조합, CI 작업 배분, 접근 권한, 결과 수집 방식이 그 자산에 연결돼 있을 수 있다. Playwright의 Grid 연결 안내는 Selenium Grid를 통한 Chrome·Edge 실행을 실험적 기능으로 분류하고, 향후 연동이 깨질 위험도 명시한다. 기존 Grid를 그대로 연결하면 이식 비용이 사라진다고 가정하기 어려운 이유다.

Grid를 쓰는 조직이라고 Playwright를 도입할 수 없는 것은 아니다. 다만 기존 노드가 어떤 브라우저를 제공하는지, 원격 세션을 어떻게 만들고 인증하는지, 실패 기록과 병렬 작업을 어디서 관리하는지에 따라 변경 범위가 달라진다. 특히 Safari 실행을 Grid에 묶어 운영한다면 Playwright와 Grid의 제한적인 연결 범위가 브라우저 요구와 맞지 않는다. 이 경우 Selenium의 해당 검사를 남기고 다른 흐름만 옮기는 방식도 선택지가 된다.

테스트 언어와 러너 역시 코드의 양만큼 중요하다. 현재 언어로 작성된 공용 도우미, 테스트 데이터 생성기, 보고서 처리, CI 스크립트를 재사용할 수 있는지에 따라 이전 범위가 달라진다. Playwright에서 팀이 쓰는 언어의 공식 지원 경로와 테스트 러너를 확인한 뒤, 기존 Selenium 코드의 어느 부분을 다시 작성해야 하는지 따져야 한다. 선택자만 바꾸면 끝나는 이전으로 예산을 잡으면 공용 기반 코드를 옮기는 시간이 빠진다.

요구 조건별 선택표

도구의 우열을 한 줄로 정하기보다 검증 대상과 기존 자산을 함께 놓으면 선택이 분명해진다. 아래 항목은 해당 조건에서 먼저 검토할 방향이다. 여러 조건이 동시에 중요하다면 하나의 도구로 모든 검사를 통일할 필요가 있는지도 판단 대상이다.

새 스위트, 지원되는 브라우저, 동적 화면: Playwright를 우선 검토할 만하다. 클릭 전 자동 대기와 재시도 단언은 화면 변화에 맞춘 대기 코드를 줄일 수 있다. 다만 실제 절약되는 시간은 팀의 화면과 테스트 설계에 달려 있다.
실제 Safari가 합격 기준: 해당 브라우저의 자동화된 회귀 검사는 Selenium을 우선 검토한다. Playwright의 WebKit 검사를 추가할 수는 있지만 두 실행 결과를 같은 브라우저의 결과로 합쳐 보고해서는 안 된다.
기존 Grid가 핵심 실행 환경: Selenium 스위트를 유지할 가치와 새 도구의 이익을 함께 계산한다. Playwright를 일부 흐름에 도입한다면 Grid 연동의 실험적 상태와 Chrome·Edge 범위가 현재 노드 구성에 맞는지 살펴야 한다.
기존 언어와 공용 코드의 재사용이 중요: 현재 테스트 언어의 지원 방식뿐 아니라 러너, 도우미, 보고서 처리의 이전 범위를 비교한다. 이 기반 코드가 크다면 새 스위트의 작성 편의보다 재작성 비용이 결정을 좌우할 수 있다.
실행 시간이 배포의 병목: 브라우저 요구를 충족하는 대표 흐름으로 두 구현의 전체 시간을 비교한다. 재시도 전 실패, 재시도 후 통과, 실행 자원 사용량까지 함께 봐야 빠른 실행이 운영상 이익으로 이어지는지 판단할 수 있다.

기존 Selenium 스위트는 어디까지 옮길 만한가

전면 이전의 가치는 가장 단순한 테스트 몇 개보다 실제 유지보수 부담을 만드는 흐름에서 드러난다. 로그인과 권한, 서버 응답에 따라 바뀌는 입력 화면, 결제나 저장의 완료 확인처럼 실패 원인을 자주 조사하는 구간이 비교 대상으로 적절하다. 외부 서비스 장애가 결과를 좌우하는 흐름만 고르면 도구의 차이가 가려질 수 있으므로, 테스트 데이터와 스테이징 상태도 함께 기록해야 한다.

두 구현의 브라우저 대상과 CI 자원을 맞춘 다음 실행 시간과 실패 원인을 비교하면 이식 성과를 읽기 쉽다. Playwright로 옮기면서 불필요한 단계나 공유 상태를 정리했다면 그것도 실제 이식의 이익이다. 다만 그 개선을 자동 대기 기능 하나의 효과로 계산해서는 안 된다. 반대로 Selenium 쪽의 고정 지연을 정리하는 것만으로 병목이 풀린다면 전체 스위트를 다시 쓰는 근거는 약해진다.

결국 이전 여부는 테스트가 통과해야 하는 브라우저에서 시작해, 실패를 다루는 노동과 기존 실행 자산의 교체 비용으로 좁혀진다. 브라우저 범위가 맞는 새 스위트에는 Playwright의 자동 대기가 설득력 있는 장점이다. 실제 Safari 검증이나 축적된 Grid 운영이 중요한 기존 스위트에는 Selenium을 남겨 두는 결정도 합리적이다. 두 요구가 공존한다면 검사 범위에 따라 도구를 나누는 편이 전면 교체보다 목적에 맞을 수 있다.

함께 읽기: