본문 바로가기
기술-제품 분석

새벽 3시, 또 멈춘 크롤러를 보며 든 생각

by H . Sol 2026. 4. 19.

새벽 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 사업 실험실에 정리해 놓을 예정이다.