예약 작업 모니터링 체크리스트: 실행보다 공개 결과가 먼저

현재 Builderlog에는 발행, 큐 관리, 통계, Threads 배포, 프롬프트 모니터링을 담당하는 예약 작업 5개가 연결돼 있어요. 스케줄러에 5개가 보인다는 건 설정이 존재한다는 뜻이지, 실제 결과가 나왔다는 증거는 아니에요.

상태 화면은 첫 번째 확인일 뿐이에요

예약 작업은 로드된 상태에서도 마지막 실행이 실패했을 수 있어요. 입력 큐가 비었거나, 생성된 페이지가 공개 사이트에 배포되지 않았을 수도 있고요. “작업이 등록돼 있나?”만 보면 이 상태들이 모두 정상처럼 보여요.

그래서 작업마다 아래 네 가지 증거를 연결해 확인해요.

1. 의도한 요일과 시각으로 작업이 로드돼 있는지
2. 가장 최근 로그가 과거 성공이 아니라 이번 실행 결과인지
3. 큐·파일·통계 시각처럼 바뀌어야 할 상태가 실제로 바뀌었는지
4. 독자가 보게 될 공개 URL에 결과가 나타났는지

로드는 설정이고, 정상은 결과가 확인된 상태예요.

발행 작업은 이렇게 증명해요

Builderlog의 주 발행 작업은 평일에 실행돼요. 로그에는 영문·국문 파일 생성, 사이트 빌드, 배포, dev.to 교차 발행 과정이 남아요. 하지만 로그의 성공 문구만으로는 충분하지 않아요.

이번 감사에서는 최신 회차 파일이 존재했고 배포 로그가 성공을 기록했으며, 번호가 포함된 공개 URL이 HTTP 200으로 열리는 것까지 확인했어요. 그 뒤 큐에는 아직 사용하지 않은 주제 5개가 남아 있었어요.

이 조합이어야 “주제 하나가 소비됐고, 공개 글 하나가 생겼으며, 다음 발행 재료도 남았다”고 말할 수 있어요.

배포 로그는 성공인데 번호가 붙은 URL이 404라면 실패예요. 페이지는 열리지만 큐가 이동하지 않았다면 다음 실행에서 같은 주제를 다시 발행할 수 있어요. 둘은 서로 다른 문제라서 따로 확인해야 해요.

나머지 작업은 증거가 서로 달라요

큐 관리 작업은 파일을 다시 썼는지가 아니라 실제 미사용 주제가 남았는지로 판단해요. 통계 작업은 파일 존재 여부보다 집계 날짜가 최신인지가 중요해요. Threads 작업은 배포 결과 기록이 있어야 하고, 프롬프트 모니터는 원천 데이터와 갱신 시각이 바뀌었는지를 봐야 해요.

작업마다 계약이 다르기 때문에 “종료 코드가 0이다”라는 검사 하나로 전체를 정상 판정할 수 없어요.

자동화를 만드는 일보다 유지하는 일이 덜 화려한 이유도 여기에 있어요. 각 작업에 대해 “무엇을 바꿔야 하는가”와 “그 변화가 실제로 유효했다는 외부 증거는 무엇인가”를 정해야 하거든요.

실제로 쓰는 감사 표

공개 결과를 마지막에 확인하는 이유는 독자의 경험과 가장 가깝기 때문이에요. 내부에서 성공했다고 적혀 있어도 공개 결과가 없으면 아직 성공이 아니에요.

앞으로 자동화를 추가하는 기준

이제 Builderlog에 새 작업을 붙일 때는 스케줄과 스크립트만 만들지 않아요. 결과 계약, 최신 로그, 공개 또는 상태 검증 단계가 함께 있어야 완료로 봐요.

이 기준은 오래된 성공 로그가 멈춘 파이프라인을 정상처럼 보이게 만드는 문제도 막아줘요. 최신 시각과 최신 결과물을 함께 보면 성공, 스킵, 실패를 서로 다른 상태로 유지할 수 있어요.

쓸모 있는 자동화는 실행된 자동화가 아니라, 결과를 증명할 수 있는 자동화예요.