"매일 3,000개 상품 가격을 수작업으로 확인하세요." — 이 말을 듣고도 멀쩡할 사람은 없습니다. 실제로 국내 이커머스 기업 상당수가 파이썬 크롤링 하나로 이 작업을 자동화하고 있고, 그 시작은 놀랍도록 간단합니다. 이 글에서는 웹 스크래핑의 기초부터, 실전에서 마주치는 진짜 문제들까지 — 실제 동작하는 코드와 함께 정리했습니다.
목차
- 웹 크롤링이란?
- 파이썬 크롤링 기본 — requests + BeautifulSoup
- 동적 페이지 크롤링 — Selenium과 Playwright
- 크롤링할 때 흔히 겪는 문제들
- 크롤링과 법적 이슈 — 꼭 알아야 할 것들
- 대규모 크롤링의 현실 — 유지보수 지옥
- 직접 만들기 vs 전문 서비스 — 언제 무엇을?
웹 크롤링이란?
웹 크롤링(Web Crawling) 은 프로그램이 웹 페이지를 자동으로 방문해 원하는 데이터를 추출하는 기술입니다. 웹 스크래핑(Web Scraping) 이라고도 부르며, 실무에서는 두 용어를 거의 같은 뜻으로 사용합니다.
[웹 크롤링 기본 흐름도: HTTP 요청 → HTML 수신 → 파싱 → 데이터 추출 → 저장](images/seo1-crawling-flow.png)
어디에 쓰일까요? 생각보다 범위가 넓습니다.
- 가격 모니터링 — 경쟁사 쇼핑몰 3,000개 상품 가격을 매일 자동 수집해 최저가 추적
- 시장 조사 — 네이버 쇼핑, 쿠팡 등에서 제품 정보·리뷰·평점 데이터를 한 번에 수집
- 리드 생성 — 잠재 고객 연락처, 기업 정보를 대량 수집해 영업에 활용
- 콘텐츠 모니터링 — 뉴스·SNS·커뮤니티에서 특정 키워드 실시간 추적
- 데이터 분석 — 부동산 시세, 채용 공고, 학술 데이터 등 대규모 데이터셋 구축
파이썬이 크롤링에 가장 많이 쓰이는 이유는 명확합니다. BeautifulSoup, Selenium, Playwright 같은 라이브러리가 풍부하고, 문법이 직관적이어서 프로토타입을 빠르게 만들 수 있기 때문입니다.
파이썬 크롤링 기본 — requests + BeautifulSoup
가장 기본적인 조합입니다. requests로 HTML을 가져오고, BeautifulSoup으로 원하는 데이터를 파싱합니다. 정적 HTML 페이지라면 이것만으로 충분합니다.
설치
pip install requests beautifulsoup4
기본 예제: 뉴스 제목 수집
import requests
from bs4 import BeautifulSoup
# 1. 웹 페이지 HTML 가져오기
# requests.get()으로 HTTP GET 요청을 보냅니다
url = "https://news.ycombinator.com/"
# 2. User-Agent 헤더 설정
# 헤더 없이 요청하면 봇으로 판단해 차단하는 사이트가 많습니다
# 실제 브라우저처럼 보이도록 User-Agent를 설정합니다
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
}
response = requests.get(url, headers=headers)
# response.raise_for_status() # HTTP 에러 시 예외 발생 (선택)
# 3. BeautifulSoup으로 HTML 파싱
# html.parser는 파이썬 내장 파서 — 별도 설치 불필요
soup = BeautifulSoup(response.text, "html.parser")
# 4. CSS 선택자로 원하는 요소 추출
# .titleline > a → class="titleline" 하위의 <a> 태그 (뉴스 제목 + 링크)
titles = soup.select(".titleline > a")
for i, title in enumerate(titles, 1):
print(f"{i}. {title.text}")
print(f" 링크: {title['href']}")
이 코드 20줄이면 Hacker News의 모든 제목과 링크를 수집할 수 있습니다. 파이썬 크롤링의 진입 장벽이 낮다고 하는 이유가 바로 이것입니다.
여러 페이지 크롤링 (페이지네이션)
실무에서는 한 페이지만 수집하는 경우가 드뭅니다. 여러 페이지를 순회하는 패턴을 알아두면 대부분의 리스트형 사이트에 적용할 수 있습니다.
import requests
from bs4 import BeautifulSoup
import time
# 페이지 번호를 URL에 넣는 패턴 — 대부분의 리스트 페이지가 이 구조
base_url = "https://example-blog.com/posts?page={}"
all_posts = []
for page in range(1, 11): # 1~10페이지 순회
response = requests.get(base_url.format(page), headers=headers)
soup = BeautifulSoup(response.text, "html.parser")
# 각 게시글 카드에서 제목, 날짜, URL 추출
posts = soup.select(".post-item")
for post in posts:
all_posts.append({
"title": post.select_one(".post-title").text.strip(),
"date": post.select_one(".post-date").text.strip(),
"url": post.select_one("a")["href"]
})
# 서버 부하 방지를 위한 요청 간격 설정
# 1초도 짧을 수 있음 — 대상 사이트 robots.txt의 Crawl-delay 확인 권장
time.sleep(1)
print(f"총 {len(all_posts)}개 포스트 수집 완료")
팁:
time.sleep()으로 요청 간격을 두는 건 웹 스크래핑의 기본 예의입니다. 너무 빠른 요청은 서버에 부하를 주고, IP 차단의 직접적인 원인이 됩니다. 일반적으로 1~3초 간격이면 안전합니다.
동적 페이지 크롤링 — Selenium과 Playwright
요즘 상당수의 웹사이트가 JavaScript로 콘텐츠를 렌더링합니다. React, Vue, Next.js 기반의 SPA(Single Page Application) 에서는 requests로 HTML을 가져와도 빈 <div id="root"></div>만 달랑 나옵니다 — 데이터가 JavaScript 실행 후에야 로드되기 때문입니다.
이럴 때 브라우저 자동화 도구가 필요합니다. 실제 브라우저를 띄워 JavaScript까지 실행한 뒤, 렌더링된 결과에서 데이터를 추출하는 방식입니다.
[정적 크롤링 vs 동적 크롤링 비교: requests는 서버 HTML만 수신, Selenium/Playwright는 JS 렌더링 후 DOM 접근](images/seo1-static-vs-dynamic.png)
Selenium 크롤링 예제
Selenium은 브라우저 자동화의 원조 격 도구로, 크롤링 관련 자료가 가장 풍부합니다.
pip install 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
# 1. 크롬 브라우저를 헤드리스(화면 없이) 모드로 실행
# 서버 환경에서는 화면이 없으므로 헤드리스 모드 필수
options = webdriver.ChromeOptions()
options.add_argument("--headless=new")
driver = webdriver.Chrome(options=options)
try:
# 2. 대상 페이지 접속
driver.get("https://example-spa.com/products")
# 3. JavaScript 렌더링이 끝날 때까지 최대 10초 대기
# WebDriverWait는 요소가 나타나면 즉시 다음 단계로 진행
# 10초 안에 안 나타나면 TimeoutException 발생
WebDriverWait(driver, 10).until(
EC.presence_of_all_elements_located((By.CSS_SELECTOR, ".product-card"))
)
# 4. 렌더링된 DOM에서 데이터 추출
products = driver.find_elements(By.CSS_SELECTOR, ".product-card")
for product in products:
name = product.find_element(By.CSS_SELECTOR, ".product-name").text
price = product.find_element(By.CSS_SELECTOR, ".product-price").text
print(f"{name}: {price}")
finally:
# 5. 브라우저 종료 — 안 닫으면 메모리 누수 발생
driver.quit()
Playwright 크롤링 예제 (2026년 추천)
Playwright는 Microsoft가 만든 차세대 브라우저 자동화 라이브러리입니다. Selenium보다 빠르고 안정적이며, 자동 대기(auto-wait) 기능이 내장되어 있어 WebDriverWait 같은 보일러플레이트 코드가 필요 없습니다. 2026년 기준으로 새 프로젝트라면 Playwright를 추천합니다.
pip install playwright
playwright install chromium # 브라우저 바이너리 자동 다운로드
from playwright.sync_api import sync_playwright
# Playwright는 컨텍스트 매니저로 리소스를 자동 관리
with sync_playwright() as p:
# 1. Chromium 브라우저를 헤드리스 모드로 실행
browser = p.chromium.launch(headless=True)
page = browser.new_page()
# 2. 대상 페이지 접속
page.goto("https://example-spa.com/products")
# 3. Playwright는 자동으로 요소가 나타날 때까지 대기
# 별도의 WebDriverWait 코드가 필요 없음 — 훨씬 깔끔합니다
cards = page.locator(".product-card").all()
for card in cards:
name = card.locator(".product-name").text_content()
price = card.locator(".product-price").text_content()
print(f"{name}: {price}")
# 4. 브라우저 종료
browser.close()
Selenium vs Playwright — 어떤 걸 쓸까?
[Selenium vs Playwright 비교 인포그래픽](images/seo1-selenium-vs-playwright.png)
| 비교 항목 | Selenium | Playwright |
|---|---|---|
| 속도 | 보통 | Selenium보다 빠르다는 평가가 일반적 |
| 자동 대기 | 수동 설정 필요 | 내장 |
| 브라우저 지원 | Chrome, Firefox, Edge, Safari | Chromium, Firefox, WebKit |
| 네트워크 인터셉트 | 제한적 | 기본 제공 |
| 학습 자료 | 매우 풍부 (10년+ 역사) | 빠르게 증가 중 |
| 추천 상황 | 레거시 프로젝트, 간단한 자동화 | 신규 프로젝트, 대규모 크롤링 |
크롤링할 때 흔히 겪는 문제들
여기까지 읽으면 "크롤링 별거 아니네?" 싶을 수 있습니다. 하지만 실전에서 파이썬 크롤링을 해보면 코드 작성보다 훨씬 까다로운 문제들이 기다리고 있습니다. 처음 크롤러를 만들어 본 개발자 대부분이 겪는 문제 5가지를 정리했습니다.
1. IP 차단
같은 IP에서 반복 요청이 들어오면 대부분의 사이트가 차단합니다. 대응 방법은 프록시 로테이션과 요청 간격 조절인데, 문제는 비용입니다. 품질 좋은 레지덴셜 프록시는 업체별로 GB당 5~15달러, 월 기본 요금만 50~500달러 수준입니다. 프록시 품질 모니터링, 차단된 IP 교체 등 관리 공수까지 더하면 결코 가벼운 비용이 아닙니다.
2. 캡차(CAPTCHA)와 봇 탐지
Cloudflare, PerimeterX, Akamai Bot Manager, DataDome — 봇 방지 솔루션이 해마다 정교해지고 있습니다. reCAPTCHA v3는 마우스 움직임, 스크롤 패턴, 키 입력 속도까지 분석합니다. CAPTCHA 풀이 서비스(2Captcha 등)를 쓰면 건당 1~5원(유형에 따라 다름) 수준이지만, 하루 10만 건이면 월 600만 원 이상이 됩니다. 비용뿐 아니라 속도와 성공률 관리도 만만치 않습니다.
3. 동적 렌더링과 무한 스크롤
JavaScript 렌더링이 필요한 사이트가 계속 늘고 있습니다. 브라우저 인스턴스를 띄워야 하니 페이지당 메모리 300~500MB를 잡아먹고, 정적 크롤링 대비 속도가 5~10배 느립니다. 동시에 50개 브라우저를 돌리려면 최소 16GB RAM 서버가 필요하고, 클라우드 기준 월 15~30만 원 수준의 인프라 비용이 발생합니다.
4. 사이트 구조 변경
크롤링 대상 사이트가 디자인을 바꾸거나 HTML 구조를 변경하면 크롤러가 즉시 깨집니다. 활발한 사이트는 2~3개월에 한 번 꼴로 구조가 바뀝니다. 변경 감지 → 코드 수정 → 테스트 → 배포 사이클을 상시 유지해야 하고, 대상 사이트가 20개라면 연간 80~120번의 유지보수가 필요한 셈입니다.
5. 데이터 정제
수집한 데이터가 깨끗할 거라는 기대는 금물입니다. 사이트마다 인코딩(UTF-8, EUC-KR)이 다르고, 날짜 형식(2026.01.30 vs 2026-01-30 vs Jan 30, 2026)이 다르며, 같은 정보를 전혀 다른 방식으로 표현합니다. 경험상 데이터 클리닝 작업이 수집 자체 시간의 30~50% 를 추가로 잡아먹습니다.
크롤링과 법적 이슈 — 꼭 알아야 할 것들
크롤링은 기술적으로 쉬워도 법적으로는 회색 영역이 넓습니다. "긁을 수 있다"와 "긁어도 된다"는 완전히 다른 문제입니다. 비즈니스 목적의 크롤링이라면 다음 세 가지를 반드시 확인하세요.
robots.txt — 크롤링의 기본 규약
robots.txt는 사이트 소유자가 "이 경로는 수집하지 말아주세요"라고 명시하는 파일입니다. 법적 구속력이 있느냐에 대해서는 논란이 있지만, 사실상 업계 표준으로 통합니다. 이를 무시한 크롤링은 소송 시 불리하게 작용할 수 있습니다.
# 예시: https://example.com/robots.txt
User-agent: *
Disallow: /private/
Disallow: /api/
Crawl-delay: 2 # 요청 간격 2초 이상 유지 요청
확인 방법은 간단합니다. 대상 URL 뒤에 /robots.txt를 붙이면 됩니다 (예: https://naver.com/robots.txt). Disallow로 명시된 경로는 수집 대상에서 제외하고, Crawl-delay가 있다면 해당 간격을 준수해야 합니다.
개인정보보호법 — 가장 주의해야 할 영역
한국의 개인정보보호법은 개인정보 수집 시 정보주체의 동의를 원칙으로 합니다. 크롤링으로 수집한 데이터에 이름, 전화번호, 이메일 등 개인을 식별할 수 있는 정보가 포함되어 있다면, 그 데이터를 저장하거나 활용하는 것 자체가 위법이 될 수 있습니다.
실무에서 주의할 점:
- 공개된 웹 페이지라 해도 개인정보는 동의 없이 수집·활용 불가
- 특히 연락처, SNS 프로필, 사용자 리뷰(닉네임 포함)는 주의
- EU 대상 서비스라면 GDPR 적용 — 위반 시 전 세계 매출의 최대 4% 과징금
- 한국에서도 개인정보보호위원회의 제재가 점점 강화되는 추세
현실적 조언: 가격, 상품 스펙, 시장 데이터 등 비개인정보만 수집하는 것이 가장 안전합니다. 개인정보가 포함된 데이터가 필요하다면, 반드시 법적 검토를 먼저 받으세요.
저작권법 — 데이터 자체의 권리
웹 페이지에 게시된 텍스트, 이미지, 영상 등은 대부분 저작권의 보호를 받습니다. 크롤링으로 데이터를 수집하는 것 자체는 기술적 행위지만, 수집한 콘텐츠를 그대로 재게시하거나 상업적으로 활용하면 저작권 침해에 해당할 수 있습니다.
판례와 기준:
- 사실 정보(가격, 수치 데이터) 는 저작권 보호 대상이 아닌 것이 일반적
- 창작물(기사, 리뷰, 이미지) 은 저작권의 보호를 받음
- 데이터베이스 자체를 통째로 복제하면 부정경쟁방지법 위반 가능
- 미국의 hiQ Labs v. LinkedIn 판례(2022)에서는 공개 프로필 스크래핑에 대해 CFAA 위반이 아니라는 판결이 나왔으나, 이후 LinkedIn은 이용약관 위반을 근거로 별도 소송을 진행했고 최종적으로 합의로 종결되었습니다. 공개 데이터라도 이용약관·계약법 차원의 제한이 있을 수 있으므로, 각국 법률과 대상 사이트의 ToS를 반드시 확인해야 합니다
[크롤링 법적 체크리스트: robots.txt 확인 → 개인정보 포함 여부 → 저작권 침해 가능성 → 이용약관 검토](images/seo1-legal-checklist.png)
정리하면: 크롤링을 시작하기 전에 ① robots.txt 확인, ② 개인정보 포함 여부, ③ 수집 데이터의 활용 범위, ④ 대상 사이트의 이용약관 — 이 네 가지를 반드시 점검하세요. 확신이 없다면 법률 자문을 받는 것이 비용 대비 가장 안전한 투자입니다.
대규모 크롤링의 현실 — 유지보수 지옥
소규모 프로젝트에서는 파이썬 스크립트 하나면 충분합니다. 하지만 비즈니스에서 크롤링을 지속적으로 운영해야 한다면 상황이 완전히 달라집니다.
대규모 웹 스크래핑 시스템을 운영하려면 이런 것들이 필요합니다:
- 인프라 — 서버, 스케줄러(Airflow, Celery 등), 큐 시스템, 데이터베이스
- 프록시 관리 — 수백~수천 개 프록시 구매·로테이션·품질 모니터링 (월 50~500달러)
- 에러 핸들링 — 재시도 로직, 장애 알림, 자동 복구
- 데이터 파이프라인 — 수집 → 정제 → 적재 → 검증 자동화
- 모니터링 — 크롤러 상태, 수집 데이터 품질, 대상 사이트 변경 감지
- 법적 준수 — robots.txt, 개인정보보호법, 저작권법 지속적 검토
[대규모 크롤링 아키텍처: 스케줄러 → 크롤러 풀 → 프록시 로테이션 → 데이터 파이프라인 → 저장소](images/seo1-large-scale-architecture.png)
더 복잡한 프로젝트에는 Scrapy 같은 프레임워크도 고려해볼 수 있지만, 어떤 도구를 쓰든 운영 복잡도는 줄지 않습니다.
현실적인 비용을 따져보면 — 개발자 1명이 크롤러를 만드는 데 약 2주(인건비 300~400만 원)가 걸리고, 이후 유지보수에 매달 40~60시간(인건비 200~300만 원)이 소요됩니다. 크롤링 대상이 10개, 20개로 늘어나면 크롤링 인프라 관리 자체가 풀타임 업무가 됩니다. 여기에 프록시, 서버, CAPTCHA 풀이 비용까지 더하면 월 500만 원 이상이 크롤링에만 들어가는 경우도 드물지 않습니다.
"크롤러 만드는 건 쉽다. 안 죽게 유지하는 게 진짜 일이다."
— 크롤링 시스템을 운영해 본 개발자라면 누구나 공감할 이야기
직접 만들기 vs 전문 서비스 — 언제 무엇을?
| 상황 | 추천 방법 |
|---|---|
| 학습 목적, 일회성 수집 | requests + BeautifulSoup |
| 동적 사이트, 소규모 프로젝트 | Playwright 또는 Selenium |
| 비즈니스 운영, 다수 사이트, 안정성 필수 | 전문 크롤링 서비스 |
파이썬 크롤링을 배우는 건 개발자로서 확실히 가치 있는 투자입니다. 간단한 데이터 수집이나 프로토타입에는 이 글에서 다룬 도구들만으로 충분하고요.
다만 크롤링이 비즈니스의 핵심 데이터 파이프라인이 되는 순간, 직접 만들고 유지하는 비용(월 500만 원+)과 전문 서비스 비용을 냉정하게 비교해볼 필요가 있습니다. 개발 리소스는 데이터를 수집하는 일이 아니라 활용하는 일에 집중하는 게 훨씬 효율적이니까요.
전문 서비스를 검토한다면, 크롤러 개발부터 유지보수까지 통째로 맡기고 정제된 데이터만 받아 쓰는 방식이 있습니다. 국내에서는 해시스크래퍼(HashScraper) 같은 B2B 크롤링 서비스가 이런 구조로 운영되고 있어, 인프라 구축 없이 바로 데이터 수집을 시작할 수 있습니다.
지금 바로 시작해보세요:
- 위 코드 예제를 복사해서 실행해보세요 — 5분이면 첫 크롤링 결과를 볼 수 있습니다
- 대규모 수집이 필요하다면, 직접 구축할지 외부 서비스를 쓸지 비용 비교부터 해보세요
크롤링 관련 궁금한 점이 있다면 댓글로 남겨주세요. 경험에서 나온 답변을 드리겠습니다.
데이터 수집, 이제 자동화하세요
복잡한 크롤링, 해시스크래퍼가 다 해줍니다. 개발비 0원, 유지보수 포함.
무료로 시작하기 →
