Selenium Playwright 비교

크롤러 (헤드리스, Selenium, 동적)

이전 글에서 BeautifulSoup로 정적 HTML을 파싱하는 흐름까지 다뤘다면, 이번 글은 그 다음 단계인 동적 페이지 크롤링이다. 현대 웹 페이지의 대다수가 자바스크립트로 콘텐츠를 사후 렌더링하기 때문에, requests로 받아 온 HTML에는 정작 사람이 보는 데이터가 빠져 있는 경우가 흔하다. 이 문제를 해결하는 표준 방법이 실제 브라우저를 띄워 자바스크립트를 실행한 뒤 결과 DOM을 읽는 브라우저 자동화이며, 대표 도구가 Selenium과 Playwright다. 본 글은 두 도구의 차이와 헤드리스 모드 활용을 정보처리기사 시험 범위 밖의 실전 입문 관점에서 정리한다(출처: Playwright 공식 문서). 제가 처음 학교 공지 사이트를 크롤링하면서 BS4로 빈 div만 받아 한참 헤맨 적이 있는데, 같은 페이지를 Playwright로 열자 그 빈 div에 콘텐츠가 그대로 차 있는 모습을 보고 "왜 두 도구가 다른 시대를 살고 있는지"를 손끝으로 받아들였다.

 

정적 HTML과 동적 페이지의 차이

전통적인 웹 페이지는 서버가 HTML을 완성된 형태로 보내 주는 정적 렌더링이었다. 이 시절에는 requests.get() 한 줄로 받은 응답에 사람이 보는 모든 데이터가 들어 있었고, BS4로 파싱하면 끝이었다. 그런데 React·Vue 같은 단일 페이지 애플리케이션(SPA, Single Page Application)이 보편화되면서 흐름이 바뀌었다. 여기서 SPA란 초기 빈 골격만 받은 뒤 브라우저에서 자바스크립트가 데이터를 비동기로 가져와 화면을 채우는 클라이언트 사이드 렌더링 방식을 가리킨다.

SPA를 BS4로 그대로 크롤링하면 사람이 보는 데이터가 비어 있는 빈 컨테이너만 받게 된다. 해결책은 두 가지다. 첫째, 그 자바스크립트가 호출하는 백엔드 API를 직접 찾아내 호출하는 방법(가벼움). 둘째, 실제 브라우저를 띄워 자바스크립트를 실행시킨 뒤 결과 DOM을 읽는 방법(무겁지만 거의 모든 사이트에 적용 가능). 첫 번째 방법은 가능하면 항상 우선시되어야 한다. API 호출은 HTML 파싱보다 5~10배 빠르고 깨질 위험도 적기 때문이다. 다만 인증·암호화·SSR 캐싱 같은 이유로 첫 번째 길이 막히는 경우가 흔하고, 그때 두 번째 길인 브라우저 자동화가 필요해진다.

여기서 헤드리스(headless) 모드란 브라우저를 화면에 띄우지 않고 메모리 안에서만 실행해 자동화 스크립트의 입력대로 페이지를 렌더링하는 모드를 가리킨다. 서버 환경에서도 동작할 수 있고 자원 사용량도 훨씬 적기 때문에, 운영 크롤러는 거의 예외 없이 헤드리스로 굴린다. 솔직히 제 경험상 처음에는 헤드 모드로 띄워 두고 페이지가 어떻게 흐르는지 눈으로 확인하다가, 안정화가 끝나면 헤드리스로 갈아 끼우는 흐름이 가장 안전했다.

Selenium과 Playwright, 두 도구의 차이

Selenium은 2004년부터 사용된 가장 오래된 브라우저 자동화 표준이다. WebDriver 프로토콜이라는 W3C 표준을 따르며, 모든 주요 브라우저(Chrome·Firefox·Edge·Safari)를 지원한다. 자료가 압도적으로 많고 회사·학교 환경에서 가장 널리 검증되어 있다는 점이 강점이다. 다만 비동기 처리·자동 대기·네트워크 가로채기 같은 현대적 기능이 다소 약하고, "요소를 못 찾았다(NoSuchElement)" 같은 시점 의존적 오류가 입문자를 자주 괴롭힌다.

Playwright는 2020년 마이크로소프트가 공개한 신세대 자동화 도구로, Selenium이 풀어내지 못한 자동 대기·네트워크 인터셉트·여러 컨텍스트 격리·모바일 에뮬레이션을 표준으로 제공한다(출처: Selenium 공식 문서). 여기서 자동 대기란 "요소가 화면에 나타날 때까지 알아서 기다린다"는 의미로, Selenium에서 흔히 쓰는 time.sleep() 또는 명시적 WebDriverWait 코드를 거의 없애 준다. 입문자가 가장 자주 막히는 지점이 바로 이 대기 처리이기 때문에, 학습 곡선만 놓고 보면 Playwright가 압도적으로 부드럽다.

두 도구의 최소 비교 예시는 다음과 같다. 같은 작업(검색창에 키워드 입력 후 결과 첫 줄 가져오기)을 두 도구로 짜 보면 차이가 한눈에 보인다.

# Selenium
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

driver = webdriver.Chrome()
driver.get("https://example.com")
box = WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.NAME, "q")))
box.send_keys("BeautifulSoup\n")
result = WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.CSS_SELECTOR, "h3"))).text
print(result); driver.quit()

# Playwright
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.goto("https://example.com")
    page.fill("input[name=q]", "BeautifulSoup")
    page.press("input[name=q]", "Enter")
    print(page.locator("h3").first.text_content())
    browser.close()

두 코드를 나란히 두면 Playwright 쪽이 명시적 대기 코드가 거의 사라진 모습이 가장 인상적이다. fill·press·locator 같은 메서드가 내부적으로 요소가 인터랙션 가능한 상태가 될 때까지 자동으로 기다려 주기 때문이다. 솔직히 이건 예상 밖이었는데, 제가 처음 같은 사이트를 두 도구로 동시에 짜 봤을 때 Playwright 쪽 코드 라인 수가 거의 절반이라는 사실보다, 그 절반의 코드가 단발 실행이 아니라 운영 환경에서도 안정적으로 도는 모습이 훨씬 강한 인상을 남겼다.

어떤 도구를 언제 쓸 것인가, 실전 가이드

선택의 기준은 단순하다. 신규 프로젝트라면 거의 모든 경우 Playwright가 우선이다. 자동 대기, 네트워크 인터셉트, 헤드리스 안정성, 그리고 브라우저별 컨텍스트 격리 기능이 운영에서 곧바로 가치를 만들어 낸다. 다만 사내 표준이 이미 Selenium으로 잡혀 있는 경우, 그리고 Selenium IDE 같은 GUI 도구로 테스트 케이스를 관리하는 조직에서는 Selenium을 그대로 유지하는 편이 사회적 비용 측면에서 합리적이다.

성능 측면에서는 Playwright가 평균 1.5~2배 빠르다는 벤치마크가 일반적이지만, 실제 차이는 사이트 특성과 네트워크에 더 크게 좌우되므로 단순 비교에 너무 의미를 두지 않는 편이 안전하다. 안정성 측면에서는 Playwright의 자동 대기와 트레이스 뷰어(Trace Viewer)가 디버깅 비용을 크게 낮춘다. 트레이스 뷰어란 자동화 스크립트가 실행하는 모든 동작을 타임라인으로 기록해 재생할 수 있게 만든 디버깅 도구로, 운영 환경에서 가끔만 깨지는 사고를 잡을 때 가장 위력적이다.

브라우저 자동화의 마지막 단계는 항상 봇 탐지 회피와 윤리적 운영이다. 봇 탐지란 사이트가 자동화 도구의 흔적(headless 표시·navigator.webdriver 속성·비정상적 마우스 패턴 등)을 감지해 차단하는 방어 기법을 의미한다. Playwright와 Selenium 모두 stealth 계열 플러그인이 있지만, 차단을 우회하기보다 사이트의 robots.txt와 이용약관을 먼저 확인하고, 가능하면 공식 API를 사용하는 흐름이 항상 첫 번째 선택지여야 한다. 제가 학교 프로젝트에서 처음 자동화 크롤러를 운영해 본 후 가장 자주 받은 사고가 "차단당했어요"였는데, 그때마다 결국 답은 우회가 아니라 요청 빈도를 줄이거나 공식 API로 갈아 끼우는 일이었고, 이 사실을 한 번 받아들이면 도구 선택의 절반은 자연스럽게 해결된다.

---

메타 디스크립션: 정적 HTML과 동적 페이지의 차이부터 Selenium과 Playwright의 자동 대기·네트워크 인터셉트 차이, 그리고 헤드리스 운영과 봇 탐지 회피의 실전 가이드까지 한 번에 정리합니다.