넥슨 데브캣 스튜디오에서 근무하는 김한수 프로그래머는 9일 열린 넥슨 개발자 컨퍼런스(NDC)에서 “로컬라이징 노하우 공유 - 개발 환경 구축부터 글로벌 서비스까지” 세션을 통해 실제 사례를 중심으로 글로벌 원빌드에서 많은 국가와 언어에 대응하며 어떤 일들에 대비해야 하는지에 대해 공유했다.

국가별 빌드는 해당 국가에 맞는 맞춤 빌드를 준비할 수 있지만 비용이 많이 들고, 버전 관리가 힘든 단점이 있다. 그리고 글로벌 원빌드는 비용이 저렴하고 지원 언어를 늘리기 쉽지만, 맞춤 서비스를 준비하기 어렵다는 단점이 있다.

글로벌 원빌드를 준비함에 있어 먼저 클라이언트의 대응을 보자. 개행(줄바꿈)이 없는 언어의 대응과 언어별 폰트 문제, 텍스트가 포함된 이미지 처리, 금칙어 적용 범위, 닉네임 관련 처리 등의 이슈가 가장 크다. 

먼저 개행 없는 언어의 대응이다. 중국어나 일본어, 태국어 등 생각보다 띄어쓰기를 쓰지 않는 언어가 많기 때문. 그리고 유니티는 반각 공백에 대해서만 적절히 개행을 해준다. 그래서 개행이 없는 언어는 잘라야할 포인트를 찾지 못해 읽을 수 없는 수준까지 줄여버린다. 이 문제 해결을 위해 런타임에 글자폭을 계산해 개행토록 하거나 형태소 분석으로 반각 공백을 미리 삽입하는 방법을 쓸 수 있다.

언어별 폰트 문제의 경우 나라마다 같은 한자를 조금씩 다르게 쓰는 경우가 있고, 유니코드의 코드포인트가 같기에 언어별로 폰트를 다르게 쓰도록 시스템을 미리 구축해야 한다. 그래서 필요할 때 폰트를 로딩하게 하거나 언어별로 폰트 사이즈를 지정할 수 있도록 해야 한다. 참고로 한글과 번체의 폰트를 공유해 리소스를 절약할 수도 있다.

텍스트가 포함된 이미지 처리의 경우 제일 좋은 방법은 안 넣는 것이다. 이미지 수에 언어 수를 곱하면 엄청나게 늘어나기 때문. 변경되기 쉬운 부분들은 텍스트 영역을 별도로 분리하는 것이 좋지만, 하지만 꼭 넣어야 할 경우 상황에 맞게 정책을 정해야 한다.

금칙어의 경우 모든 언어에 동일한 금칙어를 적용하게 되면 다른 국가 금칙어에 걸려 채팅이 되지 않는 상황이 벌어진다. 그리고 언어별로 금칙어를 분리하게 되면 한쪽에만 금칙어가 걸리는 상황이 벌어진다. 하지만 어느쪽을 선택해도 너무 일반적인 금칙어는 지양하는 것이 좋다.

닉네임 관련 처리 부분에서는 몇 글자 이하 혹은 특수문자 제외가 일반적으로 쓰이는데, 특수문자의 범위에서 난감함이 발생한다. 이 부분은 정규식을 사용해 언어별로 사용 가능한 특수문자를 제외하는 방법을 쓸 수 있다.

다음으로 파일 포맷의 대응을 보자. 여기에는 파일 포맷 선정과 인코딩 이슈, 부가정보 기록, 로컬라이징 포맷 등의 이슈가 있다.

파일 포맷은 작업자간 충돌을 최소화하는데 중점을 뒀고, 이를 위해서는 Json 포맷을 쓰는 것이 좋다. 또한 영역별로 파일 분리를 권장하고 텍스트 키를 기준으로 정렬하면 충돌을 방지할 수 있다. 다만 최종 포맷은 효율성 문제로 TSV나 CSV, BSON을 추천한다.

인코딩 이슈의 경우에는 한중일 언어를 2바이트로 표현할 수 있고 대체로 많이 쓰기에 UTF-16LE(유니코드)를 추천하지만, 텍스트 편집기의 경우 비주얼 스튜디오 코드에서 기본 인코딩은 UTF-8을 쓰는 것을 추천한다.

부가정보 기록의 경우 작업자 간의 원활한 의사소통과 번역팀에게 추가적인 정보 전달을 위해 진행하는 것이 좋다. 여기에는 화자와 텍스트 순서, UI 너비, 타겟 버전 등을 기록해두면 좋다.

마지막으로 개발 환경 구축 이슈를 보자. 게임을 만들기 위한 기반 시스템에서 미리 준비해두면 좋은 기능에는 긴급패치 텍스트 분리, 텍스트 포맷팅, 조사 처리, 엑셀 익스포트/임포트 기능이 있다.

텍스트는 패치 직전까지 빈번하게 수정되고, 고칠 경우 번역 과정도 필요해 시간이 많이 걸리게 된다. 그래서 미리 별도로 텍스트를 어셋 번들로 관리, 프로세스를 거치지 않고 바로 올려 긴급 패치를 할 수 있도록 준비하는 것이 좋다.

텍스트 포맷팅은 글로벌 원빌드에서 적극 권장된다, 그 이유는 데이터 변경 시 텍스트를 다시 번역할 필요가 없기 때문이다. 또 텍스트 포맷팅을 미리 해두면 언어에 따라 어순이 달라도 대응이 용이하고 나라마다 다른 날짜 표기법에도 대응할 수 있다.

엑셀 형식의 익스포트/임포트 기능도 있으면 좋다. 외부에서 전달받는 포맷은 엑셀일 경우가 많고, 서로 다른 시스템을 오갈 때나 작업 내용을 일괄 적용할 때 이 기능이 아주 유용하기 때문이다.

그는 아시아 국가별로 다른 대응에 대해서도 사례를 공개했다. 중국의 경우 판호를 받으려면 종교와 폭력, 공산주의를 부정하는 내용이 들어가면 안 된다. 예를 들어 해골이나 핏자국, 죽은 사람이 되살아나는 것도 안 된다. 또 중국에는 수많은 앱 마켓이 있는 만큼 라이브러리를 추가해야 하며, 음성 메모 성격의 보이스 채팅 기능이 필요하다.

일본의 경우 법률이 까다롭다. 동일 아이템으로 구성 시 보너스는 50%까지 괜찮고, 다른 아이템을 섞으면 30%까지 괜찮다. 그리고 보너스는 라벨을 붙이는 식으로 UI에서 반드시 구분해야 하고 유료와 무료 재화는 DB에서 반드시 구분해야 한다. 환불 문제 때문이다.

그리고 컴플리트 가챠 금지 이슈로 80%까지만 모아도 모든 보너스를 획득할 수 있어야 하고, 조합이 가능한 개수는 32종 이상이어야 한다. 또 특정 카드에서만 다른 효과가 발생하면 안 된다. 또 실제 기능과 설명이 다른 상품을 판매하면 안 된다. 텍스트를 오역할 경우에도 문제가 발생하는 만큼 한 번 더 확인하고 챙기기를 당부했다.

박상범 기자  ytterbia@gamevu.co.kr

<저작권자 © 게임뷰, 무단 전재 및 재배포 금지>