URL 슬러그 생성기
제목을 깔끔한 URL 안전 경로로 변환 — kebab-case, 소문자, 악센트 없음
제목 또는 텍스트
슬러그
URL 슬러그 생성기란?
"JavaScript에서 URL 파싱하는 법 — 카페 사장의 가이드 (2026년판)"이라는 블로그 글을 썼고 이제 URL 경로가 필요합니다. %E2%80%94가 거기 들어가는 건 원치 않고, 공백도 원치 않으며, 대소문자 구분 서버에서 깨지는 대문자도 원치 않습니다. 원하는 건 javascript-url-parsing-guide-cafe-owner-2026-edition 같은 형태입니다. 이 도구가 그걸 합니다. 제목을 붙여넣고 슬러그를 복사하세요. 이 용어 자체는 출판업계에서 왔습니다 — 어원은 위키피디아의 슬러그 항목을 참고하세요.
알고리즘은 표준입니다. 소문자로 변환한 다음, String.prototype.normalize('NFD')를 실행해 유니코드 문자를 베이스 문자와 결합 부호로 분해합니다. 부호를 제거합니다(그래서 é는 e가 됩니다). 일반적인 합자 몇 개는 수동 처리 — æ는 ae, ø는 o, ß는 ss, ł은 l이 됩니다. 영숫자가 아닌 문자의 연속은 단일 하이픈으로 교체. 앞뒤 하이픈을 제거. 단어 경계에서 80자로 제한해 단어 중간에서 잘린 슬러그가 되지 않도록 합니다.
왜 kebab-case인가? 하이픈이 관례이기 때문입니다. Google의 URL 구조 가이드라인은 URL에서 단어 구분에 언더스코어보다 하이픈을 권장합니다 — 검색 엔진은 하이픈을 단어 경계로 파싱합니다. RFC 3986은 URL 경로의 비예약 문자(영문자, 숫자, 하이픈, 마침표, 언더스코어, 물결표)를 정의하며 대부분의 슬러그 관례는 그 부분집합을 따릅니다. Snake_case(my_post_title)와 Title-Case-Slug(My-Post-Title)도 보이는 대안이지만, 소문자 kebab-case가 깔끔한 URL 관행부터 대부분의 CMS 기본값까지 어디서나 디폴트입니다.
슬러그 생성기 사용법
세 단계. 각각 이 페이지의 버튼에 대응합니다.
제목을 붙여넣거나 샘플 불러오기
왼쪽 패널에 제목, 헤드라인, 상품명 또는 임의의 텍스트를 넣으세요. 샘플을 클릭하면 em 대시, 악센트, 괄호가 들어간 현실적인 예제가 로드됩니다 — 단순한 슬러그 코드를 깨뜨리는 종류의 제목입니다. 샘플 입력:
How to Parse a URL in JavaScript — A Café Owner's Guide (2026 Edition)뭐든 됩니다 — 이모지, 악센트 문자, 스마트 따옴표, em 대시, 이중 하이픈, 다중 공백. 슬러그는 깔끔하게 나옵니다.
슬러그 읽기
오른쪽 패널은 입력하는 동안 슬러그를 보여줍니다. 소문자, 하이픈 구분, ASCII만, 단어 경계에서 80자로 제한. 입력에 슬러그화 가능한 문자가 없는 경우(예: 이모지만 있거나 구두점만 있는 경우) 혼란스러운 빈 결과 대신 친절한 안내 메시지를 보게 됩니다.
복사 또는 다운로드
복사를 클릭해 슬러그를 클립보드로 보내거나 다운로드로 .txt 파일로 저장하세요. 새 제목으로 다시 시작하려면 입력 패널의 지우기를 사용하세요.
실제로 쓸 만한 상황
블로그 글 URL
CMS가 슬러그를 자동 생성하지만 보기 안 좋습니다 — 악센트를 잘못 제거하고, 언더스코어를 남기고, 스마트 따옴표를 처리하지 않습니다. 제목을 여기 붙여넣고, 깔끔한 슬러그를 받아 URL 필드에 다시 붙여넣으세요. WordPress, Ghost, 직접 만든 Next.js 블로그 등 슬러그 덮어쓰기를 허용하는 무엇에든 동작합니다.
이커머스의 상품/카테고리 URL
Marco Rivera가 "Crème Brûlée Set — 4 Pack (Limited Edition)"이라는 새 상품을 추가합니다. URL은 /products/creme-brulee-set-4-pack-limited-edition이어야 하지, /products/Crème+Brûlée+Set+%E2%80%94+4+Pack+%28Limited+Edition%29이 되어선 안 됩니다. 슬러그화하고 꽂아 넣으세요.
사람이 입력한 제목으로부터 파일명
업로드된 문서를 디스크에 저장하는데 고객이 제목으로 "Q4 Report — Final (v3).docx"를 입력했습니다. 그걸 파일명으로 쓰고 싶지는 않습니다. 제목을 슬러그화하고, .docx를 붙이고, 파일을 씁니다. S3 키, 이슈 제목으로부터 GitHub 브랜치 이름, 프로젝트 이름으로부터 Slack 채널 이름에도 같은 방식으로 동작합니다.
다른 CMS로부터 콘텐츠 마이그레이션
Priya Patel이 800개 글을 레거시 CMS에서 새 CMS로 옮기고 있는데 원본 제목들의 인코딩이 일관되지 않습니다 — 악센트가 있는 것, 없는 것, 2018년 리디자인 때의 이모지가 있는 것 등. 각 제목을 슬러거에 통과시키고 중복을 제거하면 리다이렉트 테이블용 새 URL 맵이 준비됩니다.
자주 묻는 질문
왜 악센트를 퍼센트 인코딩하지 않고 제거하나요?
슬러그는 사람이 읽으라고 만드는 것이기 때문입니다. 슬러그의 café는 실제 URL에서 %C3%A9가 되는데, 브라우저 주소창에서 보기 안 좋고, 채팅에서 복사-붙여넣기를 깨뜨리며, 비기술 독자를 혼란스럽게 합니다. ASCII로 줄이면 URL을 읽기 쉽고 SEO 친화적으로 유지합니다. NFD 정규화가 그 분해를 수행하는 표준적인 방법입니다.
비라틴 문자(중국어, 아랍어, 힌디어)는 어떻게 되나요?
NFD는 표의문자나 베이스+결합 부호 구조를 갖지 않는 문자를 분해하지 않습니다. 그래서 중국어 제목은 여기서 빈 슬러그를 만들고 "슬러그화 가능한 문자가 없습니다" 메시지를 보게 됩니다. 비라틴 문자에는 두 가지 옵션이 있습니다: 먼저 음역(ICU나 unidecode 같은 라이브러리 사용)하거나, URL에 원래 문자 그대로 사용 — 현대 브라우저와 Google은 URL의 유니코드를 잘 처리합니다, 외관이 좀 덜 예쁠 뿐입니다.
왜 80자로 제한하나요?
엄격한 규칙은 없지만, 경로 세그먼트가 ~80자를 초과하는 URL은 이메일, SNS 미리보기, 인쇄물에서 줄바꿈이 나빠지기 시작합니다. Google의 가이드는 숫자를 정하진 않지만 "단순하고 서술적인" URL을 권장합니다 — 긴 것은 둘 다 아닙니다. 이 제한은 단어 중간 절단을 피하기 위해 80자 이전의 마지막 하이픈을 찾습니다.
이모지를 처리하나요?
네. 이모지는 다른 영숫자가 아닌 문자와 함께 제거됩니다. 그래서 "🎉 New Launch! 🚀"는 new-launch가 됩니다. 슬러그가 비게 되면(이모지만 있는 입력) 깨진 URL 대신 친절한 빈 슬러그 안내를 받습니다.
제목을 URL 인코딩하는 것과 무엇이 다른가요?
URL 인코딩은 모든 문자를 유지하되 안전하지 않은 것을 이스케이프합니다 — 그래서 공백은 %20, 악센트는 퍼센트 이스케이프된 UTF-8 바이트가 됩니다. 결과는 유효한 URL이지만 읽을 수 없습니다. 슬러그는 다른 것입니다: 거기 속하지 않는 문자를 버리는 사람 친화적인 경로 세그먼트입니다. 쿼리 파라미터에는 URL 인코딩, 경로 세그먼트에는 슬러그를 사용하세요. WHATWG URL Standard에 둘 다의 정확한 정의가 있습니다.
kebab-case와 snake_case 중 어느 것을 써야 하나요?
URL에는 kebab-case(my-post-title) — 그게 관례이며 검색 엔진이 단어 구분자로 취급하는 것입니다. Snake_case(my_post_title)는 변수명과 데이터베이스 식별자에는 좋지만, URL에서는 언더스코어가 종종 단어의 일부로 취급되어 SEO를 해칩니다. 이 도구는 kebab이 기본입니다. snake가 필요하면 출력의 하이픈을 찾아 바꾸세요.
다른 URL 및 텍스트 도구
슬러그는 URL의 한 조각입니다. 함께 쓰기 좋은 도구들: