글로벌 칼럼 | 닷넷에 뒤처진 자바를 살리기 위한 2가지 방안

자바(Java) 8에는 그동안 기대를 모았던 상당히 많은 기능이 추가됐다. 그러나 자바 8의 기능 대부분은 물론, 자바 9로 미뤄진 기능들 대부분은 이미 닷넷(.Net)에서 지원하고 있다. 필자는 자바 언어에 온갖 모든 것이 추가되는 것을 그리 반기지 않지만 언어와 달리 자바 플랫폼은 다양한 기능들을 지원하는 방향으로 진화해야 한다고 생각한다. 닷넷은 훌륭한 기술이다. C#과 닷넷 플랫폼은 여러가지 측면에서 자바 3를 지향했던 당초 목표를 대부분 달성했다고 판단된다. (단 필자는 여전히 마이크로소프트의 운영 체제를 결코 좋아하지 않고 특히 이론적으로 고칠 수 없는 버그를 혐오한다)

두 플랫폼 이야기
마이크로소프트 닷넷의 신속한 버전업은 (자바 대비) 설치 기반이 더 작고, 마이크로소프트 자체가 개발자들의 기반을 흔들 의지가 더 강하다는 점에서 일면 당연하다. 그리고 이런 주장은 어느 정도 사실이다. 필자는 90년대와 2000년대 초반 마이크로소프트가 데이터베이스 API를 거의 매주 ODBC, RDO, ADO에서 OLEDB 등으로 바꿔 나가던 것을 기억한다. 이제 마이크로소프트는 일정한 임계치에 도달했고 닷넷의 빠른 진화도 계속되고 있다.

반면 자바는 닷넷에 크게 뒤처졌다. 어쩌다 이렇게 된 것일까? 초기 자바는 아주 빠르게 발전했다. 자바 1.0.2에서 자바 1.1로 단 1년 만에 급격하게 (그리고 불완전하게) 변화한 모습을 보았다. 1.1에서 1.2까지는 1년 반이 걸렸고, (숫자만큼이나 더 중요한 버전이던) 1.22 버전은 7개월여 후에 나왓다. 그리고 단 10달 만에 결정적인 자바 1.3이 공개되었는데 이는 서버 측을 염두에 두었던 가비지 콜렉터(garbage collector)가 포함된 첫 버전이었다.

이후 NIO와 regexp로 우리를 안내했던 자바 1.4은 2년이 안 되서 출시되었다. (안정적이지는 못했지만) 멀티코어 환경에서의 가비지 콜렉터를 제공했던 자바 1.4.2가 다시 1년 만에 출시되었다. 그리고 자바 1.5에는 병렬 병행 GC가 도입됐고 중요한 병행과 NIP기능을 추가했지만 여기에 다시 1년이 소요되었다.

전체적으로 좋은 성능을 보였던 자바 1.6은 로킹(locking)을 더 저렴하게 만들었지만, 1.5만큼 단단하지 못했고, 2년을 더 기다려야 했다. 자바 1.7은 1.4.2로부터 이어진 기저 VM 기술(G1 콜렉터)에 큰 변화가 있었는데, JVM의 다른 언어에 더 잘 연결할 수 있는 인보크다이나믹(invokedynamic) 기능이 추가되었다. 그러나 주요 버전이 1~2년마다 나오던 과거와 달리 거의 5년 주기로 늘어나 발전 속도가 분명히 느려졌다.

자바의 진보는 왜 느려졌나
자바의 발전 속도가 떨어진 원인에 대해 가장 먼저 지목되는 것은 썬(Sun)이다. 썬은 건강한 회사가 아니었다. 자바는 썬이 스파크(Sparc) 제품을 여기저기 판매하던 닷컴 열풍기에 태어났다. 인텔과 AMD의 가격은 하락했지만 스파크의 가격은 내리지 않았고 T1000과 이후 플랫폼들에 대한 호평에도 불구하고 경제성이 없었다. (후기 스파크 제품들은 더욱 효율적이었다. 그러나 가격이 너무 비싸 필자조차도 그 가격을 지불하느니 차라리 데이터센터 전력을 마호가니와 멸종위기종으로 공급할 수 있을 정도였다. 무슨 의미인가 하면 (국회의원들이 무역 한도 관련법을 통과시키긴 했지만) 하드웨어 가격 차이로 작은 열대우림 분량의 탄소 크레딧을 구입해 '이론적으로' 그 추가 전력 사용량을 메울 수 있다!)

닷컴 열풍이 꺼지고, 썬은 이미 구축된 대규모 아이언 클러스터(iron cluster)에나 적합한 '상용'(commodity) 컴퓨팅으로 하드웨어 사업 방향을 틀었다. 한마디로 잘못된 하드웨어 사업에서 잘못된 결정을 내린 것이다.

썬은 생태계를 만드는데 뛰어난 기업이었다. 기업들이 구매하고자 하는 제품만 만든게 아니었다. 반면 훗날 썬을 인수한 오라클은 생태계를 불태워버리고, 그 안에 존재하는 모든 회사를 인수하거나 파괴하고, 이를 대체할 자체 고수익 제품을 만드는데 능한 회사다. 오라클은 자바 7 출시 연기로 인한 시장과 정치적 측면에 영향에 대해 (전례가 없는) 공공 발표문을 통해 밝힌 바 있다. “다양한 사업적 정치적 이유 때문에, 새 버전의 출시에 시간이 걸리고 있음을 우리 모두 알고 있다”라는 식이다.

그러나 자바의 진보 속도가 느려진 진짜 이유를 찾으려면 썬의 재정적 한계를 넘어 자바를 둘러싼 시스템을 전반적으로 재검토해야 한다. 썬은 자바 표준화를 위해 자바 커뮤니티 프로세스(Java Community Process)라는 자체 “표준” 위원회를 설립했다. 본래 이 위원회는 일종의 불공정 담합소였다. 시간이 지남에 따라 어느정도 개방되었지만, 썬 그리고 이제는 오라클이 완벽한 거부권을 가지면서, 규정을 위반해 그들이 하고 싶은 모든 것을 결정하는 공간이 됐다.

JCP를 저해해 온 것은 무엇일까? 그것은 개방성이 아닌 이익 충돌이었다. 비록 필자는 옆에서 흥미롭게 지켜보기만 했지만, 당시 EJB3에 참여했던 어떤 업체를 기억한다. (그 업체의 이름은 영문 3글자였다!) 이들은 절차적 문제를 지적하며 발표 연기를 주장했다. 이유는? 자사 애플리케이션 서버에 통합할 제품을 구입하거나 개발해야 했기 때문이다. 차기 자바EE 스펙이 공개된 상황에서 시장에 뒤늦게 참여할 수는 없다는 계산이었다.

한 회사 내에서 한 가지 제품 출시를 조정하는 것도 어려운데 이런 상황이라면 무슨 설명이 더 필요하겠는가. 그러나 다행히도 합병을 통해 이런 문제들은 차차 개선될 것으로 보인다. 실제로 필자는 JCP가 자바가 가진 문제의 주요 원인이라고 생각지는 않는다.

받침 접시를 치워라: 자바의 경량화
오늘 날 썬은 기억 저편으로 사라지고, 오라클이 주인공이다. 그런데도 자바 업데이트에 왜 이리 오래 걸리는 것일까? 간단하다. 자바가 너무나도 거대하기 때문이다. 대규모 프로젝트는 느리게 진행되기 마련이고, 그 과정도 위험스러운 부분 투성이다. 그렇다면 문제를 어떻게 풀어야 할까? 자바를 '작게 만들 수 있는' 방안을 집중적으로 살펴보자.

우선 오라클은 그들의 클라이언트 기술에 대한 집착을 버려야 한다. 스윙(Swing)이나 현대적 웹 브라우저에서 문제를 더 많이 일으키는 오라클 자바FX 역시 마찬가지지만 오라클은 개발자들을 그들의 플랫폼에 묶어둘 필요가 있고, 최소한 그렇게 했다.

그러나 자바FX나 클라이언트 자바가 전략적으로 오라클에 어떤 실질적 이익을 가져다 주는지 필자는 솔직히 잘 모르겠다. 이는 VB6, 플래시 혹은 일종의 4GL과 경쟁을 염두에 두고 개발된 것으로 보인다. 그러나 이것은 전도유망한 중역들이 ‘아이패드에 손가락으로 입력하는걸 보니 멋진데’라고 생각하곤 하는 요즘의 현대식 BYOD 멀티플랫폼 환경과 그리 어울리지 않는다.

왜 클라이언트 측이 서버 측을 지체하도록 만들겠나? “자바 없는 날 보안 문제”와 “당신의 컴퓨터에서 자바를 비활성화하는 방법” 같은 제목의 기사 내용을 따라하면서 더 행복해하는 사용자들이 있다는 것을 진지하게 받아들여야 한다. 이를 통해 (이제야 사실상 퇴출을 앞두고 있지만 솔직히 끌어내 없애버려야 했을) 구식 플랫폼을 지원하는 부분을 떼어낼 수 있다.

물론 어쩌면 오라클은 이를 (그들의 또다른 재앙인) 자바 ME에 우겨 넣어 이를 오드로이드(Ordroid)로 부를지도 모른다. 만약 오라클이 블랙베리를 인수하고 이를 새 사업부문으로 옮겼다면, “미래의 플랫폼,” “아이폰 킬러”라고 하면서 초기에 그 허풍을 간파하지 못하는 투자자들을 적어도 반년 정도 끌어모았을 것이다

그러나 이것만으로는 부족하다. 자바와 자바 플랫폼도 분리해야 한다. 마이크로소프트는 지난 2007년 이후 자사 툴에서 이 둘을 사실상 통합했지만 분명하게 잘라내야 한다. 투박하게 말하면 자바 플랫폼에서 언어로서의 자바는 예전처럼 중요한 의미를 갖지 못한다. 따라서 자바 언어를 자바 플랫폼에서 단절해 자체 일정에 맞춰 발전시켜야 한다. 이것은 오라클에게도 좋을 것이다. 오라클이 만드는 개발 툴은 자바 관련 사업의 주요 부분도 아니며 실제로 자바 개발자들도 거의 사용하지 않는다. 마이크로소프트 역시 비주얼 스튜디오 차기 버전에서 닷넷과 C#을 통합해야 할 것이다.

자바 플랫폼은 자바스크립트(JavaScript), J루비(Jruby), 스칼라(Scala)에서부터 소수 언어에 이르기까지 다양한 언어를 담고 있다. 특히 클라우드에서는 이런 다양한 기술들을 성능과 확장성을 저하시키지 않으면서 지원해야 한다.

만약 클라우드가 미래라면, 자바 플랫폼과 오라클은 그 미래에 먼저 도달하고 싶어한다. 현재 자바와 오라클은 자연스럽게 그 위치에 서 있다. 다른 것들, 말하자면 루비, 스칼라, 어쩌면 노드.js(Node.js)까지 지원하는 가장 명백한 방식은 자바 플랫폼이다. 그러나 자바 플랫폼은 현재 그들 혁신의 엔진이라기보다는 닻의 역할에 그치고 있는 것으로 보인다.

필자는 자바 플랫폼에 추가할 요소에 있어 자바 SE 스펙 대표인 오라클의 마크 레인홀드보다 J루비/레드햇(Red Hat)의 찰스 너터와 스칼라/타입세이프(Typesafe)의 마틴 오더스키의 결정을 더 신뢰한다. 레인홀드를 무시하는 것이 아니라 (수많은 협업이 벌어지고 있다는 몇가지 증거가 있지만) 자바 언어나 오라클이 키우는 몇몇 프로젝트들을 기다리는 과정이 진보를 저해하기 때문이다.

그동안 자바에 대한 오라클의 리더십은 많은 풍파를 겪어왔다. 수많은 썬의 과거 결정들이 지금 다시 나타나 우리를 괴롭히기도 한다. 그러나 자바의 장기적인 발전을 위해서는 클라이언트-측 자바를 분리하고 JVM 공개 주기를 자바 언어와 별개로 운영하라. 모든 것을 한번에 하기보다는 플랫폼으로서 자바에 집중해야 할 시기다. editor@idg.co.kr