🔗 아티클 출처
https://brunch.co.kr/@fbrudtjr1/23
실전 UI/UX - 다국어 서비스기획시고려해야할것들
서점군은 가진 능력에 비해 운이 좋게도 다양한 다국어 웹서비스 구축&운영 경험을 가지고 있습니다. 처음 다국어 서비스 구축에 참여하게 되었을 때는 단순하게 생각했죠. 그래 나도 이 바닥
brunch.co.kr
🗨️ 선정 이유
▪️ 현재 글로벌 시장을 대상으로 하는 웹 서비스 프로젝트에 참여하고 있으며, 현지 시장성을 고려한 localization을 담당하고 있다.
▪️ 우리 서비스는 멕시코, 이집트, 베트남, 러시아 등 글로벌 법인을 대상으로 각 국가의 언어 및 영어 서비스를 제공한다. 가장 어려웠던 부분은 오른쪽 → 왼쪽으로 쓰는 아랍어를 화면에 반영하는 것이었다.
▪️ 처음에는 다국어 서비스 기획에 대한 개념이 없어서 이를 이해하고 활용하기 위해 다양한 아티클을 찾아 읽었다.
▪️ 이 중에서 특히 도움이 많이 된 아티클에 대해 나 스스로도 다시 한 번 개념을 정리하고 내 것으로 만들기 위해 선정하였다.
📑 내용 정리
다국어 서비스와 로컬 서비스는 큰 차이점을 가지고 있다. 글로벌 시대에서 많은 서비스들이 글로벌로 진출하고 있는데, 다국어 서비스 구축 경험이 있는 기획자는 많지 않다. 다국어 서비스를 기획할 때에는 아래와 같은 UI/UX 항목을 고민해야 한다.
1️⃣ 기능의 컴포넌트화
✔️ 서비스의 특성, 지역적 특성, 시장 환경 등 여러가지 요인으로 국가별 서비스 범위나 특성이 달라지기도 함.
✔️ 다국어 서비스 기획시에는 변화무쌍한 국가 특성을 고려해 기능을 넣고 빼기 쉽도록 단위별로 컴포넌트화하여 작업하는 것이 중요함.

- 예외사항 발생시
- 하나의 프레임: 해당 영역을 하드코딩으로 예외처리
- 컴포넌트 단위: 문제 발생 부분만 교체 또는 제외
- 다양한 국가에 서비스를 한다면, 가장 기능과 컨텐츠가 많은 국가를 우선하여 그 기점으로 다국어로 확산하는 것도 방법
2️⃣ 언어는 최우선 고려사항
✔️ 텍스트 길이에 주의할 것 : 텍스트 길이에 영향을 주는 케이스가 많다.
1) 문자의 압축률
- 문자의 압축률: 내가 어떤 표현을 할 때 몇 글자의 문자가 필요한가
- e.g. 반갑습니다의 다국어 표현 (파파고 기준)
- 한글 : 반갑습니다(5글자)
- 영어 : Nice to meet you (13글자)
- 아랍어: سعيد بلقائك (11글자)
- 베트남어: hân hạnh. (7글자)
- 동일한 표현을 할 때 한자> 한글 > 영어 순으로 문자의 압축률이 높아지는 특성을 가짐
- 문자 길이 예상 시 가장 짧은 문자는 한자로, 가장 긴 문자는 영어로 가정하고 레이아웃을 설계할 것
2) CTA 설계 시
- CTA: Call To Action 은 다국어 영향을 많이 받음 ← 글자수에 따라 버튼의 width가 달라질 수 있기 때문
- 해결방법
- 버튼의 가로폭을 글자수에 맞춰 가변적으로 조절
- 가장 긴 문자 기준으로 가로폭을 설계

- e.g. LG전자는 첫번째 방법을 택함
- TIP) 레이아웃 설계시 MIN: 중국어, MAX: 영어로 설계하면 다국어의 오차를 줄일 수 있음

3)말줄임
- 말줄임은 영역이 정해져있고 글자 길이가 영역보다 길거나 예상할 수 없는 경우 사용함
- 다국어의 말줄임 이슈는 주로 카드형 list 페이지에서 많이 발생
- e.g. 브런치 페이지

- 보통 말줄임을 할 때 글자의 Byte 수를 계산하여 글자를 자름
- e.g. “글자가 80 Byte 초과될 경우 말줄임을 한다”
- 언어마다 한글자가 차지하는 Byte에 차이가 있음 → Byte기준으로 말줄임 시 언어별 표현되는 단어의 수가 달라짐
- 1글자당 Byte 수
- 영어: 1
- 공백/특수문자: 1
- 한글: 2
- 중국어: 3
- 공백없이 80 Byte로 글자를 채운다면
- 영어: 80자
- 한글: 40자
- 중국어: 26자
- 1글자당 Byte 수
- 따라서 Byte가 아닌 Character(문자)로 말줄임 처리를 함
- 단점: 문자마다 1글자가 차지하는 영역이 다를 수 있음
- e.g.

4) 문자 코드
- 다국어 서비스에서 언어가 표시되는 영역과 문자열이 저장되는 위치
- 퍼블로 입력하는 일반 문자열 (이용안내, 개인보호정책 등) → HTML
- 관리자 페이지에서 입력하는 문자열 (공지사항, 팝업 등) → Data Base
- 프로그램에서 표시하는 문자열 (게시판의 List 버튼 텍스트) → 프로그램 소스
- 1번과 2번은 관리와 수정이 용이하지만 3번은 국가별 페이지에 따라 문자열을 다르게 표현해야 하기 때문에 복잡함
→ 프로그램 소스 내 예외처리로 분기를 해서 해결
→ 단점: 새로운 국가나 언어 추가 시 문구가 표시되는 페이지의 소스에 대한 해당 언어 문구를 일일이 추가해야 함
→ 관리와 추가/수정이 용이하도록 프로그램 공통 문구 코드를 따고 해당 문자열을 DB에 저장해서 불러오는 식으로 관리함

5) 월드타임
- 시차!
- 시차는 주로 공지사항 관리, 팝업관리, 메인 배너를 하나의 관리자에서 등록/관리하는 경우 발생
☝ e.g. 전 세계 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)
→ 시차로 인해 한국 시간 기준으로 시차를 적용해 국가마다 다른 시간에 배너가 노출됨
- 시차 문제를 해결하려면 시차 보정 기능을 추가해야 함
- 시차 보정 기능 (e.g. 예약 노출 시간 기능)
- 예약 노출 시간은 한국을 기준으로 하고, 각 국가별 시차 프로그램이 자동 보정(하드코딩)
- 국가별로 배너 오픈 시간을 별도 설정할 수 있도록 등록 영역 개발 (국가 수만큼 시간을 입력할 수 있는 영역 필요)
- 전부 한국 시간으로 보여줌
- 서버점검 시간은 시차를 보정하면 안됨 → 등록 옵션에 시차 보정 on/off를 설정할 수 있는 스위치나 라디오 버튼 추가
3️⃣ R to L
✔️ 아랍어의 고유한 특성 RTL
- 대부분의 국가들은 L to R (Left to Right) 순서로 글을 읽고 작성
- 아랍어는 R to L (Right to Left) 순서로 글을 읽고 작성
- 아랍어 선택 시 아랍어 이외의 외국어(영어)는 R To L 적용하지 않음
- UI/UX: 레이아웃 설계 시 텍스트가 오른쪽에서 시작할 수 있다는 가정 하에 모든 레이아웃을 설계해야 함
- 아랍어 문구 변경 시 어순이 강제 변경되는 경우가 있어 검수에 신경써야 함
- e.g. LG 전자 아랍어 사이트

4️⃣ 문화적 차이
✔️ 문화적 특성에 따라 콘텐츠 사용 제약사항이 있는 경우가 있음
- e.g. 사진 :
- 인종차별이 어느정도 남아있는 국가의 경우 문화적 다양성 존중을 위해 특정 인종만으로 구성된 이미지를 경계하는 국가나 회사가 있음 (e.g. 미국)
- 인종 차별주의 마인드(백인 우월주의)를 가진 회사는 반대로 특정 인종만 구성된 사진을 사용했음 (e.g. 아베크롬비)
- 이슬람 국가의 경우 국가의 주적/원수 나라가 있는 경우가 있어 백인 이미지 사용을 지양하기도 함
💡 생각 정리
▪️ 다국어 웹서비스 구축과 경험은 운이 좋아야 가질 수 있는 경험이라고 저자가 언급했듯이, 글로벌 서비스 출시 경험은 나에게 좋은 경험이라고 생각한다.
▪️ 초기에는 몇 가지 어려움이 있었다. 관련 문헌이나 자료가 제한적이어서 해외 웹사이트를 분석하여 정책을 세우기도 했었다. 그 때 저자의 글을 통해서 시작점을 찾았고, 이번 스터디를 통해 내용을 더 자세하게 정리할 수 있었다.
▪️ 다국어 서비스를 구축할 때 고려해야 하는 사항은 다양하다. 해당 국가의 개인 정보보호 정책 및 법률적인 측면을 법무실과 지속적으로 체크해야 하며, 통화의 종류/소수자릿수, 전화번호 digit, 일주일의 첫 요일 및 시간형식(12시간제 또는 24시간제) 및 국가의 time zone과 같이 국가별로 상이한 세부 정보를 고려해야 한다.
▪️ 또한 국가별 언어팩을 관리해줘야 하는데, 프로젝트 초반에는 그 과정에서 관련 경험자가 없어 시간이 많이 소요되는 비효율적 업무를 했던 적도 있다.
▪️ 특히 아랍어를 적용하는 경우에는 RTL에 따라 UI가 좌우 반전되어 그에 따라 사용성을 검토해야 하는 부분도 있다.

저요!!!! 저!!!! 저 해봤어요 !!!!!!!!! 흑흑
▪️ 글로벌 서비스 프로젝트에 참여하면서 얻은 경험을 정리하는 시간을 조만간 가져봐야겠다.
린의 맛집 블로그 https://blog.naver.com/lynnyeonjulee
맛있는 게 좋아 : 네이버 블로그
틀을 잡아가고 있어요 조금만 기다려주세요 ❤️
blog.naver.com
'서비스 기획자 > 아티클 스터디' 카테고리의 다른 글
| [아티클 스터디] 카카오맵은 왜 상세화면을 탭으로 구분했을까? (0) | 2024.01.12 |
|---|---|
| [아티클 스터디] 기능 출시 후, 우리가 챙겨야 할 것은? (2) | 2024.01.11 |
| [아티클 스터디] ‘스타트업/빅테크/대기업’ 삼각구도로 본 국내 생성형 AI 트렌드 (0) | 2024.01.09 |
| [아티클스터디] 기획자가 알아야 할 데이터 분석 도구와 활용법 (1) | 2024.01.08 |
| [아티클 스터디] 서비스 기획자의 전문성을 찾아서 (0) | 2023.10.18 |