개인적으로 99년부터 만남을 계속하고 있는 자눅스라는 모임이 있다.
다들 잘되서 IBM, MS, Sun, BEA, TMax, 일본, 중국, 싱가폴, 등등.. 여러곳에서 잘들 살고 있는듯하다.(뿌듯뿌듯)
어쨌든, Sun에 다니다가 MS로 옮긴 형이 최근 MS 개발자들 중에 ROR쪽으로 많이 전향하고 있다는
이야기를 들어(자바쪽에서는 어느정도 듣던 이야기지만 ... MS쪽까지?), 실태조사에 나서 봤다.
그리고 .. 자눅스 모임에 남겼던 글이다.
# 하루에 하나 글 쓰기 운동을 지켜야 되는데... 최근에 쓴글들은 오픈하지 않은 상태의 글들이
많기에 .. 이렇게라도 남긴다. ㅡㅡ;
====================================================================
형 글보고 휴일동안 간만에 ROR쪽을 돌려보았습니다.
예전에 Ruby에 푸욱 빠져있던 사람을 좀 알고 있었는데.. rails 초기에 자랑하기에 잠시해보고
에이~하면서 덮은 이후에 주위에서 떠들어도 그다지 거들떠 보지 않았는데.. XX형이
이야기하기에 다시한번 접해보았답니다. ^^
본론으로 들어가서...
그리고 바로 결론부터 제 생각을 말씀드리자면 현재의 ROR 수준은 단순 웹개발쪽에의 장점이외에는
고려해야 할 부분들이나 이슈들이 많아 보이고 ... 아직은 개인적으로는 그다지 끌리지가 않는다입니다.
J2EE하던 사람이 ROR 도입하고 만족해했다는 말에 대해서는 그 사람이 어떤 의미에서 J2EE를 여기에
갔다붙이려 하는지도 의심스럽습니다.
코팅양적으로나 속도차원에서의 장점도 있다고는 하지만, ROR를 접하면서 제가 가장 먼저 떠오른것은
예전의 velocity를 struts 기반으로 프레임워크 만들어서 섰던 지난날의 즐거웠으면서도 아품이 있었던
기억납니다.
ROR에서 rb를 작성하고 html에 간단한 테그나 로직을 짜는 부분은 velocity에서 마크로 기능을 이용하는
것보다 솔직히 더 파워플하다는 느낌은 받을 수 없습니다. (단순 텍스 기반의 개발 내용만 놓고 비교시..)
그 이외의 여러 기능들이 추가되고 있는 상황에서 그것들을 활용하는 차원에서는 ROR가 좀 더 낳다고는
하지만.. 그렇지 않은 부분에 있어서는....
지난 날 앞서 말씀드린 프레임워크가 실패했던 가장 큰 원인은 그리드 컴포넌트와 그래픽 API를
사용하면서 발생하였습니다. 상용그리드던 자바스크립트 기반의 그리드든 ... 이를 적용하기 위해서는
기존의 아무리 쉽게 생성하고 구조화 시킨 환경에서라도 기존의 뻘짓꺼리 코딩이 계속 뭍어만 갔습니다.
또한, 자바라는 녀석에서 .NET 기반의 그리드가 대세인 현실에서 .. velocity 기반에서는 더욱 T.T OTL
이였습니다. 이것은 그렇다치더라도 ... 통계테이터를 그래프로 뿌리기 위해 쉽게 사용할 수 있는
오픈소스차원의 것들이든 무엇이든 ... 순수 velocity 기반에서는 어림도 없었기에 결국엔 velocity + jsp
구로 갈 수 밖에 없었습니다.
속도와 코딩량에 있어서는 기존의 자바로 짤 수 있었던 어떠한 것보다 훌륭했음에도...
ROR에서 얼마나 많고 훌륭한 라이브러리나 API 또는 플러그인들이 제공되고 있는지는 파악해보지는
못했지만 아직 2년도 채되지 않는 기반에서는 이러한 확장성에 대한 것들에 있어서는 한계가 있어 보입니다.
그리고 eclipse 기반의 radrails로 테스트하기 위해 설치를 하는 과정에 의문점이 있어..
관련 자료를 찾아보았지만, 국.내외 어디에서도 자료를 찾기 힘들었습니다 그러면서 알수 있었던것이
아직 유저들이 많지 않음과 이에 따른 문제 발생시의 대처와 극복에 대해서는 인터넷의 힘을 크게
얻기 힘들 다는 생각 또한... 아직은 부정적인 생각을 만들었습니다.
끝으로.. 최근에 spring을 꾸준히 사용하면서 느끼는 부분은...
이러한 단위의 개발을 쉽게 하는 것보다 ... ROR에서 이야기하는 단순화 된 코딩과 소스의 량은 제가 보기엔
단순 기능차원의 껀껀의 내용으로 밖에는 안보여집니다.
프로세스가 있는 개발을 효과적으로 지원해줄 수 있는
프레임워크가 더 중요함을 새삼 느끼게 됩니다.
예로, 웹에서 엑셀 다운로드를 받는 단순한 기능을 예로들면..
이를 구현하기 위해서는.. jsp와 같은 페이지단에서의인코딩방식처리에서 부터 시작하여,
다운로드 이벤트 발생에 따른 DB에서의 데이터 쿼리 .. 이를 다시 엑셀로 변환하는 처리
를 거쳐 완성된 엑셀이 다시 다운로드 처리를 거쳐 다운로드되는 ...
기능적으로는 각각이지만, 이러한 프로세스적인(기능적 프로세스) 것을 설정레벨이나
로직 레벨에서 엮어 줄 수 있는 것들이 더욱 중요하게 느껴집니다.
이는 간단한 예였지만, 지금 KBS 방송관련 된 프로젝트는 데모형식으로 하고 있는데
유선(KT),무선,인터넷에서 받은 메시지를 MQ를 통하여 취합하고 이를 다시 DB에
저장하며 이를 다시 통계화하고 이를 방송을 위한 솔루션과 연계시키고.. 어쩌고..
하는 .. 차원에서의 예로 봤을 때는... 위의 ROR는 적용시키는 것이 가능하지 않을거 같습니다.
(ROR는 코딩을 쉽게 해줄 수는 있어도 Spring에서의 DI와 같은 개념은 포함되어 있지 않기에..
ROR가 웹기반이라 적절하지 않은 비유라 할 수도 있겠지만..... JSP 만으로도 위에 것들을
어느정도 생각할 수 있는 것과 다르게 어디서부터 해딩해야할지 막연하기에(공부를 안해서일지도)...)
이야기가 길어져 꼬이고 있으니.. 정리하면..
ROR는 현재의 수준에서는 단순 웹기반의 텍스트 기반의 개발에서는 어느정도의 강점이 있어보이지만
그 이외의 다양한 엔터프라이즈 환경까지 커버하기엔 다소 무리가 있어보이며,
더욱이 이를 해결하기 위한 과정과 노하우들에 대한 지식은 전세게적으로도 부족한 상황이기에
활용기술적인 차원보다는 미래에 속된 말로.. 뜰~ 기술로써 조금씩 적용시킬 수 있는 단계가 아닐까
란 개인적인 생각입니다...
다시 시간이나면 ... 확장성의 차원에서 어떠한 것들이 지원되는지는..
다시한번 확인해보고.. 글 남기겠습니다.
===========================================
요즘 벌짓꺼리하면서 노는게 많아, 언제 확인들어갈 수 있을지는 ... ... 이다. ^^
하루동안의 재미삼아 체크한 내용이라 깊이 있게 스터디하신 분들의 다른 의견이 있을 것이란 생각도든다.
* 혹시 제 사이트를 들려 글을 보시고 ... 다른 의견이 있으시다면.. 댓글 환영합니다. ~*
