JVM, .NET CLR, 구글 안드로이드... 당신이 VM에 대해 알아야 하는 모든 것.... |
 |
 김도형 dynaxis@alticast.com
양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다.
2008년 2월 12일
|
|
|
|
이전부터 소문이 돌던 구글폰이 2007년에 드디어 그 실체를 드러냈다. 구글의 비즈니스 모델과 그에 따른 이동통신 시장 변화는 일찌감치 호사가들의 주된 관심이었지만, 엔지니어 입장에서는 휴대폰을 위한 소프트웨어 스택 전체를 일부 GPL 코드를 제외하곤 모두 아파치 버전 2 라이선스로 공개한다는 사실에 더욱 주목했다. 그러던 것이 2007년 11월 12일 안드로이드 SDK가 공개되면서 애플리케이션 개발에 자바를 사용하되 썬의 지적재산권을 우회했다는 사실이 알려져 또 한번 화제가 되었다. 그 핵심에는 오픈 소스 자바 SE 구현 프로젝트인 아파치 하모니, 그리고 JVM과는 사뭇 다른 형태의 Dalvik VM이 있다.
SDK 공개 후 안드로이드에 대한 관심이 약간 식은 듯한데 그도 그럴 것이 구체적인 단말 출시나 소스 코드 공개 일정 등 새로운 소식이 뜸하기 때문이 아닐까 한다. 2008년 말이나 첫 안드로이드 폰이 나올 예정이고 그 때까지는 전체 소스 코드 공개를 미룰 거라고만 알려져 있다. 풍문에는 델이 첫 안드로이드 폰의 주인공이라고도 하고 LG전자 등 국내 업체가 더 빠르지 않겠냐는 이야기도 들린다. 물론 우리나라에서 안드로이드 탑재 휴대폰을 볼 수 있을지는 더 미지수다.
하지만 자바 이후 많은 사람이 자바를 베꼈다고 생각하는 .NET CLR을 거쳐 또 다른 VM이 나왔으니 이쯤 되면 “가상 기계(virtual machine)”라고 하는 개념 자체에 대해 이전보다는 관심이 생기지 않았을까 한다. 그런 의미에서 이번에는 VM의 역사와 목적 등에 대해 한번 정리해 보겠다. 설명하겠지만 VM 개념은 꽤 역사가 길고 우리 생각보다 다양한 곳에 사용되었고 또 사용되고 있다.
VM이란 무엇인가?
문헌에 따라 다소 이견이 있을 수는 있겠지만 넓은 의미로는 하드웨어로 구현된 실제 컴퓨터나 개념적인 컴퓨터의 소프트웨어 구현을 말한다. 이 때문에 VMware 같은 가상화 솔루션이나, 예전 디지털 알파 프로세서 상의 윈도우 NT에서 x86 코드를 돌려주던 FX!32, 리누스 토발즈가 다녔던 회사로 유명한 트랜스메타(Transmeta)의 크루소(Crosoe) 프로세서의 코드 변환 소프트웨어(code morphing software)도 VM으로 분류한다.
이 글에서는 JVM이나 .NET CLR 같은 형태의 VM으로 주제를 제한하겠다. 위키백과에 따르면 이러한 VM을 프로세스 혹은 애플리케이션 VM이라고 한다. 하지만 다른 문헌에서는 프로세스 수준 가상화를 제공하는 VM을 프로세스 VM이라고 통칭하는 대신 JVM 같은 VM을 고급 언어 VM(high level language VM)으로 통칭하기도 한다. 이 글에서는 VM이라고 하면 애플리케이션 VM 내지 고급 언어 VM을 지칭하는 것으로 이해하기 바란다.
VM의 역사
흔히 VM하면 자바를 떠올리는 것이 일반적이겠지만 자바 이전에도 다양한 이유로 VM 기술이 사용되었다. VM의 역사를 제대로 논하려면 많은 문헌 조사가 필요한 터라 이 글에서는 VM 연대기를 정리하기보다는 잘 알려진 사례를 중심으로 살펴보겠다.
BCPL O-code
JVM의 시조를 따지면 꽤 과거로 올라간다. JVM이 1993년쯤 고안된 것에 비해 영국 캠브리지 대학교의 리차드 마틴(Richard Martin)이 1966년 설계한 BCPL 언어는 1967년에 이미 O-code(O는 object의 약자)라는 일종의 바이트코드를 토해 내도록 구현되었다. 여담이지만 BCPL은 B 언어를 거쳐 C 언어에 영향을 끼쳤다. 이렇게 생성된 O-code는 해석기(interpreter)로 실행하거나 기계어로 변환되어 실행되었으니, JVM이 경우에 따라서는 해석기로, 경우에 따라서는 JIT(Just-In-Time) 컴파일을 하는 것이 결코 새로운 아이디어는 아닌 셈이다.
O-code는 자바와 비슷한 스택 기계 형태였는데 한 가지 특기할 점은 BCPL에는 오직 정수(워드)형 밖에 없었고 임의의 정수를 포인터로 쓸 수 있었다는 점이다. 이런 점은 형 검사가 엄격한 JVM과는 다른 면모다. VM 사용으로 BCPL은 해석기만 이식하면 새로운 플랫폼에서도 쉽게 사용할 수 있었다.
BCPL의 O-code는 원래 컴파일러를 쉽게 포팅하도록 하기 위해 컴파일러 내에 정의된 인터페이스에서 시작되었다. 이같이 고급 언어 VM은 대부분 일반적인 컴파일러 내부에서 기계어나 어셈블리 코드를 토해 내기 전 어떤 부분에서 선을 긋고 그 선을 중심으로 한 인터페이스를 VM의 기계어로 정의한 것으로도 볼 수 있다. 다시 말해 기계어까지 생성하던 컴파일러의 뒷단 일부를 떼어내어 코드를 실행하는 쪽에 떠 넘긴 형태다.
BCPL에 대해서는 위키백과나 리차드 마틴의 홈페이지를 참고하기 바란다.
스노볼4(SNOBOL4)
스노볼은 1962년 벨 연구소에서 설계된 언어로 String-Oriented Symbolic Language의 약자다. 1967년 스노볼4라는 구현이 나왔는데 여기에 VM이 쓰인다. BCPL과 달리 데이터 형 개념이 있고 레지스터나 스택 없이 메모리에서 메모리로 데이터를 옮기는 형태의 명령을 가진 VM라는 점이 특이하다.
UCSD 파스칼 언어를 위한 p-code
O-code가 JVM의 시조격이 된다면 가장 잘 알려지고 실제 많이 사용된 조상은 1977년 UCSD(캘리포니아 주립대 샌디에고교) 파스칼(Pascal) 언어를 위해 설계된 p-code(p는 pseudo를 의미)다. UCSD 이전에도 몇몇 파스칼 컴파일러가 해석기를 위한 바이트코드를 생성했는데 그 중 가장 널리 쓰인 것이 UCSD 버전이다. UCSD 파스칼은 파스칼이란 언어가 널리 퍼지는 데 결정적인 공헌을 했고 결국 볼랜드의 터보파스칼을 거처 델파이로 이어지는 상업적인 성공까지 이끌어내는 초석이 되었다. UCSD의 p-code는 고슬링이 공공연히 자바 바이트코드에 직접적인 영향을 준 것으로 언급하고 있다. p-code는 자바와 마찬가지로 스택 기계이고 데이터 형이 없는 O-code와 달리 소스 언어인 파스칼의 영향을 받아 형 구분이 명확했기 때문이다. P-code 기계에 대해 상세히 알고 싶으면 다음 사이트(http://miller.emu.id.au/pmiller/ucsd-psystem-um/reconstruct/03-04-pseudo-machine.html)를 참고한다.
스몰토크(Smalltalk) VM
스몰토크는 한 때 애플의 펠로우(fellow)로 있었던 알란 케이(Alan C. Kay)가 1970년대에 설계한 언어로 1983년 VM과 함께 공개되었다. 스몰토크 VM은 스택 기계 형태로 객체 지향 언어를 위한 VM이라는 점에서 자바와 비슷하며, 스크립트 언어처럼 정적 형 검사를 하지 않는다는 점에서는 차이가 있다.
스몰토크는 작지만 열광적으로 스몰토크를 사용하는 공동체가 있다는 점에서 특이한데, 단순히 연구 목적으로 사용하는 것이 아니라 상용 시스템에 활용하는 경우도 많다. 이 때문에 일찍부터 다양한 형태의 스몰토크 구현이 나와 있고 동적인 스몰토크의 실행 속도를 높이기 위해 다양한 기술이 시도되었다.
오늘날 자바 핫스팟 VM이 탄생하기까지 필요한 동적인 기계어 생성이나 실행 시간 최적화 등의 개념은 모두 스몰토크 공동체에서 시작되었다고 해도 과언이 아니다. VisualWorks라는 스몰토크 구현은 이미 1980년 초에 현대적인 JIT 컴파일을 구현했고, 자바 핫스팟 VM은 다름아닌 Strongtalk라는 스몰토크를 구현하던 회사를 인수해 거기에 적용된 기술을 활용해 탄생한 것이다.
JVM
일반에 공개된 것은 1995년이지만 자바의 기본이 된 Oak 언어는 1990년 초에 이미 완성되었다고 한다. JVM이 최초인지는 확실하지 않으나 이전까지의 시도에 비해 특이한 점은 바로 데이터 흐름 분석(data flow analysis)과 데이터 형 개념을 활용해 실행 전에 바이트코드를 검증할 수 있게 한 점이 아닌가 한다. 여기에는 몇 가지 의미가 있는데, 우선 이전까지의 VM은 바이트코드가 잘못되어 C로 작성한 프로그램처럼 메모리를 망가뜨리거나 하는 경우에 대해 고려하지 않았지만 자바는 네트워크를 통해 움직이는 코드를 표방, 검증을 중심에 놓았다. 또 실행 전에 상당 부분의 검증을 행함으로써 실행시 성능을 깎아 먹는 안전 검사를 줄여 성능을 높이고 기계어로 변환하기 쉽도록 했다.
Inferno
Inferno는 1995년 벨 연구소에서 만들어진 운영체제다. VM 이야기하다가 갑자기 웬 OS라고 이야기할 수도 있겠지만 Inferno 자체가 다른 OS 위에서 실행될 수 있고, 그 안에 Dis라고 하는 VM을 가지고 있으니 자바와 비견할 만하다(이 이름들은 단테의 신곡에서 따온 것이다. 예를 들면 프로그래밍 언어는 Limbo다). 자바와 비슷한 시기에 공개되었고 오히려 완성도는 당시 자바에 비해 높아 관심을 끌었는데 여기 포함된 Dis VM은 자바나 그 이전 VM과 달리 스택 기계 형태가 아닌 메모리 주소를 피연산자로 가지는 RISC 명령과 비슷하다. 이 때문에 자바가 쓸만한 JIT 컴파일러가 나오기까지 꽤 걸렸던 것과 달리 처음부터 JIT 컴파일러를 통해 훌륭한 성능을 보여주었다. Inferno 소스는 현재 GPL로 공개되어 있다.
스크립트 언어 VM
자바스크립트, 펄(Perl)을 포함한 대부분 스크립트 언어는 소스를 파싱한 후에 트리 형태로 만들어 놓고 트리를 따라가면서 프로그램을 실행하는 구조였다. 이러던 것이 몇몇 스크립트를 중심으로 하부에 VM을 정의해 스크립트 실행 성능을 높이고 있고 널리 쓰이는 스크립트 대부분이 VM 기반으로 이행하고 있다.
* 자바스크립트의 경우 공식 구현이 하나만 있는 것은 아니지만 어도비가 모질라 재단에 공여한 AVM2(ActionScript VM 2)가 그런 예다. ECMA 표준 4판에 포함될 내용을 지원하기 위한 내용을 포함하다 보니 JVM과 상당히 비슷해졌고 스택 기계 형태에 내부적으로 JIT 컴파일러를 가지고 있다.
* 파이선(Python) 역시 스택 기계 형태의 VM을 가지고 있고 완전하지는 않지만 JIT 컴파일러 구현도 있다.
* 게임에서 많이 사용하는 Lua의 경우 RISC와 비슷하게 레지스터 개념을 도입한 VM을 사용하며 이런 형태 탓에 성능이 뛰어 나다는 점을 강조하고 있다.
* PHP는 Zend 엔진으로 넘어가면서 일찌감치 바이트코드 기반으로 넘어간 상태다.
* 그 외 루비의 YARV, 펄의 Parrot 같은 프로젝트도 진행 중으로 앞으로 스크립트 언어 구현에 VM이 사용되는 것을 흔히 보게 될 것으로 보인다.
안드로이드 Dalvik VM
안드로이드에 사용되는 Dalvik VM은 레지스터 기반으로 스택 기반의 자바와 형태는 다르지만 실제 명령은 자바와 거의 일대일로 대응되는 구조다. Lua의 예에서도 볼 수 있지만 레지스터 기반 VM은 컴파일러가 코드를 생성하기가 상대적으로 어렵고 명령어 자체도 해석기 형태로 구현하면 디코딩하는 부담이 있다. 하지만 구현하기 나름으로는 스택을 매개로 데이터를 주고 받아야 하는 경우보다 오히려 수행해야 할 명령어 수가 줄고 효율적인 구현이 가능하기도 하다. 사실 Dalvik은 기술적인 신규성이 있다기보다는 썬의 지적재산권을 우회하고 메모리 제약이 있는 임베디드 시스템에 더 적합한 구조를 선택한 결과라고 생각된다.
기타 주목할 만한 기술 동향
앞서 BCPL에 대해 이야기하면서 VM 개념은 컴파일러 구조와 밀접한 관계가 있다고 언급한 바 있다. 지금까지의 VM은 말 그대로 VM이라서 해석기 형태로 만들거나 마이크로코드 형태의 직접적인 하드웨어 구현이 어느 정도는 가능하다. 하지만 말 그대로 컴파일러 구조에 기반을 둔 기술들도 있다. 마이클 프란츠(Michael Franz)라는 캘리포니아 주립대 어바인교 교수의 연구 분야가 거기에 해당하는데, 트리 형태로 인코딩한 프로그램 코드를 실행단에서 검증하고 실행하거나 컴파일러 중간 코드로 사용하는 SSA(Static Single Assignment) 형태의 코드를 자바 바이트코드의 대안으로 제시한다(http://www.ics.uci.edu/~franz/). 최근 JVM이나 .NET CLR의 경우 기계어 생성이 당연해졌는데 이런 관점에서는 애당초 코드 검증과 기계어 생성에 최적화된 배포 형식을 만드는 편이 나을 수도 있지 않을까 한다.
VM을 사용하는 이유
앞서 VM을 사용하는 다양한 예를 살펴 봤다. 그렇다면 왜 VM을 사용하는지 그 효용에 대해 살펴 보자.
컴파일러를 쉽게 구현하고 이식하기 위해
초기 UCSD p-시스템의 경우는 말 그대로 컴파일러를 쉽게 이식하기 위해 VM을 도입했다. 특히 스택 기계 형태의 VM은 요즘 CPU 명령보다 코드를 생성하기가 쉽다. 하지만 이런 장점은 요즘처럼 고급 언어를 이용한 개발 등 개발 환경이 좋아진 상황에서는 그다지 의미가 없게 되었다. 심지어 Lua 같은 스크립트 언어는 굳이 코드 생성이 상대적으로 어려운 레지스터 기계 형태의 VM을 사용하기도 한다. 단, 스크립트 언어의 경우 JIT 컴파일 대신 해석기를 쓰는 것이 일반적인데 기계어 대비 성능 저하를 감수하면서 언어 이식성을 좋게 하는 예라고 볼 수 있겠다.
성능을 높이기 위해
스크립트 언어의 경우 소스 코드를 파싱한 트리를 해석해 가며 동작해서는 성능이 나지 않는다. 고수준 언어로 작성된 프로그램을 실행하려면 궁극적으로 기계어로 번역해야 하는데 많은 코드가 루프를 가지고 있고 라이브러리 형태로 사용되므로 한번 실행하고 끝나지 않는다. 따라서 소스 코드에서 기계어까지 가는 과정 중 반복되는 부분을 최대한 줄여야 만족할 만한 성능을 얻을 수 있다. 이 때문에 소스 코드를 기계어에 비교적 가까운 VM 코드로 바꿔 놓고 반복 사용하는 것이다.
성능을 높이는 용도로 VM을 사용하는 것은 여기서 그치지 않는데, 자바의 핫스팟 VM처럼 정적으로 소스 코드를 분석해서는 얻을 수 없는 정보를 실행시 수집한 다음 그 정보를 이용해 같은 VM 코드를 더 최적화된 기계어로 변환하는 방법을 사용할 수 있다. 특히 객체 지향 언어나 동적인 스크립트 언어는 이런 방법을 사용하지 않고는 성능을 개선하는 데 한계가 있다.
시스템에 입력되는 프로그램의 특성을 제어하기 위해
VM 코드를 어떻게 정의하느냐에 따라 자바처럼 프로그램 실행 전 혹은 실행 중에 코드를 검증하는 것이 가능하다. 극단적인 예를 들면 VM에 입출력을 위한 명령이 없으면 VM 상에서 돌아가는 프로그램은 입출력을 할 수 없다. 흔히 이런 특성은 자바에서 검증을 통해 자바 코드가 시스템을 깨먹지 못하도록 하는 것처럼 시스템 안정성이나 보안을 확보하는 방법으로 많이 사용된다. 예를 들면 최근 휴대폰에 사용되는 JVM은 하나의 메모리 공간에 여러 개의 자바 애플리케이션을 동시에 실행할 수 있는데 이것들이 서로에게 영향을 끼치지 못하는 것은 JVM에 C 언어 스타일의 포인터 연산이 없기 때문이다.
플랫폼 독립적인 프로그램 배포를 위해
최근 애플은 매킨토시의 CPU를 파워PC에서 인텔로 바꿔 버렸다. 비록 인텔 기반 맥에서 코드 변환 기능으로 파워PC 기반 소프트웨어를 실행할 수는 있다지만 무척 느리고 메모리를 많이 소모한다. 이런 경우 VM을 정의해 VM 기반으로 소프트웨어를 배포했다면 다시 CPU를 바꾸더라도 별 문제가 없을 것이다. 또 통상적인 기계어에 비해 많은 정보가 포함되어 있으므로 단순 기계어 간 변환보다 나은 성능을 기대할 수 있다.
이런 특성은 요즘 같은 인터넷 시대에 더 중요한데 분권적인 인터넷 환경에서 배포자가 실행될 환경을 가정할 수 없는 것이 현실이기 때문이다. 엑티브X가 난무하는 요즘 그 대안으로 어도비 플래시나 자바가 거론되는 것은 이러한 현실을 반영하는 좋은 예다.
하드웨어 별 특성을 활용하기 위해
VM을 사용하면 VM 상의 추상적인 연산을 특정 하드웨어에 포함된 기능을 이용해 더 빨리 수행할 수도 있다. 예를 들면 인텔 SSE2 같은 확장이 있는 플랫폼에서는 해당 명령어를 활용하도록 VM을 구현할 수 있다.
메모리를 절약하기 위해
마이크로소프트 비주얼베이직에는 p-code 엔진이라는 것이 들어가 있었는데 이 역시 스택 기계 형식의 VM이었다(http://www.programmersheaven.com/articles/userarticles/john/vbvm.htm). 마이크로소프트의 p-code는 크기가 작았는데 메모리가 모자라던 시절, 속도를 희생하고라도 프로그램 코드가 차지하는 메모리 공간을 줄이기 위한 선택 사항으로 추가되었다. 버전 5, 6 때는 p-code와 기계어 생성 부분을 혼용할 수 있어서 속도가 필요한 부분만 기계어로 컴파일할 수 있게 했다. 이처럼 VM 명령어는 작게 설계할 수 있으므로 메모리가 부족하거나 대역폭이 낮거나 비싼 통신 채널을 통해 프로그램을 전송할 때 유리하다.
구글은 정말 썬을 물 먹였는가?
다소 뜬금 없고 도발적인 소제목을 내세우게 됐다. 사실 이번 컬럼의 주제와는 직접적인 관계는 없지만 컬럼 자체를 안드로이드로 열었고 또 중요한 이슈니 간단히 언급하고자 한다. 안드로이드 SDK 공개 후 국내외를 막론하고 구글이 썬을 완전히 물 먹였다고 환호하는 분위기다.
물론 데스크톱 환경이나 서버 환경에서 공짜 자바 런타임과 공짜 서버를 사용하기만 했던 사람 입장에서는 썬에 대한 적대적인 여론이 의아할지도 모르겠다. 개인적으로도 이윤을 추구하는 회사로서 나름 자바에 많은 투자를 해 온 면을 생각하면 일방적인 매도는 무리가 있다고 생각한다.
하지만 열린 기술을 표방하고 이미 한 회사를 넘어 많은 지지자와 많은 회사에 의해 지탱되고 발전하는 자바가 특정 회사의 과도한 영향력 행사에 의해 발전이 저해되는 것은 문제가 있다고 생각한다.
당장 임베디드 시스템 분야만 해도 느린 JCP(Java Community Process)로 인해 필요한 API 제정이나 구성을 빨리 자유롭게 할 수 없어 기술/시장 변화에 민첩한 대응이 어려운 경우가 다반사고, 뭔가 알 수 없는 지적재산권에 대해 썬과 로열티 문제로 실랑이해야 하는 것이 엄연한 현실이다. 물론 기술 사용 대가에 대해서는 항상 비용을 지불하는 쪽과 받는 쪽이 이견이 있을 수 밖에 없지만 말이다. 자바 EE도 미들웨어 벤더 입장에서는 썬과의 관계에서 마찬가지 이슈가 있다.
만약 구글이 썬의 지배에서 자유로운 자바를 아무런 문제 없이 사용할 수 있게 되면 업계 표준으로 자리 잡은 표준 API가 당장 어떻게 되지는 않겠지만 중장기적으로는 JCP 체제와 썬의 감독을 벗어나는 변종이 우후죽순 생겨날 것은 명약관화다. 결국 안드로이드 자체가 문제라기보다는 그로 인해 썬의 자바 관련 사업이 직격타를 맞을 수 있다는 것이 문제의 핵심이다. 썬 입장에서는 좌시할 수만은 없는 상황이다. 풍문에 따르면 구글이 현재 접근법을 택하기 전에 썬과 협의를 했다는 이야기도 도니 지금도 막후에서는 어떤 일을 하고 있는지는 알 수 없다. 하지만 최소 썬이 제한된 사용 범위를 지정한 계약 관계에 의해 구글 안드로이드라는 예외를 인정하거나, 마이크로소프트와의 분쟁처럼(http://www.news.com/2100-1001-251401.html) 구글 혹은 안드로이드를 채용하는 단말 업체, 이동통신 사업자 등 하나를 희생양으로 전면적인 소송을 벌일 가능성도 여전히 배제할 수 없는 상황이다.
현재까지 알려진 사실로 봤을 때 구글이 썬의 지적재산권을 잘 피해나갔으리라는 확신을 할 수 없는 근거를 몇 가지 든다면 다음과 같다. 하지만 구글의 방법에 하자가 있다는 확증도 없다는 점도 강조해 둔다.
썬이 자바의 어떤 요소(JVM, API, 구현 방법 등)에 어떤 지적재산권을 가지고 있는지 알려진 바가 없다
이해가 안 가겠지만 업계에는 내가 어떤 특허에 대해 비용을 지불하는지 전체 내용을 모르는 상태에서 비용을 지불해야 하는 경우도 허다하다. 심지어 자바 ME 계약시에도 이러이러한 특허에 대해 사용권을 허여 받는다는 식이 아니라 썬 자바 구현 소스 코드와 그에 사용에 따른 제반 권리를 부여 받는 계약을 한다. 결국 썬이 뭘 가지고 있는지 알려주지 않는다. 자바에 대해 가지고 있는 것이 막 출원한 특허일 수도 있고 우리가 규격을 다운로드하면서 무심코 동의하는 계약서에 있는 제약일 수도 있다. 물론 구글이 뭔가 심층적인 검토는 했을 것으로 추정되지만 알 수는 없다.
최소 우리나라에서는 구글보다 더한 시도가 실패한 적이 있다.
우리나라 휴대폰 표준 플랫폼 규격인 위피(WIPI)의 설계 목표 중 하나는, 안드로이드와 마찬가지로, 자바 언어와 개발 환경을 쓰면서도 썬의 지적재산권을 침해하지 않는 독자적인 규격을 만드는 것이었다. 위피에서는 JVM을 쓰지 않고 서버 쪽에서 자바 바이트코드를 COD(Compile On Demand) 서버를 통해 기계어로 컴파일해 단말로 전송한다. 아예 VM을 사용하지 않는 구조니 구글과 비교할 바가 아니다. 심지어 API 면에서는 java.lang 일부 클래스 등 극히 일부만 사용하고 나머지 API는 전부 새로 설계했다.
개인적으로 위피 표준 제정에 관여하지는 못한 터라 혹시 놓친 부분이 있을지는 모르겠다. 하지만 구글보다 더 만전을 기했음에도 썬과 분쟁이 생겼고, 결국 위피 API와 기능이 중복되는 MIDP를 받아 들이고 말았다. 이 때문에 가끔 로열티 관련으로 잡음이 생기는 건 말할 필요도 없다(http://www.dt.co.kr/contents.htm?article_no=2007111602010351648002).
마지막으로 하나 더 언급하고 싶은 점이 있다. 어떤 블로그에 전반적인 사안을 냉철하게 분석하고 추후 소송 가능성까지 인정하면서도 약간은 비꼬는 투로 “VM 기술은 충분히 오래됐고 IBM 같은 회사는 태고부터 VM 기술(본문에서는 메인프레임 에뮬레이션이라고 표현했는데 앞서 언급했듯 이런 기술도 일종의 VM이다)을 개발해 왔는데 썬이 JVM 관련으로 무슨 지적재산권이 있느냐” 식의 관점을 피력해 놓은 것을 봤다(http://www.betaversion.org/~stefano/linotype/news/110/). 이 부분은 글쓴이 입장에서 가벼운 언급일 뿐 결코 심각하게 받아 들여서는 안 된다고 생각한다. VM이라는 범주에 드는 기술은 다양하므로 JVM이나 .NET CLR 같은 형태의 VM에는 다른 VM과 다른 특허가 걸려 있을 수도 있다. 실제 초기 JVM 규격에는 썬의 구현 특허에 대한 언급이 있었고 마이크로소프트가 출원한 바이트코드 검증(verification) 관련 특허는 검색해 보면 어렵지 않게 찾을 수 있다. 결국 썬이나 마이크로소프트의 특허 자체는 실체가 있고 우회할 방법을 찾을 필요는 있다.
맺으면서
구글의 안드로이드가 전혀 다른 형태의 VM을 도입한 것을 계기로 VM 개념이 왜 사용되어 왔고 또 우리 주위에서 VM 개념이 사용되는 곳을 살펴 보았다. 또 다소 긴 사족이 되었지만 안드로이드의 자바 사용에 대해 구글과 썬의 관계에 대해서도 나름대로 의견을 제시했다. 다소 부족한 내용이지만 자바, .NET CLR이나 스크립트 언어 등 VM 개념이 근간에 있는 기술을 더욱 깊게 이해하고 평가할 수 있으며, 추후 자신만의 문제에 부딪혔을 때 조금이나마 도움이 되길 바란다.
 [지난 developerWorks Column 보기]
|
