Catalyst vs Rubyonrails

Catalyst vs Ruby on Rails

By aero on July 3, 2009 10:30 PM | Permalink | Comments (1) | TrackBacks (0)

              


Ruby on Rails는 Perl, Python에 밀려  그렇게 주목받지 못하던 Ruby라는 언어를 화려한 주류언어의 무대로 끌어올린 대표적인 스타 웹프레임웍이다.

Perl하면 옛날의 CGI기반 게시판 등 고리타분 한 인식을 가진 사람들도 있겠지만 그건 호랑이 담배피던 시절 이야기고 현재에는 Perl에도 Ruby on Rails 못지않은 많은 MVC기반 웹 프레임웍들이 존재한다. 그중에서 제일 대표적인 것이 Catalyst인데 최근 Ruby on Rails와 Catalyst의 성능을 비교한 흥미로운 글이 있어 소개하려고 한다.

예전 2009년 4월 Victor Igumnov란 사람이 Catalyst vs Ruby on Rails의 성능을 비교한 글이 있었는데 그때 당시 결과는 Ruby on Rails 가 Catalyst 보다 약 62%정도 빨랐다. 그래서 인터프리터의 성능이 여타 언어보다 빠르다고 알려진 Perl이 비교적 느리다는 Ruby에서 구현된 웹프레임웍 보다 성능이 떨어지는데 의문을 품고 분석한 결과 Catalyst의 Controller구현에서 다중상속에서 메소드의 연속적 호출에 쓰이는 NEXT 모듈의 병목 때문에 성능이 떨어짐을 알아내고 Catalyst개발자에게 알려 이것을 새로운 C3 모듈로 교체하여 성능을 개선했는데

그 후 이런 개선사항이 반영된 새로운 Catalyst 5.8 버젼으로 다시 둘의 성능을 비교했더니 놀랍게도 Catalyst가 single process일때 Ruby on Rails 보다 135%, forking 된 multi process 환경에서는 471% 빨랐다고 한다.

Catalyst는 약간의 진입 장벽은 있지만 여타 프레임웍과는 다르게 ORM과 Template엔진을 필요에 따라 여러 가지로 교체해서 사용할 수 있어 개방적이고 확장성이 뛰어나다고 알려져 있다.

그런데 벤치마크결과에서 더 놀라운 것은 성능이 대폭적으로 향상된 Catalyst 5.8은 예전 5.7대 버젼에서는 OOP구현을 위해 Class::Accessor::Fast 라는 모듈을 사용한데 반해Moose 라는 Meta Object Protocol 기반의 진보된 OOP프레임웍으로 교체하였다는 것이다. Moose는 다소 번거로움이 많았던 Perl OOP구현을 어느 언어보다 편리하고 획기적이며 진보적인 방법으로 할 수 있도록 발전시킨 OOP프레임웍으로 다소 메모리를 좀 더 소비하고 속도가 떨어진다는 비판을 받았는데 Moose가 기반이 된 Catalyst 5.8의 성능이 이 정도로 나오는 걸 보면 그런 걱정은 기우에 지나지 않았나 생각된다.

Catalyst가 쓰이는 대표적인 서비스로는 일본 최대의 Social Network 싸이트인 mixi, 세계 최대규모 도색 동영상 싸이트 중 하나인 Youporn( Alexa 싸이트순위 44위 참고로 우리나라 최대 포털 naver는 60위권) 영국 BBC의 BBC News, BBC iplayer, Vox, Ticketmaster, Shopzilla, Takkle, Editgrid, IUseThis, MighTyV 등이 있다. ( Site running Catalyst )

Perl Catalyst 한 번 해보시지 않으시겠습니까?

참고: 또 다른 Catalyst vs Ruby on Rails 자료

Catalyst Framework 가이드 이상의 책 - The Definitive Guide to Catalyst

Kieren Diment and Matt S Trout, The Definitive Guide to Catalyst, Apress, 2009
Catalyst Framework 관련 책은 별로 없어서 그간은 2007년에 나온 "Catalyst: Accelerating Perl Web Application Development" 밖에 찾을 수가 없었다. 하지만 이미 2년 전에 출간된 책이라 그런지 군데군데 내용이 최신의 Catalyst Framework와 다른 점도 있어서 온라인에서 관련 문서를 찾아가면서 읽어야 했다. 그러다 새로 Catalyst Framework에 관한 책이 나왔다는 Amazon 추천에 낚여 이 책을 샀다. 결과는 아주 만족이다. 한마디로 평하자면 이 책은 Catalyst Framework 가이드 이상의 책이다.
Perl의 기초 문법과 사용법은 알고 있지만 실제로 어떻게 프로그래밍을 할지는 좀 막막할 때 이 책은 훌륭한 길잡이가 될 수 있을 것 같다. 이 책은 Catalyst Framework 설명서라지만 Perl로 어떻게 프로그래밍을 하는지 보여주는 책이기 때문이다.
나는 온라인 이곳저곳에 떠도는 문서로 대충 Perl을 사용하고 있다가 한번 제대로 공부해 보고자 마음을 먹고 최신 Perl의 내용을 충실히 담고 있는 입문서라는 "Beginning Perl"로 공부를 시작했다."Elements of Programming with Perl"과 "Intermediate Perl"을 거치면서 대략 문법과 기초적인 도구 사용법은 아는 정도가 아닌가 생각하고 있었다. 하지만 실제 Perl로 무언가를 하기는 여전히 어려웠는데 때마침 좋은 책을 만난 거 같다.
이 책은 CPAN 환경을 설정하고 모듈을 설치하는 데서부터 시작하여 Moose를 이용하여 객체 지향적인 코드를 짜는 법, perl의 각종 도구를 이용하여 코드를 생성하고 검증하는 법, 테스트를 만들고 실행하는 법 그리고 디버거로 프로그램을 디버그하는 등 Perl로 프로그래밍하는 여러 좋은 방법들을 보여 주고 있다. 간단한 기능을 구현하고 테스트로 검증하며 여기에 점점 기능을 붙여 나가면서 이를 적절히 모듈화하고 그때마다 테스트로 검사 및 확인하는 과정을 따라가며 고수가 프로그래밍하는 모습을 옆에서 바라보고 있는 느낌이다. 이 책을 공부하며 실제 업무에도 응용하여 몇 가지 프로그램도 만들 수 있었다. 한마디로 이 책을 공부하며 Perl로 프로그래밍하는 실력이 한 단계 상승한 느낌이다.
다만 아쉽게도 Catalyst Framework 자체에 대한 설명이 체계적이진 못한 느낌이다. Catalyst Framework 전반을 다루고 있긴 하지만 체계적으로 다루고 있진 않기 때문에 이곳저곳에 흩어져 있다. 온라인에 있는 Tutorial과 매뉴얼 등으로 보충하는 것이 좋을 듯 싶다.
웹프로그래밍을 해 본 사람이 Perl을 배우고 싶다면 이 책도 꼭 보는 게 좋을 듯싶다.

루비온레일즈

는 대부분의 시간을 같이 보낸 언어는 PHP, JAVA 입니다. 가장 익숙한건 아무래도 가장 오래하고 개발자층도 많은 JAVA 겠습니다.

이것은 나의 개인적인 선택이 아닌 돈을 받고 일을 하는 직업 프로그래머의 특성상 국내에서 가장 많이 쓰이는 일감이 많은 언어 순서대로 많이 할수 밖에 없었습니다.

PHP 는 언어의 초기 목표부터가 최대한 간단하며 누구나 쉽게 쓸수 있는 웹개발에 특화된 언어로써 지니는 특성으로 많은 장점과 동시에 많은 한계를 갖고 있었습니다. 지금은 물론 상당히 발전하고 OOP 적인 부분과 신기술이 도입되어 많이 다릅니다.

JSP 는 그런 PHP의 한계를 많이 매꿔주며 JAVA라는 강력한 프레임웍을 토대로 최신기술 트렌드를 주도해나가며 기업시장과 정부주도로 확장해나가게 되어 어쩔수 없이 PHP만 하다가 일거리가 바껴서 JSP 를 배워야 되기에 JAVA 또한 하게 되었습니다.

근데, 항상 일에 언어를 맞추고 나를 맞추게 되다보니 정작 내가 원하는 일과 언어를 사용하지 못하고 있는 내 자신을 볼수 있었습니다. 회사에서 작성하는 그런 팀단위로 이뤄진 웹개발언어의 코드라는건 시간이 갈수록 남의 코드와 같이 모르는 부분은 주석처리하고 다시 만들어 써넣기 반복되며 같은 이름의 클래스와 변수가 다르게 상속되거나 다른 의미로 사용되며 엄청나게 유지보수가 힘든 정말 절대 못푸는 실타래와 같이 암호화된 코드가 됩니다.

그러던중에 알게 된 새로운 언어들과 개발 프레임웍들이 Ruby / Ruby on Rails 와 Python / Django 그리고 Perl / Catalyst 였습니다.

처음에 Ruby on Rails 를 만들기 시작한 david heinemeier hansson 도 비슷한 대중성을 이유로 PHP로 만들어보려고 했다고 합니다. 하지만, 웹프레임웍을 만들려고 할려 한 2000년대초 당시엔 좀 언어로써 부족한 면이 많았습니다.

위에 얘기한거처럼, 사실 저는 Ruby on Rails 로 대규모 서비스 개발을 회사와 프로젝트에서 해본적이 없습니다. 해봐야 PHP나 JSP 서비스의 관리툴 정도로 저혼자 몰래(?) 만들어서 개발 서포트용도로 쓴 경우가 대부분이었습니다. 그리고 개인적으로 작은 필요에 의해서 만든 크롤러라던가, 재미로 간단히 만들어본 웹서비스 몇몇개 수준입니다.

근데 포스팅이 Ruby on Rails 로 대부분 채우게 되고 있습니다. 그건 제가 그만큼 Ruby on Rails 에 매력을 느끼고 최근 관심이 많다는 것이겠습니다. 그러면 왜 그럴까요? 그 이유를 설명하려고 포스팅을 하려 합니다.

Python 과 Perl 은 전에 가끔 간단한 시스템 관리용 복사, 백업같은 스크립트를 만드느라 써본 경험은 있었습니다. 하지만, 웹개발엔 전혀 써본적이 없어서 웹프레임웍이 있다는 사실조차 모르고 있었습니다. 그래서 하나씩 한번 어느것이 나에게 맞고 장단점이 있는지 몇년전부터 테스트하고 써보기 시작했습니다.

Python 은 아주 간결하고 규칙대로 해나가는 언어로 좋았습니다. 하지만, 그 탭을 맞추고 괄호로 이어지는 코드들은 좀 일단 쳐놓고 결과를 빨리 보고싶어하는 성격이 급한 나의 특성상 안맞았습니다.

Perl 은 보다 느슨한 규칙으로 빠른 코드를 쓰고 실행할수 있게 해주었지만, 그게 역시 단점으로 코드가 웹개발로 가면 여러가지 조건처리과 문자열처리로 엄청나게 난해해졌습니다.  물론 이건 제가 해당 언어에 미숙한 탓도 있습니다.

하지만, Ruby 는 이 둘을 절묘하게 섞어서 문법에서 자유와 깔끔한 코드를 만들어주었습니다. 정말 딱 필요한 글자만으로 코드를 내가 할만만 간단히 해서 적을수 있다는 느낌이었습니다. 그 언어적 특성에 기반하여 만들어낸 Rails 는 Ruby 의 특성을 최대한 살리면서 반복적인 작업을 정말 모두 자동화시키며 프로그래머는 뭘 만들어야되는지에만 집중하게 만들어주었습니다.

한때 몇년전에 Ruby on Rails 에 대한 요구가 우리나라에서도 번역된 서적이 출간되며 붐이 일뻔하다가 시장에서 수요에 대한 요구가 너무 없어서 다시 침체되었습니다. 하지만, 최근 Twitter 를 비롯하여 Groupon 같은 해외 글로벌 기업들의 개발 프레임웍으로 인정받으면서 다시 주목받을수 있지 않을까 생각합니다.

저는 국내 기업들과 개발자들이 어느 한 기술에 대해서 너무 얶매여 있지 말고, 다른 여러 시도를 해보는 것이 좋다고 생각합니다. 왜냐면, 저 또한 그런 편견을 깨지 않았다면 PHP 와 JSP만 해도 충분한 국내 개발 수요로 먹고 살며 다른 쪽은 보지도 않고 그냥 현실에 안주하며 새로운 세계를 보지 못했을거기에 말씀드립니다.

Rails 는 정말 어느정도 익숙해지면 경악할만한 개발속도와 차후 유지보수에 드는 노력 또한 엄청나게 절약해줍니다. 이게 정말 놀라운 것은 소프트웨어 개발이란 당연하게도 금방. 빨리. 만들면 코드가 정리안되고 엉망이라 계속적인 업데이트와 유지보수가 힘들어야되지만, Rails 는 그 코드 정리와 설계 과정을 대부분 자동화시켜 주고 필요한 부분에만 직접 써넣게 해주기에 왠만큼만 해놓아도 상당히 잘 정리된 설계가 나옵니다. 그리고, 당연하지만 OOP 를 완벽히 지원하는 스크립트 언어의 특성상 중복되는 코드도 최소화로 가져가며 클래스가 상속되는 구조로 갈수 있습니다.

물론, 단점도 있습니다. 기술적 내용이라 상세히 이 글에서 다 적지는 못하지만, 좀 느린 실행 속도와 최적화가 어렵다는 점입니다. JSP의 경우 JAVA 미들웨어도 교체하고 스케일아웃에 대한 이것저것 많은 상용 제품도 많고 JAVA 가 일단 기술 지원이 되니 해결책이 상당히 많습니다. PHP의 경우는 최적화를 하지 않아도 기본적으로 소규모사이트에선 언어 자체의 성능으로 충분하니 문제가 없습니다.

그러나, Rails 는 중간에 위치하기도 애매하고 아예 대규모 서비스로 가기도 퍼포먼스 측면에서 힘든 부분이 있습니다. 물론 제가 아직 그정도로 대규모 서비스 개발은 않해봐서 아직 모르는 부분이기도 합니다. 하지만,  Twitter 처럼 Back-end 부분은 분리해 나눠서 Rails 가 개발 효율성이 높은 Frond-end 부분을 맡고 아닌 부분은 타언어로 대체 합니다. 그래도 빠른 개발 속도와 유지보수가 쉬운 코드는 이런 단점을 모두 상쇄하고도 남는다고 저는 자신합니다.

마지막으로, 아마추어 프로그래머라면 어떤 언어로 무엇을 개발하든 사실 상관없습니다. 시간에 구애받지 않고 목표는 자신의 취미를 위해 하는 것이니까 말입니다. 하지만, 프로페셔널한 직업 프로그래머의 경우는 다릅니다. 자신의 최소한의 노동으로 최대한의 결과를 뽑아내는게 내 자신과 나를 고용한 회사 모두에게 이익입니다.

물론, 최대한의 노동으로 최대한 좋은 결과를 뽑아내면 좋겠지만, 그건 내 자신이 너무 힘든일입니다. 회사에서 맨날 야근할수도 없는 노릇이니, 누가 과연 그렇게 힘들게 살고 싶을까요? 프로그래머의 생활이란  회사에서 야근으로 중첩되고 지친 생활이 아니라 주어진 일을 빨리 끝내고 집에 가서 취미생활도 하는 것이 맞다고 생각합니다.

그런 시간의 여유를 가능하게 해주는 도우미? 친구? 도구가 Ruby on Rails 라고 생각합니다.

이것이 Rails 의 포인트이고 중요한거 같습니다.

반복적이고 컴퓨터가 할수 있는 일은 최대한 컴퓨터와 자동화된 도구에 맡기고 사람만이 할수 있는 일은 최소한으로 사람이 하도록 만드는 것.