이제부터 소프트웨어 국제화에서 가장 중요한 번역과 관련된 얘기를 시작하려고 한다. 번역은 다뤄야 할 주제가 광범위하므로 여러 회차를 거쳐서 다루게 될 것이다. 필자는 수십 개의 회사의 소프트웨어 국제화 방식을 조사했으며 대부분의 회사가 수많은 번역 함정에 빠져서 어려움을 겪고 있는 것을 보았다. “변역 함정”이란 소프트웨어를 번역하면서 비효율적인 방법에 쉽게 빠져서 허우적거리는 것을 말한다. 번창한 회사일수록 어려움은 더 커졌다. 그래서 어떻게 하면 번역 함정에 빠지지 않고 효율적인 번역을 통해서 소프트웨어 국제화를 성공할 수 있는지 공유를 할 것이다.
가상의 A사는 전세계 수십 개의 국가에서 사용하는 서비스를 개발하고 있다. 해당 서비스를 개발하는 소프트웨어 엔지니어는 수십 명에 이른다. 해당 서비스는 10개 언어로 번역이 되어서 서비스가 되고 있다.
그러다 보니 개발자는 소스코드에 번역이 필요한 메시지 하나를 추가하려고 해도 매우 복잡한 절차를 밟아야 한다. 소스코드에 “Hello”라는 메시지를 넣어야 한다고 가정해보자. A사의 개발자는 다음과 같은 프로세스를 밟아야 한다.
1. “Hello”에 대응하는 심볼을 정한다. MSG_HELLO로 정했다.
2. 소스코드에는 TranslateMsg("MSG_HELLO")라고 번역 함수를 이용해서메시지를 입력한다. 이 단계에서 소프트웨어는 MSG_HELLO라고 출력된다.
3. 개발자들이 공유하는 엑셀 파일에 “MSG_HELLO” 항목을 추가하고 영어 칸에 “Hello”를 입력한다. 이때 엑셀 파일은 여러 개발자가 공유를 해야 하기 때문에 소스코드 관리시스템이 아니고 파일서버에 보관하고 있다.
4. 해당 엑셀 파일에는 10개 언어별 컬럼이 있는데 각 언어별로 이번 업데이트에 추가된 메시지를 10개의 엑셀파일로 추출하여 언어별 번역가에게 번역을 의뢰한다.
5. 번역이 완료된 후에 엑셀파일은 각 언어별 메시지 파일로 저장한다. (예, Korea.ini, Japan.ini)
6. 이제 소프트웨어에서는 “MSG_HELLO” 대신 “Hello”가 출력된다.
가상의 A사의 예를 들었지만 현실과 전혀 동떨어진 얘기는 아니다. 위 프로세스를 보고 별일 아니라고 생각할 수도 있고 복잡하고 불편하다고 생각할 수도 있다. 아직 국제화된 소프트웨어를 개발해보지 못한 개발자나 한두 개 언어를 추가로 개발해본 개발자는 소프트웨어 번역의 복잡함을 과소 평가할 수도 있다.
하지만 소프트웨어는 지원해야 하는 언어가 많을수록 소프트웨어 규모가 클수록 개발팀의 규모가 클수록 업데이트 주기가 잦을수록 번역의복잡도는 기하급수로 증가를 한다.
자연스러워 보이는 위 예도 이미 수많은 함정에 빠져서 매우 비효율적인 프로세스를 밟고 있는 상태다. 물론 소프트웨어가 잘 안 팔려서 사라져가고 있다면 번역의 복잡성 함정에 빠져서 문제가 되고 있다는 사실 조차 모르고 지나간다. 하지만 2,3개 지원하던 언어를 10개 이상으로 늘려서 지원하게 되고 소프트웨어가 계속 업그레이드되어서 규모가 몇배 커지고 개발자도 많이 투입이 된다면 그 때서 번역 프로세스로 인한 비효율이 눈에 띄게 커졌다가는 것을 발견하게 된다.
그때는 이미 소프트웨어 번역 아키텍처를 바꾸기 어려운 상태이기 때문에 비효율을 개선하기는 매우 어려워진다. 번역은 실제 메시지가 현지 문화에 얼마나 잘 맞게 번역이 되었는지도 중요하지만 어떤 메시징 아키텍처를 사용하는지도 중요하고 번역 프로세스도 매우 중요하다.
흔히 RC 파일을 사용하기도 하고 자체적으로 제작한 메시징 함수를 사용하기 위해서 INI파일이나 별도의 메시지 파일을 포맷을 만들어서 사용하기도 한다. 이 과정에서 중간 파일로 엑셀파일을 사용하기도 하고Database를 사용하는 회사도 있다. 개발자가 번역이 필요한 메시지 하나를 소스코드에 추가하기 위해서 복잡한 절차를 밟아야 하는 경우가 많다.
이런 복잡한 절차의 불편함을 당연하게 생각하고 개발하는 개발자도 있는가 하면 이를 개선해보고자 여러 자동화 툴을 만들면서 노력을 했지만 쉽게 개선되지 않음을 경험하기도 한다.
앞으로 소프트웨어 번역의 원칙과 원리를 중심으로 가장 효율적으로 번역을 하는 방법을 공유하도록 하겠다.
댓글 없음:
댓글 쓰기