철수네 소프트웨어 세상 3

JavaFX가 발표되어서 긴 포스팅을 준비하다가…말았다.

기술적인 세부사항에 들어가면 다르겠지만, 하는 말이나 전략이 Flash+Silverlight 좀 짬뽕한 것이랑 똑.같.잖.아.

JavaFX is a family of products for creating rich internet applications (RIAs) with immersive media and content across the multiple screens of your life. It includes a runtime and a tools suite that web scripters, designers, and developers can use to quickly build and deliver the next generation of rich Internet applications for desktop, mobile devices, TV, and other platforms. JavaFX tools suite will offer developer and authoring tools that bridge the gap between user experience design and development logic, giving designers and developers unprecedented collaboration opportunities.

여기에 JavaFX를 Flash나 Silverlight로 바꿔보길.

기술적인 내용을 더 읽어보기 전에는 별로 할 말이 없다.

그것보다 근래 썬의 CEO 조나단 슈와츠가 Sun을 살리려고 올라섰다가 근래 Split하고 주가가 곤두박질치는 것에 대해 수근대는 것을 보는데, 웃기는건 하나같이 기술적으로는 훌륭하지만…으로 시작한다. 쩝. 기술쟁이 입장에서 씁쓸하네.

마이크로소프트에 관한 책에 대한 집착은 병적인걸까. 전에도 블로깅했듯이 집에는 Pre-마이크로소프트 서적부터 마이크로소프트의 역사를 보여주는 여러가지 다양한 책들이 널려있다. 한동안 끊었었는데, 이번에 Mary Jo Foley의 Microsoft 2.0을 나도 모르는 새에 아마존에서 주문한 결제 내역이 문자로 띠리링하고 날라왔다. 자꾸 주문해대서 책이 나온다치면 귀를 막고 모른척하고 블로그 안보고 했는데, 이번에는 반대로 보던 블로그에서 광고를 하니 안 볼 수가 없었다. 게다가 별로 관심 없는 반독점 어쩌고에 대한 것이 아니라 관심이 많은 내용이다.

이 책의 저자인 Mary Jo Foley는 오래전의 At the Evil Empire 컬럼이나 Microsoft Watch/All About Microsoft로 뿐만 아니라 전세계적으로 알려진 마이크로소프트 전문가이다. 소스도 풍부하고, 의견도 풍부하고, 다루는 것도 넓고 다양하다. 뭐든 마이크로소프트에 관해서는 기술에서부터 비즈니스와 정책등 전부 다루는데, 그런 이유에서 나온지 얼마 안된 이 책이 벌써 높은 순위를 차지하고 있지 않을까. Microsoft 2.0의 부제가 (아직 빌게이츠가 가지도 않았지만서도) 벌써 “How Microsoft Plans to Stay Relevant in the Post-Gates Era”다. 아직 책을 받지는 못했지만, 목차를 봐서는 아마도 빌게이츠가 만든 문화 등에 대한 내부 이야기보다는 현재의 상황과 소문과 방향성을 가지고 이야기를 풀어나가는 책이지 않을까싶다. 읽기 전에 벌써 여러가지 생각을 해본다.

어떤 사람들은 빌게이츠가 물러나면 후계자 문제로 마이크로소프트의 운명도 밝지만은 않을 것이라고들 하는데, 지금의 시기를 보면 꼭 그렇지만은 않아 보인다. 영향이 적다는 뜻이 아니라, 없어도 다르게 잘 굴러간다는 의미로 말이다. (단적으로 Yahoo!와의 게임에서도 선전하는 것을 봐서 그런 생각이 든다.^^)

빌게이츠가 방향을 바로잡는 역할을 계속 해왔겠지만, 재미난 것은 이런 역할이 밀실에서 이루어지기보다는 빌이 있던 없던 많은 사람들(그것도 그들만의 리그일지도 모르겠지만)에게 그것을 나누고 전달하고 서로 잘 경쟁할 수 있는 구도로 신기하게 만들어지게 되었다는 것이다. 한사람이 꼭 한 방향을 고수할 필요 없이 제각기 방향을 가면서 내부 경쟁을 하는 분위기라는 것이다. 경쟁이라고 똑같은 것을 가지고 서로 경쟁한다는 것이 아니라 각기 다른 비젼을 가지고서 다른 방향을 쳐다보고 있더라도 그것 자체로는  문제가 되지 않는다는 것이다. 게다가 서로 보완하기도 하고, 또 그렇다고 다 제치고 올라가는 모양새는 보여주지 않는다. 큰 회사라서 그런 것일지도 모르겠지만, 자생적인 밸런스를 가진 인간 생태계 만들어놓았다고 표현해야할 것 같다. 그러면서도 회사는 크기에 맞지 않게 잘도 바꾸면서 외부에 적응한다. 조직도 자주 바뀌고, 일하는 방식도 자주 바뀐다. 스티브 발머가 누구하나 귀여워해서 키우는 모양새도 아니고, 잘하면 잘해주고 못하면 혼내면 되는 자연스러운 모양새이다. 비젼이 있다면, 가지고 있는 엄청난 자금에서 투자를 해주면 되는 것이다. 비젼이 틀리더라도 나온 결과물을 활용하는 방법도 다양하다. 말이 쉽지 이 비젼이라는 것에 철저한 검증이 들어가기 때문에 간단히 투자가 나오는 것은 아니지만, 비젼을 구체적으로 보이기만 하면 실험해볼 수 있는 길은 활짝 열려 있다. 또한 연구소도 세계적으로 알려져있고, 이 연구소와도 잘 연동되어 신기술의 실용화 기간이 빠르다.

주저리주저리 뭣이 되었건, 우리나라처럼 자식이 물려받는 회사가 아니라 물러나면서 자신이 없이도 잘 굴러갈 수 있는 철저한 모양을 만들어놓고 나갈 수 있는 그런 능력 자체가 엄청난 것이란 생각이 든다. 그리하여 Post-Gates Era는 이렇게 비가오게 하고 다시 비가 증발해서 구름을 만들고 다시 비를 내리게 하도록 만든 그런 모양에서 시작할 것이다. 이미 내년을 준비하고, 2년 뒤를 준비하고, 5년 뒤를 준비하고, 또 10년 뒤를 준비하고 있고, 그 큰 덩치에도 불구하고 작년의 잘못, 제작년의 잘못 그리고 그 전의 잘못을 되풀이 하지 않기 위해서도 여러가지를 하고 있는 것(하고 있다고 모두 이뤄지는 것은 아니지만)이 사원의 입장에서 눈에 보이는데 굳이 아닌척 하면서 다르게 이야기할 필요가 있으랴. 이래가지고는 “빠”소리를 뗄 수가 없겠군.

CSI: New York Video: Admissions - CBS.com (비디오)

보나세라: Familiar with PhotoSynth? – 포토신스 알아요?

애덤: PhotoSynth, Yes, Taking a large collection of photos, analyzing the similarities, and displaying them in a reconstructed 3 dimensional space. – 포토신스, 예, 많은 양의 사진들을 찍어서, 유사성을 분석하고, 이를 다시 3차원 공간에 재구성하는 것이죠.

보나세라: Exactly, build me a high school gym. – 맞았어, 고등학교 체육관을 재구성해주세요.

애덤: 예, 헉~

개인적으로 CSI spin-off중에서 제일 좋아하는 CSI Newyork의 시즌4 에피소드18에 나오는 대사이다. 이번 에피소드에서는 그냥 사건에서 사용되는 랩탑/액세사리로써나 혹은 멋진 디스플레이 기술로써가 아닌 사건의 해결을 위한 기술로 마이크로소프트의 PhotoSynth가 그 이름 그대로 사용된다. 연출을 위해서 PhotoSynth의 PM이 직접 가서 컨설팅을 했으니.^^

PhotoSynth는 위 대사의 설명대로인 기술이고, 재구성된 3차원 공간을 볼 수 있는 클라이언트의 Tech Preview가 제공되고 있다. 이외의 내용은 아직 공개되지 않은 상황이라 뭐라 할 수 없지만, 드라마에서 사용된 씬들은 기술을 과장한 것이 아니라 실제 돌아가는 비트를 사용한 것이고 이처럼 무궁한 Appliance가 기대되는 밝은 미래를 가지고 있는 제품이다. 이 Tech Preview를 공개한지 근 1년반이나 되는 시점에서 이런 재미난 이벤트를 보여준 것은 뭔가 힌트가 있는 것이리라.

보나세라: The clarity is unbelievable!

애덤: And~ in 3D

3차원으로 구성된 스샷은 등장인물들 뒤통수가 안나와서 안썼으니, 드라마를 직접 한번 보시길.ㅎㅎㅎ

최근 회사에서 이런 저런 문서들을 읽다가 "유레카!”를 외치게 되었다(벗고 뛰쳐나가지는 않았다). 젠장. 답은 눈앞에 있었는데도 불구하고 그 주변만 수년간 헤메고 있었던 것이었으니, 속 시원하고 한편으로는 내 능력이 한탄스럽기도 하고. 아무튼 유레카에 이른 그냥 짧은 談을 적어본다. (아쉽게도 교훈적인 이야기는 아니다^^)

SoC(Separation of Control), IoC(Inversion of Control)이라는 말을 알게 된 것은 거의 9년전 Apache의 Avalon과 Cocoon 프로젝트를 쫓아다니면서였다. (정확히는 이를 도입한 Stefano Mazzocchi의 글을 읽고 나서겠지) 그때는 마치 하나의 패턴처럼 그냥 그냥 외우고 썼었지만, 정작 태생적인 Why를 이해하기 위해서는 역부족이었다. 교과서에 나오는 것처럼 텍스트에 적힌 Why를 이야기할 수는 있지만, 제대로 된 이해에서 오는 것은 아니었으니 사용할때마다 얼마나 답답했으랴. 사실 이를 사용함으로써 생기는 장점만으로도 사용할 이유는 충분하니까.

Martin Fowler에 의해서 그 구현들이 IoC라는 말보다는 DI(Dependency Injection)이 더 맞다는 제안이 커뮤니티에 받아들여져서 요즘에는 DI로 통하는데, 이 DI 컨테이너 혹은 런타임 혹은 프레임웍 혹은 패턴은 Java 진영에서는 흔히 프레임웍(Avalon, Spring등)으로 사용되지만, .NET 쪽에서는 패턴식으로는 많이 사용되더라도, 어떤 제품 프레임웍으로써의 사용례가 많지 않고 역사(?)가 (상대적으로) 짧다. Spring.NET, Castle, Unity, Structure Map(PicoContainer가 있을때는 PicoContainer.NET)등. 어차피 만든 사람들은 진영과 상관없이 왔다갔다 하는 사람들이기 때문에 어느 쪽이 더 우월하다 어쩌다 논쟁을 할 가치도 없지만, 그 프레임웍들이 이전 Java 커뮤니티처럼 사용되지 않았던 것은 사실이다.

딱 찝어서 그렇다고 할 수는 없지만, 대개 Java의 커뮤니티의 경우에는 자생적으로 기술들을 만들어 이것이 그대로 Java 커뮤니티에 다시 돌려지지만(사용되지만), .NET 커뮤니티의 경우에는 조금 다르게 자생적으로 만들어도 이는 직접 커뮤니티로 가지 않고 .NET 팀에 “피드백”으로 들어가 .NET 커뮤니티에 돌려지는 경향이 많다. 한마디로, Java에서는 좋은 것이 만들어지면 바로 프로젝트에서 사용하지만, .NET에서는 이것이 제품에 반영될때까지 사람들이 사용하지 않는다는 것이다. ASF등의 힘이 컸을지도. (점차 사람들이 교환(?)되면서 이런 성격도 점차 섞이고 있긴 하고 이를 타파하기 위한 노력도 굉장히 많다)

근래 .NET Framework의 BCL 드자이너인 Krzysztof Cwalina가 Managed Extensible Framework(MEF)이라는 것에 대해서 포스팅을 했었다. 그 글에는 마이크소프트 내에서 Framework을 확장하는 여러가지 기술들에 대해서 이야기하면서 DI(Dependency Injection)을 이야기한다. 마이크로소프트에서도 뭔가 공식적인 움직임을 만든다고 공식적으로 이야기한 것이다. (사실 ObjectBuilder나 근래 Unity라는 Application Block이 Pattern&Practice 팀에서 나왔고, 정확히 이야기하면 수년간 계속 연구중이다)

MEF를 만드는 팀은 (수십개의 큰 팀으로 이뤄진) 커다란 Division으로 치면 나와 같은 Division이다. 해서 이에 대한 정보를 얼마든지 볼 수 있다는 뜻. 참새가 방앗간을 지나칠 수 없듯이, 나도 역시나 찾고 열심히 읽어보기 시작했고…거기서 유레카를 외치게 된 것이다. 그것도 별 것 아닌 몇십페이지짜리 문서의 몇장짜리 짧은 단락에서 말이다. 당연하지만, 회사에서 뭔가를 하고자 하면 이에 대한 정당성이 명확하고 매니저에게 설득이 되어야 펀딩이 되고 할 수 있는 것이다. 따라서 이런 문서들이 넘쳐난다. 하니, 이런 문서에서 진주를 발견하는 일은 흔할 수도 있다고 할 수 있겠지.

소프트웨어를 공부하면서 이해해야하는 것들 중에서는 나뉘어져 그 구분을 이해해야하는 것들이 많이 있다. 쉽게 온라인/오프라인, 정적 언어/동적 언어, 런타임/컴파일 타임등등. 여기서 또하나 중요한 것은 이들이 둘로 나눠지는 이유를 아는 것 뿐만 아니라 이 둘이 궁극적으로 겹치거나 애매하거나 혹은 상관관계를 가지는 중간 영역이 커다랗게 있다는 것이다. 언제나 그렇다. 예를 들어 소프트웨어의 발전 과정에 있어서 템플릿이나 메타 프로그래밍처럼 강력한 무기라고 하더라도 컴파일 타임에 모든것을 하려는 C++시대만 계속 될 수만은 없는 노릇이고, Java/C# Generics나 Duck Typing이라는 것도 나와야 한다. 디스크에 있더라도 메모리로 올려지게 마련이다. 동적 형식(Type)이 다가 아니고, 정적 언어에서도 Type Inferencing이라는 형태로 흉내낼 수도 있다. 온라인이라도 Google Gears등처럼 오프라인 스토리지 형태가 필요한 것이다.

이런 것들을 이해하기 쉬운 방법 중 하나는 그 역사(History)를 이해하는 것이다. 어떤 사람이 어떤 이유로 그런 것을 사용했는가는 이해에 있어서 좋은 접근 방법이라고 생각한다. 역사는 그 필요를 보여주고, 필요에 의한 사용과 생성은 언제나 말이 된다. 역사는 또한 Trial & Error를 직접 겪지 않고도 보여주는 멋진 자료이기도 하다. 그리고 나는 이를 맹신하면서 따른다. 맹신하기에 이 역사에 어떤 이해하지 못하는 갭이 있으면 앙금으로 남는다는 것이 문제다. 이 IoC의 이해 문제도 이런 앙금이 있었지만, 간단한 연결고리에 대한 설명 몇 문구로 내 머릿속의 화룡점정畵龍點睛격이 된 것이다.

그게 다는 아니다. 거기다가 요즘 C#을 처음부터 꼼꼼하게 다시 공부하겠다고 Accelerated C# 2008을 정독하고 있기도 한데 여기서 5번째 챕터를 읽는 중이었고, 마침 이 챕터에 또 연관된 내용이 들어있기도 했다. 여하튼 이래저래 관련 내용들이 우연히 한 곳에 비슷한 시기에 모여 딱 들어맞았으니 외칠만도 했겠지. 별게 아닌데도 쓰여있는 내용이 아니라 그걸 통해서 여태껏 생각하지 못했던 뭔가가 떠올랐을때의 그 신기함이란.

이 간단한 것을 5년 전에 알았다면, 어땠을까. 인생의 각도가 0.2도 정도 바뀌지 않았을까. 뭐 그 정도 가지고라고 이야기해도 실상은 아마도 내 공부 방향이 바뀌었을지도 모를 일이고, 0.2도 정도는 가능하다고 생각된다. 알고나면 허무할지도 모르나, 알고자 하는 과정이 챌린징하다는 것이 지식의 묘미 중 하나일 것이다. 위대한 업적은 아니더라도 뭔가를 알게 된다는 것은 벤젠을 발견한 꿈이나 목욕탕에서 유레카를 외친 것과 다를 것이 없지 않을까. 유한한 인간에게 있어서 알기 위한 과정이 너무 오래 걸려서 탈이지.

유레카 한번은 외쳐줘야 고루한 회사 생활 할맛 나는게 아니겠나…모두 즐공 하시길.^^

야후! 사전 - couple of

학교에서 영어를 배울때부터 이해가 안갔던 a couple of의 번역. 위에 사전 링크를 보면,

a couple of players 두 사람[한 쌍]의 경기자.

이렇게 되어있다(사전이니까 맞겠지).

문제는 예를 들어 영화를 볼때, “a couple of 어쩌고”하면 둘을 이야기하는 것이 아니라는 것이다. “they’re just a couple of locals” = "걔네 들은 그냥 주민 몇이야”의 의미인데, 영화 자막을 보면 꼭 “주민 두명이야”라고 콕 찝어서 2명을 지정한다. “두어명”이라고 2명을 이야기하는 것이 아닌 얼버무리는 표현도 있는데 말이지. (우리나라에서 커플이라고 하면 남녀 한 쌍을 이야기하긴 한다.)

오늘 또 “a couple of things”라고 하는데, “두가지에요”라고 자막이 나온다. 물론 이 말을 하고 2가지를 이야기하지 않는다.

이거 주입식 교육의 산물일까 아니면 내가 잘못 알고 있는걸까?

Windows Live Dev : Introducing Live Mesh

그것을 싸스(SaaS: Software as a Service)라고 부르던, S+S(Software + Service)라고 부르던 간에 서비스로서의 소프트웨어 혹은 소프트웨어로서의 서비스는 근래의 대세입니다. 여러 업체들이 이런 유형으로 옮겨가면서 기술적인 성공(혹은 어떤 경우 비즈니스적인 성공)을 거두고 있는 상황이고, 기술의 (더딘) 발전 유형 속에도 브로드밴드나 무선 미디엄들로 급속하게 바뀌고 있는 인터넷의 사용 행태가 뚜렷하게 보이고 있고 그 니치를 잘 캐치한 회사들의 급작스런 성공 사례들이 속속 나타났습니다. 뻔한 이야기는 각설하고 아무튼, 이런 흐름이 있다면 이를 마이크로소프트에서도 캐치하지 않았을리 없었을 테고, 마이크소프트 안에서 크게 베팅하고 실험하는 여러가지 흐름의 포석 중에서 한가지로 레이오지가 공개한 것이 바로 아마도 이 Live Mesh일 것입니다.

Mesh란 그물같은 형태를 이야기하는데, 말그대로 웹이라는 매개를 통해 산발적으로 존재하는 다양한 endpoint들을 연결한다는 의미로 사용한 단어일 것입니다. 한마디로 사람(Social)과 PC(Device)와 프로그램(Application) 그리고 Cloud등을 그물처럼 웹에 엮는다는 의미랄까요. 여기서 엮는다는 것은 그 관계를 구체화시키는 의미가 강할 것입니다. endpoint간의 소통(communication), endpoint로의 접근(access), endpoint의 그룹화 등등…이전의 락인(벤더 락인이 아니라 기술 락인)이 웹의 변화로 인해서 distributed, decentralize, loosely coupled등의 키워드로 거듭나기 시작하면서, 다양성을 존중하는 syndication, cloud등의 또다른 형태를 만들어내고 있는 과정에서 말이죠. Live Mesh는 이런 키워드들을 연결(관계를 구체화)하는 의미의 오픈 플랫폼 서비스 중 일부입니다.

이 플랫폼을 사용하여 만들어진 첫 서비스의 기능으로 자신이 가진 디바이스들과 데스크탑들을 폴더로 연결하고, 또한 다른 사람들의 폴더와도 연결하며, 이것의 매개로 웹과 cloud를 사용할 수 있는 내용들을 제공합니다. 회사 PC와 집의 개인 PC와 집의 홈 PC, 들고다니는 디바이스들 등을 Live Mesh의 Cloud(마이크로소프트에서 제공하는 storage)와 연결하고, 각각의 데이타와 파워(지금 서비스에서는 폴더)를 공유하고 사용하고 또한 여기서 발생하는 변화들(News)을 구독하거나 통신하는 경험을 생각할 수 있습니다. 이 경험만으로는 SkyDrive나 Foldershare를 생각할 수도 있겠습니다. (여기서 silverlight를 사용한 tour를 보실 수 있습니다.)

마이크로소프트의 기술 프리뷰는 거의 대부분 개발자가 큰 대상 중 하나라는 것인데, Live Mesh도 마찬가지로 당연히 개발자를 위한 API와 API를 사용할 수 있는 API Kit을 제공하며, ATOMPub, FeedSync, RSS, POX,, WB-XML, JSON…등을 여러 기능에서 사용합니다. Mesh Framework을 사용하여 Google App Engine이나 AmazonWS등에서 이야기하는 것들을 마이크로소프트에 호스팅하여 구현할 수도 있게 됩니다. .NET Framework이나 혹은 JavaScript를 라이브러리로 제공하지만, 표준 포맷들을 사용하기 때문에 다른 언어와 플랫폼을 사용하여 개발할 수도 있습니다. (여기서 silverlight를 사용한 개발자 대상 tour를 보실 수 있습니다.)

현재 공개된 것은 기술 프리뷰(Technology Preview) 버젼으로 베타와 같은 버젼이 아닌 방향성을 보여주는 실험단계라는 의미이며, Live라는 브랜드명을 가지고 있기 때문에 Windows Live와 상통하지만 출시면에 있어서는 Windows Live의 업그레이드와는 독립적입니다. 현재는 그 모습만을 공개하기 위해 초대된 사용자들만 사용할 수 있도록 하고 있지만, 연내에 베타 서비스가 오픈할 것이라고 합니다. (비스타와 XP SP2를 지원하고 연내에 다른 모바일 디바이스와 맥을 지원할 것이라고 합니다.)

(Cross-posted to my msdn weblog)

너무 복잡한 내용들을 단순화하려다보니 제공되는 서비스와 이에 대한 설명만 봐서는 정말 SkyDrive/Foldershare를 생각하고 이해하기 아주 쉽게 되어있다는 생각이 듭니다. 사실 지금은 비젼을 팔아야하는데, 지금 상황에서 이 비젼을 팔 수 있는 대상이 일반 사용자분들은 아니기에 이런 접근이 이해는 됩니다만, 오해의 소지가 많아보여서 걱정이 됩니다. (프레스킷같은 것의 내용도 알아먹기 힘들 정도

사실 공식은 간단합니다. (Web +) Cloud(+Storage) + Endpoints + Platform + Business Value = 돈. 헌데 이 공식을 구현하고 설득하는 것이 문제죠. 웹은 이미 존재하는 것이고, 파일등을 포함한 데이타와 이를 처리하는 서비스 그리고 이들을 연결해주는 플랫폼. 여기서 Live Mesh에서 unique한 것은 오프라인 소프트웨어. 지금 공개한 기능을 설명하면, Cloud와 Endpoint를 연결하는 Platform의 기능 일부를 보여준 것이라고 할까요.

미디어에 Live Mesh가 파일 싱크하는 서비스라는 식으로 기사들이 여럿 나올 것이라는 예상 빗나갔으면 좋겠습니다. 또 무슨 Windows OS를 대체한다느니, Cloud OS라느니, 혹은 Windows Live의 실패로 만들어졌다느니, 이런 것도 마찬가지구요.ㅎㅎㅎ

참고 링크: Mary Jo Foley의 포스트 Ten things to know about Microsoft’s Live Mesh

NAVER INSIDE

여기에 여러가지 재미난 기능들이 있어서 눌러보던 중이었는데, 그 중에서도 얼굴사진 검색…

그 첫결과의 링크를 눌러보면;;; 그냥 웃겨서 그만 포스팅해버립니다~ ㅎㅎㅎ

Google App Engine Blog Introducing Google App Engine + our new blog

Hello, World! - Google App Engine - Google Code

Google App Engine =

Ning (- PHP/Javascript features + Python features like django)

+ Amazon SimpleDB(or Micrsoft SSDS or AWS?) aka Bigtable+GFS

+ Their APIs(existing or to be disclosed)

일까요?

(게다가 Amazon 부분은 유료)

요즘은 Microsoft가 오픈되고 있는 여러가지 사건들에 대한 이야기를 자주 접하게 됩니다. 그 배경에는 일련의 사건들이 엮여 있기도 하고, 또한 현 소프트웨어계의 시류에 맞추려는 노력 또한 반영되어있기도 합니다. 이런 시류에 맞추는 것이 기업의 장기적인 이익에 결부되어있는 것도 당연한 일일 것이구요. 이에 대해서 여러가지 의견차가 있지만, 일단 Microsoft에서는 공개적인 약속(OSP, Open Specification Promise)를 하였습니다. 법적으로 구속력이 약한 약속이라고 여러 법조계 분석가들이 이야기를 하지만, 여기에 속한 다양한 공개정보에 대해서 하나라도 약속을 어기게 되면 여기에 속해 있는 모든 약속에 엮이거나 관심을 둔 엄청나게 커다란 커뮤니티 - 소위 Microsoft 진영이라고 불리는 영역 뿐만 아니라 그 이외에 모든 잠재 고객과 고객 – 에 큰 파장을 불러일으킬 수 있는 상황임에는 틀림이 없기에, 단순히 차후에 안지키겠다고 하면 된다는 식의 반대는 설득력이 적어 보입니다. 이에 준하여 Microsoft가 어떤 노력을 하고 있는지 조금 살펴보는 Note를 한번 적어봅니다.

다양한 배경

일반적으로 기업의 규모와 영향력이 커지면서 다양한 시련(?)을 겪게 되는데, 그 중에서 가장 큰 것중 하나가 반독점등의 시장 질서에 관한 부분이겠습니다. 다양한 국가에서 다양한 형태로 조사를 받고 벌금을 물고 법적인 이해관계가 물리고 하게 되는데, 이에 대한 자구책이자 어떤 때에는 시정 조항으로 제시되는 것이 바로 “오픈”이라는 방책입니다.

또한가지 상황이 오픈소스라는 이데올로기 성격의 마인드셋입니다. 기업이기에 모든 것이 공공재로 열어버리는 딜레마를 만들리는 만무하지만, 오픈소스 진영이라고 하는 영역과의 수년전의 대립관계가 정답이 아니라는 것을 기업들은 이미 깨지고 깨진 끝에 깨닫기 시작했고, 지금은 그 깨달은 바를 통하여 그 두 곡선의 최적의 분기점에 가까운 비즈니스 모델로 이전을 하고 있는 시점입니다.

이런 오픈소스 마인드셋이 영향을 미친 것은 비단 기업이라는 커다란 엔티티만이 아니라 그 내부에 속한 개인들에게도 마찬가지입니다. 이 마인드셋은 냉전시대의 미-러 관계와 같은 것은 당연히 아니며, 외부의 오픈소스 전문가들이라고 Microsoft에서 일하지 말라는 배타주의적인 것도 아닙니다. 일부 극단에 속한 마인드셋은 회사 자체를 의魔화하기도 하여 “Don’t be evil”이라는 교훈을 의역하지 않고 곧이 곧대로 사용할 수도 있겠지만, 일반적으로는 그런 극단이 보편적인 것은 아니겠죠. 회사가 개인의 이데올로기를 배척하는 것은 옳지 않은 일이기에, 쉽게 이야기해서 이 마인드셋은 Microsoft 내부에도 얼마든지 영향을 미치고 리크루트되고 스며들어 이미 떼어낼 수 없는 문화적인 성격이 되어버린 것이기도 합니다.

기술적인 상황도 있습니다. 세상의 다양한 기술들이 사실상 공존하면서 생기게 되는 것이 기술적자생존 현상입니다. 예를 들어 Java 진영에서 개발한 기술이 Microsoft에서 구현되어 사용되거나 그 반대가 되는 경우가 있겠죠. 또한, 자생한 표준화 기구의 영향력이 제품의 방향을 결정하는 경우도 많습니다. 기술적으로 얼마나 우월하냐는 것보다는 (자연선택이 아니라) 시장선택을 받았으냐는 요소에 의해서 발전을 해나간다는 것인데, 근래의 시류는 이런 현상이 유달리 돋보이는 때이기도 합니다. “오픈”이라는 요소는 이런 현상에 적응하기에 더 쉽도록 만들어주는 큰 요소라는 것이 설득력이 생긴 것이겠구요.

Microsoft에서 잘하는 키워드로 “커뮤니티”, “생태계(ecosystem)”가 있는데, 여기에도 몇가지 상황이 있습니다. 이미 커뮤니티/생태계를 통한 “오픈”은 해온지 오래되었고, 예를 들어 다양한 influencer에게 내부 자료들을 공개하는 등의 방법을 통하여 시너지를 보여주고 있죠. 또한 이전의 방법이 내편을 돈독히 하는 방법이었다면, 이제는 내편이 아니더라도 모두가 내편이 될 수 있는 잠재적인 내편임을 가정하는 방법이 커뮤니티/생태계를 만드는 더 “장기적으로” 합리적인 모습이기에 “오픈”이 한번 더 설득력을 가집니다.

하나 언급하고 넘어갈 것이 OOXML의 ISO 표준 인증의 노력에 대한 것이겠습니다. “오픈”을 위해서 OOXML을 표준화하려는 것이냐, 아니면 OOXML 표준화(외의 여러가지)를 위해서 “오픈”을 표방하는 것이냐. 이는 관점의 차이라고 할 수도 있겠습니다. 하나의 비즈니스 모델로 생각한다면 결국 기업의 최종 목표인 실적을 향한 움직임일테고, 시류로 생각한다면 시류에 뒤쳐지지 않으려는 노력일 것일테죠. 하지만, 이를 갑자기 역행하여 지금까지의 노력들을 물거품으로 만들만한 메리트는 어디에도 없다고 생각됩니다.

오픈

사실 이 보편적인 의미로 사용된 “오픈”이라는 말은 “오픈소스”의 오픈과는 조금 다른 문맥일 것입니다만, 어렵게 여러가지를 정의하는 것보다는 지금까지 보여진 여러가지 예를 나열하는 것으로 이해를 도모해보는 것이 좋을 것 같습니다:

• 제품들의 Interoperability에 대한 전략 공개 – 단순한 전략 공개가 아니라 현재 이 전략의 다양한 세세 항목들이 실행되고 있습니다. 이 전략에는 제품/커뮤니티/접근/표준의 4가지 기조가 있습니다.
  • 문서화되지 않은(undocumented) 모든 Windows API들의 문서화 – 시정명령에 의하여 API들을 문서화한 이야기는 익히 들어서 아시는 내용이리라 생각됩니다. 이 시정명령 이외에도 메이져 제품들의 API들을 모두 문서화하게 됩니다.
  • 제품들의 내부 프로토콜 명세등을 공개(Open Protocal Specifications) – 공개된 프로토콜 문서 중에는 특허와 결부된 내용들이 있기에 이를 명시하게 되며, 상용 목적으로 사용될 경우 이를 적절히 협상할 수 있는 프로그램이 제공됩니다. 또한 오픈소스 제품에게는 무료로 라이센싱할 수 있게 됩니다. 이전의 닫힌 형태와는 매우 다른 모양이겠습니다.
  • OSP(Open Specification Promise) - OSP에 해당하는 리소스의 사용에 관한 침해를 제기하지 않겠다는 약속입니다. 이 약속을 적용한 다양한 표준들이 지속적으로 추가되고 있으며, 최근에는 WPF와 WF에서 사용하는 Xaml 명세의 Draft 버젼이 등록되었습니다. 여기에 현재(2008/04/01) 포함된 기술명세는 다음과 같습니다:
    • 웹서비스(Web Services) 표준
    • 가상화 기술에 사용되는 VHD 포맷
    • 몇몇 보안관련 RFC들
    • OOXML 표준
    • Office(워드, 엑셀, 파워포인트)의 바이너리 포맷들과 관련 포맷들
    • 그래픽 관련 포맷들
    • 로보틱스 관련 포맷과 FeedSync
  • Open XML SDK를 제공 - OOXML의 표준화 노력 이외에 이를 사용할 수 있는 API들을 SDK 형태로 제공하여 다운로드하거나 온라인으로 볼 수 있습니다. 현재는 기술 프리뷰형태이며 1.0 버젼이 5월께에 출시될 예정입니다.
  • Office 제품들은 앞으로 OOXML이외의 포맷으로 export할 수 있는 기능이 제공되며, 또한 새로운 포맷 지원을 원활히 하기 위한 API가 제공되어 플러그인할 수 있게 됩니다.
• 제휴를 통한 오픈소스 진영과의 공조 – 가장 대표적인 예가 Novell이겠습니다. 여러가지 제품들의 개발 단계 명세들이 제공되어 리눅스 버젼의 제품으로 구현되고 있습니다. Mono가 그 대표적인 구현입니다.
• 오픈소스 랩(OSS Lab)과 Port25라는 오픈소스 공조 커뮤니티 사이트 – 다양한 오픈소스 제품들을 대상으로한 실험들과 상호 협력을 위한 일들이 투자되고 있습니다. 또한 Open Source at Microsoft 페이지에서 다양한 프로그램들과 커뮤니티 파트너들을 보실 수 있습니다.
• Shared Source Initiative
  • Shared Source 프로그램을 통하여 Windows/Office 자체의 소스코드를 무료로 라이센싱하고 있습니다.
  • CodePlex 오픈과 활용 - CodePlex는 소스포지와 같이 무료로 프로젝트를 호스팅하여 진행할 수 있도록 만든 사이트로 이를 통하여 Microsoft의 제품들의 다양한 소스코드 공개와 오픈 프로젝트 지원도 하고 있습니다. 최근 ASP.NET MVC 프레임웍의 소스코드 공개도 CodePlex를 통해서 이뤄졌습니다.
  • .NET Framework과 관련된 소스코드의 공개 – 소스코드를 패키지화하여 공개한 것이 아니라 MS-RSL 라이센스(참조 라이센스)를 통하여 디버깅시의 소스서버를 통한 공개이기는 하지만, 이를 통하여 사용자들은 다양한 편의를 도모할 수 있게 됩니다.
• IE8의 기본 모드로 표준 지원 모드 설정 – 기존의 입장을 변경하여 웹표준모드를 기본으로 하는 파격(?)적인 결정을 하였습니다. 이로 인하여 기존의 IE7 호환을 위해서는 호환모드로 변경해야햐는 번거로움이 생기지만, 대신 웹표준이 활성화되는 계단의 한계단을 건너뛴 역할을 할 수도 있게 되겠죠.
• Windows Live의 지속적인 오픈 API화와 제휴(Windows Live Dev) – 다양한 서비스의 오픈 API들을 제공함과 동시에 이를 사용한 참조 구현 응용프로그램들을 지속적으로 만들어 제공하고 있습니다. 최근 Contacts API와 FaceBook등의 회사와의 제휴가 발표되었었죠.
• IIS의 FastCGI 개발 제휴 -  IIS상의 PHP 호스팅 개선과, PHP 커뮤니티와의 소통 그리고 개발 내용의 공유등 커뮤니티에 많은 영향을 제공합니다.
• DLR(Dynamic Language Runtime), IronPython등의 소스코드 공개 - IronPython은 .NET Framework상에서의 Python 구현은 실용성이 없다는 관념을 깬 프로젝트로, 이를 개발한 Jim Hugunin을 Microsoft에서 영입하여 긍정적인 평가를 받고 있습니다. 또한, .NET Framework상의 Ruby 구현을 하던 John Lam의 영입도 비슷한 맥락입니다. 또한 이들 동적언어의 쉬운 개발을 위하여 DLR을 개발하고 있으며 이 또한 코드를 볼 수 있습니다.
• 오픈을 향한 내부 엔지니어링의 변화 – 엄청나게 많은 변화들이 있었지만, 가장 사용자에게 가까운 변화가 개발 중에 CTP(Community Technology Preview, 커뮤니티 기술 프리뷰)라는 것이나 일일빌드등을 술렁술렁 내놓는 것이라고 할 수 있겠습니다.
• DreamSpark 프로그램 – 전세계 학생들에게 Microsoft 제품들을 무료로 사용할 수 있는 기회를 주는 빌게이츠의 역작(?)입니다.^^

이외에도 많은 소식들이 있었고, 앞으로도 발표될 예정입니다. 위의 배경에서 설명한 바대로 회사를 위하여 하는 활동임에는 틀림이 없습니다만, 이런 행위의 성격이 이전과는 다르다는 것을 보실 수 있을 것이라 생각됩니다.

맺기

문서를 만들고 명세를 만들고 또 표준을 만드시는 분들, 그리고 이를 위해서 협력을 하는 분들은 이렇게 짧은 시간에 이런 품질로 내놓는 투자가 얼마나 큰 것인지를 알고 계시리라 생각됩니다. 위에는 한줄로 적었지만, 사실은 엄청난 MM(Man-Month)가 필요한 작업이고, 개발 자체 못지 않은 작업이며, 또한 다른 부분의 희생을 요하는 작업입니다. 이런 투자를 단순히 Evil Empire를 넓히고자 하는 수단으로만 보는 색안경은 벗어버리시고, 되려 이런 상황을 이용하여 더 건설적으로 소프트웨어 계에 영향이 미쳤으면 좋겠다는 생각을 해봅니다. 개발자에게는 더 많은 문서/코드등은 좋은 소식이며, 파트너에게 있어서 자유도가 더 높아지는 것은 그만큼 생태계가 건강해질 수 있는 여지이며, 경쟁자에게 있어서는 선의의 경쟁을 위한 협력의 기회이자 방법이 될 수 있고, 일반 사용자에게는 더 좋은 제품에 대한 가능성이라고 할 수 있겠습니다. 물론 Microsoft와 같은 회사가 (긍정적이든 부정적이든) 유례 없지만, 한 회사내의 이런 대규모의 “오픈” 흐름 또한 유례가 없지 않을까요?

(cross-posted to my msdn blog)

궁극적으로는 회사의 이익이지만, 사실은, 그 과정에 있어서 바뀌는 모양이 흥미롭고 긍정적인듯한 것이 기특해서 조금 적어보려 했습니다만, 이미 직원이기에 설득력을 기대하는 글을 적지는 않았습니다. “빠”든 “까”든 합리적이라면 받아들이는 것이 합당하니 뭐.

여담이지만, 글을 덕지덕지 쓰는 습관은 msdn 블로그가 소식성 블로그로 바뀌면서부터일텐데, 여기서도 여지없이 그렇게 쓰는게 편해서 그렇게 적게 되었습니다만, 조금 노력할 필요가 있는 것 같네요.ㅜ,.ㅜ;; 글을 쓰는 것보다는 글을 나열하는 것이 훨씬 쉬우니 자꾸 이렇게 바뀌네요.

데스크탑 = 나 (III)

전에 계속 찌끄릴 예정으로 해 둔 이야기를 이어서 (III)편을 써봤습니다. 시덥잖은 내용을 너무 오래 텀을 두고 쓴거라 말이 되는지 잘 모르겠습니다. 데탑PC건 노트북이건 엄피씨건 타블렛PC건 PDA건 우리는 데스크탑 앞에 앉게 되고, 그런 사실에 대한 여러가지 생각을 묶다보니 나름 내용이 된 것인데, 방향성을 생각해보고 정리하는데 글을 쓰는 것만큼 또 도움이 되는 것이 없더란 말이 딱 맞는 것 같네요. (부제를 붙이지 않는 것은 사실 부제로 어울리는 말을 찾을 수가 없어서였습니다 암튼 즐감.ㅎㅎㅎ

데스크탑 = 나 (I)

데스크탑 = 나 (II)