루비ruby

한국루비개발자포럼 4회 세미나

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

RoR vs. GaG

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

루비의 간결함

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

Ruby on Rails

박제권
아직 아니다. 루비가 느리기 때문이다. 동일한 기능을 하는 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 라고 주장하고 있다. “런타임에 클래스에 메쏘드를 추가하는 건 다른 누군가도 지원하고 있던 것 같은데, 클래스가 아니라 인스턴스에도 추가할 수 있고, 따라서 동일한 클래스라도 인스턴스에 따라서 다른 행동을 할수있다, 라… 면.