다국어 워드프레스 웹사이트 구축: 기업이 반드시 신경 써야 할 점

소개

웹사이트를 확장하여 여러 언어의 사용자에게 서비스를 제공하는 것은 원칙적으로는 간단해 보입니다. 하지만 실제로는 많은 기업이 예상치 못한 기술적, 콘텐츠적, 전략적 결정들을 내려야 합니다. 이러한 실수들은 대개 예측 가능한 패턴을 따르며, 대부분은 사이트가 구축되어 출시된 후에 수정하는 것보다 기획 단계에서 미리 방지하는 것이 더 쉽습니다.

워드프레스 개발 회사인 Cude Design의 설립자 웨슬리 쿠드(Wesley Cude)는 영국 및 전 세계 고객을 위해 다국어 워드프레스 사이트를 구축해 왔습니다. “다국어 워드프레스의 기술적 측면은 시중의 플러그인을 통해 충분히 지원됩니다.”라고 그는 말합니다. “프로젝트가 실패하는 원인은 대개 코드 한 줄도 작성하기 전에 내려지는 결정에 있습니다. 어떤 언어를 사용할지, URL 구조는 어떻게 할지, 번역 권한은 누가 가질지, 사이트가 통화 및 지역적 차이를 어떻게 처리할지 등이죠. 이러한 결정들을 초반에 올바르게 내리면 나중에 상당한 양의 재작업 시간을 절약할 수 있습니다.”

이 글에서는 다국어 워드프레스 웹사이트 구축에 필요한 핵심 결정 사항, 활용 가능한 기술적 접근 방식, 그리고 다국어 사이트가 실제로 의도된 대상에게 효과적으로 서비스를 제공할 수 있는지 여부를 결정하는 지속적인 고려 사항들을 다룹니다.

적절한 URL 구조 선택

다국어 워드프레스 프로젝트에서 가장 먼저 내려야 할 중요한 결정은 각 언어 버전의 URL을 어떻게 구성할 것인가 하는 것입니다. 세 가지 주요 접근 방식이 있으며, 각각은 SEO, 호스팅, 지속적인 관리에 영향을 미칩니다.

하위 디렉터리는 폴더 구조를 사용하여 언어 버전을 분리하며, 기본 언어는 루트에, 다른 언어들은 하위 디렉터리에 배치됩니다. 영국 영어 버전은 domain.com에 위치하고, 프랑스어 버전은 domain.com/fr/에 위치할 수 있습니다. 이 방식은 모든 내용을 단일 도메인에 유지하므로, 해당 도메인의 모든 권위가 모든 언어 버전에 적용됩니다. 이는 각 시장을 완전히 별개의 개체로 취급해야 할 강력한 이유가 없는 상태에서 추가 언어로 사업을 확장하는 기업들에게 가장 일반적인 방식입니다.

서브도메인 방식은 각 언어 버전을 별도의 서브도메인에 배치하는 방식으로, 예를 들어 프랑스어 버전은 fr.domain.com에 위치합니다. 검색 엔진은 서브도메인을 고유한 권위를 가진 별개의 개체로 취급하므로, 메인 도메인의 순위가 높더라도 새로운 서브도메인은 누적된 권위 없이 시작하게 됩니다. 이 방식은 관리 측면에서 기술적으로 더 복잡하며, 일반적으로 각 시장을 위한 콘텐츠 전략이 현저히 다른 경우처럼 각 언어를 진정으로 별개의 개체로 취급해야 할 타당한 이유가 있을 때만 적합합니다.

국가 코드 최상위 도메인(ccTLD)은 국가별로 별도의 도메인을 등록하는 방식입니다(예: 프랑스의 domain.fr, 독일의 domain.de). 이는 검색 엔진에 가장 강력한 지역적 신호를 전달하며, 각 시장에서 상당한 입지를 확보한 기업에 효과적일 수 있습니다. 또한 각 도메인마다 사실상 별도의 SEO 전략과 링크 구축 프로그램이 필요하기 때문에 비용과 복잡성이 가장 높습니다.

다국어 워드프레스 사이트를 처음 구축하는 대부분의 기업에게 하위 디렉터리는 적절한 출발점입니다. 구현이 가장 간단하고, 모든 권위를 단일 도메인에 유지할 수 있으며, 추가 언어가 도입될 때 확장하기도 용이합니다.

플러그인 선택 및 구성

워드프레스에는 WPML과 Polylang이라는 두 가지 주요 다국어 플러그인이 있습니다. 두 플러그인 모두 복잡한 다국어 사이트를 처리할 수 있지만, 구현 방식이 다르며 사이트 성능과 지속적인 관리에 미치는 영향도 다릅니다.

WPML은 더 풍부한 기능을 갖춘 옵션입니다. 번역 관리, 테마 및 플러그인 텍스트의 문자열 번역, 우커머스(WooCommerce) 호환성, 그리고 우측에서 좌측으로 읽는 언어를 포함한 복잡한 다국어 설정을 처리합니다. 전문 번역 서비스를 위한 번역 서비스와 연동되며, 어떤 콘텐츠를 어떻게 번역할지에 대한 세부적인 제어 기능을 제공합니다. 단점으로는 데이터베이스 쿼리 측면에서 비교적 무거운 플러그인 중 하나이며, 대규모 사이트에서 신중하게 구성하지 않을 경우 사이트 성능에 영향을 줄 수 있다는 점입니다.

Polylang은 오버헤드를 줄이면서 핵심 다국어 기능을 처리하는 더 가벼운 대안입니다. WPML의 전체 기능 세트가 필요하지 않은 사이트의 경우, 성능에 미치는 영향을 최소화하면서 번역 관리 역할을 수행합니다. 유용한 기능을 갖춘 무료 버전이 있어, 비교적 간단한 다국어 프로젝트를 시작하기에 합리적인 선택지입니다.

두 플러그인 중 어느 것을 선택할지는 사이트의 복잡성, WooCommerce 통합 요구 사항, 그리고 클라이언트가 사용하고자 하는 번역 워크플로우에 따라 달라집니다. 두 가지 언어로 된 정적 페이지가 소수인 사이트와, 각기 다른 가격, 부가가치세(VAT)율, 결제 게이트웨이 요구 사항을 가진 5개 유럽 시장에 걸쳐 제품을 판매하는 WooCommerce 스토어의 요구 사항은 서로 다릅니다.

Hreflang 구현

Hreflang은 검색 엔진에 어떤 사용자에게 어떤 언어 및 지역 버전의 페이지를 제공해야 하는지 알려주는 HTML 속성입니다. 올바른 hreflang 구현은 다국어 SEO에 필수적이며, 다국어 사이트에서 가장 흔히 오류가 발생하는 영역 중 하나입니다.

다국어 사이트의 각 페이지에는 해당 페이지 자체를 포함하여 다른 모든 언어 버전을 가리키는 hreflang 태그가 포함되어야 합니다. 영어, 프랑스어, 독일어로 존재하는 페이지의 경우, 해당 페이지의 모든 버전에 세 가지 언어 버전에 대한 hreflang 태그가 필요합니다. hreflang 태그가 누락되거나 형식이 잘못된 경우, 검색 엔진이 사용자에게 잘못된 언어 버전을 제공하거나 서로 다른 언어 버전을 중복 콘텐츠로 간주할 수 있습니다.

WPML과 Polylang 모두 올바르게 구성되면 hreflang 생성을 자동으로 처리하지만, 자동 구현이 제대로 이루어졌다고 가정하기보다는 반드시 확인해야 합니다. 흔한 오류로는 x-default 태그 누락, 표준 URL 대신 리디렉션된 URL을 가리키는 hreflang 태그, 사용 중인 URL 구조와 일치하지 않는 hreflang 구현 등이 있습니다.

Rank Math와 Yoast SEO는 모두 다국어 플러그인과 함께 사용할 때 추가적인 hreflang 관리 기능을 제공합니다. 중요한 점은 SEO 플러그인과 다국어 플러그인이 서로 충돌하는 마크업을 생성하지 않고 올바르게 연동되도록 구성되어야 한다는 것입니다.

콘텐츠 전략과 번역 품질

다국어 워드프레스 사이트의 기술적 구현은 프로젝트에서 비교적 간단한 부분입니다. 많은 다국어 사이트가 의도한 목적을 달성하지 못하는 부분은 바로 콘텐츠 전략에 있습니다.

기계 번역 기술은 크게 발전하여 일부 콘텐츠 유형의 경우 수용 가능한 결과를 내놓기도 합니다. 그러나 상업적 콘텐츠, 특히 비즈니스에 가장 중요한 서비스 설명, 제품 설명문, 전환율 향상에 초점을 맞춘 페이지의 경우, 사람의 검토와 편집 없이는 기계 번역만으로는 거의 충분하지 않습니다. 어색하게 읽히거나 문화적으로 부적절한 표현이 포함된 텍스트는 다국어 사이트가 구축하고자 하는 신뢰도를 훼손합니다.

지속적인 번역 워크플로는 기획 단계에서 종종 과소평가되는 고려 사항입니다. 다국어 사이트에 새로운 블로그 게시물이나 제품 페이지를 추가한다는 것은 해당 콘텐츠의 번역본을 제작해야 함을 의미하며, 이는 시간과 비용이 소요됩니다. 포괄적인 번역 콘텐츠로 출시된 후 번역 유지 관리를 소홀히 하는 사이트는 결국 주 언어 버전에 비해 언어별 버전이 구식이 되어 버립니다. 이는 번역이 아예 없는 것보다 더 나쁜 사용자 경험을 초래합니다.

다국어 사이트를 위한 현실적인 콘텐츠 전략에는 번역 프로세스에 대한 명확한 책임 소재, 신규 콘텐츠를 위한 정의된 워크플로우, 그리고 어떤 콘텐츠가 진정으로 번역되어야 하는지에 대한 신중한 판단이 포함되어야 합니다. 사이트의 모든 페이지에 번역본이 필요한 것은 아닙니다. 해외 사용자에게 가장 중요한 페이지에 우선순위를 두고 해당 번역을 적절히 유지하는 것이, 포괄적인 번역을 시도했다가 최신 상태를 유지하지 못하는 것보다 더 효과적입니다.

WooCommerce와 다국어 전자상거래

다국어 WooCommerce 사이트는 일반적인 다국어 WordPress 고려 사항 외에도 추가적인 복잡성을 수반합니다. 가격, 배송 규칙, 결제 게이트웨이, 세금 설정 등은 시장마다 다를 수 있습니다. 통화 표시는 각 지역의 사용자 기대에 부합해야 합니다. 제품 재고 상황도 시장마다 다를 수 있습니다. 주문 확인 및 배송 알림을 포함한 고객 커뮤니케이션은 고객의 언어로 전송되어야 합니다.

WPML은 상품 번역, 통화 전환, 결제 과정 현지화를 처리하는 전용 WooCommerce 다국어 지원 기능을 제공합니다. 설정 과정은 일반적인 다국어 사이트보다 더 복잡하므로, 표준 WooCommerce 구축의 연장선이 아닌 별도의 프로젝트 범위로 다루어야 합니다.

결제 게이트웨이의 이용 가능 여부는 국가에 따라 크게 다릅니다. Stripe와 PayPal은 대부분의 시장에서 사용할 수 있지만, 특정 지역에서는 현지 결제 수단이 중요합니다. 네덜란드에서는 iDEAL이, 독일에서는 Sofort가, 프랑스에서는 Carte Bancaire가 주류를 이룹니다. 유럽 시장을 대상으로 하면서 국제 카드 결제 옵션만 제공하는 WooCommerce 스토어는, 해당 시장의 선호 결제 수단을 지원하는 현지 경쟁사들에 비해 실적이 저조할 것입니다.

성능 고려 사항

다국어 사이트는 본질적으로 단일 언어 사이트보다 규모가 큽니다. 페이지 수 증가, 데이터베이스 레코드 증가, 플러그인 오버헤드 증가는 모두 서버 부하 증가와 잠재적인 성능 문제로 이어집니다. 이러한 문제들은 출시 후 사후 대응적으로 해결하기보다는 사전에 계획해야 합니다.

캐싱 구성 시 언어 감지 기능을 고려하여 사용자에게 잘못된 언어로 된 캐시된 페이지가 제공되지 않도록 해야 합니다. 캐시가 제공되기 전에 작동하는 서버 측 언어 감지는 일반적으로 클라이언트 측 감지보다 더 신뢰할 수 있지만, 구체적인 접근 방식은 호스팅 환경과 사용 중인 캐싱 플러그인에 따라 달라집니다.

여러 국가에 서비스를 제공하는 사이트의 경우, 각 대상 시장과 지리적으로 가까운 에지 위치에 콘텐츠를 캐싱하는 콘텐츠 전송 네트워크(CDN)를 활용하면 해외 사용자의 지연 시간을 줄일 수 있습니다. 이는 특히 주요 호스팅 위치와 지리적으로 멀리 떨어진 시장을 대상으로 하는 사이트에 해당됩니다.

다국어 사이트에서는 WPML과 같은 플러그인이 사용하는 번역 테이블이 콘텐츠 양이 늘어남에 따라 데이터베이스 오버헤드를 크게 증가시키기 때문에 데이터베이스 최적화가 더욱 중요해집니다. 대규모 다국어 사이트에서는 비슷한 규모의 단일 언어 사이트보다 정기적인 데이터베이스 유지 관리와 적절한 인덱싱이 훨씬 더 중요합니다.

출시 전 테스트

다국어 사이트는 검증해야 할 언어, URL, 콘텐츠의 조합이 더 많기 때문에 단일 언어 사이트보다 더 철저한 테스트가 필요합니다. 체계적인 테스트 접근 방식은 모든 페이지의 언어 전환 기능, 출시 후 Google Search Console을 통해 검증된 올바른 hreflang 구현, 모든 상업용 페이지의 번역 완성도, WooCommerce 구현에서 각 시장에 대한 올바른 통화 표시 및 결제 흐름, 그리고 각 언어 버전의 모바일 성능을 포괄해야 합니다.

URL 구조나 hreflang 구현의 변경이 여러 시장의 검색 순위에 동시에 영향을 미칠 수 있는 운영 중인 다국어 사이트에서 문제를 수정하는 데 드는 비용과 복잡성을 고려할 때, 출시 전 철저한 테스트에 투자하는 것은 충분히 타당합니다.