발행 버튼을 자동화하지 않기로 한 이유

블로그 운영 흐름을 자동화하다 보면 마지막에 꼭 한 번 유혹이 옵니다. 글감도 뽑고, 목차도 만들고, 초안도 쓰고, 내부 링크 후보까지 찾았는데 발행 버튼도 그냥 자동으로 누르면 안 될까 하는 생각입니다.

저도 Daejin Lab을 만들면서 그 생각을 했습니다. 특히 글을 30개, 40개 가까이 늘리다 보면 사람이 매번 확인하는 시간이 꽤 걸립니다. 그래도 지금은 자동 발행을 막아두고 있습니다. 초안은 도구 도움을 받더라도, 공개 판단은 사람이 해야 한다고 봤기 때문입니다.

자동 발행을 막아둔 이유

가장 큰 이유는 수습 비용입니다. 글 하나를 빨리 올리는 이득보다, 잘못 올라간 글을 나중에 지우고 고치는 비용이 더 컸습니다.

제가 특히 찝찝하게 본 부분은 아래였습니다.

확인하지 않은 사실이 경험처럼 쓰일 수 있다
직접 해보지 않은 설정이 성공 사례처럼 보일 수 있다
가격이나 정책 정보가 오래된 상태로 남을 수 있다
내부 링크가 문맥과 다르게 붙을 수 있다
민감한 경로나 설정값이 섞일 수 있다

개발·블로그 운영 글은 명령어와 파일 경로가 자주 들어갑니다. 대충 보면 별것 아닌 문장도, 공개된 뒤에는 검색엔진에 캐시될 수 있습니다. 나중에 고쳐도 흔적이 남을 수 있다는 점이 부담스러웠습니다.

자동화해도 되는 일

자동 발행을 막는다고 해서 모든 일을 손으로 하겠다는 뜻은 아닙니다. 오히려 반복 확인은 도구가 더 잘합니다.

Daejin Lab에서는 이런 일은 자동화 후보로 봅니다.

글감 목록 정리
frontmatter 형식 점검
카테고리와 태그 후보 찾기
관련 글 후보 찾기
내부 링크가 없는 글 찾기
짧은 글 후보 뽑기
빌드 검증 실행
sitemap URL 개수 확인

예를 들어 글을 고친 뒤에는 npm run build로 빌드가 끝까지 통과하는지 봅니다. 커스텀 도메인으로 옮긴 뒤에는 https://daejinlab.com/sitemap.xml과 대표 글 canonical이 같은 도메인을 가리키는지도 직접 봤습니다.

이런 확인은 사람이 매번 눈으로 세는 것보다 도구가 낫습니다. 반복적이고 기준이 분명하기 때문입니다.

사람이 마지막에 봐야 하는 일

반대로 아래는 아직 사람 몫으로 남겨두고 있습니다.

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

특히 마지막 질문이 중요했습니다. 빌드가 성공했다고 좋은 글은 아닙니다. sitemap에 들어갔다고 수익형 글이 되는 것도 아닙니다.

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

이번 작업에서 선을 더 분명히 했다

Search Console 대응을 하면서 이 기준이 더 분명해졌습니다. sitemap 파일은 공개 URL, XML 파싱, Googlebot 유사 요청까지 정상인데 Search Console 화면만 늦게 바뀌는 상황이 있었습니다.

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

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

도구는 빠르게 고칠 수 있습니다. 문제는 빠르게 고치는 게 항상 좋은 판단은 아니라는 점입니다. 이 경우에는 “사이트 쪽 조건은 통과했으니 멈추고 기다린다”가 더 나은 판단이었습니다.

이건 사람이 봐야 했습니다. 자동화는 확인을 빠르게 해주지만, 멈출 시점을 정해주지는 않습니다.

지금 쓰는 운영선

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

초안: 도구 도움을 받을 수 있음
검수: 사람이 직접 읽고 수정
배포 전 확인: npm run build
배포: GitHub push 후 Cloudflare 반영 확인
Search Console: 화면보다 공개 파일과 canonical을 먼저 확인

이 흐름이면 속도는 조금 느립니다. 대신 글이 “급하게 찍어낸 문서”처럼 보일 가능성은 줄어듭니다.

사실 AdSense를 생각하면 이 부분이 더 중요하다고 봅니다. 글 수만 많고 운영자의 판단이 보이지 않으면, 개인 블로그라기보다 운영자 목소리 없는 사이트처럼 보일 수 있습니다. 그래서 지금은 새 글을 계속 늘리기보다 대표 글을 경험형으로 고치는 작업을 같이 하고 있습니다.

같이 묶어 보는 글

이 운영선은 아래 글들과 같이 볼 때 더 분명합니다.

블로그 초안 검수 체크리스트에서는 공개 전 문장·사실·링크를 보는 방법을 따로 적었습니다.
Cloudflare Pages 배포 후 확인 체크리스트에서는 글을 고친 뒤 실제로 확인할 URL과 빌드 순서를 적었습니다.
블로그 글 내부 SEO와 관련 글 연결에서는 자동 추천보다 문맥에 맞는 내부 링크가 중요한 이유를 다뤘습니다.

블로그를 키우겠다고 마음먹으면 글 수를 빨리 늘리고 싶어집니다. 저도 그 마음이 있습니다. 그런데 바로 그 지점 때문에 자동 발행을 막아두는 글이 필요했습니다.

AdSense 심사에서 정확히 어떤 글을 사람이 읽을지는 알 수 없습니다. 다만 사이트 전체가 운영자 목소리 없는 글처럼 보이면 불리하다고 봅니다. 그래서 이 글은 정책 설명이 아니라 운영자의 약속에 가깝습니다. 도구 도움은 받지만, 공개 버튼은 사람이 누른다는 선을 보여주는 글입니다.

마지막 버튼은 남겨두기로 했다

자동 발행을 막아둔 건 기술적으로 못해서가 아닙니다. 오히려 할 수 있을 것 같아서 더 조심했습니다. 글이 공개되는 순간부터는 제 이름이 붙습니다. 그래서 초안 작성과 발행 사이에는 사람이 한 번 불편하게 읽는 시간이 필요하다고 봅니다.

다음에도 자동화할 일은 있습니다. 초안 작성, 내부 링크 후보, 빌드 검증, sitemap 확인은 계속 줄일 생각입니다. 대신 발행 버튼은 아직 남겨둡니다. 반복 확인을 덜어내서 마지막 판단에 쓸 시간을 남기는 것이, 지금 Daejin Lab에 맞는 자동화입니다.

2026-05-31에 다시 본 마지막 버튼의 의미

AdSense 거절 뒤 이 글의 중요도는 더 커졌습니다. 저가치 콘텐츠 문제를 고치려면 글을 많이 찍어내는 방향으로 가기 쉽습니다. 하지만 Daejin Lab에서는 그 반대로 갔습니다. 새 글을 대량으로 만들기보다 기존 공개 글을 다시 읽고, 출처와 한계와 검증 흔적을 보강했습니다.

AI 초안, 민감정보 검수, publish gate, 사람 승인으로 이어지는 수동 발행 게이트

이 카드는 발행 자동화를 막아둔 이유를 보여줍니다. 초안과 점검은 도구가 도울 수 있지만, 공개 결정은 사람이 남깁니다.

자동 발행을 막는 것은 속도를 포기한다는 뜻이 아닙니다. 잘못된 공개를 줄이는 장치입니다. 특히 블로그 repo는 git push가 곧 배포로 이어지기 때문에, push 전에는 draft, secret, 내부 경로, 출처, 이미지 권리, sitemap/RSS를 같이 봐야 합니다. 이 과정이 번거롭더라도 사이트 신뢰를 지키는 데 필요했습니다.

참고한 공식 문서

공식 문서는 공개 전 확인해야 할 위험을 분리하는 데 봅니다. 이 글의 판단은 Daejin Lab의 운영선입니다. 자동화가 가능해도 공개 책임까지 넘기지는 않습니다.

확인하지 않은 것

이 글은 모든 예약 발행이나 CI/CD를 금지한다는 뜻이 아닙니다. 다만 현재 Daejin Lab 단계에서는 자동 발행보다 수동 승인 게이트가 더 안전하다고 봅니다. 규모가 커지면 승인 절차를 도구화할 수는 있지만, 승인 자체를 없애지는 않을 생각입니다.

FAQ

자동 발행을 막으면 운영이 느려지지 않나요?

조금 느려집니다. 하지만 잘못 공개된 글을 지우고 수습하는 비용이 더 큽니다. 지금은 느린 공개가 더 안전합니다.

AI가 쓴 초안도 쓸 수 있나요?

쓸 수 있습니다. 다만 공개 전에는 사람이 사실, 출처, 민감정보, 톤을 다시 봐야 합니다.

저가치 콘텐츠를 피하려면 자동 생성처럼 보이는 대량 발행보다, 검수된 경험형 글을 남기는 편이 더 낫습니다.