AI 블로그 운영에서 Markdown 검증 스크립트가 필요한 이유

요약

AI와 함께 블로그를 운영하면 글을 빠르게 만들 수 있지만, 빠른 작성만으로는 안정적인 게시가 되지 않습니다. Futory처럼 Next.js Markdown 블로그를 매일 자동 게시하는 환경에서는 새 글이 실제로 필요한 frontmatter를 갖췄는지, 오늘 날짜로 중복 없이 추가됐는지, 독자가 읽기 좋은 구조를 지켰는지, 기존 다크/라이트 모드 기능을 망가뜨리지 않았는지 확인해야 합니다. 이 역할을 사람이 매번 눈으로만 처리하면 언젠가는 빠뜨리는 조건이 생깁니다.

그래서 Markdown 검증 스크립트는 단순한 보조 도구가 아니라 자동 운영의 안전장치입니다. content/posts/*.md에 글 하나를 추가한 뒤 npm run test:content, npm run test:theme, npm run build를 통과해야만 호스트 /opt/wordblog로 동기화하고 PM2 프로세스를 재시작할 수 있습니다. 이 글은 Futory 운영 맥락에서 Markdown 콘텐츠 검증을 어떻게 바라봐야 하는지, 어떤 항목을 자동화해야 하는지, 그리고 검증 결과를 배포 판단에 어떻게 연결할 수 있는지 정리합니다.

Markdown 블로그에서 검증이 중요한 이유

Markdown 기반 블로그는 파일 하나가 곧 페이지 하나입니다. 글 작성자는 문서만 추가한다고 느끼지만, Next.js 입장에서는 빌드 대상 콘텐츠가 늘어나는 일입니다. frontmatter의 title, description, date, category, tags가 빠지면 글 목록, 상세 페이지, 메타 정보, 검색엔진 노출 흐름이 모두 흔들릴 수 있습니다. 특히 자동 게시에서는 사람이 관리자 화면에서 오류를 보는 방식이 아니라 빌드와 공개 확인으로 문제를 발견해야 하므로 사전 검증이 더 중요합니다.

Futory의 현재 방향은 “AI와 함께 만들고, 자동화하고, 운영하는 기록”입니다. 이 방향을 유지하려면 글마다 카테고리가 제멋대로 늘어나지 않아야 하고, 바이브코딩이라는 하나의 주제 안에서 AI 개발, 자동화, 배포, 운영 경험이 깊게 쌓여야 합니다. Markdown 검증은 단순한 문법 확인을 넘어 블로그의 편집 방향을 지키는 장치가 됩니다.

또한 글 구조도 검증 대상입니다. ## 요약, 여러 개의 H2/H3, ## 자주 묻는 질문, ## 결론이 들어가면 독자가 글을 빠르게 파악하기 쉽습니다. AI가 생성한 글은 문장은 자연스러워도 운영 맥락이 흐려질 수 있으므로, 구조 검증을 통해 최소한의 품질선을 유지하는 것이 좋습니다.

Futory에 맞는 콘텐츠 검증 항목

frontmatter와 날짜

가장 먼저 확인할 것은 frontmatter입니다. 날짜는 KST 기준 오늘 날짜와 맞아야 하고, 자동 게시 루틴은 이미 오늘 날짜의 글이 있는지 먼저 검사해야 합니다. 이 조건이 없으면 같은 날 여러 글이 올라가거나, UTC 기준 날짜가 섞여 운영 기록이 어긋날 수 있습니다. 매일 14시부터 18시 사이에 선택된 한 시간에만 게시하는 구조라면, 날짜와 시간 게이트가 함께 작동해야 합니다.

category는 반드시 바이브코딩으로 유지하는 편이 좋습니다. 아직 여러 카테고리로 넓히기보다 하나의 주제 안에서 충분한 글을 쌓는 단계이기 때문입니다. tags는 4~6개 정도로 제한하면 글의 핵심을 드러내면서도 과도한 키워드 나열을 피할 수 있습니다.

본문 구조와 실제 운영 맥락

본문은 일반적인 AI 이야기로 끝나면 Futory의 장점이 약해집니다. 예를 들어 “AI가 콘텐츠를 잘 써준다”보다 “Next.js Markdown 파일이 추가되고, 콘텐츠 검증과 테마 검증을 통과한 뒤, PM2/Nginx를 거쳐 공개 URL에서 200 응답을 확인한다”는 식의 구체성이 필요합니다. 독자는 추상적인 조언보다 실제 운영 흐름에서 얻은 기준을 더 신뢰합니다.

검증 스크립트는 모든 문장의 품질을 평가할 수는 없지만, 최소 길이, 필수 섹션, FAQ 포함 여부, frontmatter 필드 존재 여부는 충분히 확인할 수 있습니다. 여기에 더해 장기적으로는 금지어, 중복 제목, 오래된 운영 전략, 내부 경로 노출 수준 같은 항목도 검사할 수 있습니다.

테마와 UI 기능 보존

콘텐츠 자동화가 UI 기능을 삭제하면 안 됩니다. Futory에는 다크/라이트 모드가 있고, components/ThemeToggle.tsx, app/theme-init.tsx, CSS의 data-theme 변수 흐름이 유지되어야 합니다. 글 하나를 추가하는 작업이라도 배포 동기화 과정에서 스테이징과 라이브의 차이를 잘못 처리하면 기존 기능이 사라질 수 있습니다.

따라서 npm run test:theme는 콘텐츠 배포에서도 필수입니다. 글만 바꿨는데 왜 테마 테스트가 필요하냐고 볼 수 있지만, 실제 운영에서는 “글만 바꿨다”는 의도와 “동기화 후 결과”가 다를 수 있습니다. 자동화는 의도가 아니라 결과를 검증해야 합니다.

검증 결과를 배포 판단에 연결하기

검증 스크립트의 가장 중요한 역할은 배포 여부를 결정하는 것입니다. 스테이징에서 npm run test:content가 실패했다면 새 글을 수정해야 하고, npm run build가 실패했다면 호스트 PM2를 재시작하지 않아야 합니다. 실패한 빌드를 배포하면 공개 블로그가 깨질 수 있기 때문입니다.

성공한 경우에도 바로 끝이 아닙니다. 컨테이너의 /opt/data/wordblog_next_staging과 호스트의 /opt/wordblog는 다른 경로입니다. Docker socket과 nsenter 또는 호스트 파일시스템 마운트를 사용해 라이브 경로에 안전하게 동기화해야 하며, .env, node_modules, .next, .git처럼 보존해야 할 항목은 제외해야 합니다. 이후 호스트에서 의존성 설치, 콘텐츠 검증, 테마 검증, 빌드, pm2 restart futory-wordblog --update-env를 순서대로 실행해야 합니다.

마지막 판단은 공개 URL입니다. 새 글 상세 URL과 /posts가 HTTP 200을 반환하고, 오늘 날짜가 화면에 노출되어야 게시 성공이라고 말할 수 있습니다. 내부 포트 127.0.0.1:8042만 확인하면 Nginx 프록시나 공개 도메인 문제를 놓칠 수 있습니다. 반대로 공개 확인까지 통과하면 운영 보고에 자신 있게 성공이라고 남길 수 있습니다.

검증 스크립트를 점진적으로 키우는 방법

처음부터 완벽한 검증기를 만들 필요는 없습니다. Futory처럼 운영하면서 발견한 문제를 하나씩 규칙으로 바꾸는 방식이 현실적입니다. 예를 들어 frontmatter 누락이 한 번 문제가 되었다면 필수 필드 검사를 추가합니다. 너무 짧은 글이 올라갈 위험이 있다면 최소 글자 수를 검사합니다. 테마 토글이 사라질 수 있다는 경험이 있다면 테마 파일과 CSS 토큰을 확인합니다.

이렇게 쌓인 검증은 운영 지식의 코드화입니다. 사람이 기억해야 할 체크리스트를 스크립트가 대신 확인하고, 사람은 주제 선정과 맥락 검토에 더 집중할 수 있습니다. AI 에이전트가 글을 작성하더라도 검증 스크립트가 기준선을 지키면 자동 게시의 신뢰도가 올라갑니다.

자주 묻는 질문

Markdown 검증만 통과하면 글 품질이 충분한가요?

아닙니다. 검증은 최소 기준입니다. frontmatter, 구조, 길이, 필수 섹션은 확인할 수 있지만 주제의 참신함과 문장의 설득력은 별도로 봐야 합니다. 다만 자동 게시에서는 최소 기준을 자동으로 막아주는 것만으로도 큰 안정성을 얻습니다.

왜 콘텐츠 배포에서 테마 테스트까지 실행하나요?

스테이징에서 라이브로 동기화할 때 의도치 않게 UI 관련 파일이 바뀔 수 있기 때문입니다. Futory의 다크/라이트 모드는 독자 경험과 연결된 기존 기능이므로, 글 추가 작업에서도 보존 여부를 확인해야 합니다.

공개 URL 확인은 빌드 성공과 다른가요?

다릅니다. 빌드 성공은 정적 결과물이 만들어졌다는 뜻이고, 공개 URL 확인은 PM2와 Nginx를 거쳐 실제 독자가 접근할 수 있다는 뜻입니다. 자동 게시 성공은 두 조건을 모두 만족해야 합니다.

검증 규칙이 많아지면 AI 작성 속도가 느려지지 않나요?

일시적으로는 수정 시간이 늘 수 있습니다. 하지만 장기적으로는 실패한 배포, 중복 글, 누락된 메타데이터를 줄여 운영 시간을 아껴줍니다. 빠르게 쓰는 것보다 안정적으로 공개되는 것이 블로그 운영에는 더 중요합니다.

결론

AI 블로그 운영에서 Markdown 검증 스크립트는 글쓰기 속도를 방해하는 절차가 아니라 자동화를 믿을 수 있게 만드는 기반입니다. Futory는 Next.js Markdown 콘텐츠, KST 기준 자동 게시, PM2/Nginx 배포, 공개 URL 확인이라는 흐름을 갖고 있습니다. 이 흐름에서 콘텐츠 검증과 테마 검증은 새 글이 블로그의 방향과 기존 기능을 해치지 않는지 확인하는 필수 단계입니다.

앞으로 글이 더 쌓일수록 검증 규칙은 더 중요해집니다. 중복 주제 방지, 날짜 관리, 카테고리 일관성, UI 기능 보존, 공개 확인이 자동화될수록 운영자는 더 좋은 주제와 실제 경험을 기록하는 데 집중할 수 있습니다. AI와 함께 만들고, 자동화하고, 운영하는 기록을 오래 유지하려면 매일의 Markdown 파일 하나도 작은 배포로 다루는 습관이 필요합니다.