작년 여름에 쓴 글이죠? 닷넷에 대한 이해의 거품이 마구 들끓던 때였습니다.
물론 지금도 여러 분들이 닷넷에 대해 말하는 내용을 들어보면 그런 거품이 완전히 가시지는 않은
듯 하지만, 그때보단 많이 나아졌죠.

궁그미님이 말씀하신 내용, 그러니까 닷넷이 웹서비스 구현만을 위해 만들어진 것은 아니다, 라는
것은 분명한 사실입니다. 사실 제가 썼던 글의 작은 결론들 중의 첫번째가 그거였죠.
제가 결론을 도출하기 위해 풀어썼던 내용들을, 거꾸로 제가 그렇지 않다고 생각하는 것으로 잘못
이해하신 듯 합니다. 잡생각이라는 형식으로 글을 쓰다보니 명확하게 "이러이러하니 결론은
이것이다"라고 짚지 않고 결론은 독자에게 맡긴 것입니다.

왜 그런 복잡한 설명이 필요했냐 하면(지금은 그럴 필요가 좀 적어진 거 같습니다만) 당시에는
웹서비스를 구현하기 위해서는 반드시 닷넷(혹은 J2EE)라는 새로운 환경이 필요하다, 그런 오해가
많이 퍼져 있었고, 그 오해의 상당부분은 MS가 의도적으로 만든 것이었기 때문입니다.

물론, MS가 그렇게 한 이유는 닷넷의 필요성을 웹서비스에 의존해서 널리 퍼뜨리고 싶어서였죠.
'웹서비스=닷넷'이라는 공식을 세뇌시키고 싶었던 겁니다. 이 정도는 홍보와 마케팅의 기본입니다.
MS는 최근에 들어서는 그런 홍보공세는 거의 하지 않습니다. 왜냐하면, 마케팅이란 시기에 따라서
적절한 단기 전술을 펼치고 접고 하는 것이니까요.

그런 이유로, 당시의 상황상 "웹서비스를 위해 닷넷이 반드시 필요하다는 인식은 오해다"라는 결론을
얻어내고 싶었던 거였습니다. 이 말을 듣고 다시 읽어보시면 좀 이해가 되실 듯...
(글이 너무 장황한 것은 제 고질병이니 오해가 궁그미님의 탓만도 아니네요.)


그런데, 궁그미님이 말씀하신 내용중에서는 역시 저와는 상당히 다른 부분도 있네요.
닷넷이 완전히 새로운 환경이라는 것에는 100% 동감합니다. 뭐 그런 사실을 부인한 적은 없죠?
제가 주로 문제를 제기하는 부분은, 닷넷이 어느 정도의 기간동안 어느 정도 파급력을 가질 것인가
하는 것입니다. 구체적으로는, 과연 MS가 주장하는 닷넷의 비젼이 그대로 성공할 수 있을 것인가죠.

그동안 시간도 꽤 지났고 하니 오랜만에 다시 개발자에 대한 닷넷의 의미에 대해 끄적거려보겠습니다.
좀 길어질 듯 하니 닷넷 잡생각 시리즈의 네번째라고 해도 좋을 듯 합니다.


ASP.NET

먼저 ASP.NET을 살펴봅시다. ASP.NET은 대단히 멋지게 만들어진 웹프로그래밍 기술입니다.
일단 성능면에서는 내부적으로 컴파일되는 스크립트이므로 이전까지 JSP에 비해 뒤쳐졌던 것을
적어도 개념적으로는 따라잡았고, 또한 웹폼을 도입함으로써 웹 클라이언트 개발의 또다른 방법을
제시했습니다. 그리고 장점으로 또 뭐가 있을까요? 음, JScript와 VBScript 외에 다른 언어도 사용할
수 있게 되었다는 것도 들 수 있겠습니다.

그런데 ASP.NET의 이런 멋진 이면에는 상당한 웃기는 면도 있습니다.
JSP의 자바코드가 바이트코드로 컴파일되는 것처럼, ASP.NET에서도 MSIL 코드로 컴파일됩니다.
그런데 ASP.NET에서는 디스크상으로는 MSIL 모듈을 생성하지만 처음 호출 후에는 메모리에 네이티브
코드로 컴파일된 상태로 가지고 있게 됩니다. 이것은 물론 성능 때문입니다. 자바 바이트코드나
MSIL은 중간언어인만큼 다시 그것을 실행하는 데 시간이 더 들어가니까요. 다시 말해서, ASP.NET
페이지를 생성할 때 바로 컴파일해서 해당 MSIL 코드 모듈을 생성해놓지만,첫번째 호출 후에는
메모리에 저장된 네이티브코드로만 실행시킵니다. 이 과정에서 굳이 MSIL 코드가 필요하지 않는
것입니다.

다시 말해서, 기술적인 배경을 따지자면 ASP.NET에는 닷넷이 필요하지 않습니다. 단지 각 언어
컴파일러를 이용할 뿐이지요. 여러 언어를 지원하지만 각 컴파일러를 호출하고 다시 MSIL 컴파일러를
호출해서 네이티브로 컴파일해서 반복 실행하니 닷넷이 관련될 필연성이 없습니다. 굳이 따지자면
닷넷용 언어들을 ASP.NET에서도 사용할 수 있다, 이런 정도의 편리함은 있겠지요.

실제로, 원래 ASP.NET은 닷넷 계획 발표 전까지만 하더라도 ASP+로 불리던 별개의 기술이었습니다.
그러니까 ASP.NET의 기술적인 편리함을 들어서 닷넷이 멋지고 훌륭한 환경이라고 부르는 것은 좀
어폐가 있다고 할 수 있습니다. 따져보면, MS가 닷넷을 전파하기 위해 일부러 별개의 기술인 ASP+를
닷넷에 낑궈놓은 것입니다. ASP+가 닷넷 기술 패밀리에 추가되어서 얻게 되는 장점은 여러 컴파일러를
활용할 수 있게 된 정도인데, 그런 면에서는 쓸데 없이 닷넷 컴파일러와 MSIL 컴파일러의 두단계를
거치지 않고 네이티브 컴파일러를 이용하는 것이 성능면에서 더 강력해질테니까요.

결론적으로... 좀 나쁘게 말하자면, ASP.NET을 .NET에 포함시킨 것은 마케팅의 기본중의 하나인
낑궈팔기입니다. 물론 MS가 .NET 정책을 발표한 이후로는 ASP.NET을 .NET과 분리해서 내놓지 않으니까
ASP.NET의 여러 장점들의 대부분은 오직 .NET에서만 활용할 수 있는 것이 되고, 덩달아 .NET의 가치도
더 높은 것이 아니냐.. 라고 따진다면 그런 측면도 있긴 하지만, .NET의 기술 본질과는 거리가 있는
멋진 기술을 낑궈넣었다고 해서 .NET의 기술 가치가 더 높아진다고 말하긴 좀 그렇죠.
물론 상업적인 가치는 높아진다고 할 수 있겠습니다만.


마치기 전에, 잠깐 ASP.NET의 웹폼을 따져보지요. 뭐 그다지 큰 가치가 있다고 보지 않습니다.
물론 멋지고 예쁘긴 합니다. 그런데 새로운 기술의 카테고리로 바라보기보다는 라이브러리 수준에서
지원될 수 있는 종속기술일 뿐입니다.

웹폼이란 것이 무엇입니까. 윈도우 개발에서 사용되는 것과 거의 똑같은 컴포넌트를 비슷한 방법으로
웹페이지에 올릴 수 있다는 것 아닙니까. 그런데, 실제로 미국보다 적어도 웹 개발 응용 기술에
있어서만은 훨씬 앞서가고 있는 우리나라에서도 이런 윈도우 컨트롤 형태의 컨트롤을 사용할 일은
거의 없습니다. 어떤 인터넷 웹사이트에서 이런 컨트롤들을 사용하는 것을 보신 적이 있습니까.

그런데 이 웹폼이 멋지게 이용될 수 있는 분야가 있습니다. 그런데 인터넷은 아니지요.
인트라넷입니다. ERP나 CRM등의 사내망에서 이용되면 아주 멋진 도구가 됩니다.
특수한 제한되고 커스터마이즈된 환경에서 데이터를 검색하고 보여주고, 이런 목적에 딱 맞죠.
실제로 일부에서 웹폼과 비슷한 컨트롤들을 HTML 코드를 이용해서 사용하고 있습니다.
다시 말해, 우리가 말하는 일반적인 웹 사이트가 아니라, 엔터프라이즈 프로젝트에 활용도가 높다는
얘깁니다.


.NET GUI 개발

이제 .NET GUI 개발에 대해 제 생각을 말해보겠습니다.
결론부터 말하자면, 향후 몇년 사이에 .NET을 클라이언트 GUI 개발에 광범위하게 사용하게 되고
Win32 개발을 급격히 대체할 것이라는 전망은 MS의 희망사항일 뿐입니다.

MS는 윈도우 각 버전마다 새로운 API들을 추가해왔습니다. 그런데 우리가 일반적으로 사용하고 있는
GUI 관련 API들은, 거의 윈도우95 수준을 벗어나지 못합니다. 예를 들어서, 윈도우2000에는 알파
블렌딩 관련 API가 눈여겨볼 만한 예쁜 기능으로 추가되었었고, 윈도우XP에서는 그 폭이 더 커서
테마 지원이 추가되었습니다. 그런데, 이들 새로운 GUI API들을 적극적으로 이용하는 경우는 그다지
흔하지 않습니다.

.NET 애플리케이션이 실행되기 위해서는 필연적으로 자바의 가상머신에 해당하는 .NET 환경이 설치되어
있어야 됩니다. 이것이 서버 프로그래밍에서는 거의 문제가 되지 않습니다. 약간의 메모리와 프로세스
자원을 더 소모하겠지만, 그 이점을 생각한다면 약간의 비용을 들여 서버를 업그레이드하거나 증설하는
것으로 문제는 깔끔하게 해결됩니다.

그런데 클라이언트 GUI 개발에서는 문제가 완전히 달라지게 됩니다.
그 프로그램을 사용할 불특정 다수의 사용자들이 모두 .NET 환경을 설치해놓고 있어야 합니다.

물론 MS가 이번에 출시될 윈도우2003 이후의 모든 윈도우 버전에는 .NET 환경을 설치하여 출시할
것은 분명합니다. 하지만 현재 전세계를 뒤덮고 있는 거의 100%에 가까운 윈도우 머신들에는 닷넷
환경이 깔려있지 않습니다. 현재 운영중인 구버전의 윈도우들을 반 정도만이라도 .NET 환경으로
유도(.NET 다운로드 설치이든 혹은 새버전의 윈도우 구입이든)하는 데 걸리는 시간은 암만 적게
잡아도 4~5년은 걸리게 됩니다. (아마 MS는 그보다 더 길게 보고 있을 겁니다)

그러면, .NET 환경이 전세계 사용자들의 절반 정도에 깔려있다고 하면, 소프트웨어 개발자들이
.NET용 애플리케이션을 만들어낼까요. 택도 없습니다. 여러분이 WinZip 개발사에 소속된 개발자라고
합시다. Win32 기준으로 만든 WinZip은 .NET 환경의 윈도우에서도 문제없이 잘 돌아가지만,
WinZip을 .NET 기반으로 만들면 전세계 고객의 절반이 사용할 수 없습니다. 그렇다고 .NET 기반으로
애플리케이션을 만든다고 기존에는 없던 우수한 기능을 활용할 수 있느냐고 하면 그것도 아닙니다.

그러면 소프트웨어 개발사들에서 Win32 기반과 .NET 기반의 두가지 버전의 제품들을 내놓을까요.
일부는 그럴 수도 있습니다. 그런데 대부분의 소프트웨어 개발사들에게는 쓸데없는 두배의 투자가
됩니다. 다시 말하지만, Win32용으로 만든 GUI 애플리케이션은 .NET이 설치된 윈도우에서도 훌륭하게
동작합니다.

MS 스스로도 자사의 대표적 클라이언트 애플리케이션인 오피스를 Win32용으로 계속 지원할 것입니다.
물론 MS라면 오피스를 Win32용에 더해서 .NET용으로도 내놓을 가능성도 있습니다.
그런데 누가 그걸 사용할까요. 두가지 버전 모두 이상없이 동작한다면, 사용자는 조금이라도 시스템에서
더 빨리 실행되고 메모리를 적게 잡아먹는 버전을 선택할 것입니다. 의도적으로 닷넷 버전에 특출난
기능을 더 추가하지 않는 한 말입니다. 그런데 이것은 현실적으로 불가능합니다.
최근 몇년간 오피스의 업그레이드율이 계속 떨어지는 것에서 보듯이, 오피스는 이미 사용자들이
필요로 하는 수준에서는 거의 '완벽한' 수준에 올라있기 때문에 사용자들을 확 사로잡을 획기적인
기능이 더 나오기가 힘들기 때문입니다.

MS가 다른 선택을 할 가능성은 없을까요. 예를 들어, 모험을 하면서라도 오피스 제품군에서 Win32
버전을 중단하고 .NET 버전만 내놓을 가능성 같은 것 말입니다. 그런데 모험도 할 만 해야 하지,
.NET 설치를 강제할 경우 오피스 구매율(실질적으로는 업그레이드율)은 급격히 떨어질 수 있습니다.
독점을 점하는 MS의 제품들에게 있어서도 최대의 적이 있는데, 그것은 자사의 구버전이기 때문이죠.
이미 거의 100%에 가까운 사용자들이 오피스 구버전을 사용하고 있는 상황에서, .NET 버전을 강제하는
것은 거의 자살행위라고 할 수 있을 겁니다. 며칠전에 발표된 MS의 부문별 수익률을 참고하면,
지난 4분기에 전체 32억6000만달러의 영업이익에서 오피스의 영업이익이 무려 18억8000만달러나
되었습니다. 오피스의 업그레이드율에 사운이 걸려있다고 해도 전혀 과언이 아닌 것입니다.
그만큼 MS 스스로도 섣불리 Win32 버전의 오피스를 걷어치울 수가 없습니다. 아마 수년이 걸릴 겁니다.

이런 이유로, 클라이언트 GUI 개발에서 .NET이 대세가 되려면 낙관적으로 생각하더라도 수년 이상의
긴 시간이 걸리게 될 것이며, 비관적으로 생각한다면 클라이언트에서 .NET이 대세로 자리잡는 것은
불가능할 수도 있습니다.

이런 면에서 비교되는 기술인 자바의 경우를 비교해볼 수 있는데...
자바는 웹브라우저라는 획기적인 킬러애플리케이션이 폭발적으로 배포되면서 JVM이 함께 널리 퍼지면서
적어도 이런 면에서의 난점은 많이 극복했었습니다. 하지만 배포 이후에 자바의 GUI 성능의 한계를
뛰어넘지 못했죠. 물론 .NET은 GUI 측면에서는 자바를 훨씬 능가하겠지만, 배포가 문제가 됩니다.
클라이언트 불특정 사용자들에게 .NET 환경을 널리 전파해줄 킬러 애플리케이션이 없습니다.

결론적으로, .NET 기반의 GUI 프로그래밍은 소수의 한정된 이용자에게만 사용되는 엔터프라이즈
프로젝트에서는 유용할 수 있지만 불특정 다수에게 배포되는 소프트웨어에서는 너무나 시기상조입니다.
그리고 앞에서 4~5년 정도를 얘기했는데, 그것도 상황이 나쁘지 않을 때의 이야기이지, 훨씬 더 길어질
수도 있겠구요. 자바에서의 AWT이나 스윙처럼 등장할 때는 화려한 스포트라이트를 받았지만 막상
실무에서는 별로 사용되지 않는, 예쁘긴 하지만 쓸모없는 도구가 될 수도 있습니다.


엔터프라이즈 프로그래밍에서의 .NET

엔터프라이즈 프로젝트 분야는 현재 .NET이 유일하게 승부를 걸 수 있는 분야이며 실제로도 그렇게
하고 있습니다. .NET 자체가 IT 업계 전체를 아우르는 거대한 컨셉에서 시작되었다고 MS는 강조하지만
사실을 따지자면 오래전부터 기업시장에 도전했다가 계속 실패했던 MS의 숙원사업이 엔터프라이즈
사업인만큼, .NET의 1차적인 목표도 엔터프라이즈 시장임에는 의문의 여지가 없습니다.

ASP.NET의 강점들도, 인터넷 시장보다는 엔터프라이즈 시장에서 궁극적으로 더 쓸모가 있습니다.
ASP.NET이 기술적으로 이전의 ASP보다 많이 뛰어나고 보강되었다고는 해도, 인터넷 분야에서는
리눅스를 눌러버릴 수가 없습니다. 개인적인 견해로는, 인터넷 분야에서 리눅스의 점유율이 지금보다도
지속적으로 계속 상승하여 오히려 ASP.NET을 압도하는 지경에 이를 것입니다.
앞서 살펴봤던 ASP.NET에서 웹폼이 인터넷에서 그다지 큰 쓸모가 없지만, 엔터프라이즈 시장에서는
완전히 달라집니다.

그런데 이 엔터프라이즈 컴퓨팅 분야에는 자바가 먼저 점령하고 있는 상태입니다. 그때문에 MS가
끊임없이 자바에 시비를 걸고 있는 것입니다. 잡지 광고라든지 배너 광고 등등 MS의 홍보공세를
살펴보십시오. .NET에 관련된 거의 모든 홍보공세는 엔터프라이즈 분야로 집중되고 있습니다.
MS가 리눅스를 경계한다고 떠들어대고는 있지만 리눅스를 공격하는 홍보공세의 예는 거의 없습니다.
왜냐, 리눅스는 아직 엔터프라이즈 컴퓨팅에서는 한참 멀었다고 자타가 공인하는 수준이기 때문입니다.
간혹 ERP를 리눅스 기반으로 구축했다는 기사가 나오더라도 상당히 실험적인 시도이기 때문에 MS가
경계할 이유가 없습니다.

엔터프라이즈 분야에서 .NET이 상당부분 성공을 거둘 것이라는데는 대부분의 전문가들이 이견이 없고,
저도 마찬가지입니다. 그렇다고 자바를 압도하고 급속히 대체할 것이라는 얘긴 아닙니다.
MS는 자사에 유리한 벤치마크 결과만을 인용해가면서 성능의 차이를 강조하는데, 어느정도는 사실이기도
하겠고 그럴듯 하기도 하지만, 그런식의 벤치마크는 상당히 편파적이기도 하고,
또 성능만이 성공을 좌우하는 유일 요소가 아니라는 것도 주의할 필요가 있습니다.

이미 자바가 엔터프라이즈 컴퓨팅에서 확실히 검증된 대세로 자리잡은 상태에서 .NET이 시장에 파고들기
위해서는 어쩔 수 없이 시간이 걸리는데, 다른 모든 일들에서 그렇듯이 이 시간 인터벌은 모든 것을
바꾸어놓을 수 있는 중요한 변수가 될 수 있습니다. 예를 들어 .NET이 자바 시장을 본격적으로 위협하는
수준에 이르기 전에 J2EE의 새로운 버전 1.4가 발표되고 성능면에서 .NET과 비슷하거나 더 뛰어나게 된다면?
이런 변수들의 유무에 따라 .NET의 시장 점유율도 크게 달라질 수밖에 없는 거죠.
또 이런 측면들 때문에 MS가 아무리 적극적으로 .NET을 외치고 다녀도 기업들에서 MS가 원하는 만큼 빠르게
.NET을 받아들이지 않습니다.



.NET이 성공하느냐 마느냐, 혹은 언제쯤 성공적으로 특정 분야를 점령하게 되느냐를 생각할 때,
보통 개발자들은 MS의 장황한 설명보다는 무의식적으로 MS의 압도적인 자본력과 데스크탑OS 시장을
싹쓸이한 MS의 무서운 시장지배력을 먼저 떠올리는 경향이 있습니다. 그야말로 대마불사의 논리입니다.

그 와중에서 개발자의 논리에 주객이 전도되게 됩니다. 개발자는 플랫폼 혹은 개발툴 공급사의 논리에
따라 움직이는 것이 아닙니다. 고객의 논리에 따라 움직이지요. 이것은 불변의 시장의 법칙이며,
MS가 제 아무리 역사상 유래없는 초유의 거대기업이건 자본력이 얼마나 대단하건 바뀔 수 없는 것입니다.
소비자, 고객의 힘은 MS의 힘을 몇백배로 능가하며 MS의 모든 힘도 소비자로부터 임대한 것이라고
볼 수 있습니다. 그러니 제아무리 MS라고 한들 소비자를 잡아끌 아이템이 없다면 장사는 다한 겁니다.

그런데 MS는 개발자들에게 이것을 거꾸로 생각하게끔 암시를 반복하고 있습니다.
그 이유는, .NET에는 일반 고객을 확 잡아 끌고갈 만한 아이템이 없는데도, .NET이 성공하지 못하면
MS의 미래도 불투명해지기 때문입니다.
그래서 개발자들로 하여금 일반 고객들을 끌고 오도록 유도하고 있는 것입니다.
이런 시도가 성공할지는 아직 미지수입니다.

개발자들은 MS의 영향력을 실제보다도 강하게 느낍니다.
개발자들이 소비자들보다 시장을 더 잘 아는 것이 아니라 단지 그렇게 느낀다는 겁니다.
그래서 시장의 판도 변화에서 소비자를 제쳐놓고 MS의 동향만 눈에 보입니다.
반면 소비자들은 개발자들의 생각보다는 의외로 MS에 강하게 지배되지 않습니다.

MS가 어마어마한 자본을 붓고 있지만, 대상으로 하는 시장도 엄청나게 크고, 또 MS가 존속 혹은
성장하기 위해 필요한 MS의 매출/수익 증가율도 엄청나게 큽니다. 기존의 시장과 기업 규모가
엄청나기 때문에 투자도 엄청나지 않으면 존속할 수 없다는 말입니다.
이렇게 MS도 어쩔 수 없는 필연성 때문에 그만큼의 돈을 붓고 있다는 것을 개발자들은 잘 깨닫지 못합니다.


잡생각 시리즈의 글을 처음 쓰기 시작했을 때부터, 저는 .NET을 싫어하거나 .NET이 실패할 것이라고
단정하려는 것이 아니었습니다. 저와 같은 처지의 엔지니어들이 너무 순진하게 MS의 감언이설에 쉽게
넘어가고 있는데, MS의 희망사항과는 다르게 상황이 전개될 가능성도 절대로 무시할 수 없을 정도로
많이 존재한다는 것을 개발자분들에게 알리고 싶어서였습니다.

개발자들(물론 저까지 포함해서)의 머리는 true, false의 2진법으로 동작하는 경우가 많은 것 같습니다.
아닐 가능성도 있음을 말하고 있는데, 마치 제가 아니라고 말했다는 것처럼 반박을 받는 경우가 많군요.
MS가 그토록 열심히 설파하는 성공 가능성을 제가 다시 반복할 필요는 없는 거 아니겠습니까.
제가 여기서 쓰고 있는 내용들은 MS의 .NET 계획은 실패할 것이다, 가 아니라 위험성도 엄연히 존재하고
있다는 얘기입니다.

기업들은 장기적인 전략면에서 제품을 내놓고, 그 제품의 연한이 다하기 전에 새로운 제품을 내놓고
하면서 먹고 삽니다. 영원히 돈을 토해내는 제품이란 없습니다. MS도 마찬가지입니다.
그리고 어떤 기업에게도, 이런 전략 제품간의 전환기가 위기가 됩니다. 만약 새로운 제품이 기존의
제품이 과거의 제품을 대체했을 때만큼의 확실한 메리트가 없다면 기업은 최대의 위기에 봉착하게 됩니다.

대마불사?
MS도 시장에 참여한 플레이어중의 하나일 뿐이며, 모든 시장에서 쓰러지지 않는 대마는 소비자뿐입니다.
소비자가 가진 권력에 비하면 MS의 권력도 종잇조각에 불과합니다.

닷넷과 MS에 대한 제 생각의 핵심은, 역사상 최대의 기업인 MS라도 약화되거나 쓰러지는 순간이
언젠가는 다가오게 마련이고, 지금이 그 시기일 가능성이 상당히 높아보인다는 것입니다.
그리고 MS가 벌이는 판에 무조건 그럴듯 하다고 개발자가 따라 뛸 것이 아니라, 상황의 전개 추이를
봐나갈 필요가 있다는 거죠.

몇년전에 MS와 썬이 NetPC와 NC로 접전을 벌였을 때 IT 업계는 둘중의 하나가 PC시장을 대부분 대체할
차세대 비젼이 될 것처럼 떠들썩했었습니다. 그때도 양쪽의 논리는 그럴듯 했습니다.
당시에 앞서간답시고 MS와 썬 한쪽을 택해서 같이 뛴 업체가 몇개 기업이나 되었는지 모르겠습니다만,
지금에 와서 그 기업들의 경영진들이 뭐라고 자평하고 있을지 궁금합니다.