자동화가 조용히 멈췄을 때 알아채는 구조

에러 없이 0건

대시보드는 초록색이었습니다. 실패율 0%.

3주 동안 처리 건수도 0이었습니다.

입력이 끊겼는데 아무도 몰랐습니다. 실패한 적이 없으니 알림도 없었습니다.

조용히 멈춘 자동화가 가장 위험하다

자동화가 에러를 내며 죽으면 그나마 낫습니다. 누군가 알아차립니다.

진짜 문제는 이런 경우입니다. 워크플로가 정상 종료로 표시되는데 실제로는 아무것도 처리하지 않은 상태. 입력이 0건이었고, 0건을 잘 처리했고, 성공으로 기록됩니다. 한 달 뒤에 "그거 요즘 안 오던데요"라는 말로 알게 됩니다.

앞선 글에서 정착 조건 중 하나로 "깨졌을 때 알 수 있는가"를 들었습니다. 이 글은 그걸 구조로 만드는 방법입니다.

세 가지 층위로 본다

관측을 한 덩어리로 생각하면 로그만 잔뜩 쌓고 끝납니다. 층을 나누세요.

1층 — 살아 있는가 (Liveness)

워크플로가 예정대로 실행되긴 했는가. 스케줄 기반 작업이라면 실행되지 않은 것 자체가 장애입니다. 대부분의 도구는 실행 실패는 알려주지만 미실행은 알려주지 않습니다.

해결책은 단순합니다. 성공할 때마다 신호를 보내고, 정해진 시간 안에 신호가 오지 않으면 알리는 감시 장치를 따로 둡니다. 외부 헬스체크 서비스를 쓰든 별도 워크플로로 만들든 상관없습니다. 핵심은 감시자가 감시 대상 밖에 있어야 한다는 것입니다.

2층 — 제대로 했는가 (Correctness)

실행됐다고 일이 된 건 아닙니다. 최소한 이 지표는 매 실행마다 남기세요.

• 입력 건수와 출력 건수
• 사람에게 넘긴 건수(핸드오프)
• 건너뛴 건수와 그 이유

입력 0건이 이틀 연속이면 알림을 거는 것만으로 앞의 사례 대부분이 잡힙니다. 정상 범위를 벗어난 조용함은 그 자체가 신호입니다.

3층 — 나빠지고 있는가 (Drift)

당장은 돌지만 서서히 나빠지는 상태입니다. 앞선 90일 측정 글에서 다룬 지표들이 여기 해당합니다. 사람이 뒤집는 비율, 핸드오프 비율, 처리 시간. 주 단위로 추세를 보면 사고 나기 전에 보입니다.

알림은 적을수록 좋다

관측 체계를 만들면 알림이 쏟아지고, 사람은 곧 무시하게 됩니다. 무시되는 알림은 없는 알림보다 나쁩니다. 안전하다고 착각하게 만들기 때문입니다.

알림 설계 원칙 세 가지입니다.

실패를 기록하는 방식

실패 로그는 재현 가능해야 의미가 있습니다. 남길 것들입니다.

• 언제, 어느 워크플로, 어느 단계
• 입력 데이터 — 민감 정보는 마스킹하되 구조는 남깁니다
• 오류 메시지 원문 — 요약하지 말고 그대로
• 재시도 여부와 결과

특히 두 번째가 중요합니다. "실패했습니다"만 남은 로그로는 아무것도 못 합니다. 어떤 입력에서 실패했는지 알아야 고칠 수 있습니다.

사람도 관측 대상이다

기술 지표만 보면 절반을 놓칩니다. 앞선 글에서 다룬 두 가지를 같이 보세요.

핸드오프 응답 시간. 사람에게 넘긴 건이 얼마 만에 처리되는지. 이게 길어지면 자동화가 아무리 빨라도 전체 리드타임은 그대로입니다.

승인 거부율. 0에 가까우면 승인이 형식화된 것이고, 지나치게 높으면 조건이나 품질에 문제가 있는 것입니다.

최소 구성

전부 갖출 필요는 없습니다. 처음에는 이 네 가지면 충분합니다.

1. 스케줄 작업의 미실행 감지
2. 입력 0건 연속 알림
3. 실패 시 묶음 알림과 원문 로그
4. 주 1회 핸드오프 비율·거부율 요약

이걸 갖추면 "돌아가고 있는 줄 알았다"는 상황이 사라집니다. 그것만으로도 AX가 되돌아가지 않을 확률이 크게 올라갑니다.

관측에서 제일 위험한 상태는 실패가 아니라 침묵입니다.

에러는 알려주지만 멈춤은 알려주지 않습니다. 그래서 "돌았는가"가 아니라 "몇 건 나왔는가"를 봐야 합니다.

그리고 감시자는 감시 대상 밖에 둡니다. 같은 서버에서 도는 감시자는 함께 조용해집니다.