HOONS님이 아니라도, 바람개비님의 글도 충분히 좋고 논의할 만하다고 생각되네요. 닷넷에 많은 투자를 하시는 것 같으니 닷넷 비관론자인 저와 서로 반대편에 서서 좋은 토론을 끌어갈 수 있었으면 좋겠습니다.


WPF/E의 목적에 대해서는 기본적으로 RIA, 리치 인터넷 애플리케이션을 타겟으로 한다는 것에 대해서는, MS도 스스로 그렇게 말하고 있고 또 많은 개발자분들이 그렇게 믿고 있습니다. 저도 그 목적 자체가 거짓이라고 말한 적은 없죠. 제가 그 관련으로 주장한 내용에서 중요한 것은, WPF/E에 그런 표면적인 이유 외에도 닷넷 보급의 목적도 있을 개연성이 충분히 있고 MS의 입장에선 너무나 당연할 거라는 점입니다.

MS가 'WPF/E는 플래시와 경쟁하는 것이 유일한 목적이므로, WPF/E로 배포하는 닷넷은 다른 목적으로 활용하지 않겠다' 라고 결심했을 거라고 생각한다면 오히려 너무 순진한 생각 아니겠습니까. 혹은, MS의 의도가 정말 그렇게 순수하다고 해도, 억지로 회피하지 않는 한 기술적으로도 좀 이상하게 되죠. 이미 WPF/E로 배포된 닷넷이 설치된 피씨에, 다시 닷넷을 설치하면 어떻게 될까요?

MS에게 WPF/E로 플래시와 경쟁하려는 목적과 닷넷 배포의 목적이라는 두가지가 다 있다고 한다면, 닷넷 배포라는 목적이 훨씬 큰 그림이고 더 중요할 것이라는 것도 상식적으로 짐작이 가능한 것 아니겠습니까. 우리나라에서야 플래시가 엄청난 시장을 갖고 있지만 미국을 포함한 해외에서 그런 대단한 시장을 갖고 있는 것 같지 않고, 또 인트라넷/업무 개발에서는 WPF/E보다 더 강력할 수밖에 없는 닷넷 씬클라이언트라는 방식을 밀고 있는데 굳이 닷넷 배포 목적 없이 RIA만을 위해 WPF/E를 내놓았다는 것은 좀 설득력이 적을 듯 합니다.


다음으로.. 닷넷에 대한 전망에 대해 몇가지 써보겠습니다.

저는 91년에 C를 시작했고 말씀하신 89년에는 포트란을 쓰고 있었으니까 따지자면 저보다 선배이십니다. (아마 터보이빨님과 같은 세대쯤 되시겠군요) 하지만 지금까지의 기술의 변화를 바라보는 데 있어 그게 그다지 큰 의미가 있을 정도로 차이가 될 거 같지는 않군요. 저도 89년쯤에 C언어가 국내에 소개되는 과정을 지켜보고 있었습니다. (제 기억으로는 88년이었던가 89년에 마소였던가 과학동아였던가 어디 잡지에서 C 언어 소개 기사를 봤던 걸로 기억합니다)

그런데... 바람개비님이 기술의 트랜드를 바라보는 방향은 저와는 좀 다르십니다. 좀 오해일 수도 있겠다 싶습니다만, 쓰신 글만 봐서는, 과정이야 어찌됐든 어떤 배경이 있든 결과적으로 새로 나온 기술은 '그동안의 기술들을 정제한' 것이므로 일단 다 가치가 있다는 말씀처럼 들립니다. 아마 원래의 뜻은 그런 뜻이 아니지 않았을까 싶습니다.

제가 바라보는 닷넷의 가장 큰 문제점은 기술적인 내용에 있는 것이 아니라, 개발자들이 원하지 않은 상태에서 MS가 일방적으로 내놓고 있다는 것입니다. 닷넷의 첫번째 모토는 아시다시피 웹 서비스입니다만, 지금에야 어떤 과정으로든 웹 서비스를 사용하는 개발자들이 꽤 있겠습니다만, 웹 서비스라는 개념을 내놓은 초기에는 거의 누구도 실제로 사용하지는 않았던 기술이 아닙니까.

MS나 썬이 웹 서비스를 내놓지 않았더라도, 웹 서비스가 정말로 필요했다면 업계의 어디서든 혹은 어떤 오픈소스 프로젝트로든 웹 서비스가 출현했을 겁니다. 마찬가지로 WPF/E도 개발자가 필요로 해서 나온 것이 아니라 MS가 일방적으로 내놓은 것 아닙니까. WPF는 어떻습니까. 아니, WPF를 포함한 닷넷 3.0 전체는 어떻습니까.

MS가 꾸준히 밀다보면 언젠가는 다수 개발자들이 이런 기술들을 활용하게 되는 시점이 오게 되겠지요. 하지만 그건 단지 몇년의 시간 차이가 아니라, 개발자들이 폭발적으로 환영해서 수용하게 되는 것과는 천지차이 아닙니까. 하나의 기술이 킬러앱이 되느냐 아니면 그냥 적당히 나쁘지 않으니까 수용되느냐는 개발자들에게도 큰 차이가 있고, MS의 입장에서는 더 더욱 큰 차이가 될 것이라는 것은 바람개비님의 연륜이라면 절대로 모르시지 않으시겠지요.

제가 지금까지 소프트웨어 업계에서 지켜본 수많은 변화들의 공통점은, 오직 개발자가 스스로 필요로 했던 기술만이 적극적으로 수용되고 흐름을 변화시켰다는 겁니다. 제가 직접 겪은 것이 아닌 읽거나 들은 소프트웨어 업계의 첫 태동기부터 지금까지 이 법칙이 깨진 것을 보지 못했습니다.

바람개비님께서는 웹 서비스를 닷넷의 긍정적인 전망의 근거로 보고 계시는데, 저는 반대입니다. 제가 웹 서비스를 바라보는 관점은, 한 마디로 하자면 '필연성 없이 끼워진 기술'이라는 것입니다. MS가 닷넷을 정식으로 내놓기도 전에 볼랜드에서는 델파이에서 Win32 환경에서 먼저 웹 서비스를 지원하기 시작한 것을 아십니까. 닷넷과 아무런 연관성이 없었던 순수 Win32 개발툴인 델파이 6 버전에서 말입니다. 굳이 델파이를 거론할 필요도 없이, 웹 서비스가 닷넷과 어떤 필연적인 관련성이 있습니까.

(여담입니다만, 웹 서비스 자체도 현재 원래의 취지대로 쓰이는 것 같지는 않더군요. 닷넷은 닷넷대로, 자바는 자바대로, 끼리끼리 호출하고 있을 뿐, 닷넷-자바-Win32 사이에 웹 서비스로 연동하는 사례를 별로 들어보지 못했습니다. 물론 제가 자세히 알지 못해서 그런 것일 뿐 그런 프로젝트들도 꽤 있겠지만, 닷넷 프로젝트들 사이에서만 웹 서비스로 연동하는 프로젝트가 더 많은 것이 현실이겠지요. 그런 경우에 왜 굳이 성능면에서 최선의 선택일 수도 없는 웹 서비스를 사용할까요?)

닷넷을 구성하는 '핵심'이라고 불리는 기술들이, 제가 보기엔 닷넷과 필연적인 연관성이 없습니다. ASP닷넷은 닷넷 발표 이전부터 이미 계획중이었고 일반 개발자들에게도 알려져 있었던 ASP+의 이름이 바뀌어 업그레이드된 거죠. 닷넷 계획 이전부터 별도로 추진되던 프로젝트였다는 얘깁니다. 또, WFP가 닷넷 없이는 구현이 불가능한 것인지도 저는 의문스럽습니다. XAML도 마찬가지입니다.

이런 배경들 때문에, 저는 닷넷이 하나의 필연적인 기술이 아니라 개발자들에게 매력적으로 보일 수 있는 기술들을 그저 짜집기해놓은 것에 불과하다고 봅니다. 물론 닷넷의 공통 언어로 이런 저런 환경에서 쓸 수 있고...라는 식의 논리도 가능은 합니다만, 그런 유니버설한 언어, 환경이라는 것이 과연 기존의 언어와 기존의 환경, 즉 네이티브에서는 불가능한 것인지를 생각해 볼 필요가 있다고 생각합니다.


물론 지금의 현실을 어떻게 해석하느냐에 따라 제 주장이 맞을 수도 있고 틀려질 수도 있겠죠. 그래서 저와 바람개비님(그리고 아마도 대부분의 닷넷 올인 개발자들)이 영원히 양쪽이 수긍할 수 있는 결론이 나지 않을 수 있다고 생각합니다.

하지만 저로서는 제 생각이 도무지 틀렸다고 생각할 수가 없는 것이, 닷넷의 첫 발표 이후로 거의 대부분의 흐름이 제가 예견한 대로 흘러가고 있기 때문입니다. 2000년대 초반에 여러 개발자들이 닷넷에 올인하면서 곧 닷넷 대세 시대가 올 것처럼 낙관했지만, 오히려 닷넷의 보급 속도는 제가 예상했던 것보다도 더 느려지고 있습니다.

닷넷이 발표된지 벌써 6년이 지났습니다. 6년이 과연 개발자가 쉽게 감내할 수 있는 짧은 시간입니까. 6년이면 4년제 대학 신입생이 졸업을 하고도 실무 3년차로 들어가는 시간입니다. 자바는 95년에 처음 공개되고 닷넷이 발표되던 2001년 사이 6년 동안에 막강한 대세의 흐름을 차고 앉았습니다. 심지어는, MS의 윈도우조차도 3.0이 일반에 시판되고 나서 완전히 대세로 자리잡은 윈도우95까지 6년이 걸리지 않았습니다. 더 거슬러 올라가보면, 지금보다 IT 업계의 흐름이 훨씬 느렸던 도스 시절에도, 도스가 완전한 대세로 자리잡는 데 6년은 걸리지 않았습니다. 잘 아시다시피 C도, C++ 언어도 대세가 되는 데 6년이나 걸리지 않았습니다.

6년이 지난 지금도 대세가 되지 못한 닷넷에 대해, '언제 대세가 될 것인가'를 생각하는 자체가 어떻게 보면 무의미할 수 있습니다. 윈도우XP를 단종시키고 나면 언젠가는 윈도우 비스타가 '대세'가 되는 것이 당연하듯이, 언젠가는 Win32를 넘어서서 닷넷이 '대세'가 되는 시기가 오겠지요.

하지만 그게 언제냐의 문제는 단지 그냥 멍하게 기다리면 되는 문제가 아니라, 심각하게 고민해야 하는 문제입니다. 왜냐하면, 닷넷을 믿고 있는 개발자는 무한정 기다릴 수 있을지 몰라도, 기술을 일방적으로 주도하고 있는 MS는 '언젠가는'을 무한정 기다릴 수 없기 때문입니다. MS는 이미 VB와 폭스 프로의 사례에서 사용중인 개발자가 아직 많고 계속 원하고 있는데도 불구하고 자사의 정책과 시장의 필요에 따라 개발자들을 얼마든지 버리고 갈 수 있다는 것을 여러번 보여줬습니다.

(사실 제가 보기엔 C++도 이미 이런 개발자에 대한 배신의 사례에 포함된다고 봅니다. MS는 C++이 닷넷의 핵심 언어다 뭐다 하면서 C++ 개발자들을 안심을 시키려고 애쓰는 기색이 역력하지만, 이미 다른 글에서도 썼다시피 MS는 CF 환경에서 C++을 지원할 계획이 없다고 공언한 바 있습니다. C++이 가장 강력하게 능력을 발휘할 수 있는 모바일/임베디드 환경에 C++을 지원하지 않겠다는 것은 C++ 개발자들이 쉽게 납득할 수 있는 문제가 아니지요?)

저는 이런 당연한 추론의 결과로, MS가 다시 한번 닷넷에 올인하고 있는 개발자들을 배신하는 상황이 얼마든지 또 일어날 수 있다고 생각합니다. 흔한 말로, 한번 배신한 사람은 다시 배신할 수도 있다고 하지 않습니까.


이제 글을 슬슬 마무리하겠습니다. 저는 무조건 제가 옳다고 주장하고 싶은 것이 아닙니다. 저는 논쟁이나 싸움을 하고 싶은 것이 아니라 토론을 하고 싶습니다. (소모적인 논쟁을 좋아하는 사람은 없겠지요) 그런데, 제가 가지고 있는 이런 생각들에 대해 마땅한 근거를 들어 답하신 분은, 바람개비님을 포함해서 지금껏 아.무.도. 없었습니다. (지금 쓴 글의 주요 논리들은 이미 위의 다른 글들에서 나온 내용들이지요?) 기껏해야, 'MS가 시장에서 압도적인 파워를 갖고 있으니 언젠가는 대세가 되지 않겠냐' 라는 얘기들 뿐이더군요.

MS가 아무리 업계의 거대 공룡이라고는 해도, 매출로 먹고사는 기업일 뿐이기 때문에 일부 개발자들의 맹신과는 달리 얼마든지 위기가 닥칠 수 있습니다. 소프트웨어 업계에서 파워 면에서라면, 일부 개발자들이 착각하고 있는 것처럼 MS가 아니라 개발자들이 압도적으로 더 강력합니다. (물론 일반 사용자들이 훨씬 더 강합니다) 그리고 지금 현실에서는, 개발자들이 MS가 원하는 만큼, 그리고 원하는 속도로 따라가주지 않고 있다는 것은 분명합니다.

윈도우의 적은 구버전 윈도우라는 말처럼, 지금 현실적으로 MS에게 닷넷의 가장 큰 적은 자바가 아니라 Win32와 비주얼스튜디오 구버전입니다. 그 원인은 말할 필요도 없이 다수 개발자들이 움직이지 않고 있기 때문입니다. 6년이나 세월이 흐른 지금 아직도 Win32 개발이 훨씬 더 많다는 것을 어떻게 해석할 수 있습니까.

자, 바람개비님이 쓰신 글에 대해 제 반론은 여기까지입니다. 부디 멋진 근거를 들이대셔서 제가 그 동안 갖고 있던 닷넷에 대한 생각들에 대해 심각하게 고민을 하게 만들어주셨으면 좋겠습니다. 저는 잘난체를 하고 싶은 것이 아니라, 정말로 '진지하게' 미래를 더 잘 예측하고 싶고 그래서 더 잘 살아남고 싶기 때문입니다.




바람개비2003 님이 쓰신 글 :
: HOONS님이 아니어서 죄송합니다.
: 박지훈.임프님의 글을 읽고서 드리고 싶은 말씀이 있어서 글을 쓰게 되었군요
:
:
: 먼저 WPF/E에 대해서 .NET의 Subset이다며 .NET을 퍼뜨리기 위한 것이다고 말씀하시면서
: MS에서 .NET을 WPF/E에 포함 시킬 것이라는 걸 근거로 제시하셨군요
: 네 어떻게 생각하면 님의 주장이 옳다고 할 수도 있습니다. 그런데 이렇게 생각하시면 어떨지요
: Flash에 ActionScript가 포함되어 있는 프로그램이 가능한 것처럼 WPF/E에는 .NET의 기능을 포함하여
: 프로그램이 가능하도록 했다고요 제가 보기에는 MS에서도 이런 의도로 .NET을 포함하려는 것이지 .NET Framework를 배포하려는 의도는 아니라고 생각합니다.
: WPF/E를 설치한다고 해서 .NET Framework이 설치되는건 아니거든요 즉 WPF/E를 설치했다고 해서 .NET용 APP를 바로 실행할 수 없다는 뜻입니다.
:
: WPF/E를 평가하는 것도 달라져야 한다고 생각합니다. WPF/E는 RIA를 위한 새로운 툴입니다. 그동안 Flash를 사용한 RIA를 개발해본 많은 개발자들은 알것입니다. Flash를 이용한 RIA를 위해서는 Flash를 공부해야 한다는 것을 하지만 개발자들은 개발자들이 익숙한 언어를 가지고 있습니다. Web에서는 Javascript가 대표적이겠죠 물론 .NET의 경우에는
: C#이나 VB.NET이겠지요 WPF/E는 XAML이라는 새로운 방식을 이용해 디자이너와 개발자를 연결 시겨주는 편리한 툴이라는 거죠 WPF/E를 처음 보면서 전  이젠 다투지 않아도 되겠다는 생각과 함께 그동안 디자이너와 다퉜던 많은 시간들이 떠오르더군요
:
: 물론 WPF/E가 님의 말처럼 얼마나 많이 보급이 될런지 Flash를 얼마나 따라 잡을지는 아무도 모릅니다. 그리고 2000이나 하위의 OS뿐만 아니라 비 MS계열의 OS를 얼마나 지원하게 될지는 아직 아무도 모르죠 다만 WPF/E는 RIA를 개발하기 위해 개발자가 선택할 수 있는 하나의 선택으로 추가 되었다고 생각하면 될 것같습니다.
:
: 그리고 .NET이 시장을 주도적으로 이끌때에도 과연 현재의 .NET 개발자들이 살아 남을 수 있을까 하는 글에 대한 저의 생각입니다.
:
: 전 사실 89년도 부터 개발에 몸을 담고 있습니다. 국내에 C++이 처음 소개 되었을 당시부터 C++을 공부했고 또 OOP에 대해서 공부를 해왔습니다.
: 그동안 많은 기술들이 소개 되었지요 저도 한동안은 CORBA에 매달린 적도 있습니다. 물론 COM/DCOM도 마찬 가지구요 JAVA도 해본적이 있구요
:
: 그리고 요즘 새로 발표되는 많은 기술들 특히 INETA에 봤던 WPF,WCF,WPF/E같은 기술들을 보면서 느낀 건 어떤 기술이든지 갑자기 전혀 새로운 기술이 나올 수는 없다는 것입니다.
:
: 새로운 기술이라고 발표되는 많은 것들은 결국은 과거의 기술들에서 우수한 것들만 모아 많든 정제된 것이라는 것입니다.
:
: 일례로 Web Service만 해도 그렇지 않습니다. 그동안 분산환경 기술들은 많이 소개가 되었고 또 많이 사용되고 있습니다. 하지만 각각에는 우수한 기능이 있는 반면에 부족한 부분들이 있었습니다. DCOM/COM도 그랬고 CORBA도 그랬습니다. XML기반의 Web Service같은 경우에는 지금까지의 이런 모든 기술들의 문제점을 해결하기 위해 그동안의 기술들을 정제했다고 저는 생각합니다. 물론 현재의 Web Service도 문제가 있고 또 앞으로 어떤 새로운 기술이 소개될지는 아무도 모릅니다.
:
: 그렇다면 과거의 많은 기술들을 전혀 모르는 사람이 이해하는 현재의 기술과 과거의 많은 기술들을 이해하고 있는 사람이 이해하는 현재의 기술은 다를 것이라고 생각합니다. 저는 단연코 과거의 기술을 이해하고 있는 사람이 새로운 기술을 더 빨리 습득하고 또 사용할 수 있을 거라 생각합니다.
:
: .NET또 마찬 가지입니다. 마치 .NET 2.0이 .NET 1.0과 전혀 별개의 것처럼 말씀하시는데 그것 또한 아니라고 생각합니다. 물론 .NET 2.0에 새로 추가된 기능이 있고 또 MS에서는 그걸 사용하도록 권고는 하고 있지만 기존에 .NET 1.0에서 지원했던 기능들을 지원하지 않거나 하는 것은 없습니다. API기반의 프로그램을 많이 해보셨다니 잘 아시겠지만 하위 호환성을 생각하지 않을 수는 없다는 것이죠 물론 이번에 발표된 .NET 3.0도 마찬가지라고 보시면 될 것입니다.
:
: WCF같은 경우에는 Web 서비스 및 기타 APP간의 통신이 필요한 프로그램의 개발하는데 과거에는 많은 코드를 개발자가 직접작성하여야 했던 부분들을 자동화 했다는 것이라고 보시면 될 것입니다.
:
: 님의 글에 대한 반론으로 생각하시기 보다는 저처럼 생각하는 사람도 있구나 하고 읽어 주셨으면 합니다.