AI 블로그 자동화에서 로그 보존 기준을 정하는 법

요약

Futory처럼 Next.js와 Markdown으로 운영되는 AI 블로그는 매일 새 글 하나를 만드는 것만큼 실행 증거를 잘 남기는 일이 중요합니다. 크론은 KST 시간 판단, 중복 검사, 백업, 파일 생성, 콘텐츠 테스트, 테마 테스트, 빌드, PM2 재시작, 공개 URL 확인을 차례로 수행합니다. 이 과정의 로그가 전혀 없으면 실패 원인을 추적하기 어렵고, 반대로 모든 원시 출력을 끝없이 쌓으면 다음 운영자가 핵심 신호를 찾기 어렵습니다.

로그 보존 기준은 “나중에 복구와 판단에 필요한 증거는 남기되, 공개 콘텐츠 원천을 어지럽히지 않는다”는 약속입니다. Futory의 바이브코딩 루틴에서는 posts 폴더에는 최종 Markdown만 두고, 백업 파일은 /opt/data에 두며, 크론 최종 보고서에는 통과한 단계와 실패한 명령을 간결하게 남기는 방식이 현실적입니다. 이 글은 AI 블로그 자동화에서 로그를 얼마나 남기고 어떻게 읽기 좋게 줄일지 정리합니다.

왜 로그 보존 기준이 필요한가

자동 발행은 대부분 조용히 성공합니다. 그래서 운영자는 성공 로그를 대충 흘려보기 쉽습니다. 하지만 어느 날 빌드가 실패하거나 공개 목록이 갱신되지 않으면, 그날의 작은 증거가 장애 분석의 출발점이 됩니다. 이때 필요한 것은 길고 산만한 콘솔 전체가 아니라, 어느 단계까지 통과했고 어디서 멈췄는지를 보여 주는 구조화된 기록입니다.

성공 로그도 다음 실행의 입력이다

오늘의 성공 보고서는 내일 자동화가 주제를 피하고 중복을 막는 데 도움이 됩니다. 제목, 날짜, slug, 파일 경로, 공개 URL이 남아 있으면 다음 실행은 최근 글과의 거리를 판단할 수 있습니다. 특히 Futory의 글들은 운영검증, 캐시, 목록, 날짜처럼 비슷한 단어를 공유하므로, description과 태그까지 남겨 두면 주제 중복을 줄이는 데 유용합니다.

실패 로그는 단계 경계를 보여야 한다

npm run test:content가 실패한 경우와 pm2 restart가 실패한 경우는 대응이 완전히 다릅니다. 전자는 새 Markdown의 frontmatter나 본문 계약을 확인해야 하고, 후자는 호스트 SSH, PM2 앱 이름, 런타임 반영을 봐야 합니다. 로그 보존 기준은 실패 단계와 “하지 않은 일”을 함께 남기게 해 줍니다. 예를 들어 빌드 실패 후에는 PM2를 재시작하지 않았다고 명시해야 안전합니다.

Futory에 맞는 로그 분리 원칙

posts 디렉터리에는 로그를 두지 않는다

/opt/futory/content/posts는 공개 글의 원천입니다. 여기에 테스트 로그, 빌드 결과, 임시 캡처를 넣으면 Next.js의 콘텐츠 수집 대상과 섞일 수 있습니다. 자동화가 만든 파일은 오늘 날짜의 최종 Markdown 하나여야 합니다. 운영 로그는 크론 보고서나 별도 운영 위치에 남기고, 백업 tar.gz도 /opt/data처럼 콘텐츠 트리 밖에 두는 편이 안전합니다.

최종 보고서는 짧은 장부가 되어야 한다

무인 크론의 최종 메시지는 나중에 검색 가능한 장부처럼 읽혀야 합니다. 선택된 KST 시간, 중복 검사 결과, 백업 경로, 새 파일, 테스트와 빌드 상태, .next slug 확인, PM2 재시작, 공개 상세 및 목록 검증을 고정된 순서로 적으면 충분합니다. 이 방식은 긴 로그보다 사람이 빠르게 판단하기 좋고, 실패 시에도 어느 단계에서 멈췄는지 분명합니다.

보존 기간을 정하는 실무 기준

모든 로그를 영구 보관할 필요는 없습니다. 다만 복구에 직접 필요한 백업과 장애 분석에 필요한 요약은 구분해야 합니다. 예를 들어 posts 백업은 최근 며칠 또는 몇 주 단위로 보존하고, 최종 발행 보고서는 날짜별로 검색 가능하게 남기는 식입니다. 원시 빌드 로그는 실패한 실행에서만 자세히 보관하고, 성공 실행에서는 PASS 상태와 핵심 명령만 남겨도 충분합니다.

복구 가능한 증거와 읽기 쉬운 증거를 나눈다

백업 파일은 복구 가능한 증거입니다. 파일 크기와 경로가 확인되면 실제로 되돌릴 수 있는 기준점이 됩니다. 반면 최종 보고서는 읽기 쉬운 증거입니다. 어떤 제목이 발행됐고 공개 URL이 200이었는지 알려 줍니다. 두 종류를 섞지 않으면 운영자는 복구할 때는 백업을 찾고, 판단할 때는 보고서를 읽으면 됩니다.

민감한 실행 정보는 필요한 만큼만 적는다

SSH 명령이나 키 경로는 운영상 필요할 때가 있지만, 보고서가 외부로 전달될 수 있다면 과도한 세부 정보를 반복해서 남길 필요는 없습니다. 실패 시에는 재현 가능한 명령과 오류를 남기고, 성공 시에는 PM2 재시작이 통과했다는 상태를 중심으로 기록하면 됩니다. 로그 보존은 투명성과 노출 최소화 사이의 균형입니다.

자주 묻는 질문

성공한 빌드 로그도 모두 저장해야 하나요?

대부분의 경우 전체 원시 로그까지 보존할 필요는 없습니다. 성공 실행에서는 명령별 PASS, 새 slug의 .next 반영 여부, 공개 URL 검증 결과가 더 중요합니다. 원시 로그는 실패했을 때 정확한 오류를 남기는 쪽이 실용적입니다.

백업 파일이 있으면 최종 보고서는 짧아도 되나요?

백업과 보고서는 역할이 다릅니다. 백업은 복구용이고, 보고서는 판단용입니다. 백업 경로만 있고 어떤 글을 만들었는지 없다면 운영자는 내용을 다시 열어봐야 합니다. 따라서 최종 보고서에는 제목, 날짜, slug, 파일 경로, 검증 상태를 함께 남기는 편이 좋습니다.

로그를 줄이면 나중에 원인을 놓치지 않나요?

줄인다는 것은 증거를 없앤다는 뜻이 아닙니다. 단계별 상태와 첫 번째 조치 가능한 오류를 남기고, 반복적이고 의미가 낮은 출력은 생략한다는 뜻입니다. 실패 지점이 분명하면 오히려 원인 분석은 빨라집니다.

결론

AI 블로그 자동화의 로그는 많을수록 좋은 것이 아니라, 다시 읽었을 때 판단을 빠르게 만드는 형태여야 합니다. Futory의 Next.js Markdown 루틴에서는 공개 콘텐츠 원천, 복구 백업, 운영 보고서를 분리하는 것만으로도 로그의 품질이 크게 좋아집니다. posts 폴더에는 최종 글 하나만 남기고, 백업은 콘텐츠 밖에 두며, 최종 보고서는 단계별 PASS와 실패 명령을 고정된 순서로 기록하면 됩니다.

바이브코딩은 빠른 실행을 장점으로 삼지만, 빠른 실행일수록 증거의 모양을 정해 두어야 합니다. 오늘의 발행 로그가 간결하고 충분하면 내일의 자동화는 더 안전하게 판단하고, 문제가 생긴 날에도 운영자는 어느 경계에서 멈췄는지 바로 이해할 수 있습니다.