썬-MS「하늘이 준 기회를 놓쳤다!」
MS가 썬의 자바를 퇴출시키는 작업이 거의 끝났다. 기업용 개발에 있어서 종종 자바가 필요한 경우를 제외하고는, MS의 모든 개발 계획에 있어서 자바는 포함돼 있지 않다.
John Carroll (Special to ZDNet) 2002/10/18
이것은 MS가 자바 기술 구현에 관해서 3년 6개월 동안 치룬 법정 투쟁의 결과다. 사람들은 썬이 법정 싸움을 성공적으로 끝냄으로써, MS가 자바의 WORA(Write Once, Run Anywhere) 약속을 오염시키는 것으로부터 세계를 구했다고 믿을 수도 있다.
사실 썬이 성취한 것이라곤 윈도우에서 가상머신(VM) 스타일의 기술을 무효화시킴으로써 "오염된" 자바(닷넷)가 등장할 수 있는 시장 기회를 없앤 것뿐이다.
썬은 MS가 계획대로 자바를 요리하게 방치해 개발자들이 스스로 선택을 하도록 하는 편이 나았을 것이다. 오히려 썬은 MS가 자바에 투자하고 마케팅에 쏟아부을 자원을 거부한 꼴이 됐다.
자바는 1996년 발표됐을 당시 MS를 포함해 컴퓨터 산업계 전반에 걸쳐 많은 환영을 받았다. 이 시기의 뉴스들은 MS 개발자들이 자바에 얼마나 열광적이었는지 자세히 적고 있다.
특히 MS R&D는 자바를 이용해 흥미있는 많은 일들을 했다. 이런 연구가 당시로서는 가장 빠른 자바 VM을 탄생시켰다. MS 개발도구인 J++는 자바 통합 개발 환경(IDE) 중에 가장 뛰어난 것중 하나로 널리 인정됐다. MS의 투자와 지원을 등에 업은 자바는 미래 소프트웨어 아키텍처라는 위치를 거의 굳힌듯 보였다.
최소한 썬의 입장에서 일이 어긋나기 시작한 것은 MS가 자바 VM에 추가 기능을 부가하고, 맘에 들지 않는 기능을 제거하려고 했을 때였다. 한 가지 예는 자바 애플리케이션이 운영체제의 고유 함수들을 호출할 수 있게 하는 JNI를 MS의 VM이 지원하지 않는다는 것이었다.
MS는 J/다이렉트라는 고유의 기술을 개발해 이러한 함수 호출이 더욱 쉽도록 했다(JNI의 harness 코드가 필요없었다). MS는 RMI를 자사의 클래스 라이브러리에 추가하지 않기로 결정했다.
RMI는 1997년 2월에 JDK 1.1과 함께 발표된 기술로 원격 객체를 호출하는 자바의 표준 아키텍처였다. MS는 또한 자바 언어에 기능을 추가해 '위임자(delegates)'를 두어 이벤트 통보를 효율적으로 하게 했다(이것은 현재 C#에서 찾을 수 있는 기능이다).
분쟁의 핵심
썬은 기저가 되는 운영체제에 상관없이 어떠한 VM에서도 모든 애플리케이션이 동작한다는 것에 자바의 중요성이 있다고 믿었다. 이러한 WORA 기능은 모든 플랫폼을 자바를 중심으로 조직된 소프트웨어 시장으로 편입시키려는 목적을 가졌다. 즉 인기가 없는 플랫폼에 좀더 많은 애플리케이션을 공급함과 동시에 윈도우가 쥐고 있던 애플리케이션상의 이점을 침식하려는 의도였다.
MS는 WORA 기능에 관해 다른 계획을 갖고 있었다. 점증하는 컴퓨팅 기기들의 네트워크를 위한 제품을 생산하는 소프트웨어 업체로서 어떤 기기에서도 동작하는 애플리케이션을 한 번만 작성한다는 것은 도움이 됐을 것이다.
또한 네트워크로 다운로드받은 코드들의 보안은 보장될 수 없었다. 이로 인해 스스로를 기술하는 자바의 '바이트코드' 포맷이 가진 보안 능력이 더욱 주목을 끌었다. 자바는 또한 고유 코드 개발을 개선한 것으로 생산성을 증가시키고, 버그가 없는 안전한 코드를 제작하기가 쉽다.
요약하면 자바는 소프트웨어 개발과정에서 많은 것을 추가할 수 있었는데, 세계에서 가장 큰 소프트웨어 기업인 MS로서는 분명 이익이 되는 일이었다.
그러나 MS는 시장에서 자사 제품을 차별화시키지 못한다는 사실에 흥미를 잃었다. 결국 차별화란 측면에서 MS의 VM에 애플리케이션들로 하여금 고유 코드(즉 윈도우 API)를 쉽게 호출할 수 있도록 하는 기능을 J/다이렉트를 이용해 추가했다.
또한 J/다이렉트 위에서 작성됐으며 WFC(Windows Foundation Classes)라고 불린 완전한 WIN32 API를 보다 잘 표현하는 윈도우 클래스 라이브러리도 제작했다.
이로 인해 윈도우 애플리케이션의 작성이 쉬워졌지만 어떤 플랫폼에서도 자바가 완전히 동일해야 한다는 썬의 비전과는 상충됐다.
썬은 소송을 제기했으며 결국 이겼다. 결과적으로 MS는 미래의 윈도우에서 자바를 포기했다.
상식적으로 생각하면 이러한 결과는 불가피했다. 그러나 과연 그럴까?
상이한 접근법
썬의 일차적인 목표가 완벽한 크로스 플랫폼 지원을 위해 일탈을 제한하는 것이었거나 아니면 전세계에서 가장 큰 소프트웨어 기업이 크로스 플랫폼 지원을 한다는 서명을 확실하게 받을 수 있었더라면(비록 그 회사가 실제로는 그런 결심을 하지 않았다고 하더라도)?
썬이 "좋다. 당신 회사의 VM에 특정한 기능을 추가하는 것은 좋다. 타당한 정도의 핵심 VM 기능과 라이브러리를 지원한다면 말이다. 그리고 VM 코어에 더해진 부가 기능들은 자바 커뮤니티에 환원돼 다른 구현에도 포함될 수 있도록 한다면 말이다"라고 말했으면 어땠을까?
다시 말해 핵심이 지원됨으로써 개발자들이 일관성있는 크로스 플랫폼 기준선을 갖도록 해야 한다. 그러나 원하는 기능은 무엇이든 추가할 수 있다. 타협의 여지가 있었다.
MS는 자사 VM에서 삭제했던 기능중 일부를 지원해야만 했겠지만, 그밖에 원하는 기능도 자유롭게 추가할 수 있었을 것이고, 심지어는 바이트코드 확장도 포함될 수 있었을 것이다.
호환성 측면에서 MS는 이미 필요한 위치에 서있었다. 최근 기사에서 래리 셀처가 시사한 바와 같이 실험결과는 MS VM이 가장 호환이 잘되는 자바 구현이었다는 것을 나타냈다.
순수 자바 애플리케이션들은 고유 함수 호출을 어차피 못할 것이고, 썬은 분명히 MS가 RMI(심지어 JNI)도 포함하도록 할 수 있었다. 자바 VM을 확장시킬 수 있는 자유의 반대급부로 말이다.
MS VM의 확장 기능을 자바 커뮤니티에 공개하는 문제에 있어서 썬이 요구했다면 MS가 긍정적으로 고려했을 것이란 증거가 있다. 다음은 자바월드 1999년 7월호의 기사이다.
MS는 최근 자바 통합 기술(J/다이렉트, 자바/COM, 위임자)을 개발도구 기업들에게 공개해 이들이 자사의 컴파일러와 VM에 이들 기술을 적용시키게 할 의사가 있다고 밝힘으로써 산업계 종사자들을 놀라게 했다. 이러한 움직임은 뉴워드와 같은 개발자에게 있어서 놀라운 것은 아니다. 그는 자바를 공개하는 것은 필수 불가결하다고 믿는 사람이다.
"MS는 썬이 거부한 것을 하고 있다. 즉 JVM을 모두에게 공개하고 볼 수 있도록 하는 일 말이다. 솔직히 말해 MS 중심적 사고를 가진 일부 개발자들은 MS VM 이외에서는 MS 고유 기능을 사용할 수 없다는 사실에 분노했다. 이것은 자바 로비(자바 온라인 공동체)에게 분명한 혼동을 주었다"고 뉴워드는 말했다.
물론 자바는 썬의 고유 기술이라고 지적할 사람들이 있을 것이다. 따라서 썬이 어떤 기능이 포함될지 결정할 수 있도록 말이다. 그 말이 사실이긴 하지만 썬의 목표가 비MS 플랫폼에서 동작하는 애플리케이션의 숫자를 확대시키는 것이었다면, 사업적으로는 별 의미가 없는 일이다. 썬은 법정 소송 대신 MS의 기세를 이용했다면 자기 목표를 달성하는데 더 유리했을 것이다.
뉴워드가 시사한 바와 같이 심지어 윈도우-중심의 개발자들도 크로스 플랫폼을 원했다. 썬은 MS가 제공하지 않는 것을 대신 제공함으로써 이러한 수요를 이용할 수 있었을 것이다.
어떤 형태로든 자바를 이미 사용하고 있던 이러한 윈도우 개발자들을 설득해서 진정한 크로스 플랫폼인 자바를 사용하도록 하는 것은 쉬웠을 것이다. 더욱이 MS VM의 확장 기능들을 복제할 수 있었다면 윈도우 개발자들은 다른 플랫폼용으로 프로그램을 제작하기 위해 자신들이 MS VM에서 선호한 기능들을 희생할 필요도 없었을 것이다.
뉴질랜드의 분자 생물 소프트웨어과 서비스 회사인 제나믹스(Genamics)의 수석 자바 개발자인 벤 알바하리는 썬에게 해주고 싶은 말이 있다. "당신들은 순수 자바에서 VJ++로 옮기는 사람보다 더 많은 사람이 윈도우 개발 도구에서 VJ++로 옮기는 것을 중단시켰다. 오염된 자바라 할지라도 아예 안쓰는 것보다는 자바를 사용하는 것이 낫다. 컴퓨터들이 충분히 빨라지고 순수 자바 라이브러리가 개선된다면 사람들은 순수 자바로 옮기기 시작할 것이다. 당신들은 이러한 과정을 지체시켰을 뿐이다. 뿐만 아니라 MS에게 진정으로 오염된 자바 클론의 구현이라는 선례를 MS에게 선사했다. 이는 순수 자바에게 있어서 진정으로 장기간에 걸친 위협이 될 것이다.(자바월드, 7월호)"
알바하리는 얼마나 선견지명이 뛰어난 사람이었는가?
결론
썬의 실수는 다방면에 걸쳐있다. 부분적으로는 개발자들이 크로스 플랫폼 자바와 특정 플랫폼에 묶여버린 자바를 구분하지 못할 것이라는 믿음의 결여로 설명될 수도 있다. 자바월드 기사가 시사하듯 MS 중심적인 개발자들은 MS VM에 존재한 특정 기능들이 다른 VM에도 존재하길 바랬다. 개발자들은 이러한 추가기능을 원하지 않는다고 말하지 "않았다". 단지 그들은 크로스 플랫폼이 있었으면 하고 바랬을 뿐이다.
이는 몇 가지 사실을 드러낸다. 첫째 개발자들은 크로스 플랫폼 자바와 특정 플랫폼용 자바를 구분할 수 있다. 둘째, 윈도우 개발자중에 크로스 플랫폼 제품을 원하는 수요가 있었다. 썬은 이러한 수요를 자사의 고유 라이브러리나 MS 라이브러리를 복제해 충족시킬 수 있었다. 엑시미안이 닷넷 프레임워크에서 하는 작업처럼 말이다.
셋째, MS는 개발자들이 흥미를 느낀 자바에 관한 아이디어를 가졌었다. MS는 자신들이 추가한 VM 기능을 좀더 폭넓은 자바 커뮤니티에 공개할 의사가 있었음을 증명했다. 썬은 이러한 공짜 R&D를 이용해 자바 플랫폼을 밀어줄 수 있었다.
썬의 실수는 또 소프트웨어 시장에서 MS의 중요성을 간과한 것을 포함한다. 세계에서 가장 인기있는 소프트웨어 제품을 생산하는 업체로서 MS가 그들 자신의 제품에서 특정 기술을 지원하기로 결정했다는 것은 그 기술의 성패를 결정한다.
더욱이 MS는 윈도우 제작사로서 윈도우 개발자들에게 상당한 영향력을 행사한다. MS는 윈도우에서 동작하는 가장 인기있는 소프트웨어 제품을 제작했다. MS는 윈도우용 개발 도구의 우수한 벤더이다. MS는 윈도우 개발자들을 위한 정보원이다(MSDN, MS 프레스 등).
MS가 특정 기술을 사용하도록 확신시킨다면 윈도우 개발자들을 그 기술로 유인하기가 훨씬 쉬워진다. 대다수 개발자들이 윈도우용 프로그램을 작성한다는 사실을 고려하면 이는 중요한 것이다.
썬은 잠재적으로 크로스 플랫폼의 가능성이 있는 인프라스트럭처에 MS가 서명하도록 집중했어야만 했다. 비록 MS가 완벽한 크로스 플랫폼 지원을 결심하지 않았더라도 말이다. MS는 기술세계에서 자사가 가진 상당한 능력을 자바 플랫폼을 대중화하는데 사용했을 것이며, 윈도우 개발자들로 하여금 자바 기술에 익숙해지도록 했을 것이다.
VM 환경의 개념을 이해하는 것은 API를 배우는 것보다 훨씬 많은 노력을 필요로 한다. 또한 다른 플랫폼으로 개발자들을 유인하는 것은 훨씬 쉬웠을 것이다.
썬은 MS가 기술 방향을 결정하는데 있어서 영향력을 행사할 기회를 가졌었다. 비록 자바에 대해서 썬이 좀더 적은 통제력을 갖게 됐을지라도 좀더 큰 영향력을 얻을 기회가 있었다.
대신에 썬은 MS가 상당한 자원을 썬이 통제할 수 없는 기술에 적용하도록 보증했다. 필자 생각이 옳다면, 그리고 닷넷이 크로스 플랫폼 통일을 위한 기술이 되어 "세계를 정복한다면", 썬의 유연성 부족은 전략적 실수로 간주될 것이다. 그 실수는 워싱턴주에 있던 한 이름없는 소프트웨어 회사(MS)와 비독점적인 협약에 서명하기로 한 IBM의 실수에 버금간다.
http://geekforum.kldp.org/stories.php?story=02/10/05/3903959 |
|hit:4924|2005/04/03
|
