AI 블로그 자동화에서 구조화 데이터 점검을 루틴화하는 법

요약

Futory처럼 Markdown 파일 하나가 곧 블로그 글이 되는 구조에서는 본문을 잘 쓰는 것만으로 발행이 끝나지 않습니다. 제목, 설명, 날짜, 카테고리, 태그, canonical URL, sitemap 반영처럼 여러 신호가 함께 맞아야 검색 엔진과 독자가 같은 글을 안정적으로 발견할 수 있습니다. 특히 AI가 매일 글을 작성하고 Next.js가 정적 산출물로 묶어 내는 자동화에서는 구조화 데이터 점검을 작은 운영 루틴으로 만들어 두는 편이 안전합니다.

이 글은 새 Markdown 글을 만든 뒤 frontmatter, 상세 페이지, 목록 페이지, 빌드 산출물, 공개 URL을 어떻게 연결해서 확인할지 정리합니다. 목표는 거창한 SEO 최적화가 아니라 “오늘 만든 글이 기계와 사람 모두에게 같은 의미로 보이는가”를 검증하는 것입니다.

왜 구조화 데이터 점검이 필요한가

AI 블로그 자동화는 빠르지만 같은 속도만큼 작은 누락도 반복하기 쉽습니다. 예를 들어 파일명은 올바른데 date가 빠져 있거나, description이 너무 일반적이거나, 상세 페이지에는 표시되지만 목록에는 반영되지 않는 상황이 생길 수 있습니다. 이런 문제는 한 번 발생하면 글 하나의 품질 문제가 아니라 이후 자동 발행 루틴 전체에 대한 신뢰 문제로 이어집니다.

구조화 데이터는 검색 엔진을 위한 JSON-LD만 의미하지 않습니다. Futory 운영 관점에서는 Markdown frontmatter와 라우팅 규칙, 공개 HTML의 메타 태그, 목록 카드에 나타나는 제목과 날짜까지 모두 같은 계약의 일부입니다. 이 계약이 맞아야 크론 재시도, PM2 재시작, 캐시 우회 검증을 할 때 판단 기준이 흔들리지 않습니다.

Futory에서 확인할 핵심 신호

1. frontmatter의 최소 계약

새 글은 다음 정보를 반드시 가져야 합니다.

• title: 목록과 상세 페이지에서 독자가 보는 대표 문장
• description: 검색 결과와 공유 미리보기의 기대치를 만드는 설명
• date: 하루 한 글 중복 방지의 기준
• category: Futory의 주제 축을 유지하는 분류
• tags: 다음 글이 최근 주제를 피할 때 참고하는 지문

AI가 작성한 글이라도 이 값들은 운영자가 검토하기 쉬운 형태여야 합니다. 특히 description은 “AI 블로그 자동화에 대한 글”처럼 넓게 쓰기보다, “구조화 데이터와 메타 정보를 함께 확인해 검색 노출과 공개 검증의 신뢰를 높인다”처럼 이번 글의 실무 초점을 담는 편이 좋습니다.

2. slug와 공개 경로의 일치

파일명은 영어 kebab-case로 두고, 공개 URL은 /posts/<slug> 규칙을 따릅니다. 이때 slug는 제목을 그대로 번역하기보다 운영 기록으로도 읽히는 이름이 좋습니다. 예를 들어 ai-blog-structured-data-check-routine은 주제, 점검 대상, 루틴 성격을 모두 드러냅니다.

이름이 명확하면 빌드 산출물에서 새 slug를 찾기도 쉽고, 공개 검증 실패 시 “파일은 있는데 라우트가 없는지”, “라우트는 있는데 캐시가 오래된지”를 빠르게 분리할 수 있습니다.

3. 공개 HTML의 메타 정보

빌드가 성공해도 실제 공개 HTML에 오늘 날짜나 slug가 보이지 않으면 아직 발행이 끝난 것이 아닙니다. Futory 운영에서는 상세 URL을 먼저 확인하고, 이어서 홈, /posts, /vibe-coding 목록에서 오늘 글이 노출되는지 확인하는 순서가 실용적입니다. 각 요청에는 cache-busting 쿼리와 Cache-Control: no-cache 헤더를 붙여 이전 응답을 새 발행으로 착각하지 않도록 합니다.

자동화 루틴에 넣기 좋은 절차

발행 전: 최근 글의 주제 지문 읽기

새 글을 쓰기 전에 최근 10~20개의 제목, 설명, 태그, slug를 읽으면 중복 주제를 피하기 쉽습니다. Futory에는 이미 발췌문, canonical URL, alt 텍스트, 내부 링크, sitemap, description 같은 점검 루틴 글이 있으므로 오늘은 구조화 데이터라는 더 좁은 관점으로 잡는 식입니다.

이 단계는 콘텐츠 품질뿐 아니라 자동화 안정성에도 도움이 됩니다. 다음 실행이 오늘 글을 중복으로 만들지 않으려면 날짜뿐 아니라 주제 지문도 분명해야 하기 때문입니다.

작성 후: Markdown 파일 하나만 추가되었는지 확인

정기 발행 크론은 기존 글을 수정하지 않는 것이 안전합니다. 새 파일 하나만 추가하고, 이후 테스트와 빌드에서 문제가 발견되면 그 파일을 기준으로 원인을 좁힙니다. 이 방식은 장애 영향 반경을 줄이고, 백업에서 복구할 때도 판단을 단순하게 만듭니다.

빌드 후: 산출물에서 slug 찾기

npm run build가 성공했다면 .next 내부 산출물에 새 slug가 포함되어 있는지 확인합니다. 이는 Markdown 파서, 라우트 생성, 정적 빌드 단계가 글을 실제 페이지 후보로 인식했다는 신호입니다. 단순히 테스트 통과만 보고 PM2를 재시작하면 “빌드는 됐지만 새 글은 포함되지 않은” 상태를 놓칠 수 있습니다.

운영자가 보는 체크리스트

1. 오늘 KST 날짜와 선택된 발행 시간이 맞는가?

2. 같은 날짜의 frontmatter 또는 파일명이 이미 존재하지 않는가?

3. 최근 글과 겹치지 않는 좁은 주제인가?

4. 새 Markdown 파일의 frontmatter 계약이 정확한가?

5. content/theme 테스트와 Next.js build가 모두 통과했는가?

6. .next 산출물에서 slug가 확인되는가?

7. PM2 재시작 뒤 상세 URL이 200을 반환하는가?

8. 홈, 글 목록, 바이브코딩 목록에서 오늘 날짜 또는 slug가 보이는가?

이 체크리스트를 매번 짧게 남기면 다음 크론 실행이나 수동 장애 분석에서 큰 차이가 납니다. “어디까지 됐는지”가 명확하면 중복 발행을 피하면서도 안전하게 재시도할 수 있습니다.

자주 묻는 질문

JSON-LD까지 꼭 만들어야 하나요?

처음부터 복잡한 JSON-LD를 추가할 필요는 없습니다. 먼저 frontmatter, URL, 목록, sitemap, 공개 HTML처럼 현재 Futory가 이미 사용하는 신호를 일관되게 만드는 것이 우선입니다. 이후 글 타입이 다양해지거나 검색 리치 결과를 노린다면 JSON-LD를 별도 계약으로 추가하면 됩니다.

description은 AI가 자동으로 쓰게 해도 괜찮나요?

가능하지만 검증 기준이 필요합니다. 너무 짧거나 일반적인 문장은 목록 품질과 중복 방지에 도움이 되지 않습니다. 좋은 description은 프로젝트 맥락, 이번 글의 구체적 초점, 독자가 얻는 결과를 한 문장 안에 담습니다.

공개 URL이 200인데 목록에 없으면 성공인가요?

부분 성공입니다. 상세 페이지가 살아 있어도 목록에 없으면 독자가 자연스럽게 발견하기 어렵고, 운영 검증도 불완전합니다. Futory 루틴에서는 상세 URL 200과 함께 홈, /posts, /vibe-coding 목록 반영까지 확인하는 편이 안전합니다.

결론

Futory의 AI 블로그 자동화에서 구조화 데이터 점검은 SEO 장식이 아니라 발행 신뢰를 지키는 운영 절차입니다. Markdown frontmatter, slug, 빌드 산출물, 공개 HTML, 목록 페이지가 같은 글을 같은 날짜와 의미로 가리키는지 확인하면 매일 반복되는 크론 발행도 훨씬 안정적입니다.

좋은 자동화는 글을 빠르게 만드는 데서 끝나지 않습니다. 새 글이 어디에 있고, 어떤 제목과 설명으로 노출되며, 실제 공개 페이지에서 확인되었는지를 작게 증명하는 데까지 이어져야 합니다. 그 증거가 쌓일수록 Futory의 바이브코딩 운영은 더 안전하고 예측 가능해집니다.