AI 블로그 자동 게시 후 공개 URL을 검증하는 방법

요약

AI와 함께 블로그를 운영하면 글 작성, Markdown 저장, 테스트, 빌드, 배포까지 빠르게 자동화할 수 있습니다. 하지만 자동 게시의 성공은 파일이 하나 생겼다는 사실로 끝나지 않습니다. 실제 독자가 보는 공개 도메인에서 새 글 상세 페이지와 목록 페이지가 모두 정상으로 보여야 성공입니다. Futory는 content/posts/*.md에 글을 추가한 뒤 npm run test:theme, npm run test:content, npm run build를 통과시키고, 호스트의 /opt/wordblog에 동기화한 다음 PM2와 Nginx를 통해 https://futory.oig.kr로 공개합니다.

이 과정에서 실수하기 쉬운 지점은 “빌드가 성공했으니 공개도 성공했다”고 판단하는 것입니다. Next.js 빌드는 통과했지만 PM2가 이전 프로세스를 들고 있을 수 있고, Nginx는 살아 있지만 새 산출물을 아직 서빙하지 않을 수 있습니다. 또는 상세 페이지는 열리는데 /posts 목록에는 날짜나 제목이 반영되지 않는 경우도 있습니다. 자동화가 매일 반복될수록 이런 작은 차이를 놓치면 실패가 조용히 누적됩니다.

그래서 Futory의 자동 게시 루틴에는 공개 URL 검증이 반드시 포함되어야 합니다. 이 글은 AI 개발과 운영 자동화 관점에서 새 글이 실제로 공개되었는지 확인하는 기준을 정리합니다. 핵심은 내부 상태, 호스트 상태, 공개 응답을 나누어 보고, 최종 성공 판정은 독자가 접근하는 URL을 기준으로 내리는 것입니다.

공개 검증은 배포의 마지막 단계가 아니라 성공 조건이다

자동 배포에서 검증은 보통 테스트나 빌드 단계에 집중됩니다. npm run test:content가 통과하면 frontmatter, 카테고리, 태그, FAQ, 글 길이 같은 콘텐츠 조건은 맞다고 볼 수 있습니다. npm run test:theme가 통과하면 기존 다크/라이트 모드 기능도 유지되었을 가능성이 큽니다. npm run build가 성공하면 Next.js 애플리케이션이 산출물을 만들 수 있다는 뜻입니다.

하지만 이 세 가지는 모두 공개 전 검증입니다. 실제 운영에서는 그 뒤에 스테이징 파일이 호스트 라이브 경로로 제대로 복사되었는지, 호스트에서 다시 빌드가 성공했는지, PM2 프로세스가 새 코드로 재시작되었는지, Nginx가 올바른 내부 포트로 프록시하는지까지 확인해야 합니다. Futory의 내부 포트는 127.0.0.1:8042이고, PM2 프로세스 이름은 futory-wordblog입니다. 이 값들이 맞아야 공개 도메인 응답도 안정적으로 이어집니다.

따라서 공개 검증은 “혹시 모르니 한 번 열어보기”가 아니라 배포 성공의 일부입니다. 자동화 보고서에서 성공이라고 쓰려면 새 글 URL과 /posts 목록이 HTTP 200으로 응답하고, 오늘 날짜와 제목 또는 slug가 노출되는지 확인해야 합니다.

Futory에서 확인해야 할 세 가지 화면

새 글 상세 페이지

첫 번째는 새 글 상세 페이지입니다. slug는 영문 소문자 kebab-case로 만들고, 파일명과 라우팅 규칙이 일치해야 합니다. 예를 들어 public-url-verification-for-ai-blog-automation.md를 추가했다면 공개 URL은 보통 /posts/public-url-verification-for-ai-blog-automation 형태가 됩니다. 이 URL이 200으로 응답해야 하고, HTML 안에 글 제목과 2026-05-24 같은 오늘 날짜가 보여야 합니다.

상세 페이지 검증은 가장 직접적입니다. 글 파일이 복사되지 않았거나 Next.js 빌드 산출물이 오래되었거나 라우팅이 깨졌다면 여기서 바로 드러납니다. 자동화에서는 브라우저 대신 curl로 상태 코드를 확인할 수 있지만, 단순히 200만 보는 것보다 본문에 제목, 날짜, category가 포함되는지도 함께 보는 편이 좋습니다.

글 목록 페이지

두 번째는 /posts 목록입니다. 새 글 상세 페이지가 직접 URL로는 열리지만 목록에 나오지 않으면 독자 입장에서는 발견하기 어렵습니다. 목록 정렬, 날짜 파싱, frontmatter 처리 중 하나가 잘못되었을 가능성도 있습니다. Futory처럼 Markdown 기반 블로그를 운영할 때는 새 파일이 콘텐츠 컬렉션에 정상 포함되는지 확인하는 과정이 중요합니다.

목록 페이지에서는 오늘 날짜, 새 제목, 또는 slug가 보이는지 확인합니다. 특히 자동 게시가 매일 실행되는 구조라면 같은 날짜의 글이 중복으로 생기지 않았는지도 함께 봐야 합니다. KST 기준 오늘 날짜의 글이 이미 있다면 새 글을 만들지 않고 건너뛰는 것이 운영 데이터의 일관성을 지키는 방법입니다.

홈 또는 주요 진입 페이지

세 번째는 홈이나 주요 진입 페이지입니다. 모든 블로그가 홈에 최신 글을 보여주는 것은 아니지만, Futory처럼 콘텐츠 운영 기록을 쌓는 사이트에서는 최신 글 노출이 중요한 진입점이 될 수 있습니다. 홈에 최신 글이 노출되는 구조라면 /posts와 함께 확인하고, 아니라면 최소한 홈이 정상 200으로 응답하는지 확인해 배포 과정에서 전체 사이트가 깨지지 않았는지 봐야 합니다.

PM2와 Nginx 상태를 공개 응답과 연결해서 보기

PM2 상태가 online이라고 해서 공개 성공이 보장되는 것은 아닙니다. PM2는 프로세스가 떠 있는지만 보여줄 수 있고, 그 프로세스가 새 빌드를 서빙하는지까지 자동으로 보장하지는 않습니다. 그래서 호스트 배포 후에는 pm2 restart futory-wordblog --update-env를 실행하고, 짧은 부팅 시간을 고려해 공개 URL을 재시도해야 합니다.

Nginx도 마찬가지입니다. Nginx가 살아 있어도 프록시 대상 포트가 틀리거나, 기본 vhost가 응답하거나, 캐시된 응답이 보일 수 있습니다. 서버 내부에서는 127.0.0.1:8042가 응답하는지 확인하고, 외부에서는 https://futory.oig.kr가 같은 콘텐츠를 보여주는지 확인해야 합니다. 내부와 외부를 분리하면 문제가 애플리케이션인지, 프록시인지, 네트워크인지 빠르게 좁힐 수 있습니다.

AI 자동화에게는 이 구분이 특히 중요합니다. “PM2 재시작 완료”라는 로그만 보고 성공을 말하지 않도록, 최종 판정 문장을 공개 URL 검사 뒤에만 작성하게 해야 합니다. 실패했을 때도 build 실패, PM2 재시작 실패, 공개 URL 404, 목록에 날짜 없음처럼 어느 단계에서 멈췄는지 남겨야 다음 수정이 쉬워집니다.

캐시와 오래된 산출물을 의심해야 하는 상황

자동 게시 후 가장 헷갈리는 문제 중 하나는 캐시입니다. 소스에는 새 글이 있고, 호스트 빌드도 성공했는데 브라우저에서 이전 화면이 보일 수 있습니다. 이때는 먼저 공개 HTML을 직접 확인해 새 제목이나 날짜가 들어 있는지 봅니다. HTML에 새 내용이 있는데 브라우저만 다르게 보인다면 사용자는 강력 새로고침이 필요할 수 있습니다.

반대로 HTML에도 새 내용이 없다면 캐시가 아니라 배포 또는 빌드 문제일 가능성이 큽니다. .next 산출물이 갱신되지 않았거나, PM2가 이전 작업 디렉터리에서 실행되고 있거나, 파일 동기화 단계에서 새 Markdown이 빠졌을 수 있습니다. Futory 배포에서는 .git, node_modules, .next, .env를 제외하고 소스를 동기화한 뒤 호스트에서 다시 빌드하므로, 새 글 파일이 라이브 경로에 실제로 있는지 확인하는 것이 좋은 출발점입니다.

기존 테마 토글도 같은 관점에서 봐야 합니다. 콘텐츠 배포가 components/ThemeToggle.tsx, app/theme-init.tsx, CSS의 data-theme 변수를 지우면 안 됩니다. 새 글 하나를 올리는 작업이 기존 사용자 경험을 망치지 않도록 npm run test:theme를 배포 전후로 반복하는 이유가 여기에 있습니다.

자동화 보고서에 남길 최소 정보

자동 게시가 성공했을 때 보고서는 길 필요가 없습니다. 다만 운영에 필요한 핵심 정보는 있어야 합니다. 제목, 날짜, 공개 URL, 스테이징 검증 결과, 호스트 검증 결과, 공개 확인 결과를 남기면 충분합니다. 이 정보가 있으면 나중에 실패 패턴을 분석하거나 콘텐츠 릴리즈 노트를 만들 때도 도움이 됩니다.

실패했을 때는 더 구체적이어야 합니다. 단순히 “실패”라고 남기면 다음 자동화나 사람이 어디서부터 봐야 할지 알기 어렵습니다. 예를 들어 콘텐츠 테스트가 실패했다면 어떤 frontmatter 조건을 어겼는지, 빌드가 실패했다면 어떤 파일이나 환경변수가 원인인지, 공개 확인이 실패했다면 상태 코드와 확인한 URL을 남겨야 합니다.

자주 묻는 질문

빌드가 성공했는데도 공개 URL 확인이 꼭 필요한가요?

필요합니다. 빌드는 애플리케이션이 만들어졌다는 뜻이지, 공개 도메인에서 독자가 볼 수 있다는 뜻은 아닙니다. 호스트 동기화, PM2 재시작, Nginx 프록시, DNS/HTTPS 경로가 모두 통과해야 실제 공개 성공입니다.

/posts 목록과 상세 페이지 중 하나만 확인하면 안 되나요?

둘 다 확인하는 편이 안전합니다. 상세 페이지는 라우팅과 본문 렌더링을 확인하고, 목록 페이지는 콘텐츠 인덱싱과 최신 글 노출을 확인합니다. 둘 중 하나만 보면 발견하지 못하는 문제가 생길 수 있습니다.

PM2가 online이면 서비스가 정상 아닌가요?

PM2의 online 상태는 프로세스가 떠 있다는 신호입니다. 새 빌드를 서빙하는지, 올바른 환경변수를 사용하는지, Nginx를 통해 공개되는지는 별도로 확인해야 합니다. 그래서 공개 URL 검증이 필요합니다.

캐시 때문에 새 글이 안 보이면 어떻게 판단하나요?

먼저 curl로 공개 HTML에 새 제목과 날짜가 있는지 확인합니다. HTML에는 있는데 브라우저만 오래된 화면이면 브라우저 캐시 가능성이 큽니다. HTML에도 없다면 동기화, 빌드, PM2 재시작, 라우팅 문제를 봐야 합니다.

결론

AI와 함께 운영하는 블로그에서 자동화의 목표는 글을 빠르게 만드는 것만이 아닙니다. 매일 같은 기준으로 안전하게 공개하고, 실패하면 어느 단계에서 멈췄는지 알 수 있게 만드는 것이 더 중요합니다. Futory의 Next.js Markdown 블로그는 스테이징 검증, 호스트 빌드, PM2/Nginx 운영, 공개 URL 확인이 하나의 흐름으로 이어질 때 안정적으로 성장할 수 있습니다.

새 글 파일을 추가하는 순간은 게시의 시작입니다. 성공 판정은 https://futory.oig.kr에서 새 글과 목록이 실제로 보이는 순간 내려야 합니다. 이 기준을 자동화에 고정해두면 AI 개발, 배포 검증, 콘텐츠 운영이 따로 움직이지 않고 하나의 운영 루틴으로 연결됩니다.