블로그 자동 발행 검증, 성공 로그 대신 URL로 확인하기

혹시 자동화 스크립트가 성공이라고 찍었는데, 정작 결과물이 안 보였던 적 없나요? 혼자 운영하면서 블로그 발행을 자동화해 두었는데, 저는 이 성공 로그를 어디까지 믿어야 할지 계속 고민이었어요.

스크립트가 성공을 반환하는 것과 독자가 실제로 글을 읽을 수 있는 건 다른 문제거든요. 중간 어디선가 조용히 어긋나도 로그에는 초록불이 켜질 수 있어요. 겉으로는 성공, 실제로는 실패인 상태죠.

확인 단계를 통째로 교체했어요

그래서 발행 스크립트의 마지막 확인 단계를 교체했어요. 새 기준은 두 가지예요. 글마다 URL이 200 응답을 주는지, 그리고 그 페이지에 본문이 실제로 렌더되는지.

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

200 확인만으로 끝내지 않은 이유가 있어요. 테스트해 보면 페이지가 200을 주면서도 본문이 비어 있는 경우를 만들 수 있거든요. 껍데기만 뜨고 내용은 빠진 상태죠. 그래서 응답 코드 확인과 본문 렌더 확인을 2단계로 나눠, 둘 다 통과해야 발행 완료로 쳐요.

이번 작업에서 손댄 파일은 3개예요. 발행 스크립트와 검사 스크립트 2개, 그리고 검사기 자체를 검증하는 테스트 1개. 직접 만들어 보니 검사기도 틀릴 수 있겠다는 생각이 들어서 테스트를 같이 붙였어요. 돌려 보니 검사 로직이 깨지면 테스트가 먼저 잡아주는 구조라 마음이 놓이더라고요.

같은 날, 같은 방향으로 3건

커밋 기록을 보니 이날 블로그 파이프라인에만 3건을 커밋했더라고요. 발행 확인 교체 말고도, 초안의 근거를 git 이력에서 뽑은 사실 시트로 고정했고, 거짓정보 게이트에는 결정론 검사와 근거 대조를 더했어요. 셋 다 방향은 같아요. 자동화가 스스로 내놓는 보고를 그대로 믿지 않고, 실제 표면을 다시 확인하는 것.

• ✓성공 로그 의심하기
• ✓실제 화면 기준으로 검증하기
• ✓검사기도 테스트하기

혼자 운영할수록 검사가 대신 봐줘야 해요

농구 동호회 운영 매니저인 플랜비(plan-b) 같은 서비스를 만들면서 블로그까지 챙기다 보면, 발행된 글을 매번 눈으로 열어 볼 여유가 없어요. 그래서 제 눈이 못 가는 자리에는 검사를 세워두는 편이에요. 적용해 봤더니 검사가 실패하면 발행이 완료로 처리되지 않으니, 문제가 조용히 넘어갈 틈이 줄어들어요.

됐다는 말 대신 보이는 화면을 믿는 것. 자동화를 오래 굴리고 싶다면 이 원칙 하나부터 챙겨보는 걸 권해요.