2026년 웹사이트를 다국어로 만드는 방법

첫 번째 결정은 어떤 로케일을 게시할지이며, 답이 '전부'인 경우는 드뭅니다. 추가하는 모든 로케일은 하나의 약속입니다. 해당 콘텐츠를 유지 관리하고, SEO를 모니터링하고, 번역을 검토하고, 방문자에게 응대해야 합니다. 감당할 수 없는 로케일 10개를 추가하는 것은 감당할 수 있는 로케일 2개를 추가하는 것보다 나쁩니다.

실제 오디언스에 맞는 로케일부터 시작하세요. Google Analytics의 기존 트래픽을 살펴보세요 — 이미 어떤 국가와 언어가 방문하고 있나요? 고객을 살펴보세요 — 그들은 어떤 언어를 사용하나요? 경쟁사를 살펴보세요 — 그들이 제공하지만 여러분은 제공하지 않는 로케일은 무엇인가요? '내 오디언스가 있는 곳'과 '내가 품질을 낼 수 있는 곳'의 교집합이 바로 로케일 후보 목록입니다.

대부분의 서비스 비즈니스에서 답은 두 개의 로케일입니다. 주요 비즈니스 언어에 더해 하나의 커뮤니티 언어(예: 중국인 커뮤니티를 상대하는 미국 치과의 경우 영어 + 중국어)입니다. 국경을 넘나드는 비즈니스의 경우 2~4개 로케일(예: 미국, 중국, 라틴 아메리카를 상대하는 컨설턴트의 경우 영어 + 중국어 + 스페인어)입니다. 소프트웨어 및 콘텐츠 사이트의 경우 단위 경제성이 유지 비용을 정당화하면 4~10개 로케일이 합리적일 수 있습니다.

다국어 사이트를 위한 세 가지 실행 가능한 URL 구조: (1) 로케일 접두사 하위 디렉터리(example.com/zh-CN/, example.com/es/), (2) 로케일 접두사 하위 도메인(zh-cn.example.com, es.example.com), (3) 로케일별 개별 도메인(example.cn, example.es, example.com). 각각 장단점이 있습니다.

하위 디렉터리는 가장 흔한 선택이며 보통 최선입니다. SEO 자산이 로케일 전반에 복리로 쌓이고(/zh-CN/에 대한 링크가 전체 도메인에 이익이 됨), 유지 관리가 단순하며(하나의 CMS, 하나의 코드베이스) hreflang이 깔끔하게 작동합니다. Google 문서는 가능하면 하위 디렉터리를 명시적으로 권장합니다.

하위 도메인은 SEO 자산을 로케일별로 분할합니다(zh-cn.example.com에 대한 링크는 /zh-CN/만큼 example.com에 이익이 되지 않음). 각 로케일을 별도 인프라를 가진 별도 팀이 운영하거나, 로케일별 법적 요건(데이터 상주, 콘텐츠 라이선싱)이 물리적 분리를 요구할 때 합리적입니다. 대부분의 사이트에는 필요하지 않습니다.

개별 도메인은 브랜드를 공유하는 진정으로 별개의 비즈니스(예: 국가별 메뉴와 가격을 가진 글로벌 패스트푸드 체인)에 합리적입니다. 별도의 SEO, 별도의 DNS, 별도의 호스팅이라는 복잡성은 중소 규모 다국어 사이트에는 거의 가치가 없습니다.

Cogo Site는 기본적으로 하위 디렉터리(/zh-CN/, /es/ 등)를 사용하며, 이는 95%의 다국어 사이트에 올바른 답입니다. 법적 이유로 하위 도메인이나 개별 도메인이 필요하다면 그것은 사용자 지정 구성입니다. 그렇지 않으면 하위 디렉터리를 고수하세요.

번역 품질이 다국어 사이트가 복리로 성장할지 서로 잠식할지를 결정합니다. 비용과 품질 순으로 세 가지 접근법이 있습니다:

접근법 A — 순수 인간 번역. 최고 품질, 가장 느림, 가장 비쌈. 오류 비용이 큰 법률, 의료, 규제 콘텐츠에 최적. 비용: 전문 번역 기준 단어당 $0.10-$0.30. 시간: 전체 사이트 기준 수 주에서 수 개월.

접근법 B — 원어민 검수를 거친 AI 번역. AI가 번역하고 원어민이 홈페이지와 전환 핵심 페이지를 검수합니다. 품질은 인간 번역에 근접하면서 비용은 10-20% 수준입니다. 대부분의 서비스 비즈니스에 최적. Cogo Site는 기본적으로 이 접근법을 사용합니다.

접근법 C — 순수 AI 번역. 가장 빠르고 저렴하며 품질이 가장 낮습니다. 내부 도구나 위험 부담이 낮은 콘텐츠에는 허용되지만 고객 대면 사이트에는 위험합니다. Google은 저품질 기계 번역을 감지할 수 있으며 두 로케일 모두 순위를 떨어뜨릴 수 있습니다.

하이브리드 접근법(B)이 대부분의 사이트에 최적점입니다. Cogo Site의 AI 번역은 로케일에 맞는 표현(단어 대 단어가 아닌)을 만들어내며, 원어민이 항상 홈페이지, 가격, 전환 핵심 페이지를 검수해야 합니다. 결과는 인간 품질의 90%를 10%의 비용으로 얻는 것입니다.

Hreflang은 Google에 어떤 검색자에게 어떤 로케일 버전을 보여줄지 알려줍니다. 이것이 없으면 Google이 잘못된 검색자에게 잘못된 로케일을 제공하여 이탈과 순위 손실을 초래할 수 있습니다. 모든 다국어 페이지에는 세 가지가 필요합니다: 자기 참조 hreflang 태그, 다른 모든 로케일에 대한 대체 태그, 일치하지 않는 검색자를 위한 로케일을 가리키는 x-default 태그.

hreflang 외에도 각 로케일은 자체 제목, 메타 설명, URL 슬러그를 가지며 모두 해당 로케일 언어로 작성됩니다. 흔한 실수는 본문 콘텐츠는 번역하면서 영어 SEO 메타데이터는 그대로 두는 것입니다. Google은 이를 '저노력 번역'으로 읽고 그에 맞게 순위를 매깁니다. 모든 것을 번역하세요.

사이트맵: 각 로케일은 XML 사이트맵에 포함되어야 합니다. 대부분의 최신 CMS(Cogo Site 포함)는 올바른 hreflang 주석이 있는 다국어 사이트맵을 자동으로 생성합니다. 사이트맵을 수동으로 관리한다면 각 URL 항목에 hreflang 주석을 추가하세요.

구조화 데이터: 각 로케일 페이지의 JSON-LD는 해당되는 경우 해당 로케일 언어로 작성되어야 합니다(예: FAQ Question 이름 번역, Article headline 번역, Breadcrumb name 번역). 전체 hreflang 사양은 hreflang 가이드를 참조하세요.

번역은 절반의 작업입니다. 나머지 절반은 진정한 다국어 사이트와 번역된 사이트를 구분하는 로케일별 UX 세부 사항입니다.

날짜와 시간 형식: 미국은 MM/DD/YYYY, 세계 대부분은 DD/MM/YYYY, ISO 표준은 YYYY-MM-DD를 사용합니다. 각 로케일 관례에 맞는 형식을 선택하고, 전 세계적으로 하나의 형식을 사용하지 마세요.

전화번호와 주소: 각 로케일의 우편 관례에 따라 형식을 지정하세요. 미국 주소는 '123 Main St, San Francisco, CA 94101'이고, 중국 주소는 역순(국가, 성, 시, 구, 거리, 번호)입니다. Cogo Site의 로케일 인식 형식 지정이 이를 자동으로 처리합니다.

통화와 단위: en-US는 USD, zh-CN은 CNY, es-MX는 MXN으로 가격을 표시합니다. 자동 변환하지 말고 해당 로케일의 실제 통화를 표시하세요.

소셜 프루프: zh-CN에는 WeChat / Weibo / QQ 후기를, en-US에는 Facebook / Twitter / Yelp 후기를 보여주세요. 중국어 페이지에 영어 소셜 프루프를 보여주지 마세요 — '외국 운영자'라는 신호를 줍니다.

양식 라벨과 검증: 전화번호 검증 규칙은 다릅니다(미국 10자리, 중국 본토 11자리), 우편번호도 다릅니다(미국 5자리, 중국 6자리), 이름 필드도 다릅니다(서양은 이름/성 vs 중국은 성/이름 순). 로케일별로 검증하세요.

폰트 스택: 중국어는 CJK 지원 폰트(Noto Sans CJK, PingFang, Microsoft YaHei)가 필요하고, 영어는 라틴 폰트(Inter, system-ui)가 필요합니다. 혼합 문자 타이포그래피에는 대체 스택이 필요합니다. Cogo Site는 이를 로케일별로 처리하며, 직접 만든 사이트는 신중한 CSS가 필요합니다.

출시 후 세 가지를 모니터링하세요: (1) hreflang 오류를 위한 Google Search Console의 International Targeting 보고서, (2) 로케일별 Search Console 실적 보고서(쿼리, CTR, 순위), (3) 로케일별 Analytics(트래픽, 참여, 전환).

출시 후 흔한 문제: hreflang 오류(즉시 수정), 한 로케일의 페이지가 색인되지 않음(URL 검사 확인), 잘못된 지역에서 잘못된 로케일 순위(hreflang이 올바른지 확인), 한 로케일의 낮은 참여(번역 품질과 UX 세부 사항 검토).

데이터에 기반해 반복 개선하세요. zh-CN이 en-US보다 트래픽이 10배라면 오디언스가 중국어라는 뜻이니 해당 로케일을 우선하세요. es-MX가 트래픽은 높은데 전환이 낮다면 번역이 어색하거나 가격이 잘못되었을 수 있으니 수정하세요. 다국어 사이트는 살아 있는 시스템이며, 출시는 끝이 아니라 시작입니다.

hreflang을 분기마다 재감사하세요. 사이트맵 변경, 콘텐츠 마이그레이션, CMS 업데이트가 hreflang을 조용히 깨뜨릴 수 있습니다. 분기별 Ahrefs 또는 Sitebulb 크롤이 순위 손실을 초래하기 전에 문제를 잡아냅니다.

실수 1 — 한 번에 너무 많은 로케일을 게시하는 것. 각 로케일은 유지 관리 약속입니다. 감당할 수 없는 로케일 10개는 감당할 수 있는 2개보다 나쁩니다. 가치가 가장 높은 로케일부터 시작하고, 모델을 입증한 뒤 나중에 확장하세요.

실수 2 — 확실한 이유 없이 하위 도메인이나 개별 도메인을 선택하는 것. 하위 디렉터리는 SEO 자산을 복리로 쌓지만 하위 도메인과 개별 도메인은 그렇지 않습니다. 법적 또는 운영상 요구가 강제하지 않는 한 하위 디렉터리를 사용하세요.

실수 3 — 본문 콘텐츠는 번역하면서 SEO 메타데이터는 번역하지 않는 것. 제목, 설명, URL, 대체 텍스트, 구조화 데이터 — 모두 번역이 필요합니다. 영어 메타데이터를 남기면 '저노력' 신호를 주고 순위를 떨어뜨립니다.

실수 4 — 원어민 검수 없는 기계 번역. AI 번역은 좋지만 완벽하지는 않습니다. 항상 원어민이 홈페이지와 전환 핵심 페이지를 검수하게 하세요. 비용은 적고 품질 향상은 큽니다.

실수 5 — 로케일 전반에 동일한 UX 세부 사항. 날짜 형식, 전화 형식, 통화, 소셜 프루프, 양식 검증 — 모두 로케일별 처리가 필요합니다. '만능' UX는 '우리가 당신의 로케일을 실제로 알지 못한다'는 신호입니다.

실수 6 — Baidu와 Bing을 잊는 것. Google은 서구에서 지배적인 검색 엔진이지만, Baidu는 중국 본토를 지배하며 Bing은 일부 기업/교육 부문에서 여전히 중요합니다. hreflang과 사이트맵이 세 곳 모두에서 작동하는지 확인하세요.