AI 블로그 자동화에서 frontmatter 품질 게이트를 세우는 법

요약

Futory처럼 Next.js와 Markdown으로 운영되는 AI 블로그에서 frontmatter는 단순한 머리말이 아닙니다. 제목은 목록의 클릭 이유가 되고, description은 검색과 공유 카드의 요약이 되며, date는 최신 글 정렬과 중복 방지의 기준이 됩니다. category와 tags는 독자가 글을 찾는 길이고, 자동화 입장에서는 “이 글이 어떤 계약으로 공개되어야 하는가”를 알려 주는 작은 데이터베이스입니다.

그래서 평일 무인 발행 루틴은 본문을 잘 쓰는 것만큼 frontmatter 품질을 엄격하게 확인해야 합니다. 새 Markdown 파일을 만들기 전에 최근 글과 주제가 겹치지 않는지 보고, 작성한 뒤에는 날짜, 카테고리, 태그, slug가 서로 맞는지 점검해야 합니다. 이 품질 게이트가 있으면 Futory의 바이브코딩 자동화는 빠르게 글을 만들면서도 목록 누락, 잘못된 날짜, 중복 주제 같은 운영 사고를 줄일 수 있습니다.

frontmatter를 운영 데이터로 보는 이유

Markdown 블로그에서는 파일 하나가 글의 원본입니다. 하지만 Next.js는 그 파일을 읽어 라우트, 목록, 메타데이터, 카테고리 페이지를 만듭니다. 즉 frontmatter가 틀리면 본문이 아무리 좋아도 공개 화면의 동작이 흔들립니다.

제목은 콘텐츠의 식별자다

제목은 사람에게 보이는 첫 신호입니다. 자동화가 제목을 만들 때는 멋진 표현보다 구체성이 먼저입니다. “AI 블로그를 잘 운영하는 법”처럼 넓은 제목은 이전 글과 겹치기 쉽습니다. 반대로 “frontmatter 품질 게이트를 세우는 법”처럼 좁은 제목은 오늘 글의 역할을 분명히 보여 줍니다. 최근 Futory 글들이 백업, 공개 검증, 발행 창, 환경 신호처럼 운영 절차를 하나씩 다루고 있다면 새 제목도 그 흐름 안에서 한 가지 문제만 잡아야 합니다.

description은 목록과 검색의 계약이다

description은 짧지만 중요합니다. 독자는 목록에서 글을 열지 말지 판단하고, 검색 엔진은 페이지의 주제를 이해합니다. 자동 생성 글에서는 description이 본문 첫 문장을 그대로 반복하는 경우가 많지만, 운영 블로그에서는 더 구체적인 편이 좋습니다. 어떤 프로젝트에서, 어떤 문제를, 어떤 결과로 해결하는지 한 문장에 담아야 합니다. Futory라면 “Next.js Markdown 발행 루틴”, “공개 반영 전 오류”, “frontmatter 품질 게이트”처럼 맥락과 효용을 함께 써야 합니다.

품질 게이트를 발행 흐름에 넣는 방법

frontmatter 품질 게이트는 별도의 거대한 시스템이 아니라 발행 순서 안에 들어가는 작은 체크리스트입니다. 중요한 점은 생성 이후에 대충 훑는 것이 아니라, 테스트와 빌드 전에 실패할 수 있는 조건을 분명히 두는 것입니다.

날짜와 파일명은 같은 날을 가리켜야 한다

Futory의 weekday 루틴은 Asia/Seoul 기준으로 하루 한 편을 발행합니다. 따라서 frontmatter의 date는 KST 오늘 날짜여야 하고, 중복 검사는 같은 날짜로 수행되어야 합니다. 파일명은 영어 kebab-case slug를 사용하되 날짜를 꼭 넣을 필요는 없습니다. 다만 오늘 날짜가 이미 frontmatter나 파일명에 있으면 새 글을 만들지 않는 규칙이 먼저 실행되어야 합니다. 이 순서가 있어야 재시도 상황에서도 같은 날 두 편이 생기지 않습니다.

category와 tags는 목록 진입로다

category: "바이브코딩"은 Futory의 바이브코딩 목록에 들어가기 위한 직접적인 신호입니다. tags는 더 세밀한 탐색을 돕습니다. 태그를 너무 많이 넣으면 초점이 흐려지고, 너무 적으면 다음 자동화가 주제 중복을 판단하기 어렵습니다. 좋은 태그 묶음은 공통 태그인 “바이브코딩”, “AI 블로그”, “Next.js”, “Markdown”, “자동화”에 오늘의 핵심인 “frontmatter”나 “품질검증” 같은 좁은 신호를 더하는 방식입니다.

본문 구조와 frontmatter를 함께 본다

frontmatter가 정확해도 본문이 요구 구조를 놓치면 발행 품질은 떨어집니다. 반대로 본문이 길고 좋아도 title과 description이 모호하면 목록에서 힘을 잃습니다. 그래서 품질 게이트는 ## 요약, 여러 H2와 H3, ## 자주 묻는 질문, ## 결론 같은 본문 구조와 frontmatter 필드를 함께 확인해야 합니다. 자동화 보고서에 본문 글자 수와 필수 섹션 존재 여부를 남기면, 나중에 문제가 생겼을 때 어느 계약이 지켜졌는지 빠르게 알 수 있습니다.

Next.js Markdown 운영에서 자주 생기는 실수

frontmatter 문제는 보통 작은 오타에서 시작됩니다. 따옴표가 빠지거나, 배열 형식이 깨지거나, 카테고리 값이 기존 목록과 다르게 적히면 빌드 또는 목록 렌더링 단계에서 문제가 드러납니다. 더 까다로운 경우는 빌드는 성공하지만 공개 목록에 글이 보이지 않는 상황입니다.

빌드 성공이 곧 노출 성공은 아니다

npm run build가 통과했다면 문법과 정적 생성은 대체로 안전합니다. 그러나 PM2 재시작이 실패하면 공개 사이트는 이전 빌드 결과를 계속 보여 줄 수 있습니다. 또한 목록 페이지가 다른 필터 조건을 사용한다면 상세 URL은 열리지만 홈이나 카테고리 페이지에서는 빠질 수 있습니다. 그래서 Futory 루틴은 build 이후 .next 산출물에서 slug를 확인하고, PM2 재시작 뒤 공개 URL과 목록 페이지를 다시 확인합니다.

제목만 검색하면 검증이 흔들린다

한국어 제목은 HTML에서 줄바꿈, escape, 메타 태그 위치 때문에 단순 문자열 검색이 불안정할 수 있습니다. 공개 검증에서는 slug와 날짜를 우선 신호로 삼는 편이 안정적입니다. 상세 페이지는 /posts/<slug>의 HTTP 200을 확인하고, 홈과 /posts, /vibe-coding에서는 오늘 날짜 또는 slug가 있는지 본다면 캐시나 렌더링 차이에도 비교적 강합니다.

자주 묻는 질문

frontmatter를 자동으로 더 많이 넣으면 좋나요?

필드가 많다고 품질이 좋아지는 것은 아닙니다. 사용하지 않는 필드가 늘어나면 자동화와 테마가 해석해야 할 계약도 늘어납니다. Futory의 현재 루틴에서는 title, description, date, category, tags를 일관되게 쓰는 것이 더 중요합니다.

slug는 한국어로 만들어도 되나요?

가능한 환경도 있지만 무인 운영에서는 영어 kebab-case가 안전합니다. URL 인코딩 문제를 줄이고, 빌드 산출물과 공개 검증에서 문자열을 찾기 쉽기 때문입니다. slug는 글의 핵심을 짧게 담되 기존 글과 겹치지 않아야 합니다.

frontmatter 오류는 언제 발견하는 것이 가장 좋나요?

가장 좋은 시점은 파일을 만든 직후, 빌드 전에 발견하는 것입니다. npm run test:content가 이 역할을 맡고, 이후 npm run test:theme와 npm run build가 렌더링 계약을 확인합니다. 공개 검증은 마지막 안전망으로 남겨 두어야 합니다.

결론

AI 블로그 자동화의 품질은 긴 본문보다 작은 계약을 얼마나 꾸준히 지키는지에서 결정됩니다. Futory의 frontmatter 품질 게이트는 제목, 설명, 날짜, 카테고리, 태그를 운영 데이터로 다루게 해 줍니다. 이 데이터를 정확히 만들고 테스트, 빌드, 공개 검증으로 확인하면 무인 발행은 더 빠르면서도 덜 위험해집니다.

바이브코딩의 장점은 실행 속도입니다. 하지만 빠른 실행이 지속되려면 매번 같은 기준으로 멈추고 확인하는 장치가 필요합니다. frontmatter를 작은 체크리스트로 관리하는 습관은 Futory가 매일 한 편씩 안정적으로 쌓이는 데 필요한 가장 현실적인 운영 기술입니다.