우선 토론하는 방법에 대해 먼저 생각해 봐야 할것 같군요...
님의 글중에 계속 비꼬는 투로 저의 경험이니 연륜이니를 말씀하시는데 그건 올바른 토론 방식은 아니라 생각합니다.
제가 알기에는 박지훈.임프님은 상당히 고수인 분으로 알고 있습니다. 프로그래머 세계에서 연륜이 뭐 중요합니까?
저또한 그런 뜻으로 말씀 드렸다기 보다는 저의 경험을 말씀드리기 위한 부가적인 설명이었을 뿐인데 자꾸 그런식으로 말씀하시면 감정을 자극하는 것 밖에는 되지 않을 것입니다.

우선 WPF/E에 대한 말씀을 먼저 하셨으니 저 또한 먼저 말씀 드리죠

MS에서 WPF/E에 .NET을 포함시키려는 의도가 .NET의 배포를 위한 것이다고 하셨는데 반대하지 않겠습니다. 하지만
만일 MS가 .NET의 배포만을 위해 WPF/E를 발표했다면 왜 현재 나와있는 Beta버젼부터 지원하지 않았을까요?

현재 사용할 수 있는 Beta버전에는 .NET이 포함되어 있지 않습니다. 현재의 버젼에서는 모든 Object를 JavaScript로 제어하고 있습니다. 즉 .NET이 WPF/E의 필수 요소는 아니라는 거죠 다만 Flash에서 그랬듯이 .NET은 단지 WPF/E의 보조자적인 역할뿐이라는 것입니다.

물론 박지훈.임프님의 글처럼 MS가 왜 Javascript같은 표준이 있는데 굳이 .NET을 포함시키려 하는지 의심의 눈초리로 바라 볼 수는 있을 것이고 저 또한 MS가 어느정도는 .NET을 보급하려는 의도에서 그랬다고 봅니다.

그리고 WPF/E에 포함된 .NET이 설치되어있는데 .NET은 설치한다면 어떤일이 일어날까요 라고 하셨는데 글쎄요 아무일도 일어나지 않을 것같은데요 박지훈님께서는 충돌이 날 거라 생각하시나보죠?

웹서비스에 대해서도 전혀 엉뚱한 기술을 끼워넣기 하고 있다고 하셨는데
웹서비스를 어떤 관점에서 보는냐에 따라 중요한 차이가 있다고 생각합니다.  DOS환경이나 Win32환경의 개발자의 관점에서 보는냐 아니면 Enterprise 환경의 개발자의 관점에서 보는냐에 따라 엄청난 차이가 있을 거라 생각합니다.

일례로 현재 제가 추진하고 있는 프로젝트의 경우에는 중앙의 서버에 동시에 최대 800대의 클라이언트가 접속하여야 합니다. 이런 경우 모든 서비스를 win32 API기반으로 개발할 수 있을까요? 물론 개발할 수 있겠지요 그럼 기간은 얼마나 걸릴까요 현재 제게 허락된 기간은 2개월 뿐입니다.

몰론 Win32 API환경에서도 개발이 가능합니다. 하지만 정해진 시간내에 개발이 완료 될 수 있을까요 물론 기간이 너무 짧다 더 달라 할수도 있겠지요 하지만 그게 쉽나요? 특히 국내에서는 전산에 대해서 아무것도 모르는 관리자와 개발자들 사이에서 대부분 개발자들이 피해를 보고 있는게 아닌가요?

사실 C++이 국내에 소개된 88년도 에는 박지훈님의 말씀처럼 국내의 마소라는 잡지가 유일했고 좀더 봤다는 사람이라면 BYTE라는 잡지를 기억할 것입니다. 그리고 BYTE에 실렸던 C브레인 바이러스 소스를 보고 백신을 연구했던 사람들도 많을 것이고 그중 한분이 안철수씨라고 전 알고 있습니다.

C++이 국내에 소개되었을 당시 C++의 언어적인 측면보다 더 중요한 측면은 바로 OOP가 아니었나요 아니 OO라고 하는게 더 정확하겠지요 물론 미국의 경우에는 C++이외에도 OO를 지원하는 많은 언어들이 있었지요
그런데 우리나라의 개발자들은 어떻게 C++을 대했을까요 C++의 기반 기술인 OO를 배우기 보다는 C++언어를 배우는데 만족하였고 그러다 보니 언어는 OOP언어인 C++을 사용하면서 프로그램은 C스타일로 개발하는 개발자들이 대부분이었지요

제가 왜 이런 말씀을 드리는지 박지훈님은 이해를 못하실 수도 있습니다.

전 개발자의 자세에 대해 말씀을 드리려는 것입니다. .NET이나 Java진영 물론 개발자는 .NET이나 Java둘중 하나를 선호 할 수는 있습니다. 하지만 박지훈님이 절 표현했듯이 .NET에 올인하거나 Java에 올인해서는 안된다는 것입니다. 보다 중요한 것은 이론적인 지식이라는 것이죠

웹서비스라는게 .NET에서만 주장하는 기술입니까? 아니면 Java에서만 주장하는 기술입니까?
그리고 Web 2.0이라는 기술도 과연 어느 한쪽에서만 주장하는 기술인가요?

결코 어느 한 업체에서 일방적으로 주장해서 만들어진 기술은 아니라는 것입니다.

.NET이나 Java는 단지 웹서비스를 구현하기 위한 하나의 도구에 불과한것입니다. 그런데 도구에 불과한 .NET의 미래에 대한 말씀을 하시면서 현재 표준으로 정해진 웹서비스라는 기술이 사용된 곳이 없다고 말씀하셨는데 정말 그렇게 생각하시는지요?

기업환경에서나 사용하게되는 웹서비스가 어떻게 생각하면 DOS나 Win32 API환경의 개발자에게는 아무 소용이 없어 보일 것입니다. 물론 저도 그렇게 생각하고 있구요 임베디드 환경또한 마찬가지 입니다.

하지만 유비쿼터스 환경에서는 지금까지처럼 단절되어 있는 모든 단말기들(PC,PDA,냉장고,가전제품)이 모두 Network환경으로 나오게 되며 이들은 모두 정보를 주고 받아야 하는 환경으로 변하고 있습니다. 그런 환경에서 과연 기계종속적인 코드의 가치가 얼마나 지속될까요?

물론 속도를 생각한다면 기계종속적인 코드가 가치가 있을 것입니다. 하지만 상호 운용성을 생각하고 배포까지 고려한다면 어떨까요 아마도 기계 독립적인 언어가 필요할 것입니다. 물론 현재 이런 환경에 가장 많은 세력을 확보하고 있는것이 JAVA입니다.

우리 개발자들은 어떤 도구를 사용해서라도 상호 운용성이 지원되는 프로그램을 개발하면 되는 것입니다. NET을 사용하든 아니면 JAVA를 사용하든 그건 아무 상관이 없다는 것이지요 물론 현재는 .NET과 JAVA간의 원할한 통신이 되지 않고 있지만 결국 웹서비스라는 것이 바로 이런 문제를 해결하기 위해 나온 기술 아닌가요 조만간은 원할한 통신이 될 것이라고 생각합니다.

오늘 글은 조금 두서 없는것 같군요 다만 제가 말씀 드리고자 하는 것은

전 개발자로서 MS나 SUN의 일방적인 독주는 싫어합니다. 또한 개발자가 어느 한 업체의 기술에 종속되어서도
안된다는 것입니다. 일례로 미국의 개발자들은 어떤 언어를 사용하는가는 별로 중요하게 생각하지 않는다고 하더군요
PC환경의 개발자가 UNIX환경의 개발도 하고 또 UNIX환경의 개발자가 PC환경의 개발도 한다고 합니다. 더구나 그들은 한달 정도면 새로운 환경에 적응하고 개발에 들어갈 수 있다고 하더군요 우리도 그런 능력을 가질 필요가 있다고 생각합니다.

저같은 경우만 해도 PC에 너무 익숙해지다 보니 LINUX환경의 프로젝트를 하면서도 무지 고생하였고 익숙해지는데만 해도 2-3개월이 넘게 걸리더군요......





박지훈.임프 님이 쓰신 글 :
: 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간의 통신이 필요한 프로그램의 개발하는데 과거에는 많은 코드를 개발자가 직접작성하여야 했던 부분들을 자동화 했다는 것이라고 보시면 될 것입니다.
: :
: : 님의 글에 대한 반론으로 생각하시기 보다는 저처럼 생각하는 사람도 있구나 하고 읽어 주셨으면 합니다.