오늘 조금 전에 올린 IT 뉴스의 가장 머릿기사를 보시면, 썬과 MS가 자바를 두고 벌인 전쟁에 대한
기사가 있습니다. 한번 보시죠.
"썬-MS「하늘이 준 기회를 놓쳤다!」"
http://www.borlandforum.com/impboard/impboard.dll?action=read&db=itnews&no=1975

제가 IT 뉴스를 올리기는 하지만, 그 기사의 시각에 100% 동감하기 때문만은 아닙니다. 하루에 수백건이
올라오는 각종 IT 관련 매체들의 기사들 중에서 10건 내외를 선별하여 올리는 데는, IT 업계의 흐름에
있어 중요한 사건의 전달도 중요하지만, 또 IT 업계에 발을 담그고 있는 사람이라면 한번쯤은 생각해봐야
할 문제들에 대해 짚어보는 관점도 중요하다고 생각합니다.

바로 위에 언급한 기사의 경우에는, MS와 썬의 자바 전쟁에 대해 다루고 있지만, 필자가 도출한
결론은 제 시각과는 아주 정 반대입니다. 그럼에도 개발자라면 한번쯤은 생각을 해보고 지나가야 할
중요한 사건이었기에 올렸답니다.

위 기사가 넘 길어서 다 읽어보시지 않은 분들을 위해 위 기사를 간단히 요약하자면, MS가 비호환
자바 기술로 썬의 자바 표준을 어지럽히고 있을 때, 썬은 MS를 소송 등의 방법으로 제재하기 보다는
MS와의 협력을 통해 자바 진영의 품안으로 끌어들였어야 했다는 얘깁니다. 한마디로 때려서 쫓아내기
보다는 얼러서 델구 살아야 한다는 얘긴데요.

일견 그럴 듯 해보이는 내용입니다. 썬이 자바의 스펙을 관리해오는 과정에서 폐쇄적이거나 자사의
이익만을 위해 자바 표준을 자사의 의도대로 끌고가려는 보수적인 모습을 보인 적이 몇번 있었습니다.
또한 MS가 썬의 방해없이 자바에 좀 더 적극적으로 참여할 수 있었더라면, MS는 자바의 발전에
아주 긍정적인 역할을 했으리라는 점에도 동의합니다.

그리고 덧붙여 말하자면, MS가 자바에 더 적극적으로 뛰어들 수 있는 기회가 있었더라면 닷넷의 출현도
없었을지도 모른다는 생각도 듭니다. 사실 닷넷은 지금까지도 성공여부가 불투명한 모호한 상태에
있을 정도로, MS로서도 상당한 부담을 가지고 뛰어든 비즈니스이기 때문이죠.
(기업으로서, 필요한 결과를 '필요한 시기에' 얻어내지 못하면 성공이 아니죠)

하지만, MS에게 더 많은 기회를 제공하는 편이 썬 스스로에게나 대다수 개발자들에게도 도움이
되었으리라는 필자의 시각에는 반대입니다.

필자인 존 캐롤은, 본문에는 쓰지도 않은 핵심적인 전제를 기반에 깔아놓고 그것은 당연한 것처럼
기사를 쓰고 있습니다. 그 전제란, 자바의 근본적인 큰 테두리 내에서 MS와 썬이 자바의 발전을 위해
협조하고 공존할 수 있다는 것입니다.

적어도 지금은 상당부분 아니라고 할 수 있지만, MS가 VJ++과 J다이렉트 등을 내놓으면서 자바에
본격적으로 발을 뻗고 있던 시점에서는, 썬은 소프트웨어 전문 기업이라고 부를 수도 없는,
거의 완전한 하드웨어, 정확히는 서버 하드웨어 기업이었습니다. 반대로, 아시다시피 MS는 그때나
지금이나 소프트웨어 업계에 있어서는 절대적인 영향력을 가지고 있지요.

썬은 MS의 소프트웨어 업계에 대한 영향력에 전혀 대항력이 없었고, 만약 MS가 그대로 활개를 치도록
두었다면, MS가 자바 진영을 통째로 집어삼키는 것은 몇년 걸리지 않았을 것입니다. 예를 들어서
J다이렉트 등에 비표준 윈도우 호환 기능을 지속적으로 추가하여 윈도우 데스크탑 애플리케이션에서의
자바 성능을 지금보다는 비약적으로 끌어올릴 수 있었습니다.

비표준 윈도우 호환기능을 추가하려고 맘먹는다면 이런 일은 어려운 문제가 아닙니다.
예를 들어, 썬이라고 하더라도 솔라리스 X윈도우만을 위한 비표준 기능을 추가했더라면 솔라리스에서만은
데스크탑 자바 성능을 충분히 끌어올릴 수 있었을 것입니다.
하지만, 핵심적인 문제는, 문제는 그렇게 한다면 그것은 이미 '자바'가 아니라는 것입니다.

물론 데스크탑 애플리케이션에서의 자바의 영향력이 늘어날 수 있는 중요한 요인이므로 좋은 일이라고
생각할 수도 있지만, 많은 사람들에게 '자바=MS'라는 공식을 성립시킴으로써 그로 인해 데스크탑 분야
뿐 아니라 서버 분야, 다시 말해 유닉스/리눅스 분야(당시에는 MS는 거의 힘을 못쓴 상황이었죠)까지,
모든 IT 분야를 손쉽게 먹을 수 있는 기회였다는 것입니다.

이러한 MS의 행보는 지금 MS가 닷넷으로 드라이브하고 있는 현황에 비추어보면 사실 거의 당연한
것입니다. MS가 닷넷을 추진하는 원인은 두가지 관점에서 생각해볼 수 있습니다. 첫번째는, 수십년간
노려온 서버 분야(최근에는 엔터프라이즈 분야)로의 점유율 확산입니다. 두번째는 향후 줄어들 것으로
예상되는 기존 시장(데스크탑용 OS 및 오피스 등)에 대한 업그레이드 수요를 대대적으로 일으켜서
잠재적인 위기를 탈출하기 위함입니다.

썬이 MS에게 자바를 던져주는 것은, 이러한 MS의 필요성을 닷넷이라는 엄청난 모험을 할 필요도 없이
기본좋게 냠냠할 수 있는 기회를 주는 것입니다. MS는 오직 윈도우 플랫폼만을 고려하므로,
자바에 있어 MS는 처음부터 호환성을 고려할 필요가 없는 입장에 서 있었습니다.

다시 말해, '자바는 호환성이다'라는 구호를 썬이나 IBM등 자바 진영의 멤버들이 열심히 외치는 동안,
MS는 '근데 우리 자바는 비호환입니다'라는 말을 할 필요도 없이 그 효과는 고스란히 받아먹고
비호환 자바로 자바 시장을 쓸어버리게 됩니다. 결과적으로 썬이 호환성을 외치는 것이 자바의
비호환화에 일조하게 되는 것입니다.

이것은 자바의 근원적인 딜레마입니다. 비호환 자바 구현을 자바의 영역으로 인정하게 되면, 순수
자바나 비호환 자바나 다 자바이니까, 그 다음 이슈는 성능이 됩니다. 그러면 개발자들은 당연히
성능이 더 높게 나오는 플랫폼을 선택할 수밖에 없게 됩니다.

이것은 당장 썬에게 치명적인 결과가 됩니다. 썬은 MS가 노리고 있는 유닉스 시장에서 가장 큰
벤더들 중 하나입니다. 결과적으로 자바가 썬에게는 매출을 급감시키는 웬수가 되지요.

이것은 비단 MS만의 문제가 아닙니다. 자바의 모토가 호환성이고, 자바의 성능상의 문제는 대부분
이 호환성 고수가 근본적인 원인이기 때문에, 어느 벤더이든지 자사 플랫폼에만 최적화된
비호환으로 자바 구현을 만든다면 자바 성능을 끌어올리기는 어렵지 않습니다.

MS도 이같은 썬의 반발이 나올 가능성을 충분히 예상했을 것입니다. 썬의 본격적인 제재가 시작되기
전에도 MS가 자바에 대해, MS가 할 수 있었던 것보다는 덜 적극적이었던 것은 이런 이유도 있었으리라
생각됩니다.

만약 썬이 MS의 비호환 자바를 인정했다면, MS는 닷넷이란 부담스런 전략을 내놓을 필요도 없이
자바 시장을 낼름 잡아먹고 지금쯤 더 승승장구하고 있을 것입니다. 썬이 그나마 MS를 자바에서
쫓아냄으로써 지금 정도라도 자바 시장이 유지될 수 있는 겁니다.

기본적으로, 캐롤의 시각은 비주얼 J++에 대해 향수를 가지고 있는 MS쪽 자바 개발자들의 입장을
대변한 것일 뿐입니다. MS와 자바 진영이 '화목하게' 잘 지낼 수 있는 그런 환경이 되었더라면
많은 자바 개발자들이 지금과 같은 고민은 하지 않아도 되었을텐데 하는 생각을 하는거죠.

하지만 그런 갖다붙이기식의 상상은 그야말로 공상일 뿐입니다.

썬이 처음 자바를 내놓은 것은 MS의 닷넷과 같이 자사 매출을 급진작시켜보려는 비즈니스 전략이
아니라, 연구의 부산물 정도였습니다. 그런만큼 자바는 초기부터 많은 자유로운 서드파티 개발자들의
관심을 끌게 되면서 상당부분 썬의 영향력을 벗어나게 되었고, 현재는 자바가 썬의 이익을 대변하기
보다는 자유로운 플랫폼으로서 인정을 받고 있는 것입니다. (썬은 자바의 어머니이면서도 자바에서
가장 돈을 못버는 벤더이기도 합니다. 정작 돈은 IBM과 BEA, 볼랜드가 벌고 있죠)
만약 자바가 MS의 닷넷처럼 초기부터 썬의 강한 비즈니스 전략의 틀에 묶여 있었다면 자바는 결코
성공할 수 없었을 것입니다. 또한 그 이후에도 썬이 더 강한 비즈니스 전략으로 자바를 독차지하려는
시도를 했더라면 자바는 풍지박산이 났을 수도 있습니다.


말을 한 김에 마저 합시다. 그럼, 앞으로는 어떻게 될까요.

꽤 오래전부터 예상되었던 것이지만, 최근의 보도로도 닷넷의 크로스플랫폼 가능성은 거짓에 가까움을
알 수 있습니다. MS는 C#이나 CLI 등의 스펙을 국제표준으로 올려놓고 다시 그 중 필수적인 부분에
특허를 걸어놓음으로써, 실질적으로는 제3자가 다른 플랫폼으로 닷넷을 포팅하는 것을 막고 있습니다.
국제표준은 무료(free)라는 업계의 상식에 법적인 구속력이 없다는 것을 악용한 것이라고밖에 말할
수 없습니다. RFC 822에 특허가 걸려있었다면, 이메일이 오늘날과 같이 인터넷의 가장 중요한 부분을
차지할 수 있었겠습니까?

그런데도 대다수 개발자들에게는 이런 사실은 알려지지 않습니다. MS의 복잡한 설명은, 대다수
개발자들에게 닷넷도 크로스플랫폼을 지원할 것처럼 느껴지도록 만드는 뉘앙스를 가지고 있습니다.
보도의 흐름을 잘 악용하는 MS이기 때문에 가능한 일이지요.

크로스플랫폼을 지원하지 않는다면 닷넷은 뭐하러 쓰는가?
MS는 자바는 여러 플랫폼을 지원하지만 닷넷은 여러 언어를 지원한다고 합니다.
그런데, 닷넷 이전에 윈도우 플랫폼에서 같은 역할을 했다고 할 수 있는 DLL이나 COM/DCOM 등은
여러 언어를 지원하지 않는가? 그렇다면 구태여 닷넷이라는 '새로운' 플랫폼을 만들어낼 필요 없이
기존의 기술을 강화시키고 발전시킴으로써 닷넷과 같은 효과를 낼 수도 있지 않았을까?

MS가 되풀이하면서 계속 내세우고 있는 닷넷의 신기술이란 것이 과연 뭘까요.
그 속내를 파헤쳐보면 결국 웹서비스일 뿐입니다. 하지만 우리 볼랜드 진영의 개발자들은 웹서비스가
닷넷이라는 완전히 '새로운' 플랫폼을 통하지 않아도 충분히 강력하게, 그리고 충분히 쉽게 구현할
수 있음을 알고 있습니다.

결과적으로, MS의 닷넷 전략은 말장난에 불과합니다. 크로스플랫폼이 되지 않는 한 CLI가 아니라
DLL이나 COM/DCOM으로도 충분합니다. 반대하고 싶은 분은 여기서 C#을 얘기할 수도 있을 것입니다.
하지만 C#은 분명히 자바 킬러로서 태어난 것으로서, C#이 꼭 필요한 분야라면 자바로 충분히
소화할 수 있었던 것입니다. 또 ASP닷넷은 어떨까요? 역시 좋기는 하지만, CLI를 통해 구현할 필요는
없었던 것입니다. CLI를 빼면, ASP닷넷 자체는 그리 기술적으로 대단한 것이 아닙니다.

IT 업계 중 가장 큰 덩치를 차지하는 분야들 중 하나인 소프트웨어 분야는 거의 대부분 개발자들의
영향력 아래에 있습니다. 결과적으로 MS 닷넷의 성공 여부는 개발자들이 얼마나 MS의 언변에
잘 속아넘어가느냐에 절대적으로 좌우됩니다. 그리고 빌게이츠가 시인했던 것처럼, '예상했던 것보다는
못미치고' 있습니다.

근본적인 문제로 돌아가봅시다. MS는 개발자들을 편하게 해준다면서 유혹하고 있죠.
그런데 개발자가 편하다는 것은 두가지 측면으로 생각해볼 수 있습니다. 개발 자체에서 소요되는
시간이 줄어드는 것과, 기술의 도입 혹은 업그레이드 과정에서 개발자가 공부해야 할 양이 줄어드는
것입니다.

첫번째는 50% 정도는 인정할 수 있습니다. '상당히' 편해질 수 있습니다.
하지만 우리 볼랜드 진영의 개발자들은, 그런 측면에선 볼랜드가 MS보다 더 낫다고 판단하고 있습니다.
두번째 문제는 어떨까요. MS는 이 문제에 대해 0점입니다.

그럼...