Community
2월 1일자로 조직 개편이 되면서 프로토타이핑을 담당하는 조직을 맡게 되었다. 새롭게 진행하는 업무가 기획자의 요청에 따라 발빠르게 프로토타이핑을 할 수 있어야 하기 때문에 최대한 빨리 대응할 수 있는 기반을 만들기 위한 준비 작업을 하고 있다. 처음 개발 작업을 위한 기반 프레임워크로 Ruby on Rails, Grails, Spring Roo 세 개가 물망에 올랐다. 각각에 대하여 개발 편의성, 학습 비용, 프로토타이핑 팀 개발자 및 사내 개발자들의 지식 수준, 향후 실 프로젝트에 적용할 때의 적용 가능성 등을 고려해서 Spring Roo로 진행하기로 잠정적으로 결정하고 준비하고 있다. 이에 대한 더 자세한 내용은 같이 일하고 있는 꿈꾸는 개발자님이 더 자세하게 부연 설명 해주리라 생각한다.
직접적인 기반 준비 작업은 꿈꾸는 개발자님이 진행하고 있지만, 옆에서 지켜보면서 느끼는 Spring Roo에 대한 감정은 일단 긍정적이다. 우리는 Spring Roo의 UI 관련 기능은 제외하고 Entity 영역만 사용하기로 결정했다. 포털의 성격상 UI에 대한 변화나 요구가 많고, Spring Roo를 통하여 생성되는 JSP가 만족스러운 수준은 아니었다. Spring Controller까지 자동 생성하고 싶었지만 Ben Alex에게 문의한 결과 Controller만 단독으로 생성할 수는 없다고 한다. Spring 3.0으로 버전업 하면서 @MVC가 잘 만들어져 있어 Controller 만들기는 어렵지 않게 해결하고 있다. 이후 이 작업이 귀찮으면 Controller만 생성할 수 있는 add-on을 하나 만들어도 좋을 듯 하다.
Spring Roo를 적용하면서 가장 만족할만한 부분은 코드 생성 방식이다. Introduction To Spring Roo 1.0.0 문서에서도 설명하고 있지만 Passive Generation과 Active Generation을 모두 지원하고 있다는 것이다.
이 같은 코드 생성 방식은 roo shell을 이용하여 소스 코드를 생성하는 것도 가능하지만, 도메인 모델 클래스를 직접 변경하더라도 관련된 aj 소스가 자동으로 변경되는 것을 확인할 수 있었다. 예상하지도 못했던 부분까지 고려해서 개발되었다는 것을 보고서 놀라지 않을 수 없었다. 이 같은 기능을 지원하기 때문에 JPA Annotation과 Validation Annotation만 알고 있다면 굳이 roo shell을 사용하지 않고 도메인 모델 클래스에서 직접적인 수정이 가능하다. 이 같이 동작하는 방식에 대해서는 Spring Roo 1.0.0 Technical Deep Dive 문서에서 좀 더 구체적으로 파악할 수 있다.
아직 add-on까지 만들어 보지 못하고 Spring Roo에서 제공하는 샘플 add-on 프로젝트를 생성하고 배포해 봤는데 생각보다 쉽게 개발할 수 있을 듯 하다. 이미 add-on을 쉽게 개발할 수 있도록 roo shell에서 샘플 프로젝트까지 제공하고 있어 이 프로젝트를 참고해서 만든다면 어렵지 않게 개발하는 것이 가능하리라.
이 참에 지난 번에 만들었던 Spring Batch Monitoring System을 Spring Roo 기반으로 만들어보면 어떨까라는 생각을 했다. "Spring Batch Log야 단순 조회용도니까 지금처럼 Spring Jdbc 기반으로 개발하면 되고, 그 외의 User, Role, 통계 기능에 대해서는 Spring Roo를 적용가능하지 않을까?", "기존 Legacy Project에 Spring Roo를 적용하기 어렵지 않을까?"라는 생각으로 시도해봤는데 생각보다 쉽게 Spring Roo를 통합할 수 있었다. 물론 아직까지 기존 Legacy 테이블까지 매핑해서 개발하는 단계까지는 가지 않았지만 기존 Legacy Project에 쉽게 통합해서 일부만이라도 Spring Roo 기반으로 개발하는 것이 가능하다는 것을 확인할 수 있었다. Spring Roo에서 강조해서 이야기하고 있듯이 Spring Roo는 상당한 유연성을 가지고 있다는 생각이 들었다.
아직 프로토타이핑 업무에 직접 적용한 단계는 아니고 준비 단계이지만 만족할만한 수준이라고 생각한다. 사내 프로토타이핑 업무와 Spring Batch Monitoring System에 적용해 나가면서 Spring Roo의 허와 실에 대해서 지속적으로 공유해보도록 하겠다.
Comments (2)
2월 19, 2010
Anonymous says:
재훈입니다. SpringSource가 이미 Grails를 가지고 있는데, Roo를 런칭하는 건 왜일까요? 아마 회사의 규칙에 의해 Grails를...재훈입니다.
SpringSource가 이미 Grails를 가지고 있는데, Roo를 런칭하는 건 왜일까요?
아마 회사의 규칙에 의해 Grails를 사용할 수 없는 상황 때문이 아닐까 생각합니다.
Groovy 같은 언어를 제대로! 알지 못하면 막연히 이런 생각을 가지기 쉽습니다.
이것은 곧 Groovy/Grails가 큰 회사에서 쓰이지 못하는 적절하고 타당한 이유가 됩니다.
Roo는 컴파일타임에 AJ를 적용하고 기존 도구들을 사용하니 회사 입장에서야 거부할 이유가 없죠.
위에서 보면 결국 Java, Maven이니까요. IDE 지원도 SpringSource Tool Suite로 되구요.
개인적으로는 SpringSource가 하나만 선택해서 밀었으면 하는데, 생각해보니 이런 이유 때문에 의미가 없는 것도 아니라 생각합니다.
Roo도 많은 발전하길 바랍니다.
ps. 이전에 쓰신 조직 세분화에 대한 문제점에 관한 포스팅도 잘 읽었습니다.
트랙백을 걸려고 글을 쓰다가...
글을 잘 정리해서 쓰는 필력도 딸리고 '이런 거 내가 써보니 무엇 하나. 어차피 변하는 것도 없는데. 내 자신이나 잘하자.' 이런 생각에 도중에 취소했습니다.
하여튼, 형님 글 재밌게 잘 읽고 있습니다.^^
댓글은 안달아도 열심히 보고 있는 사람 1명 여기 있답니다.
2월 19, 2010
Anonymous says:
로드 존슨이 직접 발표한 자료를 보니 Grails와 Roo사이의 가이드맵도 있더군요 ( http://jaoo.dk/aarhus-2009/file...로드 존슨이 직접 발표한 자료를 보니 Grails와 Roo사이의 가이드맵도 있더군요
( http://jaoo.dk/aarhus-2009/file?path=/jaoo-aarhus-2009/slides/RodJohnson_ExtremeJavaProductivityWithSpringRooAndSpring30.pdf )
benelog
Add Comment