Igor Vassiliev, former Senior Localization Project Manager at Adobe, offers advice.
저는 1933년부터 로컬리제이션 분야에서 근무하였습니다. 처음 대부분은 생산과 QA쪽에 관여했고, 몇개 회사를 옮겨다니다가 마침내 실리콘벨리에서 알아주는 개발사의 로컬리제이션 프로젝트에 관리자로 6년정도 일했습니다.
처음 이 일을 시작했을 때와는 많은 것들이 달라졌습니다. 아마 다른 산업 분야와 비교볼 때 가장 급격히 변화된 분야중에 하나가 아닐까 생각합니다. 하나의 방법으로 일을 처리하는데 익숙해질 때면 워크플로, 프로세스, 태스크 모두를 바꿔야 하는 신기술이 등장하는 곳이 여기가 아닌가 싶습니다. 지난 3년간 저는 이러한 변화를 두차례 겪었습니다. 어쩔때는 재미있고 확실히 유익하다고 생각되는데, 또 어쩔때는 충분히 테스트되지 않고 버그가 여전한 기술을 익혀야만 하는 주요 학습 곡선 (major learning curve)이 문제를 악화시키기도 했습니다.
위와 같은 변화는 로컬리제이션 프로젝트 비용에 영향을 줍니다. 분명히 모든 프로젝트는 고객과 벤더라는 양면을 가지고 있습니다. 고객은 가능한 비용을 줄이려고 합니다만, 기실 벤더들은 비용 절감에 대해서 크게 신경을 쓰지 않았습니다. 하지만 최근 번역회사들이 합병하고 대형화됨에 따라 이련 경향도 바뀌어 가고 있다는 것을 느낍니다. 대형 번역회사는 단기적인 이익보다는 비즈니스를 장기적으로 이어가는데 더 많은 관심을 보입니다. 그래서 저는 견적에 대해서는 논할 위치가 아니었지만, 도큐멘테이션 로컬리제이션의 비용을 획기적으로 감소시키는 협상이 가능하게 할 수 있었습니다.
우선 Translation Memory 보급이 번역비용을 낮춘 가장 주요한 요소라고 할 수 있습니다. 하지만 모든 신기술에는 돈이 듭니다. 몇년전 World Server를 도입할 때 우리는 심각한 문제가 있다는 것을 발견했습니다. 시스템엔 버그가 많았고 많은 부분에 대한 커스터마이징이 필요했습니다. 파일을 임포트, 익스포트에서 아무도 무슨 문제가 발생할지 예측할 수 없는 상황이 었습니다. 그래픽이 없어지거나 PDF나 Help 를 만들때 오류가 발생하기도 했고, 링크가 깨졌으며 인덱스가 중복되고, 탬플릿 버그도 있었습니다. 일본어를 비롯한 몇몇 언어에서 폰트 문제가 발생했으며 리뷰 서버에 리뷰 프로젝트를 만드는데도 문제가 있었고 문서 구조도 틀어지는 경우가 많았으며 심지어는 견적을 내는 것도 오류가 생겨서 프로젝트 비용을 대폭 증가되기도 했었습니다. 하지만 시스템이 수정되가면서 이런 문제들은 눈에 띄게 감소되었습니다. 또 점점 시스템에 대한 신뢰가 늘어나게 되었고, 전반적으로 사용할 수 있는 수준이 되었습니다.
비용이 늘어나게 된 또 다른 이유는 이른바 sim-ship 모델(영어 버전과 함께 다국어 버전을 동시 출시하는 것) 때문입니다. 이 경우에 생산팀은 특정 일자까지 해당 기능에 대해 아무것도 할 수 없게 됩니다. 이 부분이 가장 약한 부분입니다. 만약 그렇게 하지 않으면 다른 생산/로컬리제이션 공정에 영향을 미치게 되기 때문입니다. 우리는 sim-ship을 가능하게 하는 유일한 방법은 다국어 도큐멘테이션 핸드오프로 계획하는 것 밖에는 없다는 것을 알게되었습니다. 우선 레거시 매터리얼을 이용하고 남은 부분은 기능을 완성해 가는 것으로 스케쥴을 진행했습니다.
위 모델의 문제는 개발팀의 엔지니어가 어플리케이션에 대한 수정을 끊임없이 계속 한다는 것입니다. 심지어 특정 기능이 동작하지 않는 경우에도 다른 쪽의 변경은 계속됩니다. 그렇게되면 심각한 버그를 포함한체 제품을 릴리즈하고 이후에는 버그 수정판을 또 배포해야 하는 것이 기정화된 순서이며, 그 이후에 마니너 버그를 수정하게 될 것입니다. 하지만 이 마이너 버그때문에 문서의 많은 부분이 변경되어야 하고, 수정된 문서는 벤더에 의해 다시 로컬리제이션 해야합니다. 많을 때는 다섯번까지 해 봤습니다. 다국어 핸드오프의 재미있는 점은 벤더는 모든 것을 리뷰해야 하지만 ICE는 매번 수정을 한다는 점입니다. 리뷰어는 그리 한가하지는 않습니다. 결국 우리는 같은 컨텐츠에 대해서 여러번의 리뷰 비용을 벤더에 물어야 했습니다. 변경 사항을 적용하는데에 추가된 시간은 차치하고도 변경사항은 다시 언어 수 만큼 적용되야 합니다. 고로 나는 여전히 이 모델이 과연 비지니스에 효과가 있는지가 의문스럽습니다. 이 모델은 4,5개 언어 정도의 작은 프로젝트에 적용한다고 해도 추가비용을 감수해야 할 것입니다.
아래는 로컬리제이션 프로젝트 관리를 위해서 제가 제안드리는 몇가지 팁입니다.
-
벤더를 존중하고 업무적으로, 개인적으로 좋은 관계를 유지하십시오. 친근한 통화 몇 마디로 놀랄만한 성과를 얻을 수 있습니다.
-
벤더에서 보내는 최초 견적에 변경 사항 적용에 대한 내용이 포함되는지를 확인하십시오. 이후 진행되는 작업에서 벤더가 임으로 허가되지 않은 작업을 추가하지 않도록 확인하십시오.
-
벤더가 여럿이라면 rate을 꼼꼼히 챙길 필요가 있습니다. 벤더별로 최초 견적부터 순서대로 리뷰해야 합니다. 벤더의 프로젝트 매니저는 보통 견적을 수정하면서 실수를 많이 합니다.
-
당신이 제공하는 TM을 확실하게 하여야 합니다. 이 부분 역시 가장 실수가 많은 부분입니다. TM관리가 잘 될 수록 비용은 줄어들게 됩니다.
-
만약 sim-ship 모델에 의해 일하고 있다면 개발팀으로부터 기능 완료후 일정기간에 대한 여유시간을 확보하십시오. 그리고 그들에게 그들의 수정 작업때문에 로컬리제이션에서 발생할 수 이는 문제와 추가 비용에 대해 일러줘야 합니다. 수정작업 때문에 발생하는 핸드오프가 하나 줄어들면 추가 리뷰 사이클이 한 번 줄어들게 되고 그것은 즉 비용 절감을 의미합니다.
-
편집자나 생산팀에서 도큐멘테이션의 오류를 찾아 낼 때가 있습니다. 시간에 쫒겨 작업을 하다보면 실수를 할 경우가 있습니다. 이 경우는 바로 그 파일을 수정하여 반영하는 것 보다는 다음 핸드오프에 포함시키는 것이 좋습니다. 실수를 찾아낼 확롤은 시간이 많을 수록 높아집니다. 즉, 다음 핸드오프까지 더 많은 오류를 발견할 수도 있습니다.
댓글을 달아 주세요