글 주소를 이렇게 만들었습니다.
/blog/무지개는-7색이-아니다한국어 사이트니까 주소도 읽을 수 있으면 좋겠다고 생각했습니다. 빌드는 아무 경고 없이 성공했고, 정적 페이지 159개가 만들어졌다고 로그에 찍혔습니다. 그리고 열어 보니 전부 404였습니다.
어긋나는 지점
브라우저가 저 주소를 요청할 때, 실제로 서버에 도착하는 경로는 퍼센트 인코딩된 형태입니다.
/blog/%EB%AC%B4%EC%A7%80%EA%B0%9C%EB%8A%94-7%EC%83%89...그런데 빌드 산출물의 프리렌더 목록에는 한글 원문 그대로 기록돼 있습니다. 정적 파일 매칭은 요청이 애플리케이션 코드에 닿기 전 단계에서 일어나므로, 컴포넌트 안에서 decodeURIComponent를 부르든 유니코드 정규화(NFC/NFD)를 맞추든 소용이 없습니다. 매칭은 이미 끝나 있고, 결과는 404입니다.
이 문제의 고약한 점은 빌드가 성공한다는 것입니다. 에러도 경고도 없습니다. 로컬에서 프로덕션 모드로 띄워 실제로 열어 보기 전까지는 아무 신호가 없습니다.
슬러그가 한국어 검색에서 하는 일
고치면서 따로 확인한 게 있습니다. 그럼 로마자로 음차하면(/blog/mujigae-neun-7-saek) 검색에 도움이 되느냐. 답은 아니오였습니다.
URL 슬러그의 키워드 기여는 원래도 미미하고, 한국어를 로마자로 적은 문자열은 검색어와 일치하지도 않습니다. 사용자가 mujigae라고 검색하지 않기 때문입니다. 키워드를 전달하는 것은 title 태그, h1, 본문이고 이 셋이 전부 한국어라면 이미 충분합니다.
그래서 결론은 ASCII 식별자였습니다. 글 번호를 그대로 씁니다.
/blog/1
/blog/100읽어서 뜻을 알 수 없는 주소지만, 잃는 게 없습니다. 공유될 때 보이는 것은 제목이고, 검색에 잡히는 것도 제목과 본문입니다.
가져갈 규칙
- 정적 생성 경로에는 ASCII만 씁니다. 비ASCII 슬러그는 인코딩 경계를 여러 번 넘나들며, 넘을 때마다 깨질 자리가 생깁니다.
- 빌드 성공은 동작의 증거가 아닙니다. 프로덕션 모드로 띄워 실제 URL을 열어 봐야 합니다.
- URL 스킴처럼 전체에 일괄 적용되는 결정은, 159개에 적용하기 전에 한 개로 확인합니다.