정말 공감가는 글이로군....
책으로 해결하려고 하면 결국은 사람이 하는 일이기에 가변이 너무 많다.
틀은 있지만 컨텐츠는 다시 채워야 한다는.......

ORM is a good solution for legacy databases when the schema
 -- Is highly normalized
 -- Has primary keys
 -- Has foreign key relationships referring to primary keys, not columns

나의 막강한 저항... 그러나 어떠한 것은 받아 들어야 한다는거....

이 GAP 이 Relational model에서는 unique identifer column 으로 구분....된다 ( 상속도 있고 다른것도 많지만 )
차이는 이것에서 시작이 된다.

오픈소스 자료를 정리 중이다.
음... 내일 가서 발표 잘해야 할텐데....
이것이 가지는 특별한 의미도 잘 설명해야 할텐데...다만 학회의 교수님들이 나의 취지를 많이 이해하시고.... 좀더 상위레벨의 정책자들에게 내 문서를 전해주셨으면 좋겠다.

JBoss가 레드헷에 인수 되었고 우리나라 D회사가 이것에 대한 기술지원을 적극 하겠다고 라이센스를 맺었지만...국내 사례에서 모 통신사를 제외하고는 사례가 없다.

이전에 내 친구 승권에게 한 이야기가 생각난다. 내가 컨설팅을 하게 되면 언젠가는 상위레벨에서 오픈소스를 전달하는 날이 올것이라고...했던.....
그러고 보니 승권이와 알고 지낸지 3년도 넘었네 이제....
그때의 열정이 지금도 나에게 남아 있기를 바라면서....


홧팅....

EA와 ISP를 통해 아키텍처를 고민한다면 개발부분까지도 고려해야 한다.
근 1년간 프로젝트를 하면서 항상 고민하는 부분이다.
플레닝 단계에서 레벨을 낮게 잡은 부분에 대해 개발업체는 항상 고민을 할 수 밖에 없다.
때문에 컨설팅을 하고 나면 개발업체/개발팀등등....는 무얼 해야 하는지 모르는 경우 태반....
그러다 보면 EA한 결과를 받아 들이고 싶지 않기에 또다른 플레닝을 하는 그런 모습들이 보인다.

이 갭을 채우려면 EA 컨설턴트는 낮은 단계까지 플레닝을 해야 하며 개발영역과 컨설팅 영역을 채우워야 하는 필요성이 생긴다. 그런데 상위레벨의 아키텍처와 구현레벨의 아키텍처의 갭을 메우기란 쉽지 않다.
EA는 Owner단계와 Planner단계에 집중을 하는 경우가 많고 Designer단계로 내려오면 설계부분에 대한 압박이 있기 때문이다. 디자인 단계까지 내려간다 하더라도 구현의 레벨로 들어서면 또 갭이 생긴다. 그러다 보면 의사결정을 위한 도구라는 냄새는 점점 사라지게 되는 것이다....이러한 이유로 EA는 실체가 없다는 말을 하는 사람들도 있었다.
그렇지만 상위단계의 플레닝이나 구도를 잡아주는 모습을 보여주는 역활로 본다면 아주 중요한 작업이지 않을 수 없다.

비지니스와 기술을 연결해주는게 아키텍트라면 이러한 단계를 연결해줘야 하는 사람은 누구인가? 아무도 없다???? T.T 결국은 아키텍트나 아키텍트 그룹이 이갭을 채워줘야 하는데
지금 내가 이 갭을 채우는 작업을 하고 있다. 서로 안하려고 발버둥 치는 경우도 있었다.

EA를 알아야 하며 이것을 분석하고 이것을 구현레벨까지 끌어내리는것이 나의 회사에서의 존재 목적인 것이다....
일을 하다 보면 상위레벨과 구현레벨의 차가 작지 않아 이러한 영역을 채우려면 많은 것을 알아야 한다. .....기술 , 디자인 말고도 알아야 할게 태반이다. 더군다나 아키텍트라면 코드레벨까지 알아야 한다. 이러한 경우라면 더더욱..... 뿐만아니라 EA의 상위레벨도 알아야 한다.
코딩을 직접 하지는 않더라도 상위레벨과 하위레벨을 연결하고 그들의 뷰로 설명을 할수 있는 문서와...언어등이 필요한것이다. 그냥 박스나 몇개 그리고 말꺼라면 또다시 그자리인것이다... 안하느니 못한 아키텍처정립인 것이다. 쯪....

게다가 상위레벨의 개념적인 생각들이 개발 영역으로 들어오면서 퇴색하는 경우도 있고 변경되는 경우도 있고..... 아키텍처에 대한 통합 관리가 필요한데 이러한것을 개발조직들은(현업은 다르다고 할수 있겠지만 전문지식성이 없기에 별 이견없음 ) 더군다나 알고 싶지 않아 한다. 이러한 것은 기업의 자산이 되는 경우가 많지만.... 별로 중요시 여기지 않는 경우가 태반.....

조직의 리더들이 생각하는 바가 많이 달라지는 경우도 있고....
심지어는 그들이 변절 ( ? ) 하는 경우도 있다. 그들의 생각이 서로 상충하여 조직에 분열이 생기는 경우도 있다.
어떻게 보면 기술때문에 생기는 문제도 문제이지만 사람때문에 생기는 문제가 더 많은 듯하기도 하고..... 거버넌스라는 말을 해야 하는 경우도 생기는 것이다.....

이러한 것이 내가 가지고 가야할 숙제... 인지도 모르지.... 음냐...뭐해먹고 살지 ??
 

토요일 아침엔 커피를 마신다. 종로에서 마신다.
토요일 아침의 커피향이 너무나 좋다. 그런데 나는...커피를 못마신다. 속이 매우 아픔..

내 블로그를 보시는 분중에 나와 함께 커피를 마시고 싶으신 분은 아침 일찍 종로로 오면 됨다...... 아마 웨이크업하기 힘드실 것입니다....

물론 나는 커피를 못마시기에 보통 석류주스나 혹은 다른 음료를 마신다. 주로 단호박 센드위치를 토요일 아침밥으로 먹는데 자꾸 먹으니까..좀 지겹기도 하고....ㅋ

오늘까지 OOAD를 본 진도는 100Page다. 다시 한번 느끼는 건데 가장중요한건 고객의 요구사항.... 이게 결론...T.T

ModelAndView()           Default constructor for bean-style usage: populating bean properties instead of passing in constructor arguments.

ModelAndView(String viewName)           Convenient constructor when there is no model data to expose.

ModelAndView(String viewName, Map model)           Creates new ModelAndView given a view name and a model.

ModelAndView(String viewName, String modelName, Object modelObject)           Convenient constructor to take a single model object.

ModelAndView(View view)           Convenient constructor when there is no model data to expose.

ModelAndView(View view, Map model)           Creates new ModelAndView given a View object and a model.

ModelAndView(View view, String modelName, Object modelObject)           Convenient constructor to take a single model object.

이건 조금더 복잡한 건데 저 모델이라는 놈이 가만히 보면 Object이다. 그런데 로드존슨은 왜 이놈의 이름을 ModelAndView라고 지었을까....?? 저 오브젝트에 이런 저런 클라스들이 다 들어가겠지...오라클의 탑링크...IBatis 등등등....

스프링에서 생각하는 모델을 스프링에서는 어떻게 정리 했을까...라는 생각이다. DTO, VO, Entity라 불리우는 객체들을 저 모델의 값으로 넘겨주는 경우에 대한 생각이다. 아는 사람은 알다 시피 하이버네이트 세션을 대략 이용하면 화면에서 비지니스를 처리 하는 겪이 된다. 이러한 가정은 DTD나 VO를 EJB에서 처럼 사용하지 않았다는 가정하에 가능하겠다. 뭐 내 생각이지만......
언젠가 하이버네이트를 보다가.... 이상한 오픈소스 프레임웍을 봤는데 테그라이브러리로 Hibernate를 제어하는 것이다. 결론적으로 보면 화면에서 바로 써버리겠다는 말인데....
그때는 이런 황당한걸 왜 만들지 하는 생각이 많이 들었다.  어이 없었다...그때가 2004 초던가 였는데...다분히 내 머리속엔 EJB적인 생각 ㅋㅋㅋ ( 반성중 ) EJB는 그렇게 코딩 안하기에 그렇다. 그러니까 문제....
왜냐면 Lookup때문에 많은 자원이 소비 되어 몇몇 프락시성 클라스를 넣어줘야 하기 때문이다. 만일 EJB가 아니었다면 나는 Struts나 다른 프레임웍을 안배우고 오히려 View관련 Framework에 관심을 기울였을것 같다.

이렇게 이야기 하면 결론적으로 c/s의 아키텍처가 되는데 c/s의 db연동과 다른게 없다라는 생각이 또 들었다. ....하여간 쓰잘떼깅 없기능ㅋㅋㅋ
그러나 Layer구조로 된 도메인 모델이라면 그리 염려는 안해도 될듯 하기도 하고...
Layer를 횡단하는 구조는 아직도 의문이다. 그런데 어쩌는 수 없이 횡당하는 경우가 생긴다는 것은 인정한다. 억지로 Layer 구조를 갖추기 위해 몇몇 아키텍처적인 더미 클라스를 넣는  패턴을 쓰기도 하지만.... T.T

토요일날 아침부터 쓰잘때기 없는 생각하고 있음....
도메인 모델링을 하게 되면 어쩌면 고질적인 DTD나 VO가 없어질지도 모르겠다는 생각이 조금들었다. 물론 없어지기는 힘들지도 모르겠다. 트렌젝션이나 세션문제가 그리 간단하지 않을꺼라는 생각이 들었기에 말이다..... 왜냐하면 사람들의 편견문제부터 시작이 될듯....
서비스의 시작이라는 그리고 그 서비스에 대한 트렌젝션까지 알아야 할것이다.
고려할게 많은 상황....

그런데 이렇게 하면 또 문제가 나중엔 도메인 모델링된 구현체에 화면의 로직이 섞을지도 모른다는 생각이 조금들었다. 또 상상력 발동중....도메인모델링 구현된 코드에 AOP섞으면...
음..... 멋지겠엄...ㅋㅋ

암튼 상상을 한 4시간 정도 하면서 토요일 아침을 보냈다.
그리고 나서 집에와서 와이프하고 영화 한편을 봤다. 영화 이름은

와이프는 보다가 잠들었음....ㅋㅋ 꼭 봐야 하는데....




http://movie.naver.com/movie/bi/mi/review.nhn?code=64354#01
보면 10점 만점에 까탈스런 우리나라 넷티즌이 9.11점 줬음...
음..어제보다... 0.3점 깎였네....ㅋ 9점이면 대단한 영화인데....

이 영화 정말 감동적인데 꼭 봐줘야 하는 영화다..가볍게 보고 억지로 감동받으려고 보려한다면 안보는게 좋고....귀여운 꼬마는 윌스미스의 친아들....
윌스미스가 연기를 정말 잘하네...ㅋ
영화보는 동안 계속 한숨을 쉬어야 했던 그 영화....
마지막 황제를 보고 눈물을 흐렸고..그 이후 그럴듯한 영화 안보였는데...이영화는...
음...

왜 저 포스터 보면 happyness라고 적었을까요 ?? 아시는분 ??
우리나라 말로 치면 행복을 향복이나 항복으로 적은건데....
영화자세히 보면 아실듯.....

ps : 영화는 크리스 가드너 라는 분의 실제 이야기인데...
본받아도 될 아름다운 사람의 이야기 이다. 나도 저런 의지를 가져야....
http://en.wikipedia.org/wiki/Chris_Gardner : 멋진사람
http://www.gardnerrich.com/ 차린 회사

이전에 오프라 쇼에 나왔을 때는 그런갑다 했는데 (영어를 다 이해 못해서)
사람들이 마구 마구 울어서 그냥 그런갑다 했는데... (이쑈 보면 눈물바다가 많아서)
영화와 위키를 보니 더 대단하시다는....

블로그에까지 논리적으로 적기 시작하면... 대강 끝내야....

어느날 갑자기 책이 보고 싶었다. 사는게 잼없어졌다고 생각되어서 인가?
요즈음 보면... 실력이 넘쳐나는 사람들이 많이 있다.
비록 내가 슈퍼맨은 아니지만...스스로에게 냉정해 지려고 많이 노력하고 있다.
가끔 인생에 테클을 맛나게 받아 먹어줘 버리지만.... (무시한다는...ㅋ)

몇년전부터 공부를 하면서 독특한 사람들을 많이 봐왔다. (최근엔 없음)
이론만 중요시하고... 정작 자기가 하는 일(직업) 은 뒷전인 사람들이 있었다.
유명하다고 초빙하면 프로젝트를 국수 말아 먹듯...하는 사람도 있었고...
서로에게 상처를 주는 사람도 있었다.

그 이론이 뭐냐고 되물으면 대답을 잘 못한다....이상하다....
네가 프로페셔널 이라면 절대 그렇게 행동하지 않을 것이라는 관리자적인 말을 그런 사람들에게는 해준다. ㅋ.... 절대 있어서는 안 될 일....이야..하면서...

어떤이는 나에게 실력이 좋다고 말하지만....
정작 나는 실력이 않좋은데 좋다고 말을 들으면 많은 생각이 든다.
상당히 부끄럽고... 아직도 멀었구나 !!! 생각이 깊고... 더 넓고 실력자체가 좋은 사람은 많이 있다.

이러한 의미에서 누군가와 무언가를 나누는 커뮤니티는 매우 중요하다. 사람들의 생각이 다들 달라서 더 값어치 있다. 누구는 벨류어블하다고 엘레강스하게 말하기도한다. ㅋ
가끔 나와 다른 사람들도 있다. 다만 바라보는 시각이 다를뿐 내가 정답은 절대 아니다.
물론 위에 적힌 말도 나의 생각일뿐....

그러나 커뮤니티는 자신의 일상의 일부일 뿐이라는 생각이 든다.
내가 무슨 커뮤니티에 있던지 간에.... 주가 되기는 조금 힘들듯...물론 내 생각이다.
"그런게 한국사회 아니겠어 , 커뮤니티 문화를 이해 못햇...!!! " 라고 말하는 사람이라면 아마..그사람은 자신의 일을 충실히 하기때문에 그런 이야기를 한다고 생각하고 싶다. 그럴 자격있으니..말하는 것이겠지...
규굴 ( 구글이 아님 : 귤만까서 먹어도 돈을 주는 회사다. 어제 꿈에 나온....) 에 취직해서 자유를 만끽하면서 일햇....!!! 이렇게 말해주고 싶은 사람도 있었다. 그것도 나와 다르기에 말하는 것이겠다.

가끔 보면 공부할 시간없다고 요동치는 사람들 많은데...(나도포함)
절대 그렇지 않다고 본다. 늦게 철들어서 지금 고생하고 있지만... 주말에 커뮤니티에서 공부해도 되고..화장실에서도 해도 된다. 샤워하면서 해도 되고....
밥을 씹으면서 해도 된다. 3년전엔 그러했는데...이제 늙어서 그런지.... T.T

악보 조금만 보고 자야하겠다. 마눌님이 화를....그러면 오직 죽음이라는....

PS : 사소한건 사소한거다. 오래 생각하면 머리 아픈거고...
생각이 짧은건 다시 생각 안해서 이다.
먼저 해야 하는 것이라면 먼저 하고..나중엔 후회하지 말아야 .....

그런데 왜...규굴에 취직하고 싶지...

Timer 관련 Sample 잘 볼것 (중요한건 아니지만...)
클릭

오늘 빡센 하루 보내고 내일은 일어날 수 있을지 모르겠다. 지금 집에와서 컴터 앞에 앉은지..5시간째....막 가트너와 포레스트리서치의 자료를 뒤지고... 자려고 하는데
도통 잠이 안온다. 두 회사의 리서치 자료중 그래도 맘에 드는건 가트너...
공통점은 둘다 최근들어 ESB관련 자료를 토해낸다..... 토해낸다는 의미는....^^;;;;

최근에 본 자료의 양은 태어나서 가장 많이 본듯.... 정말 끔찍하게 많은 양이다. 머리속에서 자료들이 둥둥 떠다니는듯.... 이 많은 양의 자료를 함축하고 추상화 하느냐가 지금은 중요하다....

포레스트리서치의 자료는 CIO나 혹은 CEO전용인듯...그래서 몇번 좌절.... 그러나 나에게는 너무나 좋은 자료들....그들의 레벨에서 많은것을 생각해야하니...
다행히 엔지니어링 자료는 여기저기 뒤지면 많이 있어 다행...

얼마전 쓴 블로그에서 마이크로커널이 왜 훌륭하다고 하는지... 아는 사람은 알겠지만
JBoss의 마이크로 커널이야 말로...SOA의 실체라는 생각이 들어서 이다.
너에게만 TRUE SOA라는 말을 내가 붙여준다. ^^

그거와 관계없이...여기저기 레포트를 뒤지다 레드헷의 이야기를 보게 된다.
오라클이 탐냈던 JBoss결국은...레드헷이...가졌다.
결국 레드헷은 SOA플레폼을 원했던 것이다.

엄청난 자료속에 내가 필요한 것은 별로 없던데...한숨이 핑핑 나온다.
내일은 또 무슨 일이 있을랑가.... 토요일만 기다려진다.

이번주에 알아야 했던 사실은 이전에 알았던 그 무엇보다 광범위 했다.
특히 기업이 오픈소스를 도입할때 얼마나 신중하여야 하는지...
또 경영자, 그 중간, 개발자들간의 갭등에 대해서 다시 생각해보는 좋은 시간이 되었다.
다시 한번 부끄러워지는 하루였다. 그래서 더 힘이 빠졌나....
아래 그림은 오늘을 생각하며 넣은 뽀나스 T.T