블로그 운영을 자동화하다 보면 끝까지 자동으로 보내고 싶어집니다. 글감 정리, 목차 작성, 초안 생성, 내부 링크 추천까지 이어지면 “발행 버튼도 자동으로 누르면 되지 않을까?”라는 생각이 자연스럽게 듭니다.

Daejin Lab에서는 그 선을 넘기지 않기로 했습니다. 초안 작성은 자동화해도, 최종 발행은 사람이 봐야 합니다.

자동 발행을 막아둔 이유

이유는 단순합니다. 글이 올라가는 속도보다, 잘못 올라간 글을 다시 수습하는 비용이 더 큽니다.

확인하지 않은 사실이 들어갈 수 있다.
직접 해보지 않은 일이 경험처럼 보일 수 있다.
정책이나 가격 정보가 오래된 상태로 남을 수 있다.
내부 링크가 문맥과 맞지 않을 수 있다.
민감한 설정값이 섞일 수 있다.

특히 개발·블로그 운영 글은 파일 경로, 명령어, 서비스 설정이 자주 들어갑니다. 한 번 실수하면 검색엔진에 캐시될 수도 있고, 나중에 어디서 새어 나갔는지 찾기도 번거롭습니다.

자동화해도 되는 부분

자동 발행을 막는다고 해서 모든 일을 손으로 하겠다는 뜻은 아닙니다. 오히려 반복 작업은 적극적으로 줄이려고 합니다.

글감 목록 정리
frontmatter 형식 점검
카테고리·태그 후보 찾기
관련 글 후보 찾기
빌드 검증 실행
sitemap URL 개수 확인

이런 작업은 규칙이 분명합니다. 사람이 매번 눈으로 세는 것보다 도구가 더 잘합니다.

Daejin Lab에서도 글을 수정한 뒤에는 npm run build로 42개 페이지가 만들어지는지 확인하고, sitemap에 42개 URL이 들어가는지 봤습니다. 이런 검증은 자동화할수록 좋습니다.

사람이 봐야 하는 부분

반대로 아래는 사람이 마지막에 확인해야 합니다.

제목이 과장되지 않았는가
내 경험과 조사 내용이 구분되는가
확실하지 않은 정보를 단정하지 않았는가
광고·제휴 고지가 필요한가
글의 톤이 사이트 성격과 맞는가

예를 들어 “Search Console 오류를 해결했다”라고 쓰려면 실제로 무엇을 확인했는지 같이 적어야 합니다. 공개 URL이 200인지, Googlebot 요청이 되는지, XML 파싱이 되는지 정도는 봐야 글이 기록이 됩니다.

지금 쓰는 운영선

현재 운영선은 이렇게 잡았습니다.

초안: 도구 도움을 받을 수 있음
검수: 사람이 직접 읽고 수정
배포 전 확인: npm run build
배포: GitHub push 후 Cloudflare 반영 확인
Search Console: 바로 성공하지 않으면 파일 상태부터 재확인

이 흐름이면 속도는 조금 느려집니다. 대신 글이 “대량으로 뿌린 초안”처럼 보일 가능성은 줄어듭니다.

이번 작업에서 더 엄격하게 둔 선

이번 Search Console 대응에서도 자동 발행을 막아둔 이유가 드러났습니다. sitemap 파일은 공개 URL, XML 파싱, Googlebot 유사 요청까지 정상인데 Search Console 화면만 늦게 바뀌고 있었습니다.

이때 자동화가 위험한 방향은 계속 파일을 바꾸는 것입니다.

sitemap.xml을 다시 생성한다.
sitemap.txt를 제출해본다.
robots.txt를 또 바꾼다.
canonical을 흔든다.

반대로 사람이 해야 할 판단은 “사이트 쪽 조건은 통과했으니 멈추고 기다린다”였습니다. 자동화는 확인을 빠르게 해주지만, 멈출 시점을 정하는 일은 아직 운영자가 봐야 합니다.

지금 운영 기준

블로그 자동화의 목적은 사람이 사라지는 것이 아니라, 사람이 봐야 할 부분에 시간을 남기는 것입니다. Daejin Lab에서는 초안과 검증은 최대한 효율화하되, 발행 판단만큼은 계속 사람이 하기로 했습니다.