서로의 가치를 배가하는 VM 기술과 스크립트 언어

김도형 dynaxis@alticast.com 양방향 TV 솔루션 개발을 해 왔고 현재는 DMB를 위한 자바 규격 표준화와 제품 개발을 맡고 있다. JSR 242, JSR 272 등 방송 관련 JSR에 전문가로 참여했으며, 자바 외에 프로그래밍 언어 전반, XML 등 다양한 분야에 걸쳐 관심을 가지고 있다. 2007년 8월 21일

들어가면서

2005년에 우리말로 번역돼 인기를 끌었던 책으로 "조엘 온 소프트웨어"가 있다. 그 책 번역 당시 역자들과의 친분으로 베타리더로 활동할 기회를 얻었다. 불행히 다른 일로 바빠 글 하나만 리뷰하고는 기권했지만 말이다. 그 때 단 하나 리뷰한 글이 책에는 "언어 선택"이라고 번역된 글이다(블로그를 엮은 책이라 원문은 http://www.joelonsoftware.com/news/20020505.html에서 볼 수 있다).

짧지만 나름 읽어둘 만한 이 글 마지막에는 JVM과 달리 언어 선택의 자유를 기치로 내걸고 등장한 .NET CLR(Common Language Runtime)의 허상에 대한 언급이 있다. 대표 언어인 C#과 VB.NET만 보더라도 사소한 문법 차이 빼곤 사실상 똑같다고 꼬집으면서 별 차이 없이 단순히 많은 언어를 사용할 수 있다는 점은 프로그래머에게 특이한 이점을 주지 못한다는 점을 이야기하고 있다. 그도 그럴 것이 VB.NET 첫 버전은 C#에 있는 새로운 특징, 즉, .NET 런타임이 새로 들여온 특성과 라이브러리들을 버무리느라 비주얼 베이직 특유의 간결함과 호환성을 희생했고 수십 MB의 .NET 런타임의 무게만 짊어졌으니 말이다. 이런 마당에 더 이상 기존 비주얼 베이직을 판매하지 않으니 오죽하겠는가.

그렇다면 자바나 .NET CLR의 경우처럼 어차피 덩치 큰 런타임 시스템이 따라 다니는 환경에서 대표 언어인 자바와 C# 외에 다른 언어가 빛을 발하는 경우가 있다면 어떤 경우일까? 바로 스크립트 언어처럼 문법 자체에 편리함이 있고 별도의 컴파일이 필요 없는 빠른 개발을 지원하는 경우가 아닐까 한다. 이런 탓인지 최근 자바도, .NET CLR도 스크립트 언어 지원에 열을 올리고 있다. 자바의 경우 최근 JRuby 1.0이 나왔고 그루비(Groovy) 같은 언어도 매니아 층을 형성하며 승승장구하고 있다. 그뿐인가. 스크립트 언어처럼 동적 언어를 지원하기 쉽도록 특별한 명령어와 기타 지원을 JVM에 추가하려는 논의가 활발하다. .NET CLR에도 DLR(Dynamic Language Runtime)이라는 층을 추가해 벌써 파이썬(Python), 루비(Ruby)를 지원하기 시작했다. 앞으로 나올 VB.NET도 이 DLR 득을 보게 될 거란다.

사실 JVM이나 .NET CLR 같은 VM 기술과 스크립트 언어 사이에는 서로의 가치를 배가할 수 있는 많은 연결 고리가 있다. 이번 글에서는 자바와 C#이라는 대표 언어가 지배하고 있는 자바/.NET 환경에서 스크립트 언어가 어떤 이점을 줄 수 있으며, 기존 스크립트 언어 엔진과 달리 VM과 결합된 스크립트 언어가 어떤 이점을 가지는지를 살펴 보고자 한다. 솔직히 개인적으로는 특별한 경우를 제외하면 스크립트 언어를 별로 선호하지 않는 편이지만 VM 환경과 스크립트 언어의 결합은 양쪽 모두에게 득이고 특히 스크립트 언어에는 획기적인 저변 확대의 계기가 되지 않을까 감히 예상해 본다.

한 가지 양해를 구할 것은 이 글이 구체적인 예에서는 .NET보다는 자바에 치중한다는 점이다. 사실 .NET도 상당히 성숙된 환경이지만 아직 저변 확대 측면에서는 자바만 못한 것도 사실이고 또 무엇보다 필자가 .NET보다는 자바쪽에 경험이 많으니 어쩌겠는가(개인적으로 어느 환경에 대한 극단적 선호는 없다). 하지만 필수적인 부분에서 .NET 동향도 빠짐없이 언급할 것이며, 제목에서도 알 수 있듯 스크립트 언어와의 결합으로 득을 보는 것은 자바나 .NET이나 마찬가지다.

위로

스크립트 언어가 자바/.NET에 주는 것

여기서 굳이 스크립트 언어의 장단점을 일일이 언급할 필요는 없을 것이니 간략히 짚고 넘어가자. 개인적으로 파이썬으로 작성된 빌드 도구(make나 Ant의 대체품)를 고칠 일이 있어 코드를 분석하다가 두 손 두 발 다 든 경험이 있다. 원 작성자야 훤히 꿰고 있겠지만 제3자로서 특정 함수에 넘어온 객체의 타입이 뭔지를 알기 위해 함수 호출을 굽이굽이 따라 올라가야 했던 경험은 그다지 유쾌하지는 않았다. 사실 스크립트 언어는 여러 사람이 유지 보수하는 어느 이상 규모와 복잡도를 가진 시스템을 작성하는 데는 바람직하지 않다. 할 수 있다 하더라도 문서화 등의 부담으로 결국 스크립트 언어를 쓰는 이점을 잃을 가능성이 높다.

하지만 반대로 혼자 작업하거나 적당한 규모의 프로젝트를 진행하기에는 스크립트 언어만큼 신바람 나는 도구도 없다. 아이러니하게도 필자의 경우 앞서 언급한 빌드 도구가 입맛에 맞지 않아 같은 파이썬으로 내부 목적에 맞는 도구를 만들어 썼는데 자바 프로그래머들이 파이썬으로 작업하면서 겪은 애로점이라고는 통합 환경을 사용하지 않아 생기는 귀찮은 점 정도였고 단기간에 훌륭한 빌드 도구를 완성할 수 있었다.

이러한 스크립트 언어 사용의 명암은 자바나 .NET 환경에 들어오면 소위 말하는 정적 타입 언어인 자바나 C# 같은 언어와 서로 보완이 되어 찰떡궁합이 된다. 스크립트로 작성하기 적합한 부분은 스크립트로 작성하고 나머지 부분은 자바나 C#으로 작성하면 된다. 또 각 부분은 동일한 VM 위에서 동일한 표준 라이브러리를 매개로 작성되기 때문에 한 쪽에서 다른 한 쪽을 호출하는 것도 별도의 스크립트 엔진이 있는 경우보다 더 쉽다.

보통 스크립트 언어에서 자바 API를 호출하는 것은 다음에서 보듯 대부분 자연스럽게 지원한다. 다음은 JRuby에서 java.util.Random 클래스를 사용하는 예다.

  

require 'java' 
include_class 'java.util.Random' 
r = Random.new 
puts r.nextInt 

이번에는 자바만을 위한 스크립트 언어인 그루비의 예다.

  

import org.apache.commons.lang.WordUtils 
class Greeter extends Greet { 
  Greeter(who) { name = WordUtils.capitalize(who) } 
} 
new Greeter('world').salute() 

반대로 스크립트로 작성된 코드를 자바 쪽에서 호출해 쓰는 것은 반대 방향만큼 간편하지는 않지만 그래도 상당히 간편하다. 그루비의 경우 groovyc라는 컴파일러를 제공하기 때문에 아예 자바 클래스를 생성할 수도 있고, 그렇지 않으면 JSR 223처럼 스크립트 엔진에 대한 표준 인터페이스를 사용할 수도 있다. 그루비의 경우 자체적인 인터페이스를 제공하는데 대략 다음 방식으로 사용한다.

TestInterface.java 파일의 내용으로 자바 인터페이스를 정의한다.

  

public interface TestInterface { 
    public void printIt(); 
} 

Tester.groovy 파일의 내용으로 위 자바 인터페이스를 구현하는 클래스를 그루비로 구현한 것이다.

  

public class Tester implements TestInterface { 
    public void printIt() { 
        println "this is in the test class"; 
    } 
} 

위 두 파일의 존재 하에 스크립트를 호출하는 부분을 보면 다음과 같다. 특수한 클래스 로더를 이용해 스크립트 파일을 자바 클래스로 바꿔 읽어 자바 객체처럼 사용한다.

  

String fileName = "Tester.groovy"; 
GroovyClassLoader gcl = new GroovyClassLoader(); 
Class clazz = gcl.parseClass(new File(fileName)); 
Object aScript = clazz.newInstance(); 

TestInterface ifc = (TestInterface) aScript; 
ifc.printIt(); 

이러한 매끄러운 상호 작용은 자바뿐 아니라 .NET도 마찬가지다. 여하튼 이러한 매끄러운 상호 작용을 기본으로 최근 필자가 자바와 스크립트를 적절히 섞어 성공한 몇 가지 사례를 소개해 보겠다.

연산자 다중정의(Operator Overloading)

몇 달 전인가 미국에서 전자공학 박사 과정을 하는 선배가 자바에서 메서드 호출하는 방식 말고 복소수(complex number) 수식을 쉽게 표현하는 방법이 없는지를 물어왔다. 논문에 쓴 내용을 자바로 만들어 웹에서 쉽게 볼 수 있도록 프로그래밍을 하고 싶은데 a.plus(b) 형식으로 수식을 적어서는 그 선배가 사용하는 복잡한 수식을 표현하기가 너무 번거롭고 어렵다는 것이었다.

물론 자바에도 예전부터 다양한 전처리기(preprocessor)나 스크립트 언어 등이 시도되어 왔지만(http://www.robert-tolksdorf.de/vmlanguages.html 참조) 대체로 자바 자체의 진화에 발맞추지 못하고 지지부진한 것이 대부분이라 마땅한 것을 찾기가 어려웠다. 그래서 알려준 것이 그루비 같이 연산자 다중정의가 가능한 스크립트 언어다. 이를 사용해 수식이 들어간 부분을 작성하고 이를 그래프를 그리거나 하는 다른 부분에서 불러 쓰는 안을 제시했다.

분야에 특화된 언어로 사용(Domain Specific Language)

그루비나 다른 언어를 쓰다 보면 DSL(Domain Specific Language)이라는 이야기가 심심찮게 나온다(http://groovy.codehaus.org/Writing+Domain-Specific+Languages 참고). 개인적으로는 이 글을 쓰는 현재 작업하고 있는 시스템 내에서 일종의 컴포넌트들을 어떤 조건일 때 어떻게 조합하는지 규칙을 명시하기 위한 파일 형식이 필요했는데 이를 위해 XML을 쓸 수도 있고 별도의 언어를 정의해 파서를 만들 수도 있었다. 하지만 최종적으로는 그루비를 쓰는 쪽으로 방향을 틀었다.

스크립트 언어는 자바나 C# 같은 언어들에 비해 문법적으로 간결하고 다양한 표현법을 제공하기 때문에 이를 잘 조합해 사용하면 눈 앞의 문제를 읽기에 자연스런 형태로 표현할 수 있다. 연산자 다중정의나 함수 호출 때 괄호를 쓰지 않아도 된다거나 코드 블록을 함수에 넘길 수 있다든지 하는 독특한 특성들 때문이다. 물론 만능은 아니다. 하지만 어중간하게 사람이 읽기 힘든 XML을 쉽다고 세뇌시키거나 간단한 파일 형식이 필요한데도 파서를 만들지는 말자.

백문이 불여일견이라고 가장 대표적인 예로 루비의 Rake(make 같은 빌드 도구)나 그루비의 Gant(Ant 태스크를 활용하되 그루비 문법을 사용하는 빌드 도구) 같은 것을 들 수 있다. Make나 Ant 같은 빌드 도구의 빌드 파일이 별도의 문법을 쓰는 파일인데 비해 Rake나 Gant는 그 자체가 각기 루비 스크립트이고 그루비 스크립트다.

먼저 Gant를 사용하는 예제다.

  

includeTargets << gant.targets.Clean 
cleanPattern << [ '**/*~' , '**/*.bak' ] 
cleanDirectory << 'build' 

target ( 'default' : 'The default target.' ) { 
  println ( 'Default' ) 
  depends ( clean ) 
  Ant.echo ( message : 'A default message from Ant.' ) 
  otherStuff ( ) 
} 

target ( otherStuff : 'Other stuff' ) { 
  println ( 'OtherStuff' ) 
  Ant.echo ( message : 'Another message from Ant.' ) 
  clean ( ) 
} 

이번에는 Rake의 경우를 살펴 보자. 아래서 file이나 task는 함수다. 루비를 포함한 많은 스크립트 언어에서는 함수를 호출할 때 괄호를 안 써도 되는 경우가 많고 또 인자를 그냥 ‘,’로 구분해 열거하는 것 외에 인자 이름에 인자로 주어지는 값을 명시할 수도 있어서 아래처럼 ‘:default => [“hello”]’ 같은 표현이 가능해진다. 여기서 ‘:default’는 Symbol이라는 클래스의 객체로 ‘default’ 이름에 해당하는 일종의 상수라고 생각하면 된다.

  

require 'rake/clean' 

CLEAN.include('*.o') 
CLOBBER.include('hello') 

task :default => ["hello"] 

SRC = FileList['*.c'] 
OBJ = SRC.ext('o') 

rule '.o' => '.c' do |t| 
  sh "cc -c -o #{t.name} #{t.source}" 
end 

file "hello" => OBJ do 
  sh "cc -o hello #{OBJ}" 
end 

file 'main.o' => ['main.c', 'greet.h'] 
file 'greet.o' => ['greet.c'] 

기타

그 외 사례로 아파치 Velocity처럼 그루비를 이용해 템플릿 엔진 내에 스크립팅을 하거나 XML 문서를 처리해 필요한 부분을 추출하거나 하는 용도로 스크립트 언어를 편리하게 쓰고 있다. 보통 스크립트 언어들은 문자열 처리에 있어서는 발군의 능력을 발휘하고 일반 언어보다 읽기 쉽고 작성이 간결한 문법을 제공하는 것이 보통이다.

이 같이 성능보다는 간결한 코드가 중요하거나 사용자나 관리자가 뭔가를 명시해 고칠 필요가 있는 경우는 스크립트 언어를 도입하는 것이 많은 도움을 준다. 특히 VM 위에서 다른 언어로 작성한 코드와 쉽게 통합할 수 있다는 점은 별도의 스크립트 엔진을 사용하는 경우보다 빛이 나는 부분이다.

위로

VM이 스크립트 언어에 주는 것

이제 반대로 별도의 엔진이 아닌 VM 위에 스크립트 언어가 올라가서 스크립트 언어 측면에서 좋은 점은 무엇인가 생각해 보자. 우선 결론부터 정리해 보면 다음 정도가 아닐까 한다.

• 고성능/고품질 구현
• 풍부한 고품질 라이브러리
• 플랫폼 이식성

개인 의견이지만 이러한 특성으로 인해 앞으로 별도의 스크립트 엔진에 비해 오히려 VM 상의 스크립트 엔진 구현이 더 활발히 사용되는 날이 오지 않을까라는 생각도 해 본다. 그럼 왜 VM 상의 스크립트 언어가 원판보다 나을 수 있는지 하나하나 따져보자.

고성능/고품질 구현

사실 많은 비용을 들여 전업 프로그래머에 의해 개발되고 유지 보수되는 JVM이나 .NET CLR에 비해 스크립트 엔진의 성능이나 품질이 높아지기는 어렵다. 널리 사용되는 스크립트 엔진 중 다중 스레드 환경에 대한 대비가 잘 안 되어 있는 것도 적지 않으며, 인터프리터가 아니라 성능을 위해 기계어를 생성하는 JITC(Just-In-Time Compiler)를 갖추고 있는 엔진은 거의 없다. 스크립트 언어를 쓰는 커뮤니티에서야 언어를 순수하게 쓰는 쪽과 엔진을 만드는 쪽으로 나눠질 것이고 엔진을 만드는 쪽이 상대적으로 수가 적을 것은 명백하니 아무리 추종자가 넘치는 언어라도 엔진 구현과 발전은 그리 만만치만은 않을 것이다.

물론 성능 측면에 대해 이야기하면 요즘 컴퓨터 성능이 충분히 높아져 인터프리터 구현이면 충분하고 그래도 문제가 되면 성능에 장애가 되는 부분만 C/C++로 작성하면 된다고 하는 사람도 있을 것이다. 하지만 성능은 항상 중요하다. 어도비 플래시의 액션스크립트 엔진은 이미 JITC를 갖추고 있고, 주요 브라우저 내 자바스크립트 엔진도 성능 향상에 혈안이 되어 있다. 점차 스크립트로 하는 일이 많아지고 성능이 문제가 되고 있기 때문이다. PHP도 버전 4에서 젠드(Zend)라는 엔진을 도입하면서 성능 개선에 많은 무게를 두었고 버전 5로 가면서 지금도 그런 노력은 여전하다.

하지만 스크립트 언어는 일반적으로 매우 동적이다. 그 때문에 C/C++ 같은 정적 타입 언어에 비해 성능 면에서 효율적인 구현이 힘들다고 알려져 있다. 이런 사실을 두고도 굳이 VM 위의 스크립트 엔진이 고성능이 될 수 있다고 이야기하는 데는 과거에 VM 기술로 비슷한 문제를 해결해 온 전적이 있고, 결국 그 기술들이 오늘날 자바가 빨라지는 데 결정적인 계기를 제공했기 때문이다.

스몰토크(Smalltalk)라는 객체 지향 언어가 있다. 이 언어는 동적 타입을 가지고 기본 타입(primitive type)이라는 게 없이 숫자든 뭐든 모두 객체인 순수 객체 지향 언어다. 게다가 원래 환경에서는 스크립트 셸처럼 대화식으로 프로그래밍을 하는 환경이라 별도의 컴파일이라는 과정이 없다. 이런 이유로 고성능 스몰토크 구현은 상당히 도전적인 일이었다. 스몰토크는 VM 위에서 구동하는 것이 보통이었고 이 때문에 다양한 VM 기술이 개발되었다. 마찬가지로 스몰토크를 연구하던 사람 사이에서 더욱 동적인 언어로 셀프(Self)라는 언어도 개발되었는데 이 언어로 C에 가까운 성능을 얻기 위해 개발된 많은 기술이 현재 자바의 핫스팟(HotSpot) VM의 근간을 이루고 있다(http://www.cs.ucsb.edu/~urs/oocsb/papers/urs-thesis.html).

그럼 구체적으로 VM 위에서 스크립트 엔진이 구동될 때 어떤 장점이 있을까? 흔히 JVM 위에서는 자바만 사용한다고 인식되어 있지만 자바 초기부터 JVM 위에서 다른 언어를 구현하는 시도는 있어 왔다. 물론 자바에 제대로 된 JITC가 없던 시절, 인터프리터로 구동하는 언어로 베이식(BASIC) 같은 언어의 인터프리터를 구현하는 일이 멍청한 일로 치부되기도 했지만 요즘은 상황이 다르다. 우선 JVM 위의 많은 스크립트 엔진은 인터프리터가 아니라 동적으로 자바 바이트코드를 생성한다. 즉, JVM이 직접 처리하고 최적화할 수 있는 코드를 토해 놓는다는 말이다.

또 하나 특이한 점은 과거 스몰토크나 셀프 VM이 언어의 동적인 특성에도 불구하고 고성능을 얻으려고 노력했던 것과 달리 현재 JVM이나 .NET CLR은 자바나 C# 같은 정적 타입 언어에 최적화되어 있다. 하지만 최근에는 스크립트 언어의 중요성이 부각되면서 동적인 언어를 잘 지원하는 방향으로 JVM과 .NET CLR이 확장되고 있다는 점이다.

자바의 경우 invokedynamic이라는 JVM 명령을 추가하고 런타임에 클래스에 메서드를 추가하거나 제거하는 것을 지원하는 것을 고려하고 있다(http://www.artima.com/lejava/articles/dynamic_languages.html). invokedynamic의 경우 해당 객체의 타입을 몰라도 특정 이름의 메서드를 호출해 볼 수 있게 하고 만약 메서드가 없거나 하면 에러를 내는 대신 handleMethodInvocationError 같은 별도의 메서드를 불러주는 식으로 동작하게 될 것이다(초안이 궁금하면 http://java.sun.com/docs/books/vmspec/2nd-edition/Java5-Instructions2.pdf의 280쪽을 참고하라). 이렇게 함으로써 아무 객체에나 아무 메서드를 호출할 수 있는 스크립트 언어의 특성을 구현하기 위해 메서드 이름을 문자열로 받아 처리하는 껍데기 객체를 만든다든지 하는 번거로움이나 비효율이 사라진다. 또한 이러한 동적인 메서드 호출을 VM이 직접 처리함으로써 런타임 정보를 이용한 최적화를 하는 핫스팟 VM의 특성을 십분 살릴 수 있게 될 것이다. 그 밖에 통상 스크립트 언어들은 런타임에 메서드를 추가하거나 하는 일을 할 수 있는데 이에 대한 지원도 고려하고 있다.

.NET의 경우도 최근 MIX ‘07에서 실버라이트를 발표하면서 DLR이라는 .NET CLR의 추가 레이어를 발표했는데 동적인 코드 생성의 편의를 제공하거나 자바와 마찬가지로 동적 메서드 호출 등의 지원이 추가되었다. .NET의 경우는 자바에 비해 동적 언어의 구현이 더 용이해졌다. 상세한 것은 필자도 살펴 보는 중이다(http://blogs.msdn.com/hugunin/default.aspx).

결론적으로 VM 기술로 런타임에 얻을 수 있는 정보를 이용해 최적화를 하는 것이 스크립트 언어처럼 동적인 특성을 가진 언어를 가장 효율적으로 구현할 수 있는 방법이다. JVM과 .NET CLR은 자신이 사용하는 기술을 이제 본격적으로 원래 목적을 위해 사용하고자 하고 있는 셈이다.

풍부한 고품질의 라이브러리

사실 스크립트 언어들이 나름 풍부한 라이브러리를 가지고 있는 것은 사실이지만 표준 라이브러리부터 상당 부분이 성능 등의 이유로 해당 스크립트 언어로 작성되기보다는 C/C++ 등 다른 언어로 작성되고 있다. C/C++로 작성된 라이브러리는 해당 스크립트 언어 이식에 더욱 큰 짐을 지우고 양질의 라이브러리가 확산되는데 장애물이 된다.

개인적으로 프로젝트를 하면서 가능한 시간을 절약하고 코드 품질을 높이기 위해 오픈 소스 프로젝트에서 코드를 차용해 사용하려는 시도를 많이 하게 된다. 물론 주로 임베디드 쪽이라 환경마다 차이가 큰 탓도 있겠지만 C/C++ 코드를 받아다 성공적으로 사용해 본 것은 손에 꼽을 정도다. 반면에 자바 라이브러리는 아파치 등 다양한 소스에서 쓸만한 양질의 코드를 많이 확보해 큰 어려움 없이 통합해 쓰고 있다. 핫스팟 VM의 등장으로 이미 JVM 자체의 성능은 굳이 C/C++ 코드와 비슷하거나 경우에 따라서는 성능이 더 나은 경우도 있어 자바 라이브러리는 그 양이나 품질 면에서 스크립트 언어로 작성된 라이브러리에 비할 바가 아니다.

그리고 라이브러리 확보 측면에서 스크립트 언어가 아닌 다른 대안이 있다는 점을 잘 보여주는 다른 사례가 있다. 현재 3판까지 나와 있는 ECMA스크립트의 4판 작업이 진행 중인데 이 4판은 기존 ECMA스크립트와 달리 거의 자바 같은 정적 타입 언어에 가까운 특성이 대폭 추가되었고, 엄격한 타입 검사를 하는 별도 컴파일 모드가 있다. 물론 4판을 사용하더라도 현재와 같은 동적인 스크립트도 작성할 수 있는데, 이렇게 엄격한 타입 검사를 하는 언어 특성과 컴파일 모드를 추가한 데는 도조툴킷처럼 점차 스크립트 라이브러리의 규모와 복잡도가 높아지면서 때로는 동적이고 유연한 스크립트 언어의 특성을 희생하더라도 정적 타입을 가진 언어의 특성이 필요했기 때문이다. 모든 사람들이 동의하지는 않겠지만 풍부한 라이브러리 확보를 위해서는 스크립트 언어만으로는 부족하다.

플랫폼 이식성

유명한 스크립트 언어는 대체로 많은 운영체제에 이식되어 있다. 하지만 CPU/하드웨어, 운영체제의 발전 등 많은 변화에 신속하게 대처하기에 스크립트 엔진을 개발하는 개발자 커뮤니티가 충분히 여유가 있는지는 다시 생각해 볼 문제라고 생각한다. 이런 측면에서 스크립트 엔진이 VM 위에 안착하는 것은 스크립트 엔진을 개발하고 핵심 라이브러리를 확장하는 자원을 좀 더 가치 있는 쪽에 쓸 수 있도록 하는 장점이 있다고 생각한다.

위로

마치면서

소셜 북마크
	mar.gar.in
	Digg
	del.icio.us
	Slashdot

이러한 VM에서의 스크립트 언어 지원은 최소 과거 자바 상의 많은 전처리기나 인터프리터가 명멸했던 것과 달리 대세가 될 기미가 보인다. JRuby 제작자는 썬에 영입되어 지금은 썬 직원이다. 마이크로소프트는 DLR을 만들면서 직접 파이썬, 루비 등도 구현해 내고 있다.

지금까지 얌전히 자바나 C# 프로그래밍에 만족하고 살아 왔다면 VM 위에서 돌아가는 다양한 스크립트 언어에 한번 눈길을 줘 보자. 자신의 눈 앞에 있는 많은 문제를 스크립트 언어를 사용함으로써 더 쉽게 더 빨리 해결할 수 있을 것이다. 그뿐인가. 앞서 언급한 것처럼 VM 위에서 돌아가는 스크립트 엔진의 속도는 분명히 원판을 능가할 것이다. 이제 드디어 스크립트 언어를 하나씩 꿰어 찰 적절한 시간이 되었다.

위로

[지난 developerWorks Column 보기]