Beyond Java; then, you will see the ruby.

Thinking in JAVA로 유명한 Bruce Eckel은 The departure of the hyper-enthusiasts에서 Ruby가 동적인 언어이므로 가지게 되는 단점인 성능의 저하를 비판하고, 또 다른 대안인 Python과의 비교가 더 중요한 요점이라고 지적했습니다. 사실 Ruby가 Python보다 더 낫다고는 말할 수 없을 것입니다. 사실 둘은 유사한 점이 무척 많죠. 하지만 Ruby가 유명세를 치르는 배경에는 RoR (Ruby on the Rails)가 있습니다. Better, Faster, Lighter Java를 써서 유명한 Bruce A. Tate의 최근작인 Beyond Java는 특히 Eckel 의 글에서 심도깊게 비판받았습니다. 가장 큰 문제는 – Beyond Java 책에서도 살짝 언급됩니다만 – Bruce A. Tate가 실제로 Java 의 중요한 테크놀로지중 하나인 EJB 를 많이 사용해 본 사람이 아니라는 점입니다. 실제로 그가 쓴 책인 Better, .. 는 EJB의 대안 기술인 Struts, Tapestry, Hibernate, Spring 등의 프레임워크에 중점을 두고 있죠.

하지만 웬걸 Eckel은 이후 열심히 루비를 공부하고 있습니다. 그의 최근 글인 Ruby, PHP and a Conference가 그 증거이죠.

Tate의 책에서 Java를 비판하는 가장 핵심적인 구절은 아마 다음 문단일 것입니다.

In fact, Java is moving away from its base. Remember, huge number of us are waiting for better, simpler ways to baby-sit a relational database with a web frontend. Instead, we’re seeing more XML, more configuration, more layers of abstraction, and a steady drift away from the user interface and the end user. Java takes longer to learn and is no longer approachable.

저도 나름 자바를 쓸 줄 안다고 생각하지만, 최근 Generics가 추가되면서 – 도대체 왜 그런 괴물을 추가한건지 모르겠습니다 – 자바의 API는 무척 복잡해졌습니다. 앞서의 포스팅인 More fun with generics에서도 드러나지만, 자바는 이제 절대로 쉽지 않은 언어가 되버렸습니다. 그리고 XML의 폭발적인 양의 증가는 저역시 불만인 사항이죠.

반면 Ruby가 추구하는 것은 다릅니다. 루비는 자바와는 정반대로 Orthogonality 를 무시합니다. 대신, HumaneInterface를 추구하죠. 즉, 하나의 일을 할 수 있는 방법을 여러개 만들고 그 여러 방법이 있음으로 인해 사용자의 프로그램 개발이 Principle of least surprise를 따르게 합니다.

특히 RoR이 가장 멋진 부분일텐데요. RoR의 창조자인 David Heinemeier Hansson은 RoR의 특징을 다음과 같이 설명합니다.

Ruby allows Rails to implement convention over configuration at runtime, which not only removes needless repetition but also relieves the programming cycle from being bogged down by compilation, code generation and deployment.

이처럼 무엇보다 Rails가 빛나는 이유는 (1) 설정 파일 대신 기존의 통습적인 관행을 직접 적용했다는 점, (2) DB 스키마에대한 UI 작성의 자동화(일종의 메타프로그래밍)입니다. 이 두가지 문제가 과연 루비만가능한 것인가에 대해서 저는 회의적입니다. 물론 루비이기 때문에 코드가 짧다라는 주장은 가능하긴 하지만, 코드가 짧으면 짧은 코드에서도 복잡한 생각을 표현하기 마련이기 때문이죠. (이 점에 대해서 반발하는 루비 유저분은 한번 언어를 처음 배우는 초보자에게 Enumerable#inject를 설명해보는 상황을 떠올려 보시면 동감하실 것입니다.) 또한 자바의 리플렉션이 비록 sucks 할지 몰라도 적어도 현재까지는 충분히 사용 가능한 기술인것은 사실입니다. 따라서 자바에서 Rails의 복사판이 나오지 말란 법은 없습니다. 적어도 제 짧지만 고통스러운 루비 코딩 경험으로 봐서는요.

Ruby가 또한 빛나는 이유는 쉬운 AJAX 개발이 가능하기 때문입니다. 하지만 자바에는 DWR이 있으며, JSF에도 역시 AJAX enabled 컴포넌트 들이 추가 될 것입니다. 또, Echo2도 있죠. 이것 뿐만이 아니죠. 최근에는 BEA, IBM, Oracle, Yahoo, Zend 등의 회사가 모여 The AJAX Toolkit Framework (ATF) Project가 이클립스에서 시작되었습니다. 하지만 본질적인 문제는 AJAX가 가능한가 그렇지 않은가는 아니라고 생각이 됩니다. 이 시점에서 돌아봐야 할 문제는, 과연 AJAX가 우리가 당면한 본래의 문제인 rich client 를 과연 제공하고 있는가를 되짚어봐야합니다. Java가 Applet 때문에 성공했음을 알고 있는 사람들은 자바 애플릿이 제공했던 UI들을 기억하고 있을 것입니다.

과연 AJAX가 만들어내는 UI가 자바 애플릿이 하려고 했던 그것과 Parallel 하게 될까요? 저는 기본적으로 AJAX가 만들어주는 UI는 불완전하기 쉬울 거라고 생각합니다. 물론 소프트웨어 보안이 소프트웨어 혁신에서의 주된 이슈는 아니지만 – 적어도 메이저는 아니란 말입니다 – AJAX는 수많은 웹환경에서의 취약점을 만들어낼 것입니다. 그러한 예로는 (1) XMLHttpRequest요청에 대한 인증 문제, (2) state의 클라이언트측 저장 및 서버로의 전송문제, (3) XML injection 등이 있습니다. 자세한 자료는 AJAX Security가 있습니다.

또다른 AJAX의 문제는 AJAX를 사용한 리치 클라이언트의 경험은 데스크탑에서의 사용자 경험과 반응 속도면에서 다르다는 것입니다. AJAX는 기본적으로 verbose한 XML을 사용하는데다가 꽤나 시간이 많이걸리는 XML로의 (de-)serialize가 필요합니다. 또, 모든 동작은 서버에서의 처리가 완료 된 후 클라이언트로 전달되어옵니다. 이로 인해 모든 AJAX 애플리케이션은 종국에는 데스크탑과 UI는 비슷한데 어쨌든 사용하기에는 너무 느린 환경이 될 가능성이 높습니다. 문제는 튜닝이 아니라, 데이터가 서버에 있고, 서버가 데이터를 조작한뒤 이것을 클라이언트로 전달한다는데 있습니다. 이 문제의 해결은 B. A. Tate가 지적했듯이 일종의 동적인 언어를 위한 런타임환경을 내장한 브라우저 – 결국 JVM이나 CLR이나 루비 인터프리터 – 가 등장하거나, 또는 – 제 생각이지만 – 데이터 push 기술이 없이는 불가능합니다. 결국 AJAX가 대안으로서 성공하는 것은 일시적입니다.

RoR을 밑으로 끌어내리고 나면 결국에는 언어의 문제가 남습니다. 과연 루비 언어가 제공하는 동적 특성이 프로그래밍을 얼마나 개선시킬까의 문제죠. 하지만 이 문제에 대답하기 전에 분명히 짚고 넘어가야 될 점은 있습니다. 루비의 마켓에서의 쉐어는 시스템 프로그래밍 – 루비 – 복잡한 엔터프라이즈 환경과 같은 소/중규모 개발환경이 될 거라는 점입니다. 그리고 주 목적은 relational database에 대한 presentation layer제공이 될 것입니다.

좀 더 serious 한 문제에 대하여 루비가 쓰일 것인가. 예를들어, BioPerl 의 parallel 도 있을까? 예 있습니다. BioRuby가 그것이죠. 하지만 이 개발환경은 어디까지나 spike solution 개발에 쓰일 가능성이 높습니다. 언어 자체의 느린 속도 때문이죠.

p.s. 노파심에 첨언합니다. 루비가 나쁘단 말이 아닙니다. 대부분의 웹 환경은 실제로 그렇게 초고난이도로 복잡한 트랜잭션이 필요한 것도 아닐뿐만 아니라, 스파이크 솔루션을 위한 스크립트 언어는 알아두는게 모르고 있는 것보단 낫죠. 앞에서도 이야기했지만, Eckel 마저도 ‘저 오늘 루비 모임에 갔는데, 가서 Mixin과 블럭에 대해서 배웠어요’라며 artima.com에 포스팅할 정도니까요. 저 역시 지금은 루비의 metaprogramming에 대해서 보고 있는데 상당히 인상적이군요. 자바나 .NET에서의 실행시간 코드 생성은 거의 쓰이지 않았는데 이 사람들은 너무나 자연스럽고 훌륭하게 쓰네요.

Similar Posts:

Comments 6

  1. kebie wrote:

    루비에 대해 관심이 약간 있어도 관련글들을 찾아보기가 쉽지 않았는데
    이 기회에 다시 한번 생각해 볼 수 있게 되었네요. 좋은 글 잘 읽었습니다.

    Posted 10 Feb 2006 at 1:51 am
  2. MKSeo wrote:

    감사합니다 ^^

    Posted 10 Feb 2006 at 3:29 am
  3. 옷장수 wrote:

    Mixin에 대해서 찾다가 들르게 되었습니다.
    개인적인 생각(경험이겠군요 ^^;;)으로는 Applet보다는 Ajax 쪽이 더 유리하지 않을까 생각이 드네요. 아무리 Applet으로 잘 만들어봤자 jvm을 먼저 설치해야한다는 점과 Memory문제 등을 고려하면 Ajax가 더 유리하지 않을까 생각이 드네요.
    너무 좋은 글 잘 읽었습니다. 좋은 주말 보내세요.

    Posted 06 May 2006 at 5:08 pm
  4. MKSeo wrote:

    애플릿기반의 오피스웨어인 http://www.thinkfree.com 써보셨는지요. 또 http://search.live.com 이나 http://shopping.live.com 써보셨는지.. live.com 의 소프트웨어들을 써보다보면, 이거 참 느리고 불편하다는 생각이 분명히 드실텐데요..

    풀어야하는 문제는 리치 클라이언트이고, 지금까지의 답안은 applet, ajax, .net의 세가지인데 이 세가지가 궁극적인 종착역은 아니라는 말입니다. 당연히 종착역은 아닌데, 그럼 무엇이 종착역일지는 저도 잘 ㅎㅎ

    Posted 06 May 2006 at 5:56 pm
  5. 짱가 wrote:

    너무나도 좋은 글을 우연히 발견하여 읽게 되어서 무척이나 행복하네요.
    감사합니다.

    Posted 08 Aug 2006 at 11:28 am
  6. MKSeo wrote:

    별말씀을. 감사합니다.

    Posted 09 Aug 2006 at 10:32 pm

Post a Comment

Your email is never published nor shared.