요즘들어 자바의 생산성이 매우 뒤떨어진다는 얘기를 많이 듣는다. 주로 Ruby/Rails를 설명할 때 자주 비교의 대상이 된다. 조금 전에읽은 Hibernate와 ActiveRecord간의 비교에 관한 글에서도 Hibernate/JEE는 생산성이 떨어진다고 주장하는 내용을 볼 수 있었다. 물론 나도 일부분은 동의한다. 특히 EJB로 개발하던 시절에는 자바엔지니어들은 도무지 생산성은 고려하지 않고 기술을 내놓는가하는 심각한 고민을 하기도 했다. 하지만 Spring/Hibernate로 이어지는 Lightweight기술들과 그 후의 많은 노력들 (특히 Java5)은 자바의 생산성을 극대화하고 간결한 기술을 만드는데 많은 영향을 주고 있다고 생각된다.

누구는 뛰어난 생산성을 가지고 개발을 하고 싶지 않겠는가? 그래서 IDE를 사용해서 빌드시간과 코딩의 수고를 덜어내고 Hibernate나 Spring과 같은 POJO기술이 보편화되서 EJB3에까지 영향을 주고 점점 간결한 설정파일과 방식을 지향하고 심지어는 각종 CoC같은 개념까지도 도입하려고 애쓰는 것 아닌가.

나는 결코 자바가 생산성이 떨어진다고 생각하지 않는다. 나도 가볍고 빠른 개발이 필요할 때는 php나 RoR을 사용한다. 구지 간단한 웹사이트의 게시판이나 회원관리를 JEE/Spring/Hibernate로 만들지 않는다. 간단한 애플리케이션이나 시간에 쫒기는 시연등을 위해서는 그에 적절한 기술을 사용하면 된다. 생산성이라는 것은 프로그램 개발 전체 라이프사이클을 통해서 나타나는 결과이다. 초기에 좀 더 빠른 아웃풋이 나오는 것을 가지고 프로젝트의 생산성을 말할 수는 없다. 그런식으로 치면 VB는 최고의 생산성을 지닌 툴이다. 반대로 TDD는 생산성을 저해하는 가장 쓸모없는 방법이라고 할 수 있겠다. 하지만 일정 규모를 넘어서는 복잡도가 있는 애플리케이션이라면 초기 작성 생산성이 전체에 미치는 영향은 극히 미미하다고 할 수 있다. TDD는 시간이 지날 수록 프로그램이 복잡해질수록 전체 생산성을 높여준다. 결함이 있는 제품을 빨리 만들어봤자 생산성이 있다고 얘기할 수 없기 때문이다. 복잡한 구조를 가진 애플리케이션을 인원이 많은 팀이 작업을 할때도 그 생산속도가 시간이 갈 수록 현저히 저하되지 않아야 한다. 그런면에서 자바와 JEE의 최근 기술들은 내가 생각하는 최고의 생산성을 가진 도구라고 생각된다. 단지 코드라인수를 줄일 수 있고 바로바로 실행가능하고 몇가지 트릭을 쓸 수 있는 것이 꼭 생산성의 전부라고 생각할 수 없다.

그런면에서 요즘 얘기되는 자바의 생산성에 대한 지적은 모두 옳다고 볼 수 없다. 특히 Rails등과 비교는 조건을 명확히 명시하지 않는한 반쯤은 거짓말이다. 나도 Ruby를 좋아하고 RoR을 공부하면서 많은 매력을 느꼈다. 작지만 RoR로 웹애플리케이션을 개발해보면서 감동도 받고 다른 사람에게도 사용을 권유하기도 한다. 하지만 그래도 JEE보다 RoR이 생산성이 좋다고 말하지는 않을 생각이다. 다만, 복잡하지 않고 빠른 웹애플리케이션이 필요하면 RoR을 사용하겠다. 하지만 조금이라도 규모가 있고 복잡한 사이트라면 JEE를 쓸 것이다. 나는 Convention이라는 함정에 쉽게 빠지면 안된다고 생각한다. 잠시 달콤하지만 어느 단계에 가서는 일을 더 복잡하게 만들 수 있는게 Convention을 너무 신뢰하는 것이다. 내가 Maven을 좋아하지 않는 이유도 그렇다. 15분짜리 데모에 혹해서는 안될 것이다. (사실 나도 그런 것을 보면 혹한다. 워낙 단순해서…  :)
하지만 반면에 나는 자바의 생산성을 향상시키기 위한 노력이 끊임없이 필요하다고 생각된다. Annotation이나 XDoclet에 대한 많은 요구를 계속 묵살해온 Spring의 예에서 많은 생각을 해볼 수 있다. Rod Johnson은 Spring의 간결한 XML구조는 구지 Annotation,XDoclet등을 도입할 필요가 없을만큼 충분히 심플하다고 생각해서 그간의 요구를 많이 묵살해왔다. 하지만 나만 해도 Spring XML을 다루고 이해하는 것이 너무 힘들만큼의 매우 복잡한 애플리케이션을 개발하면서 무엇인가 절실한 필요를 느끼기 시작했다. 이전에 Spring/Hibernate는 지금 RoR이 그런 것처럼 내부 인트라넷 사이트나 가벼운 애플리케이션 개발에 사용되었다. 그때는 당연히 기존의 XML설정파일구조라도 별로 복잡하지 않았을 것이다. 하지만 점점 대형 사이트의 MissionCritical한 시스템에 사용되면서 그 복잡도가 증가하고 좀 더 심플한 설정방법을 스스로 찾아나가던 커뮤니티에 의해서 만들어졌던 Custom XML이 2.0에서는 표준화되어 등장하게 되었고 또 설정파일의 기본적인 사용방법 조차 훨씬 심플해졌다. 아직 초보적인 단계지만 CoC가 공식적으로 도입되어 적용되고 있고 Rod Johnson은 필요하다고 판단되면 언제든지 Annotation을 통한 설정을 도입하겠다고 밝혔다.
나는 기존에 개발해 1년여 넘게 적용해왔던 OSAF를 공개하지 않고 다시 원점에서부터 다시 재개발하고 있다. 솔직이 그렇게 된 배경에는 Ruby/RoR을 보면서 느낀 생산성향상의 아이디어가 큰 영향을 주었다. 또 그런 작업을 원활하게 가능하게 만들어주는 Spring2.0의 등장도 그렇고. 거기다 AppFuse와 같은 기본프로젝트 구성을 쉽게 도와주는 방식과 Eclipse라는 멋진 IDE와 plugin기술까지 적용한다면 RoR못지 않은 뛰어난 생산성을 갖춘 Spring/Hibernate기반의 ADF로 만들어질 것이라는 기대가 있다.

또 한가지. 자바개발자들은 프레임워크를 가져다 쓸 줄만 알지 이를 변경하려는 시도는 하지 않을 것이라는 DHH의 주장은 틀렸다고 생각한다. 물론 자바로 만든 프레임워크가 복잡하기 때문에 이를 수정하기 보다는 그냥 가져다 쓰려는 사람이 더 많을 것이다. 하지만 RoR은 더 복잡해지면 그렇지 않을 자신이 있을까? 내가 살펴본 Rails코드는 솔직이 쉽게 손대기가 어려운 매우 복잡한 코드였다. 플러그인 개념으로 기능을 추가하는 것은 가능하다고 해도 과연 RoR프레임워크 자체를 변경해서 쓸 수 있는 사람이 얼마나 되겠는가? 자바쪽도 마찬가지기는 하다. 그러나 그들은 그저 만들어주는 프레임워크를 무비판적으로 쓰기만 하지 않는다. 얼마나 많은 사람들이 커뮤니티를 통해서 아이디어를 내고 이를 개선하고 패치를 제공하고 또는 부가적인 기능을 가지는 프로젝트를 만들어 이를 발전시켜왔는지 DHH는 정말 모르는걸까? C는 가장 생산성이 떨어지는 대표적인 언어이다. 하지만 지금도 수많은 C로 개발된 애플리케이션이 다양한 OS에서 동작하는 방식으로 끊임없이 만들어져 우리가 쓰는 핵심적인 OS와 애플리케이션의 대부분을 차지하고 있다. 그럴 수 있는 배경에는 언어가 가진 기본적인 장벽을 극복하기 위해서 오랜시간동안 끊임없이 연구되어진 많은 전략과 툴과 도구와 숙련된 개발자 그리고 커뮤니티가 있기 때문이다. 툴과 언어의 막강함 만으로 Ruby/RoR이 자바를 쉽게 따라잡기는 그래서 어려울 것이다. 배포할 애플리케이션/웹서버의 최적화된 환경을 찾느라고 지금도 삽질을 하고 있는 RoR을 보면서 초기에 성능좋고 쓸만한 웹/애플리케이션 서버하나 없어서 웃음거리가 되던 J(2)EE의 모습이 떠오른다.

Related posts:

  1. Google App Engine for Java에서 Spring 3.0 사용하기
  2. 유쾌한 이슈처리 재촉 메일
  3. Ruby와 Ruby On Rails

Facebook comments:

to “Java와 생산성”

  1. Why Not Try This Out
    [url=http://fakebootsonsale.com]fake uggs boots[/url]
    fake uggs boots

  2. Browse Around THESE Guys
    [url=http://fakebootsonsale.com]fake ugg boots for sale[/url]
    fake ugg boots for sale

  3. swissmasai Java와 생산성 » Toby’s Epril

Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

© 2017 Toby's Epril Suffusion theme by Sayontan Sinha