여러 사이트를 도는 크롤러를 운영해 보면 한 가지를 곧 받아들이게 됩니다. 어느 사이트든 언젠가는 깨진다는 것입니다. 화면 구조가 바뀌고 잠깐 접속이 막히고 응답 형식이 달라집니다. 문제는 한 곳이 깨졌을 때 나머지까지 함께 멈추느냐입니다. 법률 게시판을 통합 수집하는 이 프로젝트는 "한 곳의 장애는 그 한 곳에만 머문다"를 원칙으로 삼았습니다.
게시판별로 실행을 가둔다
통합 수집이라고 해서 모든 게시판을 한 덩어리로 실행하면, 한 곳에서 터진 예외가 전체를 멈춥니다. 그래서 오케스트레이터는 게시판을 하나씩 독립적으로 실행하고 각 실행을 예외 처리로 감쌌습니다. 한 게시판 수집기가 오류를 던지면 그 게시판만 실패로 기록하고 오케스트레이터는 다음 게시판으로 넘어갑니다.
이 격리 덕분에 통합 수집이 "모 아니면 도"가 되지 않습니다. 오늘 한 게시판의 화면이 개편되어 파싱이 깨져도, 나머지 게시판의 수집은 평소대로 끝납니다. 실패한 게시판은 다음 실행에서 다시 시도되거나, 개편에 맞춰 그 수집기만 손보면 됩니다. 한 곳의 문제가 전체 데이터의 공백으로 번지지 않는 것이 핵심입니다.
실행마다 이력을 남긴다
무인으로 도는 시스템에서 가장 곤란한 상황은 "언제부터 안 되고 있었는지 모르는" 것입니다. 그래서 실행할 때마다 감사 기록을 남기게 했습니다. 어느 게시판을, 언제 시작해, 언제 끝냈고, 성공인지 실패인지, 질문을 몇 건 모았고 키워드를 몇 개 뽑았는지가 실행 단위로 기록됩니다. 실패한 경우에는 오류 메시지도 함께 남습니다.
이 이력이 있으면 운영이 눈으로 보입니다. 어느 게시판이 최근 계속 실패하는지, 특정 게시판의 수집량이 갑자기 줄지는 않았는지가 기록만 봐도 드러납니다. 자동화 시스템은 문제가 조용히 쌓이기 쉬운데, 실행 이력은 그 침묵을 깨는 최소한의 장치입니다.
일시적인 실패는 다시 시도한다
실패에도 종류가 있습니다. 화면 구조가 바뀐 것처럼 손봐야 하는 실패가 있고 잠깐의 네트워크 오류처럼 다시 하면 되는 실패가 있습니다. 후자를 곧바로 실패로 처리하면 멀쩡한 수집을 놓치게 됩니다. 그래서 일시적인 오류에는 간격을 늘려 가며 몇 차례 재시도를 두었습니다. 처음엔 짧게, 실패가 이어지면 더 길게 기다렸다 다시 시도하는 방식입니다.
간격을 점점 늘리는 것은 상대 서버를 위한 배려이기도 합니다. 실패한 요청을 곧바로 몰아치면 이미 부담을 겪는 서버를 더 밀어붙이게 됩니다. 재시도까지 소진하고도 안 되면 그때 그 게시판만 실패로 남기고 개별 페이지 하나가 실패하는 정도는 조용히 건너뛰어 수집 전체를 흔들지 않습니다.
격리와 기록이 만드는 운영감
이 세 가지, 게시판별 격리와 실행 이력과 재시도가 합쳐지면 운영의 성격이 바뀝니다. 무언가 깨져도 전체가 멈추지 않고, 무엇이 왜 깨졌는지 기록으로 남으며, 잠깐의 오류는 스스로 회복합니다. 사람이 상주하지 않아도 매일 도는 시스템이 되려면 이 정도의 안전장치가 바탕에 깔려야 합니다. 게시판마다 다른 접근을 하나로 다루는 인터페이스 설계는 법률 Q&A 크롤러 아키텍처에서, 매일 새 글만 걷는 수집 흐름은 매일 새 글만 걷어 오는 증분 수집 설계에서 이어집니다.
자주 묻는 질문
한 게시판이 실패하면 그날 데이터는 못 쓰나요?
아니요. 게시판별로 실행이 분리되어 있어 실패한 게시판만 그날 비고 나머지 게시판의 수집은 정상적으로 끝납니다. 실패한 게시판은 다음 실행에서 다시 시도되므로, 한 번의 실패가 데이터 전체의 공백으로 이어지지 않습니다.
실패를 어떻게 알아채나요?
실행마다 남는 감사 기록에 성공과 실패, 오류 메시지, 수집량이 함께 저장됩니다. 어느 게시판이 언제부터 실패하는지, 수집량이 줄지는 않았는지가 기록으로 드러나므로, 문제가 조용히 쌓이기 전에 확인할 수 있습니다.
재시도를 몇 번이나 하나요?
일시적인 오류에 한해 간격을 늘려 가며 몇 차례 시도하고 그래도 안 되면 그 게시판만 실패로 남깁니다. 화면 구조 변경처럼 다시 해도 안 되는 실패는 재시도로 해결되지 않으므로, 감사 기록을 보고 해당 수집기를 손보는 방식으로 대응합니다.
이 안정성 설계가 속한 전체 시스템은 법률 상담 게시판 통합 수집 자동화에서 볼 수 있습니다.