제 생각에 MS와 Adobe의 관점의 차이라고 하기보다는 개발자와 디자이너의 관점의 차이가 맞는 것 같네요. 항상 개발자와 디자이너의 간격이 좁혀지지 않는 이유 중에 하나가 그 것이거든요. 디자이너는 그림을 그릴 때를 봐도 전체 스케치를 통해서 점점 세부 내용을 구체화 시켜 가는 한편, 개발자는 코드 하나, 부품 하나를 서로 엮어서 전체를 완성해 나가는 것처럼 말이죠.
그런데, 중국이 들어가 있는데 일본이 빠진건 의외네요. 한국은 애초에 기대를 안했고. (음음) 곧 이 프로그램은 더 많은 나라로 확대된다고 하는데요, 두번째 대상국에 한국도 포함되기를 바래요.
현재 마이크로소프트의 제품군들이 힘을 못쓰고 있는 이유를 기존의 유닉스+오라클 시장의 보수적인 의사 결정권자들에게서 찾는 글을 본 적이 있어요. -그것이 한국적인 특수성이라고 할지라도- 그리고 그 세대가 지나 새로운 기술을 배운 학생들이 그 자리에 오를 때 마이크로소프트의 시장 점유는 자연스레 커질 것이라는 예측이었죠.
실제 원인이야 어쨌든, 많은 개발 플랫폼 벤더들이 학생 지원을 아끼지 않고 있다는 사실을 보면 앞서 말한 것이 더욱 의미 있게 다가오네요. 여튼 소프트웨어의 세상은 변화가 커서 혼란을 겪기도 하지만 그 안에서 역동적인 흐름과 재미를 찾을 수도 있어서 좋은 것 같아요. 부디 이런 훌륭한 툴들을 무료로-당당하게- 쓸 수 있는 학생들이 소프트웨어에 대한 재미를 찾고 열정을 갖게 되길 바래요.
분명히 개발자에게 .NET 프레임워크 소스의 접근과 디버깅은 전에 없었던 엄청난 사건이고 엄청난 메리트를 가져다 줄거에요.
사실 지금도 Reflector for .NET을 사용하여 대략적인 구현에 접근하고 동작을 이해할 수 있었지만 리플렉터랑 비교도 되지 않는 것은 바로 VS IDE상에서 완전히 통합되어 디버그 레벨까지 지원한다는 거죠. 게다가 리플렉터로는 알 수 없는 정확한 코드와 주석(!!)이 포함되어 있잖아요!
그렇다면 과연 MS가 .NET 프레임워크의 소스를 공개하여 얻을 수 있는 이득은 무엇일까요?
우선 대외적인 이미지 쇄신이 있겠죠. 최근 들어서 하게된 생각인데 오픈소스코드 진영을 제외하면 지금의 MS는 가장 개방적인 개발 환경과 정책을 사용하고 있는게 아닌가 싶어요. 닷넷 라이브러리의 소스코드 공개가 단지 '볼 사람만 봐라' 이런식이 아니라 누구에게나 공개적이고 공평하게 VS 2008로 통합되어 제공되기 때문이죠.
.NET 라이브러리 품질의 향상도 얻을 수 있을거에요. 제 아무리 MS의 개발자가 뛰어나다고 해도 세상에는 더 뛰어난 고수들이 있잖아요? 아마도 그들은 닷넷 프레임워크의 형편없는 코드나 버그를 찾아낸다면 가차없이 비웃으면서 더 나은 코드 구현을 공개할거에요. MS로서는 약간의 비웃음만 감수하면 그런 걸 공짜로 얻을 수 있게 되는거죠.
그리고 제 생각에 가장 큰 메리트는 앞으로 리눅스에서 닷넷 프레임워크를 구현하는 MONO와 같은 프로젝트가 더욱 가속화될 것이라는 점이에요. 확실치 않지만 MONO는 리플렉터 노가다를 통해 구현된 걸로 알고 있는데요, 정확한 구현까지 공개되었으니 MONO 팀은 지금쯤 만세를 부르고 있을지도 모르죠. 게다가 리눅스에 그치지 않고 MAC용 닷넷 프레임워크, 특수 모바일용 닷넷 프레임워크, 심지어 PS3와 같은 게임기에도 닷넷 프레임워크를 이식할 수 있는 가능성이 열리는거죠. 누가 그딴 작업을 하겠냐고요? 세상엔 단종된지 10년도 넘은 게임기의 머신 코드를 소프트웨어로 구현하는 작업을 하는 사람도 있어요!
이번 사건은 MS의 커다란 정책 변화와 함께 닷넷 프레임워크가 이미 윈도우즈 프로그래밍을 장악했다고 확신하는 자신감을 보여주는 것 같아요. 보는 시각에 따라서는 MS도 발등에 불이 떨어져 허둥대는 것처럼 보일지도 모르지만요^^
여튼 스캇 아저씨가 포스팅 한 것이니 '아님 말고'로 끝나진 않을거라 믿어요. VS 2008이 더욱 기대되네요!
음... 소스 유출이라면 어떤 부분을 말씀하시는건지 잘 이해가 안가네요^^;
닷넷 프레임웍에서 돌아가는 어셈블리는 지금도 어차피 리플렉터로 거의 대부분을 까볼 수 있는 상태라서 기껏해야 난독기로 보호하는 수준이라고 알고 있거든요.
이것은 자바 프레임웍도 마찬가지인걸로 알고 있고요.
혹시 구체적인 문제점이나 이슈가 있다면 알려주세요.
라이센스 상으로 보자면 MONO와 직접적인 관련은 없을지도요; VS 2008로 제작한 소프트웨어에 한해서 디버깅이나 성능향상등의 목적으로 소스코드 참조를 허락하는 라이센스인지라..
라이센스는 아래 주소에 있습니다;
http://www.microsoft.com/resources/sharedsource/licensingbasics/referencelicense.mspx
Submit comment.
"지하 동굴에서 바라보는 나무와
고층 빌딩 꼭대기에서 바라보는 나무는 다르게 보일 수밖에 없잖아요? ^^"
'난 비유 반댈세!'
장난이구요! 저는 황리건 과장님하고 조금 생각이 다릅니다.
MS의 트리와 Adobe의 트리의 차이점은 아래로 쌓아나가는가, 위로 쌓아나가는가일 뿐이지,
본질적으로 그 약속에 따라 보여주려고 하는 모습에는 큰 차이가 없잖아요.
MS의 객체 트리는 자료구조에 충실하게 표현했다고 생각하구요. (MS가 그동안 하던대로)
폴더 트리처럼 나중에 생긴 객체가 기본으로는 아래에 달리는 거죠.
반면, Adobe의 레이어 트리는 현실을 충실하게 표현했다고 생각해요.
현실에서는 아래쪽에 있는 종이를 위에 있는 종이가 덮는 게 (개발자에게 조차도) 친근하죠.
공도씨의 맺음말에 공감합니다.
네 오브젝트의 관점에서는 그렇지만 진짜 나무는 위로 자라잖아요. 그래서 오브젝트 트리의 뿌리가 '상위'라고 표현되는게 개념상 헤깔릴 여지가 있는 것 같아요.
제 생각에 MS와 Adobe의 관점의 차이라고 하기보다는 개발자와 디자이너의 관점의 차이가 맞는 것 같네요. 항상 개발자와 디자이너의 간격이 좁혀지지 않는 이유 중에 하나가 그 것이거든요. 디자이너는 그림을 그릴 때를 봐도 전체 스케치를 통해서 점점 세부 내용을 구체화 시켜 가는 한편, 개발자는 코드 하나, 부품 하나를 서로 엮어서 전체를 완성해 나가는 것처럼 말이죠.
네.. 사실 처음에는 아래에 있는 사진을 먼저 붙여놓고 제목걸고 글 쓰다가... 다 써놓고 보니 그렇게 되었네요;
결론은 다크나이트 빨리 보고 싶다는거 :D
제가 찾던 좋은내용입니다. 담아가겠습니다^^
나무의 개념보다는 아버지와 자식관계가 더 개념상 적합하지 않을까요??
실제로 parent child 개념도 있잖아요..
여러개의 오브젝트가 있을때.. 관계도를 그려보면 실제로 그 뿌리는 증조할아버지에서 시작해
할아버지 - 큰 아버지 - 작은 아버지, 또 그 아버지의 자식들의 자식들.. 이런식으로 개념도를
그려보면 하나의 엘리먼트가 가지고 있는 다른 엘리먼트들이 자기 자식들 같은 느낌이 듭니다.
그런데.. 다시 생각해보니까... 아버지가 죽는다고 해서 아들이나 또는 그 아들의 자식이 따라 죽진 않겠군요...;; 낳기는 했으나 죽을때도 같이 따라죽진 않으니.. 트리개념과 비교하기엔 무리가 있네여..;;;