AI 블로그 자동화에서 slug 재고를 관리하는 법

요약

Futory처럼 content/posts/*.md 파일이 곧 공개 URL의 원천이 되는 블로그에서는 글을 잘 쓰는 것만큼 slug를 안정적으로 관리하는 일이 중요합니다. slug는 파일명이고, 상세 페이지 주소이며, 빌드 산출물과 공개 검증을 연결하는 기준점입니다. 날짜가 맞고 본문이 충분해도 slug가 기존 글과 너무 비슷하거나, 오늘 발행 로그에서 다른 이름으로 기록되면 운영자는 새 글이 공개된 것인지, 이전 글을 다시 본 것인지 헷갈릴 수 있습니다.

slug 재고 관리는 복잡한 데이터베이스가 아니라 발행 직전의 작은 점검입니다. 오늘 날짜 글이 이미 있는지 확인하고, 최근 글의 파일명과 주제를 읽은 뒤, 새 slug가 무엇을 다루는지 한 문장으로 설명할 수 있어야 합니다. 이 글은 Futory의 바이브코딩 자동 발행 흐름에서 slug를 어떻게 정하고, 테스트와 빌드, 공개 URL 검증까지 같은 이름으로 연결할지 정리합니다.

slug는 운영의 주소이자 증거다

Markdown 블로그에서 slug는 단순한 예쁜 URL이 아닙니다. 자동화가 하루에 한 번 실행되고, 실패하면 다음 시간대에 재시도될 수 있는 환경에서는 slug가 운영 증거의 중심입니다. ai-blog-slug-inventory-routine.md라는 파일은 /posts/ai-blog-slug-inventory-routine이라는 공개 주소로 이어지고, 빌드 산출물 검색과 목록 페이지 검증도 같은 문자열을 사용합니다.

제목보다 slug가 먼저 흔들릴 때가 있다

사람은 제목을 보고 글을 구분하지만, 자동화는 파일명과 frontmatter를 먼저 봅니다. 제목은 한국어로 길고 비슷한 표현을 반복할 수 있지만, slug는 짧고 고유해야 합니다. 예를 들어 “검증 루틴”이라는 제목을 여러 번 쓸 수는 있어도 slug까지 모두 verification-routine에 가까우면 운영 보고서에서 구분이 어려워집니다. 그래서 새 글을 만들기 전에는 최근 파일명 목록을 확인하고, 오늘의 핵심 명사를 slug에 포함하는 습관이 필요합니다.

날짜 중복 방지와 slug 중복 방지는 함께 움직인다

Futory의 반복 발행에서는 먼저 KST 기준 오늘 날짜가 frontmatter나 파일명에 이미 있는지 확인합니다. 이것은 하루 한 편 원칙을 지키기 위한 장치입니다. 하지만 날짜만 보는 것으로는 충분하지 않습니다. 오늘 날짜가 없더라도 과거 글과 거의 같은 slug를 만들면 독자는 비슷한 주제의 글을 반복해서 보게 되고, 운영자는 공개 검증 결과를 잘못 해석할 수 있습니다. 날짜 중복 방지와 slug 재고 확인을 함께 해야 자동화가 조용해집니다.

발행 전 slug 재고 점검 루틴

새 글을 만들기 전에는 최근 글 세 가지를 빠르게 봅니다. 첫째, 파일명 목록입니다. 둘째, frontmatter의 제목과 날짜입니다. 셋째, 본문에서 반복되는 운영 주제입니다. 최근 Futory 글들은 캐시 우회 검증, 미리보기 검증, source of truth, frontmatter 날짜 감사처럼 배포와 검증의 세부 루틴을 다뤘습니다. 오늘의 글이 이 흐름을 잇더라도 같은 말을 반복하지 않으려면 “slug 재고”처럼 새로운 운영 단위를 잡아야 합니다.

영어 kebab-case를 운영 언어로 고정한다

파일명은 영어 kebab-case로 두는 편이 안전합니다. 공백, 한글, 특수문자가 섞이면 쉘 명령, 빌드 로그, URL 복사 과정에서 실수가 늘어납니다. ai-blog-slug-inventory-routine처럼 주제와 맥락을 모두 담되 너무 길지 않은 이름이면 좋습니다. 이 이름은 보고서, .next 검색, 공개 URL 검증에서 그대로 재사용할 수 있습니다.

slug 후보는 한 번에 하나만 선택한다

자동화가 여러 후보를 만들어 두면 이후 단계가 흐려집니다. 오늘 글은 정확히 하나의 파일, 하나의 slug, 하나의 공개 URL을 가져야 합니다. 후보를 비교하는 과정은 글을 쓰기 전 머릿속이나 초안 단계에서 끝내고, 실제 content tree에는 최종 파일 하나만 추가합니다. live Markdown 폴더에 임시 파일을 남기지 않는 것도 중요한 운영 규칙입니다.

작성 후에는 같은 slug로 검증한다

글이 만들어진 뒤에는 모든 확인을 같은 slug로 묶습니다. 콘텐츠 테스트는 frontmatter와 섹션 구조를 확인하고, 테마 테스트는 렌더링 규칙과 충돌하지 않는지 봅니다. 빌드는 새 Markdown을 Next.js가 실제 페이지로 만들 수 있는지 보여 줍니다. 이후 .next 산출물에서 slug를 찾으면 파일과 빌드가 연결되었다는 증거가 생깁니다.

공개 URL 검증도 slug 중심으로 남긴다

PM2 재시작 뒤에는 /posts/<slug> 상세 페이지를 먼저 확인합니다. 상세 페이지가 200을 반환하면 직접 접근 가능성은 확보된 것입니다. 그다음 홈, /posts, /vibe-coding 목록에서 오늘 날짜나 slug가 보이는지 확인합니다. 이때 cache-busting query string과 Cache-Control: no-cache 헤더를 사용하면 오래된 응답을 새 상태로 착각할 가능성을 줄일 수 있습니다.

실패해도 새 slug를 만들지 않는다

빌드나 공개 검증이 실패했을 때 가장 위험한 대응은 같은 날짜로 새 slug를 다시 만드는 것입니다. 실패는 이름의 문제가 아니라 테스트, 빌드, 런타임, 캐시 중 하나의 문제일 수 있습니다. 이미 오늘 날짜 파일이 있다면 그 파일과 slug가 기준입니다. 다음 행동은 로그를 읽고 끊긴 단계를 고치는 것이지, 새 글을 추가하는 것이 아닙니다.

운영 보고서에 남길 항목

slug 재고 관리를 제대로 하려면 마지막 보고서가 짧아도 구체적이어야 합니다. 선택된 KST 시간, 생성 파일 경로, title, date, slug, 콘텐츠 테스트 결과, 테마 테스트 결과, 빌드 결과, .next 포함 여부, PM2 재시작 상태, 공개 상세와 목록 검증 결과를 한 번에 남깁니다. 이렇게 남긴 보고서는 다음 크론 실행의 중복 방지 자료가 됩니다.

사람이 읽을 수 있는 이름도 함께 둔다

slug만 남기면 기계는 편하지만 사람에게는 딱딱합니다. 그래서 보고서에는 한국어 제목과 공개 URL을 함께 둡니다. 제목은 운영자가 글의 의미를 이해하게 하고, slug는 검증 명령과 공개 주소를 재현하게 합니다. 두 값을 함께 기록하면 빠른 확인과 정확한 추적이 동시에 가능합니다.

자주 묻는 질문

slug가 조금 길어도 괜찮나요?

괜찮습니다. 다만 너무 긴 문장형 slug는 보고서와 URL에서 읽기 어렵습니다. Futory 운영에서는 주제, 대상, 루틴 정도를 담은 4~6개 단어의 kebab-case가 실용적입니다. 핵심은 짧음 자체가 아니라 고유성과 재사용 가능성입니다.

제목을 바꾸면 slug도 바꿔야 하나요?

공개 후에는 되도록 바꾸지 않는 편이 좋습니다. slug는 이미 공개 URL과 검증 기록에 연결되어 있기 때문입니다. 발행 전이라면 제목과 slug를 함께 다듬을 수 있지만, 발행 후에는 제목만 수정하고 slug는 유지하는 것이 링크 안정성에 유리합니다.

slug 재고 관리를 자동화할 수 있나요?

할 수 있습니다. 오늘 날짜 검색, 최근 파일명 목록, 유사 slug 탐지는 스크립트로 보조할 수 있습니다. 하지만 최종 주제 선택은 블로그의 흐름을 고려해야 하므로, 자동화는 후보를 줄이고 중복을 막는 역할에 집중하는 편이 좋습니다.

결론

Futory의 AI 블로그 자동화에서 slug는 작은 문자열이지만 운영 전체를 묶는 실마리입니다. 파일명, 공개 URL, 빌드 산출물, 검증 로그가 모두 같은 slug를 가리킬 때 발행 상태는 명확해집니다. 반대로 slug가 불안정하면 테스트가 성공해도 보고서와 공개 확인이 흐려질 수 있습니다.

바이브코딩의 장점은 빠르게 만들고 바로 확인하는 데 있습니다. 그 속도를 안전하게 유지하려면 매일 새 글을 만들기 전에 slug 재고를 확인하고, 작성 후에는 같은 slug로 끝까지 검증해야 합니다. 좋은 자동화는 더 많은 이름을 만드는 시스템이 아니라, 오늘 선택한 하나의 이름을 공개까지 책임지는 시스템입니다.