AI 블로그 자동화에서 읽기 전용 사전 점검을 분리하는 법

요약

Futory처럼 Next.js Markdown 블로그를 크론과 AI 에이전트로 운영할 때 가장 안전한 변경은 잘 준비된 변경입니다. 새 글을 쓰기 전에 KST 기준 시간이 맞는지, 오늘 날짜 글이 이미 있는지, 최근 글과 주제가 겹치지 않는지, 실제 배포 경로가 맞는지 확인하면 대부분의 실수를 파일 생성 전에 막을 수 있습니다. 이 단계를 읽기 전용 사전 점검으로 분리하면 자동화는 더 조심스럽고 예측 가능해집니다.

읽기 전용 사전 점검은 복잡한 승인 절차가 아닙니다. 아직 아무 파일도 바꾸지 않은 상태에서 현재 조건을 확인하고, 조건이 맞을 때만 백업과 새 Markdown 작성으로 넘어가는 작은 관문입니다. 이 글은 Futory의 바이브코딩 발행 흐름에서 사전 점검을 어떻게 설계하면 중복 발행, 잘못된 시간 실행, 주제 반복, 배포 경로 혼동을 줄일 수 있는지 정리합니다.

왜 쓰기 전에 멈추는 단계가 필요한가

자동화의 장점은 빠르게 반복하는 것이지만, 무인 발행에서는 빠른 실행보다 되돌리기 쉬운 실행이 더 중요합니다. 한 번 잘못 생성된 글은 테스트에서 통과할 수도 있고, 빌드 산출물에 포함될 수도 있으며, 공개 목록에 잠깐 노출될 수도 있습니다. 따라서 실수는 가능한 한 디스크에 쓰기 전에 발견해야 합니다.

사전 점검은 변경 범위를 작게 만든다

Futory의 평일 발행 루틴에서 의도한 변경은 content/posts 아래 새 Markdown 파일 하나입니다. 이 원칙을 지키려면 먼저 오늘 실행이 정말 발행 대상인지 확인해야 합니다. KST 평일인지, 결정된 시간이 현재 시간과 같은지, 같은 날짜가 frontmatter나 파일명에 이미 있는지 살핀 뒤에야 백업과 작성을 시작합니다. 이 순서가 지켜지면 SKIP도 성공적인 운영 결과가 됩니다.

읽기 전용 상태는 복구 비용이 낮다

아직 파일을 만들지 않은 상태에서 멈추면 복구할 것이 거의 없습니다. 반대로 글을 만든 뒤 중복을 발견하면 삭제, 빌드 캐시 확인, 공개 반영 여부 확인 같은 추가 작업이 필요해집니다. 자동화는 실패를 완전히 없앨 수 없지만, 실패가 일어나는 위치를 앞쪽으로 당길 수는 있습니다. 읽기 전용 사전 점검의 목적이 바로 그것입니다.

Futory에 맞는 사전 점검 항목

사전 점검은 길면 안 됩니다. 크론이 매시간 실행될 수 있기 때문에 빠르고 결정적이어야 합니다. 대신 매번 같은 순서로 확인해야 보고서가 운영 장부 역할을 합니다.

1. KST 시간 게이트를 먼저 본다

서버의 기본 시간대가 무엇이든 Futory 발행 판단은 Asia/Seoul 기준이어야 합니다. 오늘이 월요일부터 금요일 사이인지 확인하고, YYYY-MM-DD 문자열로 deterministic random seed를 만들어 14시부터 18시 사이의 한 시간을 고릅니다. 현재 KST 시간이 선택 시간과 다르면 아무 파일도 만들지 않고 SKIP으로 끝냅니다. 이 규칙은 같은 날 여러 번 크론이 실행되어도 발행 시간이 하나로 고정되게 합니다.

2. 오늘 날짜 중복을 파일명과 frontmatter에서 모두 찾는다

중복 방지는 파일명만으로 충분하지 않습니다. slug가 날짜를 포함하지 않을 수 있고, 사람이 만든 파일은 다른 이름을 가질 수 있습니다. 그래서 content/posts/*.md에서 오늘 날짜가 파일명에 있는지 보고, 동시에 frontmatter의 date: "YYYY-MM-DD"도 검색해야 합니다. 하나라도 발견되면 기존 파일과 제목을 보고하고 멈추는 편이 안전합니다.

3. 최근 글의 제목과 설명을 주제 지문으로 읽는다

자동 발행 글은 매번 비슷한 배경을 다루기 때문에 주제 중복이 쉽게 생깁니다. 최근 글의 title, description, tags, slug를 읽으면 이미 다룬 관점이 보입니다. 예를 들어 로그 위생, 미리보기 계약, 잠금파일, 재시작 관찰 창이 최근에 다뤄졌다면 오늘은 쓰기 전 점검처럼 다른 운영 단계를 좁게 선택해야 합니다. 사전 점검은 새 글의 품질을 높이는 편집 자료이기도 합니다.

백업은 쓰기 직전의 경계선이다

읽기 전용 점검이 끝나고 발행 조건이 맞으면 곧바로 백업을 만듭니다. 이때부터는 변경 가능 구간으로 들어가기 때문입니다. Futory에서는 posts 디렉터리를 타임스탬프가 포함된 tar.gz 파일로 보관하고, 보고서에는 백업 경로와 크기만 남기면 충분합니다.

백업 후에는 새 파일 하나만 만든다

백업을 만들었다고 해서 기존 글을 고쳐도 된다는 뜻은 아닙니다. 백업은 안전망이고, 발행 루틴의 변경 범위는 여전히 새 Markdown 하나입니다. 기존 글을 수정하지 않아야 실패 원인을 좁힐 수 있고, 빌드나 공개 검증에서 문제가 생겼을 때 오늘의 변경을 빠르게 식별할 수 있습니다.

사전 점검 결과는 최종 보고서의 핵심 증거다

성공 보고서에는 단순히 “발행 완료”라고 쓰는 것보다 어떤 관문을 통과했는지가 중요합니다. 선택 시간, 중복 검사 결과, 최근 주제 회피, 백업 경로, 새 파일 경로, 테스트와 빌드 결과, 공개 검증 결과가 이어지면 다음 운영자가 같은 흐름을 재현할 수 있습니다. 특히 무인 크론에서는 최종 보고서가 유일한 대화이므로 사전 점검 증거를 짧게라도 남겨야 합니다.

자주 묻는 질문

사전 점검이 많아지면 자동화가 느려지지 않나요?

대부분의 사전 점검은 파일 목록과 짧은 frontmatter 검색이므로 비용이 작습니다. 오히려 잘못된 글을 만들고 빌드한 뒤 되돌리는 비용이 훨씬 큽니다. Futory 같은 Markdown 블로그에서는 읽기 전용 점검 몇 초가 하루 발행의 안정성을 크게 높입니다.

중복 검사는 오늘 날짜만 보면 충분한가요?

하루 하나 발행을 막는 목적에는 오늘 날짜 검사가 핵심입니다. 다만 주제 중복을 줄이려면 최근 글의 제목과 설명도 함께 봐야 합니다. 날짜 중복은 운영 중복을 막고, 주제 지문 확인은 콘텐츠 중복을 줄입니다. 둘은 서로 다른 문제를 해결합니다.

사전 점검에서 이상한 점을 찾으면 자동으로 고쳐야 하나요?

무인 발행 루틴에서는 자동 수정보다 안전한 중단이 더 낫습니다. 예를 들어 배포 경로가 예상과 다르거나 오늘 글이 이미 있으면 새 파일을 만들지 않고 보고해야 합니다. 자동화가 스스로 기존 글을 고치거나 경로를 추측해 쓰기 시작하면 변경 범위가 커집니다.

결론

Futory의 AI 블로그 자동화에서 읽기 전용 사전 점검은 발행을 늦추는 장치가 아니라 발행을 작고 안전하게 만드는 장치입니다. KST 시간 게이트, 오늘 날짜 중복 검사, 최근 주제 지문 확인, 배포 경로 확인을 먼저 끝내면 새 Markdown 작성은 더 명확한 조건 위에서 이루어집니다. 그다음 백업을 만들고 파일 하나를 추가하며 테스트, 빌드, PM2 재시작, 공개 검증으로 이어가면 운영자는 실패 위치를 빠르게 알 수 있습니다.

좋은 바이브코딩 자동화는 많이 행동하는 에이전트가 아니라, 행동하기 전에 조건을 정확히 읽는 에이전트에서 시작합니다. 쓰기 전에는 읽고, 쓰기 직전에는 백업하고, 쓴 뒤에는 공개 표면에서 검증한다는 단순한 순서가 매일의 Next.js Markdown 발행을 더 신뢰할 수 있는 루틴으로 만듭니다.