크롤러의 수명은 셀렉터가 정합니다. 수집 로직이 아무리 훌륭해도, 대상 사이트의 화면 구조가 바뀌는 순간 셀렉터가 어긋나고 수집은 멈춥니다. 문제는 이것이 예외가 아니라 일상이라는 점입니다. 사이트는 개편되라고 있는 것이고 크롤러는 그때마다 수리 대상이 됩니다. 그렇다면 설계 목표는 "안 깨지는 셀렉터"가 아니라 "깨져도 수리가 싼 구조"입니다. 야구 데이터 수집기를 만들며 정리한 셀렉터 안정화 기법들입니다.
셀렉터 원칙: 바뀌는 것에 걸지 말 것
같은 요소를 가리키는 셀렉터도 무엇에 거느냐에 따라 수명이 다릅니다.
| 거는 대상 | 수명 | 예 |
|---|---|---|
| 위치·순서 | 가장 짧음 | 세 번째 div, 다섯 번째 행 |
| 자동 생성 클래스 전체 | 짧음 | 빌드마다 바뀌는 해시 접미사 포함 |
| 의미 있는 안정 접두사·텍스트 | 김 | 클래스의 의미 부분, 헤더 문구 |
| 데이터 자체의 구조 | 가장 김 | JSON 필드, 표의 헤더명 |
실전 사례가 명확했습니다. 수집 대상 포털 페이지는 요즘 프런트엔드 프레임워크로 만들어져 클래스 이름에 빌드마다 바뀌는 해시가 붙습니다. 클래스 전체 문자열에 셀렉터를 걸면 배포 한 번에 깨집니다. 대신 클래스의 의미 있는 접두사만 정규식으로 매칭하니, 해시가 바뀌어도 파서가 살아남았습니다.
표 파싱도 같은 원리입니다. "몇 번째 열"이 아니라 헤더 텍스트로 열을 찾으면, 열 순서가 바뀌는 개편을 수정 없이 흡수합니다. 광고 정산 파일에서 헤더 행 위치가 유동적이던 문제를 텍스트 탐색으로 푼 것(매체별 정산서 양식 차이)과 같은 접근입니다.
주소는 한 파일에: 수리 지점의 단일화
셀렉터만큼 자주 바뀌는 것이 URL입니다. 사이트 개편은 화면 구조뿐 아니라 주소 체계도 흔듭니다. 우리는 수집 대상 URL 전부를 파일 하나에 상수로 모았습니다. 수집 스텝이 13종이라 URL이 코드 곳곳에 흩어질 뻔했는데, 단일 소스로 강제한 덕에 "어떤 주소가 바뀌어도 수정은 한 줄"이라는 규칙이 성립했습니다.
이 결정의 가치는 실제 상황에서 증명됐습니다. 개발 중 대상 사이트의 도메인 표기가 처음 가정과 달랐고 일부 레거시 주소는 서버 오류를 반환해 교체가 필요했습니다. 두 번 모두 수정은 URL 파일 한 곳으로 끝났습니다. 수리가 쌌기 때문에 대응도 빨랐습니다.
깨짐을 빨리 아는 것도 안정화다
셀렉터 안정화의 후반전은 감지입니다. 아무리 잘 걸어도 언젠가 깨지므로, 깨진 순간을 빨리 아는 구조가 필요합니다.
- 빈 결과를 성공으로 치지 않기: 셀렉터가 아무것도 못 찾았을 때 빈 목록을 반환하고 넘어가면, 고장이 "데이터 없음"으로 위장합니다. 기대 요소가 없으면 실패로 기록해야 합니다.
- 검증 가능한 지점 남기기: 우리는 리포트의 표시 수치를 원본과 대조하는 검증 절차를 만들어, 파싱이 미묘하게 어긋나는 유형(엉뚱한 열을 읽는 오류)까지 잡을 수 있게 했습니다. 상세는 수집 데이터 검증 방법에서 다룹니다.
- 실패의 격리: 수집 스텝 단위로 실패를 격리하면, 한 지표의 파싱이 깨져도 나머지 지표는 수집됩니다. 수리 우선순위도 명확해집니다.
- 실행 식별자와 중간 산출물: 실행마다 단계별 산출물을 식별자 아래 보관해, 깨짐이 감지됐을 때 어느 단계의 응답부터 이상했는지 바로 좁힐 수 있게 했습니다.
- 선행 자산 점검: 파싱에 필요한 템플릿·설정이 빠졌으면 수집을 시작하기 전에 알려 주는 사전 점검을 두어, 헛수집을 막았습니다.
셀렉터 유지보수를 견적에 넣어라
마지막은 기대치 관리입니다. 크롤러는 납품으로 끝나는 소프트웨어가 아니라 대상 사이트와 함께 사는 소프트웨어입니다. 발주자라면 "개편 시 수리 범위와 비용"을 계약에 명시하고 개발자라면 수리가 싼 구조(안정 패턴, 단일 소스, 실패 격리)를 처음부터 지어야 합니다. 이 관점은 크롤링 외주 전 체크리스트에서 발주자 시각으로 정리해 두었습니다.
이 기법들이 적용된 실제 수집기는 야구 데이터 수집 자동화 사례에서 볼 수 있습니다.
자주 묻는 질문
셀렉터가 깨지지 않게 만들 수는 없나요?
없습니다. 대상 사이트의 변경은 통제 밖이기 때문입니다. 현실적인 목표는 깨짐의 빈도를 낮추고(안정 패턴에 걸기), 깨졌을 때 수리를 싸게 만들며(수리 지점 단일화), 깨진 순간을 빨리 아는 것(빈 결과를 실패로 처리)입니다.
자동 생성 클래스가 붙는 사이트는 어떻게 파싱하나요?
클래스 문자열 전체가 아니라 의미 있는 접두사나 패턴에 정규식으로 매칭합니다. 빌드마다 바뀌는 해시 부분을 매칭에서 제외하면 배포에도 살아남습니다. 그마저 불안정하면 화면 뒤의 데이터 응답(JSON)을 직접 쓰는 쪽을 검토하는 것이 낫습니다.
사이트 개편을 미리 알 방법은 없나요?
일반적으로는 없으므로 사후 감지를 설계합니다. 기대 요소가 없을 때 실패로 기록하고 수집량 급감을 모니터링하며 표시 수치의 표본 검증 절차를 갖추면 개편을 몇 시간 안에 인지할 수 있습니다. 감지가 빠르면 개편은 사고가 아니라 일상 유지보수가 됩니다.