자동 발행 확인, HTTP 200만 믿으면 안 되는 이유

자동화 스크립트가 성공이라고 기록했는데 정작 화면에는 글이 없다면 어떨까요. 혼자 시스템을 운영하면서 제일 무서운 건 실패가 아니라, 성공처럼 보이는 실패더라고요.

성공 로그가 증명하지 못하는 것

라이프케어로그 블로그는 초안 생성부터 발행까지 스크립트로 굴러가요. 플랜비(plan-b) 같은 제품을 만드는 틈틈이 글까지 손으로 올리기는 어려워서, 반복을 줄이려고 만든 구조예요.

그런데 발행 파이프라인을 직접 만들어 보니 확인 단계에 빈틈이 보였어요. 발행 명령이 에러 없이 끝나면 성공으로 기록하는 방식이었거든요. 명령이 끝났다는 사실과 독자가 글을 볼 수 있다는 사실은 전혀 다른 이야기인데도요.

그래서 8월 14일 커밋에서 발행 확인 로직을 교체했어요. 수정한 파일은 발행 스크립트, 표면 확인 스크립트, 테스트까지 3개예요.

먼저 글별 URL을 확인해요. 목록 페이지가 아니라 방금 발행한 글의 주소가 HTTP 200을 돌려주는지 봐요. 목록이 멀쩡해도 개별 글 페이지는 빌드에서 빠질 수 있거든요.

다음은 본문 렌더 확인이에요. 200이 와도 본문이 비어 있을 수 있어서, 응답 안에 글 내용이 실제로 담겼는지까지 봐요. 상태 코드는 서버가 뭔가 돌려줬다는 뜻이지, 독자가 글을 읽을 수 있다는 뜻은 아니니까요.

발행 실행글별 URL 200 확인본문 렌더 확인

확인 스크립트 자체가 망가지면 다시 원점이라, 이 스크립트를 검사하는 테스트 파일 1개도 같이 추가했어요. 테스트를 돌려 보니 감시자를 감시하는 코드가 생긴 셈이라 마음이 놓이더라고요.

적용해 봤더니 성공 메시지를 읽는 눈도 달라졌어요. 로그를 볼 때마다 이 메시지가 무엇을 증명하고 무엇을 증명하지 못하는지 먼저 따지게 됐거든요.

작은 도구일수록 이 차이가 커요. 플랜씨(plan-c) 금융계산기처럼 로그인 없이 바로 쓰는 도구는 사용자가 보는 화면이 곧 제품이라, 확인도 화면 기준으로 하는 습관을 들이려고 해요.

자동화가 늘수록 성공 메시지도 늘어요. 성공 메시지는 주장이고 화면이 증거예요. 여러분의 자동화는 지금 무엇을 증명하고 있나요?