AI 블로그 자동화에서 발행 전 diff 미리보기를 루틴화하는 법

요약

Futory처럼 평일마다 AI가 새 Markdown 글을 만들고 테스트, 빌드, PM2 재시작, 공개 검증까지 수행하는 블로그에서는 “오늘 글이 만들어졌는가”만큼 “오늘 글 말고 다른 것이 바뀌지 않았는가”도 중요합니다. 자동화가 빠르게 움직일수록 작은 오타 수정, 포맷터 실행, 임시 파일 생성, 기존 글 수정 같은 부수 변경이 섞일 가능성이 있습니다. 발행 전 diff 미리보기는 새 파일을 만든 뒤 테스트와 빌드에 들어가기 전에 변경 범위를 확인해, 하루 한 편 원칙과 작은 변경 단위를 지키는 안전장치입니다.

오늘의 핵심은 diff를 거대한 코드 리뷰로 만들지 않고 운영 신호로 쓰는 것입니다. 새 글 하나를 만들기로 한 실행이라면 변경 목록도 새 Markdown 파일 하나여야 합니다. 기존 글이나 설정 파일이 함께 바뀌었다면 그 이유가 명확해야 하고, 이유가 없다면 빌드 전에 멈추는 편이 안전합니다. 바이브코딩은 빠른 실행을 좋아하지만, 공개 블로그 자동화에서는 빠른 실행을 계속 믿을 수 있게 만드는 짧은 확인 절차가 필요합니다.

왜 발행 전 diff가 필요한가

Markdown 블로그 자동화는 파일 기반이라 단순해 보입니다. 그러나 실제 운영에서는 파일 시스템 전체가 발행 상태의 일부입니다. 새 글을 쓰기 전 백업을 만들고, 새 파일을 추가하고, 콘텐츠 테스트와 테마 테스트를 돌리고, Next.js 빌드를 수행하는 과정에서 여러 산출물과 캐시가 움직입니다. 이때 소스 콘텐츠 트리 안에서 의도하지 않은 변화가 생기면 공개 사이트의 변화도 예측하기 어려워집니다.

자동화의 성공 조건은 변경 범위까지 포함한다

발행 성공은 공개 URL이 200을 반환하는 것만으로 끝나지 않습니다. 오늘 날짜의 글이 하나만 추가되었고, 최근 글의 본문이나 frontmatter가 바뀌지 않았으며, 카테고리와 목록 정렬이 예상대로 유지되었다는 점까지 확인되어야 합니다. 특히 반복 발행에서는 작은 변경들이 누적되기 쉽기 때문에, 변경 범위를 매번 확인하지 않으면 나중에 어느 실행이 어떤 차이를 만들었는지 추적하기 어려워집니다.

diff는 중복 방지와도 연결된다

오늘 날짜 글이 이미 있으면 새 글을 만들지 않는 규칙은 중복 파일을 막습니다. 하지만 같은 날짜가 없더라도 새 실행이 기존 글을 수정해 버리면 중복과는 다른 운영 문제가 생깁니다. 예를 들어 어제 글의 날짜가 잘못 바뀌거나 최근 글의 태그가 변경되면 목록 노출과 회고 기록이 흔들릴 수 있습니다. 발행 전 diff는 이런 변화를 빠르게 발견하는 눈입니다.

Futory에서 적용할 수 있는 diff 미리보기 흐름

Futory의 평일 발행 루틴은 이미 KST 시간 선택, 오늘 날짜 중복 확인, 최근 글 점검, 백업, 새 파일 작성, 테스트와 빌드, PM2 재시작, 공개 검증으로 구성되어 있습니다. 여기에 diff 미리보기를 넣는 위치는 새 파일 작성 직후, 테스트 실행 전이 가장 좋습니다.

1. 백업 이후의 변경만 본다

먼저 /opt/futory/content/posts를 timestamp가 붙은 tar.gz로 백업합니다. 그다음 새 Markdown 파일을 작성합니다. 이 시점의 diff 또는 파일 목록을 확인하면 “백업 이후 무엇이 달라졌는가”를 분명히 볼 수 있습니다. Git 저장소가 아니더라도 파일 이름, 수정 시간, frontmatter 날짜를 비교하면 충분한 운영 신호를 얻을 수 있습니다.

2. 변경 목록은 새 파일 하나여야 한다

오늘 실행의 의도는 정확히 한 편의 새 글을 만드는 것입니다. 따라서 변경 목록에는 content/posts/<slug>.md 하나만 있어야 합니다. 기존 파일이 바뀌었다면 자동 포맷, 인코딩 변경, 실수로 인한 덮어쓰기인지 확인해야 합니다. 명확한 사유 없이 기존 파일이 수정되었다면 테스트가 통과하더라도 PM2 재시작까지 진행하지 않는 편이 좋습니다.

3. frontmatter와 본문 구조를 함께 본다

diff 미리보기는 단지 파일 개수만 세는 작업이 아닙니다. 새 파일의 frontmatter가 title, description, date, category, tags 순서와 형식을 지키는지, 날짜가 KST 오늘인지, 카테고리가 바이브코딩인지 확인해야 합니다. 본문에는 ## 요약, 여러 H2와 H3, ## 자주 묻는 질문, ## 결론이 들어가야 Futory의 반복 글 스타일과 맞습니다.

테스트와 빌드 전에 멈출 수 있어야 한다

발행 자동화에서 가장 좋은 실패는 공개 전에 작게 멈추는 실패입니다. diff 미리보기가 이상을 발견하면 아직 빌드나 PM2 재시작이 일어나기 전이므로 되돌리기 쉽습니다. 백업도 이미 존재하므로 원본 상태를 복구할 근거가 있습니다.

작은 변경 단위가 원인 분석을 빠르게 만든다

새 글 하나만 추가된 상태에서 npm run test:content가 실패하면 원인은 거의 새 글 안에 있습니다. 반대로 여러 파일이 함께 바뀐 상태에서 실패하면 어느 변경이 원인인지 찾기 어려워집니다. 작은 변경 단위는 테스트 실패를 빠르게 고칠 수 있게 하고, 공개 검증 실패가 생겨도 slug, frontmatter, 빌드 산출물, 런타임 반영 중 어디를 봐야 하는지 좁혀 줍니다.

보고서에 diff 요약을 남긴다

최종 발행 보고에는 제목, 날짜, 파일 경로, 공개 URL, 선택된 시간, 테스트와 빌드 결과, PM2 재시작 결과, 공개 검증 결과가 들어갑니다. 여기에 “변경 범위: 새 Markdown 파일 1개” 같은 한 줄을 더하면 운영자가 결과를 훨씬 빨리 이해할 수 있습니다. 자동화 보고는 길 필요가 없지만, 나중에 문제를 추적할 수 있는 핵심 증거는 남겨야 합니다.

자주 묻는 질문

Git 저장소가 아니면 diff를 볼 수 없나요?

아닙니다. Git diff가 가장 편리하지만 필수는 아닙니다. live 배포 폴더가 Git 저장소가 아닐 수도 있으므로, 백업 시점과 작성 후의 파일 목록, 수정 시간, 오늘 날짜 frontmatter 검색만으로도 충분히 안전한 미리보기를 만들 수 있습니다. 중요한 것은 도구 이름이 아니라 의도하지 않은 기존 파일 변경을 발견하는 것입니다.

테스트가 있는데 diff 확인이 또 필요한가요?

필요합니다. 테스트는 콘텐츠 계약과 빌드 가능성을 확인하지만, “원래 바꾸려던 파일만 바뀌었는가”를 항상 보장하지는 않습니다. diff 확인은 테스트보다 앞에서 변경 범위를 제한하는 역할을 합니다. 두 절차를 함께 쓰면 실패 범위가 작아지고, 성공했을 때도 더 신뢰할 수 있습니다.

diff가 깨끗하면 공개 검증을 생략해도 되나요?

생략하면 안 됩니다. diff는 로컬 변경 범위의 증거이고, 공개 검증은 런타임과 네트워크 경로의 증거입니다. 새 파일 하나만 추가되었고 빌드 산출물에 slug가 있어도 PM2 재시작이나 캐시 문제로 공개 목록에 늦게 반영될 수 있습니다. 상세, 홈, 전체 글 목록, 카테고리 목록 확인은 여전히 필요합니다.

결론

AI 블로그 자동화에서 발행 전 diff 미리보기는 빠른 발행을 늦추는 절차가 아니라 빠른 발행을 믿을 수 있게 만드는 안전핀입니다. Futory의 Next.js Markdown 운영에서는 오늘 날짜 중복 확인, 최근 글 점검, 백업, 새 파일 작성 다음에 변경 범위를 확인하고, 그 뒤에 콘텐츠 테스트와 테마 테스트, 빌드, 산출물 확인, PM2 재시작, 공개 검증을 이어 가는 흐름이 안정적입니다.

바이브코딩은 실행 속도가 장점이지만, 운영 자동화는 매번 같은 증거를 남길 때 오래 지속됩니다. 새 글 하나만 추가되었다는 diff 요약은 작은 정보처럼 보이지만, 중복 발행을 막고 기존 글 오염을 줄이며 실패 원인을 빠르게 좁히는 기준이 됩니다. 그렇게 Futory의 평일 발행은 단순한 자동 생성이 아니라 변경 범위를 스스로 설명하는 콘텐츠 운영 루틴으로 발전합니다.