루비(ruby)

파이썬코딩 일주일째. 모든 것을 다 제공해주시던 레일즈느님의 손을 떠나보니 아쉬운게 한두개가 아니지만, 어쩐지 간만에 “코딩”이란걸 하는 느낌. 그동안 한 게 “조립”에 가까웠다면 말이죠. 귀찮은 일이 많긴하지만, 자바나 PHP에 비하겠습니까.

간만에 책꽂이에 박혀있던 녀석들을 이놈 저놈 꺼내서 공부했다. 오브젝티브씨 어쩐일인지 ObjectiveC(오오츠마코토/멘토르)가 눈에 쏙쏙들어왔다. 읽으면서 생각해보니, 얼마전까지만 해도 오브젝티브씨는 함수이름도 구질구질하게 길고, 쓸 수 있는 플랫폼도 아이폰이랑 맥뿐이라고 버려두었던게 바보같이 생각되었다. 책에는 C/C++과 공통되는 내용이 많이 나오지만, 오히려 그 점 때문에 더 잘 읽을 수 있었다. 새로운 언어 하나를 처음부터 정복하는 기분이랄까. 이제는 아이폰 프로그래밍 책들을 들춰봐도 그다지 어색한 느낌이 들지 않는다. 자바스크립트 얼마전 크락포드의 자바스크립트 핵심 가이드(Javascript: the Good Parts)를 본 다음에는 자바스크립트도 괜찮은 언어라고 생각하기로 했다.

삼성동 마이크로소프트 사무실에서 루비 사용자 모임이 있었슴. 사실 삼성동에 가도 코몰에서 밥먹거나, 전시회만 보고 왔을 뿐 그 너머에 가본 것이 꽤 오래된 듯. 그 동네에서 밤샘한거이 몇년인데… 집에서 코딩만하고 있으려니 날씨도 너무 좋고, 루비 개발자들이 뭐하고 지내는지, 다들 정말 잘쓰고있는지 궁금해서 가봤는데, 일단 재미있었고, 인사만 하고 말았지만, 꽃디앙님 얼굴도 봤다. 그런데, 개발자들하고 신나게 얘기하다가 나이를 물어보니… 띠동갑이었다. 사실 한국적 정서로는… 그냥 팀장님소리 듣고 사는게 더 정감가지 않을까. 잠시 고민했지만, 역시 보름씩 혼자 여행갈 수 있는 회사따위는 존재하지 않으니까.

루비 루비언어 자체는 “최소 놀람의 법칙” 덕분인지 그만의 색깔이 없는 것같다. 반면 파이썬은 누가봐도 ‘이건 파이썬이구나’라고 알아차릴 만큼 특징이 뚜렷한 언어였다. 최근에 들어오는 일감들은 무조건 루비온레일즈(ROR)로 진행하고 있다. 그루비를 쓸수있으면 좋겠지만 간단한 어플리케이션은 ROR로 만드는게 빠르다. 몇번 작업을 해보니 꽤 익숙해져서 간단한 넘은 정말 빠르게 만들수 있다. 헌데, 요 며칠 루비 참고서를 다시 들춰보면서, 내가 아직도 이런 종류의 언어들에서는 초보나 다름없다는 것을 깨달았다. 지금 진행중인 프로젝트에서도 루비의 yield를 쓰면 딱 좋은 상황이었는데, (그걸 쓰면 코드가 너무 간단해진다) 이상하게 코드가 길어졌다고 투덜대고 있었다.

루비라는 프로그래밍 언어를 사용해서 용역을 하고 있다. 이걸 쓰는 사람들이 국내에도 있다고 하고, 게다가 세미나도 한다고 해서.. 몸상태는 안좋았지만, 참석해보았다. 오랜만에 개발자들의 살아있는 목소리를 듣고 있으려니, 회색파티션 속에서 살아가던 기억이 떠올랐다. 흐뭇했다. 살짝 얼굴이 가려졌지만, 옆자리에는 레일스레시피랑, 애자일레일즈번역하신 “김석준님”이 앉으셨다. 유명한 분이다. 흐.. 전체적인 분위기는, 아직 개발자 수가 많지 않은 상태라서 “앞서가는 소수” 라는 공감대가 느껴지는 모임이었다. 플리커에 이날의 풍경이 올라와있다. 게다가, 스프링노트도 받고, 다음에서 주는 UCC 망치도 받고, 책도받고, 가방도 받았다.

파이선으로 시작한 한동안의 방황은 결국 다시 자바로 돌아왔다. 자바서버쪽에 Spring, Hibernate 따위 복잡한 도구들이 있는데, 아무리 잘 써볼라고 해도, XML 로 귀찮게 하거나, SQL 대신 HQL 을 들이밀거나 해서 안쓰고 있었다. Groovy and Grails 는 이런 복잡한 녀석들을 Groovy 라는 언어를 이용해서 간단하게 뛰어넘고 있다. Groovy는 상당히 유연한 언어인데, Groovy 가 없었다면, 당연히 Grails 도 없었을 것 같다. 국내에서는 Groovy 관련한 리소스가 별로없는데, 사실 세계적으로도 별로 없다. 다만, 자바기반이니까, 스크립트 언어니까, 이리저리 건드려보면 대강 돌아가게는 할 수 있었다.

그, 속도와 메모리의 엄청난 소비에도 불구하고, (루비라는 언어에 익숙해진다면) 저렇게 간단하게 코딩이 가능하다는 점. 대단하다. 하지만, 루비에 익숙해지기 전에는 저 검정상자에 쓰인 말들이 어색해보이겠지. 계속 흥미를 갖게 만드는 것은 RoR을 따라서 만들었다는 DJango를 들여다봐도, RoR만큼 간결해지지는 않는다는 점인데, MVC 에 맞춰서 이쁘게, 이쁘게 만들었던 내 작업도, RoR에 비하면 참 길었다는 기억을 더듬어 보면, 언어자체가 가진 장점이 아닐까. Duck Type 이라는.

아직 아니다. 루비가 느리기 때문이다. 동일한 기능을 하는 python cgi 보다 rails 가 더 느렸다. 게다가 메모리를 더 많이 먹었고, CPU 도 99% 먹는 것도 가능했다. 대단히 느리다. http request 한번에 CPU 18 % 를 기본적으로 차지하곤 한다. yarv 가 있다지만, debian 쪽에서는 experimental 이다. ubunto에는 없다. 버그 많을꺼라고 경고하는 녀석을 채택할 수 는 없다. dispatch.fcgi 가 좋다고 해서 써봤더니, 이번엔 이녀석이 cpu 를 먹는다. 또, 메모리도 차치해버린다. 이런. 문법이 좋긴 좋은데… 이만한 희생을 할만큼 좋은 걸까.

우리나라에도 루비를 쓰는 사람이 있을지 모르겠다. 어찌어찌하다가 발견한 건데, 꽤 자신에 찬 어투로 Ruby’s OO is carefully designed to be both complete and open for improvements. Example: Ruby has the ability to add methods to a class, or even to an instance during runtime. So, if needed, an instance of one class can behave differently from other instances of the same class 라고 주장하고 있다. “런타임에 클래스에 메쏘드를 추가하는 건 다른 누군가도 지원하고 있던 것 같은데, 클래스가 아니라 인스턴스에도 추가할 수 있고, 따라서 동일한 클래스라도 인스턴스에 따라서 다른 행동을 할수있다, 라… 면.