자동화가 조용히 멈춰 있을 때

한 줄 답

자동화는 에러를 내며 멈추지 않습니다. 아무 일도 하지 않는 상태로 멈춥니다. 그래서 실패를 잡으려 하지 말고 성공을 보고하게 만드세요. 「어제 12건 처리됨」 같은 한 줄이 매일 오면, 그 줄이 안 오는 날이 곧 경보입니다. 첨부의 자동화 점검 설계 프롬프트와 자동화 점검표 (xlsx)을 쓰면 40분 안에 운영 중인 자동화 전체의 점검 목록과 일일 보고 한 줄이 나옵니다.

이런 증상이면 이 자료입니다

· 고객 문의 자동 분류를 걸어 뒀는데, 나흘 뒤 스프레드시트를 열어 보니 마지막 행이 지난주 날짜였습니다. · 에러 알림은 한 번도 안 왔습니다. 그래서 잘 돌아가는 줄 알았습니다. · 자동화를 다섯 개쯤 만들어 뒀는데, 지금 몇 개가 살아 있는지 대답을 못 합니다. · 멈춘 걸 발견하는 방법이 「어쩌다 들어가 봤을 때」뿐입니다.

왜 안 풀렸나 — 실패를 감지하려 했기 때문

보통은 이렇게 생각합니다. 에러가 나면 알림을 받게 해 두면 되지 않나. 실제로 대부분의 자동화 도구가 실패 알림 기능을 갖고 있고, 만들 때 그 스위치를 켭니다. 여기까지는 맞습니다.

문제는 조용한 실패입니다. 연결된 API 토큰이 만료돼서 워크플로가 아예 실행되지 않는 경우, 실행이 안 됐으니 실패도 없습니다. 트리거로 쓰던 폼의 필드 이름이 바뀌어서 조건에 걸리는 데이터가 0건인 경우도 마찬가지입니다. 시스템 입장에서는 「처리할 게 없었다」와 「고장 나서 못 했다」가 구분되지 않습니다. 둘 다 조용합니다.

그러니 실패 알림은 절반짜리 장치입니다. 잡히는 건 눈에 띄게 터진 실패뿐이고, 실제로 손해를 키우는 건 며칠씩 티 안 나게 멈춰 있는 쪽입니다. 발견이 늦을수록 놓친 문의, 안 나간 메일, 안 쌓인 데이터가 같이 늘어납니다.

방향을 뒤집어야 합니다. 「문제가 생기면 알려 줘」가 아니라 「잘 됐으면 매일 알려 줘」로.

성공 보고 한 줄 — 침묵을 경보로 바꾸기

· 모든 자동화 마지막에 카운터를 붙입니다. 오늘 처리한 건수를 세서 하루 한 번 알림으로 보냅니다. 형식은 「[문의분류] 어제 12건」 한 줄이면 충분합니다. · 0건도 반드시 보냅니다. 「어제 0건」이 와야 정상 여부를 판단할 수 있습니다. 0건이 자연스러운 날인지, 이상한 날인지는 사람이 봅니다. · 아무것도 안 오는 날이 경보입니다. 보고 자체가 안 왔다는 건 자동화가 실행되지 않았다는 뜻이니까요. · 알림 채널은 하나로 모읍니다. 슬랙 채널이든 메일 라벨이든, 아침에 한 곳만 보면 되게.

코덱스에게 점검 로직을 맡기는 법

카운터를 손으로 붙이려면 워크플로마다 노드를 추가하고 날짜 범위를 계산해야 합니다. 이걸 코덱스에 맡깁니다. 첨부 프롬프트는 「이 자동화의 구조를 설명할 테니, 어제 처리 건수를 세서 하루 한 번 보고하는 코드와 붙일 위치를 알려 달라」는 형태입니다.

중요한 건 판정입니다. 코덱스가 짜 준 코드를 그대로 붙이기 전에 「이 자동화가 실행조차 안 됐을 때는 어떻게 되나」를 물어보세요. 실행이 안 되면 보고도 안 나가는 구조여야 맞습니다. 보고를 별도 스케줄로 돌리면 자동화가 죽어도 「0건」이 계속 오게 되고, 그건 다시 조용한 실패입니다.

점검표는 그 위에 얹는 관리 장부입니다. 운영 중인 자동화를 행으로 두고 기대 건수·마지막 확인일·실제 건수를 적으면, 기대 대비 실제가 0인 행에 「멈춤 의심」이 뜨고 7일 이상 손대지 않은 행도 같이 표시됩니다.

쓰는 법 — 총 40분

1단계 (10분). 점검표를 열고 지금 돌고 있다고 생각하는 자동화를 전부 적습니다. 이름, 하는 일, 하루 기대 처리 건수. 기대 건수를 모르겠으면 대충이라도 적으세요. 「대략 하루 5~10건」이면 5로 적습니다. 이 단계에서 이미 「이거 아직 살아 있나?」 싶은 행이 나옵니다.

2단계 (10분). 그 행들의 실제 데이터를 확인합니다. 결과가 쌓이는 시트나 폴더를 열어 마지막 기록 날짜를 봅니다. 기대는 5인데 실제가 0이면 멈춤 의심입니다. 여기서 고치려 들지 말고 표시만 하세요.

3단계 (15분). 살아 있는 자동화부터 프롬프트를 코덱스에 넣습니다. 워크플로 구조를 붙여 넣고 일일 보고 한 줄을 요청합니다. 받은 코드는 「실행 안 되면 보고도 안 나가나」를 확인한 뒤 붙입니다.

4단계 (5분). 알림이 도착할 채널을 정하고 하루 뒤 첫 보고가 오는지 봅니다. 안 오면 그 자동화는 이미 멈춰 있던 겁니다.

나오는 결과

· 운영 중인 자동화 전체 목록과 각각의 기대 건수·마지막 확인일이 한 장에 정리됩니다. · 매일 아침 한 곳에서 확인하는 「어제 몇 건」 보고 한 줄이 붙습니다. · 지금 멈춰 있는 자동화가 몇 개인지 오늘 안에 알게 됩니다.

한 가지 주의

처리 건수가 원래 들쭉날쭉한 자동화에는 이 방식이 덜 맞습니다. 주 1~2건 도는 워크플로는 0건이 정상인 날이 많아서 침묵이 경보 역할을 못 합니다. 이런 건 건수 대신 「마지막 실행 시각」을 보고하게 바꾸세요. 실행 시각은 처리 건수가 0이어도 갱신됩니다.

되돌리기 힘든 실수는 보고 알림을 기존 업무 채널에 섞어 넣는 겁니다. 매일 한 줄씩 쌓이면 금세 소음이 되고, 사람은 소음을 무시합니다. 두 주쯤 지나면 보고가 안 온 날도 눈치채지 못하게 됩니다. 전용 채널이나 전용 메일 라벨을 처음부터 따로 만드세요.

받는 파일 (ZIP 1개, 3종)

· 본문 PDF — 조용한 실패의 구조와 성공 보고 설계 4단계를 정리한 문서 · 자동화 점검 설계 프롬프트 (.txt) — 코덱스에 워크플로 구조를 주고 일일 보고 코드와 삽입 위치를 받아 내는 프롬프트, 판정용 확인 질문 포함 · 자동화 점검표 (xlsx) — 자동화별 기대 건수·마지막 확인일·실제 건수 기록표, 멈춤 의심과 7일 미확인 자동 표시

이 구조는 퀀텀점프가 AI로 창업·부업을 시작하는 1인 사업자들과 실제로 쓰면서 정리한 것입니다.