AI 블로그 자동화에서 발행 증거 맵 만들기

요약

AI 블로그 자동화에서 가장 위험한 표현은 “아마 올라갔을 것”입니다. Futory처럼 content/posts/*.md에 Markdown 파일을 추가하고, 콘텐츠 검증, 테마 검증, Next.js 빌드, PM2 재시작, 공개 URL 확인을 거치는 구조에서는 각 단계가 서로 다른 증거를 남깁니다. 파일이 생겼다는 사실은 작성 증거이고, 빌드가 성공했다는 사실은 배포 가능 증거이며, 공개 상세 페이지와 목록 페이지가 새 글을 보여준다는 사실은 독자 노출 증거입니다.

이 글은 Futory의 일일 발행 루틴을 기준으로 발행 증거 맵을 만드는 방법을 정리합니다. 바이브코딩으로 빠르게 자동화를 만들수록, 결과를 감각이 아니라 확인 가능한 신호로 연결해야 합니다. 증거 맵은 복잡한 대시보드가 아니라 “어느 단계에서 무엇을 확인했고, 실패하면 어디에서 멈출지”를 한 장의 운영 흐름으로 고정하는 방식입니다.

발행 증거 맵이 필요한 이유

자동화는 성공했을 때보다 애매하게 실패했을 때 더 많은 비용을 만듭니다. 새 Markdown 파일은 만들어졌지만 빌드가 실패했을 수 있고, 빌드는 성공했지만 PM2 재시작이 실패했을 수 있으며, 상세 URL은 200이지만 홈 목록에는 아직 보이지 않을 수 있습니다. 이 상태를 모두 “발행 실패”라고만 적으면 다음 조치가 모호해집니다.

단계별 성공을 분리한다

Futory 운영에서는 성공을 네 단계로 나눠 볼 수 있습니다. 첫째, 오늘 날짜의 새 파일이 정확히 하나 만들어졌는가. 둘째, npm run test:content와 npm run test:theme가 통과했는가. 셋째, npm run build 결과물 안에 새 slug가 포함됐는가. 넷째, PM2 재시작 후 공개 상세 페이지와 목록 페이지가 새 글을 보여주는가입니다.

이 구분이 있으면 보고서가 훨씬 실용적으로 바뀝니다. “빌드는 성공, 공개 목록 검증 실패”라고 쓰면 운영자는 캐시, 실행 프로세스, 라우팅 목록 생성 쪽을 보면 됩니다. 반대로 “콘텐츠 검증 실패, PM2 미실행”이라고 쓰면 공개 서버는 건드리지 않았다는 점까지 바로 알 수 있습니다.

중복 방지도 증거의 일부다

증거 맵은 발행한 경우에만 필요하지 않습니다. 오늘 날짜 글이 이미 있어서 스킵했다는 사실도 중요한 운영 증거입니다. 파일명이나 frontmatter에서 오늘 날짜를 찾고 멈췄다면, 자동화는 중복을 막는 역할을 제대로 수행한 것입니다. 특히 크론이 같은 날 여러 번 실행되는 구조에서는 “아무것도 하지 않음”이 오히려 정상 동작일 때가 많습니다.

Futory식 증거 흐름 설계

1. 파일 시스템 증거

첫 번째 증거는 /opt/futory/content/posts에 새 Markdown 파일이 존재한다는 사실입니다. 이때 파일명은 영어 kebab-case slug로 만들고, frontmatter에는 제목, 설명, 날짜, 카테고리, 태그를 고정된 형식으로 넣어야 합니다. 날짜는 Asia/Seoul 기준이어야 하며, 기존 글을 수정하지 않고 새 파일 하나만 추가했다는 점도 기록해야 합니다.

파일 시스템 증거를 남기기 전에는 백업이 필요합니다. content/posts 전체를 timestamp가 있는 tar.gz로 보관하면, 잘못된 글이 생성되거나 검증 규칙이 바뀌었을 때 복구 기준이 생깁니다. 백업 경로는 보고서에 그대로 남겨야 나중에 사람이 찾을 수 있습니다.

2. 검증 명령 증거

두 번째 증거는 프로젝트가 제공하는 검증 명령의 결과입니다. npm run test:content는 Markdown 구조, frontmatter, 필수 섹션 같은 콘텐츠 규칙을 확인하고, npm run test:theme는 테마와 목록 렌더링 관점의 규칙을 확인합니다. 둘 중 하나라도 실패하면 빌드나 PM2 재시작으로 넘어가지 않는 것이 안전합니다.

바이브코딩에서는 “일단 만들어 보고 고친다”는 리듬이 강하지만, 공개 블로그 자동화에서는 실패 후 다음 단계로 넘어가지 않는 멈춤 조건이 품질을 지킵니다. 검증 실패는 창작 실패가 아니라 운영 계약 위반입니다. 오류 메시지를 정확히 남기면 다음 수정은 훨씬 작아집니다.

3. 빌드 산출물 증거

세 번째 증거는 .next 산출물에 새 slug가 들어갔는지 확인하는 것입니다. Next.js 빌드가 성공했다는 로그만으로는 새 글이 실제 라우팅과 정적 데이터에 반영됐는지 확신하기 어렵습니다. 빌드 후 산출물에서 slug 문자열을 찾으면 파일 생성과 앱 빌드 사이의 연결이 확인됩니다.

이 단계는 특히 배포 경로와 실행 경로가 다를 때 유용합니다. 산출물에는 새 slug가 있는데 공개 페이지가 이전 상태라면, 문제는 콘텐츠가 아니라 PM2 프로세스의 cwd, 캐시, 재시작 반영 쪽일 가능성이 큽니다.

공개 검증을 맵의 마지막에 둔다

상세 페이지와 목록 페이지를 따로 본다

공개 검증은 /posts/<slug> 하나만 보면 부족합니다. 상세 페이지가 200으로 열려도 홈, 전체 글 목록, 카테고리 목록에서 독자가 새 글을 발견하지 못할 수 있습니다. Futory에서는 홈(/), 전체 목록(/posts), 바이브코딩 카테고리(/vibe-coding)를 함께 확인하는 편이 안전합니다.

검증 요청에는 cache-busting query string과 Cache-Control: no-cache 헤더를 붙여야 합니다. 그래야 브라우저나 중간 캐시 때문에 오래된 화면을 보고 성공 또는 실패를 잘못 판단하는 일을 줄일 수 있습니다.

보고서는 짧지만 증거 중심이어야 한다

자동화 보고서는 긴 해설보다 단계별 상태가 중요합니다. 제목, 날짜, 파일 경로, 공개 URL, 선택된 발행 시간, 테스트 결과, 빌드 결과, PM2 재시작 결과, 공개 검증 결과를 같은 순서로 남기면 됩니다. 실패가 있다면 “어느 명령에서 멈췄는지”와 stderr를 포함해야 합니다.

자주 묻는 질문

발행 증거 맵은 별도 도구가 있어야 하나요?

꼭 그렇지는 않습니다. 처음에는 크론 보고서에 단계별 결과를 남기는 것만으로 충분합니다. 나중에 실패 패턴이 반복되면 로그 파일, 체크리스트, 대시보드로 확장할 수 있습니다. 중요한 것은 도구보다 증거 항목을 고정하는 것입니다.

공개 상세 페이지가 200이면 성공 아닌가요?

절반의 성공에 가깝습니다. 상세 페이지가 열리면 직접 URL 접근은 가능하지만, 목록 페이지에 보이지 않으면 일반 독자는 글을 발견하기 어렵습니다. 그래서 Futory 루틴은 상세 200과 목록 포함 여부를 모두 확인합니다.

같은 날 재시도하면 무엇을 기준으로 멈춰야 하나요?

오늘 날짜가 frontmatter나 파일명에 이미 있으면 새 글을 만들지 않고 스킵하는 것이 안전합니다. 이전 시도에서 파일만 생성되고 빌드가 실패했더라도, 자동화가 같은 날짜 글을 또 만드는 것보다는 운영자가 기존 파일을 보고 수정하는 편이 낫습니다.

결론

Futory의 AI 블로그 자동화에서 발행 성공은 하나의 이벤트가 아니라 연결된 증거들의 묶음입니다. 백업, 새 Markdown 파일, 콘텐츠 검증, 테마 검증, Next.js 빌드, .next slug 확인, PM2 재시작, 공개 상세와 목록 검증이 차례로 이어져야 “발행됐다”고 말할 수 있습니다.

바이브코딩은 빠르게 만들고 빠르게 배포하는 데 강하지만, 반복 운영에서는 빠름만큼 확인 가능한 증거가 중요합니다. 발행 증거 맵을 갖추면 자동화는 더 조용하고 안전하게 움직입니다. 성공했을 때는 무엇이 통과했는지 분명하고, 실패했을 때는 어디에서 멈췄는지 분명하기 때문입니다.