송치형의 InnoLab

'루비온레일즈' 기업시장 진입 "글쎄..."에 대한 답변 글입니다.

 이 글의 기본 논조는 '기본적인 기능은 구현하기 쉽다. 하지만 구현이 복잡해 지면 레일즈는 오히려 더 불편하다'인 듯 합니다. 제가 이 글을 보고 느낀 것은 '레일즈만 보고 루비는 보고 있지 않다', '레일즈의 Convention으로 해결 못하면 다른 언어, 프레임워크보다 구현하는 것보다 더 어렵다고 생각하고 있다'는 것입니다. 각 항목에 대해 하나하나 살펴보도록 하지요.

1. 모델 기반에서 벗어날 경우 오히려 불편?
    - 자바 하이버네이트에 대한 비판과 비슷하군요. 하이버네이트를 편리하게 사용하고 있다면 ActiveRecord도 편리하게 사용할 수 있습니다. 둘의 비교에 대해서는 시간이 약간 지나기는 했지만 '마소' 2006 년 10월호 Special Report로 기고했던 '루비 온 레일즈의 꽃 - 액티브 레코드'를 참조하시기 바랍니다.
    - 정규화가 잘되어 있지 않은 레거시 DB가 있고, 이를 수정하지 못하는데 레일즈를 이용해 다시 프로젝트를 하는 경우라면 모델이 불편할 수도 있습니다. 하지만 이 경우는 하이버네이트도 마찬가지입니다. 이런 경우라면 예를 들어 자바로 할 경우, iBatis를 이용하거나 JDBC를 이용할 것입니다. 그렇다면 루비의 DBH는 왜 언급을 안하지요? 마틴 파울러가 Domain Logic and SQL이란 글을 쓴 적이 있네요... 루비의 DBH로 구현되어 있습니다. 2003년도 문서군요. :)
    - 화면 요구사항이 까다롭다는 것과 모델이 무슨 상관이 있는지 모르겠군요. 저는 오히려 클라이언트의 요구사항이 복잡하고 까다로울 수록 레일즈가 편했는데요...
    - acts_as_attachments : 파일 시스템에 저장하는 기능이 있는 것으로 알고 있습니다.

2. 기존 개발 플랫폼이나 프레임워크에서도 개발 속도 향상 노력이 있다?
     - 네, 이 항목에는 동의합니다.
     - 2006년에 쓴 'J2EE와 Rails에 관한 논쟁들'이란 글을 쓴적이 있습니다. 이 글을 쓴 이후로 Rails의 생산성에는 좀 더 후한 점수를 주게 되었습니다.
     - 언어와 프레임워크들은 서로 영향을 주며 발전합니다. 이는 상당히 긍정적인 부분이죠. 꼭 루비 온 레일즈를 사용할 필요는 없습니다. 하지만 공부하려는 노력은 필요하다 봅니다. 많은 인사이트를 얻을 수 있기 때문입니다.
     - 그리고 노력을 한다 해서 해결이 다 되는 것은 아닙니다. 기존 언어는 하위 호환성을 고려해야 합니다. 그래서 버리고 싶어도 버릴 수 없는 것들이 많습니다. 인기가 오히려 발목을 잡는 것이지요. 예를 들어 기존 타입 시스템과의 호환성 및 안정성 때문에 복잡해진 자바의 Generics와 Closure를 예로 들 수 있을 듯 합니다. 자세한 내용은 Joshua Bloch의 Java Puzzler를 참조하시면 좋을 듯 합니다(특히 10장. Advanced Java Puzzlers).

3. 로우레벨의 개발에서는 기존 개발 플랫폼이 월등하다?
      - 로우레벨이란 용어가 무엇을 말하는지가 애매하네요. JNI 등 FFI(Foreign Function Interface)를 말씀하시는 것은 아닌 듯 합니다. 내용을 보니 라이브러리를 말씀하시는 듯 합니다.
      - 라이브러리라면 당연히 오래 인기를 얻어온 언어가 유리합니다. 하지만 루비와 레일즈에도 상당히 많은 라이브러리들이 존재합니다.
      - 심화된 기능과 특별한 요구사항을 말씀하셨는데 도대체 왜 이 이야기가 나오는지 잘 모르겠습니다. 루비와 레일즈는 이 부분에서도 강점을 발휘하는데 말이지요. 루비는 메타 프로그래밍, 클로져, 컨티뉴에이션, 오픈 클래스, 메시지 전달과 missing_method 처리 메커니즘, 선택적 파라미터 등 수많은 고급 언어 기능을 지원합니다. DHH의 'Rails is Rails because of Ruby'와 Kent Beck의 "I always knew one day Smalltalk would replace Java. I just didn’t know it would be called Ruby."란 말은 괜히 나온 것이 아닙니다.

4. 퍼포먼스 문제는 심각하게 고민해야 합니다?
      - 역시 하이버네이트에도 적용되는 말입니다.
      - 그런 경우가 있다면 모델에서 find_by_sql을 써보시면 어떨지요...
      - 동적 스크립트 언어라 퍼포먼스에 문제가 있다는 점은 인정합니다. 하지만 말씀하신 쿼리 최적화의 가능성은 활짝 열어두고 있습니다.

5. 참고자료가 부족하다?
      - 네, 제가 2006년 초에 공부할 때는 그랬습니다. 한글 서적이 한권도 없었으니 말이지요.
      - 그런데 지금은 인사이트의 '프로그래밍 루비', 'Agile Web Development with Rails', 'Rails Recipes', ITC의 'Ruby for Rails', 한빛 미디어의 'Ruby on Rails' 등 5권의 책이 있습니다. 아, 대산 님의 책도 있군요. 그리고 조만간 몇권 더 나올 것으로 알고 있습니다.
      - 커뮤니티와 메일링 리스트를 말씀하셨는데 일정 부분 공감합니다. 그런데 개발자에게 영어 독해는 어느 정도 필수 사항(?) 아닌지요? 자바 역시 필요한 내용을 찾을 때 구글링하게 되고 주로 영문 자료를 보게되는걸요...

6. 웹 2.0기능의 강점?
      - 레일즈의 Ajax 기능은 크게 2가지 정도로 나누어 볼 수 있을 듯 합니다. Prototype과 script.aculo.us를 쉽게 사용할 수 있도록 해주는 헬퍼들과 RJS 입니다.
      - 제 경우는 기본 헬퍼와 RJS가 지원하는 부분에 대해서는 이들을 사용하고, 이를 벗어나는 범위의 개발이 있을 때는 개인의 취향 상 jQuery를 사용하고 있습니다. 만약 Prototype을 좋아한다면 RJS 등에서 Proxy(Collection Proxy 등)와 JavascriptGenerator를 이용하여 Prototype의 모든 기능을 자유롭게 이용할 수 있습니다. 레일즈의 Ajax 기능에는 Ajax 헬퍼만 있는 것이 아닙니다. 저는 단지 Prototype 보다 jQuery를 선호하기 때문에 jQuery를 통합해 사용하고 있을 뿐이지요.
      - 그런데 여기서 다시. 왜 "제공되는 범위를 벗어날 경우에는 오히려 더 힘들다는 점은 기억하실 필요가 있을것 같군요"라는 말씀을 하신건지 모르겠습니다. 무엇이 더 힘들다는 것인지요? 기본 기능을 편하게 제공해 준다는 것이 확장을 막는다는 이야기는 아닙니다. Convention over Configuration 역시 마찬가지입니다. 관례를 통해 보다 쉽게 문제를 해결하도록 도와준다는 의미이지 설정을 막는다는 이야기가 아닙니다.
      - RJS에 대해서도 한 말씀 드려야겠군요. RJS에서는 임의의 자바스크립트 코드를 삽입할 수도, 인클루드했던 자바스크립트의 객체를 사용하거나 함수를 호출할 수도 있습니다. 레일즈를 사용한다고 해서 기본 기능만 사용하는 것은 아닙니다. 기본 기능을 편리하게 이용하되 필요한 경우 외부로 자바스크립트 파일을 빼고, RJS 등에서 이들을 편리하게 사용합니다.
      - 제 경험으로는 레일즈의 웹 2.0 기능은 "헬퍼로 기본 기능을 편리하게 사용하고, RJS를 통해 'Instruction instead of Data'를 지원한다"는 것이 핵심인 듯 합니다. 그리고 확장 가능성은 활짝 열어두고 있습니다.