자동화를 하나 걸어 두면 그날 일은 끝난 것처럼 느껴집니다. 저도 그랬습니다. 반복되는 일을 하나 떼어 내 예약 실행에 올리고 나면, 다음 날부터는 신경 쓰지 않아도 되는 일이 하나 늘어난 셈이니까요. 그런데 그 자동화가 조용히 멈추면 제가 어떻게 알게 되는지는 한 번도 생각해 본 적이 없었습니다.
제 작업 환경에는 매일 혹은 매주 저절로 도는 자동화가 49개 있습니다. 아침마다 뉴스레터 재료를 모으고, 카드뉴스 발행을 예약하고, 저장소를 정리하고, AI 도구 사용량을 집계하는 것들입니다. 하나씩 만들 때마다 뿌듯했습니다. 걸어 두면 끝이라고 생각했거든요.
그런데 8월 어느 날, 서로 다른 고장 네 건을 같은 날 발견했습니다. 그동안 알림은 한 건도 오지 않았고, 어디에도 오류는 기록되지 않았습니다.
같은 날 발견한 고장 네 건
첫째, 주간 사용량 보고서가 4주 동안 나오지 않았습니다. 그 4주 동안 저는 사용량이 늘고 있는지 줄고 있는지 모르는 채로 일했습니다. 예약 작업은 매주 제시간에 깨어났고 종료 코드도 0(문제없이 끝났다는 표시)이었습니다. 그런데 안에서는 “이전 실행이 아직 도는 중”이라며 스스로 건너뛰고 있었습니다. 한 달 전 비정상 종료된 실행이 남긴 잠금 파일(‘지금 실행 중’이라고 남겨 두는 표시) 하나가 원인이었습니다. 건너뛰기를 성공으로 기록했으니 어디에도 빨간불이 들지 않았습니다.
둘째, 한 달 전에 등록한 작업이 한 번도 돌지 않았습니다. 그 작업이 매달 정리해 주기로 한 자료, 가져다 쓰는 오픈소스들이 원본에서 얼마나 바뀌었는지를 저는 한 달 내내 손으로 찾고 있었습니다. 등록도 됐고 설정도 맞았는데 실행 기록이 0건이었습니다. 더 나빴던 건 제 점검 도구가 ‘실행 기록이 있는 작업’만 훑고 있었다는 점입니다. 한 번도 돌지 않은 작업은 점검 목록에조차 오르지 않았습니다. 없는 것을 세지 않으니 없는 줄도 몰랐던 거죠.
셋째, 2주 전에 잠깐 꺼 둔 작업이 그대로 꺼져 있었습니다. 문제가 생겨 멈춰 두고 “나중에 다시 켜자”고 생각했는데, 그 ‘나중’을 챙기는 사람도 장치도 없었습니다. 꺼 둔 기록만 남고 다시 켤 조건은 어디에도 적혀 있지 않았습니다. 그 2주치 결과물은 그냥 비었습니다.
넷째, 월요일 새벽에 도는 작업이 반복해서 빠졌습니다. 컴퓨터가 잠들어 있으면 그 시각의 실행을 건너뛰고, 깨어난 뒤에도 보충하지 않는 방식이었습니다. “시끄럽지 않게 새벽에 돌리자”는 제 정책이 오히려 가장 중요한 작업을 가장 자주 놓치게 했습니다.
네 건의 공통점은 ‘완료’를 센 시점이었습니다
원인은 네 가지로 달랐지만 공통점은 하나였습니다. 제가 자동화의 완료를 ‘등록한 순간’으로 세고 있었다는 점입니다. ‘첫 결과물을 눈으로 본 순간’이 아니었습니다.
넷째는 실행 시각의 문제였지만, 첫째부터 셋째까지는 어디서 돌리든 똑같이 생깁니다. 실행 장소의 문제가 아니라 ‘성공을 무엇으로 정의하느냐’의 문제이기 때문입니다.
정리해 보면 조용한 실패는 세 가지 형태였습니다. 성공으로 위장한 건너뛰기, 등록만 되고 한 번도 돌지 않은 작업, 꺼 두었는데 켤 사람이 없는 작업. 셋 다 로그를 열어도 보이지 않습니다. 로그는 ‘있었던 일’을 적는데, 이 셋은 ‘있어야 했는데 없었던 일’이기 때문입니다.
오류 알림으로는 이 고장을 잡을 수 없는 이유
처음 겪는 문제라고 생각했는데, 서비스 운영 쪽에서는 오래전부터 다뤄 온 문제였습니다.
구글이 정리한 서비스 운영(SRE) 감시 원칙에는 먼저 볼 신호 네 가지가 있습니다. 지연, 트래픽, 오류, 포화입니다. 이 원칙은 두 가지를 강조합니다. 하나는 원인이 아니라 증상에 알림을 걸라는 것입니다. 감시는 ‘무엇이 망가졌나’와 ‘왜 망가졌나’에 답해야 하는데, 사람을 깨우는 알림은 앞쪽인 증상에 걸고 원인은 조사할 때 쓰라는 거죠. 다른 하나는 사람을 호출하는 알림은 모두 사람이 조치할 수 있어야 한다는 것입니다. 기계적으로 대응해도 되는 일이면 호출하지 말라고까지 합니다. 알림 수를 줄여야 사람이 읽기 때문입니다.
그런데 제 고장 네 건은 이 네 신호 어디에도 걸리지 않습니다. 돌지 않은 작업은 느려지지도 않고 오류를 내지도 않습니다. 신호가 나쁜 게 아니라 신호 자체가 없는 상태입니다. 알림을 줄여 조용하게 만드는 것까지는 좋은데, 조용함에는 두 종류가 있습니다. 모든 게 잘 돌아서 조용한 것과, 아무것도 돌지 않아서 조용한 것이죠.
그래서 운영 쪽에서는 이 자리에 반대로 동작하는 장치를 둡니다. 데드맨 스위치(dead man's switch), 또는 하트비트 감시라고 부릅니다. 보통 알림은 뭔가 깨졌을 때 울리지만, 이 장치는 평소에 늘 신호를 보냅니다. 그 신호가 끊기는 순간을 고장으로 봅니다. 침묵을 실패로 뒤집는 장치입니다. 서버 감시에 널리 쓰이는 오픈소스 구성에도 이런 알림이 기본으로 들어 있습니다(참고 자료 2). 항상 울리도록 만들어 두고, 알림이 전달되는 경로 전체가 살아 있는지를 확인하는 데 씁니다.
이 원칙이 원래 서버 운영팀의 몫이었던 데는 이유가 있습니다. 자동화가 몇 개 안 될 때는 눈으로 다 보입니다. 아침에 결과물을 열어 보는 사람이 있고, 안 나왔으면 바로 압니다. 사람의 일과가 하트비트 역할을 해 준 셈입니다. 지금은 사정이 다릅니다. 각자 노트북에서 AI 에이전트와 예약 작업이 백그라운드로 돌아갑니다. 눈으로 다 보이던 방식이 개수 앞에서 무너지는 지점이 개인 작업 환경에도 온 것입니다.
그래서 이 원칙을 개인 환경으로 가져올 때 하나를 더해야 했습니다. 증상에 알림을 거는 것까지는 같지만, ‘결과물이 나오지 않은 것’도 증상으로 세야 합니다. 오류는 신호를 만들지만 미실행은 아무 신호도 만들지 않으니까요.
완료를 ‘첫 결과물을 본 순간’으로 바꿨습니다
지금은 자동화를 하나 만들어도 등록한 순간을 완료로 치지 않습니다. 다음 예정 실행까지 며칠 남았으면 손으로 한 번 미리 돌려 첫 결과물을 눈으로 확인합니다. 첫 실행이 관측된 시점이 완료입니다.
기능을 배포했다고 끝이 아니라 사용자가 실제로 화면을 열어 봐야 끝인 것과 같은 원리인데, 자동화에도 똑같이 적용되더라고요.
이 기준 하나를 세우고 나니 네 건이 각각 어디서 샜는지가 보였습니다. 없는 것을 세지 않았고, 꺼 둔 것을 다시 켤 조건이 없었고, 잠든 시간대에 중요한 작업을 두었습니다. 이걸 점검 도구와 운영 규칙으로 어떻게 옮겼는지는 환경마다 답이 달라 여기서 다 적지는 않겠습니다.
되돌린 결정: 새벽에 조용히 돌리자는 정책
넷째 고장은 순전히 제 정책 탓이었습니다. 낮에 방해받지 않으려고 중요한 작업을 새벽에 몰아 두었는데, 그 시간에 컴퓨터가 잠들어 있으면 실행이 그냥 사라졌습니다. 조용하게 만들려던 결정이 가장 자주 놓치는 결정이 된 셈입니다.
그래서 이 정책을 절반만 되돌렸습니다. 반드시 돌아야 하는 작업은 제가 깨어 있는 아침 시간대로 옮겼습니다. 새벽에는 놓치더라도 다음 날 보충되면 괜찮은 작업만 남겼습니다. 새벽 실행 자체를 버리지는 않았습니다. 작업의 성격을 보지 않고 시간대만 정한 게 문제였지, 시간대가 문제는 아니었으니까요.
컴퓨터가 잠들어 있어도 정해진 시각에 도는 클라우드 예약 실행으로 옮기면 이 넷째 문제는 구조적으로 사라집니다. 다만 첫째부터 셋째까지는 거기서도 똑같이 생깁니다.
아직 못 잡는 것: 돌긴 돌았는데 비어 있는 결과물
지금 방식으로도 보이지 않는 고장이 남아 있습니다. 결과물은 제시간에 나왔는데 내용이 비어 있는 경우입니다. 파일이 생겼고 종료 코드도 0이라 살아 있는 것처럼 보입니다. 그런데 열어 보면 안이 비어 있습니다.
이건 ‘돌았나’가 아니라 ‘쓸 만한 게 나왔나’를 물어야 잡히는데, 그 질문은 자동으로 묻기가 어렵습니다. 아직 답을 찾지 못했습니다.
마치며: ‘돌고 있나’가 아니라 ‘멈추면 어떻게 알게 되나’
자동화를 늘릴수록 어려운 일은 ‘만들기’에서 ‘살아 있는지 알기’로 옮겨 갑니다. 몇 개일 때는 눈으로 다 보였는데, 지금 49개가 돌고 있는 제 환경에서는 조용히 멈춘 것과 조용히 잘 도는 것이 화면에서 구별되지 않습니다.
자동화를 늘릴수록 어려운 일은 ‘만들기’에서 ‘살아 있는지 알기’로 옮겨 갑니다.
그래서 자동화를 하나 걸 때마다 질문을 바꿨습니다. “이게 돌고 있나”가 아니라 “이게 멈추면 나는 어떻게 알게 되나”로요. 답이 “로그를 열어 보면”이라면 아직 완료가 아닙니다. 로그는 있었던 일만 적으니까요.
지금 걸어 둔 자동화 목록이 있다면 세 가지만 세어 보시길 권합니다. 마지막 결과물을 최근에 눈으로 확인한 작업이 몇 개인지, 등록한 뒤 결과물을 한 번도 본 적 없는 작업이 몇 개인지, 꺼 두었는데 다시 켤 조건이 적혀 있지 않은 작업이 몇 개인지. 저는 세는 데 20분이 걸렸고, 둘째가 가장 많았습니다.
이 글은 AI의 도움을 받아 작성했습니다.
참고 자료
- Google SRE Book, “Monitoring Distributed Systems” (네 가지 신호, 증상 기반 알림): https://sre.google/sre-book/monitoring-distributed-systems/
- kube-prometheus, Watchdog 알림 규칙 (항상 울리도록 만든 알림으로 알림 경로 전체가 동작하는지 확인): https://github.com/prometheus-operator/kube-prometheus/blob/main/manifests/kubePrometheus-prometheusRule.yaml
- 자동화 49개, 고장 4건, 점검 20분: 필자 운영 환경 자체 실측 (2026-08-21 발견, 2026-09-06 기준). 환경마다 다를 수 있습니다.