문제: 간단한 질문 — 파이썬으로 크롤러를 직접 만들 수 있나?
짧게 답하자면: 예, 기본적인 사이트는 requests + BeautifulSoup로, 자바스크립트 렌더링이 필요하면 Selenium 또는 Playwright를 씁니다. 이 글은 제가 직접 만든 셋업(요구사항, 코드 예시, 장애 포인트)과 도구별 장단점 비교를 담아 빠르게 따라 할 수 있게 정리했습니다.
제가 만든 크롤러의 핵심 결론(한 문장)
정적 HTML이면 requests+BeautifulSoup, 동적 페이지는 Playwright(무거운 경우 Selenium), 대량 스케줄링·파싱 자동화는 Scrapy와 n8n/Redis 큐 조합이 현실적입니다.
실제 셋업·워크플로(제가 만든 구성)
프로젝트 목표: 뉴스 사이트에서 제목·요약·링크를 하루 3회 수집해 Airtable로 적재.
구성요소:
- 파이썬 3.11
- Playwright (브라우저 헤드리스 렌더링, JS 로딩 처리)
- BeautifulSoup (간단한 HTML 파싱 보조)
- Redis + RQ(작업 큐) — 스케줄링과 retry
- Airtable API로 결과 저장
- GitHub Actions로 하루 3회 트리거
간단한 이유: Playwright는 JS 처리와 안정성이 좋아 사이트 구조가 변해도 대응하기 쉬웠고, RQ는 구현이 간단해 초기 MVP에 적합했습니다.
핵심 코드 예시(Playwright + BeautifulSoup)
from playwright.sync_api import sync_playwright
from bs4 import BeautifulSoup
with sync_playwright() as p:
browser = p.chromium.launch(headless=True)
page = browser.new_page()
page.goto('https://example-news-site.com')
page.wait_for_load_state('networkidle')
html = page.content()
soup = BeautifulSoup(html, 'html.parser')
for item in soup.select('.article'):
title = item.select_one('.title').get_text(strip=True)
link = item.select_one('a')['href']
print(title, link)
browser.close()이 코드는 예시입니다. 실제 셀렉터는 대상 페이지 구조에 맞춰 수정하세요.
도구별 차이와 언제 어떤 걸 선택할지
다음 비교표는 제 경험과 실사용 기준으로 정리했습니다 — 비용·속도·설치 난이도를 고려하세요.
| 도구 | 장점 | 단점 | 추천 시나리오 |
|---|---|---|---|
| requests + BeautifulSoup | 가벼움, 설치 쉬움, 빠름 | JS 렌더링 처리 불가 | 정적 HTML, API 없는 가벼운 스크랩 |
| Playwright | JS 완전 렌더링, 안정성 높음 | 브라우저 리소스 사용, 초기 설치(브라우저 바이너리) | SPA, 동적 컨텐츠 크롤링 |
| Selenium | 오래된 생태계, 다양한 드라이버 지원 | 속도 느림, 설정 번거로움 | 레거시 환경, 브라우저 자동화가 필요한 경우 |
| Scrapy | 대규모 크롤링·파이프라인에 강함 | 학습 곡선, 초기 설정 필요 | 대량 페이지, 분산 크롤링 |
한 가지 구체적 예(가설적 사례)
가설: 특정 뉴스섹션 100개 페이지를 하루에 모으려면 Playwright로 렌더 후 제목 추출, Redis 큐로 병렬화해 평균 처리 시간은 페이지당 1.2초(환경에 따라 0.8~2.5초)였습니다. 실제 성능은 네트워크와 서버 차단에 따라 달라집니다.
제가 겪은 문제와 해결법(막힌 지점)
- IP 차단: 너무 빠른 요청은 429 발생 — 해결: 요청 간 delay, 프록시 풀 사용, 헤더에 정교한 User-Agent
- 동적 로딩 누락: some elements가 lazy-load 됨 — 해결: scroll/페이지 스크롤 시뮬레이션 또는 API 엔드포인트 직접 호출
- 환경 차이: 로컬에선 잘 돌아가는데 CI에서 브라우저 바이너리 누락 — 해결: GitHub Actions에 playwright install 명시
추천 대상별 선택 가이드
초보자: requests + BeautifulSoup으로 먼저 시도해보세요.
JS 렌더링 필요하면: Playwright를 권합니다. 안정성·속도 균형이 좋습니다.
대규모 스케줄링/분산이 필요하면: Scrapy + Redis + Celery(또는 RQ) 조합을 고려하세요.
자주 묻는 질문(FAQ)
Q1: Playwright와 Selenium 중 어느 쪽이 더 쉬운가요?
A: 초보자 관점에선 Playwright가 API가 더 직관적이고 설치·동작 안정성이 좋아 추천합니다. Selenium은 특정 드라이버 호환이 필요할 때 유용합니다.
Q2: 크롤링이 법적으로 문제가 될 수 있나요?
A: 사이트의 robots.txt와 서비스 약관을 확인하세요. 공개 데이터라도 과도한 요청은 문제가 될 수 있으니 책임 있게 사용해야 합니다. 법적 문제는 각자 확인 필요합니다.
비교 요약표(빠른 의사결정용)
| 목표 | 권장 도구 | 비고 |
|---|---|---|
| 간단한 스크랩 | requests + BeautifulSoup | 가장 빠름 |
| 동적 페이지 | Playwright | JS 렌더링 강함 |
| 대규모/분산 | Scrapy + Redis/Celery | 스케일링 용이 |
한 가지 흔한 실수
너무 빨리 대규모 병렬 요청을 띄우는 것 — 초기부터 프록시나 회피 전략을 적용하면 오히려 복잡도와 비용이 늘어납니다. 작은 규모로 먼저 안정성(에러 재시도, 백오프)을 확인한 뒤 확장하세요.
다음 행동(바로 따라 해볼 것)
- 대상 페이지를 열고 F12로 네트워크/렌더 방식을 확인한다 (xhr/스파 등).
- 아래 예제 코드를 로컬에서 실행해 보고, 셀렉터를 조정한다.
- 작동 확인되면 GitHub Actions로 스케줄링해 하루 1회 자동 실행하도록 설정한다.
참고 링크 및 내부 연결
내부 링크: Playwright 설치·사용기
외부 레퍼런스: Playwright 공식 문서 — https://playwright.dev/
마무리
이 글은 파이썬 웹 크롤러 직접 만든 개발기를 중심으로, 어떤 도구를 언제 선택해야 하는지와 제가 겪은 문제와 해결법을 담았습니다. 작은 목표로 시작해 도구를 단계별로 바꾸면 실패 확률이 줄어듭니다.
