AI 블로그 배포에서 신호를 단계별로 확인하는 법

요약

AI 블로그 자동화에서 배포가 끝났다는 말은 하나의 신호만으로 판단하기 어렵습니다. Futory처럼 content/posts/*.md에 새 Markdown 파일을 추가하고 Next.js 빌드와 PM2 재시작을 거쳐 공개 사이트를 확인하는 구조에서는 파일 생성, 콘텐츠 검증, 빌드 산출물, 프로세스 재시작, 공개 URL 응답이 각각 다른 의미를 가집니다. 파일이 있다는 것은 원고가 준비됐다는 뜻이고, 빌드가 성공했다는 것은 애플리케이션이 그 원고를 처리할 수 있다는 뜻입니다. 하지만 독자가 실제로 볼 수 있는지는 공개 상세 페이지와 목록 페이지까지 확인해야 알 수 있습니다.

이 글은 Futory의 바이브코딩 운영 관점에서 배포 신호를 단계별로 나누는 방법을 정리합니다. 자동화가 매일 한 편의 글을 만들 때 중요한 것은 빠르게 “성공”이라고 말하는 것이 아니라, 어디까지 통과했는지 정확히 남기는 것입니다. 신호를 잘게 나누면 실패했을 때도 새 글을 중복으로 만들지 않고, 어느 단계의 조치가 필요한지 바로 판단할 수 있습니다.

배포 신호를 하나로 뭉치면 위험하다

반복 발행 루틴에서 가장 흔한 착각은 “빌드 성공”과 “공개 성공”을 같은 말로 취급하는 것입니다. 개발 서버에서는 이 둘이 거의 동시에 보일 수 있지만, 운영 환경에서는 다릅니다. 파일은 배포 경로에 있어도 실행 중인 프로세스가 예전 빌드를 보고 있을 수 있고, 상세 페이지는 열리지만 홈이나 카테고리 목록에는 아직 반영되지 않을 수 있습니다. 캐시나 프록시가 끼어 있으면 더더욱 단일 신호만으로 결론을 내리기 어렵습니다.

파일 신호는 시작점이다

새 Markdown 파일은 배포의 시작점입니다. frontmatter에 오늘 날짜가 있고, slug가 영어 kebab-case로 고정되어 있으며, category: "바이브코딩"과 태그 배열이 들어 있으면 자동화가 읽을 수 있는 최소 조건을 만족합니다. 그러나 파일 신호는 아직 독자에게 도달한 신호가 아닙니다. 그래서 Futory 루틴에서는 파일을 만들기 전에 백업을 남기고, 만든 뒤에는 검증 명령을 반드시 실행합니다.

빌드 신호는 처리 가능성을 보여 준다

npm run build가 성공하면 Next.js가 새 글을 처리할 수 있다는 강한 증거가 됩니다. 여기에 .next 산출물에서 새 slug를 확인하면 파일과 빌드 결과가 연결됩니다. 이 확인은 작지만 중요합니다. 빌드 로그는 전체 애플리케이션의 성공을 말해 주지만, 산출물 검색은 오늘 만든 글이 그 성공 안에 포함됐는지를 알려 줍니다.

Futory식 단계별 확인 흐름

Futory의 일일 발행은 한 번에 많은 것을 바꾸지 않습니다. 오늘 날짜 글이 이미 있는지 먼저 확인하고, 없다면 content/posts를 백업한 뒤 새 파일 하나만 추가합니다. 그 다음 콘텐츠 테스트, 테마 테스트, 빌드, 산출물 확인, PM2 재시작, 공개 URL 확인으로 이어집니다. 이 순서는 보수적이지만 자동화에는 잘 맞습니다.

검증은 공개 서버를 건드리기 전의 안전장치다

npm run test:content는 글의 frontmatter, 필수 섹션, 날짜 형식 같은 기본 계약을 확인하는 단계입니다. npm run test:theme는 콘텐츠가 사이트의 디자인 규칙과 충돌하지 않는지 확인하는 단계입니다. 이 둘 중 하나라도 실패하면 PM2를 재시작하지 않는 편이 안전합니다. 공개 프로세스를 흔들기 전에 문제를 파일 단계에서 멈추는 것이 운영 안정성에 좋습니다.

재시작은 런타임 신호다

빌드가 성공해도 실행 중인 Node 프로세스가 새 산출물을 읽지 않으면 사용자는 변화를 보지 못합니다. 그래서 PM2 재시작은 단순한 부가 작업이 아니라 런타임 반영 신호입니다. 특히 Futory처럼 호스트의 PM2 앱을 별도로 재시작해야 하는 환경에서는 SSH 명령의 성공 여부를 보고서에 남겨야 합니다. 실패했다면 공개 검증을 기대하기보다 재시작 명령과 오류를 그대로 확인하는 것이 우선입니다.

공개 확인은 상세와 목록을 나눠야 한다

공개 검증에서는 /posts/<slug> 상세 페이지 200만 확인하면 부족합니다. 상세 페이지는 직접 URL을 알고 있는 사람이 접근할 수 있다는 신호이고, 홈이나 /posts, /vibe-coding 목록은 독자가 새 글을 발견할 수 있다는 신호입니다. 자동화 보고서에는 이 둘을 나눠 적는 편이 좋습니다.

캐시를 의식한 요청이 필요하다

목록 페이지가 늦게 바뀌는 것처럼 보일 때는 실제 미반영인지 캐시인지 구분해야 합니다. 그래서 cache-busting query string과 Cache-Control: no-cache 헤더를 붙여 확인하는 습관이 좋습니다. 이 작은 절차는 “내 브라우저에서는 안 보인다”와 “운영 서버가 아직 새 목록을 만들지 않았다”를 구분하는 데 도움이 됩니다.

실패 보고서는 다음 행동을 줄여 준다

상세 페이지는 200인데 목록에서 slug가 없으면 목록 생성 로직, 정렬 기준, 캐시, 프로세스 경로를 의심할 수 있습니다. 반대로 목록에는 날짜가 보이지만 상세가 404라면 라우팅이나 slug 생성 문제를 봐야 합니다. 단계별 신호가 남아 있으면 다음 조치가 추측이 아니라 좁혀진 점검이 됩니다.

자주 묻는 질문

빌드가 성공했는데도 왜 공개 URL을 다시 확인하나요?

빌드는 코드와 콘텐츠를 처리하는 단계이고, 공개 URL은 사용자가 실제로 접근하는 단계입니다. 운영 환경에서는 프로세스 재시작, 프록시, 캐시, 배포 경로 문제로 두 단계가 어긋날 수 있습니다. 그래서 빌드 성공만으로 발행 완료를 선언하지 않는 편이 안전합니다.

오늘 글이 이미 있으면 검증만 다시 실행해도 되나요?

정기 발행 크론의 기본 역할은 중복 없이 하루 한 편을 만드는 것입니다. 오늘 날짜 글이 이미 있으면 새 글을 만들지 않는 것이 우선입니다. 별도 점검이 필요하다면 운영자가 의도한 수동 검증 작업으로 분리하는 것이 좋습니다. 이렇게 해야 재시도 상황에서 같은 날짜 글이 여러 개 생기는 일을 막을 수 있습니다.

공개 목록에 늦게 보이면 새 글을 다시 만들어야 하나요?

아닙니다. 새 파일을 다시 만들면 중복 문제가 생깁니다. 이미 파일과 빌드 산출물이 있다면 다음에는 PM2 재시작 상태, 캐시, 목록 페이지 응답, 실행 경로를 확인해야 합니다. 자동화의 목표는 같은 일을 반복하는 것이 아니라, 어느 신호에서 끊겼는지 찾아내는 것입니다.

결론

Futory의 AI 블로그 자동화에서 배포 신호는 파일, 검증, 빌드, 런타임, 공개 페이지로 나뉩니다. 이 신호를 단계별로 확인하면 매일 한 편을 빠르게 발행하면서도 실패 원인을 작게 유지할 수 있습니다. 특히 Next.js Markdown 운영에서는 새 파일 하나가 곧 새 URL 하나가 되기 때문에, 그 파일이 어디까지 반영됐는지를 증거로 남기는 습관이 중요합니다.

바이브코딩은 빠른 실행을 가능하게 하지만, 반복 운영에는 빠름을 지탱하는 확인 체계가 필요합니다. 오늘의 새 글이 파일로 존재하고, 테스트와 빌드를 통과하고, PM2 재시작 뒤 공개 상세와 목록에서 확인될 때 비로소 발행 완료라고 말할 수 있습니다. 신호를 나누어 보는 루틴이 쌓이면 자동화는 더 조용하고, 더 정확하며, 더 믿을 수 있는 블로그 운영자가 됩니다.