클로저 웹 개발 놀이
폴 그레이엄의 책, “해커와 화가”의 Lisp 언어 뽐뿌에 입문한 클로저 놀이에 코가 꿴 것 같다. 어색했던 수많은 괄호 쌍이 친근하고, 남의 클로저 코드를 보는 것도 즐겁고, 내가 작성하는 것도 재미있다. 내게도 궁극의 프로그래밍 언어로 자리 잡을지 모르겠지만, 적어도 당분간은 꽤 빠져들어 지낼 언어임은 분명하다.
호감 가는 클로저 환경
초보자로서 얘기하기 두렵지만, 남 눈치 덜 볼 만큼 뻔뻔해졌으니 마구 적어보자. 그리고, 이런 건 알면 알수록 고개를 숙이게 되기에, 잘 알고 나서 적으려 미루면 결국 그런 날이 오지 않더라.
남들 다 중요하게 여기는 대표적인 특징은 이미 “클로저에 빠져들기”에서 많이 적었으므로 구태여 더 설명하지 않기로 하고, 개인적으로 좋게 느낀 점 세 가지만 적어보면 다음과 같다.
- 매우 매우 간결하다, 어려울 정도로.
- 믿음직하다.
- DSL도 그저 Lisp 코드(S-expression)다.
하나씩 차례로 얘기해 보자.
매우 매우 간결하다, 어려울 정도로.
Lisp만큼 궁극의 간결함을 보이는 언어가 있을까? 이 정도가 사람이 읽고 이해할 수 있는 수준에서의 궁극인 것 같고, 이 수준을 지나치면 이해하고 전달하는 힘이 떨어져서 곤란하다.
간결한 코드가 좋은 점은 무언가? 내가 작성해야 할 코드가 짧은 것은 물론이고, 읽어야 할 남의 코드가 짧다는 의미도 된다. 개발하다 보면 결국, 사용하는 라이브러리의 문서만으로는 부족해서 내부 소스를 들여다봐야 할 때가 잦다.
성숙한 소프트웨어일수록 문서가 상세하고 다양한 상황에 대처할 수 있기에 내부 소스까지 봐야 할 일은 드물지만, 때때로 미숙한 소프트웨어를 써야 할 때도 있고, 또 어떨 때는 성숙한 소프트웨어를 쓰지만, 그 사용 환경이 특수해서 소스를 열어 봐야 할 때도 있다.
이럴 때, 장황한(verbose) 언어로 작성된 코드를 보려면 소스 파일 여러 개를 열어 여기저기 스크롤 해가며 메모해가며 추적해 분석해야 한다. 그러나 코드가 간결하면 소스 코드 한페이지 분량만 봐도 더 많은 내용을 파악할 수 있다. 살펴봐야 할 범위(scope)가 적은 것.
장황한 언어가 직관적이라고 말하는 사람도 있다. 하지만, 처음에는 조금 난해한 수준의 간결한 언어가 좋다고 생각한다. 중국집에 간 손님의 입장에는 “자장면 곱배기 한 그릇, 짬뽕 그냥 두 그릇 주세요”라고 주문하겠지만, 점원과 주방 사이에는 “짜곱, 짬둘”이라고 소통하는 것이 맞지 않겠는가? 그리고 다른 많은 분야에서 그러하듯, 처음에는 반직관적인 것이 결과적으로 옳은 것일 때도 잦다. 암튼, 개인적으로는 “간결한 언어가 결국엔 직관적이다”는 생각이다.
믿음직하다, 고퀄이다.
두 번째로, 언어 환경이 믿음직하다. 클로저로 개발하며 필요한 라이브러리를 가져다 쓰다 보면, 대부분 라이브러리가 꽤 잘 작성돼 있다는 점을 알게 된다. 작성자의 실력이 뛰어난 것. 진입장벽이 높은 언어의 특징일 수도 있다
Lisp 계열의 언어는 아마 앞으로도 대중적인 언어가 되지는 못할 거다. 결국 오래 개발하며 프로그래밍 언어에 관심을 가져온 해커들만이 Lisp 계열로 수렴하는 경향이 있어 보인다. 프로그래밍 언어의 깔때기가 Lisp에 꽂혀 있는 것이다. 물론 나 같은 기준 이하의 사람도 쓸데없는 호기심으로 뛰어들기도 하지만, 대세에는 차이가 없을 게다. 정리하자면, 아마 앞으로도 기준 실력 이상의 순도 높은 개발 능력자들이 활동하는 커뮤니티가 이어질 가능성이 크다 하겠다.
그런 믿음직한 커뮤니티의 특성상, 가져다 쓰는 라이브러리의 문제로 삽질할 시간이 대폭 줄어든다. 뭐가 잘못됐다면, 그냥 내가 작성한 코드가 잘못된 거다. 남 탓하지 말고 내 코드를 고치면 된다. (사실 어떤 개발 환경이든 내 잘못을 먼저 찾는 것이 바람직한 자세이긴 하다)
DSL도 Lisp표현식이다
마지막으로 DSL(Domain Specific Language)도 Lisp 코드로 표현된다는 장점을 적어 뒀는데, 무슨 얘기냐 하면, Lisp에서 사용하는 S-표현식(S-expression)이 그 어떤 DSL을 표현하기에도 적절하고, 매크로를 써서 그 표현식을 자유자재로 휘두르기도 좋아서, 여러 라이브러리나 프레임워크가 그저 S-exp를 DSL의 표현 언어로 사용한다는 점이다. 그래서 개발자 입장에서는 별도의 언어를 배울 필요 없이, 그저 Lisp 코드가 그 도메인을 위한 언어가 되므로, 단일 표현식으로 강력하고도 편리하게 개발할 수 있다는 거다. 가장 설명하기에 자신 없는 부분이니, HTML과 SQL을 쓰기 위한 라이브러리인 두 가지 라이브러리를 예로 들어보자.
HTML 표현을 위한 Hiccup
아마 Ruby의 HAML로부터 파생된 마크업 언어를 접해본 분이라면 눈에 익숙하게 들어올 텐데, HTML 태그와 속성과 포함된 요소들을 간략히 표현하는 형식이다.
예를 들어,
<div id=”section-1” class=”container”>안녕하세요!</div>
라는 HTML 표현을 위해서,
[:div {:id “section-1” :class “container”} “안녕하세요!”]
이렇게 클로저의 표준 자료형인 vector와 map으로 표현할 수 있다. 클로저 컴파일러가 구문 오류도 해결해주고, 중간중간 프로그래밍적 요소가 얼마든지 들어갈 수 있다. 그냥 클로저 코드이기 때문에, 별도의 언어를 익힐 필요조차 없다. 이 자체가 JavaScript에서 JSON처럼 클로저에서의 표준 데이터형으로 표현되므로, 그냥 프로그래밍하듯이 군데군데 마구 함수도 꽂고, 불러다 쓰고, 고차함수(HOF)도 넘기고 하며 자유롭게 쓰면 된다.
프론트엔드에서 HTML 코딩하는 업무와 백엔드 개발하는 업무가 잘 분리 된 환경이라면 아마 Enlive 같은 템플릿 언어가 최적의 선택일 것이고, 어차피 클로저 개발자가 HTML 출력까지 담당해야 한다면 hiccup같은 DSL(?)이 괜찮아 보인다.
SQL을 위한 Korma
루비온레일스의 ActiveRecord를 참 좋아라 쓰기는 했지만, 간혹 ORM을 힘겹게 쓰다 보면, 그런 생각이 들 때도 있다.
이럴 바에야 그냥 SQL을 잘 쓰는 게 훨씬 낫지 않나?
사실 ORM을 간단히 설명하자면, RDB 제조사마다 조금 다른 SQL을 중간 레이어에 껴서 표준화(?)해서 다뤄주는 역할과, SQL에서 활용하는 관계형 연산과 OOP 언어의 모습이 다른 데서 생기는 이질감(?)을 줄여주는 완충재 역할을 하는 것일 테다.
그런데 만약 OOP 언어를 쓰지 않는다면? Lisp 같은 함수형 프로그래밍(FP) 언어와 SQL의 근간인 Relational Algebra와는 잘은 몰라도 왠지 가까워 보인다. 따라서 굳이 Mapper가 필요 없을 수도 있다. 그렇다면 그냥 SQL을 잘 쓰는 게 그다지 어색하지 않다. 조금 친절하게 처리해준다면 RDB 제품에 따른 비표준을 커버해주는 수준으로 충분하다. 거기에 ActiveRecord나 JPA등에서 덧붙여 주는 관계 링크 기능까지 덧붙여 준다면 금상첨화! 그것이 바로 클로저 환경의 SQLKorma가 추구하는 바일 테다.
조금 전까지 갖고 논 korma로 개발하는 코드다. 초짜의 클로저 코드라 지저분하므로, 맨 아래에서 두 번째 줄의 코드만 떼서 보자.
(select signups (where {:email email :userid userid}))
분명 클로저 코드인데, 어렵지 않게 SQL로
SELECT * FROM signups WHERE email=“…” and userid = “…”
로 처리될 것임을 알 수 있다. SQL를 처리하기 위한 도메인 언어(DSL)인데, 그저 클로저 언어의 기본 함수와 매크로, 표현식을 사용한다. 모양새도 SQL과 별반 다르지 않다.
마무리
이상, 최근 클로저 놀이에 빠져 지내면서 느낀 장점을 적어보았다. 클로저로 얼마나 오래 즐겁게 지낼지, 그다음에는 어떤 프로그래밍 언어에 빠져들지 모르겠지만, (아마 Racket이나 Haskell?) 당분간 충분히 몰입해서 지낼 수 있을 것 같다. 아마도, 클로저가 프로그래밍 언어의 주류가 되는 일은 없겠지만, 함수형 프로그래밍이 주류가 되는 날은 머지않았으므로, 어떤 식으로든 개발자 삶에 도움이 클 것이라고 본다. (사실 주류, 대세, 인생에 도움, 이런 것은 잘 모르겠고, 놀이니까 재밌으면 된다.)
재밌습니다, 함께 해요~