git status 미추적 14개: 자동 발행이 커밋을 빼먹은 걸 찾은 방법

아침에 블로그 저장소를 열고 git status를 쳤더니 미추적 파일이 14개 떠 있었어요. 라이프케어로그 블로그는 새벽마다 자동 발행 파이프라인이 글을 쓰고 커밋까지 하도록 짜 두었거든요. 커밋 로그를 보니 마지막 5개는 하루 4~6편씩 정상이었어요. 그 뒤로는 파일만 쌓이고 커밋이 없었고요. 워크플로 실행 기록은 전부 성공이었어요.

성공 응답이 거짓말을 한 지점

파이프라인은 3단계예요. 글 생성, 프런트매터 검증, 그리고 git add·commit·push. 직접 로그를 따라가 보니 앞 두 단계는 멀쩡했고, 마지막 단계도 셸 스크립트가 exit code 0으로 끝나 있었어요. 문제는 그 스크립트가 커밋 명령의 결과를 보지 않고 "done"만 찍은 거였어요. 워크플로 입장에서는 HTTP 200에 본문 "success"가 왔으니 성공으로 기록할 수밖에 없죠.

백엔드에서 자주 보는 모양이에요. DB에 행은 들어갔는데 이벤트 발행이 안 된 아웃박스 문제와 같아요. 파일 쓰기가 INSERT라면 커밋은 발행이고, 둘 사이를 잇는 검증이 없으면 "저장됐다"와 "반영됐다"가 조용히 갈라져요.

종료 코드 대신 표면을 검사하기

고쳐 보니 핵심은 한 줄이었어요. 커밋 단계의 완료 조건을 "스크립트가 끝났다"에서 "글 디렉토리에 미추적·수정 파일이 0개다"로 바꿨어요.

git add content/
git commit -m "feat(blog): 자동 발행 $(date +%F)" || exit 1
git push || exit 1
[ -z "$(git status --porcelain content/)" ] || { echo "dirty tree"; exit 1; }

테스트해 보면 git commit이 훅에 막히거나 push가 인증 만료로 실패했을 때 워크플로가 바로 실패로 넘어가요. 응답 본문에는 HEAD 해시를 실어 보내서, 실행 전후 해시가 같으면 호출한 쪽에서 실패로 처리하게 했어요. 쓰기 API가 "success" 문자열만 돌려주면 안 되는 이유가 이거예요. 무엇이 바뀌었는지 식별자로 돌려줘야 호출자가 검증할 수 있어요.

조용히 멈추는 실패는 따로 잡아야 해요

위 검사는 "돌았는데 안 됐다"를 잡아요. "아예 안 돌았다"는 다른 실패예요. 워크플로가 실행조차 안 되면 실패 기록도 안 남거든요. 그래서 마지막 커밋 시각을 보는 감시를 별도 경로에 붙였어요.

last=$(git log -1 --format=%ct)
[ $(( $(date +%s) - last )) -lt 129600 ] || echo "36시간 넘게 커밋 없음"

36시간으로 잡은 건 하루 1회 발행이라 하루 반 동안 커밋이 없으면 확실히 이상하기 때문이에요. 적용해 봤더니 검사 자체는 1초도 안 걸리고, 워크플로 서버가 죽어도 이 검사는 다른 곳에서 도니까 같이 죽지 않아요.

돌려 보니 미추적 14개 같은 상황은 이제 실패 알림으로 먼저 도착해요. 플랜엘처럼 법령·판례 데이터를 외부에서 매일 받아오는 서비스라면 더 그래요. "가져왔다"와 "저장됐다"는 늘 따로 확인해야 해요.