i18n: 다국어 처리와 글로벌 서비스의 필수 요소 파악하기

i18n이란 무엇인가
알아보면서..
Ref

i18n이란 무엇인가

i18n 이란 Internationalization의 약자이며, 'i'와 'n' 사이에 18개의 글자가 있어 'i18n'으로 줄여 표현한다. 어떤 문화, 지역, 언어를 사용하는 사용자도 쉽게 서비스에 접근할 수 있도록 설계하고 개발하는 방식을 뜻한다.

국제화를 고려한 설계 방식은 서비스의 확장성에 상당한 영향을 준다. 언어 및 문화를 고려한 제품은 그렇지 않은 제품에서 확장하려 할 경우 개발 비용이 많이 드는 작업이다. 이런 이유로 이상적으로는 서비스 중간에 고려하는것이 아니라 서비스 초기에 기본으로 고려하는것이 가장 좋다.

국제화는 다음과 같은 항목을 반드시 고려해야 한다.

유니코드 사용
양방향 텍스트, 세로 텍스트 등 읽기 방식에 따른 css 지원
날짜 및 시간 형식, 달력, 숫자 형식, 목록 형식, 이름 및 주소 형식 처리 같은 로케일 대응
리소스의 외부화

간단하게 해당 내용을 살펴보려 한다.

유니코드(범용 코드 기반)

i18n의 기본은 서비스가 전 세계의 모든 문자 체계의 텍스트를 지원하는지 확인하는 것이다. 유니코드는 컴퓨터에서 사용되는 대부분의 언어, 기호, 고대 문자 등을 인코딩하고 나타내기 위한 표준이다. 최대 약 110만개의 문자를 인코딩 할 수 있어 단일 표준으로 전 세계 모든 언어와 스크립트를 지원하며 대부분의 웹 및 운영체제에서 기본적으로 제공하는 표준이다. 인코딩 자체를 뜻하는게 아니며, 어떻게 기호가 숫자로 변환 되는지를 정의하지 않는다. 그저 문자와 숫자간의 매핑을 정의하는 명세서일 뿐이다.

읽기 방식에 따른 css 지원

세계에서 가장 많이 사용되는 문자 체계는 라틴어 문자 계열이고, 그 다음이 바로 아랍어이다. 대부분의 언어들은 주로 왼쪽에서 오른쪽으로 읽는 방식이지만 아랍어의 경우 오른쪽에서 왼쪽으로 읽는다.

이는 UI 레이아웃에도 영향을 미친다. 따라서 css 작성시 명시적 방향 값인 left, right 대신 논리적 방향 값인 start, end를 사용하는 것이 권장된다. 이렇게 하면 페이지 방향을 변경 하더라도 코드를 건드릴 필요가 없다.

로케일 대응

이름, 주소 등

이름과 주소에 대한 정보를 저장하거나 UI로 표현할 때, 나라별로 다르게 표현하거나 저장해야 할 수 있다. 때문에 해당 데이터들을 어떻게 처리해야 하는지에 대한 고민이 필요하다.

나라마다 성을 주로 사용하는 나라와 이름을 주로 사용하는 나라들이 있으며 한글자의 이름을 사용하거나 매우 긴 이름을 사용하는 경우도 있다.

혹은 주소체계가 달라서 다른 방식으로 주소를 조회하고 저장해야 할 수 있다. 한국은 지번 주소 체계와 도로명 주소를 사용하지만, 일본은 주로 우편번호를 통해 주소를 조회하는게 일반적이다.

이와 같은 데이터들은 UI부터 저장 방식을 고려해 확장성을 갖도록 설계하면 지원하지 않던 국가에 쉽게 확장할 수 있다.

시간, 통화, 날짜 등

시간, 통화, 날짜 등의 데이터는 하나의 표준된 방식으로 저장하는 데이터 이지만 로컬 사용자에게 현지 시간과 통화, 날짜에 맞춰서 표현할 수 있는 데이터들이다.

날짜 표기 방식으로 예로 들면 표기 순서와 구분 기호에서 주로 차이가 난다. 미국의 경우 월/일/년 순서 + 슬래시(/)를 이용하여 날짜를 표시하며, 유럽에선 일/월/년 순서 + 슬래시(/) or 점(.)을 혼동해서 쓴다. ISO 표준은 연/월/일 + 대시(-) 조합이지만 서비스하는 나라마다 유저가 느끼는 친숙함에 맞춰서 표시하는것이 좋다.

문화적 상징 및 규제

사용자 경험에 혼란을 줄이기 위해서 문화적으로 다른 의미로 해석될 수 있는 상징이나 아이콘등을 파악하고 제공하는것이 중요하다.

서양권에선 완료 와 같은 긍정적인 의미로 사용하는 체크표시(✓)의 경우 일본의 경우 선택을 뜻할 때 사용하기도 하며, 다른 일부 국가의 경우 부정확함을 뜻할 수 있기 대문에 서비스를 제공하는 나라의 문화적인 차이에 맞게 변경해서 제공해야한다.

또한 나라별 규제에 대응할 필요도 있다. 미국의 경우 CCPA(California Consumer Privacy Act) 쿠키 정책을 따르고 있으며 유럽의 경우 GDPR(General Data Protection Regulation) 쿠키 정책을 따르고 있다.

리소스의 외부화

리소스를 외부화하지 않으면 서비스가 개발자에게 지나치게 의존적인 서비스가 되어버린다. 예를 들어, 번역된 파일이 소스코드 내부에 있다면 텍스트 하나를 수정하기 위해선 개발자가 내부 파일을 수정해서 다시 배포를 해야하는 플로우를 가지게 된다. 만약 잘못 수정할 경우 또 다시 배포 해야하는 경우가 생긴다. 더 나은 업무 효율을 위해서는 리소스를 최대한 외부화 해서 다국어 처리하는것이 중요하다.

알아보면서..

다국어 처리는 단순한 번역 이상의 과정으로, 각 지역의 사용자 경험을 고려해 서비스의 확장성을 높이는 필수 요소임을 다시 느꼈다. 주로 동양권 다국어 작업을 해 오면서 익숙했던 방식에서 벗어나, 이번 기회에 CSS의 읽기 방향 지원 등 다양한 요소의 중요성을 새롭게 인식하게 되었다.