AI 블로그 자동화에서 변경 단위를 작게 유지하는 법

요약

AI 블로그 자동화에서 안정성을 높이는 가장 현실적인 방법은 변경 단위를 작게 유지하는 것입니다. Futory처럼 content/posts/*.md에 Markdown 파일을 추가하고, 콘텐츠 검증, 테마 검증, Next.js 빌드, PM2 재시작, 공개 URL 확인까지 이어지는 구조에서는 “오늘 새 글 하나”라는 단순한 범위가 큰 안전장치가 됩니다. 자동화가 한 번에 글 작성, 기존 글 수정, 테마 변경, 배포 설정 변경을 모두 처리하면 실패 원인을 찾기 어렵고 롤백 기준도 흐려집니다.

이 글은 Futory의 반복 발행 루틴을 기준으로 변경 단위를 작게 쪼개는 운영 방법을 정리합니다. 바이브코딩은 빠른 실험과 배포에 강하지만, 매일 실행되는 블로그 자동화에서는 속도보다 추적 가능성이 더 중요해지는 순간이 있습니다. 작은 변경은 자동화의 발목을 잡는 제약이 아니라, 실패했을 때 바로 원인을 좁히고 다음 실행을 안전하게 만드는 구조입니다.

왜 변경 단위를 작게 해야 할까

자동화 작업은 사람이 직접 눌러 보는 작업보다 실행 맥락이 적습니다. 크론은 정해진 시간에 움직이고, 보고서는 실행이 끝난 뒤에 도착하며, 중간에 사람이 “잠깐 멈춰”라고 말하기 어렵습니다. 그래서 한 번의 실행에서 바꾸는 대상을 줄여야 합니다. 변경 범위가 작으면 검증도 단순해지고, 실패 보고서도 곧바로 다음 행동으로 이어집니다.

실패 원인을 빠르게 좁힌다

오늘 실행에서 새 Markdown 파일 하나만 추가했다면 npm run test:content 실패의 원인은 대부분 새 글의 frontmatter, 제목, 섹션 구조, 태그 배열, Markdown 문법 안에 있습니다. 반대로 같은 실행에서 목록 컴포넌트와 테마 설정까지 바꿨다면 어떤 변경이 실패를 만들었는지 분리하기 어렵습니다. 작은 단위는 디버깅 시간을 줄이는 가장 쉬운 방법입니다.

Futory 운영에서는 새 글 생성 전 백업을 남기고, 기존 글을 수정하지 않으며, 빌드가 실패하면 PM2를 재시작하지 않는 흐름이 중요합니다. 이 규칙은 자동화가 보수적으로 보이게 만들지만 실제로는 재시도를 쉽게 만듭니다. 문제가 새 파일에 있으면 그 파일만 고치면 되고, 기존 서비스는 불필요하게 흔들리지 않습니다.

중복 방지와도 잘 맞는다

하루 한 편 발행 루틴에서는 중복 방지가 핵심입니다. 오늘 날짜가 frontmatter나 파일명에 이미 있으면 새 글을 만들지 않고 멈추는 규칙은 단순하지만 강력합니다. 변경 단위가 “오늘 글 하나”로 고정되어 있으면 이 규칙을 적용하기 쉽습니다. 같은 날 재시도하더라도 자동화가 새로운 주제를 또 만들어 내지 않고, 이미 생긴 파일을 운영자가 확인할 수 있습니다.

Futory식 작은 변경 루틴

Futory의 Next.js Markdown 블로그에서는 작은 변경 루틴을 네 단계로 볼 수 있습니다. 첫째, 오늘 날짜와 선택된 실행 시간을 확인합니다. 둘째, 기존 글에서 오늘 날짜가 있는지 확인합니다. 셋째, 백업 후 새 Markdown 파일 하나를 만듭니다. 넷째, 검증과 빌드와 공개 확인을 순서대로 진행합니다.

파일 하나만 추가한다

가장 중요한 원칙은 기존 파일을 고치지 않는 것입니다. 새 글을 만들면서 이전 글의 링크, 카테고리, 설명을 같이 손보면 작업 범위가 커집니다. 물론 내부 링크 정리나 시리즈 페이지 개선이 필요할 수 있지만, 그것은 별도 작업으로 분리하는 편이 안전합니다. 매일 발행 자동화는 “정기 콘텐츠 추가”에 집중하고, 구조 개선은 사람이 의도한 변경으로 다루는 것이 좋습니다.

파일명도 영어 kebab-case slug로 고정하면 운영이 쉬워집니다. URL이 예측 가능하고, .next 산출물에서 slug를 검색하기도 쉽습니다. frontmatter에는 날짜, 카테고리, 태그를 일정한 형태로 남겨야 목록 페이지와 카테고리 페이지가 안정적으로 글을 읽어 옵니다.

검증 단계를 건너뛰지 않는다

작은 변경이라고 해서 검증을 줄이면 안 됩니다. 오히려 변경이 작기 때문에 검증 결과가 더 명확해집니다. npm run test:content는 글 자체의 규칙을 확인하고, npm run test:theme는 테마와 렌더링 기준을 확인합니다. 두 단계가 통과한 뒤에만 npm run build로 넘어가야 합니다.

빌드가 성공하면 .next 안에 새 slug가 들어갔는지 확인합니다. 이 확인은 단순한 검색이지만 운영상 의미가 큽니다. 파일 시스템의 새 글이 Next.js 빌드 산출물에 반영됐다는 연결 증거이기 때문입니다. 이후 PM2 재시작과 공개 URL 확인은 배포 반영 증거가 됩니다.

작은 변경을 보고서에 남기는 법

자동화 보고서는 길 필요가 없습니다. 다만 어떤 변경이 있었는지와 어디까지 검증됐는지는 분명해야 합니다. 제목, 날짜, 파일 경로, 공개 URL, 선택된 시간, 테스트 결과, 빌드 결과, PM2 재시작 결과, 공개 상세와 목록 검증 결과가 있으면 충분합니다.

성공보다 멈춘 지점이 중요하다

실패 보고서에서는 “실패”라는 단어보다 멈춘 지점이 중요합니다. 콘텐츠 검증에서 멈췄다면 공개 서버는 건드리지 않은 것입니다. 빌드에서 멈췄다면 PM2 재시작은 하지 않은 것입니다. PM2 재시작은 성공했지만 공개 목록에서 보이지 않는다면 캐시, 실행 경로, 목록 생성 로직을 의심해야 합니다.

이렇게 단계가 분리되어 있으면 사용자는 보고서를 보고 바로 다음 행동을 정할 수 있습니다. 작은 변경 단위는 보고서의 해상도를 높입니다. 무엇을 바꿨는지 작게 남기고, 무엇을 확인했는지 순서대로 남기면 자동화는 더 신뢰받는 운영 도구가 됩니다.

자주 묻는 질문

작은 변경은 생산성을 떨어뜨리지 않나요?

처음에는 느려 보일 수 있습니다. 하지만 반복 발행에서는 실패를 고치는 시간이 전체 생산성을 좌우합니다. 작은 변경은 한 번에 많은 일을 하지 않는 대신, 실패했을 때 원인을 빠르게 찾게 해 줍니다. 장기적으로는 더 빠른 방식입니다.

기존 글의 오타를 발견하면 같이 고쳐도 되나요?

정기 발행 크론에서는 분리하는 편이 좋습니다. 오늘 글 추가와 기존 글 수정은 성격이 다른 변경입니다. 오타 수정이 필요하면 별도 커밋이나 별도 운영 작업으로 처리하면 검증과 롤백이 훨씬 명확해집니다.

공개 페이지가 늦게 바뀌면 새 파일을 지워야 하나요?

그렇지 않습니다. 파일 생성, 빌드, PM2 재시작, 공개 검증은 서로 다른 단계입니다. 새 파일과 빌드 산출물은 정상인데 공개 페이지만 늦게 바뀐다면 실행 프로세스나 캐시 문제일 수 있습니다. 먼저 어느 단계의 증거가 있는지 확인하는 것이 안전합니다.

결론

Futory의 AI 블로그 자동화에서 변경 단위를 작게 유지하는 것은 단순한 운영 취향이 아니라 안전한 반복 배포를 위한 핵심 원칙입니다. 오늘 날짜의 새 Markdown 파일 하나만 만들고, 기존 글을 건드리지 않으며, 검증과 빌드와 공개 확인을 차례로 통과시키면 실패 원인이 작아지고 보고서의 의미가 선명해집니다.

바이브코딩은 빠른 실행을 가능하게 하지만, 매일 돌아가는 자동화에는 작은 변경과 확실한 증거가 필요합니다. 작게 바꾸고, 정확히 검증하고, 어디까지 반영됐는지 보고하는 루틴이 쌓이면 블로그 운영은 더 조용하고 예측 가능한 시스템이 됩니다.