모노는 어떻게 될것인가?

현재 자바는 대부분 웹관련 시장에 포진해 있습니다. 그렇지만 일반 사용자가 사용하는 데스크탑 응용프로그램은 그다지 많지 않습니다.

닷넷의 경우 닷넷을 구성하는 라이브러리(클래스)를 살펴보면 Windows.Form이 핵심입니다. 닷넷 기반 언어인 C#혹은 VB.NET은 언어 자체가 GUI 프로그래밍을 위해서 존재한다고 해도 틀린말은 아닙니다. 물론 객체지향과 콤포넌트 기술의 발전으로 ASP.NET같은 웹 서비스도 통합되었습니다.

데스크탑 환경에서의 효용성이 자바와 닷넷의 근본적인 차이점입니다.

여기서 모노는 Windows.Form을 제외한 부분을 구현한 1.0을 릴리즈 했습니다. 모노가 ASP.NET 미는것 처럼 보이는 이유는 별거 없습니다. 그냥 리눅스에서 이런것도 된다. 정도입니다. 중소형 규모의 단일 웹 사이트 구축에는 아주 좋은 환경임에는 분명합니다. 하지만 대형 프로젝트 같은경우 자바를 쓰지 모노를 쓸 이유가 없습니다.

그래서 ASP.NET으로는 현재 확고한 위치를 차지하고 있는 자바기반의 웹, 어플리케이션 서버 시장을 무너뜨리기에는 매우 힘들다고 생각됩니다.

모노는 일단 ASP.NET으로 광고효과를 낸 뒤, 오픈소스 데스크탑 GUI 프로그래밍쪽의 환경을 변화시킬 계획인 것이죠. 현재 매우 부진한 자바의 GUI로는 큰 성과를 거두지 못하고 있습니다.(기술적으로 어떻든 간에 아무도 안쓰니까.)

게다가 GTK+ 프로그램은 C로 프로그래밍을 해야 하기 때문에 GUI를 프로그래밍 하기는 쉽지가 않습니다. (쉽다고 반론할지도 모르겠지만 순수 Win32 API가지고 메모장을 만드는것과 C#과 IDE로 한두번 그려서 만드는것 중 어느것이 쉬운지는 두말 안해도 아실겁니다.)

미겔이 모노 세미나를 열었을때 가장 처음 한 것이 ASP.NET 어쩌고 저쩌고가 아닌 모노 디벨롭을 이용한 빠른 GUI 응용프로그램 개발이었습니다.

모노는 GTK#을 계속 발전시켜서 Windows.Form의 공백을 메꿀것입니다. GTK#은 GNOME 데스크탑 환경, 기타 오픈소스 환경에 딱 맞습니다. 물론 Windows위에서도 별탈 없이 잘 돌아가니깐 이것보다 좋은것은 없죠. 물론 Windows.Form도 구현하겠죠. 이건 시간이 오래 걸리는 문제라 두고봐야 할 문제고요.

모노가 외치고자 하는 것은 우리(오픈소스 진영)도 쉽고 강력한 언어와 IDE툴을 가져보자. 입니다.

예를들어 SF.net의 전체 다운로드 순위 4위인 Azureus나 MLDonkey의 공식 GUI 클라이언트인 G2GUI, RSSOwl 등이 그런 가능성을 보여주고 있습니다.

GTK#의 최대 강점은 언어중립적인 닷넷 플랫폼의 특성을 이어받아 오픈소스 개발자들이 널리 쓰는 다양한 언어를 지원한다는 점입니다(물론 닷넷 API를 다양한 언어의 문법으로 개발한다는 효용성에 대한 논란은 있을 수 있습니다).

반면 SWT의 경우 기본적으로 자바 종속적이라는 단점이 있지만 무엇보다 GTK#과 달리 리눅스, 맥, 윈도우즈 등에서 네이티브 위젯을 사용한다는 장점이 있습니다. 현재 SWT를 제외하고 이런 기능을 지원하는 오픈소스 툴킷은 제가 아는 한 wxWindows 밖에 없습니다. 자바의 경우 이미 Java-GNOME이라는 공식적인 그놈 바인딩이 있으며 기본적으로 GTK#과 동일한 기능을 갖습니다. 다만 자바의 경우 SWT의 네이티브 툴킷 지원이나 RCP와 같은 상위구조, 그리고 최근에는 이클립스 VE와 같은 위지위그 개발환경을 가지고 있기 때문에 굳이 Java-GNOME으로 리눅스 GTK에 최적화된 어플리케이션을 제작할 이유가 없을 뿐입니다.

어쨌든 특별한 이벤트가 없는한 서버측은 J2EE와 MS.NET의 싸움이 당분간 지속될 것이고 윈도우즈 클라이언트에선 MS.NET이 주도하는 가운데 SWT, GTK/GTK#, WX 등등을 사용한 오픈소스 어플리케이션이 속속 등장해서 MS.NET을 위협할 것입니다. 리눅스의 경우 모노의 영향으로 GTK#의 사용이 꾸준히 늘어날 것으로 보며 기존 GTK+/QT와 경쟁할 것이라고 생각합니다.

가능성이 있는것과 이미 GUI를 전제로 만들어진 닷넷은 비교대상이 되지 못합니다.

점유율 측면에서 보더라도 현재 Windows를 끼고 가는 것과 혼자 노는것은 천지차이니깐 말이죠. :wink:

위협한다기 보다는 대부분의 GUI 툴킷들이 닷넷기반으로 이전하겠죠. 이미 GTK#과 WX.NET이 있죠.

Win32 GUI의 경우 지금이나 예전이나 MFC가 버젓히 존재 하지만 볼렌드의 VCL을 많이 쓰는것이 한 예이죠.

GUI는 어떻게 하던간에 Windows위에서 놀려면 닷넷 프레임워크 안으로 흡수될수밖에 없습니다..

WinForms는 Wine Library로 구현한다고 되어있었던 것 같은데,

제가 알고 있는 것이 틀린 것인가요 ?

저게 사실이라면 거의 구현된 거나 다름없는 것이 아닌지 ..

Wine 라이브러리가 그리 썩 좋은 물건이 아니라서 Wine을 배제하고 순수하게 새로 Windows.Form을 구현하기로 결정났습니다.

vacancy님께서 모노의 WinForms는 WINE 기반이기 때문에 이미 구현된거나 마찬가지라고 말씀하셔서 그 차이점을 설명 드린 것입니다. 그리고 와인이 윈도우즈 클론을 만드는 프로젝트라고 한적은 없습니다. 윈도우즈 API의 클론(재구현)이라고 표현했고 이는 와인 홈페이지에도 나와 있습니다.

모노에 있어서 GTK#과 WinForms의 위상은 상당히 애매모호 합니다. WINE 기반 WinForms가 개발 목적이 아니라면 결국 모노는 GUI 개발에 있어서는 MS.NET과의 호환을 포기해야 합니다. 실제 모노 개발자들이 WinForms를 이용한 개발을 어떻게 생각하는 지는 아직 모르겠습니다. 메일링에서 WinForms를 이용한 샘플 스크린샷을 보기도 했고 어쨌든 리눅스 개발자 입장에서 자신이 만든 프로그램이 윈도우즈에서도 네이티브하게 보인다는 건 큰 매력이니까요. (방금 보니 pyrasis님께서 올리신 글에 WINE 기반을 버리고 새로 구현한다는 내용이 있군요. 어쨌든 제 글의 의도는 충분히 전달 됐으리라고 봅니다)

어쨌든 지금으로서는 모노기반 WinForms를 이용한 개발은 viable한 접근이 아니라는 걸 말씀드린 겁니다.

표준으로 발표된 부분은 닷넷 플랫폼의 극히 일부일 뿐이고 앞에서 계속 이야기한 WinForms 조차도 완전히 MS 마음대로 개발될 뿐입니다.

pyrasis님께서는 MS의 제품을 베끼는 것의 문제가 MS가 하위 호환성을 깨는 경우에 국한해서 생각하고 계시지만, 닷넷 프레임워크의 전체가 표준화 기구에 의해 정의되지 않고 MS보다 모노가 먼저 닷넷 API를 확장하고 이를 업계에서 defacto standard로 받아들이는 날이 오지 않는 한 이러한 위험은 상존하고 있습니다.

두분의 열띤 토론 잘 봤습니다. 배운것도 많구요.

한분은 모노가 결국 한두박자늦은 MS clone이 될 뿐 오픈소스진영에 도움은 절대 되지 않는다고 판단 하시는거군요(물론 GTK등, 독자 API를 공세적으로 주도하지 못한다면 이라는 가정을 두긴 하셨지만요)

또 한분은 모노를 오픈소스진영이 얼마든지 긍정적으로 활용할 수 있다고 판단하시는 거구요.

결국 개인적인 믿음의 문제인가요. 우리는 MS의 탐욕적이고 노련한 마케팅전략을 이미 알고 있고요. 그럼에도 '윈도우를 배우자'는 이만용씨의 언급(http://www.zdnet.co.kr/news/column/mylee/0,39024739,10066095,00.htm)이 무엇을 의미하는지도 알고 있습니다.

닷넷 개발자로서 저의 생각은요. 제가 만든 프로그램이 리눅스에서도 잘 돌아갔으면 좋겠어요. 저의 고객에게 리눅스도 가능한 머신으로 추천하고 싶기도 하고요. (물론 아직멀었습니다. com도 않돼 com+도 않돼 .... ㅋㅋ)

다양한 선택가능성이야말로 오픈소스 리눅스가 가진, 윈도우에는 없는, 생명력아닌가요.

결국 모노가 MS의 닷넷보다 항상 한두버전 늦기만한 클론신세라고 해도.
이미 우리는 더 많은걸 가지고 있지않나요.

특히 IE의 JScript와 넷스케이프 자바스크립트와의 공통 분모인 ECMAScript의 경우, 이름에서 보듯이 닷넷과 마찬가지로 ECMA에서 관리되는 표준입니다. 이런 상황만 놓고 보면 MS가 표준을 충실히 지키고 버전이 올라갈 때 하위호환성만 깨뜨리지 않는다면 아무 문제가 없어 보입니다.

하지만 실상은 전혀 그렇지 않습니다. 바로 문제는 표준으로 관리되지 않는, 하위호환성과 관계없이 MS가 임의로 추가하는 확장 기능입니다. 즉, 최소한의 공통분모인 ECMAScript와 DOM 인터페이스만 건드리지 않는다면 웹페이지에서 HTC를 쓰건 스크립트를 액티브엑스로 임베드하건 DirectX 필터를 쓰건 문제되지 않는 다는 점입니다. 특히 축약된 DOM 표현식과 같이 호환되지 않을 경우 웹사이트 이용 자체가 불가능해질 수 있는 기능들은 인터넷에서 MS의 독점적 지위를 지키는 핵심적인 역할을 합니다.

MSDN의 웹 관련 섹션을 보셨는지 모르지만 IE5에서 IE6에 이르기까지 정말 셀수도 없는 많은 비표준 IE 전용 확장들이 등장했습니다. 레퍼런스에는 어떤 기능이 IE 전용이고 어떤 기능이 다른 브라우저와 호환되는지 명확하게 밝히지 않고 있습니다. 바로 이런 전략에 특히 표준이나 접근성에 대한 인식이 부족하고 보통 촉박한 프로젝트 기간에 쫓기는 국내 개발자들이 걸려든 결과가 바로 지금의 IE 전용 사이트가 판치는 우리나라의 인터넷 환경입니다.

과연 이게 모노/닷넷과 전혀 무관한 이야기일까요?

아시다시피 데스크탑 응용프로그램과 웹기반 응용프로그램, 그리고 기업용 응용프로그램을 만드는데 각각 핵심이 되는 WinForms, WebForms/ASP.net, ADO.net은 ECMA 표준이 아닙니다. 즉, 모노가 이들 API를 그대로 가져다 베낄 수는 있지만 이들 API 설계에는 어떠한 영향력도 행사할 수 없고 여기에 어떤 확장 기능을 가져다 붙여도 그건 MS 마음대로 입니다.

MS가 무슨 '악의 축'이라도 되는 건 아니지만, 자사의 이익을 위해 표준을 내세워 교묘하게 경쟁 기술을 사장시키려는 시도는 이미 IE와 J++에서 명백히 보여준 바 있습니다. 지금 당장 MS가 모노에 우호적인 태도를 보이는 것은 당장 MS의 가장 큰 적은 모노가 아닌 자바이고 더구나 리눅스에서 구동되는 어플리케이션은 MS의 직접적인 시장이 아니기 때문입니다. 그런 점에서 모노를 통해 후발 기술인 닷넷으로 업계의 모멘텀을 끌어들이고 오픈소스를 지원하는 모습으로 개발자들에게 우호적인 이미지를 심어줄 수 있다면 MS입장에선 절대 손해보는 일이 아닙니다.

만일 MS가 리눅스나 유닉스 시장에 관심을 갖거나 윈도우즈 플랫폼에서 모노가 무시할 수 없는 경쟁상대로 부각되는 즉시 MS의 태도는 180도 달라질 것으로 믿습니다.

분명 IE/Jscript와 마찬가지로 MS는 자사의 닷넷 기술에 여러 비표준 확장 기술을 덧붙이고 아발론 같은 윈도우즈 플랫폼에 종속적인 기능과 연동하려 할 것입니다. 윈도우즈를 쓰는 웹개발자가 모질라 등에 무관심하듯, 대부분의 닷넷 개발자들은 자신의 응용프로그램이 리눅스/모노 위에서 동작하는 지 보단 보다 더 편리하고 강력한 MS가 제공하는 기술을 배우고 따라하기 바쁠 것입니다.

그렇게 된다면 어차피 많은 수의 윈도우즈 응용프로그램은 모노에서 정상적으로 동작하지 않을 것이고 모노는 불완전한 MS.NET의 클론으로 남을 수밖에 없습니다.

이러한 결과를 피하는 것은 애초에 모노를 와인과 같이 윈도우즈 응용프로그램을 구동하는 역할에 충실하도록 방향을 전환하거나 아예 MS.NET과의 호환을 무시하고 CLI/C#이라는 공통분모만 남긴채 그 위에 구현하는 API는 완전히 독립적인 노선을 택해야 한다고 봅니다.

제가 볼 때 모노는 이와 같은 커다란 잠재적 문제를 안고 있음에도, 모노를 리드하는 미구엘의 경쟁 기술에 무지하고 MS의 마케팅 구문을 앵무새처럼 따라하는 모습이나 메일링 등에서 이런 문제를 지적할 때마다 '닷넷은 ECMA표준이고 모노는 GPL이다'만 반복하는 모습 등에서 개인적으로 전혀 신뢰가 가지 않습니다.

"MS.NET을 1:1로 베낄 이유는 없다고 봅니다만"
이 말 자체가 저는 자존심 싸움으로 밖에 보이지 않습니다.
앞서 말씀드렸듯이 이런것은 진정한 사용자를 위한 태도가 아닙니다. 프로그램은 사용자가 쓰는 것이지 개발자만 쓰라고 있는것이 아니니깐요.
미겔을 비롯한 모노 지지자들이 MS가 이뻐서 MS 기술을 그대로 구현하려고 하는게 아니라는걸 잘 아실겁니다. 이 사람들은 사용자가 무엇을 원하는지 잘 파악했기 때문입니다.

노벨의 통제를 받건 받지 않건 그건 별 상관 없을듯 하군요. 어차피 지미안도 영리를 추구하는 회사였고 미겔의 뜻과도 잘 드러 맞았기 때문에 노벨과 한몸이 된것이죠.
지미안 제품군을 봐도 MS Exchange 커넥터 같은 MS 제품을 위한 상품도 개발을 한적이 있죠.

그리고 쓰라고 있는 API를 따로 구현하는 행위는 법적으로 아무런 문제가 없습니다.

ASP.NET에 왜그리 집착하시는지 모르겠군요. ASP.NET은 그냥 한 부분일 뿐이지 다른 대체 수단은 얼마든지 있습니다.(잘 아시는 자바 관련 제품들이 엄청나게 많이 있죠.)ASP.NET은 그리 비중있는 논제가 되지 못합니다.

매번 그다지 정확하지 못한 근거로 위험하니 어쩌니 불안감만 조장하지 마시고 진짜로 우리 오픈소스 진영에 도움이 되는쪽으로 생각했으면 합니다.
제가 보기엔 큰 문제가 없는데도 계속 위험하니 문제가 있니, 계속 그러면 모노에 대해서 잘 모르시는 분들은 정말 그런지 오해할 수도 있으니깐요.

당시 MS가 규모가 어쨌든 간에 그게 어떻게 모노가 오픈소스 커뮤니티에 미치는 영향에 대한 논쟁의 근거가 되는 지 이해가 가지 않습니다. 또한 모노가 MS.NET의 비표준 API를 1:1로 베끼는 것에 대한 반박으로 MS-DOS와 WindowsNT를 드셨는데 MS는 오픈소스 커뮤니티도 아니고 CP/M이나 VMS가 기술 표준도 아니며 MS-DOS나 WindowsNT가 이들 기술의 호환을 목적으로 API레벨에서 1:1로 베끼지도 않았습니다. 이 부분은 pyrasis님께서 더 설명을 해주셔야 할 것 같습니다.

왜 모노가 비표준 API를 포함한 독점 기업의 기술을 1:1로 베끼는 것이 위험한지에 대한 제 주장은 이미 수 차례 반복했기 때문에 다시 쓰진 않겠습니다.

제가 pyrasis님에 대해 안타깝게 생각하는 건, 저의 주장의 핵심되는 내용 및 그 근거에 대해서는 전혀 언급 조차 안하시면서, 반대로 지엽적이거나 지극히 방어적이고 공격적인 대응 - 예를들어 근거로 든 예가 너무 일반인에게 친숙하지 못하다거나 저의 주장이 무작정 별로 정확하지 못해서 있지도 않은 위험을 부풀린다거나 하는 식의 발언을 통해 비생산적인 토론을 유도하고 계시다는 점입니다.

이 토론을 감정 싸움이나 플레임으로 만들고 싶지 않으시려면 부탁드립니다만 먼저 제가 예전에 적은 글과 이 쓰레드에서 주장한 내용을 먼저 정확히 읽고 이해한 다음에 근거를 들어 논리적으로 반박해 주셨으면 합니다.

논쟁이 이렇게 가면 잘못하면 그냥 말꼬리 잡는 식의 논쟁밖에 되지 않습니다...

그럼 전세계에서 90% 이상의 사용자들이 쓰는 Windows를 표준 OS라고 할 수 있습니까?

표준, 비표준의 의미는 국제 규약을 따르는지... 사용해도 나중에 LICENSE 문제 등 불필요한 부분 때문에 신경쓰지 않아도 되는지... 그런 의미로 이해하는 것이 좋지 않을까요?

괜히 제가 디지탈 리서치, DEC를 예로 들어서 한순간에 바보가 되는 상황이 되었지만

제가 세세한 기술까지 들먹이지 않는 이유가 있습니다.

fender씨처럼 전문 분야의 세세한 기술적 용어를 들먹이면서 그럴싸하게 주장을 계속 해댄다면 잘 모르는 사용자 입장에서는 믿을수 밖에 없습니다.

그래서 저는 언제나 사용자 입장에서 생각하도록 노력하고 있습니다.

RFC 2026, "인터넷 표준 절차" (Internet Standard Process) 관련 부분을 인용합니다.

4.1.2 Draft Standard

A specification from which at least two independent and interoperable implementations from different code bases have been developed, and for which sufficient successful operational experience has been obtained, may be elevated to the "Draft Standard" level. For the purposes of this section, "interoperable" means to be functionally equivalent or interchangeable components of the system or process in which they are used. If patented or otherwise controlled technology is required for implementation, the separate implementations must also have resulted from separate exercise of the licensing process. Elevation to Draft Standard is a major advance in status, indicating a strong belief that the specification is mature and will be useful.

적어도 두 개의 서로 독립적이고 호환되는 구현물이 존재하고 이들 구현물 사이에 충분한 호환성이 검증되었다면, "Proposed Standard"는 "Draft Standard"로 전환될 수 있다. 호환성이 있다 함은 기능적으로 동일하여 (functionally equivalent) 대체될 수 있음(interchangable)을 뜻한다.

--feanor

mono로 만든 프로그램들. 그러나 MS .NET이라기 보다는 mono로 만든 GNOME 프로그램들.

tomboy

Unofficial Beagle and Dashboard Development Wiki
Dashboard
beagle 스샷

muine 음악 연주기

그림관리 및 편집 툴 f-spot

RSS reader blam

체스 게임 WoodPusher

닷넷 애플리케이션의 스크린샷이 이 토론과 무슨 상관이죠? 토론 물 흐리려고 일부러 그러는 것 같아서 보기가 좋지 않군요.

단지 GNOME 공동체에서는 mono를 MS Window에서도 돌아가는 닷넷 애플리케이션(?)를 만들기 보다는 GNOME 개발 언어중 하나로써 사용한다는 것을 보이기 위해서 스크린 샷을 남겨습니다.

토론의 접점이 맞지 않는다는 생각입니다.

한 분은 모노 1.0에 구현된 콤포넌트들이 리눅스 데탑의 GUI 개발 환경에 도움이 될 것이라는 주장이시고, 다른 한 분은 모노 2.0에서야 어쩌면 제대로(?) 구현이 될 ASP.NET 과 Windows.Forms의 기술 기반에 대해서 이야기를 하셨습니다. 그리고 표준 기술에 대한 이야기로 넘어 갔고요.

모노의 미래에 대한 토론이라면, 주제를 좁혀서 토론을 시작해 보는 것이 좋지 않을까요? 현재의 가치가 무엇이냐 부터요.
예를 들어 (우선은 알고 싶은게), 리눅스 상의 데스크탑 어플리케이션 개발시, C#과 GTK#의 조합이 다른 여타의 (Java/SWT, C/GTK, C++/QT 등)조합에 비해 강점을 가지는가?
나아가, 크로스플랫폼에서는 어떤가?
얼마만큼의 완성된 IDE를 포함한 개발 환경을 제공하는가?
현재의 결과물의 품질은 어떻고 개발의 용이성은 어느 정도 인가?

제 개인 생각으로는, 모노의 미래는 궁극적으로 개발자의 선택에 달려 있다고 보고, 시대를 꺼구로 가는 이야기 일지는 몰라도 데스크탑(특히, 리눅스상) 어플리케이션의 수요에 직접적으로 연관이 된다고 봅니다. 이 관점에서, 위의 토론 내용중에는 pyrasis님의 의견에 동의하는 편입니다.

그리고 모노에 대응할 만한 기술이 리눅스에 이미 있었다면 모노가 이슈가 될 리가 없습니다. 그렇지 않나요? 모노의 대안으로 자바를 얘기하는데, 자바도 모노와 아주 똑같은 문제점이 있는데 그 얘긴 쏙 빼고 모노의 단점만 부각시키면 공정한 주장이 아니죠. 그래서 결국 모노가 안된다면 대안이 뭐냐는 것입니다. 모노를 반대하는 분들은 대안을 이야기하지 못합니다.

그리고 재차 강조하지만 전 모노의 대안이 GCJ나 썬의 자바라고 생각하지도 않고 이 쓰레드에서 그런 주장을 한 적도 없습니다.

애초에 모노가 주목받게 된 것에는 여러 이유가 있지만, 대체적으로 특히 최근에 대학에서 자바와 같은 고급언어를 주로 가르치기 때문에 이러한 학교를 졸업한 신세대 프로그래머들을 리눅스 쪽으로 흡수해보자는 취지도 있고, 무엇보다 MS 진영과는 달리 리눅스 쪽에는 어떤 표준화된 타입 시스템이나 여러 언어가 공통으로 사용할 수 있는 라이브러리, 인터페이스가 부족하다는 점이 모노가 그 대안으로 떠오른 큰 이유입니다.

개인적으로 그런 주장의 타당성은 인정하지만 과연 그게 지금 당장 MS.NET을 1:1로 베끼거나 자바냐 닷넷이냐 양자택일을 강요할 정도로 시급한 문제라고 생각하지 않습니다. 왜냐하면 이러한 주장과는 반대로 리눅스나 오픈소스의 점유율은 계속 증가해왔고 지금도 리눅스 프로그래머가 부족하거나 GTK/QT 응용프로그램이 없어서 윈도우즈와 경쟁이 안되는 상황이 아니기 때문입니다. 제 생각에 MS.NET과 자바의 싸움은 앞으로 1년 사이에 어느 방향으로든 결정이 날 것으로 봅니다. 이미 GTK의 경우 파이썬, C, C++, 자바, C# 등 수많은 언어의 바인딩이 존재하고 자바나 닷넷 코어 플랫폼이 제공하는 라이브러리는 대부분 어떤 형태로든 구현되어 있습니다.

그렇다면 지금 필요한 건 지금 처럼 꾸준히 오픈소스의 입지를 강화하면서 썬의 자바나 MS의 닷넷과 비교할 만한 오픈소스 플랫폼을 생각하거나 아니면 자바나 닷넷과 관련한 비표준, 독점 이슈들이 어느 정도 정리 될 때까지 기다려도 늦지 않다고 보는 입장입니다.

일단 리눅스도 이제는 윈도우즈 데스크탑 시장을 잠식해 가야하는 상황에 접어든 것은 사실입니다. MS가 리눅스를 이제는 위협으로 인식하고 있다는 사실은 이제 공공연한 상식이 되었습니다.

보통 데스크탑 환경을 얘기할 때 우리는 사용자들이 리눅스를 쓰느냐 쓰지 않느냐에 관심을 많이 가집니다. 그리고는 아무리 리눅스가 기능이 좋더라도 일반 사용자들은 널리 쓰이고 손에 익은 윈도우즈를 쓰지 리눅스를 쓰지 않는다는 현실에 직면하게 됩니다. 소프트웨어 시장에서 네트워크 효과와 거기에서 비롯되는 과도한 스위칭 비용은 후발 주자에게는 극복하기 어려운 진입장벽인 것이 사실입니다.

그러나 이것보다 더욱 문제가 되는 것은 개발자들의 스위칭 비용입니다. 현 상황에서 윈도우즈 개발자가 리눅스용 어플을 개발하려면 결국 KDE나 Gnome 어플을 개발할 수 밖에 없고, 이는 곧 QT나 GTK+부터 새로 배워야 한다는 것을 의미합니다. 사실, 이런 상황에서 윈도우즈 개발자들이 리눅스로 플랫폼을 바꾼다는 것은 상상하기 어렵습니다.

모노는 이런 상황에서 윈도우즈 개발자들을 리눅스로 끌어들일 수 있는 가능성을 보여줍니다. 적어도 윈도우즈에서 MS.NET 어플 개발자라면 모노 덕분에 자신의 어플을 Gnome 환경으로 포팅하는 것을 심각하게 고려해 보게 될겁니다.

여기서 하나 또 생각해 볼 것은 윈도우즈 개발자들의 엄청난 숫자입니다. 상식적으로, 윈도우즈 개발자 10명 중 1명, 아니 100명중 한 명만 자신의 어플을 모노에 포팅한다고 하더라도 이 숫자는 아마 상당한 수준이 될 것이고 이는 임계점을 넘어서는 모노 개발자 커뮤너티의 형성으로 이어지게 되어 있습니다.

일단 여기까지만 모노가 성공적으로 자리를 잡는다면 그 이후로는 MS가 적으로 돌아서서 MS.NET의 표준을 바꾸어 나가더라도 별 문제가 없습니다. 그 때쯤이면 모노 사용자 커뮤너티가 자신들의 표준을 fork 해버리면 그만입니다. 자바의 경우는 썬이 적절한 선에서 자바에 대한 제어권과 자유로운 표준 개발 사이의 균형을 잘(?) 유지해 오고 있지만 자바 역시 썬이 지나치게 자바에 대한 제어권에 집착했다면 자바 개발자 커뮤너티에서 분명히 자바 컴파일러부터 완전히 새로 만들겠다는 얘기가 나왔을 겁니다. 한 때 Lignux라는 단어에 열받아서 gcc를 버리고 새 컴파일러를 만들겠다고 으름장을 놓는 저력이 있는 곳이 오픈 소스 개발자 커뮤너티입니다. 일단 임계점을 넘어 확산된 오픈 소스 플랫폼은 스스로 표준을 만들고 진화해 나갈 수 있는 저력이 충분합니다. 게다가, 윈도우즈 개발자 역시 MS가 주도하는 소위 패러다임 쉬프트를 항상 따라가야 하는데 상당한 불만을 갖고 있는 경우가 많습니다.

그런 의미에서 모노는 항상 MS.NET의 API를 쫓아가야하는 운명에 처해 있다고 보기 힘듭니다. 일단 최소 수준의 임계점까지만 모노가 확산되고 나면 그 이후에는 오히려 모노의 표준을 MS가 구현해야 하는 상황이 전개될 수도 있습니다. 중요한 것은 윈도우즈 개발자들이 모노용으로도 어플을 내놓는 것을 자연스럽게 생각하는 변화를 유도해 내는 것입니다.

리눅스 데스크탑은 결정적으로 윈도우즈에 비해 가격이 싸다는 장점이 있습니다. 아무리 MS가 윈도우즈의 가격을 내려도 공짜로 윈도우즈를 출시할 수는 없습니다. 게다가, 기업 환경처럼 오피스와 여러가지 솔루션들이 번들링되면서 가격이 천정부지로 솟는 경우는 비슷한 기능을 제공할 수 있는 경우 리눅스 데스크탑이 대안으로 쉽게 자리잡을 수 있습니다. 만약, Gnome 데스크탑이 모노덕택에 어플리케이션 공급의 측면에서도 윈도우즈용 어플을 고스란히 받아들여 돌릴 수 있다면 기업 환경에서는 똑같은 어플을 돌릴 수 있는데 굳이 돈을 더 주고 비싼 윈도우즈를 구매할 필요가 없게 됩니다. 이런 상황이 사실 제대로 된 리눅스 데스크탑 환경의 도래가 아닐까요?

그런 이유로 모노가 MS.NET을 "쫓아가는" 방식은 위험해 보여도 일단 힘을 실어줄 필요가 많다고 봅니다. 위험이 있어 보이지만 그만큼 성공했을때 예상되는 이득이 크며 윈도우즈 개발자들을 쉽게 리눅스 데스크탑 환경으로 이전시킬 있는 잠재력을 갖고 있습니다. 어차피 지금 상황에서 Gnome 환경이 윈도우즈로 포팅될 가능성도 없고, Gnome 데스크탑이 윈도우즈로 포팅되더라도 윈도우즈 개발자들은 Gnome 프로그래밍에는 관심이 없을 것이라는 상황을 고려한다면 모노가 거꾸로 윈도우즈를 따라가는 것이 적절한 접근 방법이라고 봅니다.

조금은 상황이 다르지만 애플의 매킨토시에서 현재 이러한 상황이 실제로 발생하고 있습니다. 맥의 오에스텐은 아시다시피 기본적으로 BSD 입니다. 여기에 애플은 아쿠아 데스크탑, 코코아 API 등등을 집어넣어 자신들만의 오에스를 만들었습니다. 물론, 맥 오에스텐 전용 어플은 코코아나 카본 API가 리눅스나 다른 BSD계열 유닉스에 포팅되어 있지 않기 때문에 다른 플랫폼에서 돌릴 수 없습니다.

그러나 애플이 오픈소스 환경에 free-riding해서 얻은 이득은 큽니다. 그중에서 가장 중요한 이득은 오픈 소스 어플의 오에스 텐 환경으로의 유입입니다. 어차피 이들 오픈 소스 어플들은 유닉스 기반이니 재컴파일 작업으로 오에스텐으로의 포팅이 끝이 납니다. 그리고 많은 경우 이러한 어플들 중의 상당수가 command-line 기반 오픈소스 어플에 코코아 그래픽 유저 인터페이스 frontend를 입혀서 내놓습니다. 이 덕분에 애플의 오에스 텐은 짧은 기간 동안에 많은 수의 어플리케이션을 확보할 수 있게 되었습니다. 오픈 소스 진영의 그 누구도 어플 개발시 오에스 텐 전용으로의 포팅을 심각하게 고려하지 않고 있는데도 말입니다.

마찬가지 상황이 모노에서도 발생할 개연성이 높습니다. 오에스 텐의 경우야 리눅스 역시 마이너 플랫폼이다 보니 소수의 리눅스 사용자의 오에스 텐으로의 유입이 맥 플랫폼의 입장에서는 큰 영향이 없습니다만 윈도우즈 사용자가 Gnome 환경을 윈도우즈 환경과 비슷하다고 여기게 된다면 그 여파는 상당할 것입니다. 모노가 지향하고 있는 윈도우즈 개발자의 유입은 그래서 관심있게 지켜볼 필요가 있습니다. 모노는 언제까지나 MS의 뒷걸음만 따라가야 하는 숙명을 타고 나지 않았기 때문입니다.

오픈소스가 중요하다, 아니면 시장점유율이 중요하다, 혹은 GTK/QT가 발전하고 있다 아니다는 보는 사람의 시각에 따라 크게 달라질 수 있는 부분입니다. 여기에 대한 이야기는 어떤 구체적인 근거가 없다면 더 이상 어느 쪽으로 의견이 좁혀지지 않을 것 같습니다.

어쨌든 중요한 점은 비표준 API를 통한 확장의 위험은 MS가 비표준 API를 공개하지 않을까봐서가 아니라 MS.NET과의 호환성을 목표로 하는 한 영원히 따라하기 게임을 벌여야 한다는데 있습니다.

결론적으로 정리해서,

(1) 저작권 측면에서 모노, GCJ/Classpath 등은 모두 GPL로 차이가 없습니다.
(2) Sun의 경우 자바와 관련된 모든 것이 표준화 기구는 아니지만 썬과 관련 없는 수많은 개인, 단체가 참여하는 JCP에 의해 관리 되고 있습니다. 반면 MS.NET은 ECMA라는 표준화 기구에 의해 관리 되지만 표준에 적용 받는 것은 C#과 플랫폼의 일부입니다.

오픈 소스 커뮤니티에서 오픈 소스가 아닌 걸 싫어하는 것은 당연합니다만, 그게 자바를 싫어할 이유는 되지 못합니다. freshmeat.net에 등록된 프로젝트 중 자바 프로젝트는 C에 이어 두번째로 많습니다. 물론 이게 다 오픈 소스는 아니지만 OSI 인증 받은 라이센스가 상당히 많고 GPL도 많습니다. Apache Group, Open Symphony, codehaus, eclipse, java.net 처럼 고품질의 자바 컴포넌트들을 쏟아내주는 커뮤니티도 많고요. 엔터프라이즈 컴퓨팅에서 이처럼 오픈 소스가 많은 언어는 자바 밖에 없습니다.

사실 따지고보면 리눅스와 자바는 반 MS 진영의 두 기둥입니다. 이 둘이 친해진다면 엄청난 시너지 효과를 낼 수 있을 꺼라고 보기에 리눅스 진영에서 자바를 평가절하하는 것이 못내 안타깝습니다.

참고로 지금은 Java-GNOME과 GCJ 모두 데비안에 들어가 있습니다. 사실 데비안과 젠투는 자바 지원이 꽤 괜찮은 배포판 중의 하나입니다.

어쨌든 말씀하신 대로 썬의 JDK/JRE는 오픈소스가 아니고, 썬이 오픈소스 진영에서 백안시 당하게 된 가장 큰 이유는 이제까지 자바의 오픈소스화에 대한 문제에 있어서 썬이 입장을 바꾸거나 불분명한 태도로 일관해 왔다는 점입니다. 그리고 초창기 자바가 등장했을 때 사람들의 기대감과는 달리 형편없는 위젯 지원과 느린 속도 등으로 첫인상이 매우 좋지 못하게 남았습니다. 그리고 상대적으로 C/C++을 배경으로 하는 오픈소스 개발자가 자바 언어에 대해 느끼는 반감도 무시할 수 없습니다.

이런 면을 볼 때 모노, ECMA, 그리고 C/C++ 개발자들이 친근감을 느낄 수 있게 하는 여러 장치들을 적절히 이용하는 MS의 뛰어난 마케팅 전략과 썬의 사실상 마케팅의 부재(솔직히 말하면 '삽질')가 맞물려 오늘과 같은 결과가 나왔다고 생각합니다.

자바의 미래를 위해선 썬이 자바를 오픈소스로 풀거나 IBM에 인수되는 것이 훨씬 낫다고 봅니다.

어쨌거나 썬의 삽질을 제외하면 저작권이나 대부분의 프로젝트가 오픈소스 JVM이 아닌 썬의 제품에 최적화 되어 있는 등의 문제는 MS.NET과 모노에도 그대로 적용되는 문제입니다. 다만 아직 표면화되지 않았을 뿐이라고 생각합니다. (참고로 여기에는 조금은 더 복잡한 문제가 걸려있습니다. 공식적으로 JVM 등의 스펙은 모두 공개적으로 관리되지만 이를 구현한 결과물에 '자바'라는 이름을 붙이기 위해선 특정한 자동화된 테스트를 통과해야 합니다. 특히 오픈소스에서 활용과 관련해서, 이 테스트 킷의 저작권이나 가격 등에 대한 논란이 있었습니다. 어쨌든 GCJ/Classpath나 Kaffe가 정식으로 certified되지 않는 한 엄밀하게 이들 제품은 '자바' 구현이 아닙니다).

그럼에도 creativeidler 님이 말씀하신 자바와 리눅스 진영이 친해지지 못한 아쉬움은 저도 공감하는 바입니다. 사실 최근 2-3년 사이 서버 시장에서 리눅스의 선전은 갑자기 PHP+MySQL 사이트가 늘어나서가 아니라 거의 J2EE의 성장에 힘입은 바가 크다는 건 명확한 사실이니까요...

표준과 자유로운 참조 구현의 중요성에 대해 예를 들어서 설명하고자 합니다. 앞에서 말한 "니가 틀렸다고 까댈 수 있는 자유"와도 일맥상통합니다.

http://httpd.apache.org/info/aol-http.html

1996년 HTTP 1.1 표준이 막 발표되었을 때, 아파치에서 보내는 정상적인 HTTP 1.1 응답을 AOL 프록시에서 차단한 일이 있습니다. 아파치에서는 자신들이 표준에 맞는 올바른 행동을 하고 있다고 선언하고는, AOL이 프록시 구현을 바꾸어야 한다고 주장했습니다. 자세한 내용은 링크를 보시기 바랍니다.

당시 아파치의 웹 서버 점유율은 약 30%였습니다. 이처럼 "개무시되지 않는" 자유로운 참조 구현이 있었기 때문에 HTTP가 현재와 같이 모두가 지키는 (지키려고 하는) 제대로 된 표준으로 자리잡을 수 있었다고 생각합니다.

--feanor

모노의 기술적인 미래를 보려고 왔는데, 결국 다른 이념으로 논쟁을 하는 수많은 오픈소스 진영의 정치적 싸움 밖에 보지 못하고 가는군요.

제가 오픈소스에 관심을 가지고, 현재도 관심을 가지는 이유는 개발자에게 주는 오픈소스의 즐거움이었습니다. 이러한 정치적인 싸움은 물론 오픈소스의 발전을 이룩하자는 의미도 있겠지만, 오픈소스 내의 자신의 영역을 확고히 하고자하는 욕심쟁이들의 땅따먹기 싸움으로 밖에 보이지 않는군요.

모노가 닷넷을 오픈소스화해보자는 순수한 재미에서 시작되었다면, 그 재미가 계속 지속되는한 모노는 아직 발전할 앞날은 창창하다고 할 수 있겠습니다. 하지만, 이러한 정치적 싸움에 휘말려 모노는 '미래가 없다'와 같은 인식을 오픈소스 개발자들에게 심어주면서 참여개발자들이 줄어든다면 여느 수많은 오픈소스 프로젝트처럼 자연스럽게 조용히 역사로 묻혀버리게 되겠죠.

오픈소스가 주는 장점을 더 키우기 위한 오픈소스 진영의 정치적 행동은 어디로 이어질지 궁금하며, 언젠가는 이러한 욕심으로 인하여 이 분야도 다른 더 새로운 개념의 운동에 의해서 탄압되는 날이 오기를 기원하면서 답변글을 마무리합니다.

Java와 뭐가 다르죠?

위 글들에서 .NET을 빼고 Java라는 말을 넣어도 거의 성립되는 글 같은 데요.

CrossPlatform으로 인해서 OS의 장벽이 무너진다는 얘기는 Java가 나올 시점부터 있던 이야기 입니다. .Net이라고 해서 Java보다 나은 뭔가를 보이기는 힘들 거 같은데요.

그리고 요즘 Linux도 예전에 비해서 상당히 고성능의 사양을 요구합니다. 그리고 Linux를 저사양에서 돌 수 있도록 만든다고 하더라도 .Net 자체가 고사양을 요구합니다. 그러면 당연히 고사양 컴퓨터를 써야 하죠. Java에서 문제점으로 지적되는 것들은 대부분 .Net에서도 문제점으로 지적될 수 있습니다. 거의 비슷한 구조를 채택하고 있기 때문일 겁니다.

위 글은 아마 .Net이 나오고 얼마 안된 시점에서 나왔을 법한 글이네요.