친 MS적인 베이스가 깔려 있긴 하지만 최대한 중립적인 입장에서 답변을 적어 보도록 하겠습니다. 개인 적인 생각일 뿐 저의 답변이 MS를 대변하는 것은 아닙니다.

임프님은 기술의 변화에 대해서 부정적인 견해를 가지고 있는 것 같습니다.

IT 업계에서 고객이 원하는 요구는 계속 해서 변해가고 있고 IT업계에서도 그 변화를 느끼고 있습니다. 웹이라는 환경에 2.0 이라는 버젼이 붙게 되리라고 상상이나 했겠습니다. 웹이 그런 것처럼 소프트웨어를 다루는 기본적인 사용자 경험도 새롭게 바뀌어야 할 시대가 오게 되면 기술역시 변화할 수 밖에 없다고 생각이 듭니다.

제가 생각하는 것은 MS는 나름 OS의 변화를 통해 여러가지 변화를 시도하고 있는 중이라고 생각이 듭니다. 닷넷을 발표하면서 속도보다 안전성의 무게를 두게 될 수 있었던것도 하드웨어가 충분히 받쳐주고 있는 상황이고, 지금의 현실에 맞는 기술을 주도 해야 하지 않을까 싶습니다. Win32를 고집해야 되고 그 기술이 최고의 기술을 인정하고 끝까지 고집할 수 있을 수 있지만 Win32라는 언어 자체가 생산성이 많이 떨어진다고 생각이 듭니다. 저 역시 처음개발을 시작할 당시 C++빌더의 유저이기도 하였기때문에 그 닷넷의 생산성을 많이 인정하고 있습니다. 또한 예전 VC++이 C++빌더 보다 생산성이 떨어지는 것 역시 인정하는 사실이기도 합니다.

닷넷이 처음 발표 되었을 당시 자바에 대응하기 위해서일 뿐이였고, 그 자바보다 새로운 그 무언가를 보여주지 못했기 때문에 그저 실패한 프로젝트로 평가가 내려질 수 밖에 없는것 같습니다. 하지만 닷넷 3.0이 발표 되면서 닷넷의 입장은 조금 다르지 않을까 생각이듭니다. 기존의 Flex 혹은 Flash의 시장을 깎아 먹기 위한 정책이 된다라고 평가한 부분도 있겠지만 어떻게 보면 개념자체가 조금 다릅니다. WPF 같은 경우는 윈도우의 그래픽 카드의 지원을 받는 반면에 Flex같은 경우는 오로지 플래시 플레이어를 의존하기 되기 때문에 그 성능을 따라 갈 수 없습니다. 그만큼 새로운 윈도우 프로그램의 패러다임을 제공 해주고 있습니다.

비스타가 물론 실패한 OS가 될 수도 있습니다. 많은 성능의 하드웨어를 필요로 하고, 자체 보안이 까다롭기 때문에 당장 대세가 되기는 힘들것으로 예측이 되기도 합니다. 그리고 MS는 새로운 개발 패러다임이 필요하다면 닷넷 3.0을 죽이고 새로운 환경이 등장할 수도 있습니다. 하지만 그것을 선택하는것은 개발자의 몫일 뿐 개발자들이 MS를 따라갔더니 우리를 배신했다라는 논리는 조금 맞지 않은 것이 아닐까 생각이 듭니다. 닷넷이 필요했기 때문에 선택한 것이지 MS가 오라고 해서 따라간건 아니라는 말입니다.

개발자로서 오래 살아 남기 위해서 어떤 기술을 선택하는 것은 의미가 없어 보입니다. 어떤 기술이든 시대의 흐름에 따라서 퇴새되기 마련입니다. 닷넷은 닷넷만의 특징을 가지고 있습니다. 그것이 자바와 비슷하고, 시장을 크게 잡고 있지 않은 상황이라 하더라도 그 기술은 단지 닷넷 기술일 뿐인 것입니다.

중요한것은 MS가 Win32를 지원을 중지하고 닷넷이라는 기술을 Win32에 대한 대안으로 발표한 것은 아닙니다. 닷넷은 Win32 보다 훨씬 큰 개념을 품고 있습니다. 웹 서비스도 그러한 의미범주에 포함되고 손쉬운 COM+ 서비스의 구현이나 ASP.NET 역시 그렇습니다.

웹 서비스가 처음 발표 되었을 때 보안이나 성능상의 문제가 많이 제기가 되었지만 그를 보안하는 여러 WS-* 표준들이 발표 되면서 굉장히 유용한 기술로 인정받고 있습니다. 앞에서 자바와 자바 닷넷과 닷넷에서만 이용하고 있다라는 평가는 조금 성급한 평가입니다. 한 예로 특허청에서는 웹 서비스로 여러 업체들에게 특허관련 정보를 제공하고 있습니다. 그 서비스는 자바로 구현되어 있었습니다. 하지만 기존의 특허청의 정보를 일일히 웹에서 검색할 수 밖에 없던 상황에서는 단비와 같은 기술이 제공 된 것이였습니다. 이와 같이 웹 서비스는 이미 충분히 대중화 되고 있고, 일반 어플리케이션을 클라이언트에 배포할 때 데이터 교류가 필요할 경우 TCP통신을 선호하기 보다는 웹 서비스를 이용한 통신이 선호되고 있는 것이 지금의 현실이 되고 있습니다.

업계의 변화를 보면 대부분의 SI 가 Win32기반의 CS환경에서 지금은 웹이 주도하는 환경으로 많이 넘어 오고 있습니다. MS적인 베이스가 깔린 Win32 개발자가 웹 환경으로 개발을 해야하는 상황이오고 있는데 OOP의 개념조차 없는 기존의 ASP를 선택하여 개발하는 것은 너무나 어려운 일이지만 ASP.NET은 그렇지 않습니다. 주위의 ASP.NET 개발자들을 보면 VC++ 개발자였지만 ASP.NET으로 넘어와서 개발을 하는것을 많이 볼 수 있었습니다. 그렇기 때문에 닷넷이 가진의미가 없다고 보지는 않습니다.

여튼 저의 요지는 닷넷기술이 실패할 미래가 없다는 것이 중요한것이 아니라 개발자로서 살아남기 위해서는 자신부터 계속 변할 수 있어야 한다고 생각이 듭니다. 혹시 웹 개발을 하고 계시는지는 모르지만 웹의 경우 웹 2.0의 기술이 이슈가 되면서 고객들의 눈은 높아지게 되었습니다. 그런 요구를 ASP라는 기술로는 구현의 한계가 있기 마련이고, Ajax기술의 생산성을 보장하는 ASP.NET을 선택할 수 밖에 없다고 생각이 듭니다. 만약 닷넷 개발자의 길을 선택하였고, 또한 지금의 세상이 닷넷이란 기술이 주도를 하고 있지 않으면 어떻습니까? 닷넷 개발자들 솔직히 구하기 어렵습니다. 그렇다고 닷넷 프로젝트가 없는 것도 아닙니다. 주위의 개발자들만 보더라도 닷넷 개발자들을 구하지 못하여 자바이상으로 몸값이 많이 올라가고 있는 것을 보고 있습니다. 그렇듯이 닷넷은 닷넷의 자리에 있는 것이라 생각이 듭니다. 향후 몇년의 기술 트랜드가 변화되어 닷넷이 사용이 아니라면 그 기술을 다시 학습해서 밥벌이 하면 되는것이 아닐까요?! 저는 그렇게 생각이 드는데요;;




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