AI 블로그 자동화에서 발행 결정 로그를 남기는 법

요약

Futory처럼 평일마다 AI가 Markdown 글을 만들고 Next.js 빌드와 PM2 재시작, 공개 검증까지 수행하는 블로그에서는 결과 로그만큼 결정 로그가 중요합니다. 결과 로그가 “무엇이 성공했는가”를 말한다면, 결정 로그는 “왜 지금 실행했는가”와 “왜 멈췄는가”를 설명합니다. 자동화가 하루에 여러 번 실행되는 구조에서는 선택된 발행 시간, KST 기준 날짜, 기존 글 중복 여부, 최근 주제 확인, 백업 위치 같은 판단 근거가 남아야 다음 실행이 같은 기준을 반복할 수 있습니다.

발행 결정 로그는 긴 보고서가 아니어도 됩니다. 오늘이 평일인지, deterministic seed로 뽑힌 시간이 현재 시간과 일치하는지, 오늘 날짜 글이 이미 있는지, 어떤 주제를 피하고 어떤 주제를 선택했는지, 어느 파일을 새로 만들었는지를 같은 순서로 남기면 충분합니다. 바이브코딩은 빠르게 만들고 확인하는 방식이지만, 반복 운영에서는 빠른 결정이 설명 가능한 결정이어야 합니다. 결정 로그가 있으면 실패한 실행도 낭비가 아니라 다음 재시도의 기준선이 됩니다.

발행 결정 로그가 필요한 이유

자동 발행에서 가장 흔한 혼선은 “왜 지금 새 글이 생겼는지”를 나중에 알 수 없을 때 생깁니다. 크론은 정해진 시간대에 반복 실행되고, 네트워크나 빌드 상태에 따라 같은 날 여러 번 재시도될 수 있습니다. 이때 결정 근거가 없으면 운영자는 새 글이 정상적으로 한 번만 만들어졌는지, 실패 후 중복으로 만들어졌는지, 또는 이전 실행의 산출물을 다시 배포한 것인지 구분하기 어렵습니다.

실행 조건을 먼저 기록한다

Futory의 평일 발행 루틴은 KST 기준 월요일부터 금요일까지만 움직이고, 14시부터 18시 사이에서 날짜별로 하나의 선택 시간을 정합니다. 이 조건은 단순하지만 매우 강력한 중복 방지 장치입니다. 결정 로그에는 오늘 날짜, 요일, 현재 KST 시각, 선택된 시각을 함께 남기는 편이 좋습니다. 그러면 “오늘은 왜 건너뛰었는가”도 설명할 수 있고, “왜 이 시간에만 발행했는가”도 설명할 수 있습니다.

중복 검사 결과를 기록한다

선택 시간이 맞더라도 오늘 날짜 글이 이미 있으면 새 파일을 만들지 않아야 합니다. 이때 단순히 SKIP이라고 쓰는 것보다 기존 파일 경로와 제목을 함께 남기면 다음 확인이 쉬워집니다. frontmatter의 date와 파일명 검색은 발행 결정의 핵심 증거입니다. 자동화가 멱등하게 동작하려면 “이미 있다”는 판단도 성공적인 결정으로 취급해야 합니다.

Futory에 맞는 결정 로그 항목

결정 로그는 사람이 빠르게 읽을 수 있어야 하고, 자동화가 매번 같은 형식으로 만들 수 있어야 합니다. 항목이 많아 보이더라도 순서가 고정되면 오히려 운영 부담은 줄어듭니다.

1. 시간 결정

첫 항목은 시간 결정입니다. YYYY-MM-DD, KST 현재 시각, 선택된 발행 시각, 평일 여부를 남깁니다. 이 정보는 크론이 여러 시간대에 실행되는 구조에서 특히 중요합니다. 선택 시간이 아니라면 파일 시스템을 건드리지 않고 짧게 건너뛰어야 하며, 선택 시간이라면 다음 항목으로 넘어갈 수 있습니다.

2. 콘텐츠 결정

두 번째 항목은 콘텐츠 결정입니다. 최근 글의 제목과 설명을 훑어 보고, 오늘 다룰 관점을 정합니다. 예를 들어 최근에 배포 준비 표시, 공개 전 점검 큐, 변경 영향 반경을 다뤘다면 오늘은 그 앞단에 있는 “결정 로그”를 주제로 삼을 수 있습니다. 같은 Futory 운영 자동화를 다루더라도 관점이 다르면 독자에게는 반복이 아니라 연재의 확장으로 읽힙니다.

3. 변경 결정

세 번째 항목은 변경 결정입니다. 라이브 콘텐츠 트리에 손을 대기 전 content/posts를 백업하고, 기존 글은 수정하지 않으며, 새 Markdown 파일 하나만 추가한다는 원칙을 기록합니다. 이 항목은 실패했을 때 특히 유용합니다. 빌드가 실패해도 변경 범위가 새 파일 하나로 제한되어 있으면 원인 분석과 복구가 훨씬 단순해집니다.

실패와 재시도에서 결정 로그를 쓰는 법

결정 로그의 가치는 성공한 날보다 실패한 날 더 잘 드러납니다. 콘텐츠 테스트가 실패했는지, 빌드가 실패했는지, PM2 재시작이 실패했는지에 따라 다음 실행의 시작점이 달라지기 때문입니다.

첫 실패 지점을 남긴다

자동화는 모든 단계를 억지로 끝까지 밀어붙이면 안 됩니다. npm run test:content가 실패하면 테마 테스트와 빌드로 넘어가지 않고, 빌드가 실패하면 PM2를 재시작하지 않습니다. 결정 로그에는 어느 단계에서 멈췄는지와 그 이후 단계를 실행하지 않았다는 사실을 함께 남겨야 합니다. 그래야 다음 실행이나 사람이 개입하는 순간에 잘못된 공개 검증을 근거로 판단하지 않습니다.

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

실패 후 재시도할 때 새 제목과 새 slug를 다시 만들면 같은 날짜에 비슷한 글이 여러 개 생길 수 있습니다. 결정 로그에 오늘의 파일 경로와 slug가 남아 있으면 재시도는 그 파일을 기준으로 이어 갈 수 있습니다. 이는 발행 자동화에서 가장 현실적인 멱등성입니다. 완벽한 상태 저장소가 없더라도 날짜, slug, 파일 경로, 실패 단계를 남기는 것만으로 중복 가능성을 크게 줄일 수 있습니다.

자주 묻는 질문

결정 로그를 별도 데이터베이스에 저장해야 하나요?

처음에는 크론의 최종 보고만으로 충분합니다. 중요한 것은 저장소의 종류가 아니라 매번 같은 판단 항목이 빠지지 않는 일입니다. 나중에 운영 지표가 필요해지면 날짜, 선택 시각, slug, 실패 단계, 공개 URL 정도만 별도 로그 파일이나 테이블로 옮기면 됩니다.

SKIP도 보고해야 하나요?

네. 선택 시간이 아니거나 주말이거나 오늘 글이 이미 있는 경우의 SKIP은 정상 동작입니다. 다만 아무 변화가 없는 시간대의 반복 보고는 짧아야 합니다. 반대로 선택 시간에 기존 글을 발견해 건너뛴 경우에는 기존 파일과 제목을 함께 남겨야 중복 방지 검증이 됩니다.

공개 검증 로그와 결정 로그는 다른가요?

다릅니다. 결정 로그는 발행을 시작하거나 멈춘 이유를 설명하고, 공개 검증 로그는 빌드와 런타임 반영 이후 실제 URL이 보이는지를 설명합니다. 둘은 함께 있어야 합니다. 결정이 맞아도 공개가 실패할 수 있고, 공개가 성공해도 다음 실행이 왜 새 글을 만들지 않았는지 설명하려면 결정 로그가 필요합니다.

결론

AI 블로그 자동화에서 발행 결정 로그는 운영자를 위한 작은 블랙박스입니다. Futory의 Next.js Markdown 흐름에서는 KST 날짜와 선택 시간, 기존 글 중복 검사, 최근 주제 확인, 백업, 새 파일 경로, 첫 실패 지점을 같은 순서로 남겨야 합니다. 이 기록은 발행을 느리게 만드는 절차가 아니라, 반복 실행을 안전하게 빠르게 만드는 기준선입니다.

바이브코딩은 빠른 실행과 즉각적인 피드백을 장점으로 삼지만, 평일마다 공개되는 블로그 자동화는 그 실행이 왜 일어났는지 설명할 수 있어야 신뢰를 얻습니다. 결정 로그를 남기면 SKIP도 성공적인 판단이 되고, 실패도 다음 재시도의 출발점이 되며, 성공한 공개는 더 선명한 운영 증거로 남습니다.