2015.05.22

자바 20주년: JVM, 자바의 또 다른 자산

Serdar Yegulalp | InfoWorld
자바가 이번 주 20주년을 맞았다. 물론 가장 먼저 떠오르는 것은 자바 언어 자체겠지만 사실 자바 언어의 기저에는 자바 자체 못지않게 중요하고 강력한 기술적 자산, 바로 자바 가상 머신(JVM)이 있다.

JVM은 특정 언어를 실행하도록 만들어지지 않았고(자바는 여러 가능성 중의 하나일 뿐임) 그 특성에 힘입어 일종의 플랫폼으로 자리매김했다. JVM을 위해 개발된 언어들은 자바와는 거의 아무런 연관성이 없다. JVM의 향후 개발 방향도 자바의 풍족한 라이브러리와 소프트웨어 자산을 활용할 수 있는 새로운 요소, 또는 자바와는 완전히 별개의 요소를 지향하고 있다.

JVM의 기반 엔진
JVM이라고 하면 보통 특정 JVM, 즉 썬마이크로시스템즈가 처음에 만들었고 현재 오라클이 소유한 JVM을 지칭한다. 이 JVM은 JIT 컴파일과 성능 가속을 위해 핫스팟 엔진을 사용한다. 핫스팟에서 작동하는 코드는 가끔 C/C++로 작성된 코드의 성능과 대등하거나 심지어 앞서기도 한다.

핫스팟 JVM이 유일한 자바 구현은 아니지만 탁월한 성능과 오랜 시간에 걸친 개발을 통해 사실상의 유일한 선택안이 됐다. 수없이 많은 다른 JVM이 나타났다 사라지는 동안 핫스팟(현재는 오픈 소스)은 엔터프라이즈 프로덕션에서 여전히 가장 보편적인 옵션으로 남아 있다.

물론 독자적인 JVM을 추구하는 경우도 종종 있다. 예를 들어 어떤 개발자는 온전히 구글 고(Go) 언어로 JVM을 개발 중이다. 다만 지금은 핫스팟의 경쟁 상대라고 하기는 어렵고 그저 실험 수준일 뿐이다.

그동안 핫스팟에 구현된 다양한 최적화 작업 덕분에 JVM은 그 자체가 다른 언어의 목표 플랫폼이 됐다. JVM의 빠른 속도와 크로스 플랫폼 구현을 활용하기 위해 완전히 새롭게 만들어지는 언어도 있고, 기존 언어가 이식되는 경우도 있다. 또한 JVM을 사용한다는 것은 언어를 위한 런타임을 처음부터 새로 만드는 수고를 덜 수 있음을 의미한다.

JVM의 대스타: 클로저(Clojure), 스칼라(Scala), 그루비(Groovy)
JVM에서 새로 만들어진 언어 중에서 가장 자바와 닮지 않은 언어를 꼽으라면 바로 클로저다. 클로저는 제작자인 리치 히키의 표현을 빌자면 “자바를 사용할 수 있는 모든 곳에서 사용 가능한”, 일종의 JVM을 위한 리스프(Lisp)로 고안된 함수형 언어다. 나아가 자바를 사용할 수 없는 곳까지 지향한다. 한 예로 최근 성능을 비롯한 여러 이유로 코어 언어를 루비에서 클로저로 교체한 퍼펫 서버(Puppet Server)가 있다.

클로저는 함수형 언어로서 갖는 강력함 외에, JVM용 언어를 만들 때 얻게 되는 부가적인 혜택 중 하나, 즉 자바 자체가 제공하는 모든 리소스, 대표적으로 스윙 또는 자바FX와 같은 라이브러리를 이용할 수 있다는 점을 잘 보여주는 예다. 클로저에 익숙한 개발자는 자바가 이미 제공하는 재료를 사용해서, 자바 코드를 직접 쓸 필요 없이 플랫폼 네이티브한 UI를 갖춘 프로그램을 만들 수 있다.

JVM을 위한 또 다른 함수형 언어인 스칼라는 구문 측면에서 자바와 더 근접하지만 잘 알려진 자바의 여러 제약을 극복하기 위한 목적으로 만들어진 언어다. 람다 표현식의 부재와 같은 일부 제약은 최근 자바 버전에서 해결되었지만, 스칼라를 만든 사람들은 이러한 개선이 개발자의 요구 수준을 더욱 높이게 될 것이며, 자바가 아닌 스칼라가 그러한 요구 수준을 충족하게 될 것으로 보인다.

과거 피보탈(Pivotal)이 주도했다가 지금은 아파치 소프트웨어 재단 프로젝트로 편입된 그루비 역시 자바의 보완재로 만들어졌다. 그로비는 루비 또는 파이썬과 같은 언어의 기능을 도입하면서도 자바 개발자들이 쉽게 접근할 수 있는 언어를 지향한다. 그루비는 많은 자바 식을 더 간결하게 다듬어 제공한다.

JVM 이식: 자이썬(Jython), J루비(JRuby)와 기타
개발 언어들이 JVM을 겨냥하면서 발생한 또 다른 결과는 JVM에서 실행되는 언어가 많아졌다는 것이다. 예를 들어 Node.js가 서버 측 개체로 실행된 최초의 자바스크립트라고 생각한다면 오산이다. 모질라의 리노(Rhino)가 1999년부터 자바로, JVM에서 이미 시작했다(2006년 이후에는 오픈 소스 버전만).

이식된 언어 중 가장 눈에 띄면서 엔터프라이즈 개발자와의 연관성도 큰 언어는 파이썬과 루비다. JVM에서 자이썬과 J루비로 구현됐다. 다른 JVM 언어와 마찬가지로 JVM에 호스팅함으로써 파이썬과 루비는 방대한 자바 소프트웨어에 접근할 수 있게 된다. 이 관계는 두 가지 방식으로 작용한다. 즉, 자이썬을 사용하면 자바 애플리케이션 내에서 테스트를 위한 스크립팅 언어로 파이썬을 활용할 수 있다.

JVM에서 언어가 빠른 편이라고는 하지만 JVM으로 이식된 언어가 다른 버전에 비해 더 성능이 우수하다는 보장은 없다. 예를 들어 자이썬은 일반적인 C파이썬 구현에 비해 빠를 때도 있고 더 느릴 때도 있다. 워크로드의 성격에 따라 성능이 크게 좌우되기 때문이다. 마찬가지로 J루비 역시 원조 루비보다 빠를 때도 있고 그렇지 않을 때도 있다.

JVM 호스팅 언어의 또 다른 단점은 원조 언어의 최신 버전을 따라가는 데 다소 시차가 있다는 점이다. 예를 들어 자이썬은 파이썬의 2.x까지만 지원한다.

JVM의 다음 단계
성능은 둘째치고 이러한 언어들이 자바를 대체하게 될 가능성은 별로 없다. 그러나 애초에 자바를 대체하는 것이 목적은 아니었다. 이렇게 광범위하게 사용되고 성공적이며 유용한 자바를 대체해야 할 이유가 무엇인가?

그보다는 자바를 중심으로 생겨난 문화(모든 라이브러리와 애플리케이션)를 가져와 JVM을 통해 자바 개발자에게 더욱 유용한 개발 환경을 만들어주려는 것이 주된 목적이다.

향후 JVM은 미래 지향적인 언어를 위한 개발 환경으로 사용할 수 있도록 더 쉬워질 것이다. 오라클은 2014년 자바 API를 통해 JVM의 내부를 공개하는 프로젝트인 그랄(Graal) VM을 공개했다. 프로젝트가 성공적으로 끝나면 개발자는 자바를 일종의 지휘통제 언어로 사용해서 JVM을 위한 새로운 언어를 만들 수 있게 된다. (그랄로 호스팅되는 자바스크립트, 루비, R의 프로토타입은 아직 불안정하긴 하지만 기대감을 주기에 충분했다.)

예상하기 어려운 점은 자바 자체만큼 영향력 있고 광범위하게 사용되는 새로운 언어가 JVM 또는 그 후속 기술을 통해 탄생할지, 아니면 전혀 다른 방향에서 탄생할지다.

자바스크립트와 자바스크립트용 V8 엔진은 자바의 후계자로 유력한 후보다. Node.js는 이미 자바와 유사한 소프트웨어 재사용 문화를 정착시켰고, 자바스크립트로 트랜스파일(Transpile)되는 언어들은 자바스크립트를 작성할 필요 없이 이 생태계를 이용할 수 있게 해준다.

이처럼 자바가 대대적인 변화를 준비하는 가운데, JVM에서 사용할 수 있는 언어도 이제 태동기를 맞이한 것으로 보인다. editor@itworld.co.kr


2015.05.22

자바 20주년: JVM, 자바의 또 다른 자산

Serdar Yegulalp | InfoWorld
자바가 이번 주 20주년을 맞았다. 물론 가장 먼저 떠오르는 것은 자바 언어 자체겠지만 사실 자바 언어의 기저에는 자바 자체 못지않게 중요하고 강력한 기술적 자산, 바로 자바 가상 머신(JVM)이 있다.

JVM은 특정 언어를 실행하도록 만들어지지 않았고(자바는 여러 가능성 중의 하나일 뿐임) 그 특성에 힘입어 일종의 플랫폼으로 자리매김했다. JVM을 위해 개발된 언어들은 자바와는 거의 아무런 연관성이 없다. JVM의 향후 개발 방향도 자바의 풍족한 라이브러리와 소프트웨어 자산을 활용할 수 있는 새로운 요소, 또는 자바와는 완전히 별개의 요소를 지향하고 있다.

JVM의 기반 엔진
JVM이라고 하면 보통 특정 JVM, 즉 썬마이크로시스템즈가 처음에 만들었고 현재 오라클이 소유한 JVM을 지칭한다. 이 JVM은 JIT 컴파일과 성능 가속을 위해 핫스팟 엔진을 사용한다. 핫스팟에서 작동하는 코드는 가끔 C/C++로 작성된 코드의 성능과 대등하거나 심지어 앞서기도 한다.

핫스팟 JVM이 유일한 자바 구현은 아니지만 탁월한 성능과 오랜 시간에 걸친 개발을 통해 사실상의 유일한 선택안이 됐다. 수없이 많은 다른 JVM이 나타났다 사라지는 동안 핫스팟(현재는 오픈 소스)은 엔터프라이즈 프로덕션에서 여전히 가장 보편적인 옵션으로 남아 있다.

물론 독자적인 JVM을 추구하는 경우도 종종 있다. 예를 들어 어떤 개발자는 온전히 구글 고(Go) 언어로 JVM을 개발 중이다. 다만 지금은 핫스팟의 경쟁 상대라고 하기는 어렵고 그저 실험 수준일 뿐이다.

그동안 핫스팟에 구현된 다양한 최적화 작업 덕분에 JVM은 그 자체가 다른 언어의 목표 플랫폼이 됐다. JVM의 빠른 속도와 크로스 플랫폼 구현을 활용하기 위해 완전히 새롭게 만들어지는 언어도 있고, 기존 언어가 이식되는 경우도 있다. 또한 JVM을 사용한다는 것은 언어를 위한 런타임을 처음부터 새로 만드는 수고를 덜 수 있음을 의미한다.

JVM의 대스타: 클로저(Clojure), 스칼라(Scala), 그루비(Groovy)
JVM에서 새로 만들어진 언어 중에서 가장 자바와 닮지 않은 언어를 꼽으라면 바로 클로저다. 클로저는 제작자인 리치 히키의 표현을 빌자면 “자바를 사용할 수 있는 모든 곳에서 사용 가능한”, 일종의 JVM을 위한 리스프(Lisp)로 고안된 함수형 언어다. 나아가 자바를 사용할 수 없는 곳까지 지향한다. 한 예로 최근 성능을 비롯한 여러 이유로 코어 언어를 루비에서 클로저로 교체한 퍼펫 서버(Puppet Server)가 있다.

클로저는 함수형 언어로서 갖는 강력함 외에, JVM용 언어를 만들 때 얻게 되는 부가적인 혜택 중 하나, 즉 자바 자체가 제공하는 모든 리소스, 대표적으로 스윙 또는 자바FX와 같은 라이브러리를 이용할 수 있다는 점을 잘 보여주는 예다. 클로저에 익숙한 개발자는 자바가 이미 제공하는 재료를 사용해서, 자바 코드를 직접 쓸 필요 없이 플랫폼 네이티브한 UI를 갖춘 프로그램을 만들 수 있다.

JVM을 위한 또 다른 함수형 언어인 스칼라는 구문 측면에서 자바와 더 근접하지만 잘 알려진 자바의 여러 제약을 극복하기 위한 목적으로 만들어진 언어다. 람다 표현식의 부재와 같은 일부 제약은 최근 자바 버전에서 해결되었지만, 스칼라를 만든 사람들은 이러한 개선이 개발자의 요구 수준을 더욱 높이게 될 것이며, 자바가 아닌 스칼라가 그러한 요구 수준을 충족하게 될 것으로 보인다.

과거 피보탈(Pivotal)이 주도했다가 지금은 아파치 소프트웨어 재단 프로젝트로 편입된 그루비 역시 자바의 보완재로 만들어졌다. 그로비는 루비 또는 파이썬과 같은 언어의 기능을 도입하면서도 자바 개발자들이 쉽게 접근할 수 있는 언어를 지향한다. 그루비는 많은 자바 식을 더 간결하게 다듬어 제공한다.

JVM 이식: 자이썬(Jython), J루비(JRuby)와 기타
개발 언어들이 JVM을 겨냥하면서 발생한 또 다른 결과는 JVM에서 실행되는 언어가 많아졌다는 것이다. 예를 들어 Node.js가 서버 측 개체로 실행된 최초의 자바스크립트라고 생각한다면 오산이다. 모질라의 리노(Rhino)가 1999년부터 자바로, JVM에서 이미 시작했다(2006년 이후에는 오픈 소스 버전만).

이식된 언어 중 가장 눈에 띄면서 엔터프라이즈 개발자와의 연관성도 큰 언어는 파이썬과 루비다. JVM에서 자이썬과 J루비로 구현됐다. 다른 JVM 언어와 마찬가지로 JVM에 호스팅함으로써 파이썬과 루비는 방대한 자바 소프트웨어에 접근할 수 있게 된다. 이 관계는 두 가지 방식으로 작용한다. 즉, 자이썬을 사용하면 자바 애플리케이션 내에서 테스트를 위한 스크립팅 언어로 파이썬을 활용할 수 있다.

JVM에서 언어가 빠른 편이라고는 하지만 JVM으로 이식된 언어가 다른 버전에 비해 더 성능이 우수하다는 보장은 없다. 예를 들어 자이썬은 일반적인 C파이썬 구현에 비해 빠를 때도 있고 더 느릴 때도 있다. 워크로드의 성격에 따라 성능이 크게 좌우되기 때문이다. 마찬가지로 J루비 역시 원조 루비보다 빠를 때도 있고 그렇지 않을 때도 있다.

JVM 호스팅 언어의 또 다른 단점은 원조 언어의 최신 버전을 따라가는 데 다소 시차가 있다는 점이다. 예를 들어 자이썬은 파이썬의 2.x까지만 지원한다.

JVM의 다음 단계
성능은 둘째치고 이러한 언어들이 자바를 대체하게 될 가능성은 별로 없다. 그러나 애초에 자바를 대체하는 것이 목적은 아니었다. 이렇게 광범위하게 사용되고 성공적이며 유용한 자바를 대체해야 할 이유가 무엇인가?

그보다는 자바를 중심으로 생겨난 문화(모든 라이브러리와 애플리케이션)를 가져와 JVM을 통해 자바 개발자에게 더욱 유용한 개발 환경을 만들어주려는 것이 주된 목적이다.

향후 JVM은 미래 지향적인 언어를 위한 개발 환경으로 사용할 수 있도록 더 쉬워질 것이다. 오라클은 2014년 자바 API를 통해 JVM의 내부를 공개하는 프로젝트인 그랄(Graal) VM을 공개했다. 프로젝트가 성공적으로 끝나면 개발자는 자바를 일종의 지휘통제 언어로 사용해서 JVM을 위한 새로운 언어를 만들 수 있게 된다. (그랄로 호스팅되는 자바스크립트, 루비, R의 프로토타입은 아직 불안정하긴 하지만 기대감을 주기에 충분했다.)

예상하기 어려운 점은 자바 자체만큼 영향력 있고 광범위하게 사용되는 새로운 언어가 JVM 또는 그 후속 기술을 통해 탄생할지, 아니면 전혀 다른 방향에서 탄생할지다.

자바스크립트와 자바스크립트용 V8 엔진은 자바의 후계자로 유력한 후보다. Node.js는 이미 자바와 유사한 소프트웨어 재사용 문화를 정착시켰고, 자바스크립트로 트랜스파일(Transpile)되는 언어들은 자바스크립트를 작성할 필요 없이 이 생태계를 이용할 수 있게 해준다.

이처럼 자바가 대대적인 변화를 준비하는 가운데, JVM에서 사용할 수 있는 언어도 이제 태동기를 맞이한 것으로 보인다. editor@itworld.co.kr


X