모든 처리는 브라우저 내부에서 실행됩니다 — 파일·입력은 서버로 전송되지 않습니다.
제목이나 파일명을 붙여 넣으면 URL 경로·CSS 클래스·정규화된 파일명으로 쓸 수 있는 ASCII 슬러그가 생성됩니다. 구분자(`-`·`_`·`.`)를 고르고 소문자화를 토글하며, 필요하면 최대 길이를 지정해 단어 경계에서 잘라 냅니다. 한글은 국어의 로마자 표기법(Revised Romanization)으로 변환되고(`서울` → `seoul`), 가나는 헤본식으로(`ありがとう` → `arigatou`), 라틴 악센트는 NFKD 분해 후 제거됩니다(`café` → `cafe`, `naïve` → `naive`).
블로그 글이나 CMS 항목, 파일명에서 CJK나 악센트가 들어간 제목으로부터 안정된 ASCII 핸들이 필요한 경우에 사용하세요. Google은 Unicode URL도 색인하지만, ASCII 슬러그는 복사·붙여 넣기, 터미널 로그, 모니터링 대시보드, 멀티바이트가 깨지기 쉬운 팀 채팅에 더 잘 통합니다. 한글 로마자 변환표와 헤본식 로직은 브라우저 안에 내장되어 있으므로 비공개 글 제목이 서버에 닿지 않습니다.
서울에서 일본 IT 회사 다니는 이야기
seoul-eseo-ilbon-it-hoesa-daninun-iyagi
한글은 국립국어원이 2000년에 발표한 국어의 로마자 표기법(Revised Romanization)으로 변환됩니다. 각 음절이 일관되게 매핑되고(`서울` → `seoul`, `회사` → `hoesa`) `IT` 같은 라틴 부분은 그대로 통과합니다. 결과는 한국어 화자가 제목으로 인식할 만큼 역추적이 가능하면서도 거치는 모든 시스템에서 안전한 ASCII 형태에 머무릅니다.
日本企業のAWSコスト管理でよくある失敗
ri-ben-qi-ye-noawskosutoguan-li-deyokuarushi-bai
히라가나·카타카나는 헤본식으로 변환됩니다(`コスト` → `kosuto`, `よくある` → `yokuaru`). 한자는 사전 조회를 하지 않아서 각 글자에 대한 핀인 풍의 읽기로 폴백합니다. `日本企業`이 `nihon-kigyou`가 아니라 `ri-ben-qi-ye`가 되는 이유입니다. 일본어 비중이 큰 URL에서는 URL에 일본어를 그대로 두고 브라우저의 퍼센트 인코딩에 맡기거나(`/日本企業の…`) 로마자를 손으로 적는 사이트가 많습니다. 이 도구의 로마자 변환은 실용적 기본값이지 번역이 아닙니다.
Pourquoi mon application Node.js consomme trop de mémoire en production ? separator: - lowercase: yes max length: 60
pourquoi-mon-application-node-js-consomme-trop-de-memoire
NFKD는 `é`를 `e`와 결합용 어큐트 기호로 분해하고, 이어서 악센트가 제거됩니다. 끝의 물음표와 `en production ?` 부분은 60자 한계 밖으로 밀려나며, 잘림이 단어 경계에서 일어나므로 슬러그가 단어 중간에 끝나지 않습니다. CMS나 프레임워크가 더 엄격한 제한을 둔다면 상한을 더 낮추세요. Google이 권장하는 소프트 상한은 75자입니다.
브라우저는 Unicode URL을 무리 없이 처리하지만 그 이후의 경로는 항상 그렇지 않습니다. 서버 로그, Slack 스니펫, 이메일에 복사된 링크, 분석 대시보드, 모니터링 도구, 다수의 CLI가 비-ASCII 경로를 망가뜨리거나 퍼센트 인코딩 주문(`%EC%84%9C%EC%9A%B8`)으로 표시합니다. ASCII 슬러그는 모든 경로를 살아남습니다. 대가는 URL 바에서 스캔하기 약간 어려워진다는 것이고, 얻는 것은 로그와 대시보드의 가독성입니다. CJK URL을 남기는 팀도 있고 로마자화를 택하는 팀도 있습니다. 견딜 수 있는 쪽의 고통을 고르세요.
제거됩니다. 이 도구는 Unicode NFKD 정규화를 실행해 `é`를 기저 글자 `e`와 결합용 어큐트 악센트(U+0301)로 분해한 뒤 결합 마크를 모두 삭제합니다. `naïve` → `naive`, `crème brûlée` → `creme-brulee`처럼 됩니다. 이것은 대부분의 CMS 슬러그 생성(WordPress·Hugo·Jekyll 등)과 같은 동작입니다. 악센트를 유지한 슬러그가 필요하면 URL을 Unicode 그대로 두어야 합니다. 순수 ASCII 규칙과 악센트 보존은 양립하지 않습니다.
의미 있는 단어 3~5개, 소프트 상한 60~75자를 목표로 하세요. Google의 SEO 문서에는 엄격한 상한이 없지만 "짧고 설명적이게"라고 적혀 있습니다. 검색 결과 스니펫에서는 URL이 약 60자 부근에서 시각적으로 잘립니다. 로그와 대시보드는 전체 경로를 표시할 수 있지만 200자 경로는 SNS 미리보기에서 스팸처럼 보이고 음성으로 공유하기도 어렵습니다. WordPress는 기본적으로 상한이 없고 Hugo·Jekyll·주요 정적 사이트 생성기도 긴 슬러그를 받지만 제목 자체를 짧게 두는 편이 권장됩니다.
한자를 일본어 음으로 매핑하려면 사전 조회가 필요합니다. `日`은 `nichi`·`hi`·`jitsu` 또는 `nihon` 같은 숙어의 일부가 될 수 있고, 정답은 문맥에 의존합니다. 형태소 분석기(kuromoji·MeCab)를 내장하지 않으면 도구가 메가바이트급 사전 데이터를 들고 있어야 해서, Unicode CJK Unified Ideographs 블록에 기반한 글자 단위 로마자화(`日` → `ri` 같은 핀인 풍)로 폴백합니다. 일본어 비중이 높은 제목은 슬러그 필드에 손으로 로마지를 적거나, 사전을 가진 CMS 플러그인을 함께 쓰세요.
아포스트로피는 앞뒤 글자가 같은 단어에 속하므로 구분자를 끼우지 않고 제거됩니다. `don-t-think`은 읽기 어색하고 단어 인식을 깨뜨립니다. `dont-think`이 독자의 기대에 맞습니다. 대부분의 슬러그 라이브러리도 동일한 처리를 합니다. 스타일 가이드가 어떤 이유로 아포스트로피 분할을 요구한다면 출력을 한 번의 치환으로 후처리하세요.
내장되어 있지 않습니다. 이 도구는 입력에 충실한 결과를 돌려주는 방침입니다. 불용어 제거는 "어느 것을 불용어로 볼지"가 주관적이고 언어에도 의존합니다. "10 ways to improve your SEO"를 "10-ways-improve-your-seo"로 줄이면 몇 글자와 가독성의 약간을 맞바꿉니다. 최근 SEO 통설에서는 짧은 불용어를 슬러그에 남기는 편이 좋다고 봅니다. 그래도 깎고 싶다면 출력에 sed 한 번을 돌리거나 손으로 편집하세요. 남겨 두어도 해가 없습니다.
URL 슬러그란 경로 안에서 사람이 읽기 쉽고 URL 안전한 부분을 가리킵니다 — `/blog/seoul-eseo-ilbon-it/`의 `seoul-eseo-ilbon-it`이 그것입니다. 임의의 텍스트를 슬러그로 만드는 변환은 두 단계입니다. **로마자화**는 비라틴 문자를 라틴 글자로 대응시킵니다. 한글은 국어의 로마자 표기법(2000년), 일본어 가나는 헤본식(1867년 제정, 지금도 가장 보편적인 규격)을 따릅니다. **Unicode 정규화 + 악센트 제거**는 악센트가 든 라틴 글자를 NFKD로 기저 글자와 결합 마크로 분해하고(RFC 3454 IDNA, Unicode TR15), 결합 마크를 제거합니다. 이 일련의 처리는 설계상 비가역입니다. 서로 다른 두 제목에서 같은 슬러그가 나올 수 있습니다. 따라서 슬러그는 저장 측의 안정 레코드 ID와 짝지어 운용하는 것이 기본입니다.
근본적인 선택은 **ASCII URL vs Unicode URL**입니다. 현대 브라우저·검색 엔진·HTTP 라이브러리는 IRI(국제화 리소스 식별자, RFC 3987)를 무리 없이 다룹니다. 판단은 결국 실용입니다. ASCII 슬러그는 로그·터미널·복사 붙여넣기·모니터링 도구·애널리틱스를 깔끔히 통과합니다. Unicode URL은 모국어 화자에게 가독성을 지켜 주지만 디코드하지 않는 UI에서는 퍼센트 인코딩 덩어리(`%EC%84%9C%EC%9A%B8`)로 보입니다. 성숙한 CMS는 어느 방향이든 일관된 결과를 돌려줍니다. WordPress는 키릴 문자를 로마자화하고 CJK는 기본적으로 Unicode 그대로 두며, Hugo는 퍼머링크마다 선택을 허용합니다. 어느 쪽을 택하든 나중에 슬러그 규칙을 바꾸면 기존 URL이 모두 고아가 되므로 초기에 정하고 일관성을 지키세요.
인접한 3가지 개념이 있습니다. **IDN·Punycode**(`xn--…`)는 도메인 쪽을 담당합니다. 호스트명은 퍼센트 인코딩을 쓸 수 없으므로 국제화 도메인은 비-ASCII를 ASCII 봉투에 숨깁니다(예: `日本.jp` → `xn--wgv71a.jp`). **퍼머링크**는 공개된 URL이 어떻게 보일지를 정하고 그것이 바뀌지 않는다는 것을 약속하는 정책 계층입니다. 슬러그가 부품, 퍼머링크가 계약입니다. **파일명 정규화**는 거의 같은 알고리즘을 사용하지만 구분자 선호(URL은 `-`, 파일명은 `_`가 흔함)와 더 엄격한 길이 제한(대부분의 파일 시스템에서 255바이트, 실무적 크로스 플랫폼 호환에서는 훨씬 짧음)이 다릅니다.
한국 주소를 영문 표기로 변환합니다. 해외 배송, 비자 신청, 각종 폼 작성에 유용합니다. 시/도 영문명 테이블과 도로명·구의 자동 로마자 변환을 내장했습니다.
문자, 단어, 줄, 바이트(UTF-8)를 실시간으로 집계합니다.
camelCase / PascalCase / snake_case / kebab-case / CONSTANT_CASE / Title Case를 서로 변환합니다.
단어/문장/단락 단위로 더미 텍스트를 생성합니다. 고전적인 "Lorem ipsum…" 시작 옵션 지원.
