크롤링 프로그램이 자주 멈추는 이유와 유지보수가 필요한 이유

크롤링 프로그램을 처음 개발한 뒤에는 데이터가 정상적으로 수집되다가 어느 날 갑자기 멈추는 경우가 있습니다.

• 일부 데이터만 누락됨
• 로그인 단계에서 실패함
• 수집 건수가 갑자기 0건이 됨
• 특정 페이지에서 계속 멈춤
• 같은 데이터가 중복 저장됨
• 이미지와 첨부파일이 내려받아지지 않음
• 실행 시간이 평소보다 길어짐

개발 당시에는 정상적으로 작동했는데 왜 시간이 지나면 문제가 생기는 걸까요?

가장 큰 이유는 크롤링 프로그램이 개발 업체의 시스템만 사용하는 것이 아니라 계속 변경되는 외부 웹사이트의 구조와 정책에 의존하기 때문입니다.

대상 사이트가 화면, 로그인 방식, 주소와 데이터 로딩 방식을 변경하면 기존 수집 코드도 수정이 필요할 수 있습니다.

따라서 장기간 사용하는 크롤링 프로그램은 처음 개발하는 것뿐 아니라 오류를 탐지하고 변경에 대응하는 운영 구조가 중요합니다.

크롤링은 외부 사이트 구조에 의존합니다

일반적인 웹서비스는 개발자가 자기 서비스의 화면과 서버를 모두 관리합니다.

반면 크롤링 프로그램은 다른 사이트의 페이지를 읽습니다.

예를 들어 상품명을 다음 구조에서 찾고 있을 수 있습니다.

<h2 class="product-title">상품명</h2>

대상 사이트가 다음처럼 변경하면 기존 코드가 상품명을 찾지 못할 수 있습니다.

<div class="item-name">상품명</div>

사용자에게 보이는 화면은 비슷해도 내부 HTML 구조가 달라지면 수집 결과가 달라질 수 있습니다.

크롤링 프로그램이 멈추는 대표적인 이유

1. HTML 구조가 변경되었습니다

가장 일반적인 원인입니다.

변경될 수 있는 요소:

• 태그
• 클래스 이름
• 페이지 구조
• 목록과 상세 배치
• 버튼
• 탭
• 이미지 주소
• 페이지 번호

문제는 프로그램이 완전히 멈추지 않고 잘못된 데이터를 저장할 수도 있다는 점입니다.

예를 들어 상품 가격 대신 배송비를 가격으로 잘못 읽을 수 있습니다.

따라서 성공 여부뿐 아니라 데이터 품질도 확인해야 합니다.

2. 페이지 주소가 변경되었습니다

기존 주소:

example.com/products?page=1

변경된 주소:

example.com/shop/list/1

주소 규칙이 바뀌면 다음 페이지로 이동하지 못하거나 상세 페이지를 찾지 못할 수 있습니다.

다음 변경도 영향을 줄 수 있습니다.

• 도메인 변경
• 서브도메인 변경
• 카테고리 주소
• 검색 URL
• 언어별 주소
• 모바일 페이지 통합

3. 페이지 이동 방식이 바뀌었습니다

기존에는 페이지 번호를 눌렀지만 이후 무한 스크롤이나 더보기 버튼 방식으로 바뀔 수 있습니다.

• 페이지 번호
• 더보기
• 무한 스크롤
• 내부 API
• 날짜별 로딩

프로그램이 첫 화면만 수집하고 나머지 데이터를 놓칠 수 있습니다.

4. 데이터가 JavaScript로 로딩됩니다

초기에는 HTML에 데이터가 들어 있었지만 이후 브라우저에서 API를 호출해 데이터를 표시하는 구조로 변경될 수 있습니다.

이 경우 일반적인 HTML 요청으로는 빈 화면만 받을 수 있습니다.

다음 방식의 변경이 필요할 수 있습니다.

• 내부 API 분석
• 브라우저 자동화
• 로딩 완료 대기
• 스크롤과 클릭
• 데이터 응답 직접 처리

5. 로그인 방식이 변경되었습니다

• 로그인 화면 개편
• 보안 인증 추가
• 2단계 인증
• CAPTCHA
• 소셜 로그인 전환
• 세션 만료 시간 변경
• 동시 접속 제한

자동 수집 계정이 로그아웃되면 로그인 이후 페이지를 모두 수집하지 못할 수 있습니다.

6. 접근 제한이 강화되었습니다

대상 사이트에서 짧은 시간에 많은 요청을 보내는 접속을 제한할 수 있습니다.

발생할 수 있는 현상:

• 응답 속도 저하
• 일시 차단
• 오류 페이지
• 로그인 해제
• CAPTCHA 표시
• 특정 IP 제한
• 일부 데이터 숨김

단순히 요청 속도를 높이는 방식은 안정적인 수집과 반대될 수 있습니다.

필요한 정보와 변경 주기를 고려해 적절한 수집 빈도를 정해야 합니다.

7. 데이터 형식이 변경되었습니다

화면 구조는 같아도 실제 데이터 표현이 달라질 수 있습니다.

가격

10,000원
10,000
10천 원
가격 문의
무료

날짜

2026-07-24
2026.07.24
24 July 2026
3시간 전

상태

판매 중
품절
일시 품절
판매 종료

프로그램이 예상하지 못한 값은 오류가 되거나 잘못 저장될 수 있습니다.

8. 필수 데이터가 비어 있습니다

일부 페이지에는 이미지, 가격 또는 작성자가 없을 수 있습니다.

모든 데이터가 항상 존재한다고 가정하면 수집이 중단될 수 있습니다.

다음 처리가 필요합니다.

• 빈 값 허용
• 기본값
• 오류 데이터 분리
• 필수 항목 누락 알림
• 해당 항목만 건너뛰기

9. 광고와 추천 영역이 섞였습니다

목록 중간에 광고나 추천 콘텐츠가 추가되면 일반 데이터처럼 수집될 수 있습니다.

예시:

상품 1
상품 2
광고
상품 3
추천 콘텐츠

수집 대상과 제외 대상을 구분하는 규칙이 필요합니다.

10. 요청 응답이 느려졌습니다

대상 사이트나 네트워크가 느려지면 프로그램의 제한 시간을 초과할 수 있습니다.

• 페이지 응답 지연
• 이미지 로딩
• 브라우저 자동화 지연
• 외부 API 지연
• 서버 자원 부족

너무 짧은 제한 시간은 정상 페이지도 실패하게 만들고, 너무 긴 제한 시간은 전체 작업을 늦출 수 있습니다.

11. 일부 페이지가 삭제되었습니다

기존 데이터의 상세 페이지가 사라질 수 있습니다.

이 경우 다음을 결정해야 합니다.

• 기존 데이터를 삭제하는가?
• 판매 종료로 표시하는가?
• 마지막 데이터를 유지하는가?
• 삭제 이력을 남기는가?
• 일정 횟수 확인 후 삭제하는가?

페이지가 한 번 열리지 않았다고 바로 데이터 전체를 삭제하면 일시적인 장애 때문에 정보가 사라질 수 있습니다.

12. 서버 자원이 부족합니다

크롤링 서버 자체의 문제일 수도 있습니다.

• 메모리 부족
• 저장 공간 부족
• 데이터베이스 용량
• CPU 사용 증가
• 동시에 너무 많은 작업 실행
• 브라우저 프로세스 누적
• 로그 파일 증가

데이터와 사이트 수가 늘어나면 초기 서버 설정이 부족해질 수 있습니다.

13. 자동 실행이 중복되었습니다

서버가 재시작되거나 스케줄러가 중복 등록되면 같은 작업이 동시에 실행될 수 있습니다.

발생 가능한 문제:

• 중복 데이터
• 요청량 증가
• 중복 알림
• 같은 파일 덮어쓰기
• 계정 차단 가능성
• 서버 부하

한 번에 하나만 실행되도록 잠금과 중복 방지 구조가 필요할 수 있습니다.

14. 작업이 중간에 종료되었습니다

1만 건 중 7천 건을 수집한 상태에서 서버가 재시작될 수 있습니다.

다시 처음부터 수집하면 시간과 요청이 낭비됩니다.

대규모 수집에서는 다음 기능이 필요할 수 있습니다.

• 진행 위치 저장
• 페이지별 완료 상태
• 실패 구간 재시작
• 작업 단위 분리
• 체크포인트
• 중복 저장 방지

15. 외부 서비스가 변경되었습니다

크롤링 결과를 다음 서비스와 연결할 수 있습니다.

• 이메일
• Slack
• 데이터베이스
• AI API
• Google Sheets
• 파일 저장소

수집은 성공했지만 저장이나 알림 단계에서 실패할 수도 있습니다.

프로그램이 멈췄다는 사실을 어떻게 알 수 있을까?

가장 위험한 상태는 프로그램이 실패했는데도 아무도 모르는 것입니다.

다음 기준으로 이상 여부를 감지할 수 있습니다.

• 예정 시간에 작업이 실행되지 않음
• 수집 건수가 0건
• 평소보다 수집 건수가 급감
• 필수 항목 누락률 증가
• 특정 사이트 연속 실패
• 실행 시간이 지나치게 길어짐
• 마지막 성공 시각이 오래됨
• 동일 데이터 급증

성공 로그만으로는 부족합니다

프로그램이 오류 없이 종료됐다고 데이터가 정확한 것은 아닙니다.

예를 들어 사이트 구조가 변경돼 상품을 하나도 찾지 못했지만 프로그램 자체는 정상 종료될 수 있습니다.

실행 결과: 성공
수집 건수: 0건

따라서 성공 여부와 함께 수집 결과를 검증해야 합니다.

데이터 품질 점검 기준

1. 수집 건수

평균 5,000건이던 사이트가 갑자기 50건만 수집됐다면 이상할 수 있습니다.

2. 필수 항목 누락

• 제목 없음
• URL 없음
• 가격 없음
• 날짜 없음

3. 값의 범위

상품 가격이 모두 0원이거나 동일한 값이면 잘못 수집했을 가능성이 있습니다.

4. 중복률

기존보다 중복 데이터가 급증하면 식별 기준이나 페이지 이동에 문제가 있을 수 있습니다.

5. 신규 데이터 비율

새 데이터가 평소보다 지나치게 많거나 전혀 없으면 확인이 필요합니다.

모니터링 화면에서 확인할 정보

실패 알림에 포함하면 좋은 내용

좋지 않은 알림:

크롤링 실패

보다 유용한 알림:

수집 대상:
사이트 A

발생 시각:
2026-07-24 08:15

실패 단계:
로그인

원인:
로그인 세션 만료

마지막 성공:
2026-07-23 08:12

필요 조치:
관리자에서 계정을 다시 인증해 주세요.

운영자가 다음 행동을 판단할 수 있어야 합니다.

자동 재시도가 필요한 경우

일시적인 네트워크 오류와 서버 지연은 다시 시도하면 해결될 수 있습니다.

예시:

1차 실패
→ 5분 뒤 재시도
→ 30분 뒤 재시도
→ 최종 실패 알림

하지만 사이트 구조가 바뀐 경우 반복 재시도만으로 해결되지 않습니다.

같은 오류가 계속된다면 재시도를 멈추고 관리자에게 알려야 합니다.

수동 재실행

관리자 페이지에서 실패한 작업만 다시 실행할 수 있습니다.

• 전체 사이트 재실행
• 특정 사이트
• 특정 날짜
• 실패 페이지
• 특정 데이터

재실행 시 기존 데이터가 중복 저장되지 않도록 해야 합니다.

사이트 구조 변경을 빠르게 발견하는 방법

1. 핵심 데이터 검증

제목과 URL처럼 반드시 존재해야 하는 값이 비면 오류로 처리합니다.

2. 예상 수집량 비교

최근 평균과 비교해 갑작스러운 변화가 있으면 알립니다.

3. 샘플 페이지 저장

문제가 발생한 원본 페이지나 화면을 저장하면 원인을 분석하기 쉬울 수 있습니다.

개인정보와 이용 조건을 고려해 필요한 범위만 보관해야 합니다.

4. 사이트별 테스트

정식 수집 전에 대표 페이지에서 수집 항목을 확인하는 테스트를 실행할 수 있습니다.

크롤링 유지보수에는 무엇이 포함될까?

1. 사이트 구조 변경 대응

• 선택자 변경
• URL 변경
• 페이지 이동 수정
• 로그인 변경
• 데이터 형식 변경

2. 오류 확인

• 실행 실패
• 데이터 누락
• 중복
• 비정상 값
• 처리 지연

3. 서버 관리

• 저장 공간
• 프로세스
• 스케줄러
• 로그
• 백업
• 배포

4. 계정 관리

• 로그인 만료
• 비밀번호 변경
• 인증
• 계정 잠금
• 권한

5. 외부 API와 연동

• 데이터베이스
• 이메일
• AI
• 메시지
• 파일 저장소

6. 데이터 규칙 변경

사업 운영에 따라 수집 항목과 분류 기준이 달라질 수 있습니다.

이는 기존 오류 수정이 아니라 기능 변경이나 추가 개발이 될 수 있습니다.

하자보수와 운영 유지보수의 차이

하자보수에 가까운 경우

• 개발 당시 합의한 페이지에서 수집이 처음부터 작동하지 않음
• 특정 조건이 누락됨
• 중복 방지 기능이 잘못 구현됨
• 자동 실행 설정 오류

운영 유지보수에 가까운 경우

• 대상 사이트가 화면 구조를 변경함
• 로그인 정책이 변경됨
• 수집 항목이 새로 추가됨
• 새로운 사이트를 추가함
• 외부 API가 변경됨
• 데이터 양이 크게 증가함

대상 사이트의 변경은 개발 업체가 통제할 수 없으므로 지속적인 무상 수정으로 포함되지 않을 수 있습니다.

계약 전에 기준을 확인하는 것이 좋습니다.

유지보수 계약 방식

1. 건별 대응

문제가 발생할 때마다 원인을 분석하고 견적을 받아 수정합니다.

적합할 수 있는 경우:

• 사이트 수가 적음
• 변경이 드묾
• 크롤링이 중요 업무가 아님
• 중단돼도 즉시 피해가 크지 않음

2. 월 유지보수

정기적으로 상태를 확인하고 일정 범위의 변경에 대응합니다.

포함될 수 있는 업무:

• 실패 모니터링
• 사이트 구조 수정
• 서버 점검
• 월 작업 시간
• 결과 보고

3. 운영형 계약

사업의 핵심 데이터 수집이라면 보다 구체적인 대응 기준을 정할 수 있습니다.

• 모니터링 주기
• 장애 등급
• 대응 시간
• 복구 목표
• 백업
• 담당자
• 월간 보고

유지보수 비용을 결정하는 요소

크롤링 프로그램을 더 안정적으로 만드는 방법

1. 공식 API를 먼저 검토합니다

공식적인 데이터 제공 방식이 있다면 화면 구조를 읽는 크롤링보다 안정적인 경우가 많습니다.

다만 API에도 이용 한도와 비용, 정책 변경이 있을 수 있습니다.

2. 꼭 필요한 데이터만 수집합니다

수집 범위와 요청 횟수를 줄이면 실패와 운영 비용도 줄어듭니다.

3. 적절한 주기를 사용합니다

하루에 한 번 바뀌는 데이터를 매분 수집할 필요는 없습니다.

4. 사이트별 작업을 분리합니다

한 사이트 실패가 전체 수집을 멈추지 않도록 구성할 수 있습니다.

5. 수집 원본과 정제 데이터를 구분합니다

원본 데이터를 일부 보관하면 정제 규칙이 잘못됐을 때 다시 처리하기 쉬울 수 있습니다.

6. 변경을 자동으로 감지합니다

수집량, 누락률과 실행 시간을 기준으로 이상을 탐지합니다.

7. 다른 개발자가 이어받을 수 있게 문서화합니다

• 사이트 목록
• 수집 항목
• 실행 주기
• 로그인 계정
• 데이터 구조
• 오류 처리
• 배포 방법

운영 담당자가 매일 확인할 항목

[ ] 모든 수집 작업이 실행됐는가?
[ ] 마지막 성공 시각은 언제인가?
[ ] 수집 건수가 평소와 비슷한가?
[ ] 특정 사이트가 연속 실패했는가?
[ ] 필수 데이터 누락이 증가했는가?
[ ] 중복 데이터가 급증했는가?
[ ] 서버 저장 공간은 충분한가?
[ ] 자동 재시도가 반복되고 있지 않은가?

개발 업체에 물어볼 질문

• 사이트 구조가 변경되면 어떻게 감지하나요?
• 수집 건수가 0건이어도 성공으로 처리되나요?
• 실패하면 자동으로 재시도하나요?
• 사이트 하나가 실패해도 다른 사이트는 계속 수집하나요?
• 관리자에서 마지막 성공 시각을 확인할 수 있나요?
• 오류 알림에는 어떤 정보가 포함되나요?
• 대상 사이트 변경 대응은 무상인가요, 유지보수인가요?
• 월 유지보수에 몇 개 사이트까지 포함되나요?
• 서버와 데이터베이스도 관리하나요?
• 다른 개발자가 이어서 관리할 수 있도록 문서를 제공하나요?

유지보수 계약에서 확인할 항목

대상 사이트:
수집 주기:
모니터링 범위:
장애 접수 방식:
일반 오류 대응 시간:
긴급 오류 기준:
구조 변경 수정 범위:
월 포함 작업 시간:
신규 사이트 추가 비용:
서버 관리:
로그 보관:
백업:
월간 보고:
계약 종료 후 소스·데이터 인계:

마무리

크롤링 프로그램이 자주 멈추는 이유는 코드가 반드시 잘못되어서만은 아닙니다.

프로그램이 의존하는 외부 사이트가 계속 변경되기 때문입니다.

장기간 안정적으로 운영하려면 다음 기능이 중요합니다.

• 실행 상태 확인
• 데이터 품질 검증
• 실패 알림
• 자동 재시도
• 수동 재실행
• 사이트 변경 대응
• 서버와 로그 관리

크롤링 개발을 의뢰할 때 최초 수집 성공만 확인하지 말고, 몇 달 뒤 구조가 바뀌거나 일부 작업이 실패했을 때 어떻게 발견하고 복구할지도 함께 설계하는 것이 좋습니다.