AI 블로그 자동화에서 slug 안정성을 운영하는 법

요약

Futory처럼 Markdown 파일 하나가 곧 글의 원본이 되고, Next.js 빌드가 그 파일을 공개 URL로 연결하는 구조에서는 slug가 작은 문자열 이상의 의미를 갖습니다. slug는 파일명이고, 상세 페이지 경로이며, 목록 페이지가 글을 식별하는 단서이고, 크론 보고서가 발행 성공을 증명하는 키입니다. 그래서 평일 자동 발행 루틴은 제목을 멋지게 짓는 일만큼이나 slug를 안정적으로 정하는 일을 중요하게 다뤄야 합니다.

실무 기준은 단순합니다. 한 번 공개된 slug는 바꾸지 않고, 오늘 새로 만드는 글은 최근 글의 주제와 겹치지 않는 영어 kebab-case 파일명을 사용하며, 빌드 후 .next 산출물과 공개 페이지에서 같은 slug가 보이는지 확인합니다. 이 과정을 루틴으로 고정하면 AI가 작성한 글이라도 운영자는 어떤 파일이 어떤 URL이 되었는지 빠르게 추적할 수 있습니다.

slug는 운영 계약이다

Markdown 블로그에서 slug는 보통 content/posts/example-post.md의 example-post 부분입니다. 겉으로는 파일명처럼 보이지만 실제로는 여러 계층을 묶는 계약입니다. 작성 단계에서는 새 파일을 구분하고, 빌드 단계에서는 정적 페이지 생성 대상이 되며, 공개 단계에서는 /posts/example-post 같은 주소가 됩니다.

자동화가 이 계약을 느슨하게 다루면 문제가 생깁니다. 같은 날짜에 두 파일이 만들어지지 않았더라도 비슷한 slug가 생기면 운영 보고서가 헷갈립니다. 제목을 나중에 다듬는 과정에서 파일명을 같이 바꾸면 이미 공유된 링크가 깨질 수 있습니다. 반대로 제목은 조금 바뀌어도 slug가 그대로라면 검색 색인, 내부 링크, 검증 스크립트가 안정적으로 동작합니다.

사람이 읽는 규칙으로 만든다

좋은 slug는 기계만 읽기 쉬운 값이 아니라 사람이 봐도 주제를 짐작할 수 있는 값이어야 합니다. Futory의 경우 ai-blog-slug-stability-routine처럼 프로젝트 맥락, 핵심 주제, 루틴 성격을 함께 담는 방식이 유용합니다. post-20260907처럼 날짜만 있는 이름은 중복 방지에는 도움이 되지만 나중에 장애를 추적할 때 내용이 떠오르지 않습니다.

반대로 너무 긴 문장형 slug도 피해야 합니다. 길수록 오타 가능성이 늘고, 공개 검증 로그가 읽기 어려워집니다. 실무에서는 세 단위 정도로 나누는 것이 좋습니다. 예를 들어 ai-blog는 범위, slug-stability는 이번 주제, routine은 운영 문서 성격을 뜻합니다.

자동 발행에서 slug를 정하는 순서

자동화가 글을 만들 때는 제목보다 먼저 최근 slug 목록을 확인하는 편이 안전합니다. 최근 며칠의 파일명, 제목, 설명, 태그를 함께 보면 이미 다룬 운영 주제를 피할 수 있습니다. 그다음 오늘 다룰 좁은 주제를 정하고, 주제를 영어 kebab-case로 바꿉니다. 마지막으로 파일을 쓰기 전에 같은 이름이 이미 있는지 확인합니다.

이 순서가 중요한 이유는 재시도 때문입니다. 크론은 네트워크 오류, 빌드 실패, PM2 재시작 실패 같은 이유로 다시 실행될 수 있습니다. 이때 날짜 중복 가드가 1차 방어선이라면 slug 중복 확인은 2차 방어선입니다. 날짜가 오늘인 글이 이미 있으면 멈추고, 파일명이 이미 있으면 덮어쓰지 않는다는 원칙이 있어야 기존 글을 보호할 수 있습니다.

frontmatter와 파일명을 분리해서 본다

제목은 한국어로 독자에게 자연스럽게 보여야 하고, 파일명은 영어 slug로 안정적으로 남아야 합니다. 두 값이 반드시 직역 관계일 필요는 없습니다. 중요한 것은 둘이 같은 주제를 가리키고, 보고서에서 함께 기록된다는 점입니다.

예를 들어 이 글의 제목은 “AI 블로그 자동화에서 slug 안정성을 운영하는 법”이고 파일명은 ai-blog-slug-stability-routine.md입니다. 제목에는 독자 맥락을 넣고, 파일명에는 운영자가 검색하기 쉬운 키워드를 남겼습니다. 이런 분리는 Futory 같은 한국어 블로그에서 특히 실용적입니다.

검증 루틴에 slug를 포함하기

새 글을 쓴 뒤에는 콘텐츠 테스트와 테마 테스트, 빌드를 통과하는 것만으로 끝내지 않아야 합니다. 빌드 산출물 안에 slug가 포함되어 있는지 확인해야 합니다. 이 확인은 “새 Markdown 파일이 실제 라우트 생성 대상에 들어갔다”는 증거가 됩니다.

그다음 PM2를 재시작하고 공개 URL을 확인합니다. 상세 페이지 /posts/ai-blog-slug-stability-routine이 200을 반환하는지 보고, 홈과 /posts, /vibe-coding 목록에도 오늘 날짜나 slug가 보이는지 확인합니다. 캐시 때문에 이전 화면이 남을 수 있으므로 쿼리 문자열과 no-cache 헤더를 붙여 확인하는 것이 좋습니다.

보고서에는 같은 키를 반복한다

운영 보고서에는 제목, 날짜, 파일 경로, 공개 URL, slug를 함께 적어야 합니다. 같은 slug가 백업, 빌드 산출물, 공개 URL, 목록 검증 결과에 반복해서 등장하면 나중에 로그만 보고도 어느 단계에서 문제가 생겼는지 알 수 있습니다. 특히 무인 크론에서는 이런 반복이 장황함이 아니라 안전장치입니다.

자주 묻는 질문

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

대부분은 바꾸지 않는 편이 좋습니다. 공개 후 slug를 바꾸면 기존 링크와 검색 색인이 흔들릴 수 있습니다. 제목이 크게 틀린 것이 아니라면 파일명은 유지하고 frontmatter의 제목과 설명만 다듬는 방식이 안전합니다.

날짜가 있으면 slug 중복 검사는 필요 없나요?

필요합니다. 날짜 중복 검사는 하루 한 글 원칙을 지키는 장치이고, slug 검사는 URL과 파일 충돌을 막는 장치입니다. 두 검사는 목적이 다르기 때문에 함께 두어야 합니다.

한국어 slug를 써도 되나요?

기술적으로 가능하지만 운영 자동화에서는 영어 kebab-case가 더 다루기 쉽습니다. 터미널 로그, 빌드 산출물 검색, 외부 도구 연동, URL 공유에서 인코딩 문제를 줄일 수 있기 때문입니다.

결론

Futory의 AI 블로그 자동화에서 slug는 단순한 파일명이 아니라 발행 전체를 이어 주는 안정적인 식별자입니다. 최근 글을 확인해 주제를 좁히고, 영어 kebab-case로 파일명을 만들고, 빌드 산출물과 공개 페이지에서 같은 slug를 검증하면 무인 발행의 신뢰도가 높아집니다. 좋은 자동화는 글을 쓰는 데서 끝나지 않고, 나중에 운영자가 그 글을 확실히 찾고 검증할 수 있게 만드는 데까지 이어집니다.