AI 블로그 자동화에서 공개 전 점검 큐를 운영하는 법

요약

Futory처럼 AI가 평일마다 Markdown 글을 만들고 Next.js 빌드, PM2 재시작, 공개 검증까지 이어 가는 블로그에서는 “무엇을 쓸까”만큼 “무엇을 확인하고 넘어갈까”가 중요합니다. 자동화가 빠르게 움직일수록 작은 누락이 뒤늦게 공개 장애로 보일 수 있습니다. 공개 전 점검 큐는 새 글 작성, 콘텐츠 검증, 빌드, 런타임 반영, 공개 확인을 한 줄씩 통과시키는 운영 장치입니다.

점검 큐의 핵심은 복잡한 승인 절차가 아니라 반복 가능한 순서입니다. 오늘 KST 날짜의 글이 이미 있는지 확인하고, 최근 주제와 겹치지 않는 제목을 고른 뒤, content/posts를 백업하고, 새 Markdown 파일 하나만 추가합니다. 그 다음 콘텐츠 테스트와 테마 테스트, 빌드, .next 산출물 확인, PM2 재시작, 공개 URL 검증을 차례로 진행합니다. 바이브코딩은 즉흥성과 속도를 살리지만, 운영에서는 이 속도가 안전한 레일 위에서 움직여야 합니다.

공개 전 점검 큐가 필요한 이유

자동 발행은 여러 단계가 연결된 파이프라인입니다. 글 본문은 좋아도 frontmatter의 날짜가 잘못되면 목록에서 빠질 수 있고, 파일은 있어도 빌드가 실패하면 공개되지 않습니다. 빌드가 성공해도 런타임 프로세스가 새 산출물을 읽지 않으면 독자는 이전 상태를 봅니다. 점검 큐는 이 연결 고리를 보이게 만들어, 실패했을 때 어디에서 멈췄는지 바로 설명할 수 있게 합니다.

중복 발행을 먼저 막는다

가장 앞에 와야 할 항목은 중복 방지입니다. Futory의 기준은 KST 날짜입니다. frontmatter나 파일명에 오늘 날짜가 이미 있으면 새 글을 만들지 않습니다. 이 규칙은 단순하지만 크론이 하루에 여러 번 실행되는 환경에서는 매우 중요합니다. 같은 날짜 글이 둘 이상 생기면 어떤 글을 공개 목록에 남길지, 어떤 글을 운영 기록의 기준으로 삼을지 불필요한 판단이 생깁니다.

주제 겹침을 줄인다

중복 날짜가 없더라도 최근 글과 주제가 지나치게 비슷하면 독자에게는 반복처럼 느껴집니다. 그래서 새 글을 만들기 전에는 최근 며칠의 제목과 요약을 훑어야 합니다. 예를 들어 멱등 발행, 공개 증거 묶음, 인수인계 메모를 이미 다뤘다면 오늘은 그 사이에 놓이는 “점검 큐”처럼 다른 운영 관점을 선택할 수 있습니다. 같은 시스템을 다루더라도 관점을 바꾸면 연재의 밀도가 높아집니다.

Futory에 맞는 점검 큐 설계

점검 큐는 사람에게도 읽히고 자동화에도 맞아야 합니다. 항목 이름은 짧고 결과는 명확해야 합니다. 성공, 실패, 건너뜀을 구분할 수 있으면 충분합니다.

작성 전 큐

작성 전 큐에는 세 가지가 들어갑니다. 첫째, 오늘 날짜의 기존 글 검색입니다. 둘째, 최근 글의 제목과 태그 확인입니다. 셋째, content/posts 백업입니다. 이 세 항목이 끝나야 새 파일을 만듭니다. 특히 백업은 “나중에 필요하면 하자”가 아니라 쓰기 직전의 고정 단계여야 합니다. 자동화가 기존 파일을 수정하지 않는다고 해도, 라이브 콘텐츠 트리에 새 파일을 추가하는 순간 복구 기준점이 필요합니다.

작성 후 큐

작성 후 큐는 새 파일 하나를 기준으로 움직입니다. frontmatter에 title, description, date, category, tags가 들어갔는지 확인하고, 본문에는 ## 요약, 여러 개의 H2와 H3, ## 자주 묻는 질문, ## 결론이 있는지 봅니다. 이 구조가 일정하면 독자는 익숙한 흐름으로 글을 읽고, 자동화는 콘텐츠 테스트에서 같은 기준을 적용할 수 있습니다.

공개 큐

공개 큐는 로컬 성공과 공개 성공을 분리합니다. npm run test:content와 npm run test:theme은 글과 테마 규칙을 확인하고, npm run build는 Next.js 산출물을 만듭니다. 그 뒤 .next 안에서 새 slug가 발견되어야 빌드가 실제로 새 글을 포함했다는 증거가 됩니다. 마지막으로 PM2를 재시작하고, 상세 URL과 목록 페이지를 캐시 우회 옵션으로 읽어 공개 상태를 확인합니다.

점검 큐를 운영 기록으로 남기는 법

점검 큐는 실행 중에만 쓰고 버리는 체크리스트가 아닙니다. 매일의 결과 보고에 그대로 남기면 다음 실행의 기준선이 됩니다. 제목, 날짜, 파일 경로, 공개 URL, 선택된 발행 시간, 테스트와 빌드 결과, PM2 재시작 상태, 공개 검증 상태를 같은 순서로 남기면 운영자는 긴 로그를 다시 열지 않아도 됩니다.

실패 보고도 큐 기준으로 한다

실패가 생기면 “안 됨”이라고 쓰기보다 어느 큐에서 멈췄는지 적어야 합니다. 콘텐츠 테스트 실패라면 PM2 재시작을 하지 않았다고 명시하고, 빌드 산출물 확인 실패라면 공개 URL 검증 전 단계에서 멈췄다고 남깁니다. 이렇게 하면 다음 재시도는 새 글을 또 만드는 대신 이미 만들어진 파일과 실패 지점을 기준으로 이어 갈 수 있습니다.

성공 보고는 짧아도 된다

모든 단계가 통과한 날의 보고는 길 필요가 없습니다. 다만 값은 빠지면 안 됩니다. 어떤 slug가 공개되었고, 어떤 명령이 통과했으며, 어느 URL에서 200을 확인했는지가 핵심입니다. 짧지만 같은 형식의 성공 보고가 쌓이면 자동화의 신뢰도도 함께 쌓입니다.

자주 묻는 질문

점검 큐가 발행 속도를 늦추지 않나요?

각 항목은 이미 발행에 필요한 확인입니다. 큐로 만들면 새 일이 늘어나는 것이 아니라 흩어진 확인을 순서대로 묶는 효과가 납니다. 오히려 실패 원인을 빨리 좁힐 수 있어 전체 운영 시간은 줄어듭니다.

매일 다른 글을 쓰는데 같은 큐를 써도 되나요?

네. 글의 주제는 달라도 Futory의 운영 경로는 같습니다. Markdown 파일, frontmatter, 테스트, 빌드, PM2 재시작, 공개 검증이라는 흐름이 유지되는 한 같은 큐를 반복하는 편이 안전합니다.

공개 URL만 200이면 충분하지 않나요?

상세 URL 200은 중요한 신호지만 충분하지는 않습니다. 홈, /posts, /vibe-coding 같은 목록 페이지에 오늘 날짜나 slug가 보이는지도 확인해야 독자가 실제 탐색 경로에서 새 글을 찾을 수 있습니다.

결론

공개 전 점검 큐는 AI 블로그 자동화를 느리게 만드는 문서가 아니라, 빠른 발행을 운영 가능한 형태로 고정하는 안전장치입니다. 오늘 날짜 중복 검사, 최근 주제 확인, 백업, 새 파일 작성, 테스트, 빌드, 산출물 확인, PM2 재시작, 공개 검증을 같은 순서로 반복하면 Futory의 평일 발행은 더 조용하고 예측 가능해집니다. 바이브코딩의 장점은 즉시 실행하는 데 있지만, 반복 운영의 품질은 그 실행을 매일 같은 기준으로 증명하는 데서 완성됩니다.