티스토리 뷰

"어느 수위만큼 로컬라이징을 할 것인가?"

음... 체력을 가다듬고... [?!] 슬슬 로컬라이징시에 고려해야 할 요소에 대해 하나하나 정리를 해보도록 하겠습니다.
 
지난 포스팅에 제가 제시한 그 요소들은 아래와 같습니다.

1. 로컬라이징 레벨 - 어느 수위만큼 로컬라이징을 할 것인가?
2. 로컬라이징 컨텐츠 - 어떤 것들을 로컬라이징할 수 있게 할 것인가?
3. 스크립트의 구조 - 스크립트가 로컬 작업에 용이한가?
4. 해외 계약에 따른 업데이트 계획 - 어떠한 내용들을 단계적으로 업데이트 할 것인가?
5. 패치 프로세스 및 버전의 형식 - 버전 관리를 어떻게 할 것인가?
6. 이벤트 시스템 - 어떠한 이벤트를 지원해줄 수 있는가?
7. 툴의 준비 및 관리 - 해외에서 관련 툴의 사용이 얼마나 용이한가?
8. 시놉시스, 캐릭터 등에 대한 자료 - 서비스를 위해 필요한 정보들이 얼마나 준비되어 있는가?


이 중에서 오늘은 '1. 로컬라이징 레벨'에 대해서 이야기를 해보도록 하지요.


1. 로컬라이징 레벨


'로컬라이징 레벨'이라고 함은 쉽게 이야기 해서 '어디까지 로컬라이징이 가능토록 할 것이냐?' 라는 것입니다. 예전의 패키지 게임처럼 단순히 텍스트 스크립트와 이미지에서 글자 부분만을 번역하는 단계에 그칠 것인지, 아니면 서비스 되는 국가에 어울리는 아이템, 캐릭터, 배경 오브젝트들을 넣을 것인지, 또는 그것을 훨씬 넘어서 코어한 밸런스 부분까지 로컬라이징이 가능토록 할 것인지를 말하는 것이죠. 그렇다면 로컬라이징 레벨을 어떻게 나눌 수 있고, 나눠진 레벨별로 어떠한 준비가 필요한지를 알아야할 것입니다.

저는 이러한 로컬라이징 레벨을 다섯 개의 레벨로 나누어 구분하고자 합니다.

1단계 - [Translation]
게임에 사용되는 스크립트와 이미지의 로컬라이징

2단계 - [Localized Contents]
NPC, 아이템, 코스튬, 작은 배경 오브젝트 등의 로컬라이징(새로운 것의 추가가 아닌 응용 및 수정의 수준)

3단계 - [Localized Source]
순수하게 해외 용으로 작업된 NPC, 아이템, 캐릭터 등의 추가

4단계 - [Localized World]
존, 맵, 서킷 등과 같은 월드 단위의 로컬라이징

5단계 - [Localized Balance]
게임의 핵심적인 밸런스의 로컬라이징



1단계 - [Translation]
단순히 게임에 사용되는 스크립트와 이미지의 번역만을 처리하는 수준의 로컬라이징입니다. 패키지 게임이야 이 단계가 로컬라이징의 시작이요 끝이 될 수도 있겠지만, 온라인 게임에서는 '우리 게임도 로컬라이징을 했다' 라는 의미 그 이상도 그 이하도 아닐 것입니다. 제가 '단순히'라는 표현을 사용했지만, 사실 1단계의 로컬라이징을 하기 위해서도 상당히 많은 고려와 준비가 필요합니다.

우선 스크립트의 경우, 개발자, 관리자, 번역자. 이 세 명의 구미에 맞도록 구조가 잘 짜여져 있어야 합니다. 세 명 모두의 구미를 맞춘다는건 아래와 같은 내용을 의미합니다.

(로컬라이징을 위해 스크립트는..)
1. 개발자가 스크립트 작성에 불편이 없어야 한다.
2. 중간 관리자는 버전 및 여러 종류의 스크립트를 관리함에 있어 불편함이 없어야 한다.
3. 번역자가 번역을 할 때 용이하게 작업할 수 있어야 한다.

모두를 만족시키는 그런 완벽한 솔루션은 아마도 존재하지 않을 것입니다.
그러나, 완벽하지 못한 여러 대안 중에서 최상의 대안을 찾을 수 있도록 노력하고 또 찾아야 한다는 것이지요.

로컬라이징을 위한 스크립트 솔루션은 게임의 장르, 게임의 성격, 관리 시스템에 따라 달라질 것입니다. 게다가 스크립트 솔루션은 현재 사용하고 있고 논의되고 있는 것만해도 방대하리만큼 다양하니 이에 대해서는 별도의 시간을 할애해서 따로 다루도록 하겠습니다.

이미지의 경우 로컬라이징을 대비해서 어떠한 준비가 필요할까요?

우선 첫번째 문제로, 이미지 번역을 위해 자료를 준비하는 그래퍼 또는 중간 관리자가 흔히 하는 실수인 "작업에 사용된 작업파일을 그대로 해외에 전달한다."는 것입니다.
이미지 편집툴의 대명사인 "PhotoShop" 포맷인 PSD 파일을 기준으로 이야기를 해보겠습니다. 하나의 이미지 스프라이트를 만들기 위해서는 다수의 이펙트와 다수의 레이어를 사용하게 됩니다. 전체 화면에 사용되는 이미지의 경우 많게는 수십개의 레이어와 이펙트를 사용하기도 하지요. 그런데 이렇게 많은 이펙트와 레이어가 작업 파일에 그대로 남아 있는채로 해외에 넘어가게 되면, 해외에서 작업하는 작업자는 작업파일에 사용된 모든 레이어들이 어떻게 사용되고 있는지 파악하기 위해 많은 시간을 낭비하게 됩니다. 그리고 더욱 심각한 문제는 이로 인해 한국에서 작업한 그래퍼가 게임의 느낌을 위해 의도적으로 처리한 효과를 해외에서 임의로 변경해버릴 수 있는 여지가 있다는 것이죠.

두번째 문제는, 이미지에 사용된 텍스트에 대한 영문식 표현이나 설명이 없어 오번역의 여지가 크다는 것입니다. (물론 이 문제는 스크립트의 번역에서 더 많이 발생할 것입니다.)

세번째 문제는 때로 대중적이지 않은 포맷으로 저장해야 하는 이미지 파일이 가이드의 부족으로 인해 결과물이 오작업되어 넘어오는 경우가 많이 발생한다는 것입니다. 'DDS' 파일을 예로 들어보겠습니다. 개발사에서는 DXT3 ARGB 포맷으로 MIP maps 정보가 없는 DDS 파일을 사용한다고 가정할 때, 정보의 부족으로 인해 해외에서는 MIP maps 정보를 포함한 DDS로 작업을 하거나, 아예 포맷을 다른 포맷으로 저장해 오는 경우가 빈번하게 발생하게 됩니다. 이렇게 되면, 작업된 것을 다시 돌려보내 설명 후 재작업을 시키거나, 개발사에서 직접 제대로 된 포맷으로 다시 저장해야 하는 불필요한 작업을 감수하게 되죠.

위의 사례들을 비추어봤을 때, 효율적인 이미지의 로컬라이징 작업을 위해서는 적어도 다음 세가지가 준비되어야 할 것입니다.

(이미지의 로컬라이징을 위해...)
1. 번역에 용이한 간단한 구조의 작업 파일 (Only Background Layer + Text Layer) 로 저장되어야 한다.
2. 정확한 의미 전달을 위해 이미지에 사용된 텍스트의 영문 정보가 포함되어야 한다.
3. 작업 및 파일 저장에 필요한 가이드를 함께 제시해야 한다.

1단계의 로컬라이징을 위해 필요한 내용들을 나열했지만, 말처럼 쉽게 준비할 수 있는 것들은 아닐것입니다. 하지만 이러한 것들을 준비하지 않으면, 여러가지 자잘한 문제들이 개발자의 발목을 잡게 된다는 것은 자명한 사실입니다.
 

2단계 - [Localized Contents]
해외 현지 사정에 어울리는 NPC, 아이템, 코스튬, 작은 배경 오브젝트 등을 게임에 추가할 수 있는 단계로, 로컬라이징 작업이 해외에서 이루어져 국내 개발사에 전해지는 방식이 아니라, 해외의 요청 또는 자사의 필요로 인해 국내에서 처리하는 방식으로 작업되는 단계입니다. 사실, 이 단계부터 의미있는 로컬라이징이 시작된다고 할 수 있습니다.

이 단계의 로컬라이징을 시행할 때에는 일반적으로 통합 관리를 하는 것이 바람직합니다. 여기서 통합 관리라는 것은 어느 국가의 클라이언트든 간에 모든 리소스를 넣어두고, 해당 국가의 클라이언트 별로 필요한 파일들만을 선택적으로 사용하게 하는 것을 의미합니다. 국가별로 서로 다른 파일 구조를 가진 클라이언트와 서버를 따로 관리를 하게되면, 관리가 상당히 까다로워질 뿐더러 리소스 및 코드 소스의 유지 보수 측면에서도 어려움이 많기 때문입니다.

그렇다면, 이러한 통합 관리를 통한 지원이 용이하게 하기 위해서는 간단한 파일의 변경과 관련 내용(스크립트 따위)의 수정만으로 오브젝트를 변경할 수 있도록 만들어야 합니다. 복잡한 절차로 인해 그래퍼나 프로그래머를 귀찮게할 필요없이, 비전문가인 로컬라이징 담당자의 손쉬운 작업을 통해 이루질 수 있도록 해야 합니다. 예를 들어 동일한 NPC가 제공하는 특정 아이템이 미국과 중국이 서로 다른 아이템으로 하고 싶을 때, 코드 소스나 그래픽 리소스를 수정, 재빌드할 필요없이 간단한 스크립트의 수정과 같은 방법으로 쉽게 해결할 수 있어야 한다는 것입니다.

둘째, 이 단계의 경우 1단계와 동일하게 해외에서 요청할 때, 전혀 엉뚱한 내용이 요청되지 않도록 규정을 정리하여 해외에 제시, 이해시켜야 합니다. 그렇지 않으면, 당치도 않는 요청으로 인해 시간와 인력을 불필요하게 소모할 수 있기 때문이죠. (해외에 왜 안되는지를 설명하고 논쟁하는 건 생각보다 힘들고 짜증나는 일입니다.) 그리고, 필요한 자료를 전달 받아 가공하고 작업에 적용할 수 있을 때까지의 시간을 절약하기 위해, 자료의 폼에 대해서도 명확히 규정하고 이를 해외에서 지킬 수 있도록 유도해야합니다. 이 역시 불필요하게 낭비되는 시간과 인력을 절약할 수 있지요.
 
마지막으로, 이러한 통합관리에서는 체계적인 파일 관리가 필수적입니다. 동일한 파일명을 사용하지만 내용이 틀린 파일들은 국가별로 혼용되지 않도록 주의해야하며, 그 외 특정 파일들은 국가별로 서로 다른 이름을 가지게 하여 파일명 만으로 어떤 내용의 어떤 국가에 적용되는 파일인지 유추하고 적용할 수 있도록 해야합니다. 예를 들어, 해외 이벤트에만 사용되는 이미지 스프라이트를 모아논 이미지 파일이라던가, 한국과 동일한 오브젝트 파일인데, 텍스쳐를 로컬라이징할 경우 등이 이에 해당하겠습니다. 물론, 이렇게 파일명이 다르게 사용되는 파일의 경우 스크립트 등으로 파일명의 변환이 용이하게 이루어지는 경우로 한정해야할 것입니다.
국내 전용과 해외용 또는 더 세분화해서 각 국가별로 파일명을 어떻게 사용할 것인지를 사전에 정해놓는 것은 개발자의 교체시 새로운 개발자가 파일 구조를 빠르게 이해할 수 있도록 해줄 뿐더러, 차후 오랜 시간이 지나서 이루어지는 자료 관리에도 큰 도움이 될 수 있습니다.
또한, 프로그래머나 그래퍼 또는 그 외 부서원 개인이 관리가 필요한 특정 파일의 파일명을 마음 내키는대로 짓게 해서는 안됩니다. 이는 사용되는 파일명이 통일적이지 않게 할 뿐더러 위의 관리 체계를 뒤흔드는 요인이 됩니다. (관리가 필요한 파일에 한해) 파일명을 어떻게 지을지는 기획, 프로그래밍, 로컬라이징 이 3개 부서의 각 담당자들끼리 협의를 통해 지어져야 하며, 차후 체계적인 관리가 이루어져야 할 것입니다.

1. 로컬라이징이 필요한 모든 오브젝트는 필요에 따라 손쉽게 텍스쳐를 바꿀 수 있도록 해야한다.
2. NPC, 아이템, 코스튬, 작은 배경 오브젝트 등 로컬라이징이 이루어지는 컨텐츠의 경우 사전에 파일 구조 및 필요한 자료의 폼에 대해 외에 전달하고 인지시켜 작업의 용이를 꾀한다.
3. 로컬라징이 필요한 파일은 체계적으로 관리할 수 있도록 하며, 기획 단계에서 파일의 네이밍 규정을 명시하여야 한다.


댓글
댓글쓰기 폼
공지사항
최근에 달린 댓글
Total
3,686
Today
1
Yesterday
2
링크
«   2019/03   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
글 보관함