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

Notice

2011.10.17 08:31 개발관련
어디를 보든, Roo 에 대한, 최대 장점은 생산성이 아주 높아진다는 것에 있다. 처음 접할때 가장 눈에 띄는 것도 그점이다. 한두줄의 명령어로 엄청난 소스코드를 생성해 버리니까 그럴만한 강력한 인식이 생겨나는것도 무리가 아니다. 그러나, 생산량의 엄청난 증가가 생산성 향상에 관련이 있을까? 생산성에 대한 정의를 잘~ 해보면, 약간 다른 관점으로 볼수 있다. 생산성에 대한 정의는 사람마다, 조직마다 다를수 있다. 적어도 나는 단순한 생산량의 증가가 생산성 증가를 가져다 준다고 생각하지 않는다.


그럼 Roo 에서 말하는 생산성은 어떤 관점일까? 그것은 생산량에 대한 관리의 용의성이 높이는 것을 하나의 생산성의 관점으로 본것이라 생각한다. (정확히 한 관점이지 모든 것을 뜻하는게 아니다. 적어도 품질관점에 관해서는 언급하지 않았으니까...) 그러니까, 단순히 모든 관점에서의 생산성을 높여준다고 이해하기 보다는, 특정한 측면에서 생산성을 높여준다고 생각해야 하는데, 그게 단순히 코드량를 뜻하진 않는다는 것을 강조하고 싶은것이다. Roo 하면 그런 코드량 때문에 생산성 이야기가 화두인데, 그것이 핵심이 아니라는  것이다. 무엇이 핵심일까?


'생산량에 대한 관리의 용의성'은 복잡성과도 관련되어 있다. 복잡성은 생산성과도 관련되어 있고...어쨌든, 저 문장에 집중해 보면, 아니 풀이해 보면, Roo에서 생산한 소스코드에 대해 관리를 잘한다는것이다. 관리를 잘 한다는것이 바로 핵심이다. 


생성되는 코드는 특정한 기준으로 분리되어 있다가 조합 되어진다. 마치 레고 블럭과도 같다. 이것이 주는 장점은 무엇일까, 이것은 우리가 객체를 클래스 단위로 분리하는 이유와 비슷하고, 패키지(네임스페이스) 단위로 분류하는 것과도 비슷하며, Layered Architecture와도 비슷하다. 우리는 이런것으로 부터 많은 이점을 얻는다. Roo는 그것을 클래스 단위까지 적용시킨 것이다. 너무 비약일지 모르지만, 단순이 세부 기술인 ITDs를 이용했다느니, finder 같은 엑티브 레코드 패턴 구현체로만 인식하기엔 서운함이 있다.


결과적으로 Roo 에서의 생산성 극대화는 소스코드의 생산량의 극대화가 아니라, 관심의 분리(SOC)로 인한 복잡성 관리의 극대화를 노리고 있는게 합당하다.



'왜 이렇게 보고 있는가'에 대한 다른 도움말로는, '도메인주도개발(DDD)' 과 '소프트웨어 복잡성'에 대한 사전 이해가 도움이 될텐데, 나는 이 두가지에 대해 설명할수 있을 정도로 이분야에 대해 아는게 없다. 인터넷에서 관련해서 좋은 글을 본적이 있는것 같은데, 어디서 봤는지 알수 없다.(어쩌면 책에서 봤는지도 모르겠다)



저작자 표시
신고
posted by Max.
2011.10.12 09:13 신변잡기
'언제까지 개발을 할수 있다고 생각하세요?' 라고 질문하는 사람에게 선듯 답하지 못했다. 의도를 알수 없는 질문에 답하는건 무리가 따른다. 보통 이럴땐, 어떤 의도인지 조심스레 다시 질문하게 된다. 그러나 질문의 의도와 상관없이 이 질문 자체가 나에게 많은 생각꺼리를 안겨주더라. 뒤를 돌아보고, 앞으로 어떻게 가야 할것인지 고민하게 말들어 버린 것이다.

이제 내 생각의 공상 세계에서, 이 질문은 질문자의 의도나 답변의 fact와 상관없이 내 삶에 대한 질문이 되어 버렸다. 삶에 대한 질문엔 답변 보다는 질문 그자체로 두는 것이 더 현명하다. 소위 인문학이란게 그런거 아닌가... 하하하


나는 개발을 즐긴다고 할수 없다. 살다보니 개발 밖에 할줄 아는게 없어서 이제 빼도 박도 못한 지경이 되어버린것이다. 그나마 아는게 개발관련 이야기들 뿐이다. 그래서 개발 이야기가 나오면 반가워서 즐거울 뿐이다. 단순히 내가 하는일에 대한 이야기가 반가울 뿐인 것이다.  나는 이런 반가움에 기한을 두고 싶진 않다. 하지만 질문에서 '언제'라는 기한은 여러가지 의미로 그려질수 있다. 타의든 자의든 언젠가는 이일을 할수 없다. 아무리 길게 하더라도 명이 다 할땐 할수 없을 테니까...


아마도 질문에서 기한은 자의적인것 보다 타의적인 것을 고려했을 것이다. 우리나라의 개발자 정년을 고려해서 질문했을 것이라 추측된다. 내가 벌써 그런 나이게 되었다는 반가움(?)을 뒤로 하고더라도, 앞으로 어떻게 할것인가에 대한 희망 보다, 지금까지 어떻게 해왔는지가 도무지 기억나지 않는다. 뭘했지? AS IS 가 없으니 TO BE를 어떻게  그리냐는 말이지...


'언제까지 개발을 할수 있다고 생각하세요?' 라는 질문에 답하기엔, 내 정서가 너무 메마른 상태이고, 지금이 10월이라 것이 문제인것 같다. 위인전이나 하나 주문해서 주말 독서 여행이나 한번 다녀 오고 싶다...

 
저작자 표시
신고
posted by Max.
TAG 미래,
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.
prev 1 next