서론
회사에서 운영하던 브라우저 스크래핑은 Selenium 기반이었다.
그러나 시간이 지날수록 예외 처리 로직이 복잡해지고, 페이지 로딩 대기 시간 때문에 속도가 경쟁사 대비 느려졌다.
특히 SPA 구조의 사이트에서 버튼 클릭 후 JS 로딩이 끝나지 않아 데이터 수집이 실패하는 경우가 잦았다.
이런 문제로 개발팀은 점점 피로해졌고, 나는 이전부터 주장해온 Playwright 전환을 본격적으로 제안할 기회를 잡았다.
본론
Playwright vs Selenium
| 항목 | WebDriver | CDP (Chrome DevTools Protocol) |
|---|---|---|
| 목적 | 크로스 브라우저 자동화 표준 | 크롬(및 크로미움 계열)의 디버깅/제어 |
| 프로토콜 | W3C WebDriver Protocol | Chrome DevTools Protocol |
| 통신 방식 | HTTP | WebSocket |
| 주요 사용 예 | Selenium | Playwright, Puppeteer |
| 대기 처리 | 수동 wait 필요 | 자동화 라이브러리에 따라 자동 대기 가능 |
| 브라우저 제어 깊이 | 상대적으로 얕음 | 매우 깊음 (네트워크, JS, 렌더링 등까지 접근 가능) |
Selenium은 W3C WebDriver 프로토콜(HTTP) 기반으로, 크로스 브라우저 호환성에 강점이 있다.
하지만 이벤트 감지와 DOM 변화 추적에서 한계가 있어, JS 기반 동적 로딩을 정확히 처리하지 못한다.
Playwright은 Chrome DevTools Protocol(WebSocket) 기반으로, 브라우저 네트워크·렌더링·JS 실행까지 깊게 제어 가능하다.
자동 대기(autowait) 기능 덕분에 불필요한 지연없이도 안정적으로 동작하며, 네트워크 요청·콘솔 로그·프레임 전환 등을 직접 감지할 수 있다
조직 설득 과정
나는 동일한 스크래핑 시나리오를 두 환경에서 구현해 성능을 비교했다.
결과적으로 특정 사이트에서 평균 30% 이상의 속도 개선과 예외처리 코드 40% 감소를 확인했다.
특히, Selenium에서는 클릭 후, 불필요한 대기시간을 넣어야 안정적이었던 동작이, Playwright에서는 자동 대기 덕분에 불필요해졌다.
이를 표와 로그 캡처로 정리해 공유했고, "더 빠르고, 더 단순하며, 유지보수하기 쉽다."는 메시지로 설득에 성공했다.
마이그레이션 전략
기존 코드는 함수형 구조로 뒤엉켜 있어, 사이트별 변경에 취약했다. 이를 레이어드 아키텍처로 재구성했다.
- 각 스크래핑 대상 사이트마다
Session클래스로 동작의 세부 구현을 정의 - 세션별 브라우저·쿠키·상태 관리 진행
SessionManager를 통해 세션들을 일괄 관리
이렇게 구조화하니 기능 추가·수정 시 영향 범위가 줄었고, 병렬 실행 시에도 상태 충돌을 방지할 수 있었다.
팀원들이 쉽게 참여하도록 가이드 문서와 코드 템플릿을 배포했다.
Playwright 도입 후 발견한 문제
도입 후 곧바로 한 가지 문제가 발생했다.
로그인 직후 곧바로 개인화 페이지에 접근하면 인증 실패가 발생했다.
이유는 Playwright이 내부적으로 세션·쿠키 정보를 Context에 완전히 반영하기 전에 다음 요청이 발생했기 때문이었다.
사람의 경우 로그인 버튼 클릭 → 페이지 로딩 확인 → 이동 순으로 자연스럽게 처리되지만, 코드에서는 “로그인 성공” 신호를 받자마자 곧바로 요청을 보내 문제가 생긴 것이다.
해결은 Context 저장 완료 시점까지 대기하는 로직을 넣어 브라우저 동작을 ‘사람처럼’ 흉내 내도록 했다.
동시에 페이지 내 이벤트를 비동기 병렬처리로 수행하는 코드들을 걷어냈다.
결론
결과적으로 전환에 성공했고 유지보수, 성능 측면에서 경쟁사 대비 큰 강점을 가지게 되었다.
조직 설득에는 "문제가 있다"는 지적보다 "문제를 해결할 구체적 방안"과 "측정된 근거"를 제시하는 것이 훨씬 효과적이다. 이번 Playwright 전환도 수치와 시연을 통해 가능성을 입증했기에 성공할 수 있었다.
하지만 Playwright도 만능은 아니다. 도입 후에도 새로운 문제가 나올 수 있고, 이를 사전에 예측하고 테스트하는 과정이 필수다. 기능 구현보다 안정적이고 재현 가능한 구조를 설계하고, 충분히 테스트하는 것이 장기적으로 훨씬 큰 가치를 만든다.
아쉬운 점은, 시점마다 명시적으로 대기하는 코드를 모두 제거하고 싶었지만 완전히 그러지 못했다는 것이다.
Playwright는 reliable end-to-end testing for modern web apps라는 문구처럼, 웹 환경에서 E2E 테스트를 빠르고 안정적으로 수행하기 위한 도구다.
그래서 본질적으로는 빠르게 테스트를 완료하는 것이 주 목적이다.
하지만 브라우저 자동화 작업을 하다 보면 단순히 빠른 동작뿐 아니라, 사람처럼 자연스럽게 동작하는 브라우저라는 목표도 종종 떠오른다.
마치 실제 사용자가 클릭하고 입력하는 것처럼 보이게 하려면 어떤 요소를 고려해야 할까? 단순 대기 코드나 하드코딩된 지연 시간 대신, 상황에 맞춘 자연스러운 타이밍과 반응을 구현하는 방법이 필요하다는 생각이 든다. :)
