LLM 시대, 한글 슬러그는 왜 위험한가 – 퍼센트 인코딩 오류 사례

검색엔진 최적화(SEO)와 한글

많은 검색엔진 최적화(SEO) 전문가들은 검색엔진의 간택을 받기 위해, 콘텐츠가 작성된 언어와 슬러그(slug : 웹 페이지의 URL 주소 중 페이지 이름 부분)의 언어를 일치시켜야 한다고 말한다. 실제로 구글(Google), 빙(Bing), 네이버(Naver), 얀덱스(Yandex)와 같은 주요 검색 엔진의 SEO 권장 사항들을 살펴보면, 콘텐츠의 URL은 그 내용과 타겟 사용자를 반영하여 사용자가 의미를 쉽게 파악할 수 있도록 구성할 것을 권장하고 있다.

잠재고객의 언어 사용: URL에 잠재고객의 언어로 된 단어(해당하는 경우 음역된 단어)를 사용합니다. 예를 들어 잠재고객이 독일어로 검색하는 경우 URL에 독일어 단어를 사용하세요. – 구글 SEO 가이드

사이트를 방문하는 사용자들도 쉽게 의미를 파악할 수 있는 URL 체계를 갖춰야 합니다. – 네이버 웹마스터 가이드

즉, SEO 관점에서 볼 때 콘텐츠의 언어와 URL의 언어를 일치시키고, 사용자가 이해할 수 있는 구조로 URL을 구성하는 것은 매우 자연스럽고 권장되는 전략이다. 본 필자 역시 이러한 기준에 따라 초기 블로그 페이지의 URL 구조를 한글 슬러그를 이용해 구성한 바 있다.

이러한 권장사항은 전통적인 검색엔진 크롤러 환경에서는 문제없이 동작한다. 그러나 최근 사용이 증가하고 있는 대규모 언어 모델(LLM) 기반의 검색 환경에서는, 한글과 같은 다국어 슬러그가 포함된 URL 구조가 문제를 일으키는 경우가 있다.

다국어와 퍼센트 인코딩

URL의 표준을 정의하고 있는 RFC-1738에 따르면, URL에는 아스키(ASCII) 문자에 해당하는 영문, 숫자, 일부 특수 기호만을 사용할 수 있다. 이러한 환경에서 한글이나 히라가나와 같은 문자를 사용하기 위해서는, 각각의 문자에 대응하는 유니코드(Unicord : 세상의 모든 문자들을 컴퓨터에서 표기하기 위한 규약)의 값을 UTF-8 형식으로 전송하는 방법을 사용하는데, 이를 퍼센트 인코딩(Percent-Encoding)이라 한다. 예를 들어, 웹 브라우저에 https://www.decteng.com/ko/배터리테스트라는 주소를 입력할 경우, 실제 전송되는 URL 주소는 다음과 같이 변환된다.

https://www.decteng.com/ko/배터리테스트
=
https://www.decteng.com/ko/%EB%B0%B0%ED%84%B0%EB%A6%AC%ED%85%8C%EC%8A%A4%ED%8A%B8

한글에 해당하는 슬러그 부분이 알 수 없는 코드들도 바뀐 것을 알 수 있는데, 한글 한 글자에 해당하는 유니코드로 치환 된 것이다.

• %EB%B0%B0 : 배
• %ED%84%B0 : 터
• %EB%A6%AC : 리
• %ED%85%8C : 테
• %EC%8A%A4 : 스
• %ED%8A%B8 : 트

LLM 환경에서 URL이 깨지는 이유 : 토큰화

전통적인 프로그래밍 언어나 웹 브라우저는 urldecode() 같은 함수를 통해 바이트 단위로 엄격하게 데이터를 해석한다. 즉, 퍼센트 인코딩된 URL을 하나의 문자열로 인식하는데 문제가 없다는 말이다.

한편, LLM은 텍스트를 토큰(Token) 단위로 쪼개어 수치화해 처리한다. LLM은 각자의 어휘 사전(Vocabulary)이라는 개념을 가지고 있는데, 여기에는 LLM이 인식하고 처리할 수 있는 최소 단위인 토큰들이 정의 되어 있다. 이 사전에는 학습 빈도가 많은 패턴들이 기록되는데, 문제는 LLM의 어휘 사전(Vocabulary)에 %ED%84%B0와 같은 긴 인코딩 문자열이 없는 경우가 매우 많다는 점이다.

때문에 LLM은 퍼센트 인코딩 부분을 완성된 문자열로 인식하는 대신, 정형적이지 않고 의미가 불분명해 보이는 ‘분해의 대상’으로 간주하고 다음과 같이 분해한다.

%EB%B0%B0%ED%84%B0%EB%A6%AC
→ "%", "EB", "%", "B0", "%", "B0", ...

그리고, 이렇게 분해된 작은 토큰의 수가 많아지면 패턴 인식에 실패할 가능성이 올라가고, 그 자리에 엉뚱한 정보를 대신 집어넣는 AI환각(LLM hallucination : 정보를 그럴듯하게 만들어내는 현상)으로 이어지게 된다. 결과적으로, 아래와 같은 문제가 발생하며 존재하지 않는 URL로 인식하는 상황이 발생하게 된다.

• 퍼센트 인코딩 문자열이 중간에서 잘림
• 일부 바이트가 누락되어 잘못된 문자로 복원
• URL 전체가 하나의 경로로 인식되지 않음

아래는 본 필자가 Gemini를 이용해 블로그 콘텐츠를 검수하는 과정에서 실제로 겪은 사례로, 퍼센트 인코딩된 URL의 일부를 제대로 인식하지 못한 Gemini가 반복적으로 잘못된 주소로 접근을 시도하면서, 정상적으로 동작하는 페이지를 존재하지 않는 것으로 응답하고 있는 벽창호와 같은모습을 볼 수 있다. 당시 슬러그는 약 80자 이상의 한글이었고, 10개의 URL을 입력해 주면 7~8개 정도의 URL에 대해 이런 결과가 동일하게 반복적으로 나왔다. (처음에는 서버나 네트워크 문제인줄 알고 정말 쌩 쑈를 다 했다. ㅜㅜ)

즉, 아무리 맞는 URL을 입력해 주어도, LLM이 못 알아먹는 상황이 발생한다.

점점 늘어나는 LLM 의존도

문제는 이러한 현상이 단순한 기술적 오류에 그치지 않는다는 점이다. 사용자들의 정보 탐색 방식 자체가 변화하고 있기 때문이다.

2026년 1월 오픈서베이에서 발표한 AI 검색 트렌드 리포트 2026에 따르면, 2025년 한해동안 검색 서비스 이용 형태는 다음과 같은 변화를 보였다.

• 검색 목적으로 LLM을 이용하는 비율이 급증하고, 기존 플랫폼의 검색 지배력이 감소.
• ‘장소·쇼핑·콘텐츠’중심 검색에서 ‘지식·업무’ 목적의 검색이 증가
• 사용자는 검색 결과의 나열이 아닌 ‘결과의 요약’을 선호
• 원하는 답을 찾지 못했더라도 기존 플랫폼이 아닌 LLM을 통해 해결

요약하자면, 사용자의 콘텐츠 접근 경로에서 LLM이 차지하는 비중이 점차 늘어나고 있다는 것으로, URL이 단순히 검색엔진 크롤러에 의해 해석되는 수준을 넘어, LLM에 의해 정확하게 전달되고 다뤄져 그 정보를 제공해 줄 수 있어야 한다는 것이다.

즉, 이제 URL은 검색엔진뿐 아니라 LLM에서의 안정적인 처리를 함께 고려해 주어야 한다.

LLM 시대의 URL 전략은 달라질 필요가 있다.

전통적인 SEO 관점에서는 콘텐츠의 언어와 URL의 언어를 일치시키는 것이 매우 자연스럽고 효과적인 전략이었다. 그러나 이러한 전략은 ‘검색엔진 크롤러’를 기준으로 최적화된 접근 방식이다.

최근 검색 환경은 LLM 기반의 자연어 질의 응답 중심으로 빠르게 이동하고 있으며, 이 과정에서 URL은 더 이상 단순한 경로 정보가 아니라, AI가 해석하고 전달해야 하는 데이터가 되었다.

LLM에서 발생하는 다국어 URL 처리를 위한 퍼센트 인코딩 문자열의 토큰 파편화 문제는, 본 필자의 사례와 같이 실제로 발생하고 있는 문제이다. 즉, 검색엔진 기준에서는 문제가 없던 구조가, LLM 환경에서는 오히려 불안정한 구조가 될 수 있는 것이다. 그리고 검색의 패러다임은 LLM으로 이동하고 있다.

때문에 이제 URL은 단순히 검색엔진에 최적화된 구조가 아니라, 다양한 AI 시스템에서도 안정적으로 유지되고 전달될 수 있는 형태로 설계될 필요가 있다.

이러한 문제를 고려할 때, 다음과 같은 실무적인 접근 방식이 현실적인 대안이 될 수 있다.

• 영문 기반 슬러그 사용 : 퍼센트 인코딩을 최소화하여 LLM에서의 손상 가능성을 줄인다.
• URL 구조 단순화 : 경로를 짧고 명확하게 유지하여 토큰 분해로 인한 오류를 최소화한다.
• 단축 URL 활용 : 필요에 따라 복잡한 URL을 단순한 형태로 변환하여 전달 안정성을 확보한다.
• 이중 URL 전략 : 한글과 영문 URL을 병행하고 canonical 설정을 통해 SEO와 안정성을 동시에 확보한다.
• 문맥 기반 링크 전달 : URL 단독이 아닌 설명과 함께 전달하여 LLM이 내용을 보완할 수 있도록 한다.

본 필자의 경우는, 블로그 콘텐츠의 양이 그다지 많지 않은 시점에 이러한 문제를 마주하게 되어 슬러그 체계를 전면 수정해 영문 기반으로 통일하는 방식을 선택했다.