자동 발행이 5편에서 2편으로 줄었을 때 막힌 곳 찾기

매일 아침 블로그 커밋을 확인하는 습관이 있어요. 며칠 동안 5편, 6편, 5편으로 꾸준히 올라오던 자동 발행 커밋이 어느 날 2편으로 찍혀 있으면 기분이 묘합니다. 에러 알림은 안 왔거든요. 실행 상태는 전부 success였고요.

이런 상황을 몇 번 겪고 나서 점검 순서를 고정해 뒀어요. 순서가 중요합니다. 순서를 안 정해 두면 로그부터 열어보게 되는데, 그게 제일 느린 길이었어요.

상태 대시보드보다 결과물을 먼저 세요

제가 가장 크게 배운 건 이겁니다. 실행 성공 표시는 "파이프라인이 끝까지 돌았다"는 뜻이지 "글이 나왔다"는 뜻이 아니에요.

그래서 첫 단계는 무조건 결과물 개수 세기로 잡았어요. 커밋 메시지에 발행 편수를 넣어 두면 git log 한 줄로 최근 7일 추이가 보입니다. 직접 해 보니 대시보드 열어서 실행 이력 훑는 것보다 10초 정도 빨랐어요. 그리고 훨씬 정확했고요.

결과물 개수 확인단계별 입력 개수 확인탈락 지점 특정해당 단계만 재실행

제 파이프라인은 크게 네 칸이에요. 주제 수집 → 초안 생성 → 품질 게이트 → 커밋. 입력 5개가 출력 2개가 됐다면 어느 칸에서 3개가 빠진 거죠.

각 단계 출력 개수를 하나씩 확인해 봤어요. 수집이 5개였는데 초안이 2개면 생성 단계 문제, 초안이 5개였는데 커밋이 2개면 게이트 문제입니다. 이 확인이 2분 정도 걸리는데, 이 2분이 로그 전문 읽기 30분을 아껴 줘요.

제 경우엔 게이트였어요. 원본성 신호 검사를 조금 빡빡하게 조정해 둔 걸 잊고 있었거든요. 통과 기준을 올렸으니 통과 편수가 줄어드는 게 당연한 결과였습니다. 장애가 아니라 설정 변경의 정상 동작이었어요.

이 경험 이후로 세 가지를 바꿨어요.

첫째, 게이트 탈락 건은 사유와 함께 별도로 남깁니다. 그냥 버리면 왜 줄었는지 알 길이 없어요. 탈락 사유 한 줄만 남겨도 다음 점검이 훨씬 빠릅니다.

둘째, 기준을 조정할 때마다 날짜와 함께 한 줄 메모를 남겨요. 일주일만 지나도 내가 뭘 바꿨는지 기억 안 나더라고요. 이건 테스트해 보면 누구나 공감할 거예요.

셋째, 성공 개수가 평소의 절반 아래로 떨어지면 알림이 오게 했어요. 에러가 없어도 산출량이 급감하면 그것도 이상 신호니까요. 기준선은 최근 7일 평균의 50%로 잡았습니다.

플랜씨나 플랜비를 운영하면서도 같은 걸 느꼈어요. 계산기가 응답을 돌려주는 것과 사용자가 원하는 답을 얻는 건 다른 문제입니다. 플랜비에서 회비 정산 로직을 손볼 때도 "처리 완료"만 보지 않고 실제 정산 내역이 맞게 찍혔는지 화면에서 확인하는 습관을 들였어요.

자동화는 만드는 순간이 아니라 조용히 망가진 걸 알아채는 순간에 진짜 값이 정해지는 것 같아요. 산출량 추이를 보는 눈 하나만 있어도 대부분의 조용한 실패는 하루 안에 잡힙니다.