사라진 크롤 점검을 기록하고 실제 누락을 구분하기

크롤러 점검이 끝나지 않았는데 아무 기록 없이 사라지면, 대시보드에는 오래전에 내린 정상 판정이 계속 남을 수 있어요. 이 글에서는 시간 초과된 점검을 기록하고, 크롤 실패 행에 커버리지 감사 결과를 연결한 변경을 다뤄요.

배포 후 장애 대응 시간이나 누락 감소율은 따로 측정하지 않았어요. 여기서는 무엇을 관측할 수 있게 됐는지에 초점을 맞출게요.

응답하지 않은 점검은 실패로도 남지 않았다

대시보드는 하루에 한 번 워커에 각 학교 사이트의 프록시 연결과 직접 연결을 확인해 달라고 요청하고, 결과를 도메인 점검 결과 저장소에 기록해요. 문제는 두 핑이 제한 시간 안에 끝나지 않을 때 생겼어요.

대시보드의 자동 점검 코드는 5초 간격으로 최대 60회 상태를 확인했어요. 설정상 최대 대기 시간은 60회 × 5초 = 300초, 즉 5분이에요. 그동안 두 핑이 모두 끝나지 않으면 null을 반환하고 호출부도 그대로 종료됐어요.

const result = await checkConnections(domain);
if (!result) return;
// 점검 결과 upsert

이렇게 일찍 종료되면 “결과를 확인하지 못했다”는 사실조차 기록에 남지 않았어요. 이전 판정과 확인 시각은 그대로였고, 다음 화면에서는 오래된 정상 판정이 현재 상태처럼 보였어요.

운영 DB에서 관찰한 결과를 보면 이 문제가 더 구체적으로 드러나요.

이 표가 뒷받침하는 주장은 “정상 판정이 틀렸다”보다는 조금 더 정확해요. 새로운 판정을 내리지 못한 회차가 기록되지 않아 오래된 정상 판정이 기한 없이 유지됐다는 뜻이에요.

타임아웃을 장애 판정이 아니라 관측 결과로 저장했다

대기 시간을 늘리는 것만으로는 해결되지 않아요. 5분을 10분으로 늘려도 10분 뒤 아무 기록 없이 끝난다면 같은 문제가 반복되니까요. 성공 여부와 관계없이 점검한 회차가 있었다는 사실을 남겨야 했어요.

변경 후에는 제한 시간 안에 두 핑을 모두 확인하지 못하면 도메인 점검 결과 저장소에 ‘점검 시간 초과’를 기록해요.

const result = await checkConnections(domain);
if (!result) {
// 점검 결과 저장소에 시간 초과 기록
return;
}
// 확인한 결과를 점검 결과 저장소에 기록

여기서 ‘점검 시간 초과’는 “이 도메인이 차단됐다”는 판정이 아니에요. 프록시 또는 직접 연결 점검이 제한 시간 안에 끝나지 않아 이번 회차의 상태를 확인하지 못했다는 기록이에요. 시간 초과를 곧바로 차단으로 판단하면 느린 응답, 워커 이상, 일시적인 네트워크 문제까지 모두 같은 원인으로 묶일 수 있어요.

이제 대시보드에서 최소한 세 가지 상태를 구분해 보여 줄 수 있어요.

• 확인했고 접근할 수 있었다.
• 확인했고 접근 문제를 발견했다.
• 점검을 시도했지만 제한 시간 안에 확인하지 못했다.

운영할 때는 세 번째 상태가 중요해요. 오래된 정상 판정을 믿어도 되는지 판단할 근거가 생기니까요.

다만 변경 설명만으로는 모든 점검 회차를 별도 이벤트로 쌓는 불변 이력까지 도입했는지 알 수 없어요. 기존 upsert 구조에서 과거 회차가 어느 범위까지 보존되는지는 추가로 검증해야 해요.

크롤 실패와 데이터 누락은 같은 사실이 아니다

점검 회차를 기록해도 다른 문제는 남아요. 크롤 작업이 실패했다는 기록만으로 실제 게시글이 빠졌다고 단정할 수는 없어요.

실패 작업 기록은 게시판 단위 작업이 실패했다는 뜻이에요. 글 식별자는 없고, 저장된 URL도 개별 게시글 주소가 아니라 다음과 같은 목록 주소예요.

.../board/list?boardId=...

이 정보만으로는 어느 글이 빠졌는지, 누락이 실제로 있었는지 판단하기 어려워요. 게시판 재시도에서 정상적으로 수집됐을 수도 있고, 실패 당시 새 글이 없었을 수도 있어요.

최근 24시간 동안 “조치 필요”로 분류된 실패 게시판 수십 곳을 커버리지 감사 결과와 대조한 운영 관찰이 있어요. 감사 결과가 연결된 십여 곳에서는 누락과 미발행이 모두 0건이었어요. 화면에는 모두 실패로 표시됐지만, 적어도 해당 감사 기준에서는 데이터 손실이 관찰되지 않은 셈이에요.

반대 사례도 있었어요. 환경 문제로 분류돼 기존 조치 대상에서 빠졌던 페이지 탐색 시간 초과 계열 가운데, 실제 글 누락이 확인된 게시판이 십여 곳이었어요. 실패 유형의 심각도와 데이터 손실 여부가 꼭 일치하지는 않는다는 증거예요.

이미 있던 커버리지 감사를 실패 행에 연결했다

실제 누락 여부를 확인할 데이터를 새로 만들 필요는 없었어요. 별도로 실행되던 커버리지 감사가 매일 학교 사이트의 게시글 목록을 열어 글 번호를 추출하고, 이를 운영 DB에 저장된 게시글과 비교해 게시판별 누락과 미발행을 기록하고 있었거든요.

문제는 실패 목록과 감사 결과가 다른 화면에 있다는 점이었어요. 운영자는 실패 행을 발견하면 게시판을 식별하고 감사 화면으로 옮겨 가 같은 대상을 다시 찾아야 했어요. 변경 후에는 실패 행에서 두 데이터를 함께 볼 수 있어요.

이 표는 이번 변경에서 새로 정의한 판정 규칙이라기보다, 두 신호를 한곳에서 볼 때 어떻게 해석할 수 있는지 정리한 것이에요. 특히 감사 결과가 없다고 누락을 0건으로 취급해서는 안 돼요. 확인하지 못한 값을 0으로 표시하면 ‘점검 시간 초과’를 도입하기 전과 같은 관측 공백이 다시 생겨요.

실행 실패는 원인에 가까운 신호이고, 누락·미발행은 사용자에게 영향을 줄 수 있는 결과에 가까운 신호예요. 페이지 탐색 시간 초과가 반복돼도 커버리지 감사에서 누락이 없다면 네트워크나 워커 상태를 조사하면서 데이터 복구는 뒤로 미룰 수 있어요. 반대로 기존 분류에서는 단순한 환경 문제로 보여도 누락이 확인됐다면 수집 복구를 먼저 처리해야 해요.

남은 한계와 검증할 것

‘점검 시간 초과’만으로는 프록시 차단인지, 직접 연결이 느린 건지, 워커 장애인지 구분할 수 없어요. 원인을 분석하려면 두 핑 중 어느 쪽이 완료됐는지, 마지막 상태는 무엇이었는지 같은 정보가 더 필요할 수 있어요.

커버리지 감사 결과에도 시간차가 있어요. 감사가 하루에 한 번 실행된다면 방금 발생한 실패의 영향은 다음 감사 전까지 확인할 수 없어요. 이 데이터는 실시간 무결성을 보장하지 않고, 감사 시점에 대조한 결과를 보여 줘요.

모든 시스템에 같은 구조가 필요한 것은 아니에요. 누락을 나중에 쉽게 복구할 수 있고 데이터 최신성이 중요하지 않은 크롤러라면 감사 데이터를 연결하는 비용이 더 클 수 있어요. 반면 게시글 누락이 사용자 경험에 직접 영향을 주거나 여러 실패 유형이 같은 화면에 뒤섞인다면, 실행 상태와 커버리지를 나눠 기록할 가치가 커요.

같은 문제를 재현하려면 프록시·직접 핑 중 하나 이상이 60회의 폴링 동안 끝나지 않도록 만들면 돼요. 5초 간격 설정을 그대로 쓰면 명목상 300초가 걸리니, 테스트에서는 시계와 핑 응답을 대체해 기다리지 않고 검증하는 편이 나아요.

최소한 다음 항목은 확인해야 해요.

• 두 핑이 제한 시간 안에 끝나지 않으면 도메인 점검 결과 저장소에 ‘점검 시간 초과’와 해당 점검 시각이 반영되는가.
• 직전 값이 정상이어도 타임아웃 이후 화면에 오래된 정상 판정만 노출되지 않는가.
• 같은 도메인 점검이 중복 실행되거나 프로세스가 재시작돼도 의도하지 않은 중복 행이 생기지 않는가.
• 실패 게시판에 대응하는 감사 데이터가 있으면 누락·미발행 수치가 같은 행에 표시되는가.
• 감사 결과가 없을 때 이를 0건이 아닌 미확인 상태로 구분하는가.
• 실패 후 재시도에 성공했을 때 작업 실패, 최신 점검 상태, 감사 결과 중 무엇을 유지하고 무엇을 갱신하는가.

제시된 근거는 시간 초과를 기록하고 감사 결과를 연결해야 하는 이유를 설명해 줘요. 다만 중복 실행, 프로세스 재시작, 감사 데이터 지연까지 아우르는 전체 검증 결과는 없어요. 후속 테스트에서 이 항목들을 확인하고, ‘점검 시간 초과’ 이후 실제 차단으로 판명된 비율과 실패 유형별 누락 동반 비율, 감사 결과가 없는 행의 비중을 일정 기간 측정해 볼 수 있어요.