글 slug, 날짜, 카테고리 구조를 처음부터 어떻게 잡아야 안 꼬이는가

블로그를 조금만 운영해 봐도 금방 느끼게 되는 사실이 하나 있습니다. 글을 많이 쓰는 것보다, 이미 쓴 글의 주소를 안정적으로 유지하는 일이 훨씬 더 어렵다는 점입니다. 특히 기술 블로그는 시간이 지나면서 제목을 다듬고, 카테고리를 다시 정리하고, 일부 글은 시리즈로 묶고 싶어집니다. 이때 초반에 slug, 날짜, 카테고리 구조를 어떻게 잡았느냐가 그대로 발목을 잡기도 하고, 반대로 아주 큰 도움이 되기도 합니다.

처음에는 보통 이렇게 생각합니다. 제목을 기반으로 slug를 만들고, 날짜를 URL에 넣고, 카테고리를 경로에 같이 넣으면 정리돼 보인다고요. 그런데 실제 운영에서는 그 셋이 서로 다른 역할을 합니다. slug는 “주소의 고정 식별자”에 가깝고, 날짜는 “발행 시점 정보”, 카테고리는 “탐색용 분류 체계”에 가깝습니다. 문제는 이 셋을 같은 레벨의 개념처럼 다루는 순간부터 구조가 꼬이기 시작한다는 데 있습니다.

Next.js 공식 문서는 App Router에서 [slug] 같은 dynamic segment를 사용해 경로를 만들 수 있다고 안내합니다. 이 자체는 단순합니다. 하지만 실제 블로그 운영에서는 dynamic segment를 무엇으로 삼을지, 날짜와 카테고리를 URL의 일부로 넣을지, 아니면 본문 메타데이터로만 둘지를 함께 결정해야 합니다. 제 경험상 1인 개발 블로그에서는 이 세 가지를 처음부터 분리해서 생각하는 편이 훨씬 안전합니다.

기반 설계URL 아키텍처

글 slug, 날짜, 카테고리 구조를 처음부터 어떻게 잡아야 안 꼬이는가

기술 블로그를 오래 운영하려면 slug, 날짜, 카테고리를 어디에 저장하고 무엇을 URL에 넣을지 초기에 정해두는 편이 훨씬 안전합니다. 1인 개발 블로그 기준으로 가장 덜 꼬이는 구조를 정리합니다.

핵심 1

먼저 결론: 저는 이렇게 추천합니다

핵심 2

왜 slug, 날짜, 카테고리를 분리해야 하는가

핵심 3

slug는 무엇으로 만들어야 하는가

URL 아키텍처기반 설계slug date category architecture

먼저 결론: 저는 이렇게 추천합니다

기술 블로그 기준으로는 아래처럼 잡는 편이 가장 덜 꼬입니다.

• 본문 URL: /blog/<slug>
• 발행일: frontmatter의 publishedAt
• 수정일: frontmatter의 updatedAt
• 카테고리: 별도 필드와 카테고리 아카이브에서 관리
• canonical: 항상 slug 기준으로 한 주소만 유지

즉 제 기본 추천은 이렇습니다.

/blog/nextjs-blog-folder-structure

여기에 날짜를 URL에 넣지 않고, 카테고리도 URL에 강하게 묶지 않습니다. 날짜와 카테고리는 분명히 중요한 정보이지만, “주소를 결정하는 기준”으로까지 올려버리면 수정 비용이 너무 커집니다.

왜 slug, 날짜, 카테고리를 분리해야 하는가

이 셋은 모두 글을 설명하지만, 설명 방식이 다릅니다.

문제는 많은 블로그가 이 셋을 한 번에 URL에 넣는다는 것입니다.

/2026/04/08/nextjs/nextjs-blog-folder-structure

초반에는 보기 좋습니다. 하지만 나중에 카테고리를 nextjs에서 structure로 바꾸고 싶거나, 날짜를 URL에서 빼고 싶거나, 시리즈 구조를 정리하고 싶어질 때 문제가 생깁니다. URL이 너무 많은 책임을 떠안고 있기 때문입니다.

slug는 무엇으로 만들어야 하는가

slug는 “표시용 제목”이 아니라 “오래 유지되는 주소 식별자”라고 보는 편이 좋습니다. 그래서 저는 slug를 만들 때 아래 기준을 추천합니다.

• 짧고 설명적일 것
• 제목과 완전히 동일할 필요는 없을 것
• 한 번 정하면 되도록 바꾸지 않을 것
• 띄어쓰기 대신 하이픈 사용
• 대문자, 특수문자, 의미 없는 숫자 남발 피하기

예를 들면 이런 식입니다.

좋음: nextjs-blog-folder-structure
보통: nextjs-app-router-blog-folder-structure-guide
피하기: post-12
피하기: NextJS_Blog_Structure!!!

한국어 블로그에서는 종종 “slug도 한글로 갈까?”라는 고민이 생깁니다. 이건 절대 안 되는 건 아닙니다. 브라우저와 검색 엔진은 한글 URL도 처리할 수 있습니다. 다만 운영 관점에서는 영문 소문자 기반 slug가 더 다루기 쉬운 경우가 많습니다. 복사, 공유, 터미널 작업, 배포 로그, 리디렉션, 파일명 연결에서 마찰이 훨씬 적기 때문입니다.

그래서 제 기준은 이렇습니다.

• 본문 제목은 자연스러운 한국어
• slug는 짧은 영문 소문자
• 제목이 바뀌어도 slug는 웬만하면 유지

즉 제목과 slug를 완전히 같은 것으로 취급하지 않는 게 중요합니다.

날짜는 URL에 넣어야 하는가

이건 블로그 종류에 따라 답이 달라집니다. 뉴스 사이트나 시의성이 강한 로그, 일간 기록처럼 날짜 자체가 문서의 성격을 결정하는 경우라면 날짜가 URL에 들어가도 괜찮습니다. 하지만 대부분의 기술 블로그, 특히 오래 검색 유입을 노리는 how-to 글은 날짜를 URL에 넣지 않는 쪽이 더 낫다고 생각합니다.

이유는 세 가지입니다.

1. 글이 금방 낡아 보인다

기술 글은 발행일이 중요하긴 하지만, URL에 연도와 월, 일이 크게 박혀 있으면 독자가 본문을 읽기도 전에 “오래된 글인가?”라는 인상을 받을 수 있습니다. 실제로는 업데이트된 내용이더라도 주소가 오래된 기록처럼 보일 수 있습니다.

2. 정보 구조가 불필요하게 깊어진다

/2026/04/08/... 구조는 보기엔 정돈돼 보여도, 블로그 탐색 관점에서는 쓸모가 많지 않습니다. 독자는 보통 날짜 디렉터리를 따라가며 글을 찾지 않고, 주제나 제목으로 찾습니다.

3. 발행 방식이 바뀌면 이동 비용이 커진다

처음에는 일기처럼 시작했다가 나중에 에버그린 글 중심으로 재편하는 경우가 흔합니다. 이때 날짜가 URL에 박혀 있으면 리디렉션 범위가 커집니다.

그래서 저는 기술 블로그에서는 날짜를 frontmatter와 화면 표시용 메타데이터로만 두고, URL에는 넣지 않는 편을 추천합니다.

publishedAt: "2026-04-08"
updatedAt: "2026-04-08"

필요한 정보는 그대로 보여주되, 주소는 단순하게 유지하는 방식입니다.

카테고리는 URL에 넣어야 하는가

카테고리는 slug보다 더 조심해서 다뤄야 합니다. 왜냐하면 카테고리는 운영하면서 정말 자주 바뀌기 때문입니다. 처음에는 seo라고 묶었다가 나중엔 search-trust로 바꾸고 싶어질 수 있고, nextjs라는 카테고리가 너무 넓어서 structure, deployment, performance로 쪼개고 싶어질 수도 있습니다.

그런데 카테고리를 URL의 일부로 강하게 묶어두면 이런 재편이 전부 주소 변경으로 이어집니다.

/blog/search-trust/meta-title-description-fixes

이 구조가 항상 나쁜 건 아닙니다. 대형 미디어나 문서 사이트처럼 분류 체계가 매우 안정적이면 잘 작동할 수 있습니다. 하지만 1인 개발 블로그는 보통 운영하면서 카테고리가 바뀔 가능성이 훨씬 큽니다. 그래서 제 추천은 카테고리를 “탐색과 정리의 기준”으로 쓰되, 개별 글 URL은 slug만으로 유지하는 방식입니다.

즉 이렇게 갑니다.

• 개별 글: /blog/<slug>
• 카테고리 목록: /blog?category=search-trust 또는 /blog/category/search-trust

이렇게 하면 카테고리를 재정리해도 글 자체 주소는 유지됩니다. 운영 비용이 훨씬 낮아집니다.

처음부터 이렇게 데이터 구조를 잡아두면 좋다

제일 안전한 방식은 글의 표시 제목과 URL 식별자를 분리하고, 날짜와 카테고리를 명시적인 메타데이터로 두는 것입니다.

type ArticleMeta = {
  title: string;
  slug: string;
  category: "structure" | "search-trust" | "operations" | "tools";
  publishedAt: string;
  updatedAt?: string;
  summary: string;
};

그리고 실제 frontmatter는 이런 식으로 두는 편이 좋습니다.

---
title: "글 slug, 날짜, 카테고리 구조를 처음부터 어떻게 잡아야 안 꼬이는가"
summary: "기술 블로그의 주소와 분류 체계를 초기에 어떻게 설계해야 하는지 정리합니다."
publishedAt: "2026-04-08"
updatedAt: "2026-04-08"
category: "structure"
slug: "slug-date-category-architecture"
---

이 구조의 장점은 분명합니다.

• 제목을 다듬어도 slug는 유지 가능
• 카테고리를 재편해도 URL 유지 가능
• 발행일과 수정일을 화면에 따로 표시 가능
• canonical URL 계산이 단순해짐

canonical은 어디를 기준으로 삼아야 하는가

이건 의외로 자주 놓치는 부분입니다. URL 구조를 깔끔하게 잡더라도, 같은 글이 여러 경로로 접근 가능하면 결국 다시 꼬이기 시작합니다. 예를 들어 태그 페이지, 카테고리 페이지, 잘못된 리디렉션, 검색 파라미터 버전이 동시에 존재하면 색인 기준 주소가 흐려질 수 있습니다.

그래서 저는 “글의 진짜 주소는 slug 기반 단일 경로 하나”라는 원칙을 초기에 고정해두는 편이 좋습니다.

export function getCanonicalPath(slug: string) {
  return `/blog/${slug}`;
}

이렇게 기준 함수를 하나 두면 메타데이터, Open Graph, sitemap, 내부 링크를 모두 같은 규칙으로 맞추기 쉬워집니다.

제가 실제로 추천하는 URL 패턴 비교

추천 1. /blog/<slug>

가장 단순하고, 가장 오래 버티는 기본형입니다.

/blog/nextjs-blog-folder-structure

이 방식은 1인 개발 기술 블로그에 가장 잘 맞습니다. 이전에 작성한 Next.js App Router 폴더 구조 글처럼 주제 중심 글에 특히 잘 맞습니다.

조건부 추천. /blog/<category>/<slug>

카테고리 체계가 정말 안정적일 때만 검토할 수 있습니다.

/blog/structure/nextjs-blog-folder-structure

장점은 맥락이 더 드러난다는 점이지만, 단점은 카테고리 재편 비용이 커진다는 것입니다.

비추천. /YYYY/MM/DD/<category>/<slug>

뉴스형이 아니라면 대개 과합니다.

/2026/04/08/structure/nextjs-blog-folder-structure

정리돼 보이지만, 실제 운영에서는 너무 많은 정보를 주소에 넣은 형태입니다.

처음부터 피하면 좋은 실수

1. 제목이 바뀔 때마다 slug를 같이 바꾼다

글 제목은 다듬을 수 있어야 하지만, slug는 가능한 한 고정해야 합니다. 이 둘을 한 몸처럼 다루면 운영 후반에 리디렉션이 계속 생깁니다.

2. 카테고리를 URL 식별자처럼 쓴다

카테고리는 탐색 구조입니다. 식별자 역할까지 맡기면 나중에 재분류할 때 항상 경로 전체를 건드리게 됩니다.

3. 날짜를 URL의 중심으로 둔다

에버그린 글에서는 얻는 이익보다 잃는 유연성이 더 큽니다.

4. slug 생성 규칙이 없다

어떤 글은 짧고 어떤 글은 너무 길고, 어떤 글은 대문자고 어떤 글은 한글이면 나중에 일관성이 무너집니다.

5. canonical 기준 경로가 없다

한 글을 여러 주소로 접근 가능하게 두면, 정보 구조를 잘 짜놔도 다시 중복 문제가 생깁니다.

제가 지금 다시 시작한다면 이렇게 정합니다

• URL은 /blog/<slug>
• slug는 영문 소문자 하이픈
• 제목과 slug는 분리
• 날짜는 메타데이터와 화면 표시용으로만 사용
• 카테고리는 아카이브 탐색용으로만 사용
• canonical은 slug 기반 단일 경로

이 구조는 아주 화려하지는 않지만, 실제로 오래 버팁니다. 특히 1인 개발 블로그처럼 주제와 분류가 점점 다듬어지는 프로젝트에서는 “처음부터 완벽한 분류 체계”보다 “나중에 바꿔도 URL이 안 흔들리는 구조”가 훨씬 중요합니다.

마무리

slug, 날짜, 카테고리는 모두 중요하지만, 같은 종류의 정보는 아닙니다. slug는 주소, 날짜는 문서 이력, 카테고리는 탐색 체계라고 생각하면 대부분의 결정이 쉬워집니다. 제 기준에서는 그래서 기술 블로그를 시작할 때 가장 안전한 선택이 slug 중심 URL + 날짜/카테고리 메타데이터 분리입니다.

처음부터 이 경계를 분명히 잡아두면, 나중에 제목을 다듬고, 카테고리를 재편하고, 아카이브를 확장해도 글 자체 주소는 안정적으로 유지할 수 있습니다. 그리고 그 안정성이 결국 검색 유입, 내부 링크, 운영 편의성 모두에 영향을 줍니다.

이전 글에서 정리한 폴더 구조 글과 Markdown/MDX/CMS 선택 글을 함께 보면, 블로그를 처음 설계할 때 어디를 고정하고 어디를 유연하게 둘지 감을 잡는 데 도움이 될 것입니다.

참고 문서

• Next.js Dynamic Segments
• Next.js Project Structure