블로그 이미지
Max.

calendar

        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Notice

2009.12.08 16:46 개발관련
배경
항상 새로운 기술을 처음 실무에 적용할때는 떨립니다. 알고 있는 지식의 한계에 대한 불확실성과 어떤 경우가 발생할지 몰라서 처음 부터 다시 시작할 각오를 해야 하는 두려움이 공존해서 말이죠. 가끔은 이런 수고까지 하면서 이래야 하는가 하는 의구심이 들때가 한두번이 아니죠. 그냥 그동안의 얄팍한 지식으로 진행해도 별무리 없으니까요.

그런데 저같은 공상논자는 무리한 도전을 즐기는면이 있어서, 이번에도 그런 기질이 작용했지 않나 싶습니다. 어쨌든 아직 정식 릴리즈도 되지 않은 Spring Roo로 프로젝트를 진행했습니다. 다행히 개발 기술적인 것은 저 혼자 해야하는 좋은(?) 경우여서 시도하게 되었던것 같습니다.(사실 혼자가 아니면 사용할 엄두도 못내었을지도 모르죠)


진행
여차 저차 해서 프로젝트에 대한 컨셉과 프로토타입 문서가 나왔고, 디자인 및 Html까지 나왔습니다. 이제 개발하여, 보여주면 되는 상황인거죠. 대략 결과적으로 생성된 테이블수는 40여개가 되었고(개발하는 도중에는 테이블에 거의 신경쓸 일어 없었습니다.), 도메인 객체 모델링 및 Controller까지 구현은 2주 정도 걸렸습니다. 사실 비지니스까지 걸리는 시간의 대부분은 Roo에 대한 사용법이 미숙해서 걸리거나, OOP 개념 특히 Hibernate에 대한 미숙함으로 걸리는 시간이 대부분이 이였고, 순수 코드 작성에 걸리는 시간은 2일도 안되는것 같습니다. 그만큼 CURD 및 Finder에 대한 구현 자체의 시간의 거의 없었고, 그 Action에 '무엇이 담겨야 하고, 무엇과 연관되어야 하는가'가 많은 시간을 허비하게 했는데, 이것은 개발자에게 말 그대로 도메인에 집중하게 하는 효과를 내지 않았나 하는 생각 입니다.

총 프로젝트는 대략 한달 정도 걸렸는데, 대부분의 시간은 UI 즉,  Html로 된 디자인 파일을 적용하는  것에 시간을 허비하게 되었습니다. 이부분은 사용자 화면과 관리자 화면으로 나누는데, 사용자화면은 디자인이 적용되니 어쩔수 없다고 치더라도, 관리자 화면 역시 시간이 많이 소비되었는데, 이유는 Spring JS(Dojo)를 그대로 사용하지 못했고(IE에서의 스크립트 오류), 다 제거하고, 타일즈도 역시 제거하는 과정(SiteMesh 적용)에서 UI는 Roo의 혜택을 거의 받지 못하게 되었던것 같습니다.

어쨌든, 결과적으로 Roo를 사용하는 것은 프로젝트 시간을 단축하는 효과를 볼수있었습니다. UI 부분은 아직 상당한 부분 응용하기 어려웠고(아마도 이것은 저의 도메인 환경에 대한 제약 때문일 것입니다.), 도메인 변경(필드추가,관계 설정/변경 등)은 어렵지 않았습니다. 하지만, 관계들이 많아져서 복잡해 지니까, 전체적인 그림을 그리는(비주얼한) 무언가가 있어야 할것 같다는 생각이 들었습니다. Roo 는 DB 테이블 구조 보다는 관계 구조를 먼저 떠오르게 하는데, 그 관계를 비주얼하게 볼수 있으면, 전체적인 소스코드 분석에 도움이 될것 같은데, 그것을 보여주는 것이 없어서, 객체 설계자가 아니면, 이해하기 힘들수도 있겠다 하는 생각을 했습니다.


결론
저는 이번 작업을 통해서 Roo는 실무 적용에 문제가 없다는 것입니다. 특히 도메인이나 비지니스 이하 계층에서는 말이죠. Service나 Facade 같은게 없다고 해서, 너무 단편적일 것이라고 생각할수도 있지만, 필요하면 만들어 적용할수 있으니, Roo 때문에 무엇은 안되는거 아닌가? 하는생각은 좀더 고민을 해보시고 판단하는것을 조심스럽게 권합니다. 사실 이번 프로젝트에서도 Service 는 거의 작성하지 않았습니다. 외부로 유출되어야 할 메서드(DWR, Spring BlazeDS Integration 관련)만 작성 했지요. 신기하게도 Roo를 사용하면, Roo에 집중하는게 아니라 Roo 이외의 부분에 집중하게 만들어 줍니다.

( 개발 도중 Version 캡쳐)

앞으로
최근 저의 직업적 환경 변화가 주로 개발에 대한 관리를 하게 되는데, 시간이 허락하는 한 소규모 개발을 진행하려고 합니다. 이번에 또다른 개발을 하게 될것 같은데 역시 Roo 사용해볼까 합니다. 이번 개발에서는 Roo가 기술적 이슈가 아니라 Flex 입니다. 늦게 배운 도둑질이 밤새는줄 모른다고, 최근에 제마음을 흔들어 놓은 것 중에 하나가 Flex 입니다. 이번 프로젝트는 좀더 SI적인 냄새가 날것 같은데, Flex와 Roo 이용한 개발이 재미 있을것 같습니다. 

Spring Roo에 대한 소감을 한마디로 요약하면,
"빠르게 Rich 도메인을 실무에 적용할수 었어서 좋았다."
입니다.  잊지 말아야 할것은  Roo는 그냥 툴이라는 것입니다. 은총알을 기대하진 말아야 합니다.
저작자 표시
신고
posted by Max.
TAG , ,

티스토리 툴바