주제: '야생의 땅: 듀랑고'의 번역 버전 관리법 - 이 Git만 했어요
강연자 : 이민지 - 넥슨코리아 / NEXON KOREA
발표분야 : 사업마케팅 & 경영관리
권장 대상 : 로컬라이제이션 업무 관련 PM직군 종사자 및 관련 작업/담당자
난이도 : 관련 실무 경험 필요
[강연 주제] 총 10개의 번역 언어를 보유한 '야생의 땅: 듀랑고'는, 이전에 번역에서 흔히 사용하지 않았던 방식과 도구를 조합하여 프로젝트에 가장 적합하고 효율적인 프로세스를 고민, 확립하고 시도한 작업의 결과물입니다.
작년 NDC 비공개 세션으로 발표한 "엑셀 번역은 이제 그만, '야생의 땅: 듀랑고' 국제화 프로젝트"에서 최상급 번역 및 궁극적 현지화를 지향하며 시도했던 저비용 고효율의 국제화 도구들을 소개하고 프로세스 확립 과정을 공유했습니다. 올해는 작년에 소개한 국제화 도구 중에서도, 특히 버전 관리에 효율적인 Git을 소개하고 듀랑고의 번역 관리를 위해 어떻게 사용되고 있는지 구체적인 실무 사례를 들어 공유합니다.
한 때 현지화, 번역은 단순히 하나의 텍스트를 다른 언어로 옮기는 정도의 작업으로만 여겨졌다. 그러나 게임의 현지화 및 번역은 그보다 좀 더 복잡한 프로세스가 필요하다. 우선 단순히 초벌로 번역하는 것에서 그치지 않고 게임의 맥락에 맞춰서 체크하고 수정을 하는 검수 과정을 거친다. 이것까지 다 끝나면 게임 내에서 그 번역된 텍스트가 출력이 되도록 적용을 하는 작업까지 필요하다.
한두 가지 언어로 번역 및 현지화를 하는 데에도 이런 코스트가 드는 만큼, 몇 개 국어로 동시에 서비스하는 게임의 현지화 관리를 하는 것은 쉽지 않은 일이다. 그렇기 때문에 이민지 왓스튜디오 대리는 더 쉽게 할 수 있는 방법을 꾸준히 고민해왔다고 밝혔다.
이를 해결하기 위해 방법을 찾던 중 왓스튜디오에서 채택한 것이 Git을 활용하는 것이었다. 현재 '듀랑고'는 글로벌 서비스 준비를 위한 현지화 작업을 Git을 통해서 진행하고 있으며, 그로 인해 기존의 번역 및 현지화 프로세스보다 많은 것이 편해졌다고 이민지 대리는 밝혔다. 그리고 이번 NDC 2019에서 업계 관계자들에게 이를 활용하는 방안에 대해서 공유하고자 한다고 덧붙였다.
■ 왜 Git을 써야 할까? - 번역, 검수, 적용 3단계를 동시에 효율적으로 관리하는 방법
일반적으로 게임을 개발할 때 현지화를 진행하면 번역, 검수, 적용의 3단계를 거치게 된다. 번역가에게 초벌 번역을 우선 요청하고, 검수자들이 이 번역 내용을 보고 검토를 하고 개발자에게 넘기면 개발자들이 이 내용을 게임에 적용하는 식이다.
회사마다 부서의 구조가 다른 만큼, 번역과 검수 작업이 각각 다른 부서에서 할 수도 있고 동일한 부서에서 진행될 수도 있다. 그렇지만 번역과 검수는 각각 다른 사람이 맡는 만큼 기존의 엑셀을 활용한 파일 방식은 여러 가지로 번거로운 점이 있다고 이민지 대리는 설명했다.
가장 먼저 발생하는 문제는 번역을 하고 검수를 할 때마다 신규 파일이 생성된다는 점이다. 번역을 한 이후에 검수를 하고 수정을 하게 되면 파일명을 갱신해서 번역가에게 다시 보내곤 한다. 번역과 검수는 단순히 한 번 하고 끝나는 작업도 아니닌 만큼 언제 그 작업이 이루어졌으며, 또 몇 번째로 수정을 했는지 그 맥락을 확인할 필요가 있기 때문이다.
번역과 검수가 계속 될수록 그런 파일들이 쭉 쌓이는, 이른바 '무한증식' 현상이 발생한다. 그렇게 파일을 주고 받다가 때로는 파일명이 잘못되거나, 혹은 수정 판본을 잘못 보내는 일도 종종 생긴다. 이런 상황이 반복되다보면 이를 검토하고 체크하는 별도의 작업이 필요하게 되고 코스트가 계속 늘어나게 된다는 것이다.
이를 해결하기 위한 방법으로 듀랑고 현지화팀은 Git에 주목했다. Git은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템으로, 이미 여러 분야에서 업무 프로세스를 효율적으로 구성하기 위해서 활용되고 있다. 프로그램을 전문으로 하지 않은 팀이었기 때문에 Git을 처음 도입하기로 결정하기가 어려웠다. 그렇지만 업무를 동시에 효율적으로 관리할 수 있다는 점 때문에 듀랑고 현지화팀에서는 이를 적용하기로 했다고 이민지 대리는 전했다.
■ 듀랑고의 국제화 프로젝트- Git을 활용하기 위한 파이프라인
이민지 대리는 우선 '국제화'라는 개념에 대해서 설명했다. 국제화는 현지화와 유사하게 사용되고 있긴 하지만, 그보다는 현지화를 좀 더 빠르게 적용할 수 있도록 계획하거나 이행하는 과정이다. 번역이 되서 텍스트가 길어지는 것을 대비해서 UI에 여유 공간을 남겨둔다던가, 텍스트에 유니코드 지원을 할 수 있게 한다던가 하는 것들이 국제화의 사례인 셈이다.
듀랑고의 국제화 프로젝트는 한 단계 나아가서, 오는 5월 글로벌 정식 런칭과 더불어 그 이후의 현지화 프로세스를 원활히 하는 것에 목표를 두었다. '듀랑고'는 현재 영어, 중국어(번체), 독일어, 프랑스어, 러시아어, 스페인어, 포르투갈어, 태국어, 인도네시아어 총 9개의 언어로 번역 및 현지화를 진행, 글로벌 출시를 준비하고 있다. 이를 단순히 지금 나온 콘텐츠를 번역하고 현지화하는 것뿐만 아니라, 앞으로 작업하기 위한 파이프라인을 구축하고자 하는 것이다.
'듀랑고'의 현지화 파이프라인은 우선 서버와 클라이언트에서 텍스트를 추출하는 것부터 시작이 된다. 그 두 곳에서 POT 포맷의 파일로 추출하는데, 프로그래머들에게 부탁해서 텍스트 추출을 GUI로 쉽게 할 수 있도록 구축해둔 상태다.
이민지 대리는 번역에 필요한 텍스트가 단순히 일반 문장으로만 구성된 것이 아니라고 설명했다. 우선 번역 텍스트가 어디에서 추출되는 것인지 경로가 나오고, 원문이 어떤 문장인지 스크립트 안에 인용이 되어있다. 그리고 하단에는 번역 텍스트가 들어갈 자리가 나와있는 형태다.
이를 엑셀로 활용하지 않고 POT와 PO로 사용하고 있는데, 이는 Git의 기능을 사용할 때 엑셀보다 두 포맷이 호환이 좋기 때문이다. 또한 PO 에딧을 통해서 좀 더 직관적이고 심플하게 보는 것도 가능하다. 그리고 PO포맷은 컴파일도 쉽다는 장점이 있다. 실제로 듀랑고 현지화팀에서는 이를 활용하고 있으며, 그 외에도 다양한 툴이 있는 만큼 찾아서 활용하는 것을 권했다. 아울러 소스 작업을 바로 할 수 있도록 Gettext 체계를 활용했다고 덧붙였다.
듀랑고팀에서는 그런 식으로 파일을 추출한 뒤에는 새 번역 만들기를 눌러서 번역을 추가로 진행할 수 있도록 구축했다. 그렇게 해서 새로운 번역을 넣고 이를 검수하는데, 이 과정에서 여러 버전이 생기게 된다. 이를 효율적으로 관리하기 위해서 Git, 그 중에서 GitLab을 쓰게 된 것이라고 이민지 대리는 설명했다. 그리고 번역 및 검수가 다 끝나면 개발자는 최종 POT 파일을 서버와 클라이언트에 적용, 현지화가 완료가 된다. 이것이 현재 듀랑고의 현지화 프로세스라고 덧붙였다.
■ 듀랑고 현지화에서 Git, 어떻게 쓰고 있을까? - Git의 다섯 가지 기능을 기억하자
이민지 대리는 현지화 과정에서 Git을 활용하는 방법을 커밋-브랜치-체크 아웃-디프-머지의 다섯 가지로 소개를 했다. 우선은 Git을 활용하기 위해서는 사용하는 유형의 Git, 즉 듀랑고팀에서는 GitLab에 해당 POT 파일을 올리게 된다. 이를 Git에서는 커밋이라고 지칭한다.
커밋은 단순히 작업을 저장하는 것에 그치는 것이 아니라, 수정한 사항을 노트로 남겨 놓을 수도 있다. 그리고 이렇게 남겨진 수정 사항들을 쭉 훑어볼 수도 있다. 즉 파일이 어떤 식으로 버전이 바뀌고 있는지 꾸준히 추적할 수 있다는 것이다. 이를 GUI로 쉽게 볼 수 있는 확장 프로그램도 있는데, 듀랑고팀에서는 Git Extensions를 활용하고 있다. 기존에는 판본이 바뀔 때마다 파일이 계속 쌓이지만, Git에서 커밋을 하면 파일의 수 자체는 변하지 않으면서도 변경 내력을 쉽게 확인할 수 있다는 장점이 있다.
그렇다면 여러 언어를 동시에 작업할 때는 어떻게 진행하게 될까? 이런 상황에서 활용하는 Git에서는 브랜치라는 기능을 활용한다. 브랜치는 가지라는 뜻 그대로 하나의 파일에서 독립적으로 어떤 작업을 진행하기 위한 개념이다. 브랜치 기능을 써서 각 언어별 브랜치를 만들면, 원래 POT 파일이 아닌 각 브랜치 간에는 서로 영향을 주지 않는다. 즉 동일 POT 파일을 기반으로 각 브랜치별로 따로따로 동시에 작업을 하는 것이 가능하다. 이 POT 파일을 올려놓고, 각 브랜치에서 브랜치로 옮기는 과정을 Git에서는 체크아웃이라고 일컫는다.
Git을 활용해서 번역과 현지화를 진행하는 과정도 번역-검수-적용의 3단계로 진행이 된다. 우선 올라온 POT에 추가로 작업해야 하는 부분을 입력하고, 이를 브랜치 기능을 활용해 각 언어별 버전을 나눈다. 그렇게 하면 원문과 예전에 번역한 부분, 그리고 아직 번역이 적용되지 않은 원문이 나오는데 이를 보고 번역 담당자들이 초벌 번역을 하게 된다. 이때 번역 담당자들은 기존에 남아있던 커밋 메시지를 통해서 어떤 식으로 수정이 이루어졌나 확인을 하고, 그에 맞춰서 번역을 진행한다.
이 작업이 완료되면 번역 담당자들이 커밋을 하는데, 이때 파일명이 바뀌면 안 된다고 이민지 대리는 주의를 줬다. Git에서 커밋과 커밋 사이에 어떤 변화가 있는지 확인할 수 있는 '디프'라는 기능을 지원하는데, 이 기능은 동일한 파일 내에서 변화가 일어났을 때에만 사용이 가능하기 때문이다. 만약 파일명이 바뀌게 되면 동일한 파일이 이름이 바뀐 게 아니라 새로운 이름의 파일이 추가됐다고 인식을 하게 된다. 즉 디프 기능을 활용해서 변경 사항을 체크할 수 없는 만큼, 파일명은 절대 바꾸지 말 것을 재차 강조했다.
디프로 내용을 활용한 뒤 추가로 수정을 하고, 커밋을 하게 되면 검수 작업까지 완료가 된다. 최종적으로 모든 과정이 끝나면 원래 파일인 마스터 브랜치에 머지, 즉 병합하는 것으로 Git을 활용한 현지화 작업은 완료가 된다. 머지를 하게 되면 원래 있던 파일은 그대로 유지되고, 새롭게 추가되거나 변경된 걳들도 바로 반영이 되기 때문에 이를 재차 확인할 필요가 없다.
이민지 대리는 Git의 이 다섯 기능을 더욱 효율적이고 다방면에서 활용할 수 있다고 설명했다. 통상 번역 과정에서는 번역이 끝나기 전까지 검수자는 대기하는 식이었다. 뿐만 아니라 검수자들이 작업하는 중에 번역 담당자들이 초벌본에서 수정을 해야 한다고 요구하면 수정본이 만들어질 때까지 대기해야 했다. 그렇지만 Git에서는 이를 브랜치로 나눠서 따로 작업하고, 나중에 머지하는 식으로 동시 작업이 가능하다.
다만 이런 병렬 작업에서는 중간에 동일한 단어를 다르게 번역하는 일이 발생하기도 한다. 이와 같은 일을 Git에서는 컨플릭트라고 하는데, 이때는 그 중 어떤 단어를 고를지 선택한 뒤에 머지를 하는 식으로 처리하면 된다고 설명했다.
실제로 번역 과정에서 여러 작업자가 동시에 진행하게 되면, 용어를 서로 다르게 번역하거나 누락하는 일이 종종 있다. 그렇지만 Git에서는 머지 과정에서 이를 체크하고, 모든 작업 과정이 Git 저장소에 남아있기 때문에 관리하기가 한결 수월하다는 장점이 있다.
이민지 대리는 현지화 작업을 해온 입장에서 처음에 Git을 접하기 두려웠다고 설명했다. 프로그래머들이나 쓰는 것 아니냐는 인식도 있었고, 그런 것을 그 분야의 문외한인 자신들이 사용할 수 있을까 걱정이 됐기 때문이다. 업무 과정도 달라지는 데다가, 자신이 전혀 접하지 못하는 것을 새로 익혀야 한다는 부담감도 있었다.
그런 두려움을 이겨내고 채택한 Git은 작업에 소모되는 시간을 단축하는 데 큰 도움이 됐다고 이민지 대리는 설명했다. 무엇보다도 기존에 번거로웠던 파일 관리나 변경점 확인, 수정 과정에서 드는 리드 타임 문제가 해결이 됐기 때문이다. 앞으로도 기술이 발전하면서 어떤 새로운 시스템이나 도구가 등장할지 모르지만, 업무를 효율적으로 진행하기 위해서는 이런 것들도 체크할 필요가 있다고 하면서 강연을 마쳤다.
Ruudi@inven.co.kr