크롤링 외주는 발주자가 준비한 만큼 결과가 좋아지는 분야입니다. "이 사이트들 데이터 좀 모아 주세요" 수준의 의뢰와, 수집처와 항목이 정리된 의뢰는 견적 정확도부터 완성물의 수명까지 전부 다릅니다. 109개 소스를 수집하는 공공데이터 파이프라인을 구축·납품해 본 경험을 바탕으로, 크롤링 외주 전에 챙겨 두면 좋은 것들을 체크리스트로 정리했습니다.
1. 수집처 목록: 어디서, 무엇을
가장 중요한 준비물입니다. 수집할 사이트(또는 API)의 주소를 표로 정리하고 각 수집처에서 원하는 게시판이나 섹션까지 지정해 주세요. 실제로 우리가 진행한 프로젝트도 고객이 수집처 목록을 엑셀로 정리해 보내 준 것이 출발점이었고 그 목록이 곧 견적의 근거이자 납품 검수 기준이 됐습니다.
수집처 목록이 중요한 이유는 크롤링 비용이 "사이트 수"가 아니라 "사이트 유형 수"에 비례하기 때문입니다. 구조가 같은 게시판 50개는 유형 하나로 흡수되지만 구조가 전부 다른 사이트 10개는 10벌의 작업입니다. 목록이 있어야 개발자가 유형을 묶어 정확한 견적을 낼 수 있습니다.
2. 데이터 항목: 어떤 필드가 필요한가
"공고를 수집해 달라"가 아니라 "제목, 기관, 신청 기간, 첨부파일 링크, 본문"처럼 필드 단위로 정의해 주세요. 항목 정의가 견적과 검수의 기준이 됩니다. 나중에 "담당자 연락처도 필요했는데요"가 나오면 재작업입니다.
이때 원본 사이트에 없는 항목을 어떻게 만들지도 정해야 합니다. 예를 들어 카테고리 분류가 사이트마다 다르거나 아예 없다면, 규칙으로 매핑할지 AI 분류를 붙일지가 별도의 설계 항목이 됩니다.
3. 갱신 주기: 얼마나 신선해야 하는가
하루 한 번이면 되는지, 한 시간 단위인지, 실시간에 가까워야 하는지에 따라 아키텍처와 비용이 달라집니다. 대부분의 공고·게시물 수집은 일 1회 새벽 배치로 충분하고 그 편이 대상 서버에도 부담이 없습니다. 실시간성 요구는 정말 필요한 경우에만 넣는 것이 좋습니다. 주기가 짧아질수록 운영 비용과 차단 위험이 함께 올라갑니다.
4. 법적 경계: 모을 수 있는 데이터인가
크롤링 외주에서 반드시 짚어야 하는 부분입니다. 최소한 다음을 확인하세요.
- 공개 범위: 로그인 없이 누구나 볼 수 있는 페이지인가. 로그인 뒤의 데이터, 유료 데이터는 성격이 완전히 다릅니다.
- 이용약관: 대상 사이트 약관이 자동화 수집을 명시적으로 금지하는지. 금지 사이트는 공식 API나 제휴 등 다른 경로를 찾는 것이 맞습니다.
- 개인정보: 수집 항목에 개인정보(이름, 연락처 등)가 포함되면 수집 근거와 보관 방식이 별도 검토 대상입니다.
- 저작권: 데이터를 내부 분석에 쓰는 것과 재배포·재판매하는 것은 다른 문제입니다. 활용 목적을 개발자에게 미리 알려 주세요.
공공기관의 공고처럼 공개를 전제로 게시되는 정보라도, 수집 속도를 제한해 서버에 부담을 주지 않는 방식이 기본입니다. 이런 요건을 견적 단계에서 확인하는 업체가 신뢰할 수 있는 업체입니다.
5. 유지보수: 크롤러는 소모품이라는 전제
크롤러는 납품 순간부터 낡기 시작합니다. 대상 사이트가 개편되면 수집이 깨지는 것은 결함이 아니라 크롤링의 본질입니다. 그래서 발주 전에 다음을 정해야 합니다.
| 확인 항목 | 왜 필요한가 |
|---|---|
| 개편 시 수리 범위와 비용 | 무상 하자보수와 유상 수리의 경계 분쟁 예방 |
| 장애 감지 방법 | 수집 실패를 발주자가 어떻게 알게 되는가 |
| 소스 추가 단가 | 수집처가 늘 때마다 재견적인지, 정해진 단가인지 |
| 인수인계 범위 | 소스코드·문서 포함 여부, 내부 인력 운영 가능성 |
수리 비용을 낮추는 것은 결국 구조입니다. 사이트별 코드가 아니라 유형별 템플릿과 설정으로 지은 크롤러는 개편 대응이 설정 수정 수준으로 끝납니다. 발주자 입장에서는 "사이트가 개편되면 어떤 작업이 필요한가"를 견적 단계에서 물어보는 것으로 이 구조를 가늠할 수 있습니다. 운영 안정 장치가 갖춰진 크롤러가 어떤 모습인지는 대규모 크롤러 운영 안정성에 정리해 두었습니다.
6. 전달 형태와 이후 활용
수집한 데이터를 어디로 받을지도 미리 정하세요. 엑셀 파일, DB 적재, API 제공, 대시보드까지 선택지마다 공수가 다릅니다. 수집 후 가공(분류, 중복 제거, 알림)이 필요하면 그것도 견적 항목입니다. 우리가 만든 파이프라인 사례처럼 수집과 AI 분류·중복 통합을 한 흐름으로 묶는 구성은 공공데이터 크롤링 자동화 사례에서 볼 수 있습니다. 공공데이터가 대상이라면 API 우선 검토가 기본인데, 그 함정들은 공공데이터 API 연동 함정에 따로 정리했습니다.
투자 판단이 고민된다면 수작업 시간을 기준으로 계산해 보세요. 담당자가 매일 사이트를 도는 시간에 인건비를 곱하는 방식은 자동화 도입 ROI 계산에서 다룬 그대로입니다.
크롤링 외주 준비물 요약
발주 전에 위 여섯 가지를 한 장으로 정리하면 이렇습니다.
| 준비물 | 정해 둘 것 |
|---|---|
| 수집처 목록 | 사이트 주소 · 대상 게시판 · 우선순위 |
| 데이터 항목 | 필요한 필드 정의 · 파생 항목(분류 등) 여부 |
| 갱신 주기 | 일 1회 배치인지, 더 짧은 주기가 정말 필요한지 |
| 법적 경계 | 공개 범위 · 약관 · 개인정보 · 활용 목적 |
| 유지보수 | 개편 대응 범위 · 장애 감지 · 소스 추가 단가 |
| 전달 형태 | 엑셀 · DB · API · 대시보드 중 무엇인지 |
자주 묻는 질문
크롤링 외주 견적은 무엇으로 결정되나요?
수집처의 유형 수, 데이터 항목의 복잡도, 갱신 주기, 전달 형태, 유지보수 범위가 주요 변수입니다. 특히 사이트 수보다 "구조가 다른 사이트 유형 수"가 공수를 좌우하므로, 수집처 목록을 정리해 주면 견적이 훨씬 정확해집니다.
어떤 사이트든 크롤링으로 수집할 수 있나요?
기술적으로 가능한 범위와 해도 되는 범위가 다릅니다. 로그인 없이 공개된 페이지, 약관이 자동화 수집을 금지하지 않는 사이트, 개인정보가 아닌 데이터가 기본 전제입니다. 이 경계를 함께 확인하지 않는 업체라면 오히려 주의가 필요합니다.
사이트가 바뀌면 크롤러를 다시 만들어야 하나요?
전부 다시 만들 필요는 없지만 수리는 필요합니다. 유형별 템플릿과 설정으로 분리된 구조라면 대부분 설정 수정 수준으로 끝나고 사이트별로 하드코딩된 구조라면 사실상 재개발이 됩니다. 발주 단계에서 개편 대응 방식을 물어보는 것이 구조를 가늠하는 가장 쉬운 방법입니다.
수집 데이터에 가공(분류·중복 제거)도 맡길 수 있나요?
가능하고 오히려 함께 설계하는 것이 좋습니다. 여러 수집처를 쓰면 형식 통일과 중복 정리가 반드시 필요해지는데, 수집과 가공을 한 파이프라인으로 묶으면 데이터가 바로 쓸 수 있는 형태로 유지됩니다. 가공 요건을 발주 시점에 알려 주면 아키텍처가 처음부터 그에 맞게 잡힙니다.