HOONS님, 좋은 토론에 초대해주셔서 감사합니다.
방금 HOONS님께서 훈스닷넷 페이지에 올려주신 글도 봤습니다. 미력한 생각을 높이 평가해주셔서 더욱 감사드립니다. ^^;;

하지만 저는 그다지 토론을 즐기는 스타일도 아니고, 어떤 기술적 흐름에서 리더가 되고 싶어하는 스타일도 아니라서 좀 소극적일 수밖에 없네요. 저는 그냥 기술로 밥벌어먹고, 또 개발을 즐기면서 살아가는 엔지니어일 뿐이라서요.

이 포럼에서 논쟁이 벌어질 때마다 꼬박꼬박 참여하는 것은, 제가 뛰어나다고 생각해서도 아니고 무슨 거대한 음모가 있으니 막아보자는 영웅심도 아니랍니다. 보시다시피 제 글에서 나오는 내용들은 누구나 잠깐 생각해보면 떠올릴 수 있는 당연한 논리입니다만, 많은 개발자들이 자신과는 무관한 '거대한 흐름'이라고 생각해버리는 바람에 압도되어 생각하지 못하고 있을 뿐입니다. 그게 안타까울 뿐이죠.


닷넷에 대해 전 이런 생각을 하고 있습니다.

저도, 지금 닷넷 개발자들이 전망하시는 대로 닷넷이 완전한 주류가 되는 시기가 언젠가는 올 가능성이 높다고 생각합니다. (그렇다고 그게 필연적이라고 생각되는 정도는 아닙니다) 하지만, 지금 닷넷 시장이 미숙한 상태에서 닷넷 개발에서 주도적 위치를 가지고 계신 분들이 닷넷이 메인스트림이 된 시점에도 여전히 주도적 위치를 가지고 있을지에 대해선 의문의 여지가 있다고 생각합니다.

이렇게 생각하는 것은, MS가 지금 닷넷 2.0 위에 다시 닷넷 3.0을 내놓고 있다는 점에서 힌트를 얻은 것입니다. 물론 닷넷 3.0이 닷넷 2.0 위에서 동작하는 것도 알고 있고 전문은 아니라도 몇몇 주워들어서 닷넷 2.0과 3.0의 관계를 대충은 압니다. 하지만 이 상황을, 도스-윈도우95-윈도우2000의 관계로 바라보면 어떨까요?

윈도우95가 완전한 OS로 동작하지 않고 도스 위에서 돌아갔던 것은, 도스가 없는 완전한 OS로서의 윈도우2000의 등장을 필연적으로 예고하는 거였지요. 닷넷 4.0이나 5.0이 등장하는 시점이 오면, 지금 2.0에서 지원되는 인터페이스들 중에 3.0과 기능적으로 중복되는 상당수 인터페이스가 없어지지 않을까 생각하는 겁니다. 조금 오버해서 말하자면, 3.0의 개발자 인터페이스는 2.0과 달라진, 기술적 호환성으로 따지자면 별개의 기술이라고 바라볼 정도가 아닌가요.

이런 변화가 2000년대 초반에 닷넷의 최초 구상에서부터, 1.0이나 1.1의 발표 당시부터 예정되어 있었다고는 생각되지 않습니다. 그렇다면, 지금 2.0까지의 기술을 열심히 습득한 닷넷 개발자들은 제대로 활용하기도 전에 사라질 기술을 공부해오신 거고, 다시 말하자면 4.0이든 5.0이든 언제든 MS가 3.0과도 다른 새로운 기술을 내놓으면서 다시 3.0을 무용지물로 만들어버리는 경우도 있을 수 있습니다.

닷넷 3.0이 등장한 것에 대해(혹은 갑자기 3.0이라는 이름을 갖게 된 것에 대해) 저는 2000년대 초부터 제가 닷넷에 대해 갖고 있었던 전망이 현실이 된 것이라고 생각하고 있습니다. 닷넷이 MS의 초기 의도대로 금방 주류가 되지 못하면, 다시 말해 개발자들의 열렬한 환영을 받지 못하면 MS는 초기의 닷넷과는 다른 또다른 닷넷으로 개발자들을 유혹하려 할 것이라는 생각이었습니다.

그러니까, 저는 닷넷 3.0을, 기존의 닷넷이 성공하지 못한 것에 대한 대책으로 새롭게 나온 것이라고 생각하고 있는 거구요. 그게 일정 정도라도 사실이라면, 4.0, 5.0에서 다시 3.0을 버리는 경우도 일어날 수 있다고 생각하는 거지요. 지금까지 MS의 전례로 볼 때 개발자의 레거시 기술을 그다지 존중해오지 않아왔고, 게다가 닷넷 4.0 등에서 3.0을 버리는 이유가 주류가 되지 못해서라면 더욱더 존중하지 않을 거라고 예상이 됩니다.

너무 과격한 예상일 수도 있는데, MS가 닷넷에 대해 다시 한번 실패라는 판단을 하게 된다면, 새로운 닷넷이 아니라 어느 순간에 닷넷의 개념 모두를 버리고 Win32, 혹은 새로운 네이티브로 전면 회귀를 할 가능성도 없지 않다고 생각합니다.

새로운 닷넷이나 새로운 네이티브로 기존 닷넷 개발자들을 내팽개치는 결정 여부는, MS에게는 개발자들을 얼마나 존중하느냐가 관건이 아니라, MS가 어떻게 시장에서 살아남을 것인가의 자체적인 판단으로 이루어질 것이기 때문에 더욱 더 위험하다고 생각하고 있습니다.


어느 정도의 좀 느린 속도로라도 닷넷이 시장을 넓혀가면 MS가 그런 과격한 결정을 하지는 않지 않겠느냐, 라고 낙관할 수도 있겠습니다만... 저는 시장에서 기업이 직면하는 것은 속도의 문제라고 생각합니다. 닷넷의 주류로의 확산이 MS가 기대하고 필요로 하는 것보다 지나치게 느리다고 판단하면 MS는 판을 엎을 거라고 보는 거죠. 이번의 3.0이 그 사례라고 생각하는 거고요.

이런 이유로, 아직 본격적인 시장이 열리지 않았고 또 가까운 시일내에 폭발적으로 도입되지는 않을 것으로 보이는 닷넷에 개발자가 투자하는 것은, 개발자로서는 밥줄을 건 모험이라고 생각하고요. 지금 Win32 개발자들의 밥줄은 적어도 닷넷 개발자들보다는 더 안정적이고, 자바 개발자들의 경우엔 더욱 그렇습니다. 이런 상황에서 굳이 시간과 노력을 들여 언제 주류가 될지 모르는, 또 실제 주류가 되었을 때는 무용지물이 될 지도 모르는 닷넷을 습득해야 하는지에 대해 전 비관적입니다.


이런 모든 제 생각의 근본적인 시작은, 닷넷이 개발자들이 애타게 원해서 나온 기술이 아니라 MS가 필요해서 나온 기술이기 때문입니다. 그렇기 때문에 다수 개발자들은 닷넷에 열광해서 앞다투어 도입할 이유가 없습니다. 또 닷넷이 개발자가 원하는 방향으로 발전하는 것이 아니라 개발자들은 멍하니 기다리기만 하고 있고 MS가 새로운 것을 내놓을 때마다 그냥 '오 대단하군' 하고 또 잊어버리는 겁니다.

닷넷이 자바의 시장을 노리고 비슷한 컨셉에서 나왔음에도, 자바와 닷넷의 근본적인 차이점도 여기에 있습니다. 자바는 개발자들이 필요로 할 때 나왔고, 완전히는 아니더라도 개발자들이 원하고 요청하는 방향으로 변화해가고 있습니다. 지금 진행되고 있는 자바의 오픈소스화는 이런 장점을 더욱 극명하게 드러나게 할 것입니다.

하지만 닷넷은 거의 그렇지 않지요. 필요했던 개발자들이 이미 자바에서 답을 얻은 후에 나왔으며, 새로운 기술의 지원나 기술의 발전이 개발자 주도가 아니라 MS의 정책적 필요에 의해 이루어지고 있습니다. (MS가 일방적으로 발표하기 전에 얼마나 많은 개발자들이 닷넷 기반의 플래시 대체 기술을 원했을까요?)

저는 이런 이유로, 자바의 SI 시장 독점 상황이 앞으로도 상당한 장기간 지속될 거라고 생각합니다. 개발자는 기존 기술보다 더 강력하고 더 화려한 기술을 대안으로 내놓으면 그게 금방 주류로 올라갈 것처럼 섣불리 생각하는 경향이 있는데, 현실은 단순한 기술의 우위로 결판나는 것이 아니라 훨씬 복잡한 여러 요인들에 의해 돌아가지요.

예를 들자면, 자바쪽에는 닷넷보다 어마어마하게 다양한 서드파티, 오픈소스 프레임워크들이 필요한 입맛대로 준비되어 있습니다. MS가 자체적으로 닷넷에 포함시키고 있는 것이 자바쪽 서드파티 프레임워크들 중 가장 뛰어난 것보다 더 강력할 수는 있지만, 자바쪽 오픈소스 프레임워크는 개발자들이 당장 필요를 느끼면 바로 프로젝트에 구현되기 때문에, 필요에 대한 즉시적인 대안이라는 면에서 자바쪽이 MS보다 훨씬 빠르게 움직일 수밖에 없습니다. 더욱이, MS 입장에서는 개발자들의 지지도 필요하지만 그 필요한 이유조차 정책적인 전략이기 때문에, 전략적으로 더 필요한 무언가가 있을 경우 개발자들의 필요를 채워주는 쪽 보다는 더 급한 다른 쪽으로 자사의 리소스를 집중시킬 수밖에 없습니다.

뭐, 이렇게 썼다고 해서 제가 오픈소스에 열광하는 오픈소스 지지자인 것은 아닙니다. 단지 자바의 절대적인 우세에 오픈소스 프로젝트들이 강력한 뒷받침이 되고 있는 것은 현실이기 때문이고요.


또 한가지 제가 닷넷에 비관적인 이유는, 닷넷이 SI가 아닌 유틸리티나 시스템 프로그램에서는 Win32의 대안이 될 가능성조차 별로 없어보인다는 것입니다.

여기저기서 특정 목적의 프로그램을 벤치마킹한 결과마다 닷넷 기반으로 구현한 건 프로그램이 느리거나 둔하다.. 리소스를 많이 차지한다.. 라는 결론을 내고 있는 걸 이따금씩 보고 있습니다. 개발자가 닷넷과 Win32 기술을 비교하는 목적으로 비교한 것이 아니라, 개발자와 전혀 무관한 글에서 그냥 순수한 목적에서 프로그램 벤치마킹을 하는 글에서 말입니다.

더욱이 MS 자신도 오피스를 닷넷으로 만들지 않고 있으며(일부 소수 서비스를 닷넷쪽으로부터 호출할 수는 있겠지만) SQL 서버에서도 닷넷 기반의 UDF를 만들도록 개발자들을 유도하고는 있어도 SQL 서버의 옵티마이저 등 코어를 닷넷 기반으로 만들고 있지 않은 점에서도 볼 수 있습니다. 닷넷을 가장 적극적으로 독려하고 있는 MS조차도 닷넷 온리 기반보다는 Win32를 주로 하고 닷넷을 가미한 정도로 프로젝트를 진행하고 있는 거죠.

이런 이유로 전 유틸리티/시스템 프로그램에서 닷넷이 주류가 되는 것은 거의 불가능하리라 생각하고 있습니다. MS에게 Win32 개발자들을 닷넷으로 끌어들이는 것이 중요하긴 하지만, 당장 오피스나 SQL 서버의 경쟁자들과 경쟁해서 뒤쳐지지 않는 것이 몇배나 더 중요하기 때문에 MS는 결코 Win32를 버리지 못할 것이며, 개발자들이 언제까지나 MS의 그런 이중적인 행태(스스로는 Win32를 쓰면서 개발자들에게는 닷넷만 쓰라고 하는)를 용인하지도 못할 것이기 때문입니다. 결국, 닷넷의 시장은 자바의 틈새를 뚫고 들어가야 하는 SI밖에 남지 않습니다.


제가 뭐 대단한 논객은 못되다보니 글이 좀 두서없이 횡설수설해버렸는데...

어쨌든 제 입장에서 결론은, 현실에서는 Win32 개발자들로서는 닷넷을 고려할 이유가 없습니다. 지금도 Win32로 밥줄 전선에 문제가 없고, 닷넷으로 옮긴다고 해서 더 나아지는 것 같지도 않고, 지금 동료 Win32 개발자보다 닷넷을 먼저 공부한다고 해도 선점 효과도 불투명하니 모험이 되고 말이죠.