매일 같은 정보를 가져오기 — 깨질 것을 전제로

매일 같은 페이지를 열어보는 일

경쟁사 가격, 입찰 공고, 환율, 재고 현황, 규제 공지. 매일 같은 페이지를 열어 같은 부분을 확인하는 일은 자동화 요구가 가장 자주 나오는 영역입니다.

그리고 가장 자주 깨지는 자동화이기도 합니다. 이 글은 되게 만드는 법보다 깨지는 걸 전제로 설계하는 법에 관한 것입니다.

가장 먼저 확인할 것은 스크래핑이 필요한지 여부입니다.

1. 공개 API가 있는가. 있으면 무조건 API입니다. 안정적이고, 구조가 보장되고, 차단당하지 않습니다.

2. RSS나 공식 데이터 파일이 있는가. 공공기관 데이터는 상당수가 파일로 제공됩니다. 페이지를 긁는 것보다 훨씬 안정적입니다.

3. 그래도 없으면 그때 스크래핑을 검토합니다.

이 순서를 건너뛰고 바로 스크래핑부터 시작하는 경우가 많습니다. API가 있는데 페이지를 긁고 있는 자동화는 불필요하게 깨지는 자동화입니다.

스크래핑은 기술 문제이기 전에 허용 여부의 문제입니다.

약관이 금지하는 곳은 긁지 않습니다. 기술적으로 가능한 것과 해도 되는 것은 다르고, 이건 사업 리스크입니다. 공식 채널로 데이터 제공을 요청하는 편이 결국 빠른 경우도 많습니다.

접근 빈도도 문제입니다. 하루 한 번이면 충분한 데이터를 1분마다 요청하면 상대 서버에 부담을 주고 차단당합니다. 필요한 최소 빈도로 설정하세요.

스크래핑은 반드시 깨집니다. 상대가 페이지를 바꾸면 끝입니다. 그래서 깨졌을 때 어떻게 되는지가 설계의 중심입니다.

깨진 걸 알아야 합니다. 앞선 관측 글에서 다룬 그대로입니다. 가장 위험한 실패는 오류가 아니라 빈 결과를 정상으로 처리하는 것입니다.

최소한 이 검증을 넣으세요.

"0건을 성공적으로 수집했습니다"가 며칠 반복되는 것이 이 영역의 대표적 사고입니다.

과거 데이터를 덮어쓰지 않습니다. 매번 새로 저장하고, 이전 값을 남깁니다. 잘못 수집된 데이터로 정상 데이터를 지우면 복구가 안 됩니다.

원본을 보관합니다. 파싱한 결과만 저장하지 말고 원본 응답도 남기세요. 나중에 파싱 규칙을 고쳤을 때 과거 데이터를 다시 만들 수 있습니다.

구조가 아니라 의미로 찾습니다. 특정 위치의 세 번째 div를 지정하면 레이아웃이 조금만 바뀌어도 깨집니다. 가능하면 안정적인 식별자나 텍스트 라벨을 기준으로 찾습니다.

여러 후보를 시도합니다. 첫 번째 방법이 실패하면 대체 방법을 시도하고, 그것도 실패하면 실패로 기록합니다.

모델로 파싱하는 것의 함정. 페이지 전체를 모델에 던져 원하는 값을 뽑는 방식은 레이아웃 변화에 강합니다. 대신 비용이 들고, 느리고, 매번 다른 답을 낼 수 있습니다. 값이 조용히 달라지는 게 파싱 실패보다 위험한 경우가 많습니다.

절충안: 규칙 기반 파싱을 기본으로 하고, 실패했을 때만 모델을 부르고, 모델이 뽑은 값에는 "확인 필요" 표시를 답니다.

수집만 자동화하고 끝내면 데이터가 쌓이기만 합니다. 실제로 유용해지는 건 그다음입니다.

알림 피로가 이 자동화를 죽이는 가장 흔한 원인입니다. 매일 오는 알림은 2주 뒤 아무도 안 봅니다.