다국어 대응은 마감에 영향을 끼친다

프로젝트 매니저가 알아야 할 97가지 - 세 번째 이야기

by - Pavel Simsa
지난 10년간 소프트웨어 개발과 중앙 집중화 사업을 해왔고 그중 5년은 기업용 보안 소프트웨어 프로젝트 및 프로그램을 관리했다. 그가 참여한 프로덕트들은 10~17개 언어로 동시 발매되었다. 2008년에 PMP®인증을 얻었고 최근 몇 년간 PMBOK®Guide의 베스트 프랙티스를 접목한 애자일 방법론 적용을 위해 노력하고 있다.

다국어 작업은 어떤 언어가 가장 시간이 많이 걸릴까요? 정답은 모든 언어입니다.

다국어 대응이 필요한 제품은 새로운 리스크와 제약이 생깁니다. 기술적인 부분도 있고 기술 외적인 부분도 있습니다. 예를 들어 일본어 버전을 포함해서 발매해야 한다면 적절한 폰트를 지원해야 합니다. 만약 폰트가 지원되지 않는다면 기능이 완벽하게 동작한다 해도 그 제품은 의미가 없습니다.

폰트의 호환성이란 건 관리할 수 있는 영역이 아닙니다. 당신과 당신 팀은 이러한 주의 사항을 코딩에 들어가기 전에 충분히 검토하고 미리 인식해두어야 합니다. 개발팀의 개발 경험이 이러한 문제를 국제적 표준에 준거해서 커버할 수 있는지 확인해야 합니다.

보통 다국어 대응(일본어, 스웨덴어, 독일어 등)은 어느 일정한 간격을 갖고 베이스 언어의 개발이 진행된 후 함께 실시됩니다. 그 간격은 수일 혹은 수주일, 때에 따라서는 수개월이 될 수도 있습니다. 그러나 어느 시점에서는 번역이 베이스 언어에 "근접"해 있어야 합니다. 테스트와 리뷰는 아래 내용을 확인해야 합니다.

베이스 언어에 있는 모든 단어들이 번역되어 있을 것.
번역된 것이 베이스 언어의 의미와 정확히 일치할 것.
번역된 것이 화면에 온전히 표시될 것.

여기에 중요한 포인트가 있습니다. 베이스 언어 제품이 완성되어 릴리스 된 후에 위 테스트가 진행될지도 모른다는 점입니다. 이러한 시차를 갖고 개발이 진행되다 보면 베이스 시스템을 변경해야만 해결할 수 있는 어려운 문제가 적어도 하나는 발견되기도 합니다. 베이스 시스템의 변경이 비록 간단하고 (수초의 코딩으로 끝나는) 비교적 단순하고 리스크가 낮더라도 그 수정으로 인해 모든 언어의 시스템들 다시 테스트해야 한다는 걸 잊어선 안됩니다.

이 테스트에 추가로 시간이 들고, 때에 따라선 수천 달러나 되는 불필요한 비용을 발생시키기도 합니다. 번역 작업을 외부에 위탁하고 있다면 더더욱 그렇습니다. 경험이 적은 프로젝트 매니저가 자주 하는 실수는 단순합니다. 작은 변경이 일으키는 영향과 중대함을 얕잡아 보는 것입니다. 이를 피하기 위해 아래 두 가지를 유의해서 진행해야 합니다.

일정 말미에 "다국어 대응"이라는 버퍼(예비기간)를 준비합시다.
일정의 말미란 프로젝트 전체 일정에서 베이스 언어의 시스템 작업이 사실상 끝날 때를 의미합니다. 마감일 이후에 발생한 변경은 엄격하고 명확한 기준을 두고 그 기준에 어긋나면 변경을 해선 안됩니다. 변경이 발생할 때마다 다른 언어들도 동일한 변경이 이루어지도록 합니다.
기능의 품질관리는 베이스 언어 시스템의 품질 리뷰와는 별도로 이루어지도록 태스크를 구성해야 합니다.
베이스 언어의 모든 단어를 교정용 표에 카피해 리뷰하는 방법은 아주 간단히 실행할 수 있는 방법입니다. 제품을 돌려보며 틀린 부분을 찾아내는 것보다 미리 표를 통해 확인하면 작업 시간을 크게 단축시킬 수 있습니다.