Kenny's Java Programming

« The Elements of... | Main | JUnit 4 Class Diagra... »

토요일 1월 09, 2010

Groovy and Scala

Groovy vs. Scala - 차세대 자바 플랫폼 언어들#

한 언어의 생명을 어느 정도로 봐야 할까. 10년? 20년? 어떤 언어는 수 십년 동안 묻혀있다가 어느 날 슈퍼 스타처럼 나타나고 어떤 언어는 한 시대를 풍미했지만 알게 모르게 사라져간다. 물론 다행히도 자바 언어는 아직 왕성한 활동을 하는 현역이다. 자바는 어디서나 쓰이고 있고 API는 쏟아지고 있으며 새로운 신기술은 자바와 관련된 것이 많았다. 그러나, 최근에 변화의 조짐이 조금씩 보이기 시작한다. 자바 언어도 보완이 이루어지고 있지만 이제는 새로운 언어도 점차로 입지를 넓혀가고 있다. 어떤 것은 좀 더 생산성이 높고 어떤 것은 웹 애플리케이션 개발에 적하하고 어떤 것은 스크립트, 종류도 다양하다. 이러한 다양화는 자바 언어가 이제 정점을 지나고 있다는 것을 얘기해주고 있다. 물론 이것을 자바 플랫폼의 문제로 확대 해석하지는 말자. 자바 플랫폼의 핵심은 시스템 중립적인 자바 VM이고 자바 언어는 단지 자바 프로그램을 생성할 수 있는 언어의 한 종류일 뿐이다. 자바 VM에 관해서라면 현재 이슈가 되고 있는 것은 GC를 비롯한 성능일 것이다.

현재 차세대 언어가 어떤 모양새를 갖추어야 하는가에 대해서는 두 가지 종류의 방향이 있는 것 같다. 하나는 다이나믹 랭귀지로 Groovy, JRuby, Jython 등등이 해당된다. 다른 하나는 최근에 부상하고 있는 Actor Conccurrency를 지원하는 Scala이다. 이중 차세대 자바 플랫폼 언어의 대표 주자는 Groovy와 Scala이다.

두 언어 모두 말 많고 친절한 자바나 파스칼 계열과 달리 말 수가 적은 언어이다. 표현은 함축적이고 짧다. 따라서 설사 자바와 같은 개념으로 작성해도 작은 라인수, 작은 타이핑으로 좀 더 많은 기능을 구현할 수가 있다. 두 언어 모두 자바 언어로 작성한 것의 1/2, 1/3 면 같은 기능을 하는 코드를 작성할 수 있다고 보면 된다. 본인이 예전에 작성해본 다음의 예를 보자.

// Groovy Directory Listing Example
class ListDirectory {
	static void main(args) {
		def Dir = new File(args[0]);
		Dir.eachFileRecurse() { 
			if (it.isFile()) {
				println ">" + it.getPath();
			} else {
				println "  " + it.getPath();
			}
		}
	}
}

덧붙여 두 언어 모두 다 자바 바이트 코드로 컴파일되며 자바와 연동이 쉽다. 즉, 자바 라이브러리를 끌어다 쓰거나, 또는 자바에서 Groovy나 Scala 모듈을 호출하는 것 모두 가능하다. 이것은 새로운 언어의 이점을 취하면서 동시에 과거의 라이브러리를 활용할 수 있기에 대단한 강점이 된다. 언어를 바꿔도 버려야 할 것은 별로 없다는 뜻이다.

다음 간단한 예를 보자. Scala에서 System.out을 호출해서 사용하고 있다.

// Scala HelloWorld Example
object HelloWorld {
  def main(args: Array[String]): Unit = {
    System.out.println("Hello, Scala");
  }
}

문제가 될 수 있는 것은 Closure나 Functional Programming과 같이 기존 자바 시스템에 없는 개념들을 사용하는 경우이다. 자바 VM이 이를 지원하지 않기에 이 개념을 사용하기 위해서는 에뮬레이션을 하는 수 밖에 없다. 당연하지만 이런 에뮬레이션은 보다 많은 클래스 파일, 오버헤드, 메모리 CPU 낭비 등으로 이어진다. 이런 의문이 들 것이다. 과연 새로운 개념을 도입할 만큼 생산성이 좋아질까 하는 것이다.

다른 문제는 언어적인 복잡도와 새로운 개념에 익숙해져야 한다는 것. 처음 보면 무지 헷갈린다. 덧붙여서 자바와 함께 쓰는 경우가 많을 터이므로 어느 한 언어에만 치중할 수가 없는 점도 있다. 한국어로 얘기하다가 영어 단어 섞어쓰는 느낌 정도라면 괜찮을 것 같기도 하지만.

두 언어의 호불호를 가르는 것은 성숙도와 성능이다. Groovy는 다이나믹 타이핑을 지원하는 언어이고 Scala는 정적 타이핑을 한다. 이 때문에 Groovy는 실시간에 메소드나 함수를 호출하기 위한 오버헤드 때문에 성능 이슈가 있다. 1.6 버전에서 많이 개선 되었다고 하지만 성능 대신에 생산성을 택한 대표적인 예가 될 것이다. 반면에 Scala는 속도 문제에 있어서는 그런 이슈가 없으며 "Scalable Language"를 표방한 언어답게 멀티 스레딩을 통한 대용량 네트워크 서비스를 구현하는데 알맞다. 반면 꽤나 복잡해 보이는 언어이고 Immutable을 장려하는 것과 같은 범용성을 의심하게 하는 부분이 있다. 어쨌든 최근 twitter가 Scala로 이동하기로 했다는 뉴스[1]가 인터넷을 강타했던 것을 생각해보자. 이 언어의 가능성이 그만큼 높게 평가받고 있다는 증거이다.

언어적인 매력이나 성숙도는 역시 Groovy 편을 들 수 밖에 없다. Version 1.6, 다이나믹 랭귀지, 다양한 API, GRails 등등 활용할 여지가 많다. Scala는 꽤 역사가 되는 것 같지만 붐을 일으킨 것은 얼마 되지 않아서인지 API나 프레임워크가 Groovy처럼 다양하지 않다.

기본 비교#

구분	Groovy	Scala
특징	an agile dynamic language	OO and Functional Language
자바 API 상호 연동	가능	가능
Typing	Dynamic	Static
형 검사	RunTime	CompileTime (형 추론 매커니즘[2] 지원)
Performance	Low	High
현재 버전	v 1.6	2.7.3
대표적인 Web Framework	GRails	Lift

기타#

Web 프로그래밍에 대해서는 Groovy - Grails, Scala - Lift 이다. Grails는 RoR 개념이므로 좀 더 레벨이 높아 보인다. 레퍼런스도 풍부.
두 언어 공히 설계는 기존 CBD 방식으로 하면 되는 것일까?
엔터프라이즈 레벨에 이르면 Groovy나 Scala가 생성하는 저 많은 부가 클래스들이 어떤 영향을 미칠까?
Type Inference 글들을 보면 공동 작업을 할 때는 정적인 형검사가 유리해 보인다.
실시간 형검사만큼 편리하지는 않지만 Scala의 형 추론 매커니즘이 귀찮니즘을 많이 해소.