유니티 엔진의 멀티플랫폼 심장 Mono

1. 모노란 무엇인가?

유니티 엔진으로 스크립트를 코딩하다보면 MonoDeveloper라는 것이 있습니다. 편집기 인데 좀 유니티와는 다른 느낌에다가 닷넷툴같은 느낌을 주면서 닷넷이라고 보기엔 먼가 좀 이상하고 머 그런 느낌인데요.

일단 많은 사람들이 유니티엔진을 선호하는 이유중 하나가 손쉬운 멀티플랫폼 확장성을 들수가 있습니다. 유니티도 초반에 그문제에 대한 고민을 많이했었을겁니다. 그래서 찾은 방안이 모노라는 오픈소스 프로잭트 였다고 합니다. 그럼 어떻게 모노가 멀티플랫폼을 가능하게 하는것일까요?

2. 닷넷프레임워크

원래는 MS에서 닷넷을 만든 이유는 자바에 대응하기위해서 자사의 운영체계(운영체계에 상관없는것이라는 말이 더맞기합니다.)가 도는 시스템에서는  모든 닷넷프레임워크용 프로그램을 구동시킬수있는 환경을 만들자는 원대한 꿈을 가지고 만든것임에는 분명하지만...사실 초창기에는 일반사용자들에게 많은 혼란을 야기 했었습니다. 일반인들에게는 개념이 좀 어려웠던거죠. 그래서 닷넷기반으로 프로그램을 만들경우 기존 윈도우어플과는 다르게 닷넷버전이 맞지않을경우 실행이되지않는 문제가 발생하곤 했습니다.

그리고 여기서 드는 의문중에 하나가 '그럼 리눅스에 닷넷후레임워크가 깔린다면 그럼 닷넷어플이 실행되는건가?' 입니다.

당연지 되죠!

하지만 MS에서 절대로 안만들어줄게 분명하지만요.

왜냐구요?

바로 여기서 사기업표준의 딜래마를 만나게됩니다. 운영체계를 팔아서 먹고 사는 회사의 한계를 여실히 보여주는 씁쓸한 경우인데요. 닷넷이라는 신기술이 자사의 주력상품의 매출을 떨어뜨리게할순없지않습니까?

닷넷프레임워크 자체는 그다지 나쁘지 않습니다. 다만 M$라는 사기업에서 만든게 좀 아쉬운것이지요.

3. ECMA

MS .Net Framework는 유럽표준 기술규약에 등록되어있습니다. 

사실 MS같은 회사가 머가 아쉬워서 표준 기술규약에 등록 시킨이유가 먼지 궁금할수있는데요. 저도 기관이나 관공서에 소프트웨어를 납품하기 전까지는 이런것이 왜필요한지 몰랐었습니다.

기관에 소프트웨어를 납품하기위해서는 그 소프트웨어 기술에 대한 신뢰가 있어야합니다(문서상으로 말이지요 ㅡ.ㅡ;;). 그것을 보장받기 위해서 가장 확실한 방법은 표준기관에서 등록을하고 인증을해주면 그걸가지고 다시 이렇게 검증된기술이다. 라는 식으로 문서를 작성하게 됩니다.

그래서 MS같은 큰회사도 자사기술이 기관등에서 쓰이도록 유도하려고 기술표준 심사를 받고 등록을 한것이지요. 사람들에게 기술공개해서 널리 이롭게 할려는 목적은 절대로 아닙니다.

그러던 어느날 일당의 해커들이 작당을하여(사실 관계는 확인못함) 모노라는 프로잭트가 오픈소스형태로 시작이됩니다. ms 공개한 닷넷 후레임워크 규약을 분석하여 독자적으로 리눅스,맥,안드로이드 아이폰, 닌텐도위 등등 에서 동작하는 닷넷후레임워크를 만들게 됩니다. 

사실 이렇게 무단으로 가져다 쓰면 어떡하나? 걱정하시는 분들도 있을지모르겟는데요. 사실 법적으로는 전혀 문제될것이 없습니다.

이 경우는 안드로이드 개발환경에 자바가 사용되어서 요즘 오라클이 구글을 제소한사건의 경우와 좀 유사합니다. 그러나 이것은 자바라는 상표권 침해에 대해서 이의를 제기한 사건입니다.

모노의 경우는 구글안드로이드처럼 닷넷후레임워크라는 이름을 사용하지않았고 이미 표준기술로 공개된 규약만을 따른것뿐이므로(이것을 문제 삼으면 printf라는 이름으로 함수를 만들면 특허료를 내야겟지요 ㅡ.ㅡ;;) 전혀 문제될것이 없습니다. 라고 모노 개발팀에서 밝히고 있습니다.

 

4. 해피엔딩?

모노를 사용하면 일단 닷넷기반으로 만들어진 라이브러리를 가져다 마음대로 사용할수있습니다. 쉽게 말하면 스크립트언어를 사용하면 대부분 기존 라이브러리와 호환문제 때문에 골치 아픈데 이부분을 해결해주는것이지요.

 

그리고 닷넷 프레임워크의 특성상 언어에 종속되지않는 개발환경을 만들수있습니다. CLR(Common Language Rumtime) 덕분에 자바스크립트와 C#을 서로 섞어가며 코딩을 할수있습니다.

또한 스크립트언어가 텍스트 상태로 매번 실행할때 해석되는것이 아니라 컴파일이 된후 바이너리가 CLR에서  실행되는 방식이므로 자바스크립트를 사용하건 c#사용하건 속도의 저하가 발생하지않습니다. 

모노를 유니티엔진에 도입하면서 부터 유니티엔진이 대중적인 사랑을 받게 되기시작했습니다. 물론 그전에도 맥os쪽에서는 나름 지명도가 있었던 기억이 있습니다. 게임엔진쪽보단 쓸만한 인테리어 시뮬레이션(실내 조명쪽) 해주는 툴정도로 알고 있었죠. 그때가 2005년도 정도 엿던거로 기억이 납니다.

모노와 유니티의 밀월관계가 얼마나 돈독한지 보여주는 예가 유니티를 위해  모노팀에서 모노디벨로퍼를 계속 업그래이드해주는 배려(?)에서 알수가있습니다.  사실 모노디벨로퍼는 유니티에서 만든것이 아니고 모노프로잭트것을 가져다 그대로 쓰는것입니다.

암튼 그렇게 몇년이 지난 2009년에 다시 한번 접한 유니티 엔진은 정말 환골탈피한모습으로 다가왔는데요. 그 중하나가 다양한 플랫폼을 지원한다는 것이였습니다. 그 당시 야심차게 일리히트로 멀티 플랫폼 게임엔진 사업을 하던 저에게는 정말 심각한 타격을 주었는데요. 사업을 접으면서 여러가지를 많이 배웠습니다.  이 세상에는 댓가없는 일이없다는 교훈을 배웠다는걸로 만족을 했습니다. 총을들고 나와야할 전쟁에 철광석만 들고  나온격이였더군요. 그러니 당연히 결과는 뻔한것이였고요. 지금와서 생각해보면 비슷한 시기에 일리히트에 모노를 올리자는 논의가있었는데 그냥 지나쳐버린게 무척 아쉬움이 남습니다. 그때 일리히트엔진 개발자분은 webGL(HTML5)쪽을 선택하셨는데 물론 아직 그것에 대한 결과를 논하기엔 이르겠죠.

그리고 모노라는 프레임웍은 좀 불안한것도 사실입니다. 왜냐하면 모노는 일종의 사생아(부잣집의 숨겨둔 자식같은) 이기 때문입니다. 물론 언리얼같은 적자를 사용하려면 엄청난 댓가가 따르지만요.  좀 이른감이있지만 모노의 대안으로 html5 이면 어떨까 하는 생각도 요즘 조심스럽게 합니다.  그러기에 분명히 한계는 존재할거같습니다. 가까운미래에 우려스러운일이 생길거같은 예감은 들지만 일단은 현재의 상식적인 정답은 모노를 사용한 유니티이지 않을까 합니다.