새벽 3시, 슬랙 알림이 울렸다. "크롤러 중단됨."
어제 밤 완벽하게 돌아가던 코드였다. 분명 테스트도 다 통과했다. 그런데 왜 또 멈췄을까?
모니터 앞에 앉아 에러 로그를 뒤적이며 속으로 되뇌었다.
"내가 뭘 잘못한 거지?"
이건 당신만의 경험이 아니다
수많은 개발자가 Selenium으로 자동화를 시작했다가 똑같은 좌절을 겪는다.
- 어제는 됐는데 오늘은 안 된다
- 로컬에선 되는데 서버에선 깨진다
time.sleep(3)을time.sleep(5)로 늘려봐도 소용없다
결국 코드가 문제가 아니라 "운"에 맡기는 자동화가 된다.
핵심을 놓치면 안 된다
이건 당신 실력 문제가 아니다.
잘못된 엔진을 쓰고 있기 때문이다.
자동차 엔진처럼, 브라우저 자동화 도구도 세대가 있다.
- Selenium = 1990년대 디젤 엔진. 튼튼하지만 느리고 까다롭다
- Puppeteer = 2010년대 하이브리드. 빠르지만 특정 조건에서만 작동
- Playwright = 2020년대 전기차. 조용하고 빠르며 거의 모든 환경에서 작동
Selenium은 왜 자꾸 깨지는가
Selenium은 브라우저와 HTTP로 통신한다.
코드 → 드라이버 → 브라우저
(HTTP 요청)
매 동작마다 "요청-응답" 사이클이 돈다. 느릴 수밖에 없다.
게다가 요소가 언제 나타날지 모르니 직접 Wait를 설정해야 한다.
# 이게 매번 필요하다
WebDriverWait(driver, 10).until(
EC.presence_of_element_located((By.ID, "button"))
)
Puppeteer가 바꾼 것
Google이 만든 Puppeteer는 브라우저를 직접 제어한다. (Chrome DevTools Protocol)
코드 → 브라우저
(직접 연결)
속도가 빠르고, 기본 대기 기능도 있다.
단점? 크롬 계열만 지원한다. Firefox나 Safari는 못 쓴다.
Playwright의 3가지 돌파구
Microsoft가 Puppeteer 개발진을 영입해서 만든 게 Playwright다.
1) 모든 브라우저 지원
- Chromium (Chrome, Edge)
- WebKit (Safari)
- Firefox
2) 강력한 자동 대기
// 이게 전부다
await page.click('#button');
// Playwright가 알아서 요소 나타날 때까지 기다린다
3) 격리된 컨텍스트
// 브라우저 하나로 수천 개 독립 세션 실행
const context = await browser.newContext();
메모리 효율이 미친 수준이다.
틀린 방식 vs 맞는 방식
❌ 운에 맡기는 코드
# Selenium
driver.get(url)
time.sleep(3) # 운에 맡긴다
button = driver.find_element(By.ID, "submit")
button.click()
time.sleep(2) # 또 운에 맡긴다
✅ 시스템이 알아서 하는 코드
// Playwright
await page.goto(url);
await page.click('#submit');
// 끝. 알아서 기다린다.
상황별 선택 기준
당장 Playwright로 갈아타라는 게 아니다.
상황에 맞는 엔진을 선택하라는 것이다.
| 상황 | 도구 |
|---|---|
| IE 지원 필수 | Selenium |
| 크롬만 쓰는 가벼운 작업 | Puppeteer |
| 신규 프로젝트 / 안정성 중요 | Playwright |
이 구조는 이전 글에서 설명했듯이, 도구의 특성을 이해해야 시스템이 안 깨진다.
엔진을 이해하면 새벽 3시 알림이 사라진다.
당신 코드는 멀쩡하다. 엔진만 바꾸면 된다.
이 구조를 실제 크롤링 수익 모델에 적용하는 방법은 AI 사업 실험실에 정리해 놓을 예정이다.
'기술-제품 분석' 카테고리의 다른 글
| AI 하나로 18억 달러 회사? - 매튜 갤러거 사례를 뜯어보면 진짜 보이는 것 (0) | 2026.04.03 |
|---|