신제품보다 업그레이드 제품 번역이 더 어려운 이유 (27)

소프트웨어 국제화가 가장 쉬운 것은 신제품이다.

국제화의 여러 분야도 마찬가지이지만, 번역은 특히 신제품 개발 시 쉽게 접근하지만, 유지보수 때 쓴맛을 본다.

번역 아키텍처와 프로세스는 신제품이던지, 업그레이드 제품이던지 항상 쉽고, 빠르고, 비용을 최소화 해야 한다.

소프트웨어 개발 시 흔히 벌어지는 사례를 보자.

메시지가 1,000개쯤 되는 소프트웨어를 신규로 개발하고 있다. 번역해야 하는 언어는 10개이다.

개발자는 번역이 필요한 메시지를 소스코드에 적으면서, 별도의 번역 파일에 메시지를 적어 줘야 하는 방식으로 개발을 하고 있다. 

개발을 완료하고 1,000개의 메시지를 10개의 언어로 번역을 하여 개발이 완료되었다. 쫑파티도 했다.

이제 소프트웨어를 업그레이드 할 차례다.

메시지를 300개쯤 추가하게 되었다. 이것은 번역 파일에 300개를 추가하면 된다.

이 때 개발자는 새로 추가할 메시지가 기존의 번역 파일에 있는지 검색을 해야 한다. 원래 있던 메시지가 아니라도 오늘 아침에 다른 개발자가 추가했을 수도 있다.

만약에 내가 메시지를 삭제하게 되었다. 그러면 번역 파일에서 그냥 삭제를 하면 되는가? 그 메시지는 나만 쓰는 것이 아니고 다른 개발자가 다른 소스코드에서 쓰고 있다면?

그럼 소스코드 전체를 뒤져서 해당 메시지가 다른 곳에서 쓰이고 있는지 찾아봐야 하는가? 

이것도 완벽하지 않다.

때마침 다른 개발자가 해당 메시지가 번역파일에 있는 것을 알고 그 메시지를 이용해서 개발하고 있고, 아직 소스코드를 등록하지 않았다면?

이처럼 메시지를 새로 추가할 때, 삭제할 때 모두 문제가 된다.

이제 필요 없는 메시지라고 삭제를 하는 것도 문제가 된다.

메시지를 삭제했는데, 다음 버전에서 해당 메시지가 다시 쓰일 수도 있다. 그래서 메시지를 다시 추가하면 옛날에 번역했던 메시지를 다시 번역해야 한다. 비용과 시간의 낭비가 아닐 수 없다.

그래서 이런 문제가 전혀 없는 방식의 번역 아키텍처와 프로세를 사용해야 한다. 전 과정은 자동화 되어야 한다.

구체적인 방법들은 추후에 자세히 다루겠다.