AI 블로그 자동화에서 의존성 상태를 점검하는 법

요약

Futory처럼 Next.js와 Markdown을 함께 쓰는 AI 블로그 자동화에서는 글을 잘 쓰는 것만큼이나 실행 환경을 안정적으로 유지하는 일이 중요합니다. 매일 하나의 글을 만들고, 콘텐츠 테스트와 테마 테스트를 통과한 뒤 빌드하고, PM2로 런타임을 다시 올리는 흐름은 단순해 보입니다. 하지만 실제 실패는 대개 본문 문장보다 package.json 스크립트, 잠금 파일, Node 버전, 빌드 캐시, 네트워크 접근, 공개 페이지 캐시 같은 주변 의존성에서 먼저 발생합니다.

그래서 평일 자동 발행 루틴에는 “오늘 글이 좋은가”와 별개로 “오늘 발행 환경이 같은 계약을 지키고 있는가”를 확인하는 작은 의존성 상태 점검이 필요합니다. 이 글은 Futory 운영 관점에서 새 Markdown 파일 하나만 추가하는 흐름을 유지하면서도, 의존성 문제를 조기에 발견하고 보고서를 읽는 사람이 바로 다음 조치를 판단할 수 있게 만드는 방법을 정리합니다.

의존성 점검은 발행 전 안전장치다

AI가 글을 생성하면 운영자는 종종 본문 품질에만 집중합니다. 제목이 중복되지 않았는지, 설명문이 자연스러운지, 태그가 맞는지 확인하는 과정은 물론 중요합니다. 그러나 자동 발행에서는 본문이 완벽해도 npm run build가 실패하면 공개 사이트에는 아무것도 반영되지 않습니다. 더 위험한 경우는 빌드는 성공했지만 런타임 재시작이나 공개 검증이 실패해 사용자는 이전 상태를 보게 되는 상황입니다.

의존성 점검의 목적은 큰 감사가 아닙니다. 매일 발행 직전에 “이 발행이 통과해야 하는 최소 실행 조건이 살아 있는가”를 확인하는 것입니다. Futory의 경우 최소 조건은 posts 디렉터리 접근, frontmatter 파싱, 콘텐츠 테스트, 테마 테스트, Next.js 빌드, .next 산출물, PM2 재시작, 공개 URL 응답으로 나눌 수 있습니다. 각 단계를 작게 분리하면 실패 보고도 훨씬 선명해집니다.

Futory에서 볼 핵심 의존성

패키지 스크립트 계약

첫 번째 의존성은 package.json에 정의된 스크립트입니다. 자동화 프롬프트는 npm run test:content, npm run test:theme, npm run build를 실행한다고 가정합니다. 누군가 스크립트 이름을 바꾸거나 테스트 명령의 의미를 바꾸면 자동 발행은 같은 지시를 따라도 다른 결과를 냅니다. 따라서 발행 루틴은 스크립트가 존재하고 실제로 실행되는지를 빌드 전 검증의 일부로 삼아야 합니다.

여기서 중요한 점은 스크립트를 매번 수정하려 들지 않는 것입니다. 크론 발행 작업은 새 글 하나만 추가해야 하므로 기존 파일을 고치지 않습니다. 대신 실패하면 어떤 명령이 어떤 출력으로 멈췄는지 정확히 남깁니다. 이 원칙이 있어야 콘텐츠 자동화가 배포 자동화로 번지지 않고, 작은 변경 단위를 지킬 수 있습니다.

Markdown 파서와 frontmatter 형식

두 번째 의존성은 Markdown 파일의 구조입니다. Futory 글은 title, description, date, category, tags를 frontmatter에 담고, 날짜는 YYYY-MM-DD 형식으로 둡니다. 이 구조가 흔들리면 목록 정렬, 중복 방지, 카테고리 페이지, SEO 설명문이 한꺼번에 영향을 받습니다.

AI가 생성한 글이라도 frontmatter는 자유 문장이 아니라 계약입니다. 제목에는 따옴표를 쓰고, 카테고리는 바이브코딩으로 맞추며, 태그 배열은 JSON에 가까운 형태로 유지하는 편이 안전합니다. 특히 오늘 날짜는 중복 방지의 기준이므로 파일명보다 frontmatter 날짜를 더 신뢰할 수 있게 관리해야 합니다.

빌드 캐시와 산출물

세 번째 의존성은 .next 빌드 산출물입니다. npm run build가 성공했다는 메시지만으로는 새 slug가 실제 라우트에 포함되었는지 알 수 없습니다. 자동화는 새 글을 만든 뒤 .next 내부에서 slug가 발견되는지 확인해야 합니다. 이 검증은 단순하지만 강력합니다. 파일은 만들었는데 빌드 입력에 포함되지 않았거나, 라우팅 규칙이 바뀌었거나, 캐시가 엉킨 상황을 빨리 드러냅니다.

운영 보고서에는 “빌드 성공”과 “빌드 산출물에서 slug 확인”을 구분해 적는 것이 좋습니다. 전자는 명령 실행 결과이고, 후자는 새 콘텐츠가 빌드 결과에 반영되었다는 증거입니다. 두 문장을 나누면 나중에 공개 페이지가 늦게 갱신될 때 원인을 캐시, 재시작, 라우팅 중 어디에서 찾아야 할지 좁힐 수 있습니다.

실무 루틴으로 만드는 방법

발행 전에 최근 글을 읽는다

의존성 점검은 주제 점검과 함께 시작하는 것이 좋습니다. 최근 글의 제목, 설명문, 태그를 확인하면 오늘 글이 같은 패턴을 따르는지 알 수 있습니다. 동시에 posts 디렉터리에 접근할 수 있는지, 파일 읽기 권한이 정상인지, frontmatter가 일관적인지도 자연스럽게 확인됩니다.

예를 들어 최근 Futory 글들이 구조화 데이터, 발췌문, canonical URL, 내부 링크, 사이트맵 같은 운영 검증 주제를 다뤘다면 오늘은 의존성 상태 점검처럼 인접하지만 중복되지 않는 각도를 고를 수 있습니다. 이렇게 하면 콘텐츠 품질과 운영 안전성이 같은 탐색 단계에서 함께 좋아집니다.

백업을 먼저 만든다

새 Markdown 파일을 쓰기 전에는 posts 디렉터리를 압축해 백업합니다. 자동화가 기존 글을 수정하지 않는다고 해도 백업은 필요합니다. 사람과 AI 모두 실수할 수 있고, 경로를 잘못 잡거나 파일명이 충돌할 수 있기 때문입니다. 백업 파일명에 날짜와 시간을 넣으면 어떤 실행에서 만들어진 안전망인지 바로 추적할 수 있습니다.

백업은 복잡할 필요가 없습니다. /opt/data/futory-cron-posts-backup-YYYYMMDD-HHMMSS.tar.gz 같은 형태면 충분합니다. 핵심은 백업이 새 글 작성보다 먼저 존재해야 한다는 점입니다. 이 순서가 지켜지면 실패 보고서도 안심하고 읽을 수 있습니다.

실패 단계 이름을 고정한다

의존성 문제는 보고 방식이 반입니다. “오류가 났다”가 아니라 test:content 실패, test:theme 실패, build 실패, PM2 restart 실패, public verification 실패처럼 단계 이름을 고정해야 합니다. 그래야 다음 실행이나 사람이 보는 운영 로그에서 같은 유형을 빠르게 묶을 수 있습니다.

또한 실패한 명령과 첫 번째로 조치 가능한 오류를 함께 남겨야 합니다. 자동 발행은 무인으로 실행되므로 긴 추측보다 정확한 증거가 더 유용합니다. 빌드가 실패했다면 PM2를 재시작하지 않는 것도 중요한 계약입니다. 깨진 빌드로 런타임을 흔들지 않는 것이 작은 블로그 운영에서는 가장 안전한 기본값입니다.

공개 검증까지가 의존성 점검이다

Next.js 빌드가 끝나고 PM2를 재시작해도 작업은 아직 끝나지 않았습니다. 최종 의존성은 실제 독자가 보는 공개 사이트입니다. 상세 URL /posts/<slug>가 200을 반환하는지 확인하고, 홈, 글 목록, 바이브코딩 목록에 오늘 날짜나 slug가 보이는지 확인해야 합니다. 이때 캐시 우회를 위해 쿼리 문자열과 no-cache 헤더를 사용하는 습관이 중요합니다.

공개 검증은 SEO나 디자인만을 위한 절차가 아닙니다. 자동화가 파일 시스템, 빌드 시스템, 런타임 프로세스, 프록시, 캐시 계층을 모두 통과했는지 확인하는 마지막 통합 테스트입니다. 이 단계가 있어야 “파일을 만들었다”가 아니라 “독자가 볼 수 있게 발행했다”고 말할 수 있습니다.

자주 묻는 질문

의존성 점검을 매일 하면 너무 무겁지 않나요?

Futory 규모에서는 무겁게 만들 필요가 없습니다. 정해진 세 개의 npm 명령과 빌드 산출물 검색, 공개 URL 확인 정도면 충분합니다. 중요한 것은 많은 검사를 추가하는 것이 아니라 매일 같은 순서로 같은 증거를 남기는 것입니다.

패키지를 자동으로 업데이트해도 되나요?

평일 발행 크론에서는 권장하지 않습니다. 이 작업의 목적은 새 글 하나를 안전하게 발행하는 것입니다. 패키지 업데이트는 별도 유지보수 작업으로 분리하고, 테스트 범위와 롤백 계획을 갖춘 상태에서 진행하는 편이 좋습니다.

빌드는 성공했는데 공개 페이지가 예전 상태면 어떻게 보나요?

먼저 .next 산출물에 새 slug가 있는지 확인합니다. 있다면 콘텐츠는 빌드에 들어간 것입니다. 그다음 PM2 재시작 결과, 프록시 캐시, 공개 페이지 캐시를 차례로 의심합니다. 그래서 보고서에 빌드, 산출물, 재시작, 공개 검증을 따로 적는 것이 중요합니다.

의존성 점검이 콘텐츠 품질에도 도움이 되나요?

도움이 됩니다. frontmatter와 최근 글 목록을 함께 확인하면 제목 중복, 설명문 약화, 태그 흔들림을 조기에 발견할 수 있습니다. 운영 점검이 곧 편집 품질 점검의 일부가 되는 셈입니다.

결론

AI 블로그 자동화의 안정성은 멋진 문장 하나보다 반복 가능한 작은 계약에서 나옵니다. Futory의 평일 발행 루틴은 새 Markdown 파일 하나를 만들고, 테스트와 빌드를 통과시키고, 산출물과 공개 URL을 확인하는 단순한 흐름입니다. 여기에 의존성 상태 점검이라는 이름을 붙이면 실패 지점이 선명해지고, 재시도해도 중복을 만들지 않는 운영 습관이 자리 잡습니다.

앞으로도 자동 발행은 큰 마법보다 작은 증거를 쌓는 방식이 좋습니다. 오늘의 글이 어떤 파일로 만들어졌고, 어떤 명령을 통과했으며, 어떤 공개 URL에서 확인되었는지 남기는 것. 그것이 Futory 같은 Next.js Markdown 블로그를 오래 안정적으로 운영하는 가장 실용적인 바이브코딩 방식입니다.