"직접 해보려 했는데, 안 되더라고요"
상담에서 가장 많이 듣는 말입니다. 무료 툴도 써 봤고, 개발 좀 하는 동료에게 부탁도 해 봤고, 요즘은 AI한테 코드도 짜 보게 했는데 — 어느 지점에선가 막혀서 오셨다는 이야기죠.
흥미로운 건, 그 "안 되더라"의 내용이 다들 비슷하다는 점입니다. 크롤링 프로젝트가 무너지는 지점은 대체로 정해져 있고, 심지어 순서대로 옵니다. 시작할 때 하나, 2주 뒤에 하나, 분석하려고 데이터를 열었을 때 하나, 그리고 몇 달 뒤에 둘. 이 글은 그 다섯 지점을 미리 보여드리는 글입니다. 어디서 막힐지 알고 시작하면, 적어도 같은 자리에서 넘어지지는 않습니다.
이유 1. 수집 가능성을 검증하지 않고 시작한다
첫 실패는 시작하자마자 옵니다. 대상 사이트가 어떤 곳인지 — 차단이 얼마나 강한지, 로그인이 필요한지, 원하는 항목이 실제로 화면에 있는지 — 확인하지 않고 도구부터 고르는 경우입니다.
작은 사이트에서 잘 되던 방법이 대형 커머스·포털·SNS 앞에서는 통하지 않습니다. 자동 접근을 막는 장치가 촘촘해서, 툴이나 AI가 짜준 기본 코드는 빈 화면을 받거나 금방 차단됩니다. "크롤링은 되는 것"이라는 전제로 일정과 예산을 잡았다가, 되는지부터 다시 확인해야 하는 상황이 되죠.
예방법: 어떤 방법을 쓰든, 본 작업 전에 대상 사이트로 소량 테스트부터 해 보세요. 저희도 견적 전에 수집 가능성 검토(접근 가능성·항목 존재·구조 안정성)를 먼저 하고, 이 단계를 건너뛰는 프로젝트는 받지 않습니다. 여기서 갈리는 게 절반입니다.
이유 2. "한 번 만들면 끝"이라고 가정한다
두 번째 실패는 2주쯤 뒤에 옵니다. 처음엔 분명 잘 돌았습니다. 그런데 사이트가 화면 구조를 바꾸는 순간 크롤러는 멈추거나, 더 나쁘게는 빈 값을 조용히 쌓기 시작합니다. 그리고 아무도 모릅니다 — 깨졌다는 걸 알려주는 장치를 만들지 않았으니까요.
한 달 뒤 데이터를 열어보고 나서야 2주 치가 비어 있는 걸 발견합니다. 지나간 기간의 화면은 다시 수집할 수 없으니, 그 구멍은 영구적입니다.
예방법: 크롤러와 함께 감시 장치를 계획에 넣어야 합니다. 수집량이 평소와 다르면 알림이 오는지, 실패하면 자동 재시도하는지. 저희는 수집 실패 시 재시도를 기본으로 걸고, 수집량 이상은 크롤러가 아니라 운영 체계가 먼저 알아채도록 하고 있습니다. 크롤링은 만드는 일이 아니라 돌리는 일이라는 게 이 지점의 교훈입니다.
이유 3. 데이터 품질을 아무도 확인하지 않는다
세 번째 실패는 분석하려고 데이터를 열었을 때 옵니다. 수집 자체는 성공했는데 — 같은 상품이 세 번씩 들어 있고(중복), 일부 페이지는 빠져 있고(누락), 가격 컬럼엔 "12,900원"과 "12900"이 섞여 있습니다(형식 불일치). 분석 전에 데이터 청소부터 해야 하고, 청소하다 보면 이 데이터를 믿어도 되는지 자체가 의심스러워집니다.
수집 건수만 보고 "잘 되고 있다"고 판단한 게 원인입니다. 품질은 건수에 안 잡힙니다.
예방법: 첫 수집 결과를 반드시 샘플 검수하세요 — 중복 기준, 필수 항목 누락률, 값 형식을 눈으로 확인하는 겁니다. 저희는 온보딩 단계에서 고객사와 함께 샘플을 검수해 필드와 형식을 확정하고, 중복 제거·형식 정리를 거친 데이터로 납품합니다. 분석에 바로 넣을 수 있는 상태가 수집의 완성입니다.
이유 4. 유지보수를 계속하지 못한다
네 번째 실패는 석 달쯤 뒤에 옵니다. 감시 장치를 잘 갖춰서 고장을 바로 알아채더라도, 이번엔 고치는 쪽에서 막힙니다. 수집 대상 사이트는 한 번 바뀌고 마는 게 아니라 계속 바뀝니다. 처음 한두 번은 담당자가 고치지만, 크롤러 수리는 누구의 본업도 아니라서 점점 밀리기 시작합니다. 대상 사이트가 여러 개면 수리할 일은 곱으로 늘어나고요.
그러다 담당자가 바빠지거나 자리를 옮기면 고칠 수 있는 사람이 사라지고, 크롤러는 하나둘 "고장난 채 방치" 상태로 넘어갑니다. 멈춘 크롤러를 두 달째 못 고치고 있다면, 그 프로젝트는 사실상 끝난 겁니다.
유지보수만이 아닙니다. 모니터링도 지속되지 않습니다. 초기에는 수집 현황을 매일 들여다보지만 몇 주 지나면 챙기는 사람이 없어지고, 알림을 걸어 뒀더라도 담당자가 바뀌면 그 알림을 받는 사람이 사라집니다. 유지보수와 모니터링은 둘 다 "계속해야 하는 일"인데, 내부 운영에서 가장 먼저 무너지는 게 바로 이 지속성입니다.
예방법: 시작 전에 "누가 감시하고, 누가 얼마나 자주 고칠 것인가"부터 정해야 합니다. 사이트 변경은 예외 상황이 아니라 상수입니다. 내부 인력으로 감당하기 어렵다면 유지보수가 포함된 구조로 시작하는 게 맞습니다 — 저희는 사이트 변경 대응을 월정액에 포함해, 수리가 밀려 방치되는 상황 자체가 생기지 않게 하고 있습니다. AI가 먼저 원인을 분석해 수정안을 만들고 사람이 검수해 반영하는 체계로 수리 속도도 계속 줄여가고 있고요.
이유 5. 비용을 개발비로만 계산한다
다섯 번째 실패는 예산에서 옵니다. 처음 계산에 넣은 건 크롤러 만드는 비용뿐 — 그런데 실제로는 매달 서버·프록시 운영비가 나가고, 사이트가 바뀔 때마다 수리 비용이 들고, 수집 대상을 늘릴 때마다 개발비가 다시 발생합니다. 확정해 둔 예산 위로 청구가 반복되면, 프로젝트는 성과와 무관하게 "돈 먹는 하마"로 불리기 시작하고 확장 논의는 막힙니다.
예방법: 시작 전에 1년 총비용(TCO)으로 계산하세요. 개발비·운영비·유지보수·추가 개발까지 넣고 두 가지 방식(건별 과금 vs 월정액 구독)을 비교하면, 우리 상황에 맞는 구조가 보입니다. 계산 프레임은 아래 '함께 보면 좋은 글'의 TCO 글에 정리해 두었습니다.
다섯 가지의 공통점
정리하면 이렇습니다.
시점실패원인시작할 때수집이 안 됨가능성 미검증2주 뒤데이터에 구멍감시 체계 부재분석할 때데이터를 못 믿음품질 검수 부재석 달 뒤고장난 채 방치유지보수·모니터링 지속 불가예산 때비용 폭탄운영비 미계산
공통점이 보이시나요. 다섯 실패 모두 크롤링을 "코드 한 번 짜는 일"로 봤기 때문에 생깁니다. 실제로는 검증하고, 감시하고, 검수하고, 계속 고치고, 운영 비용을 감당하는 — 계속 돌아가는 운영입니다. "직접 해보려 했는데 안 되더라"의 정체는 대부분 기술 부족이 아니라, 이 운영의 무게였습니다.
자주 묻는 질문
Q. 직접 하다가 막혔는데, 처음부터 다시 해야 하나요? 아닙니다. 오히려 시도해 보신 분일수록 대상과 항목이 명확해서 진행이 빠릅니다. 어디서 막혔는지 알려주시면 그 지점부터 검토해 드립니다.
Q. 다섯 가지 중 뭐가 제일 흔한가요? 시작 단계에서는 1번(가능성 미검증), 운영 단계에서는 2번(감시 부재)입니다. 특히 2번은 실패한 줄도 모른 채 진행되는 경우가 많아 피해가 큽니다.
Q. 맡기면 이 다섯 가지가 다 해결되나요? 네, 다섯 가지가 정확히 수집 서비스가 하는 일입니다 — 가능성 검토(1), 감시·자동 재시도(2), 샘플 검수·정제(3), 유지보수·모니터링 상시 운영(4), 예측 가능한 월정액 구조(5). 다만 수집한 데이터를 어떤 의사결정에 쓸지는 고객사의 몫이라, 상담에서 목적을 먼저 여쭙고 수집 범위를 함께 좁혀 드립니다.
함께 보면 좋은 글
지금 바로 시작하기
지금 어느 지점에서 막혀 계신가요? 대상 사이트와 막힌 상황을 알려주시면, 다섯 가지 관점에서 무엇이 문제인지 무료로 진단해 드립니다.
