URL 슬러그를 만들고 기존 링크 보존하기

문제 상황

제목을 슬러그로 바꾸는 일은 작아 보이지만 결과 문자열은 공개 식별자의 일부가 됩니다. 시스템마다 대소문자 구분, Unicode 정규화, 퍼센트 인코딩, 끝 슬래시, 예약어, 최대 바이트, 경로 충돌 규칙이 다릅니다. ASCII 음역은 엔진이 지원하지 않는 문자 체계를 삭제할 수 있고 읽기 쉬운 Unicode 경로는 퍼센트 인코딩 시 훨씬 길어질 수 있습니다. 더 중요한 점은 공개 후 슬러그 변경이 단순 텍스트 변환이 아니라는 것입니다. 해당 주소에는 외부 링크, 북마크, 검색 이력, 분석 차원, 캐시 응답, 언어 대체 링크, 구조화 데이터, 피드, 앱 참조가 연결되어 있을 수 있습니다. 여러 locale이 같은 콘텐츠 ID를 공유하는지 번역마다 별도 경로를 소유하는지에 따라서도 redirect, canonical, hreflang 설계가 달라집니다. 따라서 깔끔한 후보는 시작일 뿐입니다. 신뢰할 수 있는 작업 단위에는 정확한 원문, 고정한 변환 설정, 실제 플랫폼의 중복·예약 경로 조회, 스테이징 동작, 모든 기존 변형의 영구 리디렉션, canonical·내부 참조 갱신, 출시 후 수집·트래픽 증거, 롤백 경로가 모두 포함됩니다.

공식 출처와 표준

다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.

• URL Living Standard

  WHATWG

이럴 때 사용하세요

• 새 글, 도움말, 상품 페이지, 릴리스 노트, 문서 섹션에 첫 공개 전 안정적인 경로가 필요할 때
• 다국어 제목을 Unicode로 읽기 쉽게 유지하거나 검토된 ASCII 전용 경로 정책을 적용할 때
• 팀이 CMS나 저장소에 구분자, 대소문자, camelCase, 정규화, 최대 길이 규칙을 고정할 때
• 기존 경로가 부정확하거나 중복되거나 일관되지 않아 URL 이전을 검토할 때
• 앱, 프록시, CDN, DB, 분석, sitemap, 검색 노출 전체에서 경로 규칙을 출시 전에 검증할 때

단계

1. 1단계

   플랫폼과 현재 경로 계약 조사하기

   공개 origin, locale 구조, 라우터와 CMS 버전, 대소문자 구분, 끝 슬래시, Unicode 정규화, 퍼센트 인코딩, 예약 경로, DB 컬럼 제한, CDN·프록시 제한과 이미 공개된 URL인지 기록합니다. 변경 전에 현재 경로, canonical, hreflang, sitemap 항목, 리디렉션, 내부 링크, 구조화 데이터, 피드 참조, 최근의 정상 분석·검색 증거를 내보냅니다.

2. 2단계

   원문을 보존하고 비공개 초안 정보 제거하기

   정확한 제목, 현재 슬러그, 전체 URL, 콘텐츠 ID, locale, 시각을 변경 기록에 남깁니다. 브라우저·클립보드·스크린샷·다운로드를 사용하기 전에 비공개 코드명, 고객 식별자, 토큰, 미공개 제품 정보를 제거합니다. 로컬 생성은 의도적인 업로드를 피하지만 기기 기록과 확장 프로그램을 통제하지는 않습니다.

3. 3단계

   명시적인 경로 정책 하나 선택하기

   국제 문자를 Unicode로 유지할지 ASCII 음역을 요구할지 정하고 하이픈·밑줄, 소문자, 영문 camelCase 분리, 선택적 표시 길이를 고정합니다. 지원하지 않는 문자 체계가 사라진다면 Unicode를 우선하세요. ASCII 표기는 자동 번역이 아니라 화자나 브랜드 담당자가 확인해야 할 편집 콘텐츠로 취급합니다.

4. 4단계

   후보 하나를 생성하고 경고 검토하기

   Slug Generator를 Manual 모드로 실행하고 @sindresorhus/slugify 3.0.0과 모든 옵션을 기록합니다. 제거된 구두점, 의미, 단어 경계, 미지원 문자 경고, 잘림, 표시 길이, 퍼센트 인코딩 길이를 확인합니다. 도구 한도는 10,000 UTF-8바이트, 20줄, 한 줄 5,000바이트지만 실제 경로 이름은 훨씬 짧고 페이지 주제에 집중해야 합니다.

5. 5단계

   실제 시스템에서 소유권·중복·예약 동작 확인하기

   CMS, 라우터, DB, 저장소, 생성된 경로 manifest에서 정확한 후보와 정규화 변형을 조회합니다. 대문자·소문자, NFC·NFD Unicode, 디코딩·퍼센트 인코딩, 끝 슬래시, locale 접두사, 프레임워크·관리 경로 같은 예약 이름을 시험합니다. 스테이징 레코드를 생성·수정해 실제 충돌과 정규화 동작을 증명합니다.

6. 6단계

   공개 URL의 전체 이전 구성하기

   기존 공개 변형을 하나의 새 canonical URL로 연결하는 플랫폼 맞춤 영구 리디렉션을 유지합니다. canonical·hreflang, 내부 링크, 탐색, sitemap, 구조화 데이터, Open Graph URL, 피드, API 참조, 캠페인 링크, 테스트, 분석 주석을 갱신합니다. 체인과 루프를 피하고 의도한 경우에만 query string을 보존하며 리디렉션 활성화 전에 기존 경로를 삭제하지 않습니다.

7. 7단계

   스테이징·출시·모니터링·롤백 증거 유지하기

   스테이징에서 대표 query·locale 변형으로 이전·신규 URL을 요청해 상태, Location, 최종 canonical, robots, 본문, 캐시 헤더를 확인하고 내부 링크를 수집합니다. 출시 후 edge 검사를 반복하고 404, 리디렉션 오류, 수집·색인, 정상 유입, 전환을 이전·신규 경로별로 관찰합니다. 캐시·크롤러·연동·사용자가 안정될 때까지 이전 라우팅 규칙과 정확한 롤백 조건을 유지합니다.

예시

2026 여름 여행 준비와 안전한 URL 가이드

2026-여름-여행-준비와-안전한-url-가이드

흔한 실수

자주 묻는 질문