共用方式為

국제화(i18n, internationalization): (2) 누가 쓰든 되기는 돼야지~

  • 發行項

내가 만든 소프트웨어는 번역을 고려하지 않았으니까 죄송합니다...라고 하는 것으로 일단 변명으로 때웠다고 한다손 치더라도 문제는 여기서 그치지 않습니다. 외국에 사는 교포라면 어떨까요? 혹은 다른 언어를 좋아하는 자국인이라면? 혹은 번역은 안해도 되니까 쓰고 싶다는 외국인이라면? 아니면 번역과 상관 없이 다른 언어를 입력하고자 하는 고객이라면? 아니면...끝없이 이어집니다. 이 시대에 소프트웨어로 돈을 제대로 벌기 위해서는 세상에서 가장 뛰어난 아이디어로 뭔가를 만들었다고해서 그것만으로 돈방석에 올라가는 케이스는 지구 전체 인구 중에서 몇 안되는 사람들 뿐입니다. 일반적인 소프트웨어 비즈니스를 하고자 한다면 위에서 한 고민들을 해결을 해야합니다. 얼마나 많은 고민들이 도사리고 있는지 이를 전부 해결할 길은 없습니다.

혹은 난 A,B,C 나라에만 제품을 판매할꺼야, 라고 하더라도 그 나라의 사용자 행태에 따라서 어디에 가중치가 가느냐는 달라지게 됩니다. 예를 들어, 어떤 나라에서는 영어권이 아닌데도 꽤 큰 %가 영어 OS를 기반으로 사용한다고 가정하면, 영어 OS에 해당 언어 제품을 설치하는 시나리오가 제데로 작동하는가를 확인해야합니다. 어떤 나라에서는 한가지 언어만을 사용하지 않는 케이스도 많은데 이 중에서 어느 것을 지원해야할지도 연구해야합니다. 그 나라에서는 어떤 툴을 굉장히 많이 쓰는데, 이와 호환이 되지 않는다면 또 문제겠죠. 법적인 규제가 있다면 이를 준수하는 것도 일일 것입니다.

일반적으로 소프트웨어의 문제를 고치는데 드는 비용은 시간이 갈수록 늘어납니다. 애초에 설계할때 문제가 제거되었다면, 고치는데에는 비용이 들지 않겠죠 - 하지만 완벽한 소프트웨어는 없기에, 되도록이면 미리 이를 해결하기위해 노력하지요. 개발하다가 고치면 개발자가 코드를 다시 들여다보는 시간지 줄어들 가능성이 크겠죠. 출시전에 찾았다면 출시후에 발생하는 문제비용이 줄어들 것이겠습니다. 하지만, 출시후에는? 다양한 시나리오들을 사용자분들이 직접 겪고 계시니 굳이 설명하지 않아도 알고 있으리라 생각됩니다. 국제화(https://msdn.microsoft.com/en-us/goglobal/bb688112.aspx)도 마찬가지로 미리 해결하면 비용을 줄일 수 있는 한가지입니다.

회사마다 가는 곳마다 약간씩 의미가 다르기 때문에 그때그때 문맥에 맞게 생각해서 이해를 해야합니다만, 일반적으로 현지화(localization, l10n)가 되어있지 않더라도 세상에 누가 쓰든 쓸 수 있도록 만드는 것을 세계화(globalization)이라고 합니다. (단어를 국제화/세계화/현지화로 번역하고 나니까 그 의미가 잘 와닿지는 않습니다만, 역시나 이는 영문 용어를 기준으로 한 분류라서 쉽지가 않습니다^^) 국제화(i18n)도 단어 자체로는 다른 것들과의 의미를 구분하기 힘든 용어이기 때문에 "World-Readiness"라는 용어로 바꾸고 있는 추세입니다만, 이를 번역하면 "세계 시장 대응성 https://msdn.microsoft.com/ko-kr/goglobal/bb688161.aspx"이라는 또 애매한 용어가 되기 때문에 참 쉽지가 않습니다. 일단은 세계화(globalization)로 돌아가면 그 의미는 소프트웨어 자체가 현지화되었건 되지 않았건 사용할 수 있다는 의미와 현지화를 하기 위한 요소(localizability)가 갖춰져있다는 의미를 모두 포함합니다.

세계화(globalization)이라는 문제는 사실 모든 언어를 사용하여 제품을 테스트해보지 않고서는 보장하기 힘들고 이를 위해서는 또한 만만치 않은 비용이 들겠지요. 그래서, 소프트웨어 제품이 100% 모든 시장에서 돌 수 있도록 만든다는 의미 보다는 문제가 발생할 때에 해결할 수 있는 방안을 마련해두는 것을 포함하기도 합니다. 위에서 이야기한 것처럼 마케팅 조사를 통해서 올바른 수치를 가지고 소프트웨어를 설계하여 나올 수 있는 문제의 큰 %를 해결하는 의미도 있구요. 소프트웨어 설계 자체를 잘못하면 해결할 수 없는 문제에 봉착하기도 하기 때문에 설계시에도 이를 고려해주어야합니다.

아시다시피 소프트웨어 세상의 처음은 무조건 영어였습니다. 영어는 알파벳 26자면 문제가 없는 언어고, 대소문자 합치고 부호 숫자 전부 넣어도 256개도 안되는 수 였습니다. 이것이 컴퓨터에서 소프트웨어가 문자를 표현하고 주고 받고 저장할 수 있게 설계한 것입니다. 이 잘못된 설계는 또다른 잘못된 설계를 낳게 되죠. Windows가 일본시장에 가기위해 땜질한 코드페이지나 ShiftJIS 혹은 우리나라도 KSC 표준, 등등, 모두가 국제화를 생각하지 않은 자국 언어만을 위한 땜질들이었습니다. 다행히 이제는 유니코드가 세상에 있는 모든 언어를 표현할 수 있는 단일 방식을 제공하고자 근접해가고 있는 중입니다만, 이를 지원하거나 지원하는 것을 확인 하는 일은 꽤나 고통스런 일입니다. 기존의 방식을 바꾸기도 해야하거니와 ASCII 방식을 사용하는 것에 비하면 개발도 좀 더 리소스가 필요하고...

하지만, 잘 계획만 하면 모두가 나중에 ROI로 크게 돌아오게 되는 것이기 때문에 점차 투자가 늘어나고 있는 것이겠지요. 어제도 세계화 컨퍼런스에 갔다 왔는데, 모두들 하는 이야기가 "잘못 계획을 하거나 무분별하게 시장 고려를 하면" 세계화는 돈먹는 하마 취급을 면할 수가 없다는 것이었습니다. 중요하지만, 잘못해서 나중에 되려 정작 중요한 때에 돈이 없어서 못하는 일이 발생한다는 것이죠. 그래서, 이를 해결하기 위한 실마리는 세계화를 통해서 소프트웨어 자체를 유연하게 만드는 것입니다. 누가쓰든 된다면 매번 현지화를 할때도 해결할 문제들의 범위가 많이 줄어들게 됩니다.