＇루비온레일즈＇ 기업시장 진입 ＂글쎄…＂
2007. 05. 07 테크놀로지 |
- 루비온레일즈가 앞으로 시간이 흘러 더 많은 개발자들이 활용하고 충분히 검증되기 전단계에서는 실무적용에 주의가 필요하다는 점을 말씀드리고 싶습니다. -
루비에 대한 환상을 가지고 접근하는 것은 매우 주의해야 할 것입니다. 실무에 적용하기 위해서는 미리 문제점을 파악하여 대처해야하며 책임문제까지 동반되므로 충분한 사전조사를 바탕으로 실무에 적용되어야 할 것입니다. 이 글은 기술자가 아니면 다소 이해하기 힘들 수도 있으니 양해바랍니다.^^; 저역시 처음에는 환상을 가지고 접근을 하였으나 환상이 깨어져 좀 안타깝습니다.
* ‘구현가능하다’와 ‘구현하기에 적합하다’는 의미가 다르다고 봅니다. 구현 할 수 있지만 불편하다면 ‘구현하기에 적합하지 않다’라고 이야기할 수 있습니다.
블로터닷넷에서 루비온레일즈(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개발도 충분히 지원할 수 있다는 것으로 받아들여집니다.
하지만, 이 부분에서도 제공되는 범위를 벗어날 경우에는 오히려 더 힘들다는 점은 기억하실 필요가 있을것 같군요^^
2007-05-08 at 10:05 오전
동감입니다. 씽크프리에서도 다양한 파트에서 기술검토를 했었는데 현재 수준에서 간단한 테이블에 단순한 서비스는 문제가 없으나 복잡한 비지니스 로직을 처리하는 것은 현재 수준에서 적합하지 않다는 판단을 내렸습니다.
2007-05-08 at 4:49 오후
1. 모델기반에서 벗어날 경우 오히려 더 불편
현재 우리나라에서 루비온레일스를 사용하려고 할 때 겪게 되는 문제 중 하나임에는 틀림 없다.
그러나 모델링 자체에 대한 개념을 다른 시각에서 바라보고 하지 않는 문제도 개발자에게 있지
않나 싶다. 특히 테이블에서 PK/FK 키 문제가 여기서 대두되는 것인데 루비온레일스 개발자가 그것도 모르고
이러한 프레임워크를 만들어 오픈했을 거라 생각한다면 우리 꼴이 우습지 않을까 생각이 든다.
* 업로드 기능에서 파일 저장도 가능함
2. 기존 개발 플랫폼이나 프레임워크에서도 개발 속도 향상 노력이 있다
기본패턴에만 루비온레일스가 강하다는 것이 단점으로 보이는 것에는 동의하지 않음.
3. 로우레벨의 개발에서는 기존 개발 플랫폼이 월등하다
로우레벨의 개발에는 기존 플랫폼이 강하다. 이것이 무슨 말인지 모르겠다.
여기서 기존의 php 에는 어떤 로우레벨이 있는지 예를 들어 보여주기 바람. 그리고
월등히 유리하다는 것을 어떤 기준에 근거하여 설명하였는지 모르겠음.
4. 퍼포먼스 문제는 심각하게 고민해야 합니다.
루비온레일스에서의 SQL 쿼리시 튜닝 문제가 나왔는데 문서를 좀 더 보시면 알것임.
5. 참고 자료가 부족하다
참고 자료가 부족하다는 데에는 이의는 없으나 현재 상반기에 여러가지의 관련서적이
나와 있어 기본지식을 습득하는 데에는 별 문제가 없음. 그리고
JSP 나 ASP.NET, PHP 처럼 우리나라에 소개된지 수년이 지난 언어임에 비추어 보면
앞으로 더 좋은 서적과 관련 자료들이 인터넷에 많이 올라올 것임.
6. 웹 2.0기능의 강점?
웹 2.0 기능에 대한 부분중 제공되는 범위를 벗어날 경우라는 것이 어떤것인지 명확치 않아
이해할 수 없음. 이해할 수 있는 내용좀 부탁드림.
2007-05-09 at 2:07 오전
글 잘읽었습니다
한마디 하겠습니다.
왜 이글을 보면서 10년전 자바로 개발을 한다고 하면 미쳤네바보네 하며 무시했던 사람들이 생각이 나는 걸까요?
지금 자바로 개발한다고 하면 그렇게 이야기 할까요?
언어와 환경은 끊임없이 진화합니다. 지금 시작하는 단계에 있는 환경을
비난한다는 것은 개발자의 생각이 아직 미진하거나 정말 로 못쓸언어나 환경일 때 뿐이지요
정말 해당 개발자가 경력이 10년차 이신지…궁금합니다..
루비온레일스 10년차 경력이라면 베테랑이라고 해도 좋습니다만 도대체 무슨 개발자이신가요?
제가 볼때 이글의 내용은 기술적인 부분을 떠나서 개발자의 안이한 생각를 보여주고
있다고 밖에는..
“개발환경이 미진하여 다른 환경으로 회귀했다.
환상을 가졌으나 열악한 환경으로 인해 깨져버렸다 .
그 정도 환상적인 노력은 다른 언어도 하고 있으니 루비온레일스를 믿지마라 …”
이런 이야기입니까?? 이해가 안가는 군요.
“환상을 가졌다가 깨지니 반감만 생기더라” 입니까?
어디서 무슨 개발을 하시는지는 몰라도 개발자의 최대 강점인 호기심과 도전정신이 안보입니다.
이런 소리한다고 해서 저도 나을 것 하나 없습니다만 적어도 저는 환상이 깨졌다느니,
제공하는 환경이 열악하다느니하는 이야기는 하지 않습니다.
비슷한 경력을 가진 사람으로써 참으로 안타까운 마음에 한마디 했습니다.
2007-05-09 at 12:16 오후
아! 참고로 아직도 루비를 공부하고 테스트로 무었인가를 만들어보고 있습니다.
하지만, 프로젝트에 이용하려던 계획은 취소했습니다. 루비가 앞으로 더욱 성장한다면 프로젝트에 도입해도 좋겠지만 아직은 아니라고 보입니다.
* ‘구현가능하다’와 ‘구현하기에 적합하다’는 의미가 다르다고 봅니다. 구현 할 수 있지만 불편하다면 ‘구현하기에 적합하지 않다’라고 이야기할 수 있습니다.
라고 이야기한부분이 있습니다.
구현이 불가능하다고 이야기하지는 않았지만 매우 불편하며 오히려 기존 개발언어들에 비하여 비효율적이라는 것입니다.
“어디서 무슨 개발을 하시는지는 몰라도 개발자의 최대 강점인 호기심과 도전정신이 안보입니다. ”
개발자의 도전정신과 호기심으로 프로젝트를 망칠 수도 있습니다.
10년전 자바라면 실제 상용서비스를 개발하기에 적합하지 않았습니다.
물론, 지금은 상용서비스로 가장 좋은 평가를 받고 있기는 하지만요.
또한 예를 들어 특정 인증받아야 하는 콘텐트를 크롤링해오는 보트와 유사한 기능을 구현해야한다면 루비로 어떻게 하시겠습니까?
또한, 이 글은 루비온레일즈를 비난하기 위함이 아니라 기업환경에 적용하기엔 이런 저런 문제들이 있으니 적용시 주의하라는 것이 요지입니다.
무작정 환상을 가지고 도입했다가 이런 저런 문제로 인하여 프로젝트가 위험에 빠질 수도 있으니 말이죠.
또한, 제가 가장 우려하는 부분중에 하나는 개발자의 마인드로 프로젝트의 플랫폼이나 프레임워크를 결정해서는 안된다는 것입니다.
2007-05-10 at 3:35 오후
행복이님을 비난하고자 함은 아닙니다. 제가 좀 격앙되어서 죄송합니다.
말씀하셨듯이 호기심과 도전정신이 프로젝트를 망칠수도 있습니다. 물론 저도 알고 있습니다.
하지만 조심하여야한다는 요지의 글이 아닌것같아 말씀드린것입니다.
글을 읽고서 느낀건 “루비는 프로젝트에 적합합지 않다. 지금은 사용 할 이유가 없다”라는 것이었기 때문이었습니다.
위에서도 동의 했듯이 현재 시장에 진입하기엔 많은 위험이 있습니다.
그렇다면 루비온레일스가 어떤 프로젝트든지 사용하기 적합할 때까지 기다리겠다는 말씀이신지?
발전은 가만히 있어도 되는게 아니라고 생각합니다.
수 많은 개발자들이 실패와 시행착오를 거쳐 이룩되는게 발전이라고 생각합니다.
한번에 모든 발전을 이루면 좋겠지만 지금까지 그렇게 진행된 기술은 없었다가 제 결론입니다.
그렇다고 실패와 시행착오를 강요하거나 찬양하는건 절대아닙니다.
님의 생각은 “조급히 생각하지말고 현재 루비로 프로젝트를 진행하기 위해서는 위험성이 존재하니 조심하자” 라는 것이지요?
님의 생각은 충분히 이해되었으나 쓰신 글은 생각과 조금 차이가 있는것같습니다.
많은 루비스트들이 저와 비슷하게 생각하지 않을까 싶습니다.
쓰신 글은 거의 비난에 가까운 수준입니다
지금 많은 루비스트들이 루비에 재미에 빠져 밤새는 줄모르고 실수와 실패, 시행착오를
겪어가며 프로젝트등을 진행하고 있습니다.
그들을 바보로 만들지 마십시요.
그들도 PHP나 자바로 프로젝트를 하면 지금보다는 쉬워질수 있다는걸 압니다.
왜 생소한 루비와 레일스로 프로젝트를 진행하겠습니까?
개발자로서 누가 프로젝트를 실패하고 싶어하는사람이 어디 있겠습니까?
프로젝트가 상업적으로 흐르다보니 실패해서도 안되고 두렵기까지 하긴합니다만
개발자의 마인드가 확고하다면 무엇으로 하든지 프로젝트는 성공할 것이라고 생각합니다.
님께서는 지금도 루비를 공부하신다고 했지요? 한가지 궁금한점은 그렇게 비효율적이라면 왜 공부를 하시는지요?
님과 싸우고자 함은 아닙니다. 하지만 자신이 쓴글에 많은 사람들이 같은 반응을 보인다면
다시 한번 생각해 보시기 바랍니다.
2007-05-10 at 5:10 오후
비난이 아니라 실제적으로 발생하고 있는 문제점들을 이야기 하는 것입니다.
모델기반을 벗어날 경우 불편하며 퍼포먼스문제와 개발라이브러리나 깊이가 부족하다는 것은 충분히 인지하시고 프로젝트에 적용을 하시면 될 것 같아요.
루비로 업무를 진행해보시면 누구나 알 수 있는 내용들입니다.
2007-05-10 at 8:27 오후
네. 위의 말씀에 동의합니다. 실제적으로 업무를 하다보면 많은 위험성이 내포되어있는것은 사실이죠.
알고있습니다.
제가 이야기 하고자 하는것은 글의 내용이 님의 의도와는 맞지 않는다는것입니다.
문제점을 이야기하셨다고 하지만 결론은 비효율적이다가 결론이지않습니까?
만약 행복이님의 의도대로 라면 글의 제목은 글쎄..가아니라 아직은 ..이라고 했어야 맞습니다.
저도 루비를 한지 얼마안되어서 문제점이 있다는 것을 잘인지하고 있습니다.
불편하다는 것도요.
하지만 이글을 읽고 루비를 계속해야하는지에 대한 회의가 들고 힘이 쫙 빠집니다.
의도가 그런것이었다면 성공하신거지만 아니라면 잘못 쓰신것이라고 볼수있습니다.
두번세번 읽고 또읽어도 느낌이 같습니다.
우리 속담에 ‘아’다르고 ‘어’다르다는 속담이 있습니다. 그것만 충분히 인지하신다면
문제는 없어 보입니다. 저도 위와 같은 문제를 많이 겪었으니까요
하지만 이건아니라고 봅니다. 열심히 하는사람들 힘빼게하는 건 좀 아니지 않나요?
그냥 루비하는 사람으로써 비효율적인 프레임웤으로 프로젝트하는 바보 취급받은 것 같아 격양된 표현을 많이 썻던 것같습니다
그점은 사과드립니다.
님의 말씀대로 많은 문제점이 있고 자료도 부족합니다. 그래서 많은 루비스트들의 노력이 필요한것이구요. 힘을 내야하는 상황이죠. 힘을 불어넣어 주실수 있는 글도 써주시기 바랍니다.
글 잘읽었습니다. 닉넴임처럼 항상 행복하시고 건강하세요
2007-05-20 at 7:32 오후
?덉씪??而⑦띁?곗뒪???덉젙?낅땲?? ?댁젣?..
2007-05-24 at 1:44 오후
‘猷⑤퉬?⑤젅?쇱쫰’ 湲곗뾽?쒖옣 吏꾩엯 “湲?…
2007-05-24 at 3:38 오후
RoR의 CRUD 처리를 보면서 90년대 중반을 풍미했던 파워빌더, 델파이 등의 4GL과 유사함을 느꼈습니다. 4GL의 CRUD 처리는 RoR의 CRUD 처리보다 쉽다고 할 수 있습니다. 그야말로 테이블만 연결 시켜주면 CRUD 처리가 됩니다. 하지만, 이런 프로그램은 거의 없으며 조금 더 깊숙하게 들어가야 하는데 그러면 양상이 달라집니다. RoR의 모습을 보면서 4GL로 웹 프로그램을 구사하는 듯한 느낌을 받았습니다.
구구절절 좁은 칸에 쓰기에 한계가 있으므로 제가 내린 결론은 기업에 RoR을 적용하기에는 향후 어떻게 될 지 모르지만 지금은 이르다는 것입니다. 기업에 있어 생산성이 매우 중요하지만, 그 보다 더 중요한 것은 조직적인 접근입니다. RoR이 프로그램 개발을 쉽고 빠르게 한다고 하지만, 이것은 프로그램 중심으로 시스템 개발을 접근한 것입니다. 기업 시스템에 있어 프로그램 개발이 차지하는 비중은 그리 크지 않습니다. 기업 시스템은 벤처 정신보다는 안정적인 접근에 무게를 둘 것입니다. 대량의 데이터 처리와 확고한 비즈니스 로직 처리에 비중이 크다고 할 수 있습니다. 요구사항 변경에 능동적으로 대처할 수 있다는 점은 그리 설득력이 없습니다. 프로그램 중심으로 접근하면 이런 모습이 발생하지만, 조직적인 접근을 하면 이 사항의 비중이 떨어집니다. 여러 RoR을 다루는 블로그의 글을 보면서 느끼는 것은 시스템을 프로그램 중심으로 접근한다는 것입니다. 이 점이 아쉽기도 합니다… 시스템은 시스템적으로 접근해야 합니다. 언어는 시스템을 만드는 도구입니다. 언어가 메인이 될 수는 없습니다.
2007-12-20 at 11:39 오전
언어나 아키텍쳐의 컨셉이 좋은거랑 적용에 좋은거랑은 별개죠.
(hibernate 좋죠? si적용해보세요..;
10년전 얘기가 나왔으니 말인데.. 그 당시 자바개발 0%에 수렴합니다.
그리고, 초기에 개발할 때 요구사항을 맞춰줘야 하는데..
관련 라이브러리가 없어서 똥줄타게 일일이 직접 만들어서
개발했던 시절을 성숙된 현재의 java환경에선 상상할 수없겠죠..
성숙되기전 적용에 대한 트레이드 오프는 분명 비교할 문제라는 겁니다.
기술적 요구사항이 마구도출될때
성숙된 각종 문서,라이브러리,포럼,팁,고민들이
기존의 언어나 개발환경만큼 갖춰져 있고 확보되어 있을까요?
그리고 그것에 일반 개발자들도 쉽게 접근하고 알 수 있는 장치, 환경이 있나요?
그럼에도 불구하고 적용하려는 특별한 이유가 있으면 모를까..
개발자의 미학적 관점에서 굳이 기존환경을 엎을만한 요소가 있다는 생각은 현재는 들지 않습니다.
물론 재미로 노는거라면 얼마든지 가지고 놀겠지만 말이죠.
2008-07-01 at 10:24 오전
루비온레일스 뿐만 아니라, 유명한 프래임웍, 언어도 유언하게 사용해야 합니다. 루비온레일스의 문서가 단순한 개발에 중점을 둔 경향이 있긴하나, 파고들면 일반언어와 다를바 없습니다.
현 시점에서 단지 보현화 되지 않아 그렇지, 자바나 ms의 언어처럼 쓰이게 만드는 누군가가 머지않아 나올 수 있고 그들이 바로 자신일 수도 있습니다.