AI 블로그 자동화에서 작업 공간을 깨끗하게 유지하는 법

요약

Futory처럼 평일마다 AI가 Next.js Markdown 글을 만들고 테스트, 빌드, PM2 재시작, 공개 검증까지 수행하는 블로그에서는 “무엇을 만들었는가”만큼 “무엇을 남기지 않았는가”가 중요합니다. 정기 발행의 목표는 오늘 날짜의 새 Markdown 파일 하나를 안전하게 추가하는 것입니다. 그런데 초안 후보, 임시 메모, 실험용 파일, 포맷터가 건드린 기존 글, 검증 로그 같은 부산물이 content/posts 안에 섞이면 다음 실행의 중복 검사와 최근 주제 판단이 흐려집니다.

작업 공간 청결은 단순한 정리 습관이 아니라 자동 발행의 신뢰 조건입니다. 새 글은 공개 사이트가 읽는 최종 입력이고, 백업과 검증 로그는 운영자가 읽는 증거입니다. 이 둘을 섞지 않으면 Futory의 바이브코딩 루틴은 더 작고 예측 가능한 변경 단위로 유지됩니다. 이 글은 AI 블로그 자동화에서 깨끗한 작업 공간을 유지하는 실무 기준을 정리합니다.

왜 작업 공간 청결이 필요한가

자동화는 빠르게 파일을 만들 수 있습니다. 하지만 빠르다는 이유로 작업 디렉터리에 여러 흔적을 남기면 다음 자동화가 그 흔적을 실제 콘텐츠로 오해할 수 있습니다. 특히 Markdown 블로그에서는 파일 하나가 곧 라우팅 입력이므로, 임시 파일도 잘못 놓이면 목록이나 빌드 검증에 영향을 줄 수 있습니다.

content tree는 최종 원고만 담아야 한다

/opt/futory/content/posts는 아이디어 보관함이 아니라 공개 가능한 글의 원천입니다. 따라서 여기에 들어가는 파일은 frontmatter 계약을 지키고, slug가 확정되어 있으며, 오늘 발행할 정확히 하나의 글이어야 합니다. 후보 제목을 비교하기 위한 메모나 검증 결과 캡처는 이 디렉터리 밖에 두는 편이 안전합니다.

작은 변경 단위가 장애 분석을 쉽게 만든다

정기 발행에서 문제가 생겼을 때 가장 먼저 확인할 질문은 단순해야 합니다. “이번 실행에서 새 파일 하나만 추가됐는가?” 이 질문에 바로 답할 수 있으면 실패 원인을 콘텐츠 형식, 빌드, 런타임, 공개 캐시 중 하나로 좁히기 쉽습니다. 반대로 기존 글 여러 개가 함께 수정되면 테스트 실패가 새 글 때문인지 오래된 글 때문인지 구분하기 어렵습니다.

Futory에서 지키기 좋은 원칙

1. 백업은 content tree 밖에 둔다

백업은 반드시 필요하지만, 백업 파일이 posts 폴더 안에 있으면 안 됩니다. Futory의 백업은 /opt/data/futory-cron-posts-backup-YYYYMMDD-HHMMSS.tar.gz처럼 배포 입력과 분리된 위치에 두는 것이 좋습니다. 이렇게 하면 Next.js 빌드가 백업을 콘텐츠 후보로 읽을 가능성을 없애고, 복구 파일도 운영 로그에서 쉽게 찾을 수 있습니다.

2. 초안 후보는 최종 파일로만 남긴다

AI가 글을 만들 때 제목이나 구성을 여러 개 떠올리는 것은 자연스럽습니다. 다만 실제 파일 시스템에는 최종 선택한 slug 하나만 써야 합니다. draft.md, test-post.md, new-post.md 같은 파일을 잠깐 만들었다가 지우는 방식은 자동화에서는 위험합니다. 중간에 실패하면 그 파일이 남아 다음 실행의 중복 검사와 빌드 결과를 흔들 수 있기 때문입니다.

3. 검증 로그는 보고서로 남기고 글 디렉터리에 쓰지 않는다

npm run test:content, npm run test:theme, npm run build의 결과는 중요하지만, 그 결과를 posts 폴더에 로그 파일로 남길 필요는 없습니다. 검증 결과는 크론 보고서에 요약하고, 실패하면 정확한 명령과 오류를 남기면 충분합니다. 글 디렉터리는 독자가 볼 콘텐츠만 담고, 운영 증거는 보고서와 백업 경로로 분리하는 것이 좋습니다.

작업 공간 점검을 루틴에 넣는 방법

새 글을 쓰기 전에는 오늘 날짜 중복을 확인하고 최근 글의 제목, description, 태그를 읽습니다. 이때 동시에 posts 폴더에 Markdown이 아닌 파일이나 임시 이름이 섞여 있는지 살피면 좋습니다. 새 글을 쓴 뒤에는 기존 파일을 수정하지 않았는지, 새 slug가 하나만 생겼는지, 빌드 산출물에 그 slug가 들어갔는지 확인합니다.

공개 검증과 연결하기

작업 공간이 깨끗하면 공개 검증도 더 선명해집니다. 상세 URL /posts/ai-blog-clean-workspace-routine이 200을 반환하고, 홈과 /posts, /vibe-coding 목록에서 오늘 날짜나 slug가 보이면 “오늘의 한 파일”이 배포까지 이어졌다고 말할 수 있습니다. 만약 공개 목록이 갱신되지 않았다면 작업 공간 문제보다 빌드 반영, PM2 재시작, 캐시 계층을 먼저 의심할 수 있습니다.

재시도 때 더 빛나는 기준

재시도 상황에서 작업 공간 청결은 특히 중요합니다. 오늘 날짜 파일이 이미 있으면 새 파일을 만들지 않는 것이 원칙입니다. 이때 posts 폴더에 임시 파일이 없고 최종 파일만 있다면 자동화는 중복 생성을 피하고 기존 파일 기준으로 남은 단계를 판단하기 쉽습니다. 깨끗한 작업 공간은 조용한 성공뿐 아니라 안전한 실패를 위한 조건입니다.

자주 묻는 질문

임시 파일을 만들었다가 바로 지우면 괜찮지 않나요?

사람이 직접 작업할 때는 가능할 수 있지만, 무인 크론에서는 권장하지 않습니다. 중간 단계에서 테스트나 빌드가 실패하면 임시 파일이 남을 수 있고, 다음 실행이 그것을 실제 글로 해석할 수 있습니다. 처음부터 최종 slug 하나만 쓰는 편이 더 안전합니다.

검증 로그를 저장하지 않으면 나중에 원인을 알기 어렵지 않나요?

로그를 저장하지 말자는 뜻이 아니라, posts 디렉터리에 저장하지 말자는 뜻입니다. 검증 결과는 크론 실행 출력, 운영 보고서, 필요하다면 별도 로그 위치에 남기면 됩니다. 공개 콘텐츠 원천과 운영 증거를 분리하면 둘 다 더 신뢰할 수 있습니다.

기존 글의 작은 오타를 함께 고치면 안 되나요?

정기 발행 루틴에서는 피하는 것이 좋습니다. 오늘 작업의 범위는 새 Markdown 파일 하나입니다. 기존 글 수정은 별도 편집 작업으로 분리해야 테스트 실패나 공개 변경의 원인을 명확하게 추적할 수 있습니다.

결론

AI 블로그 자동화에서 깨끗한 작업 공간은 보기 좋은 정리 이상의 의미를 가집니다. Futory의 Next.js Markdown 구조에서는 posts 폴더가 곧 공개 콘텐츠의 원천이므로, 그 안에는 최종 글만 남아야 합니다. 백업은 바깥에 두고, 초안 후보는 파일로 흩뿌리지 않으며, 검증 로그는 보고서로 분리하는 작은 기준이 하루 한 편 발행을 안정적으로 만듭니다.

바이브코딩은 빠르게 만들고 바로 검증하는 방식이지만, 빠른 실행일수록 남기는 흔적을 줄여야 합니다. 오늘 추가한 파일 하나, 빌드 산출물의 slug 하나, 공개 URL 하나가 서로 맞아떨어질 때 자동화는 단순해지고 운영자는 안심할 수 있습니다. 깨끗한 작업 공간은 다음 실행이 조용히 SKIP할 수 있게 만드는 가장 현실적인 안전장치입니다.