웹 크롤링 · 스크래핑
Web Crawling / Scraping
웹 크롤링이란?
- 웹을 돌며 데이터 자동 수집
- 데이터 수집·모니터링에 활용
- 과도한 크롤은 부담·법적 주의
크롤링과 스크래핑이 실제로 바꾸는 것은 '데이터를 얼마나 자주 보느냐'입니다. 담당자가 사이트를 하나씩 열어 눈으로 확인하고 엑셀에 옮기면 하루 한 번이 한계지만, 자동 수집을 붙이면 같은 일을 한 시간에 한 번도 할 수 있습니다. 그러면 가격·재고·평판이 '조사 결과'가 아니라 '실시간 지표'로 바뀝니다. 분기에 한 번 시장조사 보고서를 받아보던 조직이 오늘 오전에 벌어진 변화를 보고 오후에 대응하는 구조로 넘어가는 것입니다.
실무에서는 세 갈래를 구분해야 합니다. 첫째, 상대가 공식 API를 제공하면 무조건 그쪽이 먼저입니다. 화면이 바뀌어도 깨지지 않고 약관 시비도 없습니다. 둘째, API가 없고 값이 HTML에 그대로 박혀 있으면 단순 스크래핑으로 충분합니다. 셋째, 값이 자바스크립트로 나중에 그려지는 화면이라면 브라우저를 실제로 띄우는 도구가 필요하고 속도는 수십 배 느려집니다. 여기에 robots.txt의 허용 범위와 요청 간격이라는 조건이 붙습니다. 보통 1~2초 간격을 두고, 로그인해야 보이는 회원 전용 데이터는 손대지 않는 것이 원칙입니다.
수집 자체보다 유지가 일입니다. 페이지 구조는 예고 없이 바뀌고, 마켓 한 곳이 레이아웃을 손보면 그날부터 값이 들어오지 않습니다. 그래서 처음부터 수집 성공률을 기록하고 실패하면 알리는 장치를 함께 만들어야 합니다. 사내 화면을 자동으로 조작하는 RPA와도 성격이 다릅니다 — RPA는 권한을 받은 내부 시스템을 대신 클릭하는 일이고, 크롤링은 남의 서버에 요청을 보내는 일이라 상대 쪽 사정까지 계산에 넣어야 합니다.
가장 흔한 오해는 '공개된 화면이니 가져다 써도 된다'는 생각입니다. 공개와 자유 이용은 다릅니다. 국내에서도 경쟁 사이트의 데이터를 대량으로 긁어간 행위가 데이터베이스 제작자의 권리 침해로 다뤄진 분쟁이 있었고, 초당 수십 건씩 요청을 쏟아부어 상대 서버를 느리게 만들면 업무방해 문제로 번질 수 있습니다. 이름·연락처처럼 개인을 알아볼 수 있는 값이 섞이면 개인정보보호법 영역으로 들어갑니다. 더 조용한 사고도 있습니다. 구조가 바뀐 페이지에서 스크립트는 에러 없이 빈 값이나 0을 담아오고 대시보드는 그 숫자를 그대로 그리는데, 틀린 숫자를 근거로 가격을 내리는 일까지 벌어집니다.
검색엔진이 웹을 색인하기 위해 페이지를 자동 수집하던 크롤러에서 출발했고, 데이터 활용 수요와 함께 다양한 스크래핑 기술로 발전했습니다.
가상의 사례로 살펴보겠습니다. 생활용품을 만들어 파는 A사는 임직원 180명, 연매출 900억 원 규모이고 그중 4할이 오픈마켓에서 나옵니다. 300개 SKU가 마켓 네 곳에 깔려 있는데, 이커머스팀 MD 세 명이 매일 아침 두 시간씩 경쟁사 가격을 눈으로 확인해 엑셀에 옮겨 적고 있었습니다. 최저가에서 밀려난 사실을 반나절 지나서야 아는 일이 반복됐습니다.
- 이커머스팀 김 팀장이 '아침 두 시간을 받아적는 데 쓰는 건 낭비'라며 자동화를 꺼냈고, 네 곳 중 공식 API를 여는 두 곳은 API로, 나머지 두 곳만 스크래핑으로 가르기로 했습니다.
- 법무 담당 이 과장이 사이트별 이용약관과 robots.txt를 뒤져 공개 상품 페이지만 대상으로 잡았고, 로그인해야 보이는 리뷰·구매자 정보는 처음부터 수집 목록에서 뺐습니다.
- DX 담당 박 대리가 파이썬 스크립트를 짜 300개 SKU를 오전 9시·오후 2시·오후 6시 하루 세 번 돌렸고, 요청 간격을 2초로 잡아 한 회 수집이 15분에 끝나도록 맞췄습니다.
- 2주 차에 마켓 한 곳이 페이지를 개편하면서 가격이 전부 0원으로 들어왔습니다. 박 대리는 수집 실패율이 5%를 넘으면 사내 메신저로 알림이 가도록 규칙을 덧붙였습니다.
- 석 달 뒤 아침 작업은 두 시간에서 10분으로 줄었고, 최저가 이탈을 알아채는 데 걸리던 시간이 평균 6시간에서 40분으로 짧아졌습니다. 주력 15개 SKU의 가격 대응이 빨라지며 해당 품목 월 매출이 12% 올랐습니다.