status=success인데 글이 안 올라갔다: 발행 파이프라인 false-green 잡기

대시보드는 온통 초록불인데, 정작 결과물이 없던 적 없나요?

라이프케어로그 블로그는 하루 6편씩 글을 자동으로 올려요. 그런데 어느 날 실행 기록을 열어 보니 전부 success인데, 블로그에는 새 글이 0편이었어요. 실패 알림도 안 왔고요. 이게 제가 false-green(가짜 초록불)이라고 부르는 상태예요. 상태값은 성공인데 실제 일은 안 된 거죠.

왜 성공이라고 나왔을까

원인을 직접 쫓아가 보니 단순했어요. 파이프라인의 마지막 단계가 "글을 커밋하고 push" 였는데, 그 앞 단계에서 이미 같은 파일이 있으면 조용히 건너뛰도록 짜여 있었어요. 커밋할 변경이 없으니 push는 아무 일도 안 하고 정상 종료, 상태는 success. 도구 입장에선 거짓말을 한 게 아니에요. 실행은 오류 없이 끝났으니까요.

문제는 제가 성공의 기준을 잘못 잡았다는 데 있었어요. "명령이 에러 없이 끝났다"를 "글이 올라갔다"로 착각한 거죠.

원고 생성→파일 저장→커밋→push(변경 없음, 조용히 통과)→status=success (그러나 게시 0건)

상태값 말고 표면을 믿기

돌려 보고 내린 결론은 하나였어요. 실행 상태(status)가 아니라 실제 결과물(표면)을 확인해야 한다는 것.

그래서 발행 뒤에 점검 3단계를 붙였어요. 첫째, 방금 올라와야 할 글의 공개 주소를 실제로 요청해서 HTTP 200이 오는지 봐요. 둘째, 응답 본문에 오늘 날짜와 제목이 들어 있는지 확인해요. 파일이 있어도 배포가 안 됐으면 여기서 걸려요. 셋째, 이 검증이 실패하면 그때 진짜 실패로 처리해서 알림이 오게 했어요.

배포에는 몇 초 시간이 걸리니 확인 전에 5초 정도 기다리게 했고, 네트워크 흔들림을 감안해 재시도는 3회까지만 뒀어요.

• ✓상태값 아닌 표면 확인
• ✓HTTP 200과 본문 대조
• ✓실패는 조용히 넘기지 않기

며칠 돌려 보니

이 점검을 적용해 봤더니, 며칠 뒤 같은 문제가 딱 한 번 재발했는데 이번엔 곧바로 알림이 왔어요. 예전 같으면 초록불에 묻혀 며칠 지나서야 알아챘을 거예요. 사람이 매번 블로그를 새로고침하며 확인할 필요가 없어진 게 제일 컸어요.

혼자 운영하다 보면 "일단 돌아가니까 됐다"로 넘어가기 쉬운데, 그 자동화가 만드는 결과물을 직접 눈으로 다시 보는 한 줄이 결국 시간을 아껴 줬어요. 플랜씨(plan-c)나 플랜엘(plan-l) 같은 서비스의 다른 배치 작업에도 같은 표면 점검을 하나씩 붙여 두는 중이에요.

성공이라는 초록불은 시작점이지 결승선이 아니에요. 자동화를 하나 만들 때마다 "정말 됐는지 무엇으로 확인할까"를 같이 정해 두면, 나중에 조용히 새는 일이 훨씬 줄어들어요.