Skip to Content
×닫기

모바일메뉴

News

Location : Home News
일반

닷넷, 리눅스에 둥지 틀다 '모노 프로젝트'

posted 2017.03.31 20:39

모노 프로젝트를 만들어낸 미구엘 드 이카자는 3년간의 노력 끝에 MS 툴 중 최소한의 것들을 리눅스 진영에 일부 적용하는데 성공했다. 

그리고 지난해 지미안(Ximian)을 인수한 노벨이 모노 프로젝트를 이끌기로 결정됐기 때문에 이 프로젝트는 오픈소스 애호가들의 호기심 수준을 넘어 무시할 수 없는 잠재력을 갖게 됐다. 

모노는 MS의 비주얼 스튜디오와 같은 개발 툴이 아니다. 그보다는 MS 개발 툴의 근간 요소들에 접근할 수 있는 출입구라고 볼 수 있다. 여기에는 MS의 C#, 기작성된 라이브러리, 그리고 단일 애플리케이션에 여러 언어로 작성된 코드를 결합할 수 있는 MS의 CLR(common language runtime) 등이 들어 있다. 

드 이카자의 손에 의해 MS가 그간 공들여왔던 작업들이 복제되는 것은 개발자들에게 리눅스와 같은 다른 운영체제를 보다 매력적으로 만들 것이다. 비록 대부분이 표준기구인 Ecma 인터내셔널에 제출되긴 했지만. 또한 프로그래머들도 닷넷이라는 ‘범용 가상머신’을 이용해 언어를 선택할 수 있는 폭이 훨씬 넓어지게 됐다. 

작은 원숭이 봉제 인형-모노는 스페인어로 원숭이란 뜻이다-들로 장식된 사무실에서 드 이카자는 CNET 뉴스닷컴과 인터뷰를 가졌다. 이 인터뷰는 노벨이 모노 버전 1.0을 출시하기 직전에 진행됐다. 

모노 1.0이 완성됐다. 이젠 무엇을 하고 싶은가 
개발자들에게 있어 유닉스는 말 그대로 고통이 가득찬 세상이다. 이제 우리는 이기종 플랫폼을 이용해 소프트웨어를 개발할 수 있는 매우 현대적인 통합개발환경(IDE)을 갖게 됐다. 

예를 들어보자. 노벨에서는 모노 기술을 보자마자 아이폴더 3.0을 구현하는데 꼭 필요로 했던 것이라는 사실을 바로 알아차렸다. 나는 여기에 전혀 관여하지 않았다. 아이폴더 3.0은 데이터 동기화, 백업 등 롱혼의 윈FS처럼 여러 흥미로운 기능을 가진 새로운 버전이다. 

이 소프트웨어는 C++로 작성할 수도 있었다. 그러나 그랬다면 일정이 지연될 수도 있었을 것이다. 또한 C#으로 할 수도 있었지만 그렇다면 또 다른 윈도우가 됐을 것이다. 

바로 지미안을 인수하면서 노벨은 윈도우와 리눅스에서 동시에 수행되는 소프트웨어를 개발할 수 있는 선택권을 갖게 된 것이다. 따라서 현재 노벨은 동일한 툴에 기반해 윈도우, 리눅스, 맥 OS를 지원하고 있다. 

개발자들은 특정 플랫폼의 상세한 정보보다 자신이 개발하려 하는 것에 집중할 수 있다. 현재에도 모노와 관련해 많은 개발이 이뤄지고 있다. 노벨에서는 내부 개발자 플랫폼으로 모노를 중심에 두고 있다. 

모노는 MS가 표준화를 위해 ECMA에 제출한 기술을 옮겨놓은 것이다. 이 점을 고려할 때 MS, 그리고 MS의 개발 현황과 모노를 밀접하게 연계시키기 위해 어떻게 할 생각인가 
우리는 3년전에 출발해 2004년 중반인 바로 지금 모노 1.0을 출시했다. MS는 1년 반 이전에 제품을 출시했기 때문에 우리가 늦은 것은 분명한 사실이다. 분명 18개월이나 MS에 뒤쳐졌다. 그러나 우리는 출시해냈으며 사람들이 직접 사용하고 있다. 

나는 알란 콕스가 말한 “자유 소프트웨어는 항상 늦다”라는 구절을 좋아한다. 코드 작성에 나선다는 것은 당신이 필요로 하기 때문에 시작하는 것이다. 

또한 지금 작성하는 코드는 당장 필요한 것이지 개발이 끝나는 3개월이나 6개월 후에 필요한 것이 아니다. 이런 점 때문에 항상 미래를 미리 예상해 뭔가를 만들어야 한다. 자유 소프트웨어는 바로 이런 것이다. 

우리는 이미 닷넷 2.0의 기능들에 대해 작업하고 있다. 모노 1.0은 이미 개발이 끝났으며 패키징 작업 중이다. 그렇다고 해서 우리 팀이 앉아서 놀고 있는 것이 아니다. 방금 언급했다시피 이미 2.0 기능을 개발하고 있다. 한가지 예를 들자면 우리는 지금 MS와 함께 C# 2.0 명세에 대해 공동으로 작업하고 있다. 

MS는 Ecma에 닷넷의 업데이트 사항을 주기적으로 제출하고 있나? 
음, 비교적 잘 처신하고 있는 것 같다. 1.0의 모든 핵심 요소들을 Ecma에 제출했으며 닷넷 2.0용도 미리 제출하고 있다. MS가 첫 번째 범용 컴파일러 제품을 내놓았을 때 이미 우리도 범용 컴파일러를 확보했었다. 당시 완성품이 아니었지만 우리도 유사한 것을 갖고 있었으며 이제 완성시킨 것이다. 이것이 바로 모노 1.0이다. 

MS는 아직도 범용 컴파일러를 베타 판으로만 놓아두고 있다. 따라서 우리는 MS가 정식으로 제품을 출시할 때에 컴파일러와 가상머신(VM)에 동일한 기능을 구현하겠다고 생각했다. 그러나 지금에서는 그다지 썩 좋은 생각은 아닌 것 같다. 

MS가 롱혼에 적용할 변화에 대해 어떻게 생각하는가 
항상 롱혼과 같은 뭔가가 있어왔다. 나는 롱혼을 좋아한다. 계속 변하고 있기 때문이다. 롱혼은 표준이 될 수 없다. 그렇지 않나? 사실 우리는 아직 롱혼을 고려하고 있지 않다. 아마 현황이 파악되고 개발자들이 롱혼 기능의 뭐가 필요하고 필요 없는지 명확히 알 수 있게 되기 전까지는 고려 대상에서 계속 제외될 것이다. 

MS는 롱혼의 모든API를 윈FX라 부르고 있다. 이외에 윈FS라고 불리는 아주 작은 요소가 있긴 하다. 노벨은 아이폴더라는 동일한 기술을 갖고 있다. 

롱혼이 가변적이기 때문에 지미안에 윈FS를 구현할 수 있을진 아직 모른다. 언급했다시피 롱혼이 아직 진화하고 있는 상태이기 때문에 말하기 어렸다. 좀 조용해지면 우리는 구현을 시작할 것이다. 바로 호환성을 최대한 확보하는 것이 우리의 목표이기 때문이다. 

MS의 C#으로 뭔가를 한다는 것만으로 오픈소스 공동체에서 분개하거나 하진 않는가? 
글쎄, 물론 이런 일들에는 각자의 입장이 있기 마련이다. 다른 세상에 대한 오픈소스 공동체의 입장이 바로 이런 것이라고는 말하지 않겠다. 

특허는? MS가 닷넷의 일부를 라이선스화 할 가능성은 없는가? 
지금 시점에서 모노가 어떤 특허를 침해했다고 밝혀진 것은 없다. 

자세히 살펴봤는가? 
일부를 검토한 결과 특허 침해는 없었다. 그러나 문제를 꼽자면 바로 MS가 3만개의 특허를 갖고 있다는 점이다. 특허나 특허가 어떻게 작동되는지 경험해봤는지 모르겠다. 그건 기본적으로 이게 우리가 발명한 것이라는 법적 주장이다. 그리고 그 주장은 상대적으로 알아내기 어렵다. 

그렇다면 특허로 인한 법적 강제는 불가능한 것인가? 
일단 주목을 끌어야 한다. 일반적으로 특허 문제는 바로 주목 그 자체다. 특허 검토를 하려고 해도, 그리고 좀 하긴 했지만 그 범위란 것이 실제로 침해한 부분과는 전혀 상관이 없었다. 

또한 전례라는 것이 있다. 즉 과거에 비슷한 사례가 있었느냐 하는 것이다. 이번 경우에는 다중 언어 VM을 예로 들 수 있다. 이것은 아주 오래된 개념이다. 그리고 실제 생산에서도 사용되고 있다. 오픈 소프트웨어 재단(OSF)에서는 VM 개발을 주도한 적이 있지만 시장에 나온 적은 없다. 아니, 사실 시장에 나오긴 했지만 완전히 실패했다. 

그렇다면 당신의 정책은? 
피해갈 수 없는 특허를 우리가 침해했다는 사실을 알게 되면, 그리고 전례도 없다면 그 코드를 제거할 것이다. 이것이 우리의 정책이다. 특허를 침해할 소지가 있는 코드는 모두 제거할 것이며 모노 사용자가 삭제된 코드의 기능에 대해 조치를 취해야 한다. 

현재 우리는 특허를 침해하지 않았기 때문에 제거할 코드는 없다. 하지만 현 상황은 이렇다는 말이다. 

노벨이 리눅스에 대해 행동한 것처럼 법적 면제 방안을 고려한 적이 있는가 
없다. 그러나 리눅스를 위한 법적인 면제는 좀 다르다. 리눅스는 지적재산권이 도용됐다는 주장이 있었다. 

사람들은 언제나 개발자의 ‘감성’과 ‘이성’ 간의 전쟁이라는 말을 하고 있다. 개발자들이 MS의 닷넷과 자바 사이에 선택을 하기 때문이다. 당신 생각에 모노가 자바 개발자들을 닷넷이라는 우산 아래로 끌어들일 수 있을 것 같은가? 
현재 ASP.Net은 J2EE를 밀어내고 있다. ASP.Net은 웹 애플리케이션을 구축하는 MS의 시스템이다. 우리는 지미안에서 모노의 고객을 찾을 때 이에 대한 연구를 한 적이 있다. 

사람들은 ASP.Net 개발이 J2EE보다 25%나 효율적이라고 말했다. J2EE에서는 학술적인 부분에 가까운 쓸데없는 작업을 해야 하기 때문이다. MS도 비슷한 연구를 지원했으며 30% 더 효율적이라는 결과를 얻었다. 우리는 왜 J2EE가 아니라 모노를 사려는지 25명의 고객을 대상으로 설문조사를 했을 때 이와 같은 결과를 얻었다. 

J2EE의 문제는 너무 학술적이 돼버렸다는 것이다. 대학에서 완벽하게 설계된 것들은 너무나도 복잡해 일정 준수와 같은 과정에는 전혀 도움이 되지 않는다. 25% 더 효율적이라는 것은 일정 단축을 의미한다. 더 적은 사람을 고용해도 된다는 뜻이다. 

20만달러에서 200만달러 규모의 1년짜리 프로젝트를 수행하는 회사를 생각해보자. 지금 우리는 4, 5명에서 20명 정도의 개발자를 가진 소규모 기업에 대해 얘기하고 있다. 25% 절걍이라는 것은 매우 큰 것이다. 기술이 예쁘거나 멋진 것과는 관계없이 실제 할 일을 하느냐가 중요하다. 

즉 이것은 자바의 잘못이 아니다. 바로 프레임워크 자체가 이 사용자들을 위해 설계되지 않았기 때문이다. 

하지만 개발자들은 오픈소스에서 여러 대안들을 선택할 수 있지 않은가? 
맞다. 그리고 스트러츠(Struts)처럼 자바를 이용한 많은 대체 기술이 사용되고 있다. 문제는 오레일리(O'Reilly) 출판사의 책 두 권 정도를 제외하고는 다른 정보가 없다는 점이다. 수업을 듣는다고 해결되는 문제가 아니다. 전문 교육을 받거나 지원을 받을 수 있는 곳이 없다. 

ASP.Net과 J2EE는 자금이 풍부했기 때문에 지배적 제품이 됐다. 플론(Plone)을 비롯한 대체 기술도 아주 훌륭한 상위급 플랫폼이 될 기회가 있었다. 그러나 이 제품들은 현재 오히려 틈새용 제품이 돼버렸다. 

우리는 기본적으로 ASP.Net 교육을 받았거나 MS의 툴에 친숙하다면 리눅스에서 소프트웨어를 개발할 수 있도록 하고 있는 것이다. 

중략 ...

 

출처 / ZDNet Korea Martin LaMonica  2004.07.20  

 

원문보기 : http://www.zdnet.co.kr/news/news_view.asp?artice_id=00000039129176&type=det&re=

 

 


  1. 2017.08.08 18:44
Board Pagination 1
/ 1