번역부터 시작하면 늦습니다 — 다국어 사이트에서 먼저 정할 것

어떤 언어를 왜 추가하는지부터 정합니다

언어를 늘리는 결정은 페이지 수가 배로 늘어나는 결정입니다. 한국어와 영어 두 언어만 해도 관리 대상은 두 배가 되고, 이후 수정할 때마다 두 번씩 작업해야 합니다. 그래서 '일단 영어와 중국어와 일본어를 넣자'는 접근보다, 지금 실제로 문의가 오거나 영업이 진행 중인 시장부터 시작하는 편이 현실적입니다.

언어를 정할 때는 그 언어의 방문자가 사이트에서 무엇을 하기를 원하는지도 함께 정해야 합니다. 국내용 사이트가 문의 접수 중심이라면, 해외용은 제품 사양과 인증 정보, 거래 조건을 먼저 확인하려는 경우가 많습니다. 같은 회사 소개라도 강조할 내용이 달라집니다.

전체를 번역하지 않는 선택지도 유효합니다. 해외 방문자에게 필요한 핵심 페이지만 먼저 만들고, 국내 공지사항이나 채용처럼 해당 시장과 무관한 영역은 한국어로 두는 구성도 충분히 작동합니다.

• ●실제 문의나 거래가 있는 시장부터 언어를 정합니다
• ●언어별로 방문자가 해야 할 행동을 따로 정의합니다
• ●전 페이지 번역이 아니라 번역할 페이지 목록을 정합니다
• ●언어별 문의 접수 담당자와 응대 언어를 미리 정합니다

주소 구조와 hreflang — 나중에 바꾸기 가장 어려운 결정

다국어 사이트에서 되돌리기 가장 까다로운 결정이 주소 구조입니다. 언어별로 하위 경로를 쓸지, 서브도메인을 쓸지, 국가별 도메인을 따로 둘지에 따라 운영 비용과 검색엔진 인식이 달라집니다. 대부분의 중소 규모 프로젝트에서는 하나의 도메인 아래 언어 경로를 두는 방식이 관리하기 쉽고, 도메인의 신뢰도가 분산되지 않는다는 점에서도 무난합니다.

그다음이 언어 간 연결입니다. 각 페이지가 다른 언어의 대응 페이지를 명시하도록 hreflang을 넣어야 검색엔진이 같은 문서의 언어 버전임을 이해합니다. 여기서 흔한 실수는 대응 페이지가 실제로 존재하지 않는데도 링크를 넣는 것, 그리고 서로를 가리키도록 양방향으로 선언하지 않는 것입니다. 한쪽만 선언된 관계는 무시될 수 있습니다.

방문자의 언어를 감지해 자동으로 이동시키는 처리도 주의가 필요합니다. 자동 전환은 편해 보이지만, 사용자가 원하는 언어를 볼 수 없게 만들거나 검색엔진이 특정 언어 버전만 보게 만드는 부작용이 있습니다. 언어 선택은 항상 눈에 보이는 위치에 두고, 선택은 사용자가 하도록 두는 편이 안전합니다.

• ●언어별 주소 규칙을 착수 전에 확정합니다
• ●hreflang은 양방향으로, 실제 존재하는 페이지에만 선언합니다
• ●기본 언어와, 대응 페이지가 없을 때 보여 줄 화면을 정합니다
• ●언어 전환 메뉴는 모든 페이지에서 같은 위치에 둡니다

번역이 아니라 현지화입니다

문장을 옮기는 것만으로 해외용 사이트가 완성되지는 않습니다. 회사 소개에 들어가는 설득의 순서, 신뢰를 만드는 근거, 문의 폼에서 요구하는 정보가 시장마다 다르기 때문입니다. 한국에서는 당연한 사업자 정보 표기가 다른 시장에서는 의미가 없고, 반대로 그쪽에서 기대하는 정보가 한국어 원본에는 아예 없는 경우도 많습니다.

형식 요소도 함께 봐야 합니다. 날짜와 숫자 표기, 단위, 주소 입력 순서, 전화번호 국가 코드는 언어를 바꾸면 같이 바뀌어야 하는 항목입니다. 문의 폼에서 한국식 주소 구조를 그대로 요구하면 해외 방문자는 작성 도중에 이탈합니다. 결제가 필요한 경우 통화와 결제 수단도 시장별로 검토해야 하며, 이는 프로젝트 조건에 따라 별도로 판단합니다.

레이아웃이 실제로 깨지는 지점도 언어에 있습니다. 같은 문장이라도 언어에 따라 길이가 크게 달라져 버튼과 메뉴가 넘칩니다. 아랍어나 히브리어처럼 오른쪽에서 왼쪽으로 읽는 언어를 넣는다면 화면 전체의 방향이 뒤집히므로, 여백과 아이콘 방향까지 처음부터 대칭을 고려해 설계해야 합니다. 저희는 RTL 언어를 포함한 다국어 사이트를 실제로 구축해 왔고, 이 부분은 나중에 덧붙이는 것보다 처음부터 반영하는 편이 훨씬 저렴합니다.

• ●날짜·숫자·단위·통화 표기를 언어별로 정의합니다
• ●폼의 입력 항목과 주소 형식을 시장에 맞게 조정합니다
• ●버튼과 메뉴는 문장 길이가 늘어나도 깨지지 않도록 설계합니다
• ●RTL 언어가 포함되면 레이아웃 방향과 아이콘을 함께 검토합니다
• ●언어별 폰트와 줄바꿈 처리를 확인합니다

원본이 바뀌면 무엇이 따라가야 합니까

다국어 사이트의 진짜 비용은 오픈이 아니라 운영에서 발생합니다. 한국어 페이지를 수정했는데 다른 언어가 그대로 남아 있으면, 시간이 지날수록 언어마다 내용이 어긋납니다. 제품 사양이나 가격 정책처럼 사실이 담긴 페이지에서 이런 차이가 생기면 신뢰 문제로 이어집니다.

그래서 착수 단계에서 운영 규칙을 정해 두어야 합니다. 어떤 페이지가 언어 간에 반드시 일치해야 하는지, 어떤 페이지는 시장별로 달라도 되는지 구분하고, 원본이 바뀌었을 때 다른 언어가 검토 대상으로 표시되도록 만드는 방식이 실무에서 안정적입니다. 번역을 누가 검수하는지도 미리 정합니다.

또 하나 자주 빠지는 부분이 사이트 밖의 텍스트입니다. 자동 발송 메일, 폼 제출 후 안내 문구, 오류 메시지가 한국어로 남아 있는 경우가 많습니다. 방문자는 가장 결정적인 순간에 이해할 수 없는 문장을 보게 됩니다. 다국어 범위를 정할 때 이 항목들을 함께 목록에 넣어 주십시오.

• ●언어 간 반드시 일치해야 하는 페이지를 지정합니다
• ●원본 수정 시 다른 언어를 검토 대상으로 표시하는 절차를 만듭니다
• ●자동 발송 메일과 안내·오류 메시지도 번역 범위에 포함합니다
• ●언어별 검수 담당자를 정합니다

자주 묻는 질문