8 ClojureScript 소개

ClojureScript는 Clojure의 자바스크립트 버전이다. Clojure라는 언어를 자바스크립트 엔진상에 그대로 구현해 놓은 것이다(dot NET 상에서 구현한 Clojure CLR이라는 언어도 있다). 그래서 먼저 Clojure를 익혀야 한다는 점이 부담이 될 수 있지만, 그 보상은 그 노력과 시간을 상쇄하고도 남으리라 생각한다.

Clojure가 자바 언어로 쓰여져 있지만, 자바와는 확연히 다른 언어이듯이, ClojureScript도 자바스크립트 언어로 컴파일되지만, 자바스크립트와는 상당히 다른 언어이다. 일단 모든 자료형이 immutable형이라는 점이 가장 큰 차이점이다.

요즘 자바스크립트가 대세로 뜨고 있기는 하만, 나는 개인적으로 자바스크립트를 좋은 언어로 평가하고 있지 않다. 내가 자바스크립트를 좋아하지 않는 첫 번째 이유는, 자바스크립트가 lexical scope language라고는 하지만, this 라는 키워드만큼은 dynamic scope로 작동해서, 프로그램 실행 중에 this의 binding이 프로그래머에 의해 마음대로 바뀔 수 있어, 프로그램의 로직을 파악하는데 상당한 어려움을 안겨주고 있기 때문이다. 어떤 사람은 this의 이러한 dynamic binding이, 자바스크립트 프로그래밍을 강력하게 해 주는 무기인 것처럼 포장하기도 하지만, goto문이 남발되는 언어가 프로그램의 이해를 어렵게 하는 것처럼, dynamic binding이 남발되면 프로그램에 대한 직관적인 이해를 방해하는 요소로 작용하기에 개소리에 지나지 않는다고 본다. 프로그램은 ’사람’이 짜는 것이다. 그래서 사람이 이해하기 쉬운 구조로 프로그래밍할 수 있도록 언어 자체가 설계되어 있어야 한다고 생각한다. 나는 this 자체가 나쁘다고는 생각하지는 않는다. 대부분의 객체 지향 언어가 이 this라는 개념 위에 설계되어 있으니, 자바스크립트만의 단점이라고 보기에는 어려운 면이 있기 때문이다. 내가 문제라고 생각하는 점은, 자바스크립트의 this가 가리키는 객체가 프로그램 실행 중에 바뀔 수 있다는 것(dynamic binding)이다. 그래서 이런 방식을 자바스크립트 언어 설계 초기부터 배제했었으면 좋았을 걸 하는 아쉬움이 있다.

물론, ClojureScript에서도 this를 포함해 Javascript의 모든 기능을 불러다 쓸 수는 있다. 그런 장치를 마련해 둔 이유는, ClojureScript에서 외부의 자바스크립트 라이브러리를 사용해야만 할 때, 어쩔 수 없이 자바스크립트의 기능을 이용해야만 하는 경우에 사용하라는 취지일 뿐이다. 그런데 ClojureScript로 프로그래밍할 때는, 이 this를 거의 사용하지 않는다. this의 주요 용도가 자바스크립트에서 객체 지향을 훙내내기 위한 것(멤버 변수에 대한 접근 용도)이어서, 상태(state)를 최대한 배제하고자 하는 함수형 언어에서는 사실 쓸 일이 별로 없다. 따라서 그만큼 프로그램의 로직 파악이 수월해진다. 게다가 서버를 Clojure로 프로그래밍하는 경우, 서버와의 통신이라든가, 서버와의 코드 공유가 가능해지는 등의 장점은, 다른 언어들에서 따라오기 힘든 강점이다. 이 글을 쓰다 보니 갑자기 "Catch me, if you can" 이라는 영화의 제목이 떠오른다.

그리고 자바스크립트로는 원래 멀티 쓰레딩이 불가능한데, ClojureScript의 경우는 core.async 라이브러리를 사용하면, 마치 멀티 쓰레딩을 구현하는 것과 같은 효과(go 언어의 go block과 개념이 같다)를 누릴 수도 있다.

한 마디로, ClojureScript는 자바스크립트의 Funcitional Version이자 Lisp Version이라고 보면 된다. 자바스크립트를 변용한 언어가 많이 나와 있지만, 함수형 언어의 특성과 리습의 매크로를 반영한 언어는 ClojureScript가 유일한 것으로 알고 있다. 함수형 언어의 가치와 리습 매크로의 위력을 실감하고 있는 프로그래머들에게는 이 한 마디에 귀가 번쩍 뜨일만한 강점들이다.

데스크탑 애플리케이션 개발의 경우에도, ClojureScript의 이용 가치는 높다. 이의 대표적인 사례가 LightTable이라는 프로그램이다. 이 프로그램은 ClojureScript + node.js(local resource 접근) + node-webkit(Rendering engine on Google Chromium)을 조합해서 만들었다. 이 프로그램은 데스크탑 애플리케이션이기는 하지만, 웹 브라우저를 자체 내장한 형태의 프로그램이므로, 쉽게 웹 프로그램으로 전환할 수 있다는 장점도 있다. 이런 점에서, 저는 Clojure보다는 ClojureScript의 가능성을 더 높이 보고 있다. Clojure의 경우에는, GUI 프로그래밍을 하고자 할 때, Java의 swing을 이용하는 것 이외에는 현실적인 대안이 존재하지 않고, swing이 과거에 비해 많이 빨라졌다고는 하지만, 기존에 제공되는 Componenet의 외관을 개발자가 원하는대로 바꾸기도 쉽지 않을 뿐만 아니라, 새로운 Component의 추가도 Java swing에 대한 상당한 지식을 요구하는 일이어서 결코 만만한 작업이 아니다. JRE를 별도로 깔아야 하는 것도 사용자의 입장에서는 번거로운 일일 수도 있다. 그에 반해 ClojureScript를 이용한 Web Programming의 경우에는, 웹 브라우저가 이미 제공하고 있는 GUI 요소에, CSS를 이용해 약간의 수정만 가하면, 개발자가 원하는 GUI(이 분야가 요즘 내가 관심을 갖고 개발을 시작하고자 하는 부분이기도 하다)를 비교적 쉽게 구현할 수 있다. 숟가락 하나만 얹으면 된다고 할 정도로 과거에 비해 많이 수월해진 것이다. 게다가 React에 기반한 Reagent 라이브러리를 이용하면 더더욱 쉬워딘다. Angular.js를 이용해 구현하는 것보다, 나의 주관적인 느낌이기는 하지만, 40-50배는 더 쉽다고 평가하고 있다. 이렇게까지 말할 수 있는 이유는 프로그램의 구조가 말할 수 없이 단순해지기 때문이다. 게다가 node.js를 적절히 이용하면 웹 애플리케이션을 데스크탑 애플리케이션으로 쉽게 전환도 가능하다.

아울러 ClojureScript 언어 개발을 주도하고 있는 David Nolen이 node.js에 대한 컴파일러 차원에서의 지원을 꾸준히 하고 있다는 점도, ClojureScript를 이용한 데스크탑 애플리케이션 제작의 가능성과 전망을 한층 높게 해 주고 있다.

특히 웹 프로그래밍할 때 Clojure와 ClojureScript의 조합은 가히 환상적이라 할 수 있다. 서버의 언어와 클라이언트의 언어가 같다는 것은 이루 헤아릴 수 없는 장점을 갖는다. 이런 장점을 기대하며, 어떤 이들은 Node.js를 이용해 서버와 클라이언트를 자바스크립트로 개발하려는 시도를 하고 있는데, 자바스크립트라는 언어가 프로그래밍의 복잡성을 늘려주면 늘려주었지 줄여준다고는 보지 않기에, 그다지 좋은 선택으로는 보이지 않는다.

특히, Clojure로 간단한 웹 서버 프로그램을 구축하는 데에는 30분도 채 걸리지 않는다. 기능을 추가하는 것도 단순히 함수 몇 개 추가하면 그것으로 끝이다. 복잡하게 클래스 설계힐 필요가 없다. 신혼 여행을 준비하며 레이스가 예쁘게 달린 단추 많이 달린 잠옷을 챙기고 있는 딸을 바라보던 엄마 왈, "얘야! 신랑이 단추 풀다가 밤 새겠다."는 우스개 소리가 있는데, 프로그램 짜라고 할 때, 클래스 getter/setter부터 열심히 만들고 있는 프로그래머들을 보면 저는 그 단추가 떠오른다.