실전 UI/UX - 다국어 서비스기획시고려해야할것들
서점군은 가진 능력에 비해 운이 좋게도 다양한 다국어 웹서비스 구축&운영 경험을 가지고 있습니다. 처음 다국어 서비스 구축에 참여하게 되었을 때는 단순하게 생각했죠.
그래 나도 이 바닥 짬밥 하루 이틀 먹은 게 아닌 데 다국어라고 뭐 다를 게 있겠어. 늘 하던데로 하면 되겠지.
하지만 그건 서점군의 착각이었습니다. 곧 다국어 서비스와 로컬 서비스의 어마어마한 차이를 경험할 수 있었고 서점군은 삽질의 삽질을 거듭한 끝에 다국어 서비스의 특성과 그에 맞는 기획 방법론을 확립할 수 있었습니다. (욕도 많이 먹었...) 서점군의 이 경험은 훗날 소중한 자산이 되어 회사에게 진행하는 다국어 서비스 구축에 가장 앞에 이름을 올릴 수 있게 되었습니다.
글로벌 시대를 살아가고 있는 현재. 많은 서비스들이 탈 로컬을 외치며 앞다투어 글로벌로 진출하고 있습니다. 다국어 서비스에 대한 수요는 높아지고 있지만 다국어 서비스를 구축해본 경험이 있는 기획자는 많지 않습니다. 그리고 글로벌 다국어 구축 시 기획자가 고려해야 할 사항은 로컬 서비스의 그것과는 사뭇 다르죠.
오늘은 다국어 서비스 기획 시 기획자가 고려해야 할 다양한 UI/UX의 기술에 대해 알아보려고 합니다. 어디에서도 가르쳐주지 않는, 욕먹어가면서 배운 서점직원이 드리는 다국어 서비스 기획 시 기획자가 고려해야 할 꿀팁 모음.
기능의 컴포넌트화
전 세계 판매망을 가진 모 제조사 홈페이지를 만들 때 일입니다.
홈페이지 메인 페이지 하단에는 구글 지도를 연계하여 해당 국가의 A/S 센터 위치를 안내해주는 영역이 있었습니다. 제품 특성상 A/S 수요가 많으니 메인페이지에서 A/S 센터 위치를 안내해주면 어떨까? 라는 것이 그 영역을 설계한 김대리의 생각이었죠.
스스로 기가 막힌 생각이라고 자화자찬하며 기획서를 들고 간 김대리. 현업에게 뜻밖의 말을 듣게 됩니다.
대리님. 오스트리아에는 A/S 센터가 없는데요?
사실 오스트리아와 독일은 한나라라고 봐도 무방할 정도로 역사와 민족, 언어를 공유하고 있습니다. 히틀러의 고향이 오스트리아이고 오스트리아의 공용어가 독일어이며 1차 세계대전 이후 오스트리아 공화국에서 독일과 통일을 추진할 정도로 역사, 문화적으로 두나라의 관계가 깊죠. 고객사에서는 오스트리아의 시장규모는 크지 않았지만 다른 업체에 시장점유율을 뺏기면 안된다는 생각에 적자를 보면서까지 오스트리아에 진출했지만 법인을 따로 설립할 정도는 아니여서 거점은 독일에 두고 A/S 역시 독일 법인에서 처리하고 있었습니다. 불행하게도 이과이며 세계사를 공부한적이 없었던 김대리는 이러한 배경을 몰랐고 (알았다고 해도 예상 못했겠지만...) 곧 큰 난관에 봉착합니다. 김대리가 만든 메인페이지는 페이지 전체가 하나의 모듈로 구성된 이른바 통프레임이었거든요.
많은 기획자들이 껍데기만 만들어놓고 언어만 바꾸면 되는 거 아니야? 라는 식으로 다국어 확산을 쉽게 생각합니다. 하지만 업의 특성, 지역적 특성, 시장 환경 등 여러가지 요인으로 인해 법인마다 서비스 범위나 특성이 달라지기도 합니다. 그렇기 때문에 다국어 서비스 기획시에는 변화무쌍한 현지 법인의 특성을 고려해 기능을 넣고 빼기 쉽도록 단위별로 컴포넌트화해서 작업하는 것이 중요합니다.
위 이미지와 같이 기능을 컴포넌트 별로 쪼개서 설계하면 위와 같은 사례가 발생해도 쉽게 대응이 가능합니다. 두 가지 구축방식의 예외사항 처리 차이를 비교하면 아래와 같습니다.
하나의 프레임 : 예외사항 발생 시 해당 영역을 하드코딩으로 예외처리
컴포넌트 단위 : 예외사항 발생 시 문제가 발생한 부분만 교체 또는 제외
구축해야 하는 법인이 적으면 위와 같은 케이스가 크게 문제가 되지 않을 수도 있습니다. 하지만 30개, 50개, 100개 법인을 하나의 모듈로 관리하려면 법인 수만큼의 예외사항을 처리해야 하죠. 법인별 예외사항을 한 모듈에 모두 적용하면 소스코드가 지저분해지는 이른바 스파게티 코드가 될겁니다. 그래서 애초 설계단계부터 각 단위 기능을 컴포넌트 단위로 쪼개 넣고 법인별로 넣다 뺐다 할 수 있도록 기획하는것이 중요합니다.
기준은 꼭 한국이 아닐수도?
일반적인 서비스나 사이트는 한국에서 서비스를 론칭하고 큰 성공을 거두면 글로벌 진출을 모색하게 됩니다. 이때 해외 론칭 사이트나 서비스의 기준점은 이미 서비스가 어느정도 안정화되어있는 한국을 기준으로 합니다. 한국 서비스를 기준으로 기능을 넣거나 빼거나 하는 식이죠.
그런데 리뉴얼은 조금 다를 수 있습니다
한국에서 서비스를 론칭하고 글로벌로 확장하는것이 아니라 이미 글로벌에 진출해서 서비스를 운영 중인 회사의 사이트나 앱을 리뉴얼할 경우 기준점은 한국이 아니라 기능과 콘텐츠가 가장 많은 법인을 기준으로 합니다. 기능을 넣는 것보다는 빼는 게 훨씬 쉽기 때문이죠. 가장 기능과 콘텐츠가 많은 법인을 우선 만들고 그걸 기준점 삼아 다국어로 확산하는 방식입니다.
언어는 최우선 고려사항
글로벌 서비스를 만들 때 가장 주의해야 할 것이 텍스트 길이입니다.
텍스트 길이에 영향을 주는 케이스가 너무 많기 때문이죠.
이번 장에서는 언어 차이에 따른 UI/UX적 고려사항에 대해 이야기해볼까 합니다.
1) 문자의 압축률
텍스트 길이의 영향도를 알려면 우선 문자의 압축률을 먼저 이해해야 합니다. 문자의 압축률만 제대로 이해하고 있어도 언어 차이에 따라 발생하는 많은 문제를 해결할 수 있기 때문이죠.
문자의 압축률은 내가 어떤 표현을 할 때 몇 글자의 문자가 필요한가 라는 개념입니다.
한가지 예를 들어볼까요
반갑습니다의 다국어 표현 (파파고 기준)
한글 : 반갑습니다 (5글자)
영어 : Nice to meet you (13글자)
일본어 : 初めまして (5글자)
중국어 : 见到您很高兴 (6글자)
아랍어 : سعيد بلقائك (11글자)
한국어는 문자중에서도 압축률이 높은 언어 중 하나입니다. 알파벳이 한글자당 하나의 자음이나 모음을 표현하는 반면 한글은 2개의 자음과 하나의 모음을 조합해 한글자를 만들기 때문에 영어보다 더 짧은 문자로 동일한 표현을 할 수 있는거죠. 한자를 사용하는 중국어는 한글보다 압축률이 더 높습니다. 단어나 형태를 글자 하나로 표현할 수 있기 때문이죠.
정리하면 동일한 표현을 할 때
한자 > 한글 > 영어순으로 문자의 압축률이 높아지는 특성을 보입니다. 그래서 다국어 서비스에서 문자 길이를 예상할때는 가장 짧은 문자는 한자로, 가장 긴 문자는 영어로 가정하고 레이아웃을 설계하면 됩니다.
2) CTA 설계 시
CTA(Call To Action)는 다국어 영향을 가장 많이 받는 요소 중 하나입니다. 글자수에 따라 버튼의 가로폭이 달라질 수 있기 때문이죠. 이를 해결하는 방법은 크게 두가지입니다.
1) 버튼의 가로폭을 글자수에 맞춰 가변적으로 조절
2) 가장 긴 문자 기준으로 가로폭을 설계
LG전자는 1번 방법을 사용했습니다. 좌우 여백은 동일하게 주고 문자 길이에 따라 CTA 가로 길이가 가변적으로 길어질 수 있도록 설계한거죠. 1)번 문자의 압축률 항목에서 설명했던것처럼 동일한 표현도 문자길이는 중국어가 가장 짧고 영어가 가장 긴 특성을 보입니다. 레이아웃 설계 시에는 MIN은 중국어 MAX는 영어를 기준으로 설계하면 다국어의 오차를 크게 줄일 수 있습니다.
3) 말줄임
영역은 정해져 있고 글자 길이는 영역보다 길거나 예상할 수 없을 때 말줄임을 사용합니다. 다국어의 말줄임 이슈는 주로 카드형 List 페이지에서 가장 많이 발생합니다.
브런치 페이지로 예를 들어볼까요.
동일한 제목을 한국어, 영어, 중국어로 번역했을때 예시입니다. 1번 압축률에서 설명했던것처럼 영어가 가장 길고 한국어와 중국어는 압축률이 좋아 영어처럼 말줄임을 하지 않고도 모든 의미를 전달할 수 있죠.
다음 본문의 예를 볼까요.
동일한 영역에 똑같은 내용을 표현했을때 영어는 본문 내용과 썸네일 영역에 여백이 남는 반면 (초록색 컬러영역) 중국어는 본문 영역이 썸네일 영역을 침범했다는걸 알 수 있습니다. 왜 이런 현상이 생기는 걸까. 답은 문자의 특성에 있습니다.
보통 글자의 말줄임을 할 때 프로그램에서는 글자의 Byte 수를 계산하여 글자를 자릅니다. 글자가 80Byte 이상 초과될 경우 말줄임을 한다. 같은 식으로 말이죠. 그런데 글자를 Byte로 자르면 다국어 서비스에서 문제가 발생합니다. 문자마다 한글자가 차지하는 Byte에 차이가 발생하기 때문이죠.
1글자당 Byte 수
영어 : 1Byte
공백/특수문자 : 1Byte
한글 : 2Byte
중국어 : 3Byte
공백 없이 80Byte를 글자로 채운다고 하면
영어 : 80자
한글 : 40자
중국어 : 26자
를 표현할 수 있게 됩니다
언어마다 글자 하나를 표기하기 위해 필요한 Byte가 다르기 때문에 Byte 기준으로 말줄임을 하면 한글은 영어의 절반, 중국어는 1/3밖에 문자가 표시되지 않습니다. 그래서 요즘에는 말줄임을 할 때 글자수의 기준을 Byte가 아닌 Character(문자)로 세서 말줄임처리를 합니다. 어떤 언어든 글자 하나에 1Character로 카운트해서 정해진 Character가 넘어가면 말줄임 처리를 하는거죠.
그런데 이 캐릭터 카운트법은 치명적인 단점이 하나 있습니다. 문자마다 1글자가 차지하는 영역이 다를 수 있다는거죠.
예를 하나 들어볼까요.
화면에 10글자를 표시할 때 영어가 차지하는 영역이 가장 적고 중국어가 가장 많습니다. 이 예를 보면 위 이미지에서 영어는 왜 영역이 남고 중국어는 영역을 침범하는지 이유를 단박에 이해할 수 있습니다.
말줄임을 할 때는 글자가 차지하는 영역을 고려해 언어마다 말줄임 제한 글자수를 다르게 설정해줘야 합니다. 문제는 기획단계에서 중국어는 몇글자로 말줄임을 했을 때 영역에 딱 맞게 말줄임이 가능할까? 를 예측할 수 없다는데 있죠. 이를 해결하기 위해서는 프로토타입으로 해당 영역을 퍼블리싱 해놓고 언어를 하나하나 넣어보면서 최적화된 글자수를 알아내던가 디자인단계에서 디자이너가 글자를 일일히 넣어가며 제한 글자수를 파악하는 방법밖에 없습니다.
4) 문자 코드
다국어 서비스에서 언어가 표시되는 영역은 3가지로 구분됩니다.
1) 퍼블로 입력하는 일반 문자열 (이용안내, 개인보호정책 등)
2) 관리자 페이지에서 입력하는 문자열 (공지사항, 팝업 등)
3) 프로그램에서 표시하는 문자열 (게시판의 List 버튼 텍스트)
문자열 유형에 따라 문자열이 저장되는 위치도 다릅니다.
1)번 유형 : HTML
2)번 유형 : Data Base
3)번 유형 : 프로그램 소스
3번 유형 문자열의 예 by LG전자1번과 2번은 관리와 수정이 용이한 반면 3번은 문제가 조금 있습니다. 3번은 프로그램 소스사이에 문자열이 위치해 있는데 이 문자열을 국가별 페이지에 따라 다르게 표시해야하니까요.
조금 무식한 방법을 쓰자면 프로그램 소스안에 예외처리로 분기를 해버리면 됩니다.
예를 들면 이런 식으로 말이죠
List 버튼 텍스트 화면 표시 문구 - 언어별 표시
한국어일때 : 목록
영어일때 : List
중국어일때 : 罗列
일본어일때 : 目録
이 방법에는 치명적인 단점이 있습니다. 새로운 국가나 언어가 추가됐을 경우 문구가 표시되는 페이지의 소스를 일일이 하나하나 까서 해당 언어 문구를 추가해줘야 된다는거죠. 그래서 현업에서는 관리와 추가/수정이 용이하도록 프로그램 공통 문구는 코드를 따고 해당 문자열을 DB에 저장해서 불러오는 식으로 관리합니다.
아래 예 같은 형식으로 말이죠.
기획에서 화면설계를 할때는 텍스트의 유형을 파악해 코드로 관리해야 되는 문자열은 미리 코드를 따두고 관리하면 센스있는 기획자가 될 수 있답니다.
월드타임
다국어 홈페이지의 관리자 공지사항 게시판을 기획할 때 일입니다.
귀찮은 일은 늘 부하직원에 짬처리했던 서점군은 늘 그렇듯 공지사항 설계를 아래 직원에게 맡겨버립니다. (이전글에서 당근마켓을 똑같이 배꼈던 그 녀석) 그리고 다음날 아랫직원은 몹시 평이하지만 있을 건 다 있는 공지사항 관리자 페이지 설계안을 가지고 왔습니다.
자 여기서 문제. 그 기획안을 본 서점직원의 반응은 다음 중 어떤것이었을까요.
① 잘했어 라이코스 (칭찬형 리더)
② 뭐 그럭저럭 봐줄만하네 (츤데레 형 리더)
③ 월드타임은? (인간미 없는 리더)
다국어 구축이나 운영 경험이 없는 기획자가 다국어 서비스를 설계할때 가장 놓치기 쉬운 부분이 바로 월드타임입니다. 그다지 거창한 용어는 아니고 쉽게 말하면 시차입니다.
시차 문제는 주로 공지사항 관리, 팝업관리, 메인 배너를 하나의 관리자에서 등록/관리하는 경우 발생합니다. 쉬운 예를 하나 들어볼까요.
예)
전 세계 10개국에 진출해있는 (주)서점전자는 5월 1일 00시부터 각 국가 홈페이지에서 50% 세일 이벤트를 진행하려고 한다. 이벤트로 갈 수 있는 배너와 링크는 5월 1일 00시에 노출되도록 예약 등록해놓았다. 서점전자는 10개국 홈페이지를 하나의 관리자 페이지로 관리하고 있다.
(주)서점전자의 매인 배너 관리 기능은 월드 타임이 적용되어 있지 않다. 이때 각 법인 홈페이지별 배너 노출 시간은 다음과 같다. (현지 시각 기준)
- 한국 : 5월 1일 00시 (GMT +9)
- 미국 : 4월 30일 11시 (GMT -5)
- 중국 : 4월 30일 23시 (GMT +8)
- 프랑스 : 4월 30일 17시 (GMT +1)
- 런던 : 4월 30일 16시 (GMT +0)
위의 예에서 볼 수 있듯 원래 의도는 각 법인(국가)별로 현지 시간 5월 1일 00시에 배너가 노출되는것이나 시차로 인해 한국 시간 기준으로 시차를 적용해 국가마다 다른 시간에 배너가 노출된것을 알 수 있습니다. 시차 문제를 해결하려면 다국어 서비스 관리자 페이지에서 예약노출시간 기능을 기획할 경우 시차 보정 기능을 넣어줘야 합니다. 시차 보정 기능을 넣는 방법은 크게 3가지입니다.
① 예약노출시간은 한국을 기준으로 하고 각 법인마다 시차를 프로그램이 자동 보정 (하드코딩)
② 국가별로 배너 오픈 시간을 별도 설정할 수 있도록 등록 영역 개발 (법인 수만큼 시간을 입력할 수 있는 영역 필요)
③ 에라 모르겠다. 걍 한국시간 기준으로 다 보여줌
예약노출시간 보정에는 한가지를 더 고려해야 합니다.
바로 서.버.점.검이죠.
우리 서비스가 주 또는 월에 한번 특정 시간에 서버점검을 해서 서비스가 중지된다면 그리고 서버가 각 국가별로 있는게 아니고 특정 국가에만 있다면 서버점검 안내 배너나 팝업에는 시차를 보정하면 안됩니다. 이럴 경우에는 등록 옵션에 시차 보정 ON/OFF를 설정할 수 있는 스위치나 라디오 버튼 선택 옵션을 두는것이 좋습니다.
R to L
우리의 지원 언어중에 아랍어가 있다. 그런데 우리 기획팀 구성원중에는 아랍어로 된 서비스를 만들어본적이 있는 사람이 없다. 그러면 우리는 죽었구나 라고 생각하면 됩니다. 반대로 아랍어를 다뤄본 사람이 한명이라도 있다면 그분은 우리의 귀인이자 프로젝트를 하드캐리할 소중한 인재라고 생각하고 귀하게 모시면 됩니다.
상호교류가 활발한 일본, 중국, 미국은 해당 언어를 이용해 사이트나 서비스를 만들어본 인력도 레퍼런스도 많지만 아랍권역은 문화적, 지리적으로 떨어져 있기도 하고 연계된 비즈니스도 석유와 건설 등 B to B에 집중되어 있어 일반적인 기획자는 아랍어를 접할일이 거의 없습니다. 제 추정이지만 아랍어를 지원하는 국내 사이트나 서비스가 10개나 될까 싶을 정도로요. 어느정도냐면 사우디의 아람코가 대주주인 S-OIL도 영문 홈페이지만 운영하지 아랍어 홈페이지는 운영하지 않습니다.
지원 언어 중 아랍어가 들어가면 기획 난이도가 2배 이상 상승합니다. 단순히 문자가 익숙하지 않다. 구분이 잘 안된다의 문제가 아닙니다. (크메르어도 문자는 알아보기 힘듦) 다른 언어에는 없는 아랍어가 가지고 있는 고유한 특성이 하나 있는데 바로 R to L 입니다.
보통 대부분의 국가들은 L to R (Left to Right)이라고 하여 글을 왼쪽부터 시작해 오른쪽으로 읽습니다. 그런데 특이하게 아랍어는 R to L (Right to Light)이라고 하여 문자를 오른쪽에서 시작해 왼쪽으로 읽습니다. 잘 이해가 안가신다고요? 예를 하나 들어보죠.
LG전자 이란 다국어 사이트의 메인 페이지
LG전자 미국과 이란 다국어 사이트 GNB 비교위 이미지는 LG전자의 이란 다국어 사이트 화면입니다. GNB와 콘텐츠 텍스트 영역을 보면 단순히 문자가 오른쪽 정렬되어 있다가 아니라 좌우가 반전된 형태로 모든 문자가 오른쪽부터 시작해 왼쪽에서 끝나는 것을 알 수 있습니다. 아랍어 표기 방식에는 2가지 규칙이 있습니다.
1) 아랍어는 오른쪽에서 시작해 왼쪽에서 끝남
2) 아랍어 이외의 외국어 (영어)는 R to L 적용을 받지 않음
단순한 표기 방식의 차이가 UI/UX에는 심대한 영향을 미칩니다. 그리고 기획 측면에서 이건 상당한 리스크가 됩니다. 우리가 사용하는 모든 툴, 심지어 운영체제마저도 L to R 구조이기 때문이죠.
지금 당장 LG 전자의 이란 다국어 사이트 (https://www.lg.com/ir)에 가서 눈에 보이는 아랍어 하나만 긁어다가 엑셀에 복사해서 붙여넣기 해보면 뭐가 문제가 되는지 명확히 알 수 있습니다. 이란 다국어 사이트에 표기된 아랍어와 엑셀에 붙여넣은 아랍어의 어순이 다르죠? 엑셀이 R to L 구조인 아랍어를 L to R 구조로 강제 변환하여 표시했기 때문입니다. 엑셀뿐만 아니라 우리가 사용하는 모든 소프트웨어가 이렇게 텍스트를 강제 변환해 표시합니다.
이게 어떤 문제가 있냐면 메인 배너 CTA에 있는 텍스트 문구를 이걸로 바꿔주세요라고 개발자나 퍼블리셔에게 아랍어를 전달했을 때 중간에 어순이 강제 변경되어 내가 전달한 문구의 의미가 달라질 가능성이 매우 높다는 이야기입니다. 그래서 아랍어 문구를 변경하고 검수할 때는 문구전달부터 검수까지 매우 심혈을 기울여 체크해야 합니다. 가뜩이나 알아보기도 힘든데 어순도 신경써야되니 기획자는 정말 미칠 노릇이죠.
UI/UX 적인 측면에서도 마찬가지입니다. 지원 다국어 중 아랍어가 있다면 레이아웃 설계 시 텍스트가 오른쪽에서 시작할 수 있다 라는 가정을 넣고 모든 레이아웃을 설계해야 됩니다. 콘텐츠도 기존 관습처럼 왼쪽에서 오른쪽으로 읽는게 아니라 오른쪽에서 시작해 왼쪽으로 읽기 때문에 시선 이동에 따른 콘텐츠 배치도 달라져야 하죠. 이게 말로는 무척 쉬워보이지만 수많은 변수가 존재하기 때문에 아랍어를 경험해본 기획자라도 익숙해지는데 꽤 시간이 걸립니다.
문화적 차이
다국어 사이트를 만들다보면 해당 국가 또는 문화적 특성에 따라 콘텐츠 사용에 제약사항이 있는 경우가 있습니다. 콘텐츠 제약 사항 중 가장 보편적인 내용이 바로 사진입니다.
다문화 국가, 특히 인종 차별이 어느정도 남아있는 국가의 경우 문화적 다양성을 존중하기 위해 사진을 사용할때 특정 인종만으로 구성된 이미지를 경계하는 국가나 회사들이 종종 있습니다. 미국이 특히 이런 경향이 강한 편인데 미국 타겟의 서비스를 만들 때 특정 인종(특히 백인)만 있는 사진을 사용하는건 클라이언트나 사용자의 심기를 건드릴 가능성이 농후합니다. 그래서 다문화국가의 서비스를 만들거나 디자인을 할때는 해당 타겟 국가의 인종 구성비를 보고 인종을 적당히 섞은 사진을 사용하는것이 좋습니다. 미국으로 예를 들면 백인, 히스패닉, 흑인, 황인종 모두를 아우를 수 있는 사진을 사용하는거죠.
물론 반대의 경우도 있습니다. 요즘에는 거의 없어졌는데 예전만 해도 인종 차별주의 마인드(주로 백인 우월주의)로 가득 찬 꼰대 CEO들이 제법 있었습니다. 이런 CEO 들에게는 특정 인종만으로 구성된 사진을 사용하는게 좋습니다. 대표적인 예를 꼽아보자면 미개인이 사는 아시아, 아프리카에는 입점하지 않겠다는 말을 거리낌 없이 하고 다녔던 인종차별주의 CEO의 끝판왕 아베크롬비의 마이크 제프리스를 들 수 있죠.
콘텐츠 사용제한은 문화적 폐쇄성의 끝판왕. 이슬람 국가에도 적용됩니다. 여기는 좀 오묘한데 특정 인종 (특히 백인)을 국가의 주적이자 원수로 생각하는 나라들이 제법 있어 이미지를 사용할 때 백인이 들어간 이미지는 지양하는 것이 좋습니다. 이슬람 모델이 있는 사진을 구하기가 힘들 땐 편법이 하나 있습니다. 인종적으로나 외형적으로 가장 비슷한 국가의 사용하는거죠. 남자사진은 수염이 많이 난 이탈리아계 모델 사진 중 이놈이 아랍사람인지 이탈리아 사람인지 외형적으로 구분하기 힘든 모델 사진을 사용하면 됩니다.
이슬람 문화에서 남자의 수염은 무척 중요합니다. 이슬람 율법인 하디스에서 예언자 무함마드가 수염을 길렀다는 이야기가 있기 때문이죠. 조선시대의 상투와 비슷한 개념인데 그래서 남자 사진은 턱수염이 수북한 이미지를 사용하는게 좋습니다.
이슬람 문화권 국가에서 여자 사진을 사용할때는 특히 주의해야 합니다. 요즘은 많이 사라졌는데 예전만 해도 이슬람 문화권 국가 다국어 페이지에서 여자 사진을 사용할때는 꼭 히잡을 착용한 여자 사진만 사용이 가능한 경우가 많았습니다. 히잡 문화는 이슬람의 경전인 쿠란을 근거로 하고 있는데 우리는 기후 특성상 짱 더우니까 살타는거랑 수분 뺏기는거 막으려면 천쪼가리를 덮고 다녀라는 무함마드의 순수한 의도를 지들 멋대로 해석해서 여성들에게 히잡 착용을 강제하고 있는거죠. 일부 국가의 경우 이를 극단적으로 해석해서 눈만 보이는 형태의 부르카 착용을 강제하기도 합니다. 이는 중동 지역뿐만 아니라 이슬람 신자들이 많은 일부 동남아시아 국가와 아프리카 국가들에게도 적용됩니다. 이슬람 문화권이라고 다 그런것은 아니고 상대적으로 자유로운곳도 있고 (요르단) 엄격한 곳 (이란, 사우디, 아프가니스탄) 도 있으니 국가적 특성을 잘 고려해야 합니다.
국가별 SNS 확산
게시물이나 콘텐츠 공유 기능이 있을 경우 로컬에서 주로 사용하는 SNS 현황을 확인하여 국가별로 공유 가능한 SNS와 노출순서를 달리해야 합니다.
몇몇 국가의 경우 자국내에서만 사용하는 SNS들이 있습니다. 중국의 웨이보 / 한국의 카카오톡 / 베트남의 Zalo 같은 경우가 좋은 예죠. 이런 국가별 차이를 고려해 국가별로 노출 가능한 SNS의 개수와 종류를 다르게 설정하는것이 중요합니다.
대륙의 기상
중국은 자국기업보호와 검열을 명분으로 만리방화벽(일부 외국사이트의 접속을 차단하는 검열시스템)을 사용합니다. 중국에서 차단한 대표적인 해외서비스로는 구글, 유튜브, 페이스북, 트위터, 넷플릭스 등이 있죠. 이런 공산당스러운 조치 덕분에 이들을 대체하는 바이두와 웨이보, 유큐 같은 자국 서비스가 성장할 수 있었지만 반대로 기획자 입장에서는 머리 아픈 일이 하나 더 생기고 말았습니다.
우리가 일상적으로 사용하고 있는 서비스 관련 인프라들이 이들 기반이기 때문이죠.
구글 지도 (중국판 사용가능 / 정확도가 떨어짐)
구글 애널리틱스 (사용 가능하나 정확도가 떨어짐)
페이스북, 트위터, 인스타그램 등의 SNS (원천 차단)
유튜브 (원천 차단)
파이어 베이스 (원천 차단)
페이팔 (원천 차단)
이 정도면 기획자 입장에서 거의 손발이 잘린 수준입니다. 중국 내 기업이 제공하는 대체 서비스들 (바이두, 유쿠, 알리페이 등)을 이용하면 된다지만 이들 서비스는 가입 방법도 복잡하고 (중국 내 전화번호가 없으면 가입이 안 되는 경우가 많음) API 개발 문서도 불친절하며 인터넷상에 돌아다니는 관련 연동 노하우가 극히 부족합니다. 저희끼리는 이걸 이렇게 비아냥댔죠. 참 대단한 대륙의 기상이야.
지금까지 다국어 서비스를 구축할때 기획자가 알면 좋을 몇가지 꿀팁을 알아보았습니다. 로컬을 넘어 글로벌 진출이 선택이 아닌 필수가 된 요즘. 기획자들에게도 글로벌 마인드와 역량이 중요시되고 있습니다. 글로벌 진출을 꿈꾸고 있는 여러분을 응원합니다!
