나는 작년 10월까지만 해도 자바 프로그래머였고 그 때까지만 해도 MS 의 솔루션들은 가깝고도 먼 존재였다. MS 환경이라고는 2000-2001년 Visual Basic 6.0 으로 이것저것 툴만을 만져본 것이 고작이었고, 그것도 쓸만한 툴을 만들어내지는 못했다. (그나마 남은 소스도 지금은 구동조차 하지 않는다)
뭐 자바 경력도 사실 그렇게 긴 것은 아니다. 2001년 말부터 시작해서 고작 3년간의 실무경험을 쌓았고, 그 동안 나온 상업적 물건이라면 Eternal Dream 이라는, 국내에서는 베타서비스까지, 대만에서는 겨우 유료화를 넘어선 게임을 개발한 것 뿐이니까. 하지만 코더로서 지금 즉 2005년 1월 중반까지 C# 을 코딩해 보면서 Java 와 비교해 이것저것 재미있는 차이점을 느끼게 되었다.
VS.NET 은 놀랄만큼 기존의 구조와 새로운 모델을 교묘하게 포용한 플랫폼이고, 그 중에서도 특히 C# 은 매우 훌룡하게 완성된 개발도구 중 하나이다. VS.NET 이 여러가지 다른 언어들을 지원하기는 하지만, 사실 대부분은 C#의 들러리라 할 수 있을 정도로 C# 이라는 언어는 매우 훌륭하게 짜여져 있고, 처음 개발하기도 무척이나 쉽다. MFC 에서 개발툴이 멋대로 만들어내는 알 수 없는 선처리문과 코드들에 질리고, Visual Basic 의 되다 만 OOP 구조만 보던 나는 C# 이라는 이 멋진 물건에 흠뻑 매료될 수 밖에 없었다. 수많은 군더더기를 없애고 깔끔하게 만들어진 이 언어는, Visual Basic 에서 보이는 단순함과 Java 에서 보던 훌륭한 구성을 모두 가지고 있으며, 이에 더불어 이들에게서 아쉬웠던 여러 가지 언어적인 측면을 추가하여 매우 멋진 언어로서의 모습을 만들어내었다.
하지만 코딩해 보면서 아쉬운 점은 많았다. 엔터프라이즈 개발환경을 위한 코딩에서는 C# 의 생산석은 무척 높은 것이 사실이지만, 그 외의 분야. 다이렉트 소켓 코딩, GUI 의 깊숙한 부분 등은 아직도 충분히 해결해 내지 못했고, DirectX 같은 부분에서는 Java 와 똑같은 맹점을 가지고 있다. 특히 GUI 부분은 조금이라도 복잡한 분야로 들어가게 되면 거의 무조건적으로 WIin32API 의 힘을 빌려야 하고, 한 술 더떠서 심할 경우 unsafe 코드를 사용해야 한다. 과거 C 로 Win32API 를 코딩하는 시절의 복잡성을 그대로 가지고 있지는 않지만, 상수조차 제대로 참조하지 못해서 헤더 파일에서 상수값을 일일이 찾아 수동으로 대입하고 있는 꼴을 보고 있자면, 과연 이놈이 나중에도 제대로 돌아갈 코드일지에 대해서는 무척 의구심이 들게 된다. 게다가 unsafe 까지 들어가 가비지 컬렉트 되지도 않는 메모리들을 휘젓고 있는 코드를 보노라면, 이놈이 .NET 환경 하에 있는 물건인지 아니면 고전 환경에 있는 코드인지를 의심하게 만든다. 그만큼 현재 .NET 플랫폼은 기존의 API 를 아직 다 떠안지 못하고 있다.
물론 현재까지의 체계를 다 커버해 냈으며 거기에 추가적인 놀라운 개념들을 대입했다는 것은 매우 칭찬할 만할 일이다. 허나 그것만으로 안심할 수는 없다. 현재 .NET 의 가비지 컬렉터 성능은 솔직히 Java 만큼 좋다고 보기는 어려우며, 순수한 .NET 의 프레임워크가 가지는 하드웨어 접근성에 따른 성능 가속은, 하드웨어의 직접접근 성능이 대폭 향상된 Java SE 1.4 에 비해 한참 못미치는 수준이다. 게다가 Java SE 가 5로 오면서 기존에 비해 메모리 할당 속도와 가비지 컬렉팅이 비약적으로 향상되었기 떄문에, 만약 동일한 작업을 하는 코드를 만들어냈을 경우 .NET 이 Java 보다 빠르다는 보장이 현재로서는 없다. 게다가 Java 도 5로 오면서 델리게이트 모델까지는 구현하지 못했지만, 오토박싱이 구현된 데다 C# 에서는 존재하지 않는 템플릿을 구현, 퍼포먼스와 코딩 생산성을 더욱 향상시켰다. 특히 이와 가장 깊이 관련된 자료구조 클래스는 Java 가 C# 에 비해 훨씬 풍부한 편이기 때문에 (접근 성과 동기화 면에서 Java 의 자료구조가 훨씬 세분화되어 있다.) 현재의 .NET 은 엔터프라이즈 환경의 생산성이 높다는 장점 외에는 더 큰 메리트가 없지 않나 싶다.
물론 엔터프라이즈 환경에서는 굉장한 위협인 것이 사실이다. VS 의 통합환경은 Rational 사까지 위협할 정도로 강력한 통합체계이며 (비록 Rational 은 IBM 으로 갔지만) 실제로 개념적인 면에서 VS.NET 의 환경은 세계의 엔터프라이즈 환경이 현재 흔들리고 있을 만큼 매우 훌륭한 환경이다. 하지만, 이것만으로는 많이 부족하다. 적어도 Java 등에 대항하기 위해서는 이런 정도에서 만족하기는 어렵다. 게다가 이제 고작 리눅스로 환경을 만들어내는 .NET 플랫폼에 비해 적어도 Java 는 현재 거의 모든 운영체제에 VM 이 만들어져 있지 않은가!
나는 주로 클라이언트 UI 개발이 주 작업이고, 그렇기 떄문에 이런 부분에서 얼마나 접근을 용이하게 만들어주는지가 매우 중요하다. 솔직히 지금까지의 경험으로는 Java 가 .NET 의 C# 에 비해 훨씬 편하고 속도도 빠르다. (커스텀 IME 제작과 텍스트 컴포넌트를 만들어 본 현재까지) 물론 기존 컴포넌트를 쓴다면 .NET 가 Java 에 비해 당연히 빠르겠지만 적어도 나의 입장에서 그럴 일은 '거의' 없고, 그것은 UI 코더들에게는 모두 마찬가지의 일일 것이다.
.NET 2005 에서는 XML 을 도입한 인터페이스 구조 설계가 도입된다고 하고, 그렇다면 내가 처할 입장은 거의 할일이 없거나 - XML 로 모든 것이 표현되므로, 엄청나게 할 일이 많을 것이다 - XML 에서 지원하는 것이 너무 적은 부분밖에 없을 경우. 개인적으로는 전자에서 끝나는 것이 좋겠지만 (UI 코딩 외에도 할일은 태산이므로) 이제까지의 경험상 플랫폼 개발업체가 그 모든 편의를 다 해결해 주지는 못했고, 특히 MS 는 더욱 그러했다. (솔직히 다 해내는 게 기적이라고 생각하지만) 가능하면 도생은 하고 싶지 않은데, MS 가 어디까지 잘 해 줄려나 모르곘다.
결국 끝은 이상한 이야기로군...
에궁 그럼..