국제화(i18n, internationalization): (3) 소프트웨어 번역의 비애

가장 쉬운 예로 사람과 사람간의 통역이라는 과정을 생각해보자. TV에서 국빈이 우리나라에 오면 각자 언어로 이야기를 하는 경우를 본다. 한사람이 이야기를 하면 통역사가 이야기가 끝날때까지 기다렸다가 이를 통역해서 전달해준다. 그러면 또 반대로 이야기하고 상대방 통역사가 통역을 하게 된다. 강연같은 것을 동시통역하는 경우라면 상대방이 말하는 동시에 이야기를 해도 결례가 되지 않고 또한 번역에 집중할 수 있고, 통역하는 것으로 강연자의 이야기를 방해하지 않는 구조일 것이다. 하지만, 예상컨데 위의 시나리오라면 이야기를 하고 있는데 통역사가 중얼중얼 말을 방해하고 또 말하면서 상대방의 이야기를 캐치하는 것이 쉽지 않을 것 같다. 해서, 한구절이 멈출때까지 들어준 뒤에 통역을 하는 방식이 좀 더 격식있고 효율적이라 생각된다.

위와 같은 가정을 소프트웨어를 지역화하는 과정에도 비슷하게 적용할 수 있다. 소프트웨어의 지역화를 생각하면 가장 먼저 떠오르는 것이 영문으로 된 어구나 문장들(여기서는 전산용어인 문자열이라는 용어로 통일하겠다)을 번역하는 것이겠다. 번역가들이 소프트웨어를 사용하면서 해당 위치의 글자들을 번역할 수 있다면 아주 이상적인 상황일 것이다. 하지만, 아쉽게도 소프트웨어는 그렇게 만들어지지 않는다. 동시 통역을 하기가 힘든 구조이다.

초기의 소프트웨어들은 번역을 가정하지 않았거나 소프트웨어 번역 기술이라는 것이 딱히 없었기 때문에 프로그램의 코드를 수정해야했지만, 이제는 번역을 고려한 소프트웨어를 만든 개발자/회사라면 각 문자열들은 여러개의 표나 별도의 파일들로 이루어져 있을 것이다. 개발자는 프로그램을 만들때 지정된 언어를 사용해야될 경우 지정된 문자열을 이 표/파일에서 읽어서 화면에 보여주게 되는 간단해보이는 과정이다. (물론 간단하지 않지만 일단 이에 대한 자세한 설명은 오늘의 이야기에 집중하기 위해 다음으로 미루자.)

이런 일련의 과정을 머리에 가정하고 소프트웨어에서 어떤 문자열이 수정되었거나 삭제되었거나 혹은 새로운 문자열이 추가되었다고 생각해보자. 소프트웨어를 개발하고 있는 와중이라면 문자열은 얼마든지 바뀔 수 있다.

이 문자열들이 언제 어디서 바뀌었는지 바뀌었을때 바로 번역하는 것에대한 효율을 따지면 결코 효율적이지 않다. 바뀌는 것 자체도 문제지만, 언제 바뀔지 모르는 것을 개발과정 내내 대기하고 있을 수도 없는 노릇이고, 또 매번 바뀌는 것을 생각하면 중간에 번역한 결과물은 헛수고를 한 셈이 되는 것이다. 혹은 바뀐 사실을 놓친다면 잘못된 번역 상태로 제품이 출시될 수도 있다. 추가된 문자열을 놓친 경우에는 그대로 영문으로 출력이 될 수도 있고, 개발자에 따라서 소프트웨어가 불안정해질 수도 있다.

소프트웨어의 복잡도에 따라서 3가지 번역 방법을 생각해볼 수 있겠다. 그냥 소프트웨어의 전 과정 내내 번역을 하는 모델, 소프트웨어 개발 과정중에 일정기간 번역을 할 수 있도록 지정하는 모델, 그리고 아예 개발이 끝나고나서 모든 문자열을 번역하는 모델의 3가지이다. 작고 출시 주기도 빠르고 번역량이 적은 경우에는 첫번째 모델을 사용할 수도 있지만, 일반적인 소프트웨어 회사라면 물론 비용의 문제를 생각하지 않을 수 없기에 이렇게 하기 힘들다.

가장 안전한 모델이 세번째이다. 변화가 없고 모든 문자열은 고정되어있고, 번역은 한번으로 족하기에 비용은 고정된다. 이 모델을 사용하면 가장 큰 단점 한가지가 있다. 영문(혹은 기준이 되는 언어) 버젼이 완료 되어야만 다른 언어로의 지역화를 할 수 있다는 것이다. 일단 첫 언어를 출시하고나서 다른 언어의 번역과 함께 출시 엔지니어링을 나중에 또 하게되는 과정이기 때문에, 출시 간격이 길어지게 된다. (물론, 세계화globalization은 별도로 보장을 해야하지만, 여기서는 지역화의 관점만 생각하자.)

출시 간격이 길어진다는 것은 다른 단점들을 떠나서 재미난 부수효과를 낳게 된다. 영문 버젼은 2.0이 되었는데, 한글판은 아직 1.0이 출시가 안되더라...하는 웃긴 상황. 이 웃긴 상황은 소프트웨어를 개발하는 주체에게 서비싱이라는 골치아픈 문제를 덤으로 안겨준다. 소프트웨어 지역화는 더 "비싸지는" 것이다!

이전에 영문 출시 이후에 얼마만에 다른 언어 버젼이 출시되었다더라하는 것을 자랑스럽게 이야기하는 경우를 많이 봤을 것이다. 그만큼 출시 간격을 줄이는 것이 쉽지 않은 일이었기 때문에 이렇게 회자되었지만, 정작 사용자들은 이런 상황은 알지도, 알 필요도 없는 것이기에 이해하기 힘든 부분이었다. 하지만, 엔지니어링이라는 것이 진화하지 않는다면 엔지니어링이 아니겠지. 이 세번째 모델에서 두번째 모델로 진화를 하게 된다.

두번째와 세번째 모델로 가는 경우에 보장되어야하는 것이 있다. 일단 번역을 하는 동안 문자열이 바뀌지 않는 것을 보장해야된다. 이를 보장하기 위해서 여러가지 장치들을 사용하는데, 일반적으로 문자열들은 출력을 가정하기 때문에 UI Freeze를 하기도 하고,  혹은 새로운 기능을 추가하지 않도록 Feature Freeze로 문자열의 변동을 최소화하기도 하고, 혹은 개발자들은 멈추고 버그만 잡도록 Code Freeze를 하기도 한다. 아무튼 어디선가는 소프트웨어의 개발의 일부를 멈추(Freeze)게 한다 - 멈춘다고 표현은 하지만 개발이 멈추는 것은 아니다.

결국 소프트웨어의 복잡성이 계속 늘어나는 시대에서 문자열이 바뀌는 것은 불가피하다. 이를 최소화하거나 혹은 관리하여 오류가 없도록 하는데에 비용을 들이게 된다. 국제 시장에서 파는 소프트웨어가 중요하다면, 이런 얼리는(Freeze) 투자가 없으면 안되는 것이고, 소프트웨어의 국제화는 다시 소프트웨어 자체의 개발과정과의 균형을 위해 주판알을 튕겨야하는 것 중에서 큰 한가지가 되는 것이다.

소프트웨어 번역의 비애는 이런 것이다. 이 바뀌려는 소프트웨어의 관성에 저항하여 번역을 해야한다는 것. 이 관성은 소프트웨어 개발 관련자들도 잘 알겠지만, 늘어나는 사용자들의 요구사항을 생각하면 이해하기 어렵지는 않은 것이다. 다른 언어 소프트웨어가 한글화된 소프트웨어를 접하는 경우에는 이런 비애를 가끔씩은 떠올려보면 지역화를 위해서 고군분투하는 분들에게 뭔가 에너지가 전달되지 않을까.^^

- 철수(charlz) (20100623)

국제화(i18n, internationalization): (2) 누가 쓰든 되기는 돼야지~
국제화(i18n, internationalization): (1) 그거 번역하는거 아냐?