오류를 안 내고 조용히 깨진 자동화 — 점검으로 찾아낸 네 가지 모양

자동화를 여러 개 돌리다 하루 날 잡고 점검을 해봤습니다. 조용히 깨져 있던 것이 여러 개 나왔습니다.

공통점이 하나였습니다. 전부 오류를 안 냈습니다. 종료 코드는 0이고, 오류 로그도 없고, 알림도 안 왔습니다. 그래서 몇 주씩 아무도 몰랐습니다.

이 글은 그 네 가지 모양과 잡아내는 방법입니다.

1. 각 자동화의 "성공"을 결과물로 다시 정의합니다 2. 결과물이 안 늘면 알리게 합니다 3. 감시 장치 자체가 살아 있는지 확인할 방법을 둡니다 4. 정기적으로 눈으로 한 번 봅니다

증상 — 모든 신호가 '이상 없음'입니다

증상 — 겉으로 보이는 것은 전부 정상입니다.

원인 — "안 죽었다"를 성공으로 쓰고 있었습니다. 프로그램이 예외 없이 끝나면 성공으로 기록되는데, 아무 일도 안 하고 끝나도 예외는 안 납니다.

저는 서비스 상태만 보고 "다 돌아가고 있다"고 생각했습니다. 돌아가는 것과 일을 하는 것은 다른데, 그 구분을 안 두고 있었습니다.

네 가지 모양

하나. 빈 성공

응답 코드는 200인데 본문이 비어 있습니다. 오류 처리 코드가 안 걸립니다.

if resp.status != 200:      # 여기 안 걸린다
    raise FetchError()
data = resp.read()          # 빈 값이 그대로 흘러간다

해결 — 내용까지 검사합니다. 응답 코드는 겉면일 뿐입니다.

if not data or len(data) < MIN_BYTES:
    raise FetchError(f"응답이 비었습니다: {len(data)} bytes")

둘. 삼킨 예외

실패해도 다음으로 넘어가게 만든 부분입니다. 의도는 좋았는데 기록을 안 남긴 게 문제였습니다.

try:
    do_work()
except Exception:
    pass          # 다음 건은 돌아야 하니까 넘긴다 ← 여기서 사라진다

해결 — 넘기되 남깁니다. 그리고 연속으로 실패하면 알립니다.

except Exception as e:
    log(f"실패: {e}")
    state["fail_streak"] += 1
    if state["fail_streak"] >= 2:
        notify("연속 실패 — 확인이 필요합니다")

셋. 빈 목록

조회는 성공했는데 결과가 0건입니다. 이게 "오늘은 대상이 없음" 인지 "조회가 잘못된 것" 인지 구분이 안 됩니다.

저는 이름 한 글자가 달라서 계속 아무것도 못 찾던 것을 찾아냈습니다. 조회 자체는 성공하니 오류가 안 났습니다. 몇 주 동안 매일 0건을 정상으로 기록하고 있었습니다.

해결 — 0건이 며칠 이어지면 이상으로 봅니다. 하루 0건은 있을 수 있지만, 일주일 내내 0건이면 대개 잘못된 것입니다.

if result_count == 0:
    state["zero_days"] += 1
    if state["zero_days"] >= 3:
        notify(f"{state['zero_days']}일 연속 0건 — 조회 조건을 확인하세요")
else:
    state["zero_days"] = 0

넷. 죽은 감시

제일 고약한 형태입니다. 감시 장치 자체가 멈춘 것입니다.

알림이 안 오는 게 "이상 없음"인지 "감시가 죽은 것"인지 구분이 안 됩니다. 조용한 것을 정상으로 읽고 있으면 이 상태를 영원히 모릅니다.

해결 — 감시가 살아 있다는 신호를 정기적으로 남기게 합니다.

# 하루 한 번, 이상이 없어도 "확인했다"를 남긴다
write_heartbeat({"checked_at": now(), "status": "ok", "targets": len(targets)})

그리고 그 기록이 끊기면 그때 의심합니다. 알림이 없는 것과 확인 기록이 없는 것은 다릅니다.

고치는 원칙 — 성공을 결과로 정의합니다

네 가지를 관통하는 원칙이 하나입니다.

작업	나쁜 성공 판정	좋은 성공 판정
발행	예외 안 남	글이 실제로 한 편 늘었나
수집	요청 200	새 행이 들어왔나
배포	업로드 완료	사이트가 실제로 바뀌었나
생성	응답 받음	결과물이 기준을 넘었나

"안 죽었다"를 성공으로 쓰지 않습니다. 기대한 결과물이 있어야 성공입니다. 이 한 줄만 바꿔도 위 네 가지 중 셋이 잡힙니다.

점검을 정기적으로

한 번 고쳐도 시간이 지나면 또 생깁니다. 저는 점검 스크립트를 하나 만들어 두고 정기적으로 돌립니다.

확인	이상 판정
각 자동화가 마지막으로 결과물을 낸 시각	주기보다 오래됐으면 이상
최근 실행의 결과 건수	며칠 연속 0건이면 이상
감시·알림의 확인 기록	끊겨 있으면 이상
설정 파일·인증 파일 존재와 권한	없거나 권한이 풀렸으면 이상
디스크·로그 크기	갑자기 늘거나 안 늘면 이상

마지막 줄에 "안 늘면" 을 넣은 이유가 있습니다. 로그가 안 쌓이는 것도 신호입니다. 일하고 있으면 기록이 남아야 합니다.

한계

이 방식으로도 못 잡는 것이 있습니다. 결과물은 나오는데 품질이 나빠진 경우입니다. 건수는 정상이라 위 점검을 전부 통과합니다.

저는 결과물에 점수를 매기는 검사를 따로 붙여서 일부는 잡고 있는데, 그것도 점수 기준 안에서만 봅니다. 기준 자체가 현실과 어긋나면 점수는 높은데 쓸모없는 결과물이 나올 수 있습니다.

이 부분을 자동으로 잡는 방법은 아직 확인하지 못했습니다. 결국 사람이 정기적으로 결과물을 직접 보는 수밖에 없어 보이는데, 더 나은 방법이 있는지는 모르겠습니다.

판정 — 계속 쓴다

성공 판정을 결과물로 바꾸는 것은 값어치가 큽니다. 코드 몇 줄이고, 몇 주짜리 공백을 며칠로 줄입니다.

정기 점검도 붙일 만합니다. 저는 이 점검 한 번으로 여러 개를 찾아냈습니다. 그전까지는 전부 "정상"으로 보이고 있었습니다.

다만 조용한 고장을 전부 없앨 수는 없습니다. 새로 만드는 것마다 새로운 방식으로 조용히 깨집니다. 점검 항목을 계속 늘려가는 수밖에 없었습니다.

직접 하실 분께

하나. 각 자동화에 "무엇이 나와야 성공인가" 를 한 줄로 적어 두세요. 그게 없으면 점검 자체를 못 만듭니다.

둘. except: pass 를 찾아서 기록이라도 남기게 바꿉니다. 넘기는 건 괜찮지만 사라지면 안 됩니다.

셋. 며칠 연속 0건이면 이상으로 봅니다. 0건도 결과라고 넘기면 조회가 깨진 걸 영원히 모릅니다.

넷. 감시가 살아 있다는 기록을 남깁니다. 조용한 것이 정상인지 고장인지 구분돼야 합니다.

다음에는 결과물의 품질이 조용히 나빠지는 경우를 자동으로 잡을 방법이 있는지 찾아보려고 합니다. 되면 이어서 적겠습니다.