AI 블로그 자동화에서 실패 지점 라벨을 남기는 법

요약

Futory처럼 평일마다 AI가 Markdown 글을 만들고 Next.js 빌드와 PM2 재시작을 거쳐 공개하는 블로그에서는 실패 자체보다 실패가 어느 단계에서 멈췄는지를 빠르게 아는 것이 중요합니다. 같은 “발행 실패”라도 오늘 날짜 중복 검사에서 멈춘 것인지, 콘텐츠 테스트에서 frontmatter가 막힌 것인지, 빌드는 성공했지만 공개 목록에 반영되지 않은 것인지에 따라 다음 조치가 완전히 달라집니다.

실패 지점 라벨은 이 차이를 짧은 이름으로 고정하는 운영 습관입니다. 예를 들어 duplicate-check, content-test, theme-test, next-build, artifact-check, pm2-restart, public-detail, public-listing처럼 단계 이름을 정해 두면 크론 보고서와 재시도 판단이 훨씬 단순해집니다. 바이브코딩은 빠르게 시도하고 고치는 방식이지만, 반복 자동화에서는 빠른 시도만큼 빠른 위치 파악도 필요합니다.

실패 지점 라벨이 필요한 이유

자동 발행은 하나의 명령처럼 보이지만 실제로는 여러 작은 계약이 이어진 흐름입니다. 날짜 선택, 중복 확인, 파일 생성, 콘텐츠 검사, 테마 검사, 빌드, 산출물 확인, 런타임 재시작, 공개 URL 검증이 모두 통과해야 독자가 새 글을 볼 수 있습니다. 이 중 하나가 실패했을 때 “안 됨”이라고만 남기면 다음 실행은 어디서부터 이어 가야 할지 추측해야 합니다.

재시도는 같은 일을 반복하지 않아야 한다

가장 위험한 재시도는 실패 원인을 모른 채 처음부터 다시 실행하는 것입니다. 오늘 날짜 Markdown 파일이 이미 만들어졌는데 공개 검증만 실패한 상황에서 새 글을 또 만들면 중복 콘텐츠가 생깁니다. 반대로 파일 생성 전에 중복 검사에서 멈춘 것이라면 아무것도 쓰지 않은 정상 SKIP일 수 있습니다. 실패 지점 라벨은 재시도가 새 파일 작성인지, 빌드 재실행인지, PM2 재시작인지, 공개 검증 반복인지 구분하게 해 줍니다.

운영 보고가 짧아진다

라벨이 없으면 보고서가 길어져도 핵심이 흐려집니다. “테스트가 실패했습니다”보다 “content-test 단계 실패: frontmatter date 누락”이 낫고, “사이트 반영이 안 됩니다”보다 “public-listing 단계 실패: 상세 URL 200, 홈 목록 slug 미노출”이 낫습니다. 라벨은 사람에게도 좋지만 자동화가 다음 조건문을 선택하는 데도 유용한 신호가 됩니다.

Futory에 맞는 단계 이름 정하기

Futory의 발행 흐름은 이미 비교적 명확합니다. 따라서 새로운 시스템을 만들기보다 기존 순서에 짧은 이름을 붙이면 충분합니다. 중요한 것은 라벨이 실제 명령이나 검증 위치와 맞아야 한다는 점입니다. 이름만 예쁘고 실행 단계와 어긋나면 운영자는 다시 로그 전체를 읽어야 합니다.

작성 전 라벨

작성 전에는 schedule-window와 duplicate-check가 핵심입니다. schedule-window는 KST 기준 오늘이 평일인지, 현재 시간이 선택된 발행 시간인지 확인하는 단계입니다. 이 단계에서 멈추면 실패가 아니라 의도된 SKIP입니다. duplicate-check는 오늘 날짜가 frontmatter나 파일명에 이미 있는지 보는 단계입니다. 여기서 기존 글이 발견되면 새 파일을 만들지 않는 것이 성공입니다.

파일과 품질 라벨

새 글을 만들기 시작하면 backup, write-post, content-test, theme-test 라벨을 씁니다. backup은 live Markdown content tree를 건드리기 전 복구 지점을 만든 상태를 뜻합니다. write-post는 새 파일 하나만 생성했는지 확인하는 단계입니다. 이후 content-test와 theme-test는 각각 글 구조와 화면 회귀를 확인합니다. 이 구간에서 실패하면 PM2 재시작으로 넘어가면 안 됩니다.

배포와 공개 라벨

빌드 이후에는 next-build, artifact-check, pm2-restart, public-detail, public-listing을 나눕니다. next-build는 npm run build 자체의 성공 여부이고, artifact-check는 .next 안에서 오늘 slug가 실제로 발견되는지 보는 단계입니다. pm2-restart는 새 빌드가 런타임에 반영되도록 하는 경계입니다. 마지막으로 public-detail은 /posts/<slug>의 200 응답, public-listing은 홈과 목록 페이지에서 slug나 날짜가 보이는지 확인하는 단계입니다.

라벨을 보고서에 남기는 방법

라벨은 별도 대시보드가 없어도 크론 최종 보고에 충분히 남길 수 있습니다. 핵심은 각 라벨마다 상태를 OK, SKIP, FAIL처럼 짧게 쓰고, 실패한 라벨에는 다음에 해야 할 한 가지 조치만 붙이는 것입니다. 예를 들어 artifact-check: OK, slug found in .next처럼 쓰면 빌드 성공이 실제 글 포함으로 이어졌음을 알 수 있습니다.

성공 보고도 라벨을 포함한다

성공한 날에는 라벨이 불필요해 보이지만, 오히려 성공 보고에 라벨을 남겨야 다음 실패와 비교할 기준이 생깁니다. “오늘 글 발행 완료”보다 “content-test OK, theme-test OK, build OK, artifact-check OK, pm2-restart OK, public-detail 200, public-listing OK”가 더 재현 가능합니다. 짧지만 충분한 증거가 쌓이면 Futory의 자동화는 운영자 없이도 안정성을 설명할 수 있습니다.

실패 라벨은 하나만 강조한다

여러 단계가 연쇄적으로 실패할 수 있지만 보고에서는 첫 번째 결정적 실패를 강조하는 편이 좋습니다. 예를 들어 빌드가 실패했다면 PM2 재시작과 공개 검증은 실행하지 않는 것이 맞습니다. 이때 최종 라벨은 next-build: FAIL이고, 뒤 단계는 not-run으로 남기면 됩니다. 이렇게 하면 재시도는 빌드 문제 해결에서 시작하고, 공개 사이트 상태를 불필요하게 의심하지 않아도 됩니다.

자주 묻는 질문

라벨을 너무 많이 만들면 복잡하지 않나요?

처음에는 6~8개 정도면 충분합니다. Futory에서는 일정 확인, 중복 확인, 테스트, 빌드, 산출물 확인, PM2 재시작, 공개 상세, 공개 목록 정도만 나눠도 대부분의 운영 판단을 할 수 있습니다. 라벨이 많아지는 것보다 실제 단계와 맞지 않는 라벨이 더 문제입니다.

실패 라벨을 파일에 저장해야 하나요?

반드시 파일로 저장할 필요는 없습니다. 크론 보고서에 남아도 충분합니다. 다만 장기적으로 실패 패턴을 분석하고 싶다면 별도 로그나 운영 노트에 날짜, slug, 실패 라벨, 오류 메시지를 한 줄씩 모으는 방식이 도움이 됩니다.

공개 상세는 성공했는데 목록만 실패하면 어떻게 하나요?

새 글을 다시 만들지 않습니다. 이 경우 라벨은 public-detail: OK, public-listing: FAIL입니다. 다음 조치는 목록 생성 규칙, 캐시, PM2 반영 여부를 보는 것이지 콘텐츠를 중복 작성하는 것이 아닙니다. 오늘 날짜 파일과 slug는 이미 기준점으로 확정된 상태입니다.

결론

AI 블로그 자동화에서 실패 지점 라벨은 복잡한 장애 관리 도구가 아니라 반복 발행을 안전하게 이어 가기 위한 작은 이름표입니다. Futory의 Next.js Markdown 운영에서는 각 단계에 라벨을 붙여 두면 실패한 날에도 새 글을 또 만들지 않고, 정확히 멈춘 지점부터 다시 확인할 수 있습니다.

바이브코딩은 빠르게 만들고 검증하는 흐름이지만, 운영 자동화에서는 검증이 어디까지 끝났는지를 분명히 남겨야 합니다. 오늘의 slug, 파일 경로, 테스트 결과, 빌드 산출물, PM2 재시작, 공개 URL 확인을 단계 라벨로 묶으면 자동화는 더 조용해지고, 사람은 더 적은 문장으로 정확한 결정을 내릴 수 있습니다.