첫번째 강의인 'Spring-Test-MVC프로젝트 소개'는 부담없이 실무에서 적용해도 될만한 편리한 프로젝트인것 같다. web MVC를 테스트하는게 여간 귀찮은 작업이 아닌데, 빌더패턴을 이용한 테스트 방법이 인상적이다. 빨리 스프링 코어 프로젝트에 포함되었으면 좋겠다. 포함되지 않아도 선행 학습하여 Controller 구현을 빠르게 할수 있도록 하면 좋을듯 하다.
두번째 강의인 '스프링 3.1의 @Enable 기법을 활용한 설정 모듈화의 재사용 기법'는 정말 환상적이다.
이만한 강의를 한국어로 들을수 있다는게 정말 행운이 아닌가 싶다. 단순히 @Enable* 를 소개한것에 끝나는게 아니라, 현재 스프링 소스에서 적용하여 사용한 것까지 분석해서 그 통찰을 기반으로 모듈화 전략까지 이야기 하고 있다. 가만히 들어보고 생각해 보면, 이것이 뜻하는 그 가능성과 다양성을 대단히 크다.
내가 실로 오랫만이다. 이런 가능성에 전율했던 기억은 Spring Roo의 ITDs 기술 이후 처음이다(물론 그전에 AOP, @Configurable, DDD, @Hibernate 등 대충 여러개 있긴 하다). 현재 ITDs 기술이 내 학습 대상이듯, 이 @Enable*도 지속적인 학습 대상이 될듯 하다. 앞으로 시간이 허락하는 한 여러가지 기법들을 테스트해 보고 적용하기 위한 노하우를 쌓아야 겠다는 생각을 하게 된다.
아직 안보신 분들은, 다른 어떤 유료 강의나 책을 사보시기 전에 들어 보길 권한다. 지금 스프링에 어떤 디자인패턴을 적용할까 고민하는것 보다 중요한 영감을 받을수도 있으니까...짤리기 전에 어섯!...
어렸을땐 별로 못느꼈는데, 요즘 새삼 우리 부모님이 대단한 분이란걸 느낀다. 한 일화를 들어 보면, 우리가 살았던 시골 마을의 집을 들수 있다.
처음 부모님은 결혼후 할아버지 집 셋방에서 살다가 얼마 안되서 동네 다른집 셋방으로(한칸있는방) 분가 하셨는데, 할아버지가 분가를 못마땅하게 생각하시고 회방을 놓으셨다.
고생 끝에 조그만한 땅을 사서 집을 짖기로 했는데, 돈이 없으니, 모래나 나무를 구할수 없어서, 짚과 흙으로 벽돌을 만드시고, 산에 가서 소나무들 베어와서 기둥을 만드셨다. 짚으로 지붕을 덥고, 신문지로 내벽을 쌓았다.
이렇게 해서 우리집이 탄생했고, 지금도 그 집을 사용하고 있다. 물론 여기저기 수리해서 옛날 자제는 거의 없는 수준이지만, 집터는 그대로 이다.
이렇게 맨손으로 아버지, 어머니 두분이서 손수 만든 집이다. 아무리 먹고 살기 위해서라도 집을 지을 생각을 하고 실천했다는게 정말 대단하다. 집규모도 그때를 당시를 생각하면 상당히 크다. 부엌까지 방이 4개나 되니 말이다. 건너방은 나중에 짖은 것이다. 건너방 집은 3개도 되어 있다. 식구들이 많아서 더 지은 것이다.
유독 많은 일들이 안밖으로 있었던 2011년을 뒤로 하고, 2012년이 시작되었다. 썰을 풀 필요 없이 바로 목표를 다짐한다. 올해는 XXX 서비스를 XXX 기술로 만들어 세상에 내놔 봐야 겠다. 물론 지겹도로 했던, 다른 회사의 작품이 아닌, 내 의지에 의해 서비스 되는 것으로 말이다. 올해는 그것을 위한 수많은 데코레이션들의 연속일 것이다. 그럼 자~ 시작해 보자~... 화이팅!!! :)
- 합리적인 눈으로 합리적인 세상을 바라 보고자 하면, 합리적이지 않은 것이 더 많이 보이고, 합리적인것은 눈꼽만큼 보일까 말까 한다. 반대로, 합리적이지 않은 눈으로 합리적인 세상을 바라 보고자 하면, 합리적이지 않은 것이 합리적으로 보일 뿐만 아니라, 합리적인것은 비합리적으로 보인다.
- 현실에서는 적당한 합리성, 아니 좀더 선택 가능한 타당한 것을 찾아야 하는데, 어느순간 그 둘의 경계가 모호해 진다. 적당히 타당한 선택은, 합리적인것과는 거리가 멀다. 그반대도 같은 논리다. 오히려 자의적인 해석에 위안을 느끼는 어떤 것을 찾는게 맞겠다.
- 위와 같이 이런, 저런 상황에 대한 해석들이 내 자신의 자의적인 기준으로 타당성과 합리성을 주장하게 된다. 이런 주장에 대해서 '맞고, 틀리고' 를 생각하진 마라. 무의미 하다. 상황논리는 언제나 그럴싸한 논리다. 정해진 해법이 존재하지 않는 것들, 사회성 지식들도 이와 비슷하다. 어떨 때는 그런 지식들을 누군가가 판결하려 들지만, 소용없는 짓이다. 이런 것들은 정신분석과 비슷해서 일반 사람들에겐 '불가해한 지식'일 뿐이다. '모르는것에 대한 숭배자'가 아닌 한 그런 것에 시간을 소비할려고 하면 끝이 없다. 할 필요도 없다. '모르는것 = 신비한것' 은 아니니까.
Define value for property 'groupId': : net.max.test
Define value for property 'artifactId': : max-test
Define value for property 'version': 1.0-SNAPSHOT: : 1.0.0-SNAPSHOT
Define value for property 'package': net.max.test: : <Enter> or net.max.test.sample
5) Test 확인
- IDE에서 import하고, 예제 Unit Test를 돌려서 확인한다.
덤)
- 만약 원격 저장소에 넣고 싶다면, 3)에서 deploy 하고, 4)에서 -DremoteRepositories={repository url} 을 추가 하면 된다.
- 4)번 명령어가 복잡하다면, mvn archetype:generate -DarchetypeCatalog=local 로 단순하게 할수도있다.
어디를 보든, Roo 에 대한, 최대 장점은 생산성이 아주 높아진다는 것에 있다. 처음 접할때 가장 눈에 띄는 것도 그점이다. 한두줄의 명령어로 엄청난 소스코드를 생성해 버리니까 그럴만한 강력한 인식이 생겨나는것도 무리가 아니다. 그러나, 생산량의 엄청난 증가가 생산성 향상에 관련이 있을까? 생산성에 대한 정의를 잘~ 해보면, 약간 다른 관점으로 볼수 있다. 생산성에 대한 정의는 사람마다, 조직마다 다를수 있다. 적어도 나는 단순한 생산량의 증가가 생산성 증가를 가져다 준다고 생각하지 않는다.
그럼 Roo 에서 말하는 생산성은 어떤 관점일까? 그것은 생산량에 대한 관리의 용의성이 높이는 것을 하나의 생산성의 관점으로 본것이라 생각한다. (정확히 한 관점이지 모든 것을 뜻하는게 아니다. 적어도 품질관점에 관해서는 언급하지 않았으니까...) 그러니까, 단순히 모든 관점에서의 생산성을 높여준다고 이해하기 보다는, 특정한 측면에서 생산성을 높여준다고 생각해야 하는데, 그게 단순히 코드량를 뜻하진 않는다는 것을 강조하고 싶은것이다. Roo 하면 그런 코드량 때문에 생산성 이야기가 화두인데, 그것이 핵심이 아니라는 것이다. 무엇이 핵심일까?
'생산량에 대한 관리의 용의성'은 복잡성과도 관련되어 있다. 복잡성은 생산성과도 관련되어 있고...어쨌든, 저 문장에 집중해 보면, 아니 풀이해 보면, Roo에서 생산한 소스코드에 대해 관리를 잘한다는것이다. 관리를 잘 한다는것이 바로 핵심이다.
생성되는 코드는 특정한 기준으로 분리되어 있다가 조합 되어진다. 마치 레고 블럭과도 같다. 이것이 주는 장점은 무엇일까, 이것은 우리가 객체를 클래스 단위로 분리하는 이유와 비슷하고, 패키지(네임스페이스) 단위로 분류하는 것과도 비슷하며, Layered Architecture와도 비슷하다. 우리는 이런것으로 부터 많은 이점을 얻는다. Roo는 그것을 클래스 단위까지 적용시킨 것이다. 너무 비약일지 모르지만, 단순이 세부 기술인 ITDs를 이용했다느니, finder 같은 엑티브 레코드 패턴 구현체로만 인식하기엔 서운함이 있다.
결과적으로 Roo 에서의 생산성 극대화는 소스코드의 생산량의 극대화가 아니라, 관심의 분리(SOC)로 인한 복잡성 관리의 극대화를 노리고 있는게 합당하다.
'왜 이렇게 보고 있는가'에 대한 다른 도움말로는, '도메인주도개발(DDD)' 과 '소프트웨어 복잡성'에 대한 사전 이해가 도움이 될텐데, 나는 이 두가지에 대해 설명할수 있을 정도로 이분야에 대해 아는게 없다. 인터넷에서 관련해서 좋은 글을 본적이 있는것 같은데, 어디서 봤는지 알수 없다.(어쩌면 책에서 봤는지도 모르겠다)
'언제까지 개발을 할수 있다고 생각하세요?' 라고 질문하는 사람에게 선듯 답하지 못했다. 의도를 알수 없는 질문에 답하는건 무리가 따른다. 보통 이럴땐, 어떤 의도인지 조심스레 다시 질문하게 된다. 그러나 질문의 의도와 상관없이 이 질문 자체가 나에게 많은 생각꺼리를 안겨주더라. 뒤를 돌아보고, 앞으로 어떻게 가야 할것인지 고민하게 말들어 버린 것이다.
이제 내 생각의 공상 세계에서, 이 질문은 질문자의 의도나 답변의 fact와 상관없이 내 삶에 대한 질문이 되어 버렸다. 삶에 대한 질문엔 답변 보다는 질문 그자체로 두는 것이 더 현명하다. 소위 인문학이란게 그런거 아닌가... 하하하
나는 개발을 즐긴다고 할수 없다. 살다보니 개발 밖에 할줄 아는게 없어서 이제 빼도 박도 못한 지경이 되어버린것이다. 그나마 아는게 개발관련 이야기들 뿐이다. 그래서 개발 이야기가 나오면 반가워서 즐거울 뿐이다. 단순히 내가 하는일에 대한 이야기가 반가울 뿐인 것이다. 나는 이런 반가움에 기한을 두고 싶진 않다. 하지만 질문에서 '언제'라는 기한은 여러가지 의미로 그려질수 있다. 타의든 자의든 언젠가는 이일을 할수 없다. 아무리 길게 하더라도 명이 다 할땐 할수 없을 테니까...
아마도 질문에서 기한은 자의적인것 보다 타의적인 것을 고려했을 것이다. 우리나라의 개발자 정년을 고려해서 질문했을 것이라 추측된다. 내가 벌써 그런 나이게 되었다는 반가움(?)을 뒤로 하고더라도, 앞으로 어떻게 할것인가에 대한 희망 보다, 지금까지 어떻게 해왔는지가 도무지 기억나지 않는다. 뭘했지? AS IS 가 없으니 TO BE를 어떻게 그리냐는 말이지...
'언제까지 개발을 할수 있다고 생각하세요?' 라는 질문에 답하기엔, 내 정서가 너무 메마른 상태이고, 지금이 10월이라 것이 문제인것 같다. 위인전이나 하나 주문해서 주말 독서 여행이나 한번 다녀 오고 싶다...
나는 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 여기를 참조해 보자.)
max-roo.zip
