자동화가 조용히 멈추는 이유: '없음'을 '성공'으로 처리하는 함정

문제 제기 · '실패가 없는데 결과도 없는' 날

정기적으로 도는 자동화 작업을 운영하다 보면 가장 무서운 상황은 오류가 터지는 날이 아닙니다. 오류는 비교적 눈에 띄기 쉽습니다. 로그에 흔적이 남고, 감시가 붙어 있다면 알림이 오기도 하고, 그때부터 사람이 원인을 추적할 실마리가 생깁니다. 진짜 위험한 건 아무 오류 없이 결과만 사라지는 날입니다.
실제로 글감을 골라 자동으로 글을 만들어 주던 작업에서 어느 날 한 편도 만들어지지 않은 일이 있었습니다. 그런데 로그에는 오류가 하나도 없었고, 오히려 '정상 통과'라고 찍혀 있었습니다. 원인은 글감을 고르는 목록(편성표)이 완전히 바닥났는데, 작업이 이를 '문제'가 아니라 '오늘은 만들 게 없어서 그냥 넘어감'으로 처리했기 때문입니다.
이 글은 그 경험을 일반화해, 재고·큐·목록을 소비하는 모든 자동화에서 '조용한 실패(silent failure)'를 어떻게 발견하고, 어떤 감시로 위험을 낮출 수 있는지 정리한 실전 가이드입니다.

---

왜 위험한가 · '없음'과 '고갈'이 같은 줄에 찍힌다

이 자동화에는 두 개의 저장소가 있었습니다. 사람이 순서를 정해 둔 편성표와, 아직 쓰지 않은 글감이 쌓인 창고입니다. 작업은 편성표만 보고 다음 글을 고릅니다.
문제가 생긴 날, 편성표의 글감은 25편에서 모두 소진됐습니다. 그런데 창고에는 아직 쓰지 않은 글감이 1,683개나 남아 있었습니다. 작업은 창고를 보지 않기 때문에, 편성표가 비면 '고를 게 없다'고 판단했습니다. 이때 남은 메시지는 이렇습니다.

미사용 블로그 소재 없음 → 오늘 자동 글 생성 통과

이 한 줄이 문제의 핵심입니다. '없음'과 '통과'가 같은 줄에 찍혀 있습니다. 사람이 로그를 훑으면 그날 일이 정상적으로 끝난 것처럼 보입니다. 실패가 실패로 보이지 않으니, 문제가 생긴 당일까지 아무도 눈치채지 못했습니다.
핵심 위험은 서로 다른 두 사건이 로그에서 똑같이 보인다는 것입니다. '오늘은 정상적으로 만들 게 없어서 넘어감'과 '재고가 바닥나서 못 만듦'은 완전히 다른 사건인데, 둘 다 '조용한 성공'처럼 기록됐습니다. 이런 상태에서는 상태 표시만 초록불이어도 실제로는 아무 결과가 안 나올 수 있습니다.

---

확인 절차 · 내 자동화가 '아무것도 안 한 날'을 어떻게 기록하는지 보기

당장 코드를 고치기 전에, 지금 돌아가는 작업이 '빈 결과'를 어떻게 남기는지부터 확인하는 게 순서입니다. 아래는 이번 사례에서 드러난 문제 지점을 바탕으로 정리한 독자용 일반 점검 절차입니다. 실제 사례에서 확인된 것은 편성표가 25편에서 소진됐다는 점, 창고에는 1,683개가 남아 있었다는 점, 그리고 기존 경고가 한 방향(참조 대상 없음)만 있었다는 점입니다. 이를 자기 환경에 맞게 확장해 다음 순서로 점검하세요.

1. 최근 실행 로그에서 '결과 0건'인 날을 찾는다. 생성 수, 처리 건수 같은 지표가 0인데도 상태가 '성공/통과'로 찍힌 날이 있는지 봅니다. 있다면 그게 바로 조용한 실패 후보입니다.
2. 그 0건이 정상인지 사고인지 로그만으로 구분되는지 확인한다. '오늘은 처리할 대상이 원래 없음'과 '있어야 할 대상이 사라짐'이 같은 메시지로 찍히면 위험 신호입니다.
3. 공급 쪽 잔량을 직접 조회한다. 편성표·큐·대기열에 남은 항목 수를 실제로 세어 봅니다. 위 사례처럼 편성표는 0인데 창고는 1,683개인 식으로, 소비하는 쪽과 채우는 쪽의 숫자가 어긋나 있는지 봅니다.
4. 감시 방향이 한쪽뿐인지 확인한다. 이 사례에서는 '편성표가 참조하는 글감이 창고에 없다'는 경고는 이미 있었지만, 반대인 '편성표 자체가 텅 비었다'는 경고는 없었습니다. 한 방향만 감시하면 반대편 사고를 놓칩니다.

환경마다 로그 형식과 저장소 구조가 다르므로, 자기 작업에 맞게 항목을 조정해 적용하세요.

---

원인 정리 · 공급과 소비가 둘 다 조용했다

원인은 두 지점이 겹친 데 있었습니다. 표로 정리하면 다음과 같습니다.

공급 쪽	편성표는 사람이 채우는 목록인데, 다 떨어져도 아무 신호가 없었다. 잔량 경보가 애초에 없었다.	목록 잔량이 임계치 아래로 내려갔을 때 알림이 오는지 테스트
소비 쪽	작업이 편성표에서 고를 게 없으면 '없음'을 돌려주고, 이를 실패가 아니라 '오늘은 통과'로 처리했다.	빈 결과일 때 종료 상태 코드/로그 레벨이 성공과 구분되는지 확인

재고가 떨어진 사건과, 재고를 못 찾은 사건은 성격이 전혀 다릅니다. 그런데 로그에서는 둘 다 조용한 성공처럼 보였습니다. 실패가 실패로 보이지 않으니 발견이 늦어질 수밖에 없었습니다.

---

체크리스트 · 재고를 소비하는 자동화라면 검토할 것

• 빈 결과와 정상 결과를 로그에서 구분한다. '오늘 처리 0건(정상)'과 '재고 고갈로 처리 불가'를 다른 메시지, 다른 로그 레벨로 남긴다.
• 사람이 채우는 목록에는 잔량 경보를 검토한다. 남은 항목이 임계치(예: 5편) 아래로 떨어지면 미리 알림이 오도록 한다. 바닥난 뒤가 아니라 바닥나기 전에 채울 시간을 벌기 위함이다.
• 두 방향을 모두 감시한다. '참조 대상이 없다'와 '목록 자체가 비었다'를 각각 경고로 잡는다. 한쪽만 보면 반대편 사고를 놓친다.
• '0건 성공'은 알림 대상에 포함을 검토한다. 결과가 0인데 성공으로 끝난 날은 최소한 요약 알림이라도 오게 한다.
• 재개 후 실제 결과물까지 눈으로 확인한다. 로그 통과만 믿지 말고, 실제로 산출물이 생성됐는지 끝단까지 확인한다.

다만 위 잔량 경보와 로그 구분은 이번 사례에서 아직 적용하지 않은 남은 과제입니다. '이렇게 하면 확실히 막힌다'가 검증된 것이 아니라, '이런 감시가 없어서 사고가 났다'가 확인된 항목이라는 점을 유념하세요.

---

적용 예시 · 멈춘 연재를 다시 돌린 순서

실제로 멈춘 작업을 재개할 때는 다음 순서로 처리했습니다. 다른 환경에서도 그대로 응용할 수 있습니다.

1. 공급을 즉시 채운다. 다른 개발 기록 중에서 다음 회차로 쓸 소재를 골랐습니다. 2026년 8월 5일 개발 기록의 '과거 데이터로 미리 돌려보기 미래참조 수정'을 26번째 화 소재로 정했습니다.
2. 목록에 항목을 추가한다. 26화 제목을 정해 편성표에 추가했습니다.
3. 끝단까지 실제 산출을 확인한다. 추가한 뒤 작업을 돌려 산출물이 실제로 나오는지 확인했습니다. 제공된 개발 기록에는 글 생성·계약검사 통과·블로그 임시저장까지 정상적으로 끝난 것이 확인됐다고 남아 있습니다. 다만 이 확인 결과가 편성한 26화에 직접 대응하는지는 원본 실행 기록에서 회차 표기를 대조해야 확정할 수 있어, 여기서는 기록에 남은 범위로만 서술합니다.

전후를 비교하면 다음과 같습니다.

편성표 상태	25편에서 소진	26화 추가로 재개
그날 산출	0편 (조용히 멈춤)	생성·계약검사·임시저장 확인(기록 기준)
로그 표시	'없음 → 통과' (성공처럼 보임)	실제 산출물로 확인

주의할 점은, 이번 조치는 공급을 채워 재개하는 데 집중했고 소비 쪽 코드는 손대지 않았다는 것입니다. 담당 영역이 달라 이번에 손댈 범위가 아니었기 때문입니다. 즉 급한 불은 껐지만 근본 원인(경보 부재, '없음=통과' 처리)은 별도 과제로 남았습니다.

---

잘못 두면 어떻게 되나 · 조용한 실패의 일반적 위험

이번 사례에서 확인된 사실은, 문제가 생긴 그날 당일까지 아무도 이를 알아채지 못했다는 것입니다. '없음 → 통과'가 성공처럼 보였기 때문입니다.
여기서 한 걸음 더 나아가, 원문에 기록되지 않은 일반적인 가상 위험 시나리오를 생각해 볼 수 있습니다. 만약 이런 상태에서 누구도 결과물을 직접 확인하지 않고 상태 표시만 신뢰한다면, 목록이 비어 있는 한 다음 실행에서도 같은 '없음 → 통과'가 반복될 수 있습니다. 이는 어디까지나 조용한 실패가 남아 있을 때 이론적으로 이어질 수 있는 상황이며, 실제 사례에서 며칠·몇 주간 반복됐다는 뜻은 아닙니다.
이것이 조용한 실패의 위험입니다. 눈에 보이는 오류는 대개 로그와 알림으로 드러나 대응 시점을 잡기 쉽지만, 조용한 실패는 '언제부터 멈췄는지'조차 사후에 로그를 되짚어야 알 수 있는 경우가 많습니다. 그래서 자동화를 운영한다면, 매일 돌아가는 작업이 '아무 일도 안 한 날'을 어떻게 기록하는지 확인하는 게 좋습니다. 아무 일도 안 한 것이 정상인지 사고인지, 로그만 보고 구분할 수 있어야 합니다.

---

한계와 주의사항

이 글의 수치와 절차는 특정 자동화 환경의 개발 기록에 근거합니다. 편성표 25편 소진·창고 1,683개 같은 숫자는 그 시점의 값이며, 여러분의 환경에서는 다릅니다. 임계치(예: 잔량 5편)도 소비 속도에 맞춰 직접 정해야 합니다.
또한 잔량 경보와 '없음/고갈' 로그 구분은 이 사례에서 아직 적용 전인 남은 과제입니다. 즉 '이렇게 하면 문제가 사라진다'가 검증된 것이 아니라, '이런 감시가 없으면 이런 사고가 난다'가 확인된 것입니다. 알림 도구를 붙일 때도 알림 자체가 실패하는 경우를 대비해, 알림 경로를 주기적으로 테스트하시길 권합니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.