사내 정보시스템용 Web Application을 위해 WAF를 survey했다.
결론적으로 TurboGears를 선택하게 되었다.
RubyOnRails아직 가장 인기있는 WAF는 ROR일 것이다.
15분만에 weblog 사이트를 만드는 screencast를 보고 감명받지 않을 프로그래머가 있을까?
Amazon에서 Ruby On Rails로 검색을 해보면 108권이 나온다. 오히려 우리나라에서 이제 겨우 관심을 주는 게 이상할 정도다.
그래서 가장 많이 사용하는 WAF라고 생각되는 ROR를 선택하였고, 간단하고 풍부한 기능에 어느정도 만족하였으나, Ruby라는 언어를 새로 익혀야 하는 부담이 있었다.
Ruby언어는 python이나 Perl을 알면 기본적인 문법을 배우는 시간이 많이 걸리지 않으나 usage에 익숙해지는 것은 또 다른 문제이고, 상대적이기는 하지만 아무래도
성능 문제가
부담이 되었다. 그리고 앞으로 나올
Ruby의 VM에 대한 전망도 그리 밝아 보이지 않았다. 그리고
Programming Ruby를 읽으면서, 언어의 동적 특성이 편해 보이기는 했지만, 전혀 성능상의 고려를 안한 것처럼 보였다. Ruby는 재미있고 좋은 언어이다. 하지만 Perl이 그랬던 것처럼 탄탄한 내부 구조를 갖지 않으면
전문적인 소프트웨어를 개발하는데 사용하기가 꺼려질 수 밖에 없다. RubyOnRails는 이러한 일반적인 인식을 뒤집어 엎은 소프트웨어다. 그리고 ROR에 붙은 가속도를 생각할 때, ROR 및 Ruby가 앞으로 어떻게 발전할지는 쉽게 예측할 수 없고 절대로 평가절하할 수 없다.
하지만 앞으로 일정기간 이상 유지보수되어야 하는 시스템을 내가 충분히 납득하지 못하는 언어로 개발하기에는 부담이 되었다.
Pylons그래서 찾아 본 WAF가 Pylons였다. Pylons는 Python으로 작성되었으며 ROR과 유사한 구조를 갖고 있다는 게 가장 마음에 들었다. 그리고 MVC를 구성하는 모듈들도 유연하게 바꿀 수 있었다. 가장 큰 문제는 아직 mature하지 않았다는 점이다. 문서도 절대적으로 부족하고 안되는 기능이 너무 많다. 특히 REST를 아직 제대로 지원하지 못하여서 사용 목적에는 맞지 않았다. Pylons 코드를 보고 Pylons 자체를 개발 하려는 것이 아니라면 아직은 많이 부족한 상태였다.
TurboGearsdjango 사이에서 약간 고민은 되었지만, TG가 훨씬 ROR에 가깝다는 점에서 TG를 선택했다. 그래도 TG에는 ROR과 비슷한
screencast들도 있고 어쩌면 ROR보다 더 전문적인 Catwork 및 admi18n 과 같은 도구들도 있다. 물론 ROR의 짧고 우아하게 보이는 코드에 비해서 많이 늘어져 보이는 것은 어쩔 수 없다.
