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

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

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

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

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

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

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

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

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

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

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

- 철수(charlz) (20100623)

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

역시나 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 개발에 관한 내용은 여기, 그리고 문서는 여기에서 찾을 수 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

...다음에 계속...

위의 이미지에서 보통 보던 입력과 다른 점이 뭘까요? 관찰력이 좋으신 분들은 한눈에 알아차리시겠지만, 입력창의 커서가 일자가 아니라 위가 오른쪽으로 꼬부라진 모양이라는 것이 조금 다릅니다. 인터넷을 검색해보면, 이에 관한 수많은 글들을 보실 수 있습니다.

“커서 위에 점이 생겼는데, 바이러스인가요?” “이거 굉장히 눈에 거슬리는데 어떻게 없애나요?” “실시간 보안 툴을 설치했더니 없어지더이다.” “커서가 잘못된 것 같은데 고쳐주세요.” “키로거가 작동중인 것 같은데 어떻게 제거하나요” 등등 말이죠.

헌데 사실은 이것은 바이러스나 키로거와는 별 상관이 없는 실제 기능입니다. 어떤 기능인지 살펴보기 위해서 IE8을 사용한 약간의 실험을 해보겠습니다.

IE8의 새로운 기능 중에서 “커서 브라우징(Caret Browsing)”이라는 알면 편한 기능이 있습니다(모르면 당황스러울지도 모르는). “Caret”은 커서와 비슷한 의미로 사용되는 말인데, 커서를 사용해서 글자들을 수정할 수 있는 모드처럼 사용할 수 있는 기능입니다. 입력이 가능한 창에서는 오른쪽 키를 누르면 글자의 오른쪽으로 커서가 움직입니다. 헌데 보통 입력창이 아닌 수정이 불가능한 글씨에는 커서가 위치할 수 없죠. Caret Browsing 기능을 사용하면 이것이 가능해집니다.

지금 IE8을 사용하고 계시다면 바로 F7을 마구 눌러보세요. 그러면 (영문 Windows를 기준으로) 아래와 같은 질문을 받습니다:

Caret Browsing을 사용하기 위해서 Yes를 누릅니다. 그리고선 화살표 키들을 누르거나 마우스로 원하는 글자 근처를 클릭해보세요. 커서가 나타나서 깜빡일 것입니다. Shift와 함께 좌우 화살표를 누르면 입력창처럼 글자들을 선택할 수도 있습니다.

다음 단계로 가겠습니다. 브라우저에서 https://en.wikipedia.org/wiki/Arabic_language로 이동을 합니다. 아랍어가 섞여있는 간단한 페이지입니다:

설명에 보면 Arabic 옆에 다른 언어로 적혀있는 부분(위에 빨간 동그라미)이 아랍어 부분입니다. Caret Browsing 모드를 켜고 여기를 클릭합니다. 커서가 나타나면 오른쪽 화살표 키를 눌러봅니다. 어?

커서가 신기하게도(?) 왼쪽으로 움직이는 것을 보실 수 있습니다. 이것이 바로 BiDi(바이다이) 텍스트(여기서는 RTL 텍스트)입니다. Bi-Di는 Bi-Directional의 약자(양방향)로 우리나라나 영어권 국가들이 글을 오른쪽으로 적는 것과는 다르게 중동 쪽에서는 왼쪽으로 적기 때문에 지원하는 기능입니다. Windows가 처음에는 영어버젼밖에 없었기 때문에 오른쪽이 기준이었지만, 이제는 다른 언어들을 지원하기 위해서 양쪽방향을 모두 지원합니다. Windows 뿐만 아니라 수많은 표준들이 이를 지원하기 시작하고 있죠. 대개 오른쪽으로 적는 것을 LTR(Left to Right) 그리고 왼쪽으로 적는 것을 RTL(Right to Left)이라는 약자를 사용하여 이야기합니다. BiDi는 LTR+RTL인 것이죠.

양쪽으로 글을 적을 수 있다는 것은 어느쪽으로 글을 적고 있는 것인가를 구분하는 기능이 필요하다는 것을 의미하지 않을까요? 위에서 이야기한 커서에 달린 먼지는 바로 이 방향성을 나타내는 지시자입니다. 오른쪽에 붙어있으면 오른쪽으로 글을 쓰고 있다, 왼쪽에 붙어있으면 왼쪽으로 쓰고 있다는 말이죠. 이렇게 설명을 들으니까 있어야겠다는 생각이 드나요?

하지만, 그냥 보통 사람이 아랍언어를 사용하는 빈도는 이전보다는 있을 수 있다고 해도 그다지 많지 않을 것입니다. 해서 이 커서는 아무때나 나타나지는 않고, 일반적으로 아랍 언어 입력기를 설치할 경우에(IE8과 같이 이를 지원하는 프로그램에서) 나타납니다. 예외로 BiDi의 중요성을 크게 생각하는 일부 프로그램들에서는 자동으로 켜지는 경우가 있습니다. 이를 끌 수 있는 방법은 아랍 입력기가 있다면 이를 제거하거나 파이어폭스 브라우저같은 경우 주소창에 “about:config”로 이동해서 “bidi.support” 값을 0으로 바꾸면 없어진다거나, 혹은 다른 프로그램들은 도움말을 참조해서 기능을 꺼야하겠습니다. 안타깝게도 프로그램마다 이 커서가 나타나는 규칙에 표준이 없습니다. 그냥 표준이 되어서 사용자들이 익숙해지면 좋겠지만, 그렇게 간단하지는 않습니다.

아무튼 혹여 이런 현상을 보시더라도 이제는 잘못된 것이 아니라 BiDi 기능이 켜진 것으로 생각하시면 되겠습니다.^^

--

간만의 블로깅인데, 앞으로는 조금 더 분발해보도록 하겠습니다.ㅜ_ㅜ;;

재미난 것은(항상 하는 이야기지만;) Silverlight 1.0이 나온지 1년 반밖에 되지 않았다는 것입니다. Silverlight 1.0이 출시되고, 1.1이 공개되고, 1.1이라는 버젼으로는 설명이 안되기에 Silverlight 2라는 브랜드를 가지고 나왔고, 6개월만에 Silverlight 3의 베타버젼이 공개되었다는 것이죠. 3번째 버젼이 되면 항상 어떤 상황이든 하는 말이 드디어 쓸만해진 제품이 되었다는 말이겠습니다만, 이는 이전의 이야기고, Silverlight은 2부터 쓸만해졌고, 3부터 더욱 파워플 해졌습니다.

처음 계획 단계에서의 이번 업그레이드의 주요 골자는 사실 – 이미 공개해버린 H264/AAC 지원 이외에 - 2번째 버젼에서의 문제점들과 사용자들이 가장 많이 요구하고 불만으로 생각하는 기능들을 수집해서 이를 해결하는 것이었습니다. 문제는 이미 RIA 계의 경쟁자인 Adobe에서 사용자들의 입맛을 굉장히 까다롭게 혹은 좋게 이야기하면 높은 수준으로 만들었다는데 있었습니다. Flash와는 같은 분류에 속하게 되었다고는 해도 방식은 상당히 다름에도 불구하고 사용자분들의 요구는 “Flash/Flex에서는 이게 되는데 여기서는 왜 안돼냐”였습니다. 그렇다고 해서 Flash/Flex에서 지원한다고 무조건 비슷하게 만드는 것은 안될말이고, 최소한 사용자분들이 가장 목소리를 내는 부분에 있어서 높은 우선순위를 두고 버젼업에 박차를 가했습니다.

Silverlight 3의 여러가지 고민들 중 다른 큰 것 한가지는 빠른 버젼업으로 인하여 하위 호환성을 해치는 일이 없도록 하는 것이었습니다. Silverlight 2로 응용프로그램을 막 만들고 있는데 갑자기 Silverlight 3이 나와서 안되더라…하는 이야기가 나오면, 누가 개발을 하겠냐는 이야기죠. 이는 사실 WPF와의 호환성을 유지하는 것(WPF는 다음 버젼의 개발과 함께 또 저멀리 앞서 가고 있죠)과는 충돌이 있는 부분이기도 합니다만, 우선순위는 무조건 Silverlight 2와의 하위 호환성으로 정했습니다. 충돌이 있는 WPF와의 호환은 대체가 아닌 추가를 통해서 이뤄지도록 했구요. 일단 베타 버젼이기 때문에 Silverlight 2와 문제가 전혀 없을 것이라고 할 수 없지만, 문제가 발견된다면 무조건 Silverlight 3 정식 버젼에서는 해결을 하는 것이 큰 우선순위입니다. 언제나 그렇듯 Silverlight 3와 병행하여 개발되고 있는 관련 제품들이 여러가지가 있습니다. 모두들 아시는 IE8와 Windows 7이 대표적인데, 이들과의 호환성 테스트 기간도 물론 있었습니다.

1년내에 최대한 처리할 수 있는 이슈들을 모두 스케줄에 넣을 수 있는 한 넣고, 퀄리티를 맞추기 위해서 매주 바뀌는 테스트 스케줄을 감당하면서 베타버젼을 출시하기에 이르른 것이죠. 여러 기능들이 테스트할 시간이 없기 때문에 잘려나간 것을 생각하면 스케줄 때문에 안타까워하실 개발자분들이 있으리라 생각됩니다. 아무튼 그러다보니, 버젼 1.1처럼 Silverlight 3 이전에 2.5였다가 큰 기능들을 .5 버젼으로 커버하기보다는 메이저 업그레이드로 보는 것이 맞기에 3로 바뀌었습니다.

이번 Silverlight 3 베타버젼 공개에 관련된 다양한 제품들은 다음과 같습니다:

• Silverlight 3 Developer Runtime(Beta) (Windows, Mac) – 이번 베타버젼에는 User Runtime이 배포되지 않습니다. 즉 Go Live 라이센스를 제공하지 않고, 개발자분들이 사용해볼 수 있도록 개발자 런타임만을 제공합니다.
• Silverlight 3 SDK(Beta) - SDK에는 이전의 내용들 이외에 다음이 부가적으로 포함됩니다:
• Silverlight Toolkit Update – 새로운 컨트롤들이 소스와 함께 왕창 추가됩니다.
• Silverlight 3 Tools(Beta) – Silverlight 3를 지원하는 내용 이외에 이전 버젼과는 크게 달라진 점은 없습니다.(v2 프로젝트는 지원이 안됩니다.주의요.)
• Expression Blend 3 Preview – Silverlight 3의 지원 이외에 수많은 향상과 새 기능들이 포함되었습니다. 무엇보다 눈에 띄는 점은(전에 답답했던 관계로)…UI가 좀 더 유연해진 점?
• .NET RIA Services(Preview) – LOB 시장을 위해서 준비하던 Framework.
• IIS Media Services Extension 발표
• Silverilght 3 베타용 MSDN 문서와 CHM 문서 – 이전에 SDK에 있던 문서들이 제거되고 MSDN에서 읽거나 별도로 다운로드 받을 수 있습니다.

Silverlight 3는 간략하게 다음의 새로운 기능들을 포함합니다:

• Media – H.264/AAC 지원. Smooth Streaming(Adaptive Streaming), 써드파티 코덱 제작 가능, Silverlight PlayReady DRM, Fullscreen시 GPU Accel, Client logging.
• Rich Graphics – Perspective 3D, Pixel Shader, Writable Bitmap, Cached Composition, Custom Easing, Image 크기 미리보기, 테마 스위칭, 폰트 지원 강화, Style Composition.
• New Controls과 기능들 – TreeView나 MultiSelect ListBox등의 다양한 새 Control들, Deep Linking 지원, Data Validation, Data Forms, Element to Element Binding, Business objects 지원.
• Out-of-Browser 경험 지원 – 온라인 Silverlight 응용프로그램을 오프라인으로 캐싱하여 실행 가능.
• 기타 - Save As 기능, 압축 알고리즘 변경(약 20%향상), .NET Assembly caching(중복 바이너리 별도 다운로드), Accessibility 향상, Local Connection, Binary XML 지원, DeepZoom 향상, 오프라인 이벤트, 등등등등

(이번 베타 버젼은 안타깝게도 영어 이외에 일본어로만 번역이 되었고 제품들의 한글 버젼은 나오지 않습니다.)

이외에도 Silverlight용 Virtual Earth Control이나 WWT(World Wide Telescope) Silverlight 버젼 등의 Silverlight 2에 관한 소식도 있었습니다.

더 자세한 소식은 에반겔리온분들이 지속적으로 블로깅하시리라 믿슈미다~

Silverlight 2가 몇가지 이슈들을 살짝 고친 GDR1 버젼으로 업데이트 되었습니다. 버젼 정보를 보시면 2.0.40115.0이 최신 버젼입니다. 위 링크에 Tim이 적은 내용을 보면:

Download details Microsoft Windows 7 SDK BETA (Release Notes)

Windows 7이 나온 소식은 이미 널리 퍼져서 다들 아시는 것일테고, 개발자분들이 더 좋아하실 소식을 전해드립니다. Windows SDK가 Windows 7용으로 베타버젼을 (조용히) 내놓았습니다. 물론 Windows SDK의 정책상 롤업 릴리스이기 때문에 VS2008SP1과 함께 비스타(SP1)나 서버2008을 지원합니다.

수많은 샘플과 헤더와 라이브러리 그리고 툴들이 추가되었고, Windows 7을 위해서는 개발자 가이드와 퀄리티 Cookbook이 추가되었습니다.

요즘 Windows 7이 업계에 긍정적인 영향을 미칠 것이라는 이야기가 많은데 모쪼록 Windows 7으로 개발 커뮤니티도 더욱 활기를 띨 수 있게 되었으면 좋겠습니다.

Microsoft datacenter architect defects to Amazon - All about Microsoft - ZDNet.com

James Hamilton이 마이크로소프트를 떠난다고 합니다. 개인적으로 이 분 글을 즐겨 읽는데(사내 블로그도), 내부적으로도 유명인들의 강의를 오거나이즈하기도 하고 전설(?)로 불리기도 하는 큰 Influential이 떠나는지라 타격도 클 것 같습니다. 게다가 마이크로소프트의 차세대 전략에 있어서 중요하기도 한데 말이죠.

Amazon에서 비슷한 일을 하게 되니 업계에 있어서는 계속 같은 일을 하는 것이겠지만, 여하튼 내부에서 jrh 씨리즈는 더이상 보지 못하게 되겠군요.

대신 당시 센세이셔널 했던 Identity 2.0 프리젠테이션으로 엄청난(?) 유명세를 떨친 Dick Hardt가 직원이 되었다고 해서 위안을 삼으라는군요. 개인적으로는 비교가 안되지만요;