SI 중심의 소프트웨어 산업구조도 한 몫하고 있지요. 한국의 직장인 문화가 여유가 없이 살기 빠듯한 것도 있구요. 이미 자바는 생계를 위한 언어로 코볼의 뒤를 이어가고 있지요. 그리고 레퍼런스, 레퍼런스 외치는 S기업의 조직문화도 잉여력의 부족과 레거시의 저주(사람, 조직, 시스템, 애플리케이션)도,

그럼에도 성공하는 기술들은 다수의 매니악한 기술 전도사들 때문이겠지요.

잘 읽었습니다. 형님이 분석한 대로 ORM에 대해 잘 이해해서 리딩할만한 수준의 개발자가 적은 것이 가장 큰 이슈일 것 같습니다. 결국 DB중심에서 object 중심으로의 패러다임의 변화가 필요한데 몇년 전이나 지금이나 아직도 DB중심의 개발환경인 것 같습니다. (저는 ORM이 만병통지약이라고는 생각하지 않습니다.) 그리고 또 하나, 국민성과도 일정부분 관련이 있지 않을까 생각해봅니다. 그만큼 빨리빨리를 외치는 한편 금새 관심을 돌려버리기 때문에 RoR이나 Play가 정착되지 못했을 수도 있지 않을까요?

@kenu 공감합니다. 특히 ruby on rails 같은 경우에는 몇몇 서비스의 성공 모델이 있었다면 좀 더 넖게 퍼졌을텐데 초기에 굵직한 서비스들에서 성능 이슈를 극복하지 못하는 바람에 좋은 레퍼런스가 만들어지지 못한 듯 합니다. 카카오톡은 아직까지 RoR을 잘 쓰고 있다고 하는데 뒷 단은 자바 기반으로 동작하는 것으로 들었어요. 이런 식으로든 성능 이슈를 극복하기 위한 노하우들이 나와서 공유되었다면 RoR 생태계에 많은 영향을 미쳤을 것이라 생각합니다.

근데 형이 이야기한데로 국내 SI 중심의 산업구조가 정말 큰 영향을 미치고 있다고 생각합니다. 그 틀을 깨기가 쉽지 않은 듯 합니다. 하지만 새로이 시작하는 스타트업 기업에서는 RoR과 Play 같은 프레임워크를 활용해도 좋을 듯 한데 생각보다 많이 사용하지 않아서 아쉬움이 남아서 글 남겨봤습니다.

자기가 쓰려고 SW를 만드는 소규모 개발 조직이 별로 없기 때문이라고 봅니다. 근데 RoR은 알겠는데 Play의 생산성이 높나요? 초기 설정이야 Blank Project 하나 만들어 두고 쓰거나 AppFuse, Spring Roo 같은 걸로 쉽게 해결 가능하고... 그 이후에는... 그닥...

RoR의 개발자로써 정말 안타깝게 생각하고 있습니다. kenu님의 생각에 많이 공감을 하고요 또 한가지의 생각은 RoR은 소규모, 테스트 프로젝트에 쓰기에 적합하다라는 마인드가 아닐까 합니다.

1년전쯤 제가 해본 성능 테스트 결과로는 지금 회사에서 메인 프레임웍으로 쓰고 있는 PHP와 거의 차이가 없는 것으로 결과도 나왔었습니다.

국내 서비스에서는 카카오톡과 미투데이가 RoR로 되어있었는데 미투데이쪽도 자바쪽으로 점차 넘어가고 있었지만 개발자들과 이야기해보면 성능적인 문제보다는 개발자를 구하는 문제 + 인식의 문제로 자바쪽의 기술도 같이!!!! 쓰는 것으로 되었었습니다. (카카오톡은 잘 모르겠네요) 사실 트위터가 RoR로 되어 있다는 것만으로 성능상의 문제는 이야기할 부분이 없다라고 생각합니다. 일본의 경우는 루비개발자가 많아서 RoR로 되어있는 서비스가 꽤 있는 것으로 압니다.

이런 마이드가 개발자의 풀을 적게 만들고 그러다가보니 RoR개발자를 구하기 힘드니 확장하기 힘들고.. 이런 사이클을 돌고 있는 생각이네요..

제가 소규모라고 한 이유는 개발자가 적어서(=구하기 힘들어서) 대규모 프로젝트에 RoR을 적용할 수 없기 때문입니다. 그리고 성능 문제는... 10여년 PHP로 개발한 사람으로서 말하자면 PHP 만큼 나오면 느린 겁니다. -_- 하지만 장비발로 해결 가능하죠. 개인적으로 jRuby on Rails의 성능이 어떤지 궁금한데 jRuby 1.0 나오기 전만해도 jRuby만 나오면 동시성과 성능 이슈 해결될 거라면서 열광하더니 정작 나온 다음에는 "jRuby 뭐임? 불결하게 jvm에 ruby 돌리는 게 제 정신임?"하는 분위기로 반전하더군요.

자.. ROR로 대형 사이트를 개발했습니다.(정말 빡세게..)

근데, 작업자 대다수가 1-2년 내에 이직을 합니다. 어이쿠.. 사람 뽑아야 겠네..

어.. 없군요.

닭이 먼저냐, 달걀이 먼저냐의 문제일수도 있지만, 기업 입장에서 보면 그런 고민은 사치죠. 물론 한가지의 예..

글과 의견들 모두 잘 읽었습니다.(구글링하다 들어왔습니다) 자바로 먹고사는 SI프로젝트 종사자인데.. RoR을 꼭 해보고 싶습니다만, 생업에 치여서 엄두도 못내고 있습니다. 책도 읽어보았는데, 좀 된다 싶어도 바빠서 한 한달 놓고 있다 다시보면 머리속이 하예지요. 그러니까 생각 자체를 자유롭게 여기에 두었다 저기에 두었다 해야하는데, Java니 플렉스니 이런거 한달동안 보고 오면 루비가 외계어로 보입니다. (뭐 제 이해도가 그만치밖에 안된다는 문제도 있겠네요.)

여하튼, ORM 에 대한 이해가 부족하다 등등 많은 의견을 보았는데, 다 맞는 이야기 같습니다. 복합적인 문제네요. 따라하기 식의 책이라도 사서 봐야겠다는 생각이 듭니다. 나름 SI에서 잔뼈가 생기는 중인데... 이런 질문들 스스로가 혼란스럽네요. 허허~

아 제가 RoR을 해보고 싶은 이유는 시간은 없고, 개인프로젝트는 막 떠오르고.. 그래서 그렇습니다. 엿같은 SI 결과물 말고 뭔가 좀 의미있는 일들을 해보고 싶네요. 돈은 안되도.. ㅋ

play scala 개발자입니다. framework oralce database orm 공식 지원 library인 slick이 유료인 게 한 몫 하는 것 같습니다. 개발자가 db access layer를 직접 책임지지 않는 이상은 기존 유료 framework 대비 경제적인 가치가 없어지는 것 같습니다. 국내 구조상 db layer를 국내 개발자가 책임지게 하는 업체가 과연 있을까요?

전체 시스템이 확장되면 nosql, hadoop 같은 부분이 전체 시스템에 연동되어지면 이 부분도 담당 개발자가 어느정도 책임을 지고 개발해야 하는데 이런 부분에 투자해 주는 사업 관리자가 얼마나 있을런지요?

@eugeneseon

윗분 말에 공감하기 힘든게 국내 어딜가던 ORM을 쓰는곳이 얼마나 있는지 잘 모르겠습니다. hibernate도 사례가 거의 없는데 scala slick이면 인지도가 아예 없다고 봐야하지 않을까요

orm 이라고 하지 않았습니다. db access layer 부분입니다. 여러자기 기능이 들어 갈 수 있겠죠. transcation, fault-tolerant, master-slave replication, REST API, log processing, etc.

2008년에 의사의 카르테를 전자펜으로 인식하여 의료용품재고/출납관리와 연동시키는 프로젝트에 1년정도 참여하였습니다. 그때 RoR을 처음으로 사용해보았구요.

물론 많은 시간이 흘렀으니 그때 상황과는 많이 달라졌으리라 생각하지만 그때 제가 느낀 점들을 몇자 적어보고자 합니다.

1.ORM은 현업에서 쓰기에는 느리다. 이 부분은 제가 실력이 없어서 그럴 수도 있지만, 십수개의 테이블을 연결하여 값을 찾아들어가야 하는데 ORM으로는 도저히 퍼포먼스가 안나왔습니다. 간단한 테이블 구조에서는 직관적으로 만들기 편한 장점이 크지만, 복잡한 테이블 구조에서는 만드는 것은 간단한데 퍼포먼스가 안나오는 단점이 더 크게 부각됩니다. 결국 많은 부분을 직접 쿼리를 짜서 넣었습니다.

2.버전관리 버전관리는 어느 언어를 사용하던지 상당한 부담으로 다가옵니다. 제가 경험한 바로는 그나마 버전업에 대한 리스크가 적고, 리스크에 대해 대응하기 쉬운것이 자바인것 같습니다. 현업에서 사용해 본것이 자바, PHP, RoR 뿐이라서 3가지만 비교해 보자면 자바 > PHP > RoR 정도인것 같네요.

자바의 경우는 1.4에서 1.7로 바꾸는데도 거의 손이 안들어가고 리빌드가 되었었고 PHP는 3.x 를 4.x로 올리면서 거의 모든 소스를 손대었던 기억이 납니다. RoR은 개발 기간중에 다음버전이 발표되었는데, 버전업의 리스크가 너무 커서 결국 버전업은 포기했었습니다.

3.커스터마이즈 RoR의 장점중 하나가 구현해야하는 많은 부분들을 기본적으로 제공해주는 것인데 기본적으로 제공해주는 것 만으로 필요한 요건을 만족시키지 못할 때 커스터마이즈가 필요합니다. 이런 경우 개발공수는 갑자기 뛰게 되고, 이런 부분이 몇부분 나오면 차라리 그런 틀 자체가 없는 것만 못하게 되는 경우가 있습니다.

위에 언급한 3가지는 부정적인 점만을 나열한 것인데요, 사실 RoR개발기간동안 너무 재밌고 즐거웠습니다. 이런 점들이 개선된다면(혹시 이미 개선되었는데 저만 모르고 있는 것일수도 있겠지만) 현업에서도 널리 쓰일수 있지 않을까 생각합니다.

몇개월전에 레일즈 스타트업에 참여 해서 개발을 했었습니다. 시작부터 끝까지 학습곡선 초기였는데 내내 일본어를 번역 했습니다. 아주 큰 트위터같은 서비스가 아닐 때 좋은 프레임워크라고 생각 하고 있습니다.

그리고 ORM에 대한 의견이 분분한데 별다른 문제점을 느끼지 못했습니다. 성능은 디폴트로 사용할 때 문제가 있었지만 튜닝을 할 때마다 빨라 졌기 때문에 모르겠습니다. 크롬 익스텐션과 연동되는 gem도 있고... 재미있는 기능이 많습니다.

필요한 gem 위주로 개발을 하다 보니 나중에는 gem 에 의한 기능 변경도 생기게 됩니다. 이게 문제여서 다시 하는것도 몇 있었는데 그래도 정말 재미있었습니다.

스타트업으로 오면 Java 백엔드는 거의 없다고 보시면 됩니다.

저희 회사 또한 RoR 이구요. (제가 도입)

@이도현

"윗분 말에 공감하기 힘든게 국내 어딜가던 ORM을 쓰는곳이 얼마나 있는지 잘 모르겠습니다. hibernate도 사례가 거의 없는데"...

네? 그게 정말인가요? 좀 충격적이군요. :O

저도 몰랐는데요, (어떤 클라우드 회사의 통계 자료를 보면) 스타트업은 RoR 많이 씁니다. 왜 RoR 쓰는 개발자가 안 보일까요? 라고 물어보시면 일 하느라 바빠서 대외활동을 할 시간이 너무 없다고 합니다... 거꾸로 궁금한 점은 그루비 + 그레일즈 또는 플레이가 훌륭한 레일즈의 대안이 될 수 있을까요?

현재 PHP와 DB를 살짝 공부한 왕초보 고딩 웹 개발자 입니다... 최근 취업에 관련하여 여러가지 기술을 찾아보니 참 많은 기술이 있더군요.. 파이썬, 루비, 자바 등등... 이 모든 기술들이 웹에 사용되는것은 알고있었지만 어떻게 사용해야할지!

아직 갈길이 멉니다 ㅎㅎ

이런 주제에 관해 토론을 하시는 여러분들이 정말 멋져보입니다 ㅠㅠ 그런데 중간에 PHP는 별로 좋지 않을것이다 라는 글을 많이 보았는데 왜인지 알 수 있을까요! 아직 배우고 해본것이 많지 않아 궁금증이 많습니다!

PHP에 대한 비판 중에서는 아래 글이 유명합니다.

http://noraesae.github.io/PHP-a-fractal-of-bad-design-kr/

@Sanghyuk Jung 재미있게 읽었습니다. 제가 겪어보았던 사실들도 존재하는군요. 어떻게 보면 쉽고 빠른 언어이지만 또 어찌보면 굉장히 어렵기도 한것같습니다. 이제 다른 프레임웍이나 ASP 나 JSP 등을 배울 예정인게 그나마 다행인걸까요 ㅎㅎ