
들어가며 · 왜 그날은 한 편도 안 나왔나

글감을 골라 자동으로 글을 만들어 주는 작업이 있었습니다. 어느 날 확인해 보니 그날은 아무것도 만들어지지 않았습니다. 그런데 이상한 건 오류나 실패 표시가 하나도 없었다는 점입니다. 기록에는 오히려 '정상 통과'라고 찍혀 있었습니다.
결론부터 말하면, 글감을 골라 쓰는 목록이 완전히 바닥났는데도 작업이 이를 '문제'가 아니라 '오늘은 만들 게 없어서 그냥 넘어감'으로 처리했기 때문입니다. 이 글은 그 문제를 어떻게 발견했고, 재고가 떨어지는 자동화에서 무엇을 반드시 챙겨야 하는지 정리한 기록입니다.
무엇을 확인했나

이 자동화에는 사람이 직접 골라 순서를 정해 둔 '편성표'가 있고, 그와 별도로 아직 쓰지 않은 글감이 쌓여 있는 '창고'가 있습니다. 작업은 편성표를 보고 다음에 만들 글을 고릅니다.
문제가 생긴 날, 편성표에 담긴 글감은 25편에서 모두 소진된 상태였습니다. 그런데 창고에는 아직 쓰지 않은 글감이 1,683개나 남아 있었습니다. 작업은 창고가 아니라 편성표만 보기 때문에, 편성표가 비면 '고를 게 없다'고 판단합니다.
이때 작업이 남긴 메시지는 다음과 같았습니다.
미사용 블로그 소재 없음 → 오늘 자동 글 생성 통과보시다시피 '없음'과 '통과'가 한 줄에 같이 찍혀 있습니다. 사람이 로그를 훑어보면 그날 일이 정상적으로 끝난 것처럼 보입니다. 그래서 문제가 있었던 날 당일까지 아무도 눈치채지 못했습니다.
원인 · '없음'을 '정상'으로 처리한 것
원인은 두 가지가 겹친 데 있습니다.
| 공급 쪽 | 편성표는 사람이 채우는 목록인데, 다 떨어져도 아무 신호가 없다. 바닥났다는 경보가 애초에 없었다. |
| 소비 쪽 | 작업이 편성표에서 고를 게 없으면 '없음'을 돌려주고, 이를 실패가 아니라 '오늘은 통과'로 처리했다. |
즉 재고가 떨어진 사건과, 재고를 못 찾은 사건은 성격이 전혀 다른데도, 로그에서는 둘 다 조용한 성공처럼 보였습니다. 실패가 실패로 보이지 않으니 발견이 늦어질 수밖에 없었습니다.
참고로 수집 단계에는 '편성표가 참조하는 글감이 창고에 없다'는 경고는 이미 있었습니다. 하지만 그 반대인 '편성표 자체가 텅 비었다'는 경고는 없었습니다. 한쪽 방향만 감시하고 있었던 셈입니다.
어떻게 재개했나
당장 급한 일은 멈춘 연재를 다시 돌리는 것이었습니다. 다음 순서로 처리했습니다.
- 다른 개발 기록 중에서 다음 회차로 쓸 소재를 골랐습니다. 2026년 8월 5일에 남긴 개발 기록의 '과거 데이터로 미리 돌려보기 미래참조 수정'을 26번째 화 소재로 정했습니다.
- 26화 제목을 "과거 데이터로 미리 돌려보기가 미래를 훔쳐보고 있었다"로 정해 편성표에 추가했습니다.
- 추가한 뒤 작업을 돌려 실제로 글이 만들어지는지 확인했습니다. 글 생성, 계약검사 통과, 블로그 임시저장까지 정상적으로 끝나는 것을 눈으로 확인했습니다.
이번 조치는 편성표를 채워 연재를 재개하는 데 집중했고, 실제로 글을 만드는 쪽의 코드는 손대지 않았습니다. 편성표를 채우는 일은 담당 영역이 따로 있어서, 이번에 손댈 범위가 아니었기 때문입니다. 다만 편성 소진을 미리 알리는 경보가 없었던 점, 소비 쪽이 '없음'을 '정상 통과'로 처리한 점은 이번에 함께 드러난 별도의 과제로 남습니다.
전후 비교
| 편성표 상태 | 25편에서 소진 | 26화 추가로 재개 |
| 그날 글 생성 | 0편 (조용히 멈춤) | 생성·계약검사·임시저장 확인 |
| 로그 표시 | '없음 → 통과' (성공처럼 보임) | — |
이번 조치로 멈췄던 연재는 26화를 편성해 다시 돌아갔습니다.
배운 점 · 조용히 멈추는 목록에는 경보가 있어야 한다
이번 일에서 얻은 교훈은 세 가지입니다.
- 바닥나면 조용히 멈추는 목록은 잔량 경보가 필요하다. 사람이 채우는 목록일수록 '얼마 안 남았다'는 알림이 있어야 늦기 전에 채울 수 있습니다.
- '재고가 떨어진 것'과 '재고를 못 찾는 것'은 다른 사고다. 한쪽만 감시하면 반대편에서 사고가 나도 모릅니다.
- '없음 = 정상 통과'로 처리하면 고갈이 성공처럼 보인다. 정상적으로 넘어간 메시지와 뭔가 떨어져서 못 한 메시지는 확실히 구분해서 남겨야 합니다.
자동화를 운영하는 분이라면, 매일 돌아가는 작업이 '아무 일도 안 한 날'을 어떻게 기록하는지 한 번 확인해 보시길 권합니다. 아무 일도 안 한 것이 정상인지 사고인지, 로그만 보고 구분할 수 있어야 합니다.
남은 과제
이번에는 26화를 편성해 급한 불을 껐습니다. 이번 일을 통해 편성표 잔량이 일정 수준 아래로 떨어졌을 때 미리 알려 주는 경보가 필요하다는 점, 그리고 '없음'과 '고갈'을 로그에서 구분해 찍는 일이 필요하다는 점을 확인했습니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
'EP 빌드로그' 카테고리의 다른 글
| EP.39 맥 자동 예약작업이 3주간 안 돌았던 이유: 파일은 있는데 서비스가 멈춰 있었다 (0) | 2026.08.19 |
|---|---|
| EP.38 AI 유튜브 채널 첫 3편 조회수 66배 차이, 무엇이 갈랐나 (0) | 2026.08.18 |
| EP.37 git push 검토 훅이 잘못된 폴더를 검사하던 버그, cd 명령 추적으로 해결한 기록 (0) | 2026.08.17 |
| EP.36 쇼츠 자막이 '움직이는 글자'로 바뀐 이유 — 정지 배경의 함정 EP.리팩터 (0) | 2026.08.16 |
| EP.35 매수할 때와 팔 때 정보를 한 줄로 잇기: 자동매매 기록 개선기 P0-C (0) | 2026.08.15 |