- 루비온레일즈가 앞으로 시간이 흘러 더 많은 개발자들이 활용하고 충분히 검증되기 전단계에서는 실무적용에 주의가 필요하다는 점을 말씀드리고 싶습니다. -
루비에 대한 환상을 가지고 접근하는 것은 매우 주의해야 할 것입니다. 실무에 적용하기 위해서는 미리 문제점을 파악하여 대처해야하며 책임문제까지 동반되므로 충분한 사전조사를 바탕으로 실무에 적용되어야 할 것입니다. 이 글은 기술자가 아니면 다소 이해하기 힘들 수도 있으니 양해바랍니다.^^; 저역시 처음에는 환상을 가지고 접근을 하였으나 환상이 깨어져 좀 안타깝습니다.
* '구현가능하다'와 '구현하기에 적합하다'는 의미가 다르다고 봅니다. 구현 할 수 있지만 불편하다면 '구현하기에 적합하지 않다'라고 이야기할 수 있습니다.
블로터닷넷에서 루비온레일즈(Ruby On Rails)를 처음 접하고 관련자료를 찾아보았습니다.
그리고, 현재 진행중인 중소형프로젝트(5천만원이하)에 적용해보고자 했고 책과 관련자료들을 구해 개발자에게 진행을 시켰습니다. 참고로 해당 개발자는 개발경력 10년의 베테랑 개발자입니다.
루비온레일즈는 'MVC 모델'을 기반으로 빠른 개발기간을 강점으로 내세우고 있습니다. '블로그 30분에 만들기' 동영상을 통해 개발자들에게 환상을 심어주기에 충분했습니다.
그리고, 처음 개발을 해보면서 개발자의 꿈(?)인 '신속한 개발'이 가능하다는 것을 충분히 느낄 수 있었습니다. 테이블을 생성하고, 래드레일즈(Radrails) 프로그램을 이용하여 모델을 만들고, 콘트롤러를 만들고 뷰(View)를 만들고 몇가지 수정해주니 금방 'CRUD(Create-Read-Update-Delete)'가 만들어졌습니다. 과거의 자동화(Automation)툴들과는 비교도 안될 만큼의 많은 기능을 보유하고 있다는 것을 알았습니다.
1. 모델기반에서 벗어날 경우 오히려 더 불편
그러나 우리는 진행해오던 프로젝트를 다시 php로 바꿀 것을 심각하게 고민하고 있습니다.
MVC기반이 루비온레일즈의 기본 아키텍쳐이다보니 '모델' 구조를 기본으로 전체적인 개발이 이뤄지며 그 구조하에서는 최상의 퍼포먼스가 나오지만 그 형태를 벗어나게 될 경우에는 매우 어렵다는 것입니다.
우리나라의 경우 외국에 비하여 화면도 복잡하고 디자인도 많이 들어가며 클라이언트의 요구도 까다로운 편이라 그러한 부분들을 모두 고려하였을 때도 과연 루비온레일즈의 퍼포먼스가 유지될 지는 의문이었습니다. 오히려 기본 흐름에서 벗어나는 것을 처리하기에 더욱 더 힘들어 지게 되는 현상이 발생합니다.
* 이미지 업로드기능을 구현하기 위하여 관련자료들을 찾아 보았으며 'AAA(Act As Attatchment)' 관련자료를 보았는데 DB의 BLOG필드에 데이터를 다 넣어버리더군요. 이를 파일로 저장하고 싶다면 Act As Attachment의 기능을 그냥 그대로 사용할 수 없었으며 php에서는 너무나 쉬운 업로드문제가 이곳에서는 머리가 아파오기 시작합니다.
2. 기존 개발 플랫폼이나 프레임워크에서도 개발 속도 향상 노력이 있다
자바든 PHP든, 닷넷(.NET)이든 자신의 전문분야가 있다면 그 개발분야에서 개발시간 단축등의 효율을 높이기 위한 여러 노력(개발패턴이나 라이브러리)들을 행하는 것이 더 효율적이라고 생각합니다. 그러한 노력들이 결실을 맺는다면, 기본패턴을 만드는데 가장 빠른 성능을 보이는 루비온레일즈에 굳이 의존할 필요가 없을 것 같습니다.
3. 로우레벨의 개발에서는 기존 개발 플랫폼이 월등하다
초보개발자라면 상관없지만 고급개발자로 발전하면서 로우레벨의 많은 기능들을 구현하는 노하우를 가지고 있습니다. 그러한 기능들은 오히려 오랜 기간 이용되어져 왔고 많은 개발자들이 있으며 이미 많은 활용사례와 라이브러리들이 있기 때문에 프로그래밍 언어나 플랫폼을 사용하는 것이 훨씬 유리하다고 생각됩니다.
프로젝트의 리스크는 기본형태를 만들면서 발생하는 것이 아니라 좀더 심화된 기능이나 특별한 요구사항들로 인해 발생합니다. 이러한 문제점을 해결하기 위해서는 좀 더 자유도가 있어야 하며, 좀 더 로우레벨의 프로그래밍이 가능해야합니다.
이러한 경우에 기존의 php나 자바등이 월등히 유리하다는 것이죠.
4. 퍼포먼스 문제는 심각하게 고민해야 합니다.
SQL문에 문제가 있어서 시스템이 느릴 경우에는 메모리를 늘리거나 CPU를 늘려도 해결되지 않는 경우가 많습니다. 인건비보다 시스템비용이 저렴하다고 해서 시스템에 대한 고려를 덜 해도 되는 것은 아닙니다. 시스템 안정성이 떨어져 방문객의 신뢰를 잃는다면 이는 개발자의 인건비보다 더 큰 손해일 수 밖에 없습니다.
웹서버가 느린 문제는 앞으로 점차 해결해 나갈 것이라고 보지만 자동화로 인해 SQL문의 튜닝이 필요하거나 하는 문제에서 세심한 조작에 적합하지 않습니다.
예를 들어 /log/development.log 파일을 보면 실제로 DB로 날아가는 쿼리들을 확인할 수 있습니다.
'select * from 테이블명'의 형태로 쿼리문이 날라갑니다. 하지만 리스트를 보여줄 경우 제목과 날짜, 작성자 정도의 정보만 있으면 된다고 했을 때 모두를 가져오는 것은 낭비가 될 것입니다.
최적화와 튜닝을 위해 세심하게 코드 수정이 가능해야 하는데 많은 기능들이 자동화되어 있다보니 그런 업무가 사실상 힘들다는 것이죠.
빠르다는 것도 중요하지만, 상용서비스에서는 좀더 세심한 개발이 필요한 경우가 대부분입니다.
5. 참고 자료가 부족하다
개발을 위한 각종자료가 아직 많이 부족합니다. 물론 이것은 점차 앞으로 좋아지겠지만 아직은 실무에서 발생하는 다양하고 골치아픈 문제점들을 해결하기 위해서는 너무 많은 시간과 노력이 들어갈 것입니다.
물론 우리나라에도 루비 관련 포럼이 있습니다. 하지만, 좀더 깊이 있는 내용들을 보기위해서는 구글에 가야하고 그 수많은 영문페이지들을 뒤져야지만 겨우 내용을 찾을 수 있는 경우도 많습니다.
온라인에서 제공하는 한글강좌의 경우는 아주 기초적인 수준에 머물러 있습니다. 앞으로 많이 늘어나기를 기대해 봅니다.
6. 웹 2.0기능의 강점?
루비온레일즈는 또 '웹2.0 개발'에 강점을 내세우고 있으나 아직은 웹2.0 기능들을 라이브러리화한 정도로 보입니다. 이는 다른 개발 언어 진영에서도 이 정도의 노력은 충분히 되어 있는 것 같습니다. 웹2.0이 루비온레일즈를 나타낸다기 보다는 웹2.0개발도 충분히 지원할 수 있다는 것으로 받아들여집니다.
하지만, 이 부분에서도 제공되는 범위를 벗어날 경우에는 오히려 더 힘들다는 점은 기억하실 필요가 있을것 같군요^^