다국어 LLMO

콘텐츠 번역은 필요조건이지 충분조건이 아닙니다. 2026년 기준으로 “포르투갈어 버전을 공개했다”와 “AI 검색이 내 포르투갈어 버전을 인용한다” 사이에는 실재하고 측정 가능한 격차가 있습니다. 이 가이드는 다국어 LLMO가 해결해야 할 두 가지 문제를 다룹니다. AI 엔진이 올바른 언어 버전을 인용하게 만드는 것, 그리고 어떤 언어가 투자에 보답하는지 결정하는 것입니다.

잘못된 언어 버전이 인용되는 문제

클래식 검색 엔진은 어떤 문서를 제공할지 결정한 후 제공합니다. hreflang은 20년간 튜닝된 랭킹 시그널이며, Google은 언어가 일치하는 URL을 선택하는 것을 정말 잘합니다.

LLM 기반 엔진은 다르게 동작합니다. 몇 가지 문서를 검색하고, 사용자의 언어로 답변을 생성하고, 검색 레이어가 부상시킨 URL을 첨부합니다. 생성 단계는 유창하게 다국어를 지원합니다. 언어 선택이 살아있는 것은 검색(retrieval) 단계이며 — 그곳은 자주 영어 편향이 작동합니다.

동일한 다국어 쿼리를 엔진 횡단으로 테스트한 결과(Glenn Gabe, GSQI)와 4개 언어 사이트 자체의 인용 추적에서 관측된 동작:

• Google 백엔드 엔진(AI Overviews, AI Mode, Gemini, Copilot)은 수십 년간의 hreflang 처리를 계승하며, 대부분 올바른 로컬라이즈 버전 URL을 인용합니다.
• Perplexity는 프랑스어 선호 설정에서도 미국 영어 페이지를 반환했습니다.
• ChatGPT는 프랑스어로 답변을 쓰고, 페이지의 영어 버전에 링크했습니다. 답변은 독자의 언어를 말하지만, 인용은 그렇지 않습니다.

검색 레이어가 영어로 기본 설정되는 이유:

• 영어 버전 페이지는 피링크와 크롤 이력이 더 많아, 독자의 언어에 상관없이 검색 인덱스에서 상위에 오릅니다.
• 많은 AI 크롤러는 Googlebot만큼 hreflang 클러스터를 완전히 파싱하지 않습니다.
• 번역 품질은 신뢰 시그널입니다. 번역된 페이지가 기계 출력처럼 읽힌다면, 검색 레이어는 이를 저신뢰 중복으로 취급하고 영어 원본에 손을 뻗습니다.

실패의 정체는 “AI가 포르투갈어를 말하지 못한다”가 아닙니다. “AI의 검색 레이어가 당신의 포르투갈어 페이지를 인용할 만큼 충분히 신뢰하지 않는다”입니다.

실제로 효과가 있었던 것, 효과 순서

4개 언어 사이트에서의 단일 변수 실험(실측 보고서、영어):

1. hreflang + x-default — 가장 효과적이었습니다. 모든 언어 버전이 적절한 x-default와 함께 전체 클러스터를 선언해야 합니다. 이것이 Google 백엔드 엔진이 확실히 읽는 유일한 시그널이며, 그 엔진들이 AI 검색의 큰 부분을 차지합니다. 하나만 한다면 이것을 올바르게 하세요.
2. 언어별 자기 참조 canonical — 은근히 결정적입니다. 각 언어 버전은 영어 원본이 아닌 자기 자신에게 canonical을 향해야 합니다. canonical이 영어를 향한 번역 페이지는 모든 크롤러에게 “진짜 페이지는 영어 버전입니다”라고 말하는 — 자해 행위입니다.
3. 언어별 llms.txt — 작고, 저렴하고, 아마도 할만합니다. 언어마다 링크를 큐레이션하여 각 파일이 올바른 로컬라이즈 버전 URL을 가리키도록 하세요. 주요 엔진이 아직 이것을 가중치로 확인하지는 않았지만, 언어당 15분이면 되고, 다운사이드가 없으며, 언어별로 어떤 URL이 canonical인지 문서화합니다.
4. 엔진을 설정해서 어떻게 하려는 것 — 아무 일도 일어나지 않았습니다. ChatGPT가 로컬라이즈 버전 URL을 인용하게 만드는 설정은 없습니다. 검색 편향은 설정으로는 빠져나갈 수 없습니다. 검색 레이어에 더 깨끗한 시그널을 제공하고 기다리는 것만 할 수 있습니다.

모든 시그널을 깨끗하게 해도 잔여 격차를 각오하세요. 실패의 절반은 당신이 소유하지 않은 검색 레이어 내부에 있습니다. 격차는 줄일 수 있지만, 닫을 수는 없습니다.

언어 비대칭성: 전략적 순풍

잘못된 언어 버전 인용을 유발하는 미성숙함이 기회도 만듭니다. AI 검색 경쟁은 언어 간에 극적으로 불균등하며, LLMO의 기본은 그것이 아직 희소한 언어에서 더 빠르게 복리로 효과를 냅니다.

동일한 콘텐츠를 4개 언어로 발행하는 블로그에서의 22일간 GA4 측정(실측 보고서、영어):

언어	페이지뷰	기사 수	비고
포르투갈어	748	17	기사 수가 적은데 영어의 약 3.8배
영어	195	26	포화 시장, 작은 점유율
일본어	27	25	독자는 블로그가 아닌 플랫폼(Qiita/Zenn)에 삽니다
스페인어	7	10	경쟁은 얕지만 커뮤니티 입구가 없음

언어 비대칭성은 기사 수 비대칭성을 통째로 삼킬 수 있습니다. 세 가지 비대칭성이 쌓여 포르투갈어 결과를 만들었습니다:

1. 커뮤니티 입구 — 무명의 저자가 같은 날 읽히는, 언어별 오픈 투고 플랫폼(브라질에는 TabNews가 있습니다. 영어에는 비교할 수 있는 문턱의 낮음을 가진 곳이 없습니다).
2. 얇은 AI 검색 전쟁터 — 포르투갈어에서는 같은 프롬프트를 두고 경쟁하는 후보가 훨씬 적습니다. 과소 공급된 언어에서는 첫 번째 합리적인 답변이 이깁니다. 영어에서는 첫 번째 합리적인 답변이 묻힙니다.
3. 기본 시책의 선점자 이익 — 그 언어의 사이트 대부분이 아무것도 없는 상황에서 /pt/llms.txt는 미미하지만 차별화가 됩니다. 영어에서는 같은 파일이 그냥 위생 수준입니다.

언어마다 배포 모델도 다릅니다. 일본어 결과가 보여주는 것은, 블로그는 AI 크롤러가 인덱스하는 정식 아카이브로 기능하게 하고, 인간 트래픽 작업은 플랫폼 투고(Zenn/Qiita)에 맡겨야 하는 언어가 있다는 것입니다. 같은 콘텐츠, 반대의 역할.

구현 순서

1. 번역하기 전에 각 대상 언어의 커뮤니티 입구를 파악하세요. 독자 수가 아닌, 입구. 오픈 투고 플랫폼이 없는 언어에서는 위 표의 스페인어 결과를 각오하세요.
2. 첫날부터 /{lang}/llms.txt를 제공하세요. 언어당 15분. 과소 공급 언어에서 가능한 가장 저렴한 차별화입니다.
3. 공개 전에 언어 접두사 필터가 있는 애널리틱스를 설정하세요, 그렇지 않으면 2개월째를 글 쓰는 데가 아닌 측정 후속 처리에 쓰게 됩니다.
4. 상위 20% 기사를 먼저 번역하세요 — 커뮤니티 입구에 통할 가능성이 가장 높은 것들. 아카이브 전체를 번역하기 전에 배포를 검증하세요.
5. 언어별 AI 검색 점유율을 별도의 KPI로 추적하세요. 같은 브랜드 관련 프롬프트를 각 언어로 ChatGPT, Perplexity, Claude에서 월간으로 실행하세요(LLMO 측정에서 지표를 다룹니다). 비대칭성은 크고, 측정할 때까지 보이지 않습니다.
6. 기계 번역은 어조와 로케일을 수작업으로 편집하세요. 번역 품질은 독자에 대한 예의이기 이전에 검색 레이어의 신뢰 시그널입니다.

이 사이트 자체의 구현

llmoframework.com은 영어를 정식 소스로 8개 로케일로 발행합니다. 번역이 없는 페이지는 영어 콘텐츠를 폴백으로 제공하면서 noindex와 sitemap 제외를 적용합니다 — 번역되지 않은 페이지가 어떤 검색 인덱스에서도 자신의 정식 버전과 경쟁해서는 안 됩니다. 모든 로케일이 완전한 hreflang 클러스터와 자기 참조 canonical을 선언합니다.

체크리스트

• 모든 언어 버전이 x-default를 포함한 완전한 hreflang 클러스터를 선언하는가
• 모든 언어 버전이 자기 참조 canonical을 가지는가(영어 원본을 가리키지 않음)
• 각 언어 디렉토리가 로컬라이즈 버전 URL이 담긴 자체 llms.txt를 제공하는가
• 번역되지 않은 폴백 페이지가 noindex되고 sitemap에서 제외되는가
• 번역이 어조와 로케일의 수작업 편집을 거쳤는가(생 기계 출력이 아님)
• 번역 시작 전에 각 대상 언어의 커뮤니티 입구가 파악되어 있는가
• AI 검색 점유율을 언어별로, 해당 언어로, 월간 측정하고 있는가
• 발행 노력이 총 화자 수가 아닌 과소 공급 언어에 가중치를 두고 있는가