[MS의 닷넷 로고. 닷넷은 XML에 기반한 일종의 '사업 비전'일 뿐 명확한 정의가 내려진 용어는 아님.] 
 

미국에서 개최된 PDC(Professional Developer Conference)에서 MS의 닷넷(.NET) 발표. 데스크 탑에서 벗어난 미래의 인터넷 컴퓨팅 환경을 지원하기 위해 만들어진 닷넷은 MS가 제시한 웹 서비스(web service)를 위한 '비전'이었음.

MS는 닷넷 웹 서비스의 구체적인 전략인 "헤일스톰(Hailstorm)"을 개발해 서비스를 시작함. 헤일스톰은 "MS 패스포트(Passport)"라는 사용자 인증 시스템을 통해 이메일, 인스턴트 메시지, 스케줄 정리 등의 기능을 네트웍이 연결된 어느 곳에서나 컴퓨터 휴대폰, PDA 등 다양한 기기로 이용할 수 있게 해줌. 그러나 사용자 개인 정보 유출에 대한 우려, 업체들의 참여 저조로 서비스를 중단함.

비록 헤일스톰은 실패했지만 MS의 닷넷은 웹 서비스를 위한 성공적인 '틀(플랫폼)'을 구축해 놓은 상태임. MS는 닷넷을 위한 개발 환경인 비주얼 스튜디오 닷넷(Visual Studio .Net)을 출시해 기존의 수많은 윈도 환경 개발자들을 끌어 들였으며, 또한 자바, C와 같은 '반-MS' 프로그래밍 언어까지 지원해 주고 있음.

MS는 이전까지 주로 PC를 위한 OS와 애플리케이션으로 수익을 올린 기업입니다. 그러나 인터넷의 발달로 앞으론 PC가 아닌 무선 기기들이, 거대한 하나의 네트웍을 통해, 모든 데이터와 애플리케이션을 주고 받게 된다는 전망이 유력한 상황이죠. 컴퓨팅 환경의 중심이 데스크 탑 PC에서 네트웍 기기 쪽으로 옮겨 간다면 현재 MS가 갖고 있는 수익 모델은 크게 흔들릴 수 밖에 없습니다.

데스크 탑 PC의 윈도 OS를 대체할 만한 다른 OS가 그리 많지 않기 때문에, 지금까지 데스크 탑에 설치된 MS의 제품들은 교체하기가 매우 어려웠습니다. 하지만 인터넷 컴퓨팅 환경에서는 상황이 크게 달라집니다. 인터넷 시장에선 아파치 웹 서버나 SUN의 솔라리스(Solaris), 리눅스(Linux)와 같은 제품들이 흔하게 이용되고 있는데다, 오라클(Oracle) 데이터베이스나 BEA 애플리케이션 서버는 이미 웹 애플리케이션 시장을 거의 독점하고 있는 상황입니다. 조금 과장해 말하자면, 인터넷 시장에서 MS 제품은 있어도 그만 없어도 그만인 셈이죠.

이 때문에 MS는 앞으로 다가오는 인터넷 환경에서 MS의 독점력을 유지할 수 있는 새로운 전략을 세웁니다. 이 전략의 핵심이 바로 닷넷(.Net)입니다.

닷넷은 아직은 구체적인 모습을 드러내지 않은, 광범위한 네트웍 서비스입니다. MS의 설명에 따르면, 닷넷은 "XML 웹 서비스 플랫폼(Web Service Platform)"이라고 합니다.

XML은 웹에서 데이터의 구조와 성격을 결정해주는 언어이고, 플랫폼은 개발/혹은 서비스 환경을 일컫습니다. 기본적으로 닷넷에 대해 알기 위해선 무엇보다 웹 서비스의 개념에 대해 이해해야 합니다.

웹 서비스란 기본적으로 "WWW 상에서 어떤 것이든, 무엇이든 소통되도록 하는 것"이라는 개념으로 이해할 수 있습니다. 즉, 컴퓨팅 환경에 구애 받지 않고 어떤 환경에서도 정보를 주고 받을 수 있는 시스템을 제공한다는 것이죠. 웹 서비스는 서로 다른 애플리케이션들을 ‘이어 주는’ 역할을 합니다. 웹 서비스 시스템에서는 서로 다른 애플리케이션이 서로 교신하고, 데이터를 공유하며, 함께 작동하게 해주는 것입니다.

따라서 웹 서비스 하에서 기업들은 어떤 애플리케이션을 사용하더라도 모든 형태의 정보를 주고 받을 수 있으며, 개인 사용자는 웹 서비스에 등록을 하고 나면 언제, 어디, 어떤 기기를 이용하더라도 지속적인 맞춤 서비스를 받을 수 있습니다.

웹 서비스는 이렇게 OS 플랫폼이나 사용자 환경에 관계없이 모두 실행된다는 것을 가장 중요한 개념으로 삼고 있습니다. 따라서 앞으로 웹 서비스 모델이 컴퓨팅 환경에 도입되면 지금까지 데스크 탑 시장에서 갖고 있던 OS의 중요성은 크게 떨어질 수 밖에 없죠.

웹 서비스의 가장 현실적인 형태로 우리들 앞에 모습을 드러낸 것은 MS의 닷넷 전략의 일부인 "헤일스톰(Hailstorm)"이었습니다. MS의 웹 서비스 전략은 두 가지로 시작됐는데, 하나는 닷넷 프레임웍을 이용한 웹 서비스 플랫폼 구축이고, 다른 하나는 헤일스톰을 통한 구체적인 서비스 제공이었습니다. 말하자면, MS는 닷넷으로 틀을 짜고, 헤일스톰으로 그 틀을 구체화/현실화 한다는 계획이었죠.

헤일스톰은 "MS 패스포트(Passport)"라는 사용자 인증 시스템을 통해 이메일, 인스턴트 메시지, 스케줄 정리 등의 기능을 컴퓨터 휴대폰, PDA 등 다양한 기기에서 이용할 수 있게 해줍니다. 말하자면, 헤일스톰은 애플리케이션이 사용자 정보에 접근해 사용자가 각종 서비스를 활용할 수 있게 주는 플랫폼으로, 닷넷 성공의 핵심 전략이라고 할 수 있죠.

예를 들어, 음악 콘서트나 영화에 관심 있는 사용자일 경우, 헤일스톰은 사용자를 대신해 현재 어느 공연이나 영화의 티켓이 남아 있는지, 사용자의 계정에 상세히 보고해 줍니다. 물론 이때 헤일스톰은 사용자가 미리 지정해 놓은 공연 장르나 티켓 가격의 범위 내에서 티켓 정보를 제공하며, 이 모든 작업은 사용자가 온라인에 접속해 있지 않을 때도 변함없이 진행됩니다.

하지만 문제는 이런 헤일스톰이 제대로 작동하기 위해선 사용자 모두가 반드시 사적 정보를 MS가 관리하는 서버에 '제출'해야 된다는 점이다. 하지만 그러기 위해선 무엇보다 기업, 소비자, 정부 모두가 먼저 MS에게 사적인 정보를 맡길 수 있을 만큼의 신뢰를 갖고 있어야 하겠죠. 그러나 지금까지 MS의 전력으로 볼 때, 사람들이 MS에 대해 이런 신뢰를 갖기란 결코 쉬운 일이 아닌 것으로 판명됐습니다. (실제로, 여러 시민/소비자 단체가 지난 7월 미 공정거래 위원회에 MS의 윈도 XP에 도입된 패스포트 서비스가 불공정 거래 행위를 조장한다며 이의 신청을 제기한 바 있습니다.)

결국 프라이버시와 보안 문제에 대한 우려, 업체들의 참여 저조 등, 사회/심리적 반발로 인해 2002년 MS는 헤일스톰 전략을 접고 맙니다.

웹 서비스는 아직 성공적으로 구축된 사례가 많지 않습니다. 앞으로 웹 서비스가 활성화 되기 위한 가장 큰 문제는 기업들이 스스로 웹 서비스에서 기술적인 이익을 발견할 수 있느냐는 점입니다.

이들이 기술적 이익을 조기에 발견하든 못하든, 웹 서비스는 앞으로 기업 IT 부서에 ‘해일처럼’ 밀려들진 못할 것입니다. 다만 웹 서비스는 앞으로 ‘가랑비처럼’ 조금씩 기업 내부로 젖어 들 것으로 보입니다. 분명하게 말할 수 있는 것은 웹 서비스는 거품처럼 금방 꺼지거나 사라질 존재는 아니란 점이죠.

웹 서비스가 서로 다른 애플리케이션과 플랫폼을 이어주는 능력을 발휘하게 된 것은 모두 XML, SOAP(Simple Object Access Protocol), WSDL(Web Services Description Language), UDDI (Universal Description, Discovery, and Integration)와 같은 ‘표준 구성 요소’들 덕분입니다.

이중 가장 중요한 구성 요소인 XML은 인터넷 애플리케이션들이 HTTP와 같은 표준 웹 프로토콜을 이용해 서로 데이터를 공유/교신하게 해주는, 데이터 호환을 위한 핵심 기술입니다.

XML이 서로 다른 플랫폼 간에 데이터를 주고 받을 수 있게 해준다곤 하지만, 그렇다고 서로 다른 애플리케이션 사이에 완벽한 의사 소통을 가능케 해주는 ‘모국어 같은’ 연결 방식을 제공하는 것은 아직 아닙니다.  

XML 데이터를 다른 애플리케이션으로 옮기기 위해선 아직 데이터를 ‘포장’하고 다시 해독하는 과정을 거쳐야 합니다. 이런 인코딩-해독 과정은 어느 정도의 시간과 비용의 낭비를 가져올 수 밖에 없습니다. 결과적으로 XML을 웹 서비스의 표준으로 삼는다 할지라도, 밀접한 호환성을 필요로 한다면 최상의 성능은 기대하기 어렵습니다.

SOAP(Simple Object Access Protocol)은 이런 문제점을 해결할 대안으로 기대되고 있습니다. MS 닷넷의 핵심 기술 중 하나인 SOAP은 서로 다른 시스템과 서로 다른 애플리케이션 사이에 정보를 공유할 수 있도록 해주는 프로토콜입니다.

MS가 개발한 SOAP은 기본적으로 XML과 HTTP의 장점을 한데 합친 프로토콜입니다. SOAP에서 사용자는 XML로 데이터를 정의하고, HTTP의 헤더를 이용해 상대편으로 보내게 됩니다. 이런 식으로 어떤 종류의 플랫폼과 네트웍 환경에서도 데이터를 보내고 액세스 할 수 있게 해주는 프로토콜이 SOAP입니다.

SOAP은 윈도 기반 프로그램과 리눅스(Linux), 자바Java), 심지어 메인프레임의 코볼(Cobol) 프로그램 사이에도 정보 호환을 가능케 해 줍니다. (WWW 컨소시엄은 조만간 SOAP를 새로운 커뮤니케이션 프로토콜로 추천할 것이라고 합니다.)

그러나 SOAP을 갖고도 XML의 데이터 해독 문제를 해결할 수가 없습니다. XML 데이터가 '클라이언트 애플리케이션'에서 읽히기 위해선 여전히 인코딩과 해독 과정을 거쳐야 하기 때문이죠. XML 데이터가 각 애플리케이션에서 읽히기 위해 WSDL(Web Services Description Language) 문서는 웹 서비스 인터페이스를 규정하는 정보를 제공하고 있습니다.

결론적으로, XML 데이터가 누구에게나 유용한 ‘정보’가 되기 위해선 반드시 해독 과정을 거쳐야 한다는 것입니다. 그리고 이 해독 과정은 비주얼 베이직, 자바, 코볼 등의 각종 프로그래밍 언어로 만들어진 애플리케이션과 시스템으로 가능합니다. 말하자면, 웹 서비스의 성공을 위해선 각 언어 개발자들의 적극적인 협조가 필요하다는 뜻입니다.

MS는 닷넷 웹 서비스를 위한 개발자들의 '적극적인 협조'를 얻기 위해, 과거 윈도 OS를 개발했을 때처럼 개발 플랫폼 전략을 세웠습니다.

즉, 먼저 개발자들을 끌어들이기 위한 기본적인 개발 환경을 구축하고, 애플리케이션 몇 개를 공개한 후에, 개발 도구를 배포하는 전략이죠. MS는 이와 같은 전략을 바탕으로 닷넷을 위한 개발 도구, "비주얼 스튜디오 닷넷(Visual Studio .NET)"을 출시했습니다.

비주얼 스튜디오 닷넷은 기본적으로 비주얼 베이직 개발 환경을 그대로 답습하고 있습니다. 기존에 비주얼 베이직을 이용하던 윈도 OS 환경의 개발자들을 웹 서비스 환경으로 고스란히 끌어들이려는 계산이었죠. MS는 이처럼 개발자들에게 '친숙한' 개발 도구를 제공함으로써 수많은 닷넷 애플리케이션을 만들어 내기 위한 기반을 닦은 것입니다. 닷넷처럼 엄청난 규모의 웹 서비스를 실현하기 위해서는 무엇보다 많은 수의 애플리케이션이 필수적이기 때문이죠.

닷넷의 또 한가지 커다란 특징은 다양한 프로그래밍 언어로 소프트웨어를 만들 수 있다는 점입니다. C#, 비주얼 베이직과 같은 '비주얼 스튜디오 닷넷 브랜드'에 속한 프로그래밍 언어 외에도, 개발자들은 C, C++, 자바와 같은 다양한 언어를 이용해 닷넷 소프트웨어를 제작할 수 있습니다. (비주얼 스튜디오 닷넷은 2002년 초에 출시됩니다. 이후 MS는 비주얼 J# 닷넷을 비롯한 자바 프로그래머들을 위한 개발 도구들을 공개합니다.)

비주얼 스튜디오 닷넷 이외의 프로그래밍 언어로 작성된 소스 코드는 닷넷 소프트웨어로 작동되기 위해 "MSIL(Microsoft Intermediate Language: IL이라고도 함)"로 컴파일 됩니다.(이는 자바의 "바이트코드(bytecode)"와 같은 개념입니다.) 그리고 이렇게 컴파일 된 MSIL 코드는 "CLR(Common Language Runtime)"으로 다시 컴파일 되거나, 아니면 직접 각각의 플랫폼에 맞는 네이티브 코드로 컴파일 됩니다. 물론, 여기서 지원되는 플랫폼은 윈도 OS 시리즈 뿐입니다.

C와 C++ 사이의 '변종' 프로그래밍 언어인 C#은 자바의 대약진에 위기감을 느낀 MS가 자바에 대항하기 위해 개발한 인터넷 환경 언어입니다. 비주얼 스튜디오 닷넷의 가장 중요한 프로그래밍 언어인 C#은 개발자들을 MS가 마련한 인터넷 컴퓨팅 환경으로 이주시키기 위한 도구입니다.

C#는 자바와 매우 비슷한 기능을 갖고 있으면서, 자바에 비해 더 적은 수의 제한을 두어 프로그래밍의 자유도를 높였습니다. 그리고 (물론) 기존의 비주얼 베이직 개발자들을 끌어들이기 위해 비주얼 베이직의 개발 환경을 그대로 답습하고 있기도 하죠.

한편, 선 마이크로시스템(Sun Microsystems)에서 개발한 또 다른 웹 서비스 개발 플랫폼인 J2EE(Java 2 Platform Enterprise Edition)의 경우, 이용하는 프로그래밍 언어는 오직 자바 뿐인 반면, 컴파일 된 소프트웨어는 다른 모든 플랫폼에서 돌아갈 수 있게 하고 있습니다.

J2EE에서는 프로그래머가 작성한 자바 소스코드를 "바이트코드"로 알려진 오브젝트 코드(object code)로 컴파일 됩니다. 이 뒤에 자바 버추얼 머신(Java Virtual Machine)이 바이트코드를 해석하고 직접 실행해 준다. 여기서 바이트코드는 통째로 각각 서로 다른 플랫폼에 맞는 "네이티브 코드"로 컴파일이 가능합니다. 이론상 자바 버추얼 머신이 설치된 플랫폼은 모두 이 바이트코드를 받아들일 수 있습니다. (자바 버추얼 머신은 메인프레임, 유닉스, 윈도 등 대부분의 운영 시스템에 탑재돼 있죠.)

설명된 바와 같이 닷넷은 여러 프로그래밍 언어를 지원하는 반면, 플랫폼은 (아직까지는) 윈도 밖에 지원하지 않습니다. 반면, J2EE는 자바 단 한가지의 언어만 지원하는 대신 (이론상) 버추얼 머신이 설치된 모든 플랫폼을 지원할 수 있습니다.

따라서, 자바 이외의 다양한 프로그래밍 언어를 이용하는 개발자라면 닷넷 플랫폼을 택할 것이고, 윈도 시스템이 아닌 다양한 플랫폼을 지원하는 개발자라면 J2EE를 선택할 겁니다.

그리고, 만일 MS 오피스와 같은 윈도용 애플리케이션을 제공해야 하는 ASP(Application Service Provider) 업체라면 닷넷을 선택할 것이고, 오라클 기반의 애플리케이션을 이용해야 하는 입장이라면 J2EE처럼 (여기저기 옮겨 다니기 쉬운) 플랫폼을 선택하겠죠.

그러나 J2EE와 같은 웹 서비스 솔루션들은 대개 개발자들을 위한 도구와 플랫폼만 마련해 놓았을 뿐, 웹 서비스의 현실화를 위한 경제 모델을 구축해 놓은 상태는 아닙니다.

반면, 닷넷은 이미 엄청난 수의 개발자들과 연계해 개발 플랫폼을 충분히 구축해 놓았고, 거기서 더 나아가 이 웹 서비스 개발 플랫폼으로 개발자와 기업이 충분한 ‘보상’을 받을 수 있는 장치를 마련해 놓았습니다. 즉, MS는 '닷넷을 개발하면 수익이 생긴다'는 보장을 해주기 때문에, MS는 현재 경쟁 웹 서비스 업체들보다 한발 앞서 있는 상황이죠.