웹크롤링을 다시 설계하는 4가지 데이터 수집 원칙

웹크롤링은 단순히 데이터를 긁어오는 기술이 아니다. 잘못 설계된 웹크롤링은 노이즈만 쌓이고, 정작 의사결정에 쓸 수 있는 데이터는 나오지 않는다. 데이터 수집의 목적을 먼저 정의하지 않으면, 수집량이 늘어날수록 분석 비용만 커진다.

1. 문제: 수집은 많은데 쓸 수 있는 데이터가 없다

많은 팀이 크롤러를 돌린다. 그런데 막상 수집된 데이터를 열어보면 중복이 가득하고, 필드가 들쭉날쭉하며, 언제 수집된 데이터인지 알 수 없는 경우가 많다.

문제는 크롤러의 성능이 아니다. 수집 전에 "이 데이터로 무엇을 결정할 것인가"를 정의하지 않은 것이 원인이다. 수집 목적이 없으면 필드 설계도 없고, 필드 설계가 없으면 정제 기준도 없다. 결국 쌓이는 것은 데이터가 아니라 파일이다.

자사몰을 운영하는 이커머스 팀이 경쟁사 가격을 모니터링하려고 크롤러를 붙였지만, 상품명 표기 방식이 사이트마다 달라 매칭이 안 되는 상황이 대표적이다. 수집은 자동화됐지만 분석은 여전히 수작업이다.

2. 인사이트: 데이터 수집은 설계 문제다

크롤링을 기술 문제로 보면 해결책이 도구에 집중된다. 그러나 실제 병목은 대부분 설계에 있다.

수집 전에 세 가지를 명확히 해야 한다. 어떤 의사결정을 위한 데이터인가, 어떤 주기로 수집해야 의미 있는가, 수집된 데이터가 어떤 형태로 소비되는가. 이 세 질문에 답하지 못한 채 크롤러를 돌리면, 운영 비용은 올라가고 활용도는 낮아진다.

수집과 활용 사이의 거리가 멀수록 데이터의 유효성은 떨어진다. 수집 즉시 정제되고 구조화된 데이터만이 실제 워크플로우에 연결된다.

3. 프레임워크: 웹크롤링 데이터 수집을 재설계하는 4가지 원칙

원칙 1. 수집 목적을 의사결정 단위로 정의한다

"시장 조사를 위해 수집한다"는 목적이 아니다. "매주 월요일 경쟁사 3곳의 주요 카테고리 가격을 비교해 자사 가격 정책 검토에 활용한다"처럼 의사결정 단위로 내려야 한다.

목적이 구체적일수록 수집 범위가 줄고, 필드 설계가 명확해진다. 부동산 플랫폼이라면 매물 전체를 긁는 것이 아니라 특정 지역, 특정 면적대, 특정 가격 범위만 수집하도록 범위를 좁혀야 한다. 수집 범위가 줄면 크롤러 유지 비용도 줄고, 정제 작업도 단순해진다.

원칙 2. 수집 주기를 데이터의 변화 속도에 맞춘다

모든 데이터를 실시간으로 수집할 이유는 없다. 가격 데이터는 하루 단위, 리뷰 데이터는 주 단위, 채용 공고 데이터는 3일 단위처럼 데이터의 실제 변화 속도에 주기를 맞춰야 한다.

주기가 너무 짧으면 서버 부하가 커지고 차단 위험도 올라간다. 주기가 너무 길면 데이터가 낡아 의사결정에 쓸 수 없다. 학원 업종에서 경쟁 학원의 강좌 개설 현황을 모니터링한다면, 강좌는 주 단위로 바뀌는 경우가 많으므로 매일 수집하는 것은 자원 낭비다.

원칙 3. 필드 설계를 소비 형태 기준으로 역방향으로 만든다

수집할 수 있는 필드를 모두 가져오는 방식은 정제 비용을 키운다. 대신 최종 소비 형태, 즉 대시보드, 보고서, LLM 입력값 중 어느 형태로 쓸 것인지를 먼저 정하고, 거기에 필요한 필드만 수집 대상으로 지정한다.

카페24나 아임웹 기반 자사몰에서 경쟁사 상품 데이터를 수집한다면, 대시보드에 올릴 필드는 상품명, 가격, 재고 여부, 수집 시각 정도로 충분하다. 상품 설명 전문이나 이미지 URL까지 수집하면 저장 비용은 올라가고 실제 활용도는 낮아진다.

원칙 4. 수집 실패와 이상값을 탐지하는 구조를 처음부터 포함한다

크롤러는 반드시 실패한다. 사이트 구조가 바뀌거나, 차단되거나, 빈 값이 들어오거나, 이전과 다른 형식으로 데이터가 내려온다. 이를 탐지하지 못하면 잘못된 데이터가 의사결정에 그대로 흘러들어간다.

수집 파이프라인에는 반드시 이상 탐지 단계가 포함되어야 한다. 최소한 필드 누락 여부 확인, 이전 수집값 대비 급격한 변화 감지, 수집 성공률 로깅 세 가지를 처음부터 설계에 넣어야 한다. 병원 업종에서 경쟁 의원의 진료 시간을 수집한다면, 값이 비어 있을 때 "미수집"과 "실제 없음"을 구분하는 로직이 없으면 데이터 신뢰도가 무너진다.

4. 사례: 업종별 재설계 시나리오

이커머스 자사몰: 경쟁사 가격 모니터링

카페24 기반 의류 자사몰을 운영하는 팀이 경쟁사 5곳의 동일 카테고리 가격을 수집한다고 가정한다. 처음에는 전체 상품 페이지를 긁었지만, 상품 매칭이 되지 않아 분석이 불가능했다. 재설계 후에는 수집 범위를 베스트셀러 상위 20개 상품으로 한정하고, 필드를 상품명, 정가, 할인가, 수집 시각으로 좁혔다. 주기는 하루 1회로 고정했다. 이상 탐지로는 할인율이 전날 대비 30%포인트 이상 변동하면 슬랙 알림이 가도록 설정했다. 수집 데이터의 활용 밀도가 높아졌고, 주간 가격 검토 회의에서 실제 근거 자료로 쓰이기 시작했다.

부동산: 매물 시세 추적

특정 지역 오피스텔 매물 시세를 추적하는 팀이 있다고 가정한다. 전체 매물 데이터를 수집하던 방식에서, 전용면적 20~30㎡, 보증금 1억 이하 조건으로 범위를 좁혔다. 수집 주기는 3일로 설정했고, 동일 매물이 중복 수집되지 않도록 매물 고유 ID 기반 중복 제거 로직을 추가했다. 이상 탐지로는 동일 주소의 가격이 직전 수집 대비 20% 이상 변동하면 검토 대기열로 이동하도록 설계했다.

학원: 경쟁 강좌 개설 현황

입시 학원이 경쟁 학원의 강좌 개설 현황을 모니터링한다고 가정한다. 수집 목적을 "신규 강좌 개설 여부를 매주 확인해 자사 커리큘럼 기획에 반영"으로 정의했다. 필드는 강좌명, 대상 학년, 개강일, 수집 시각으로 한정했다. 주 1회 수집으로 충분했고, 강좌 목록 페이지 구조가 바뀔 경우 수집 실패 알림이 가도록 설정해 데이터 공백을 방지했다.

5. 다음 단계: 수집된 데이터를 워크플로우에 연결하는 방법

데이터를 잘 수집하는 것은 시작이다. 수집된 데이터가 실제 의사결정 워크플로우에 자동으로 연결되어야 비로소 자동화가 완성된다. 다음 글에서는 수집된 웹크롤링 데이터를 정제, 분류, 요약하는 파이프라인 설계 방법을 다룬다.

Q. 웹크롤링을 시작하기 전에 반드시 확인해야 할 법적 기준이 있나요?

수집 대상 사이트의 robots.txt 파일을 먼저 확인한다. robots.txt는 크롤링 허용 범위를 명시한 파일로, 비허용 경로를 수집하면 서비스 이용 약관 위반이 될 수 있다. 또한 수집 데이터에 개인정보가 포함되는 경우 개인정보 보호법 적용 여부를 별도로 검토해야 한다. 공개된 데이터라도 수집 방식과 활용 목적에 따라 법적 판단이 달라질 수 있으므로, 대규모 수집 전에는 법률 검토를 거치는 것이 원칙이다.

Q. 크롤러가 자주 차단되는 경우 어떻게 대응하나요?

차단의 주요 원인은 짧은 간격의 반복 요청과 비정상적인 요청 헤더다. 요청 간격을 늘리고, 브라우저와 유사한 헤더를 사용하는 것이 기본 대응이다. 구조적으로는 수집 주기 자체를 데이터 변화 속도에 맞게 늘리는 것이 가장 근본적인 해결책이다. 일부 사이트는 공식 API를 제공하므로, 크롤링 전에 API 제공 여부를 먼저 확인하는 것이 우선이다.

Q. 수집한 데이터를 생성형 AI에 입력할 때 주의할 점은 무엇인가요?

생성형 AI에 입력하는 데이터는 정제 수준이 높을수록 출력 품질이 올라간다. 중복 제거, 빈 값 처리, 형식 통일이 선행되어야 한다. 또한 수집 시각이 명시되지 않은 데이터는 AI가 최신 정보로 오해할 수 있으므로, 수집 시각 필드를 반드시 포함해 입력 데이터의 시점을 명확히 해야 한다. 개인정보가 포함된 데이터를 외부 AI 서비스에 입력할 경우 별도의 마스킹 처리가 필요하다.