- 자동 발행을 걸어뒀는데 며칠간 글이 한 편도 안 올라왔습니다
- 원인은 예약 작업이 작업할 컴퓨터에 접근할 권한 없이 만들어진 것이었습니다
- 진짜 문제는 실패가 아무 소리도 안 냈다는 점입니다 — 그래서 며칠을 몰랐습니다
자동화를 붙여두면 마음이 편해집니다. 정해진 시각에 알아서 돌아가니까요. 그런데 이번에 겪어보니, 그 편안함이 제일 위험한 부분이었습니다. 돌아가고 있다고 믿는 것과 실제로 돌아가는 것 사이를 확인하는 장치가 없으면, 멈춘 걸 알아채는 데 며칠이 걸립니다.
무슨 일이 있었나
블로그에 요일별 자동 발행을 걸어뒀습니다. 월요일은 코인 교실, 수요일은 시놀로지 기록, 금요일은 AI 용어 해설, 이런 식으로요. 매일 도는 개선 작업도 하나 있었고요. 설정한 날은 잘 돌았고, 그래서 그 뒤로는 신경을 안 썼습니다.
며칠 뒤에 블로그를 열어보니 새 글이 없었습니다. 처음엔 제가 날짜를 착각했나 싶었는데, 기록을 열어보니 예약 작업은 정확히 그 시각에 전부 실행돼 있었습니다. 실행 기록에 시각까지 남아 있었어요. 그런데 결과물이 하나도 없었습니다.
왜 아무것도 안 남았을까
원인은 단순했습니다. 이 블로그는 집에 있는 NAS에서 돌아가고, 글을 올리는 통로는 맥미니를 거쳐 NAS의 폴더에 작업 파일을 넣는 방식입니다. 그런데 예약 작업을 만들 때 그 컴퓨터에 접근하겠다는 선언을 빼먹었습니다.
그래서 작업은 시작은 됐는데, 폴더를 열려는 순간 권한이 없어 막혔습니다. 여기까지는 사실 정상 동작입니다. 권한 없는 접근을 막는 게 맞으니까요. 문제는 그다음입니다. 제가 작업 설명에 “컴퓨터에 접근할 수 없으면 아무것도 올리지 말라”고 적어뒀거든요. 잘못 올리는 것보다 안 올리는 게 낫다고 생각해서요.
그 지시는 지켜졌습니다. 작업은 조용히 종료됐습니다. 오류도 없고, 실패 표시도 없고, 알림도 없었습니다. 밖에서 보면 성공한 것과 구분이 안 되는 상태였습니다.
안전하게 실패하는 것만으로는 부족했다
이번 일에서 제일 크게 배운 건 이겁니다. 자동화를 만들 때 우리는 보통 두 가지를 신경 씁니다. 제대로 동작할 것, 그리고 잘못됐을 때 사고를 치지 말 것. 저도 딱 그 두 가지만 챙겼습니다. 그래서 접근이 막혔을 때 아무 짓도 안 하고 물러났고요.
실패를 알리지 않는 자동화는 아예 없는 편이 낫습니다.있다고 믿으니 확인을 안 했고, 멈춘 걸 며칠이나 몰랐습니다.
그런데 빠진 게 하나 더 있었습니다. 실패했다는 사실을 사람에게 알리는 것입니다. 조용히 실패하는 자동화는 안 만든 것보다 나쁩니다. 안 만들었으면 제가 직접 올렸을 텐데, 있다고 믿으니까 확인을 안 했으니까요.
생각해보면 이건 자동매매에서도 똑같이 겪었던 문제입니다. 봇이 죽어 있는데 계좌 잔고가 안 움직이면 “장이 조용하구나” 하고 넘어가게 됩니다. 움직임이 없는 것과 멈춘 것을 구분해주는 신호가 따로 있어야 합니다.
그래서 무엇을 바꿨나
네 가지를 손봤습니다. 순서에 의미가 있습니다.
- 맨 앞에 접근 확인을 뒀습니다. 작업이 시작하면 글부터 쓰는 게 아니라, 먼저 파일 폴더가 열리는지 확인합니다. 여기서 막히면 그 즉시 다음 단계로 넘어가지 않습니다.
- 실패하면 반드시 알리게 했습니다. 접근이 막히면 휴대폰으로 알림이 갑니다. “어디서 무엇 때문에 막혔는지”를 오류 원문과 함께 보내도록 문구까지 정해뒀습니다.
- 밖에서 보는 감시를 따로 만들었습니다. 매일 정오에 블로그를 그냥 방문자처럼 열어보고, 마지막 발행이 36시간을 넘겼거나 사이트맵이 안 갱신됐으면 알림을 보냅니다. 이 감시는 일부러 맥미니를 안 거칩니다. 감시 장치가 감시 대상과 같은 길을 쓰면 같이 죽으니까요.
- 워드프레스 쪽에도 복구 장치를 넣었습니다. 예약 시각이 지났는데 발행되지 않고 남아 있는 글이 있으면 자동으로 발행합니다. 워드프레스의 예약 발행은 방문자가 들어와야 도는 구조라, 트래픽이 적은 블로그에서는 조용히 밀리는 일이 흔합니다.
구조 자체도 바꿨습니다
알림만으로는 부족하다고 봤습니다. 지금 구조는 발행 시각에 맥미니가 깨어 있어야 글이 올라갑니다. 집 컴퓨터가 재부팅됐거나 앱이 꺼져 있으면 그날 글은 못 올라가는 거죠. 알림은 그걸 알려줄 뿐이지, 글을 대신 올려주지는 않습니다.
그래서 발행을 미리 앞당기기로 했습니다. 글을 여러 편 미리 써서 워드프레스에 예약 상태로 넣어둡니다. 그러면 발행 시각에는 워드프레스 혼자 알아서 글을 공개합니다. 맥미니가 꺼져 있어도, 클라우드 작업이 실패해도 글은 올라갑니다. 자동 작업은 이제 “발행하는 일”이 아니라 “예약을 채워두고 기존 글을 개선하는 일”을 맡습니다.
의존하는 게 하나 줄었습니다. 자동화에서 안정성은 대체로 이렇게 늘어납니다. 기능을 더 붙여서가 아니라, 실패했을 때 같이 죽는 것들의 개수를 줄여서요.
같은 걸 겪고 계시다면
NAS나 집 서버로 뭔가를 자동화하고 계시다면, 오늘 딱 하나만 확인해보시길 권합니다. 그게 멈췄을 때, 나는 며칠 안에 알 수 있는가? 답이 “확인해봐야 안다”이면 아직 감시가 없는 겁니다.
제일 간단한 방법은 결과물을 밖에서 보는 겁니다. 로그를 뒤지는 게 아니라, 사이트를 열어보고 “마지막으로 뭔가 일어난 게 언제인지” 한 숫자만 확인하는 거죠. 그 숫자가 어제·오늘이 아니면 뭔가 멈춘 겁니다. 안이 어떻게 돌아가는지 몰라도 판정이 됩니다.
- 작업 맨 앞에서 접근 가능 여부를 먼저 확인하고 막히면 멈춥니다.
- 실패하면 휴대폰 알림으로 어디서 왜 막혔는지 원문까지 보냅니다.
- 감시는 같은 길을 쓰지 않게 밖에서 사이트를 열어 확인합니다.
같이 보면 좋은 글
다음 편에서는 예약 글을 몇 주치 미리 채워두는 방식을 실제로 굴려보고, 그게 발행 리듬에 어떤 영향을 주는지 숫자로 남겨보겠습니다.
“가장의 디지털 영토 08. 자동화가 조용히 멈췄을 때 — 실패를 알아채는 장치부터 만들어야 하는 이유”에 대한 2개의 생각