자동 발행 루틴을 만들다 깨진 것 4가지 — 조용히 실패하는 자동화의 공통점

자동화를 만들어 두면 마음이 놓입니다. 매일 아침 7시에 초안이 도착하고, 새벽 3시에 백업이 돌고, 저는 검토만 하면 되니까요. 저도 그렇게 믿었습니다.

그런데 자동화가 멈추면 알림이 오지 않습니다. 멈춘 자동화는 아무 말도 하지 않거든요. 화면에 빨간 글씨가 뜨는 것도 아니고, 메일이 한 통 오는 것도 아닙니다. 그냥 아무 일도 일어나지 않습니다.

아임용 블로그는 RSS 수집, 초안 생성, 백업, 이미지 제작을 자동으로 돌립니다. 만드는 동안 네 번 깨졌고, 그중 세 번은 제가 눈으로 발견할 때까지 아무도 알려주지 않았습니다. 이 글에는 그 네 가지가 각각 어떻게 깨졌고, 무엇으로 막았는지를 날짜와 수치 그대로 정리했습니다. 성공담이 아니라 실패 기록입니다.

1. 매일 실패하고 있었는데, 아무 일도 일어나지 않았다

크론(Cron)은 매일 정확한 시각에 실행됐고, 매일 정확히 405로 실패하고 있었습니다.

버셀(Vercel)의 크론은 등록된 경로를 HTTP GET 방식으로 호출합니다. 그런데 제가 만든 두 경로(자동 수집과 자동 백업)는 POST만 받도록 열려 있었습니다. GET으로 들어온 요청은 405 Method Not Allowed로 튕겨 나갔죠.

수집도 백업도 며칠 동안 한 번도 돌지 않았습니다. 그동안 관리자 화면은 평온했습니다. 실패한 크론은 상태 코드만 남기고 조용히 사라지거든요.

같은 자리에서 하나 더 나왔습니다. 인증 코드가 if (비밀키가 있고 && 값이 맞으면) 형태였습니다. 비밀키 설정을 깜빡하면 조건문 자체가 건너뛰어져 인증 없이 통과하는 구조였죠. 흔히 페일 오픈(fail-open), 즉 '고장 나면 열린다'고 부르는 패턴입니다.

고친 것은 두 가지입니다. 두 경로에 GET 처리기를 함께 열고, 인증을 if (비밀키가 없거나 || 값이 다르면 거절)로 뒤집었습니다. 배포한 뒤 GET 요청이 405에서 401로 바뀌는 것을 확인하고서야 안심했습니다. 401이 반가운 날도 있더군요.

한 줄 정리: 자동화의 첫 검증은 "성공했나"가 아니라 "실행은 됐나"다. 실행 흔적이 없는 자동화는 없는 것과 같다.

2. 첫 실행이 통째로 사라졌다 — 원인은 코드 밖에 있었다

API도 인증도 정상이었습니다. 막혀 있던 것은 실행 환경의 네트워크였습니다.

2026년 7월 20일 오전 7시 7분, 초안 루틴은 분명히 실행됐습니다. 그런데 초안은 등록되지 않았고 보고 메일도 오지 않았습니다.

원인은 두 개였고, 둘 다 코드 바깥에 있었습니다.

1. 클라우드 실행 환경의 네트워크 권한이 '신뢰된 주소만'으로 잡혀 있었습니다. 그래서 제 도메인으로 나가는 요청이 프록시 단계에서 전부 차단됐습니다(CONNECT 403). 초안 등록도, RSS 읽기도, 원문 확인도 도달하지 못했습니다.
2. 루틴에 연결해 둔 지메일 도구에는 '보내기' 기능이 아예 없었습니다. 초안 만들기만 있었죠. 그래서 보고가 발송되지 않고 초안함에 쌓이고 있었습니다.

두 번째가 첫 번째를 가렸습니다. 보고 메일이 없으니 실행 자체가 안 된 줄 알았는데, 사실 루틴은 성실히 일하고 결과물을 아무도 안 보는 서랍에 넣고 있었던 겁니다.

초안함에 남아 있던 원고 두 건을 로컬에서 직접 등록해 복구했습니다. 재발 방지로는 네트워크 권한을 전부 연 전용 실행 환경을 새로 만들었고, "보고는 초안함 저장 + 푸시 알림으로 온다"를 루틴 지시문에 못박았습니다.

한 줄 정리: 자동화가 실패하면 코드부터 열지 말 것. 실행 환경·권한·연결된 도구가 실제로 할 수 있는 일이 먼저다.

3. 같은 뉴스를 이틀 연속 발행했다

중복 방지 장치는 있었습니다. 다만 제목이 글자 하나까지 똑같을 때만 작동했습니다.

7월 26일과 27일, 같은 사건이 다른 제목으로 두 번 나갔습니다. 루틴이 매일 새로 리서치를 하니 표현이 조금씩 달라지는데, 가드는 완전 일치만 봤으니 그대로 통과한 겁니다.

한 건인 줄 알고 열어봤다가 전수 점검으로 번졌습니다. 발행분 53건의 제목을 서로 짝지어 비교했더니 중복은 1쌍이 아니라 3쌍이었습니다.

숫자가 답을 줬습니다. 확실한 중복은 0.596~0.657에 몰려 있고, 정당한 글은 0.415 아래에 흩어져 있습니다. 문제는 그 사이입니다.

그래서 2단으로 나눴습니다. 유사도 계산에는 한국어에 강한 문자 두 글자 단위 비교(다이스 계수, Dice coefficient)를 씁니다. 조사와 띄어쓰기가 흔들려도 흔들림이 덜하거든요.

• 0.55 이상 — 등록 자체를 거절합니다(409).
• 0.40~0.55 — 막지 않습니다. 대신 알림 메일에 "비슷한 글이 최근에 있었습니다" 박스와 해당 글 편집 링크를 넣어 사람이 판단하게 합니다.

중간 구간을 기계에 맡기지 않은 이유가 있습니다. 0.415짜리 정당한 후속편과 0.333짜리 무관한 글이 그 근처에 섞여 있습니다. 여기서 자동으로 잘라내면 멀쩡한 글이 죽습니다.

물론 이걸로 다 잡히지는 않습니다. 같은 법안을 다룬 글 두 건은 제목 표현이 완전히 달라 유사도가 0.298이었습니다. 경고에도 안 걸립니다. 제목만 봐서는 못 잡는 중복이라, 이건 코드가 아니라 "주제를 고르기 전에 최근 7일 발행 제목을 먼저 조회하라"는 지시문 쪽 과제로 남겨 뒀습니다. 아직 완전히 닫지 못한 구멍입니다.

한 줄 정리: 자동 차단은 확실한 구간에만 건다. 애매한 구간은 막지 말고 사람에게 보여준다.

4. 숫자를 코드로 옮겼는데, 안 옮긴 곳에서 다시 터졌다

원인을 제거했다고 믿은 바로 그날, 옆자리에서 같은 실패가 그대로 재현됐습니다.

용어 설명 글에 넣는 본문 이미지가 편마다 조금씩 달라 보인다는 지적을 받았습니다. 눈대중이 아니라 픽셀로 재봤습니다. 강조 바가 제목을 27px 침범한 편, 바 색이 혼자 다른 편, 설명 글자가 카드 테두리에 3px까지 붙은 편이 나왔습니다.

원인은 허무했습니다. 이미지 생성 도구를 만들어 두고도 쓰지 않고, 규격 문서에 적어 둔 좌표 숫자를 보며 매번 새로 그리고 있었던 겁니다. 숫자가 문서에 있으면 도구를 부르지 않게 되더군요.

그래서 문서에서 좌표를 전부 지웠습니다. 이제 좌표의 유일한 출처는 코드 안의 상수뿐입니다. 여기까지는 맞는 판단이었습니다.

그런데 같은 날, 색에서 똑같은 일이 벌어졌습니다. 상수로 묶은 것은 좌표뿐이었고 색은 여전히 코드 문자열에 손으로 적을 수 있었거든요. 목업을 그리다 회색 세 가지(#B0B0B0·#E0E0E0·#BDBDBD)를 즉흥적으로 흩뿌린 것이 검수에서 잡혔습니다. 막으려던 실패 유형을 막은 다음 날도 아니고, 같은 날 재현한 셈입니다.

고친 방식은 두 겹입니다. 색도 상수로 승격했고(회색이 필요하면 정해진 세 가지 중에서만 고릅니다), 이미지를 올리기 전에 기계 검사와 디자이너 검수를 둘 다 통과하도록 절차를 바꿨습니다. 기계는 3px 어긋남을 잡고, 사람은 "이 문장이 정보인가"를 봅니다. 서로 못 보는 것이 다릅니다.

한 줄 정리: 재발 방지는 "그 자리"가 아니라 "그 유형"에 건다. 좌표를 막았으면 색·문구·크기도 같은 날 함께 막아야 한다.

5. 네 번의 공통점

네 건 모두 원인은 "틀린 값"이 아니라 "알려주지 않는 구조"였습니다.

네 건 중 셋은 증상이 없었습니다. 자동화는 실패해도 비명을 지르지 않습니다. 그냥 조용해질 뿐이죠.

그래서 지금은 기능을 늘리기 전에 자기 신고부터 붙입니다. 매일 오는 보고 메일에는 "이번 주 수동 작성 글 목표 2편 / 실제 0편" 같은 문장이 들어갑니다. 실제로 이 문장 덕분에 6일 동안 글을 안 썼다는 사실을 알았습니다.

한 줄 정리: 자동화에 마지막으로 붙여야 할 기능은 "자기가 못 한 일을 스스로 보고하는 기능"이다.

---

자주 묻는 질문

자동화를 만들면 확인할 일이 줄어드나요?

줄어드는 것은 '작업'이고, 늘어나는 것은 '점검'입니다. 사람이 하던 일은 빼먹으면 바로 티가 나지만, 자동화는 멈춰도 티가 나지 않으니까요. 그래서 저는 자동화를 하나 붙일 때마다 "이게 멈추면 내가 어떻게 알게 되나?"를 먼저 정합니다. 답이 "모른다"면 그 자동화는 아직 완성이 아닙니다.

중복 차단 기준을 더 엄격하게 잡으면 안 되나요?

실측값이 말립니다. 확실한 중복은 0.596 이상이었지만, 정당한 후속 보도가 0.415, 완전히 무관한 글도 0.333까지 올라왔습니다. 기준을 0.40까지 내리면 후속편이 막힙니다. 자동 차단은 오탐이 거의 없는 구간까지만 걸고, 나머지는 사람에게 보여주는 편이 안전합니다.

클라우드 자동화에 맡기면 안 되는 일도 있나요?

있습니다. 기준값이 저장소 안에 있는 작업입니다. 이미지 규격이 그랬습니다. 클라우드에서 도는 에이전트는 제 코드 파일을 읽을 수 없어서, 지시문에 좌표 숫자를 적어 주는 수밖에 없었고, 그 숫자가 곧 어긋남의 원인이었습니다. 그래서 이미지 제작은 다시 로컬로 되돌렸습니다. 자동화의 범위는 능력이 아니라 기준값에 닿을 수 있느냐로 정해야 합니다.

마치며

네 번의 사고를 겪고 나서 자동화를 보는 눈이 바뀌었습니다. 예전에는 "이걸 자동으로 할 수 있나"를 먼저 물었는데, 지금은 "이게 조용히 실패하면 내가 언제 알게 되나"를 먼저 묻습니다. 순서가 바뀐 것뿐인데 놓치는 것이 확실히 줄었습니다.

자동화는 일을 대신해 주지만, 걱정까지 대신해 주지는 않습니다. 오히려 걱정할 자리를 옮겨 놓죠. 작업에서 감시로요.

혹시 지금 돌아가고 있는 자동화가 있으신가요? 오늘 딱 하나만 확인해 보시면 어떨까요. 마지막으로 성공한 게 언제인지를요.

이 글의 정보는 2026년 8월 7일 기준입니다.

같이 읽어 볼 글

• AI 자동화 툴 3가지 — 재피어·메이크·n8n 초보자 가이드
• 클로드 코드 설치·사용법 — 윈도우에서 명령어 한 줄로 끝내기
• 회귀 검사 14종을 통과한 자동화가 32초 만에 실패한 이유

참고 자료

• Cron Jobs — Vercel Docs (크론이 GET으로 호출한다는 규격)
• 405 Method Not Allowed — MDN
• Dice-Sørensen coefficient — Wikipedia (제목 유사도 계산에 쓴 지표)