AI 블로그 자동화에서 배포 준비 표시를 남기는 법

요약

Futory처럼 AI가 평일마다 Markdown 글을 만들고 Next.js 빌드, PM2 재시작, 공개 검증까지 이어 가는 블로그에서는 “파일이 생겼다”와 “공개해도 된다”를 구분해야 합니다. 새 글 파일이 존재한다고 해서 곧바로 독자가 읽을 수 있는 상태는 아닙니다. frontmatter가 맞아야 하고, 콘텐츠 규칙을 통과해야 하며, 테마와 빌드가 깨지지 않아야 하고, 런타임 프로세스가 새 산출물을 읽어야 합니다. 배포 준비 표시는 이 단계를 한 번에 섞지 않고, 현재 상태가 어디까지 왔는지 짧게 남기는 운영 습관입니다.

이 표시는 거창한 관리 시스템이 아니어도 됩니다. 오늘 날짜, slug, 백업 경로, 테스트 통과 여부, 빌드 산출물 포함 여부, PM2 재시작 여부, 공개 URL 확인 여부를 같은 순서로 보고하면 충분합니다. 바이브코딩은 빠른 실행을 좋아하지만, 반복 발행에서는 빠른 실행을 안전하게 멈추고 이어 갈 수 있어야 합니다. 배포 준비 표시가 있으면 실패한 날에도 새 글을 다시 만들지 않고, 이미 준비된 파일을 기준으로 다음 조치를 결정할 수 있습니다.

배포 준비 표시가 필요한 이유

자동 발행에서 가장 위험한 순간은 단계가 애매하게 섞일 때입니다. 파일은 만들어졌지만 빌드가 실패했는데 다음 실행이 같은 날짜 글을 또 만들거나, 빌드는 성공했지만 PM2 재시작이 실패했는데 공개 검증 실패를 글 내용 문제로 착각할 수 있습니다. 배포 준비 표시는 이런 오판을 줄입니다.

작성 완료와 공개 완료는 다르다

작성 완료는 Markdown 파일이 생기고 frontmatter와 본문 구조가 요구사항을 만족하는 상태입니다. 공개 완료는 그 파일이 빌드 산출물에 포함되고, 런타임에 반영되며, 실제 공개 URL과 목록 페이지에서 확인된 상태입니다. 두 상태 사이에는 테스트, 빌드, 재시작, 캐시 우회 검증이 놓여 있습니다. 이 차이를 보고에 남기면 운영자는 어떤 단계를 재시도해야 하는지 바로 알 수 있습니다.

중복 방지의 기준이 된다

Futory의 반복 크론은 KST 기준 오늘 날짜 글이 frontmatter나 파일명에 있으면 새 글을 만들지 않는 규칙을 가집니다. 이 규칙은 배포 준비 표시와 함께 쓸 때 더 강해집니다. 예를 들어 오늘 파일이 있지만 빌드가 실패했다면 새 글을 또 쓰는 것이 아니라 해당 파일의 검증 문제를 해결해야 합니다. 날짜 중복 검사는 “이미 공개됐다”는 뜻이 아니라 “오늘의 작업 대상은 이미 정해졌다”는 뜻으로 읽어야 합니다.

Futory에서 쓸 수 있는 표시 항목

배포 준비 표시는 사람이 빨리 읽고 자동화가 쉽게 검증할 수 있어야 합니다. 항목이 많아 보이더라도 매번 같은 순서라면 오히려 운영 부담은 줄어듭니다.

1. 원천 파일 표시

첫 번째 표시는 파일 경로와 slug입니다. /opt/futory/content/posts/<slug>.md가 오늘 작업의 원천이고, 공개 URL은 https://futory.oig.kr/posts/<slug>가 됩니다. 제목과 날짜도 함께 남겨야 합니다. 제목은 사람이 내용을 이해하는 단서이고, 날짜는 중복 방지와 목록 정렬의 기준입니다.

2. 검증 통과 표시

두 번째 표시는 검증 명령입니다. npm run test:content는 frontmatter, 본문 구조, 콘텐츠 규칙을 확인합니다. npm run test:theme는 테마가 새 콘텐츠를 받아도 깨지지 않는지 확인합니다. npm run build는 Next.js가 실제 배포 산출물을 만들 수 있는지 확인합니다. 세 명령 중 하나라도 실패하면 그 뒤 단계의 표시는 비워 두고 첫 실패를 보고해야 합니다.

3. 런타임 반영 표시

세 번째 표시는 빌드 이후입니다. .next 안에서 새 slug가 발견되면 빌드 산출물에 글이 포함되었다는 증거가 됩니다. 그 다음 PM2 재시작이 성공해야 실행 중인 앱이 새 빌드를 읽을 가능성이 높아집니다. 마지막으로 상세 URL, 홈, /posts, /vibe-coding 목록을 캐시 우회 옵션으로 읽어 오늘 날짜나 slug가 보이는지 확인합니다.

실패했을 때 표시를 활용하는 법

배포 준비 표시는 성공 보고보다 실패 보고에서 더 큰 가치를 냅니다. 실패한 단계가 표시되어 있으면 다음 실행은 처음부터 모든 일을 반복하지 않아도 됩니다.

첫 실패에서 멈춘다

콘텐츠 테스트가 실패했다면 빌드하지 않습니다. 빌드가 실패했다면 PM2를 재시작하지 않습니다. PM2 재시작이 실패했다면 공개 검증 결과가 오래된 런타임을 보고 있을 수 있음을 함께 적습니다. 자동화는 끝까지 밀어붙이는 도구가 아니라, 위험해지는 지점에서 정확히 멈추는 운영자여야 합니다.

재시도는 같은 slug를 기준으로 한다

실패 후 재시도할 때 가장 중요한 것은 같은 날짜에 새 slug를 만들지 않는 것입니다. 이미 오늘의 작업 파일이 있다면 그 파일을 기준으로 검증과 배포를 다시 이어 가야 합니다. 이렇게 하면 공개 목록에 비슷한 글이 여러 개 생기는 일을 막고, 보고 기록도 하나의 흐름으로 연결됩니다.

자주 묻는 질문

배포 준비 표시를 별도 파일로 저장해야 하나요?

처음에는 크론의 최종 보고만으로 충분합니다. 다만 장기적으로 운영 지표를 보고 싶다면 날짜, slug, 실패 단계, 공개 URL, PM2 재시작 결과만 별도 로그로 축적할 수 있습니다. 중요한 것은 저장 위치보다 매번 같은 항목을 빠뜨리지 않는 일입니다.

상세 URL이 200이면 모든 표시가 끝난 건가요?

아닙니다. 상세 URL 200은 글 자체가 접근 가능하다는 강한 신호지만, 홈이나 /posts, /vibe-coding 목록에 보이는지도 확인해야 합니다. 독자는 상세 링크뿐 아니라 목록을 통해 글을 찾기 때문에 공개 완료 표시는 탐색 가능성까지 포함해야 합니다.

표시 항목이 많으면 자동화가 느려지지 않나요?

대부분의 항목은 어차피 안전한 발행을 위해 필요한 확인입니다. 표시로 남기면 일이 늘어나는 것이 아니라 결과가 선명해집니다. 실패 원인을 빨리 좁힐 수 있으므로 전체 운영 시간은 오히려 줄어듭니다.

결론

AI 블로그 자동화에서 배포 준비 표시는 빠른 발행을 느리게 만드는 절차가 아니라, 빠른 발행을 안전하게 반복하기 위한 상태 언어입니다. Futory의 Next.js Markdown 흐름에서는 원천 파일, 검증 통과, 빌드 산출물, PM2 재시작, 공개 URL과 목록 확인을 분리해 남겨야 합니다.

바이브코딩의 장점은 즉시 만들고 실행하는 데 있지만, 운영 자동화의 품질은 그 실행이 어디까지 준비되었는지 설명할 수 있을 때 완성됩니다. 매일 같은 기준으로 배포 준비 표시를 남기면 중복 발행은 줄고, 실패 지점은 작아지며, Futory의 평일 발행 루틴은 더 예측 가능한 시스템으로 유지됩니다.