Blog - Title

철수네 소프트웨어 세상 [마이크로소프트 지점]

Blog - Post Feedback Form(CAPTCHA)
  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

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

    • 0 Comments

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

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

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

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

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

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

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

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

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

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

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

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

    - 철수(charlz) (20100623)

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

     

  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

    Silverlight 4 출시!

    • 0 Comments

    여기서 설치 혹은 업그레이드 하세요!

    역시나 MIX10 행사의 시작과 함께 Silverlight 4가 출시되었습니다. 출시 소식은 Silverlight 사이트에서 확인하실 수 있습니다. 이번 Silverlight 4(런타임)는 Windows 버젼은 42개 언어로, Mac 버젼은 18개 언어로 번역되어 동시 출시되었습니다. 매번 강조해도 지나치지 않은 사실은 동시에 여러개의 언어를 지원하도록 출시(sim ship)하는 것은 꽤나 복잡하고 스케줄을 맞추기가 쉽지 않은 일입니다. 이번 동시 출시를 위해서 열심히 뛰어다니신 분들께 축하를 전합니다. 아직 툴과 문서들의 한국어를 포함한 현지화 제품들의 출시가 남아서 쉬지는 못하겠지만요.^^

    Visual Studio 2010에도 Silverlight 지원이 들어가 있지만, 이는 Silverlight 3를 기준으로 출시되었기 때문에 Silverlight 4용 Tools(RC)를 별도로 설치해야합니다. Tools를 설치하면 SDK가 같이 설치되지만, 혹시 링크가 필요하시다면 여기서 다운로드 받을 수 있습니다. Visual Studio 2010의 무료버젼인 Express 버젼을 사용하실 수도 있는건 아시죠?^^ Silverlight 바이너리에 들어가있지 않은 부가 컴포넌트들은 Silverlight Toolkit에서 찾으실 수 있습니다. 온라인 문서를 확인하거나 혹은 오프라인으로 다운로드 받을 수 있습니다(영문). Expression Blend 4는 정식버젼이 출시되지 않았기 때문에 RC버젼을 다운로드해 사용해보실 수 있고, WCF Ria Services를 사용하신다면 여기에서 관련 내용을 찾으실 수 있습니다.

    새로운 기능을 한눈에 볼 수 있도록 버젼별 기능 비교 차트의 Silverlight 4의 추가 내용을 옮겨봅니다:

    Local Fonts
    Printing
    WCF RIA Services
    Managed Extensibility Framework (MEF)
    Webcam
    Microphone
    Official Support for Google Chrome
    Output Protection for audio/video
    Multicast networking
    Offline DRM
    Trusted Applications (extended sandbox)
    IDispatch COM Interop
    Group policy object support
    Full keyboard in out-of-browser for trusted applications
    Cross-domain network access for trusted applications
    Custom window chrome
    Out of browser window settings (position, size etc.)
    Web Browser Control and Web Browser Brush
    Notification Toast
    Right-to-Left / BiDi Text

    조금 �� 자세한 내용을 찾으시려면 Silverlight 홈페이지의 새기능 목록을 보시거나, 각 새 기능을 설명한 MSDN 문서에서 찾을 수 있구요, 기존의 Silverlight 3 페이지를 Silverlight 4로 마이그레이션하시려면 여기Tim Heuer의 설명을 참조하시구요.

    Windows Phone에서의 Silverlight 개발에 관한 내용은 여기, 그리고 문서는 여기에서 찾을 수 있습니다.

     

  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

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

    • 0 Comments

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

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

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

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

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

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

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

     

  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

    Visual Studio 2010, .NET Framework 4 그리고 KIN?

    • 2 Comments

    모든 분들이 아시다시피 Visual Studio 2010과 .NET Framework 4가 어제 드디어 출시되었습니다. 자세한 소식은 이미 스캇거스리를 포함해 많은 분들이 어제 블로깅 했으니 참고하시면 좋을 것 같습니다.

    비록 영문판은 출시가 되었지만, 아직도 저희 팀은 한국어와 일본어등을 포함한 비영어권 버젼 출시를 위해서 열심히 일을 해야합니다. 항상 그렇지만, 영문이 출시되면 제품 개발팀은 파티를 하고 다음 버젼을 위한 정비를 시작하면서 일을 덜지만, 저희 loc팀은 계속해서 몇달간 비영어 버젼 제품을 출시해야되기 때문에 정신이 없습니다. 아쉽게도 영문의 제품 품질이 좋더라도 지역화(localize)된 제품의 품질이 좋다는 의미가 아니기 때문이죠.

    그냥 포장만 다르게 한다면야 덜 힘들겠지만, 지역화는 제품의 엔지니어링과 깊게 관여되기 때문에 - 예를 들어 어떤 식으로든 문자/스트링을 사용하지 않는 곳은 없죠 - 모든 것을 다시 확인해야합니다. 또한 많은 수의 언어로 지역화가 되기 때문에 그 양도 상당합니다. 게다가 전세계에서 가장 커다란 도움말인 MSDN Library도 갱신되어야하고, 제품에 포함되어야합니다. 아무리 쉬운 작업이라고 하더라도 양이 많아지면 복잡성은 기하급수적으로 늘게 마련이죠.

    Visual Studio 2010과 .NET Framework 4는 Microsoft에서 출시하는 제품들 중에서도 큰 것에 속하는 기술 집합체입니다. 게다가 다른 제품을 개발하고 실행할 수 있는 플랫폼이기 때문에 더더욱 주의를 해야하는 것은 물론이죠. 영문판이 나왔는데 왜 한글판은 이렇게 늦게 나오느냐는 불만은 항상 있어왔지만, 계속해서 그 간격은 줄어왔습니다. 앞으로도 줄 것이라 생각되지만, 이렇게 큰 괴물이 뿜는 엄청난 양의 번역량만 생각해도 동시 출시를 향한 길이 얼마나 험난한 것인지 상상이 가실 것입니다.

    이번 출시는 또한 최대한 영문 버젼과 퍼포먼스 델타가 크지 않는데에 투자를 한 출시이기도 합니다. WPF기술로 이전했기 때문에 영문 버젼도 베타까지만하더라도 속도가 쓰기 힘든 정도였지만, WPF로 만든게 맞는지 긴가 민가할 정도로 출시되는 버젼은 큰 퍼포먼스 향상이 있었습니다. 현재는 영문 리소스를 얻어오는 방식과 그 이외의 리소스를 얻어오는 방식이 다르기 때문에 퍼포먼스에 있어서 동일할 수는 없겠지만, 엇나가지 않도록 주의를 했기 때문에 이전보다 나은 제품을 만나실 수 있을 것 같습니다.

    여담이지만, 제품 출시와 동시에 핑크라는 코드명으로 개발하던 폰 제품이 KIN이라는 정식 명칭을 가지고 발표되었는데요, 우리나라에서는 KIN이 즐을 눞혀놓은 형상이기에 이를 재미나게 바라보는 듯 합니다. 어떤 분들의 염려가 Visual Studio 2010과 .NET Framework 4의 PR이 분산돼서 안좋지 않겠느냐고 하시는데, 타겟 마켓이 상당히 다르기 때문에 기우가 아닐까 하는 생각을 해봅니다. 되려 뭔가 커다란게 2가지나 터지니까 2배로 좋을 수도 있는 것이 아닐까요.^^

    언제나 그렇듯, 질문이 있으시면 메일이나 코멘트 주세요~ (제가 답할 수 있는 것이라면 얼마든지요!ㅎㅎㅎ)

     

  • 철수네 소프트웨어 세상 [마이크로소프트 지점]

    국제화(i18n, internationalization): (1) 그거 번역하는거 아냐?

    • 1 Comments

    무슨일을 하냐는 질문에 국제화(i18n, internationalization)과 관련된 일을 한다고 대답을 하면 다수가 "아~"라고 하면서도 잘못된 "아~"를 날립니다. 물어보면, "그거 번역하는 일이랑 관련된거 아냐?" 정도로 이해를 하고 있는 경우가 참 많더라구요. 글로벌시대에 그런 이해가 웬말입니까~^^ 번역일 자체도 복잡하지만, 번역일을 포함하는 현지화(l10n, localization) 이외의 여러가지를 포함합니다. 일반적으로 "번역?"이라고 하는 이유에는, IT직종에 있는데 번역 관련일을 하고 있다고 하면 뭔가 매치가 안되고 기술적으로 뭔가 관련이 적을 것 같은 느낌이 드는 이유도 있겠습니다.

    국제화란 것은 제품을 세계 시장에 내놓을 수 있도록 만드는 작업을 통칭하는 이야기입니다. 제품이 세계시장에서 사용되기 위해서는(이를 World-Readiness라고 합니다), 새로운 시장이 생겨도 언제든지 쉽게 바꿀 수 있도록 소프트웨어가 만들어져 있어야 합니다. 세계시장에 통용된다는 말이 단순히 해당 언어로 볼 수 있다는 것만 의미하는 것이 아니고, 해당 문화와 표준에 맞는지, 해당 법규제를 어기지 않는지, 해당 영역에서는 다르게 사용하고 있는지 등등의 다양한 질문들이 최소한 해결된다는 것을 의미합니다.

    번역 자체는 비용이 표준화되어있다고 하더라도, 이 번역한 결과물을 소프트웨어에 넣어서 문제없이 사용될 수 있는 과정은 표준화하기가 힘듭니다. 또한, 시장마다 다른 문제들을 매번 소프트웨어를 뜯어고쳐서 해결해야된다면 그 비용은 감당하기 쉽지 않겠죠. 또한 해당 시장 제품을 만드는데 드는 시간이 많이 든다면, 이 또한 비용과 직결된 문제겠습니다. 어떤 기능 때문에 해당 시장에서 아예 팔리지 못한다면, 투자한 비용을 버리는 것이 되기도 하겠죠. 또한, 제품이 잘 작동하는지 확인하는 테스트 과정은 또 어떻게 해야할까요, 모든 기능을 해당 언어로 다시 봐야할건데 말이죠. 사실 많은 것이 이렇게 비용와 예산과 결부가 되어있기 때문에, 글로벌한 소프트웨어 비즈니스를 하는 것이 알고보면 쉽게 할 수 있는 일이 아닌 것이 되어버렸습니다.

    국제화 작업은 1. 번역/현지화(localization) 2. 번역가능한 소프트웨어(localizability) 3. 번역이 안돼있어도 어디서든 사용할 수 있는 소프트웨어(globalization) 4. 해당 시장에 맞게 모든 것이 제대로 적응된 소프트웨어(market customization) 이렇게 4가지의 요소를 가집니다.

    - 소프트웨어를 만든다면 꼭 영어가 아니라고 하더라도 해당 소프트웨어를 만드는 사람의 언어로 만드는 것이 가장 효율적일 것입니다. 그런 이유로 그것을 다른 언어를 사용하는 곳에 가져가서 사용하려면 번역은 필수적인 요소입니다. 번역일 자체를 해본 분들은 아시겠지만, 번역 작업도 굉장히 어렵고, 계속된 번역을 위한 용어를 통일화하는 것, 정의하는 것 또한 어렵고, 원어와 1:1로 대비되는 용어가 없는 경우도 엄청나게 많고, 또한 사람이 번역하기에 교정/감수를 하는 일 자체도 많은 리소스를 요하게 됩니다. 또한, 번역을 위해서는 소프트웨어의 어느 부분을 번역하는 것이냐에 따라 다른 문맥을 가지게 되므로 완전히 다른 의미로 돌변하는 경우도 많습니다. 번역을 할때는 기능을 모두 사용할 줄 아는 사람이 하면 좋겠지만, 일반적으로 그렇게 이루어지지 않습니다(시간이 엄청나게 걸리겠죠). 예를 들어서 제품명인 "xxx폰"을 "xxx전화"라고 번역해버린다면, 웃긴 사태가 벌어지겠죠.

    - 번역을 해놓았다면 이 자료를 해당 소프트웨어가  읽어들여서 사용해야합니다. 소프트웨어에서는 어떤 특정 언어를 편애해서 읽어들이는 것이 아니기 때문에, 인코딩도 맞아야하고, 문자들이 올바르게 표시가 되는지도 정확해야하고, 각기 다른 크기의 문자들로 바뀌면 잘리거나 잘못 나오지 않도록 해야하고, 또한 사람이 만든 소프트웨어이기 때문에 빼먹은 부분이 없는지도 확인해야하는 등 수많은 작업들이 필요합니다.

    - 현지화가 미처 안된 시장이라고 하더라도, 이를 해당 시장의 사용자들이 사용도 하지 못하는 경우보다는 사용은 할 수 있으되 현지화되지 않은 경우가 훨씬 좋은 방향이겠죠. 가장 쉽게 이해할 수 있는 예가 입력일 것입니다. 내 언어로 입력이 안된다면, (소프트웨어의 용도에 따라 다르겠지만) 이는 번역이 안된 것보다 큰 문제겠죠. 워드프로세서가 있는데 한글판이 없더라. 게다가 한글 입력도 안되더라...상상이 되죠? UI가 영어로 되어있어도 한글 문서를 작성할 수 있다면 제 구실을 하기는 하는 것이겠죠.

    - 또한 각 시장에는 시장의 요구사항들이 있습니다. 어떤 시장을 타겟으로 마케팅을 하는 경우 문제가 되는 요소가 있는 것보다는 이를 미연에 방지하는 편이 훨씬 좋은 전략이겠죠. 예를 들어서, 어떤 시장에서는 영어 알파벳이 정렬순서의 앞쪽인데 어떤 시장에서는 반드시 뒤쪽이어야한다면, 나중에 다른쪽 시장에 적응하기 위해서는 소프트웨어를 뜯어고쳐야겠죠. 미리 이를 알고 두가지 방법으로 할 수 있도록 만들어두었다면 비용이 훨씬 적게 들테구요.

    간단히 몇가지 이야기를 했지만, 이 정도만으로도 글로벌 비즈니스를 책임(?)지는 국제화/현지화가 얼마나 복잡한 것인지 느낌이 오시죠? 그거 그냥 번역하는거 아니랍니다.^^

    ...다음에 계속...

Page 1 of 127 (635 items) 12345»