블로그 이미지
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

2011.10.11 17:28 개발관련
나는 Spring Roo을 다양한 관점에 바라볼 필요가 있다고 생각한다. 혹자는 DDD 관점에서 Roo에 대해 툴 관점의 특징만 비교하기도 한다. 분명히 잘못되었다. 태생의 루와 지금의 루가 형식이 다르더라도 철학은 함께하고 있다고 믿기 때문이다. 어쨌든 그것은 나중에 이야기 하자. 이제, 루에 대해 툴 관점에서 바라보고 이야기해 보자.


제목의 복잡하다는 것과 단순하다는 것에 대한 정의가 모호하지만, 일반적인 웹 프로젝트라고 할수 있는 것에 적용이 불가능할것이라는 생각이 지배적인것 같다.  이유는 가끔 뻑이 나는 빌드 스크립트와 다양한 도메인에 맞게 자동생성되어야 하는 소스코드의 기능이 안전하게 제공되지 않는것에 대한 불안감에서 나오는 것이다. 즉, 입맞에 맞게(다양한 환경에 적응 가능하게) 제대로 실행되는걸 기대하기 어렵기 때문인것 같다. 그래서 아주 단순한 웹사이트나 가능한 툴로 인식해버리려 할것이다. 아마도 원하는 기대는 완전한 소스코드가 생성되고, 어떤 도메인이든, 어떤 경우에도 알맞게 코드가 생성되어야 만족할만한 툴로 인식할 것이다.

내 생각에 아마도 위와 같은 기대를 채워줄수 있는 툴은 세상에 나올수 없다. 설령 기술적으로 가능하더라도 지향해서는 안될일이다.

몇가지 의문을 품어 보자. Spring Roo는 무엇일까? 어떻게 세상에 나왔나?, Spring Roo가 왜 addon 기반으로 발전할수 있게 구성 하였을까(단순히 OSGi를 지향하기 위해서는 아닐것이다)?, Spring Roo 커뮤니티가 활발한 이유는 무엇일까?...



특정 도메인의 뼈대가 되는 구조는 그 도메인 특성이 반영되야 한다. 같은 RESTful 기반의 시스템도 특성에 따라 하부 주조가 너무나 다양하게 구성될수 있다. 또한 특정기능에 대한 공통기능도 다 차이가 있을수 밖에 없다. Spring Roo는 그런 뼈대 구조와 반복적인 기능을 효과적으로 제공할수 있는 기틀을 마련해 주는 것이다(이것이 의미하는 것은 무엇인가). 따라서 기본 addon을 수정할수 있어야 하고, 필요에 따라 추가적인 addon을 만들어 낼수 있어야 한다. 그렇치 못한다면, Roo는 실무 프로젝트에서 사용할수 없은 교육용 툴에 지나지 않는 것이다. 


Roo에 대한 특징 중 소스코드 생성 때문에 생산성이 상당히 향상되리라 믿는 사람도 있다. 하지만, 생산량이 많을진 몰라도 생산성이 그리 높지는 않다. 이부분도 나중에 한번 이야기해 보자...

(초창기 Roo에 대한 토비님이 남겨 놓은 귀중한 자료도 있다.  http://toby.epril.com/?p=346 여기를 참조해 보자.)
저작자 표시
신고
posted by Max.

티스토리 툴바