에뮬레이션과 가상 머신

Wired Magazine이 예측했듯이, 애플이 인텔 프로세서를 채택하면서 기존 PowerPC 애플리케이션에 대한 해결책으로 제시한 Rosetta는 Transitive의 QuickTransit에 기반한 것으로 드러났다. 과연 QuickTransit이 기존의 다른 방식에 비해 얼마나 효율적인 에뮬레이션을 수행할 수 있을지는 물론 최종 제품을 봐야 알 수 있겠지만, 레지스터의 수가 더 적은 인텔 프로세서로 PowerPC를 에뮬레이션하기 위해서는 명령어를 1:1로 번역하는 방식으로는 실용적인 수준의 성능을 얻기 어려웠을 것이고 QuickTransit과 같이 블럭 단위로 코드를 변환하는 기술이 필요했을 것이다. news.com의 기사에서도 언급하고 있듯이, 새로운 에뮬레이션 기술이나 제품이 나올 때마다 네이티브에 근접하는 성능을 자랑하지만 실제와는 거리가 있었고 실용적으로 많이 쓰이기 보다는 최소한의 호환성 보장이나 고객들에게 “우리는 기존 애플리케이션을 지원한다"라고 생색내기 위한 목적이 더 컸던 것 같다. 하지만 에뮬레이션 기술이 단지 구 플랫폼의 애플리케이션과의 호환성을 지원하는 데에만 유용한 것은 아니다. 비록 상업적으로 실패했지만 Transmeta의 경우와 같이 새로운 아키텍쳐의 CPU를 가능하게 한 경우도 있고, Java의 경우와 같이 기존 플랫폼과의 호환성이 아닌 현재의 플랫폼간의 호환성을 얻기 위해 새로운 가상 머신을 이용하는 것도 에뮬레이션의 한 부류로 볼 수도 있다. 보다 더 흥미로운 경우는 .NET인데, 사실상 인텔이라는 하나의 플랫폼만을 지원하는 윈도우스에서 굳이 가상 머신을 사용하는 이유는 무엇이었을까? 마이크로소프트가 .NET에서 가상 머신을 사용하는 이유에 대해선 물론 여러가지 이유가 있겠지만, 내 생각에 가장 큰 이유는 기존 하드웨어 방식의 (real) CPU가 제공하는 기능이 인터넷 시대의 요구사항을 만족하지 못하기 때문이다. 굳이 거창하게 X Internet의 개념을 얘기하지 않더라도 ActiveX와 스파이웨어가 범람하는 현실을 볼 때 실제 CPU에서 제공하는 단순한 메모리 보호 기능이나 권한 관리 기능만 갖고는 다운로드받은 코드를 실행하는 것이 너무나도 위험하기 때문에 보다 정교한 실행 권한 제어를 위해서는 가상 머신을 사용할 수 밖에 없다. AJAX와 같이 스크립트를 이용하는 방법에는 한계가 있을 수 밖에 없기 때문에 Rich Internet을 위해선 Avalon/XAML과 같은 새로운 대안이 나올 수 밖에 없고 이를 위해선 가상 머신이 필수적인 것이다.