한동안 로컬라이징 작업을 열심히 하다, 최근에 시스템 개발 쪽으로 업무가 변경되었다. 다시 익숙해지느라 정신이 없는데 동료 분께서 사내 게시판에 올려둔 아래의 url들을 보고
느낀 바가 있어 나도 로컬라이징 과정에서의 경험들을 정리해본다. 예전에도 이런 포스팅을 한 적이 있지만 그때보다는 좀 더 포멀하게 써보련다.
1. 언어 입출력 단계에서부터 다국어 버전을 고려하자.
너무나도 당연한 얘기라서 요즘도 그런 경우가 있을지 모르겠지만 소스코드에 직접 텍스트를 입력하여 클라이언트에 출력하게 한다든지 게임 내 텍스트를 utf-8이 아닌 ansi로만 작업하는 경우가 있으려나?
오래 전 얘기인데 시스템 구현 도중 프로그래머가 소스 코드에 한글 텍스트를 하드코딩으로 처리했다. 당장은 문제가 없었는데 그 분이 퇴사한 이후에 대만에 게임 서비스를 시작하려고 로컬라이징 작업을 하는데 원인모를 에러가 계속 발생했다고 한다. 그래서 후임자가 차근차근 디버깅을 해보니 소스의 한글 텍스트가 대만 버전의 클라이언트에서 출력되는 과정에서 발생한 문제로 밝혀졌다.
너무 당연한 얘기지만 소스코드에서는 기획자/로컬라이징 담당자가 처리 가능하게 데이터를 별도로 빼주고 해당 스트링의 ID를 기준으로 출력하게 만든다. 스트링은 utf-8로 되어 있어서 해당 국가 버전에 맞게 번역된 데이터만 넣어주면 별다른 처리없이 어떤 언어 버전의 윈도에서도 일단은 출력되도록 해야 한다.
그리고 곧잘 잊어버리곤 하는데 데이터 입력 부분도 배려해야 한다. 한글 윈도에서 개발을 하다보니 한국어와 영어가 잘 입력되다보니 로컬라이징 작업에 문제가 없겠지라면서 툴을 개발했다가 외국어를 직접 입력하거나 퍼블리셔에서 온 번역된 데이터를 붙여넣으려다 문제가 되는 경우를 자주 본 적이 있다.
2. 한국어와 다른 어순 문제에 대해 주의를 하자.
중학교 1학년 때부터 외웠던 것처럼 한국어와 영어(를 비롯한 상당한 외국어)는 어순이 다르다. 그렇다보니 시스템 메시지 출력을 위한 스트링이 로컬라이징 과정에서 의도된 바와 다르게 출력될 때가 있다. 특히 기획자가 한국어를 기준으로 의도한 디자인/UI에서 문제가 되기도 한다.
사실 이런 부분은 검수 과정에서 금방 수정이 가능한 만큼 큰 문제가 아니다. 그렇지만 빠듯한 일정 속에서 이런 형태로 잔손이 가는 작업들이 반복되면 그만큼 시간을 잡아먹는 것이다.
3. 일본어의 경우 전각과 반각에 대해 인지하고 로컬라이징 작업을 준비하자.
전각 문자 : 문자의 폭이 일반적인 영문자의 고정 폭의 두 배 정도의 폭을 가지는 문자
반각 문자 : 전각 문자 폭의 절반을 폭으로 하는 문자
실제 클라이언트 단에서 입력 문제에 대해서는 항상 프로그래머에게 구두로 주의만 해준 터라 자세한 상황은 설명하기 어렵다^^
하지만 중요한 것은 UI. 요즘은 퍼블리셔들도 경험이 쌓여 크게 문제를 일으키지 않지만 가독성이나 구 버전 데이터 등의 이유로 전각과 반각을 혼용할 때가 있다. 그래서 처음에는 전각으로 번역 데이터가 넘어와서 UI의 폭이 사정없이 늘어나버렸다. 문제점에 대해 리포트를 하자 금새 반각 데이터가 넘어왔다.
결국 두 번 작업하게 되었는데 이런 문제는 번역 요청 전에 해당 데이터가 어디에 어떤 용도로 사용될 지 친절하게 코멘트를 달아서 보내주는 것이 최적이라고 본다.
4. 초기 UI 디자인 시점에서 폰트 사이즈 8이하로 한정짓지 말자.
이 문제는 한자 사용권에 진출할 때 자주 제기되는 문제인데 간체자를 쓰는 중국과 일본은 그나마 읽을 수 있는데, 우리와 같은 한자(번체자)를 사용하는 대만에서 문제가 된다. 가독성을 고려해 폰트가 커질 수 있다는 점을 항상 잊지 말자.
5. 다국어 버전을 준비한다면 풀어쓰기를 고려하자.
한국어로 된 데이터를 번역시키면 중국어는 외려 줄어들어서 오곤 한다. 문제는 영어권인데, 우리가 쓴 짧은 단어가 금새 문장으로 바뀌어 돌아온다. 스페인어도 무시무시하지만 독일어는 진짜 재앙이었다.
물론 이건 번역자의 역량에 따라 달라질 수 있다. 영어권 서비스를 준비할 때 번역된 데이터를 받았는데 길이가 장난이 아니었다. 그래서 곤란하다고 얘기하자, 담당자가 비행기를 타고 날아왔다! 그래서 둘이서 사이좋게 앉아서 모든 UI와 번역 데이터를 나란히 놓고 사용처에 대해 하나 하나 검수를 시작했다. 그러자 문장들의 길이는 금새 줄어들기 시작했고 UI 작업자 역시 수정 작업을 최소화할 수 있었다.
그렇다고 해서 수정 작업을 안 하는 것은 아니다. 그저 덜 하는 것이다. 그런 만큼 UI의 폭 특히 버튼의 경우 여유있게 만들어두는 쪽이 좋다.
6. 게임 내에서 더빙을 자제했으면 한다.
이건 개인의 생각 차이겠지만, 나는 게임에 한국어로 음성을 넣는 것은 매우 곤란하다고 생각한다.
해당 국가 별로 더빙을 다시 하는 경우에 한국에서 해당 국가 언어를 자유자재로 구사하는 성우를 뽑기도 어렵고 뽑는다 해도 성우가 아닌 그저 외국인 강사 심지어는 평범한 외국인인 경우도 비일비재하다.
해당 국가 별로 더빙을 다시 하는 경우에 한국에서 해당 국가 언어를 자유자재로 구사하는 성우를 뽑기도 어렵고 뽑는다 해도 성우가 아닌 그저 외국인 강사 심지어는 평범한 외국인인 경우도 비일비재하다.
그렇다고 해서 대본만 넘겨 퍼블리셔가 더빙을 하는 경우 문화적 차이로 인해 전혀 다른 느낌으로 더빙이 되는 경우가 있다. 그거야 뭐 해당 국가에서는 저렇게 받아들이는구나 라고 생각하면 되지만 언어의 차이(길이)로 인해 캐릭터 애니메이션을 다시 잡아야 하는 경우도 곧잘 생긴다.
게다가 퍼블리셔에서 비용 문제로 더빙을 하지 않고 자막 처리를 요구하는 경우도 있다. 그렇게 되면 그것 나름대로 또 작업이 발생하는 것이다.
7. UI 등 그래픽 데이터에 한국어 텍스트의 사용을 최대한 자제했으면 한다.
100% 자제하는 것은 어렵겠지만 가급적이면 텍스트를 그래픽 처리하지 않도록 한다.
예를 들어 하단 UI에 게임의 로고를 크게 박는 것도 좋지만 그게 한글인 경우 심지어 영문이라도 해외 진출 과정에서는 수정해야 하는 경우가 발생한다. 특히 맵 이동을 위해 로딩을 하면서 해당 화면에서 도움말을 보여주는 경우가 있는데 로딩 중 이미지와 도움말이 각각의 데이터로 분리되어 있지 않고 통짜 이미지인 경우도 있다. 그런 경우 국가 버전마다 죄다 그래픽팀에서 수정 작업을 해줘야 한다.
참고로 이런 일이 자주 벌어지는 부분은 미니맵과 로딩창이다.
8. 고유 명사 번역을 위한 가이드 라인도 같이 만들도록 하자. 그리고 로컬라이징 작업 때 해외 퍼블리셔에 보내주자.
게임 개발 초기 기획자는 곧잘 작명소를 차린다. 짧은 시간 안에 많은 이름을 지어야 하는데 해당 단어를 중국 설화나 프랑스 민담에서 따와도 그 근거는 남겼으면 한다. 그리고 그 근거 혹은 해설은 가급적이면 영어로 주석을 만들자.
퍼블리셔의 번역자가 아무 코멘트 없이 엑셀 시트 위에 쓰여진 '환영'(幻影)이라는 단어를 어떻게 번역하겠는가?
주석없이 illusion이나 phantasm이라 번역하면 정말 대단한 센스고, 보통은 welcome이다. 크게 휘두르자 어른거리는 칼날의 그림자가 적의 몸을 휘감으며 강렬한 데미지를 안겨주던 환영 무기는 바다를 건너자마자 적을 반기는 귀여운 무기로 바뀌게 되는 것이다.
9. 정치적 그리고 종교적으로 민감한 소재는 가급적 피한다.
이건 다른 회사의 담당자에게 들은 얘기인데, 십자가의 경우 한국 개발자들은 디자인 과정에서 크게 고민없이 사용하는데 외국에서는 특정 종교의 상징물로 받아들여져 바로 문제가 된다고 한다.
그리고 WW2 배경으로 게임을 만들었을 때 수도 없이 나오는 NAZI와 스바스티카는 정작 독일 현지에서는 쓰고 표시할 수도 없게 법으로 규정되어 있다.
또한 중국에서는 인골과 장기 노출 같은 고어한 표현에 극히 민감하다. 어느 정도냐면 이 문제 때문에 월드 오브 워크래프트가 중국에서 서비스될 때 언데드 종족에 관련한 그래픽 데이터를 전부 수정할 정도였다.
10. 로컬라이징 작업 중 은근히 빼먹는 것들
게임 인스톨러
런처
패처
최종 사용자 사용권 계약서(EULA)
보안 프로그램
그리고 운영툴
로컬라이징 작업은 텍스트와 그래픽 데이터만 바꿔주는 것이 아니다. 다른 국가의 다른 퍼블리셔가 게임 서비스를 원활하게 할 수 있도록 준비해주는 작업이다.
이것 역시 다른 회사의 담당자에게 들은 얘기인데 외국 회사에서 온라인 게임을 수입해온 것까지는 좋았는데 그 개발사가 너무 콧대가 세서 운영툴의 로컬라이징을 안 해주었단다. 그래서 운영자들이 툴의 버튼을 하나 하나 클릭하고 그 반응을 본 뒤에 운영 매뉴얼을 만들었다고 한다.
그렇다고 해서 우리도 똑같이 대응할 이유는 없다.
그렇다고 해서 우리도 똑같이 대응할 이유는 없다.
반응형