다음은 코리아인터넷 닷컴에서 긁어온 기사입니다.
대체로 아주 현실적이고 잘 분석했다고 생각합니다. 평소에 제가 주장하던 바와도 거의 일치하기도 하구요.
잠깐 시간을 들여서 읽어보실 만한 가치가 있을 겁니다.

이 기사에서는 볼랜드는 싸악 무시하고 썼더군요. 한마디 안할 수가 없지요?
당근 원문 기사에 독자의견을 달았습니다. 기사 아래에 제가 올린 제 의견을 보실 수 있습니다.

원문 : http://korea.internet.com/channel/content.asp?cid=170&nid=16082
------------------------------------------------------

J2EE와 .NET, 무엇이 같고 무엇이 다른가

XML 웹 서비스가 컴퓨팅의 미래가 될 것이라는 데에는 별다른 이견이 없다. 이는 마이크로소프트가 현재
XML 웹 서비스 플랫폼인 닷넷(.NET)에 전력을 쏟고 있는 것과 무관하지 않다.

하지만 웹 서비스를 위한 플랫폼은 닷넷만 있는 것이 아니다. 선 마이크로시스템즈(Sun Microsystems)가
개발한 자바 2 플랫폼 엔터프라이즈 에디션(Java 2 Platform Enterprise Edition: J2EE) 역시 웹 서비스
개발을 위한 플랫폼으로, 앞으로 인터넷 애플리케이션 개발 분야에서 MS와 치열한 경쟁을 벌일 것으로 보인다.

J2EE는 기본적으로 Sun의 자바를 이용해 기업용 애플리케이션을 개발할 수 있게 해주는 표준 ‘세트’다.
그리고 물론, 앞으로 J2EE는 웹 서비스 개발에 최적화 되기 위해 계속 업그레이드 될 것이다.

J2EE는 현재 IBM과 BEA, 휴렛-팩커드, 그리고 오라클과 같은 헤비급 애플리케이션 서버 업체들로부터 전폭
적인 지원을 받고 있다. Sun은 조만간 웹 서비스 팩(Web Services Pack)을 공개해 개발자들이 J2EE 플랫폼과
XML으로 보다 편리하게 웹 서비스를 제작할 수 있도록 할 예정이다.

웹 서비스의 ‘기적’

그렇다면 웹 서비스란 도대체 뭘까? 웹 서비스는 간단히 말해 서로 다른 애플리케이션들을 ‘이어주는’
역할을 하는 것이다. 즉, 서로 다른 애플리케이션이 서로 교신하고, 데이터를 공유하며, 그리고 서로
작동하게도 할 수 있게 해주는 것이다.

웹 서비스가 서로 다른 애플리케이션을 이어주는 ‘놀라운’ 능력을 발휘하게 된 것은 모두 XML 덕분이다.
인터넷 애플리케이션들은 HTTP와 같은 표준 웹 프로토콜 상에서 XML 메시지를 주고 받으며 서로 호환/공유/
교신할 수 있게 된 것이다.

웹 서비스는 모두 XML이나 SOAP(Simple Object Access Protocol), WSDL(Web Services Description
Language), 그리고 UDDI (Universal Description, Discovery, and Integration)와 같은 ‘표준 구성 요소’
들을 이용한다. 때문에, 이론상, 닷넷과 J2EE 기술은 이런 구성 요소들을 통해 서로 호환이 가능하다.

그러나 실제로는 그렇지 못하다. 닷넷 플랫폼과 J2EE이 서로 이렇게 갈라서 있는 이유는 (당연한 얘기겠지만)
지원하고 있는 기업이 다르기 때문이다. 닷넷은 MS라는 거대 기업 하나가 지원하고 있는 반면, J2EE는 여러
다른 회사들이 공동으로 지원하고 있다.

사실 J2EE는 사실 하나의 기업이 단독으로 개발한 하나의 제품이라고 말할 수 없다. J2EE는 수많은 개발자
들이 자유롭게 이용하고 의존할 수 있는 개발 표준의 ‘집합체’다.

MS의 닷넷이나 J2EE은 모두 아직 완성된 형태가 아니며, 그 각자의 개념에 대해 확실한 정의도 내릴 수 없는
상태다. 하지만 두 플랫폼의 정체와 완성된 세부 사항들은 조만간 밝혀질 것이다.

비록 완성되지 않은 상태라 하더라도 이 두 가지 플랫폼은 앞으로 웹 서비스 개발 분야에 확고한 위치를
점하게 될 것이다. 그렇다면 앞으로 ASP 업체와 소프트웨어 개발자들은 J2EE와 닷넷 중 어느 플랫폼을 선택
해야 하는 것일까?

플랫폼이냐, 프로그래밍 언어냐 그것이 문제로다

J2EE와 닷넷의 가장 중요하고 두드러진 차이점은 먼저 사용하는 프로그래밍 언어에서 발견된다.

닷넷을 구성하는 소프트웨어는 닷넷 버전의 비주얼 베이직, C, C# (“씨-샵”이라고 읽는다. C#은 C와 C++
에서 파생된, 새로운 객체 지향 프로그래밍 언어다)와 같은 여러 언어를 이용해 제작할 수 있다. 이들 개발
툴들은 모두 MS의 비주얼 스튜디오 닷넷(Microsoft's Visual Studio.Net) 브랜드에 속해 있다.

이런 프로그래밍 언어로 작성된 소스 코드는 (닷넷 소프트웨어로 작동되기 위해) 마이크로소프트 인터미디엇
랭귀지(Microsoft Intermediate Language: 줄여서 MSIL이나 IL이라고 한다)로 컴파일 된다. 그리고 이렇게
컴파일 된 MSIL 코드는 커먼 랭귀지 런타임(Common Language Runtime: CLR)으로 다시 컴파일 되거나, 아니면
직접 각각의 플랫폼에 맞는 네이티브 코드로 컴파일 된다.

물론, 현재 여기서 지원되는 플랫폼은 윈도 시스템 뿐이다.

이론상, 비주얼 베이직, C# 이외의 프로그래밍 언어로 작성된 코드도 MSIL로 컴파일 되면 닷넷 플랫폼용
소프트웨어로 이용될 수 있다.

반면, J2EE가 이용하는 프로그래밍 언어는 오직 자바 뿐이다. 프로그래머가 작성한 자바 소스 코드는 바이트
코드(bytecode)라고 알려진 오브젝트 코드(object code)로 컴파일 된다. 자바의 바이트코드는 MSIL 코드와
같은 개념으로 이해될 수 있다.

이렇게 된 후엔, 자바 버추얼 머신(Java Virtual Machine)이 이 바이트코드를 해석하고 런-타임시 직접 실행해
준다. 여기서도 바이트코드는 통째로 각각의 플랫폼에 맞는 네이티브 코드로 컴파일이 가능하다.

이론상 자바 버추얼 머신이 설치된 플랫폼은 모두 이 바이트코드를 받아들일 수 있다. (자바 버추얼 머신은
메인프레임, 유닉스, 윈도 등 대부분의 운영 시스템에 탑재돼 있다.)

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

이렇게 되면 개발자들의 선택은 조금 분명해 진다. 자바 이외의 다양한 프로그래밍 언어를 이용해야 하는
개발자라면 닷넷 플랫폼을 택할 것이고, 윈도 시스템이 아닌 다양한 플랫폼을 지원해야 하는 개발자라면
당연히 J2EE를 선택해야 할 것이다.

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

하지만 문제는 개발툴이다

개발툴은 모든 플랫폼의 성패를 결정짓는 가장 중요한 요소다. 지금까지 MS의 윈도 플랫폼이 성공을 거둘 수
있었던 것은 바로 이 개발툴 덕택이었다. MS는 그간 비주얼 스튜디오와 같은 개발툴을 개발자들 사이에
배포해 자사의 플랫폼을 위한 애플리케이션 개발을 촉진했다.

MS가 닷넷을 위해 만든 개발툴, 비주얼 스튜디오 닷넷(Visual Studio.Net) 역시, 비주얼 스튜디오의 명성을
그대로 이어받아, 닷넷 상에서의 웹 서비스 제작을 훨씬 쉽고 빠르게 만들어 줄 것이다.

물론 J2EE를 위한 개발툴도 있다. Sun을 비롯해 BEA, IBM과 같은 거대 기업들이 J2EE를 위한 개발툴을 공급
하고 있다. 이들 개발툴들은 종류가 다양하긴 하지만 서로 간에 어느 정도 호환이 가능하다.

이들 J2EE 개발툴들이 비록 업계의 내노라 하는 기업들이 공급하는 것이긴 하지만, 비주얼 스튜디오의 위력
앞에선 크게 밀리고 있다. 일단 비주얼 스튜디오는 다른 어떤 개발툴 보다도 사용자 수가 압도적으로 많다.
이토록 개발자들 사이에서 커다란 인기를 끌고 있는 ‘막강’ 비주얼 스튜디오를 앞세워 MS는 닷넷을 최상의
웹 서비스 개발 플랫폼으로 구축한다는 계획이다.

실제로 많은 전문가들이 개발툴의 압도적인 우세 덕분에 닷넷의 중요도가 더해지고 있다고 평가하고 있다.

그러나 서밋 스트레티지즈(Summit Strategies)의 분석 전문가 드와잇 데이비즈(Dwight Davis)는 다음과 같은
견해를 밝혔다. “일반적인 견해로 자바 개발자 커뮤니티가 닷넷보다 조금 뒤쳐져 있다는 것이 사실이다.
하지만 현재 자바 커뮤니티는 계속된 성장세를 보이고 있다. 게다가 지금 자바가 개발자 수 면에서 MS가
생각하고 있는 것만큼 뒤쳐져 있는 것도 아니다.”

그렇다면, J2EE과 닷넷 중 어디가 유리한지?

개발자들은 당연히 이 시점에서 J2EE과 닷넷 중 어느 쪽을 선택해야 할지 고민에 빠지게 된다. J2EE이나 닷넷
둘 중 하나를 섣불리 선택했다간 나중에 시장에서 ‘비주류’로 밀려난 플랫폼에 꼼짝없이 ‘갇히게’ 된다는
두려움 때문이다.

하지만 현실적으로 둘 중 하나가 비주류로 밀려나거나, 개발자들이 호환도 되지 않는 개발 플랫폼에 갇히는
일은 일어나지 않을 것이다. 이유인 즉, J2EE과 닷넷 두 가지 플랫폼은 서로 공존할 가능성이 크기 때문이다.

E비즈니스 소프트웨어 개발사인 리모트앱스(RemoteApps)의 CEO 이언 맥비스(Ian McBeath)는 이에 대해
다음과 같이 설명했다.

“닷넷은 MS라는 강력한 후원자가 뒷받치고 있고, J2EE 뒤에는 많은 업계 대표적인 기술 제공 업체들이
버티고 있다. J2EE과 닷넷은 서로 경쟁하는 동시에, 공존하기 위해 태어났다. 이 두 플랫폼은 상호 경쟁하면서
각자의 취약점을 개선해 나갈 것이기 때문에 업계 전체로 봐서는 커다란 이득이 될 것이다.”

컨설팅 업체인 컨쿠어즈 그룹(Concours Group)의 제이 윌리엄즈 역시 어느 한쪽이 비주류가 된다는 것은
지나치게 과장된 생각이라고 일축했다. 하지만 그는 다만 MS가 자사 이외의 다른 표준들을 지원하지 않는다는
것이 문제점으로 남아있다고 지적했다.

“MS는 앞으로도 얼마든지 오피스와 같은 자사의 애플리케이션을 닷넷에서만 작동耽?할 수 있을 것이다.
그러나 MS가 지원하지 않는 표준 사용자가 자꾸만 늘게 되면 MS도 어쩔 수 없이 이들을 지원해 줄 수 밖에
없다. MS는 전에도 윈도 이외의 플랫폼을 위해 자사의 애플리케이션을 개방한 바 있었다.”

서밋 스트레티지즈의 데이비즈는 이런 논리는 J2EE에도 그대로 적용된다고 말했다. “개발자들은 J2EE과 같은
한가지 플랫폼만 위해 코드를 짜지 않을 것이다. 독립 소프트웨어 개발사(Independent Software Vendor:
ISV)들은 자사 소프트웨어의 경쟁력을 키우기 위해 한 가지 이상의 플랫폼을 지원하는 소프트웨어를 계속
개발할 것이고 이렇게 되면 시장은 더욱 다양해 지게 된다.”

보다 현실적인 전망들

개발자들이 어떤 플랫폼을 선택할 때는 차후의 ‘전망’보다는, 당장의 현실적인 요인에 의해 결정을 내리는
경우가 더 많다고 한다.

말하자면, 어떤 플랫폼이 약세고 강세이라는 사실을 떠나, 비주얼 베이직이나 C 프로그래밍에 더 능숙한
사람은 당연히 닷넷 플랫폼을 선호할 것이고, 자바 프로그래머들을 더 많이 고용하고 있는 소프트웨어
개발사라면 당연히 J2EE를 선택하게 될 것이라는 뜻.

데이비즈는 J2EE과 닷넷이 각각 성장하면서 점점 더 많은 공통 분모를 가지게 될 것이라고 설명했다. 그
공통 분모란 바로 XML이다. 데이비즈는, “현재는 각 플랫폼 간의 개발툴이 많이 다르다. 그러나 이들은
XML을 통해 어느 정도 합쳐질 가능성이 높다”라고 말했다.

결국 모든 이들이 바라는 것은 모든 웹 서비스가 개발 플랫폼에 관계없이 하나처럼 호환되는 것이다.
애플리케이션과 개발 환경에 상관없이 안정적인 호환을 이루는 것이 웹 서비스의 진정한 모습이기 때문이다.

많은 사람들은 MS 측이 ‘어쩌면’ XML과 같은 웹 서비스 표준 요소들을 저버리고 기존의 자사 플랫폼에만
집착할 지도 모른다는 회의적인 반응을 보이기도 한다. 그러나 윌리엄즈는 다음과 같이 결론 내렸다.
“XML로 대표되는 웹 서비스 표준은 이제 결코 무시할 수 없는 대세다. MS도 이미 이 사실을 잘 알고 있다.
MS는 결코 다른 웹 서비스 표준들로부터 고립되는 우를 범하지 않을 것이다”


제공 : 코리아인터넷닷컴,2001년 08월 22일
저자 : Paul Rubens

------------------------------------------------------
의견게시

제3의 세력: 볼랜드

MS와 자바 진영이 너무 큰 컨셉에 매달려 아직 양쪽 모두 웹서비
스 플랫폼의 정식제품을 내놓지 못하고 있는 사이, 볼랜드는 이미
몇달 전에 델파이6라는 최초의 웹서비스 개발 플랫폼을 내놓았습니
다.

게다가 올 3/4분기에 출시될 C++Builder 리눅스 에디션과 4/4분기
에 출시될 C++Builder6 윈도우 에디션에서도 웹서비스 개발을 지원
할 전망입니다. 즉, 올해가 가기 전에 볼랜드는 리눅스와 윈도우 양
쪽에서 소스 레벨에서 100% 호환되는 웹서비스 개발 플랫폼을 출시
하게 되는 거지요.

MS와 썬에서는 새로운 컨셉인 웹서비스 등을 지원하기 위해서는
기존의 언어를 탈피해 새로운 언어로 가야한다고 주장하지만, 그 사
이 델파이 개발자는 전통의 파스칼을 이용해서 이미 웹서비스를 개
발해서 실무에 적용하고 있습니다. 또한 곧 C++로도 같은 일을 하
게 될 것입니다.

반드시 새 술은 새 부대에 넣어야 하는 것은 아니라고 생각합니다.
이미 오랫동안 실무에서 사용되던 '부대'가 수없이 많이 있는데,
그 '부대'들을 몽땅 버리고 새 부대를 장만하라고 우기는 것은 상술
일 뿐일 겁니다. 더욱이 '부대'가 개발자들 자신이라는 것을 잊지 말
아야 합니다.

이리저리 흔들어대는 IT 대기업들 속에서 피해를 보는 것은 결국 개
발자들일 뿐입니다. MS가 자바에 대항하기 위해 C#을 전략적으로
밀기 위한 목적으로 비베 개발자들을 희생시키고 있는 예에서 보다
시피 말이죠.

결과적으로, 썬이든 MS든 그리고 볼랜드이든 선택의 열쇄, 그리고
앞으로의 승패는 개발자에게 달려있는 것과 마찬가지로, 그에 대한
결과도 개발자가 전적으로 떠맡게 된다는 것을 잊지 말아야 하겠지
요.