사람이 다녀간 자리.

Posted at 2010.09.07 19:33 // in Architecture // by MOOVA 무바㏇
사람이 다녀간 자리는 아름답게 그 자취를 남겨 놓는게 예의이다.
그 사람이 어떤 일을 했건 어떤 업적을 세웠건 간에 말이다..

2010:09:07 19:24:01


지나간 흔적을 발췌하고 그것에 뭔가 하나를 추가해서 덤으로 어부지리하려하는 어떤 버러지가 있다. 그 버러지는 본인과 아무런 상관이 없는 곤충이다.
그 곤충은 프로젝트내에서 본인의 이름을 사방팔방 팔고 다녔던 아무개와 비슷한 류다. 그렇게 살도록 내버려두자. 곤충이 살아가는 방법이니까.

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[상관관계] TDD, 리팩터링, 프레임웍, 솔루션

Posted at 2010.09.07 17:19 // in Architecture // by MOOVA 무바㏇


위의 그림은 테스트 주도개발에서부터 MDA & Desinger에 이르기까지 발전되는 상관관계를 가시적으로 표현한 그림이다.

TDD를 통해 제대로 동작하는 주요 기능을 몇 초 또는 몇 분 만에 만들어 낸다.  그 다음, 리팩터링을 통해 필요한 수준의 정교함을 갖출 때까지 발전시킨다. 저수준 리팩토링과 복잡한 리팩토링을 통해 패턴을 만들어 낸다. 패턴을 사용함에 있어 패턴중독이 될 수 있는 부분까지 분류하여 안티 패턴을 도출해 낸다. 적당한 패턴이란 반복적으로 발생하는 문제들을 설명하고, 이 문제들에 대한 해결 방안의 핵심을 설명한 것이다.

그리고 우리는 템플릿을 작성하여 패턴 적용을 자동화하고, 이것을 다시 컴파일된 형식으로 발전시켜 프레임웍을 만든다. 프레임워크의 사용이 애플리케이션의 개발 생산성에 많은 도움을 주지만 컴파일된 코드의 형식으로 제공되기 때문에 사용자들에게 시각적인 효과를 제공하지 못한다.이러한 것을 개선한 것이 결국 디자이너이다. 이것은 시각적으로 설계할 수 있는 수준을 제공해주며 모델과 모형을 생성하고 모델을 변환하여 최종의 결과를 도출해 낸다.(MDA[각주:1])


이 모든 과정이 상황에서 비롯된 문제점들을 보완하고자 나온 형태것이며, 궁극적으로 해결책을 만드는 과정에 포함된다. 간혹 오해할 수 있는 부분이 솔루션과 프레임워크의 상관관계에 대해서 자로 재듯이 비교를 하는 실수를 할 때가 있다. 프레임웍과 솔루션의 상관관계는 상황에 따라

프레임웍 = 솔루션, 프레임웍 < 솔루션 , 프레임웍 > 솔루션

의 관계가 될 수 있다는 것에 주목하자.
  1. Model Driven Architecture [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

오픈소스 그리고 마키텍트

Posted at 2010.08.11 19:49 // in Architecture // by MOOVA 무바㏇
보통 오픈소스가 공짜라는 환상을 가지고 있다. 하지만 오픈 소스가 맹목적인 무료를 의미하지는 않는다.

 
"오픈소스가 공짜라는 환상"

예를들어 아파치 웹서버를 사용한다고 가정하자, 아파치는 무료 라이센스 모델기
2010:08:11 19:37:32
반이므로 이것을 누구에게 판매할 수 없다. 하지만 이를 관리하는데 추가적인 기타 비용을 지불해야 한다. (웹서버의 설치, 설정, 유지 등에 관한 서비스), 슬리피켓 소프트웨어는 전통적인 이용기간 제한 비즈니스 모델과 오픈 소스 라이센스 모델을 결합해 소프트웨어의 대중적인 보급과 수익성을 동시에 획득했다. 이것이 가능했던 이유는 오픈소스인 버클리 DB를 오픈 라이센스로 제공했다. 누구라도 버클리 DB를 사용할 수 있었지만, 약정에 의해서 자신의 애플리케이션의 소스 코드를 오픈 소스 라이센스로 공개해야 한다. 오픈소스 정책의 전염성을 보여주는 예다. 그래서 슬리피켓은 버클리 DB를 별도의 라이센스로도 판매한다. 이 라이센스를 구매한 회사는 자신의 소스 코드를 공개하지 않아도 되는 예외를 허용한다. 바로 여기가 오픈소스가 돈을 창출하는 지점이다.

 

"아키텍트와 마키텍트의 상생"

오픈소스를 프로젝트에 채택하려면 이와같은 라이센스 정책을 잘 따져봐야 한다. 오픈소스를 도입함으로써 얻게 되는 교육적인 비용, 또는 연간 얻게 되는 컨설팅 비용, 매 단위 트랜젝션마다 리미터에 부여하는 과금금액등. 하드웨어 선택과 오픈소스 선택에 따른 비즈니스적 가치 창출, 소프트웨어 부서에 정녕 필요한 기술에 따른 비용등, 이런 부분들은 개발자가 관여할 수도 없고 관여해서도 안된다. 때에 따라서 라이센스 정책을 제외하고 기술기반 영역만을 고집하는 팀들이 자주 실수하는 부분이 이 점이다. 기술기반 타키텍트는 기술의 희망과 기호를 강하게 가지고 있는 사람이기 때문에 전체적인 관점에서의 선택이 힘들 수 밖에 없다. 불행히도 홍보형 디자인 또는 이력서 주도 디자인을 하는 개발자가 그것이 멋져 뵌다는 이유만으로 기술을 선택하는 경우를 볼 수 있다. 설익은 아키텍트와 핵심작업자가 설익은 비즈니스 모델(그것도 단 1가지만을 가지고)만을 가지고 기술을 채택하는 것은 일반적인 병폐이지만 우린 종종 이러한 실수를 하고만다..

그러한 실수를 줄이기 위해서는 우린 마키텍트의 조언을 얻어서 합의를 통해 오픈소스기술을 채택해야 한다. 
기술밥을 먹은 사람들은 마케팅부서에 대해 좋지 않은 시각을 가지고 있는 것이 사실이다. 하지만 기술을 부리려면 마케터와도 협력을 해야만 잘 하고 있다는 소리를 듣는다. (물론, 사람팔아먹는 이런 난국에서는 이 소리가 잘 통용되지 않는다는 것을 잘 알고 있다. ) 물론 나 조차도 충분히 기술적인 관점으로 다가가려 하기 때문에 이 부분은 참 어려운 부분이다. 하지만 기술적인 명목을 우상시하면 대체 어디에서 비즈니스 가치를 얻어야 할지 애매할때가 많다. 단지 계약서상에 계약을 한다고 해서 비즈니스 가치를 올린다고 생각하면 그것은 환상일 뿐이다. 

한 솔루션 회사에서 다른 부분을 모두 제외하고 기술적인 관점만을 강하게 키워 제품을 만들었던 기억을 해 본다. 누가 뭐라해도 훌륭한 소프트웨어였지만, 시장성에선 대패를 하고 말았다. 그 이유는 무엇인가?패의 원인은 이클립스도 아니고, 스트러츠도 아니고, 스프링과 같은 기술 아닌 다른 요인이 있었기 때문이다.


"오픈소스 프로젝트를 성공으로 이끄는 열쇠"

솔루션 개발에 영향을 주는 직접적인 요인은 지표, 문제영역, 기술기반을 들 수 있다.


위에서 볼 수 있듯이 기술,마케팅,시장. 이렇게 삼박자가 맞아야만 한다. 기술만을 우뚝 세웠을 때 기존의 시장성을 간과해서 대패할 수도 있고(직접경험을 해봤다.), 마케팅만을 강조해서 기술의 느린 발전을 촉진시킬때도 있다. 마키텍트와 아키텍트가 함께 일하는 분위기를 창출하고 서로간에 불신을 없애려는 노력을 해야한다. 하지만 협력하는 방법을 배우려면 시간과 노력이 필요하다. 그런 노력이 미래를 대비한 충분한 가치가 있다는 것을 염두해 두어야한다. 피에 쩔은 실패를 맛보지 않으려면 말이다. 

위해서 말했듯이 성공적인 오픈소스 소프트웨어를 구축하기 위해선 적절한 오픈소스기술 선택이 필수요소이고 그에 알맞는 시장과 사용성에 대해서 충분한 자료가 밑바탕이 되어야 한다. 물론 기술만을 고집해서 마키텍쳐영역을 무시해서는 안된다. 종종 기술자가 실수하는 것중에 하나는 특정 기술을 맹목적으로 선호하는 경향이 강하다는 것이다. 예를들어 A라는 기술과 B라는 기술이 있을 때, 나는 A라는 기술에 상처를 받았기 때문에 A라는 기술은 무조건 채택하지 말아야 하는 태도는은 상당히 잘못된 생각이다.. 한 프로젝트의 기술선택은 정말 복잡한 이해관계가 포함되어 있다. 또한 라이센스 문제도 간과할 부분이 아니다. 그래서 전체적인 워크시트가 필요한 것이고, 경험과 사례의 실질적인 데이터가 필요한것이다. 큰 프로젝트와 관련되어 있을 때는 명세나 규격 또는 표준등을 더 세밀하게 작성하기 때문에, 이런 경우 기술은 부과적인 요소일 뿐이며 시장을 형성하고 창출하는 기본요소가 아니기 때문이다.

마케터라고 무시할 필요도 없고 기술밥먹는다고 제외할 필요도 없다. 오픈소스 선택시 필요한 기술만을 고집하면 마키텍트들에게 눈총을 받을 수 있다. 서로 협력해서 전체적으로 볼 수 있는 관점이 필요하지 않을까 한다.

마키텍트 : 제품관리자, 비즈니스 관리자, 시스템을 책임지는 프로그램 관리자


참조도서 : 


저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.08.11 21:05 신고 [수정/삭제] [답글]

    정말 회사에서 일하다 보면 은근히 GPL이 싫어지더라구요.
    BSD License를 돈을 주고 판다는건 정말 천재적인 아이디어인것 같은데요?

  2. Favicon of http://kindtis.tistory.com BlogIcon 친절한티스

    2010.08.13 16:34 신고 [수정/삭제] [답글]

    저 같은 사람에겐 오픈소스 프로젝트는 정말 생명의 젖줄 =ㅅ=;
    게임 제작 공부하면서 오픈소스로 되어있는 공개 게임 엔진을 분석하면서 정말 많은 공부를 했어요.

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.08.14 16:29 신고 [수정/삭제]

      게임쪽도 오픈소스를 많이 사용하는군요.^^
      오픈소스는 어느 분야건 학습자들에게 많은 도움을 주는것 같아요. 저도 충분히 도움을 많이 받았습니다.
      자바쪽에서는 코드를 작성하는 것만 강조하고 무조건 빨리빨리만 외치니 그렇게 좋은 오픈소스를 보고 활용하는 시간도 별로 없었던 것 같습니다.

댓글을 남겨주세요.

[오픈소스와 나와의 관계] 어제 이야기에 이어서.

Posted at 2010.08.11 17:38 // in Architecture // by MOOVA 무바㏇
S.Lim 과 오늘 또 다른 대화를 나눴다. 이 친구는 몇 년간 강의활동을 하다가 내가 해준 지적때문에 최근 다시 프로젝트를 구상하고 움직이려 한다. 여전히 그도 실전경험을 쌓고자 하는 의지가 있기 때문이고, 내실을 따질 수 있는 영역과 진짜 실력을 키울 수 있는 영역은 필드라는 것을 잘 알기 때문이다. (내가 해줬던 지적은 "실전 경험도 없이 어떻게 강사를 하냐," 훌륭한 강사가 되려면 실전경험은 몇 년은 쌓아두는 것이 좋다고 지적한 탓에 그는 많은 생각을 한 것 같다. 역시나 깨어 있는 인물이라서 스스로 움직이는 모습을 보면 참으로 자각있는 인물이다. )

그나 나나, 그때나 지금이나 여전히 오픈소스활동은 나에겐 일종의 취미이기 때문에 그 이상의 명예욕이나 승부욕을 발휘할만한 도구는 아니다. 오픈소스로 업을 가지고 사는 사람들에겐 미안한 이야기지만 나에겐 오픈소스란 이름을 팔고자 하는 영역도 아니며, 권력을 잡기 위한 도구 또한 아니다. 내실을 따지자는 취지에서 개인 학습 용도 또는 연구 목적으로 활용한 게 오픈소스였고, 전에도 그랬듯 앞으로도 그렇게 유연하게 대할 것이기 때문에 그렇게 추할 정도로 매달리려 하는 영역 또한 아니다. 연구소에서 근무할 때부터 오픈소스는 최소의 비용으로 최대의 효과를 보자는 목적이 첫째였다. ( 실제로 학습이나 개인 역량 향상을 위한 오픈소스 연구는 정말로 도움이 된다. 본인이 알고 있는 소프트웨어 공학 지식도 오픈소스에서 영감을 많이 얻었으니 그것에서 얻었던 가치는 정말 값졋다.)

왜 예전과 같이 블로그에 포스팅하지 않느냐며 글을 기다린다고 한다. 내가 이 두 번째 블로그를 접은 이유는 
그렇게 많은 공유를 했고 공개를 했는데도 불구하고, 오픈스럽지 못한 사람들의 비방이 있었기 때문이다.

"너 자신을 위해 공유하는 거지, 진정 다른 사람을 위해 공유하는거냐?" 또는,
"왜 너만 안다고 생각해?" , "튀지말고 블로그 접어라" 또는,
"나도 할 줄 아는데.. 내가 못해서 블로그을 안 쓰는 게 아니다." 라는 핀잔섞인 말들뿐이었다.
 
그런식으로 비방을 했던 인물중에 프로젝트에서 실력보다는 부패한 정치만을 했던 썩인 인물들이 대 다수였다. 오히려 업에서 스승으로 삼고 있는 몇 분들과 같은 동족(스터디위주인물들)들은 다음 포스팅을 기다리고 기대한다고 한다. 이것이 오픈된 사람들과 막혀있는 사람들의 차이 아닐까? 그렇게 비방했던 사람들의 최근 블로그를 들려보면 오픈활동을 시작한 사람도 있고, 실제로 소셜활동을 시작한 사람들도 있다. 뒤늦게야 블로그의 힘을 안 탓이리라.

한가지 질문을 스스로에게 던져본다.

그렇게 공유를 한 이유가 나 자신을 위한 것인가? 아님 명예욕때문인가? 정녕 다른 사람을 위한것인가? 

답은

난 그냥 단순히 블로그에 무언가를 공개하고 소통하는 게 좋아서였다. 위의 비방들은 따라붙지도 못한다.

 그냥 메모용도로 사용한 포스팅들이 한 프로젝트[각주:1]에서 크게 알려지면서 점차 관련인들에게 퍼저나간 이유가 첫째 조직에서 튄 이유중에 하나였다. 그런 오해때문에 누군가는 내가 홍보용도로 블로그에 PR하는 것처럼 잘못된 인식을 갖기 시작했다. 허..참. 정말 웃긴 현상 아닌가?  그 시절엔 그냥 기술이 좋고 공유라는 사상이 좋아서 블로그를 운영했을 뿐이다. 
실제로 GPL소스들을 많이 접하면서 난 그 사상이 그냥 좋았던 것이다. 프로젝트에서 실제로 나를 본 사람들은 나를 잘 안다.

지금 이 오픈소스와 나와의 관계는 그냥 연구목적일 뿐 그 이상도 그 이하도 아니다. 포스팅하지 않는다고 연구를 게을리한다고 생각하면 큰 오산이다. 나는 병상중에도 연구한 사람이다. 주변가족들이나 친지들이 걱정섞인 말로 건강때문에 IT를 관두라고 했던것도 모두 뿌리쳤던 나다. 실제로 집안 식구들은 초반부터 내가 IT를 하는 것을 굉장히 싫어하셨다. ( 오히려 요즘은 격려를 해 주지만...)

난 단지 위와같은 그런 찌질한 비방이 싫기때문에 두번째 블로그를 접은 것이고,홍보나 광고와 같은 돈벌이를 위한 일보단 내실을 더 따지는 사람이기 때문이다. 그리고, 이고 아무도 나를 위해 그런공격들에 대해서 방어해주진 않기 때문이다.

ps : 아직도 오픈소스 공부하냐는 그의 질문에 나와 오픈소스와의 관계를 명확하게 열거했다.





  1. 한쪽의 엔지니어들이 수년간 이클립스를 쓰면서 특정 솔루션에 디버깅을 하지 못하는 것을 보고, 난 그냥 2틀동안 궁리하다가 그 솔루션과 이클립스을 연동했다. 그리고 공개했다. 근데 이상하리만치 주변 엔지니어들은 환호성을 외쳐댔다. 그렇게 큰일도 아닌데 왜 그런 반응들을 보였을까? (지금 생각해보면 그 솔루션을 사용하면서 이클립스와 연동한 사람은 아무도 없었다고 한다. 7~8년동안 그런 시도조차 생각해 보지 않았으니 얼마나 기가막힌 일인가! ) 그것때문에 ROI가 2~3배나 올랐으니, 파격적인 공개였긴 했나보다. 그치만.. 그거 연동하는데 그다지 여러운 일도 아니였고, 고 수준의 기술을 요구하는 영역도 아니여서, 그냥 생각난김에 2틀간 연구해서 연동했을 뿐이다. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.08.11 21:09 신고 [수정/삭제] [답글]

    저야 블로그를 하는 이유가
    '기술 노트'를 웹으로 대체했을 뿐이니 명예나 돈을 위한것은 아니라 상당부분 반론을 제기 못하게 되는것 같아요.
    그래도 방문자 수에 대해서는 욕심이 조금 나긴하는데 말이죠 ㅋㅋ

    아무튼, 문득 왜 소통을 하지 않냐고 맞팔을 강요하던 김주하의 사건이 떠오르네요.

댓글을 남겨주세요.

내친구 쨈스

Posted at 2010.08.10 23:07 // in Architecture // by MOOVA 무바㏇

일상은 평안하고 하늘은 고요하다.

하필이면 이럴 때 쨈스생각이 나는것인가?

쨈스는 5살때 만난 미국인 친구다. 용산에서 표구사, 화랑을 운영하시는 할아버지와 아버지 밑에서 자란 나는 유년시절 가족과 친지들의 따뜻한 사랑을 받고 있었다. 가끔 씩 표구사에 놀러간 나는 아버지에게 나무로 멋진 칼을 만들어 달라고 졸랐는데,  아버지는 칼과 칼자루를 나루로 깍아 만들어 주셨고,  종종 그것을 내 친구들에게 자랑을 해서, 가끔 동네에서 제일 멋진 사람이 되었다.
어느 날 친구들과 칼 싸움을 하고 놀고 있었는데, 파란눈에 노란색 머리의 꼬마가 우리와 합류를 하자며 손을 내밀었다. 카라멜과 땅콩, 그리고 건색바탕봉지에 들어 있는 건빵을 건네주면서 말이다.

그는 미국인이었다.

지금 생각해 보건데 그 건색바탕봉지는 미군부대에서 부식으로 제공했던 군부대 압축음식이었다고 생각한다.
그 꼬마의 이름은 쨈스. 우린 금세 친해졌다. 한국말을 곧잘 했던 쨈스는 인종은 백인이었지만 어렸을 적부터 한국의 미군 부대 주위에서 자란 이유로 한국애들과 어울리는 것에 별다른 어려움이 없었다. 아직도 내 뇌리에 남아 있는 그의 이미지는 강하고 온화했고, 매우 똑똑한 꼬맹이었다고 기억한다.

하루는 쨈스집에 놀러 갔는데, 궁궐 같은 집에 아주 큰 개 한 마리가 살고 있었다. 내 몸집보다 두배나 큰 개였고 현관에서 집까지 걸어가는 데만 100발자욱이나 필요한 거리여서 나는 그 개를 무척이나 무서워했었다. 쨈스네 집에 들어가니 으리으리한 커튼과 장식들이 눈에 들어왔고, 그의 어머니는 나에게 음식을 대접해 주곤 했었다. 집도 으리으리하고 장식품들은 굉장했고, 미국인 군인 아버지와 미국인 어머니를 뒀었던 쨈스의 집은 매우 풍요로웠다. 하지만, 그의 집에는 뭔가 생기가 없는듯한 느낌이 들었다. 훈련잡지에 비행기그림에..겉은 화려했지만 속은 많이도 여렸고 어두웠던 쨈스의 방. 그 밝은 웃음뒤에 왠지모를 외로움이 숨어있었다.

그렇게 쨈스의 이미지는 내 뇌에 그런 이미지로 형상화되어 있다. 종종 서랍장을 열어서 옛날의 추억을 되살려보고, 바로 서랍에 집어넣고 1년~2년간 꺼내보지 않고 있는 그런 종류의 이미지이다. 가끔씩 가족이나 친척들이 쨈스 이야길 할때마다 기억나곤 하는데 그정도로 우린 친했던것 같다. 5살때의 기억.. 나에겐 버려지지도 않는 기억이다.


....


이따금씩 쨈스의 기억이 난다. 왜 하필이면 이런 날 쨈스의 생각이 난 것일까? 알 수 없다.
지금은 뭐 하면서 지낼까.. 나를 기억하고 있을까.

인연이란 나에게 잊을 수 없는 소중한 기억을 만들어 주곤한다. 옷깃만 스쳐도 인연이라 하니.. 나에겐 참으로 소중한 기억들이 많다. 
하나씩 껴 맞추는 듯한 기억의 조각들을 요즘은 생생하게 재생하고 연결하고 있다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://moonlgt2.tistory.com BlogIcon 소박한 독서가

    2010.08.11 00:24 신고 [수정/삭제] [답글]

    지금은 미국 들어갔을 지도 모르겠습니다. 한번 영문트위터에 rt부탁을 한번 해 보심이..

  2. Favicon of http://minimonk.net BlogIcon 구차니

    2010.08.11 21:10 신고 [수정/삭제] [답글]

    먹는 쨈이 아니었군요 ㅋㅋ

댓글을 남겨주세요.

[세탁소 이야기] 뇌주름 아키텍처 패턴 지향

Posted at 2010.06.14 13:42 // in Architecture // by MOOVA 무바㏇
패턴에 대한 인식을 재정립하고, 패턴 발굴의 확산을 기리며 쉬엄쉬엄 작성해 정리한 글입니다. 

엔지니어들이 쉽게 사용하는 IDE나 벤더 솔루션에서 가끔 
아키텍처 패턴을 응용한 제품을 접하곤 한다.
(필자는 실무에서 객체를 사용한 제품 분석을 통해 패턴감각을 익혔고, 차 후에 아키텍처 패턴을 학습한 경우다. 그 후 특화된 도메인에서 사용된 패턴들이 수없이 많다는 것을 확인했고, 차 후 범용적인 패턴까지도 서로 연결되어 있다고 믿었다. 비 정형화된 패턴과 정형화된 패턴의 만남이었다.- GOF의 디자인패턴과는 다른 이야기.) 이런 것을 발견할 때마다 신기하게 느낀 이유는 대부분 활용한 패턴들이 마치 끈처럼 연결된 듯한 느낌이 들었다. 

한마디로 "연결되어 있다" 였다. 

각 제품에서 활용한 패턴들은 대부분 똑같은데 보이는 결과물은 같은 것도 있었고, 다른 것도 있었고, 비슷한 것도 있었다. 모방은 창조의 어머니라고 하지 않았나?! 그 후 여러 가지 패턴을 조합하여 실무에 적용하려 매우 골머리를 썩힌 기억이 난다.
그 후 계속되는 연쇄작용으로 각 패턴이 연결되기 시작했고 서로 연관을 지을 수 있게 되었다. ( 결국 내 뇌는 뇌 주름만 더해간 고통의 인내과정을 겪었다.)

양보다 질을 따져서 지식적으로 제한되어 있던 패턴을 실무에 접목하고자 노력을 하는 사람들과 연구단체들이 많다. 또한, 실제로 실무에 접목하고 또 발굴해 내려는 분들 또한 많아졌다. ( 매우 반가운 소식이다 ) 그런 노력은 새로운 패턴 발굴에 도움을 줄 것이고 기존 패턴 연구에도 피드백을 줌으로써 패턴의 인식을 변화시킬 것이라 장담한다. 

패턴 대부분은 대부분 업무에 응용할 수 있고 확장할 수 있다. 또한, 정형화된 패턴 이외에 특화된 도메인에서 응용했던 비 정형화된 패턴까지도 한마디로 연결되어 있다는 사실의 발견에 매우 놀라지 않을 수 없다. 나중에 알게 된 사실이지만 이런 패턴의 연결고리를 정리한 것이 Plop에서 제안된 Pattern Map이란 지도였다. 역시 배움의 길은 멀고도 험하다.

- 알고 넘어가기
  1. 무분별한 패턴사용은 사용하지 않음만 못하다.
  2. 패턴의 범주는 이디엄 < 디자인 패턴 < 아키텍처 패턴으로 분류할 수 있다.

    위에 그림은 뇌주름이란 제목의 그림이다. 이처럼 뇌 주름에서도 쉽게 패턴을 찾을 수 있다. 하지만, 본고와는 무관한 그림이다.:)


애피소드. (세탁소 아저씨 이야기)


때문에 자주 지방에 내려갈 때, 전용으로 양복을 맡겼던 세탁소가 하나 있다.
그 세탁소 주인은 30년 동안 HH양복회사에서 일을 했었고 퇴사 후 자신만의 가게를 차렸다고 했다.
그분은 소일거리로 백화점에서 의뢰받은 수공품을 만들고 계셨는데 그 솜씨가 기가 막혔다.
백화점 브랜드이긴 하지만 어디서 설계도면을 가져왔는지
설계도면[각주:1]만 있으면 완전히 똑같은 모조품을 만들 수 있다고 했다. (물론 단순한 그림 쪼가리는 아니다. 3D 캐드 도면이었다.)

이때 그분에게서 들었던 것이
설계패턴이라는 단어였다. 설계패턴은 어딜 가도 동일하니 패턴에 맞게 하면 뛰어난 수공품이 된다는 것이었다. - 난 이것에 놀라지 않을 수 없었다.
의류업계에서도 패턴이 있었다니, 심지어는 패턴을 외워서 모조품까지 만드는 난공불락의 신념도 들어 있었다.( 어찌 됐든 모조 제품은 좋지 않다.:) 


같은 패턴 , 다른 패턴 , 비슷한 패턴.

소프트웨어는 이와 비슷하지만 조금은 대조적이다.

환경이 항상 달라서 똑같은 패턴을 쓰더라도 그 용도와 효용성은 조금씩 차이가 있게 마련이다. 
하지만, 조금씩 차이를 가진 패턴이라도 그 속을 들여다보면 비슷한 카테고리를 찾을 수 있다.  
이것을 정리한 것이 바로 Pattern Map이다.
상황과 환경이 매번 다르지만, Pattern Map을 참고 해서 원류를 찾을 수 있기도 하고, 또 그 속에 포함되어 얽혀 있는 패턴까지도 정리할 수 있다. 더불어 
패턴의 패턴 즉, 패턴의 모태도 찾을 수 있다. 자신과 자신이 속한 기업에 특화된 패턴을 발굴하여 자체 Pattern Map을 개발해 낼 수도 있을 것이다. (현재까지 정리된 Pattern Map의 Pattern들의 개수는 수 없이 많다.)

- 알고 넘어가자! 패턴 랭귀지

패턴·랭귀지는, 건축가의 Alexander가 제창한 지식 기술의 방법이다. Alexander는, 건물이나 거리의 형태에 되풀이되어 드러나는 법칙성을 '패턴'이라고 부르고, 그것을 '언어'로서 공유하는 방법을 고안했다. 그가 목표한 것은, 거리나 건물의 디자인에 관한 공통 언어를 만들고, 누구라도 디자인의 프로세스에 참가할 수 있도록 하는 것이었다.

패턴·랭귀지에서는, 다양한 경험을 패턴이라고 하는 단위에 정리한다. 패턴에는, 디자인에의 '문제'와, 그 '해결'의 발상이 한 벌이 되어서 기술되고, 거기에 이름을 써넣을 수 있다. 패턴·랭귀지를 사용하는 사람에게는, 자기의 상황에 따라서 패턴을 선택하고, 거기에 기술되고 있는 추상적인 해결 방법을, 나름대로 구체화해서 실천하는 것이 요구된다.

이러한 패턴·랭귀지의 사고방식은, 건축의 분야 이외에, 소프트웨어 개발을 넘어서, interaction·디자인이나 조직 디자인, 교육의 디자인 등에 응용되어 사용되고 있다. 패턴·랭귀지의 사고방식은, 실무 경험 지식을 공통 언어로 승화하는 방법으로서, 앞으로도 여러 가지 분야에 응용되면 좋을 것이다.




< 다빈치의 설계 패턴 中 >

보통 엔지니어들에게 확장성이 좋기로 소문이 나 있는 제품에는 고 수준의 패턴이 숨어 있으므로 쉽게 참고 해서 분석해 낼 수 있다. 패턴의 적절한 활용에 대해 어떻게 어디서 참고해야 하는지 당장 궁금하다면 널리 알려진 오픈소스를 한번 분석해 보면 된다. 또한, 정형화된 패턴에 벗어난 범주 즉, 비정형적인 패턴일지라 하더라도 결국 원류와 근본이 있기 마련이고 결국 패턴의 모태와 연결되어 있다. ( 특화된 도메인에서 지역패턴을 만들어서 국지적으로 사용했더라도 이미 원류는 범용적인 패턴범주에 속한다. )

그림1에서 볼 수 있듯이 특화된 도메인에서 개발한 패턴은 범용적인 패턴의 모태에서 파생되어 있다.



  1. PLM영역에서 설계도면이란 그렇게 간단하지가 않다. 단순히 종이 설계도면이나 UML로 만든 2D모양의 그림이 아니다. 대부분 3D툴을 이용해(캐드,마야등) 상위레벨과 하위레벨을 연결지을 수 있으며 평행선상의 구조적 부분도 연쇄 가능하다. 구조적 부분에서도 무척이나 건축분야와 닮아 있다.일반적인 종이설계문서와는 다르니 참고하자. [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기
  1. Favicon of http://minimonk.net BlogIcon 구차니

    2010.06.14 17:52 신고 [수정/삭제] [답글]

    악! 어려워요!
    음.. 디자인 패턴이라는 용어는 잘 모르겠지만 return to source 라고 하면 조금 비슷하려나요?
    핵심을 뚫는 원리를 알고 있으면 좋을텐데 그걸 시원하게 알기가 어려우니 안타까워요

    • Favicon of http://moova.tistory.com BlogIcon MOOVA 무바㏇

      2010.06.15 11:00 신고 [수정/삭제]

      흠..글쎄요 '원시로의 복귀'
      그것도 비슷한 감이 오지만 패턴과는 좀 다른 이야기일껍니다. 패턴은 원시의 소스를 중시함에 덧붙여 전체적인 구조를 바라보는 영역에 더 가깝거든요.

      디자인패턴은 'GOF의 디자인 패턴'이 유명합니다. 특정 언어에 국한되지 않고 볼 수 있는 소트프웨어 필독서죠.

      위에 서술된 아키텍트 패턴은 좀 더 상위의 개념입니다. 보통 개발하시는 분들이 GOF의 23가지 패턴이 전부라고 생각하는 분들이 많습니다. 하지만 패턴은 수천 수만가지죠.(비공식적인것 까지 합하면)

      패턴은 학습도 중요하지만 학습만 가지고는 실제로 감이 잘 오지 않습니다. 실무에 적용해보고 감을 찾고 발전해 나갈 때 핵심을 뚫은 자신만의 비법을 발견할 수 있을 것 같군요. 차근 차근 알아나가는 것이 중요한것 같아요

      We have to saw the forest!

  2. Favicon of http://9933.goofy.kr BlogIcon 지극정성

    2010.10.28 09:52 신고 [수정/삭제] [답글]

    건강㎴정보▒ <좋은 글 정보 감사합니다.<늘! 건강하시고 행복하시기를 기원합니다. 날마다 좋은날 되세요.

댓글을 남겨주세요.

경험적 공감.

Posted at 2010.02.13 16:43 // in Architecture // by MOOVA 무바㏇
javajigi님이 조직 세분화와 전문화에 따른 문제점, 그리고 해결책을 위한 포스트를 진행 중입니다.
저 같은 경우 상당히 공감이  되었던 포스팅입니다. 

1. 소프트웨어 개발자는 늘어나는데 생산성이 높아지지 않는 이유는?
2. 업무, 조직 세분화로 인해 발생하는 문제점은?


1. 글의 내용 전반이 대부분 공감된다. 근데..난 지금 이런 상황이 아니다. 내 병에만 몰두해야할 시기이다. 병적 결과가 나쁘다고 절망할 필요는 없다. 절망이라는 단어는 비관을 좋아하는 사람들이 많은 단어적 잦대니까 말이다.

2. 어느 정도 고통이 따라왔던 한 주다. 이겨내야 한다.! 그리고 다시 움직일테다! 
집안이 발칵 뒤집혔다. 이번일로 진심으로 걱정해 주는 친구들과 동료가 있지만, 남의 불행을 좋아하는 사람들 몇 명이 보인다. 여기서 인간성을 엿 볼 수 있다.
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[아키텍트와 코드] 슬립낫과 드림씨어터

Posted at 2010.02.02 16:54 // in Architecture // by MOOVA 무바㏇
한가지 문현듯 의문을 던집니다.

아키텍트가 세부적인 코드에 관해서 개입해야 할까?

라는 질문입니다.

"아키텍트가 코딩까지 관여해야 한다"라는 주장에 종종 동의를 합니다. 그리고 공감합니다.
하지만 제 관점은 사뭇 다릅니다.

몇 년 전에 포스팅한 글 '기능,구조,미'에서 은연중 저의 관점을 표현한 적이 있습니다.
아키텍트는 숲을 봐야 하는 직업이지 세부적인 코드까지 관여할 직업은 아니라고 대부분 말합니다.

하지만 제가 겪은 경험과 아키텍트 선배들이 물려준 지식과 경험에 더하여
전 아키텍처의 정의를 좀 달리 표현합니다.

"경험중심의 사례로 나타난 비즈니스 모델의 수용 가능성과 타당성을 따져, 실제 업무에서 활용 가능한 참고 아키텍처를 토대로 아키텍처 패턴을 사용하여 구조를 연결짓는 행위"
라고 단언합니다.

경험을 쌓는 행위를 중요시하고 있고, 경험주의 실용성을 더 중시하는 모습 때문인지.
쉽게 말하자면 제 관점은 구조와 구현체 중간의 입장에 있습니다. ( 경험을 쌓지 않고 오로지 스터디만 하는 [각주:1]되지 않기 위해 스스로 뛰어야 한다는 철학도 가지고 있습니다. 경험이 싫다고 하면 핑계에 불과할 뿐이죠. 코드에 집착했던 수 년전 제 모습이 떠오르기도 합니다. )

구현체를 좋아하는 어떤 선배분의 말을 옮겨봅니다. "난 구현체를 보지 못하면, 소프트웨어가 아니라고 생각한다. 추상적인 것보다 실제로 보는 모습을 좋아한다." 나쁘지 않은 말입니다. 실용성이 담긴 사상입니다.

추상체를 좋아하는 어떤 아키텍트분의 말을 옮겨봅니다. "구조란 추상화를 통한 건설이다." 나쁘지 않은 말입니다.

하지만 100% 공감할 수 있는 말은 아닙니다. 그분들도 인정했던 저의 관점을 다시 상기하면..
소프트웨어란 인간적인 요소와, 비즈니스적 성질과, 경험주의적 실용이라는 어려운 항목들이 존재합니다.
아직까지 전, 위대한 소프트웨어를 보면 그 내면을 까서 파는 행위를 종종 하곤 합니다만..
코드만을 중요시 하는 관점도 아닙니다.

자연스레 관점이 움직이고 있고, 그만큼 변화되고 있습니다.
구현과 구조의 중간입장에서 말이죠.



아키텍트의 관점


 1. 종종 사람이란, 영역이 다른 성질을 비교하는 실수를 범하기도 한다. 프로그래시브의 대가 드림씨어터와 해비매탈의 꽃 슬립낫을 비교하는 것과 비슷한 행위이다. 영역과 관점이 다르면 비교대상이 아니다.
2. 최근 아키텍트와 관련된 중요한 지식 전달을 하는 분을 몇 분 보게 되었다. 곧 조인해야지..
?????
VS

  1. 소크라테스 인용 [본문으로]
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

일본전산 이야기

Posted at 2010.01.22 01:43 // in Architecture // by MOOVA 무바㏇
꼭 한번 읽고 싶었던 책인데 이제서야 읽게 되었습니다. 친구님의 추천덕에*^^*

일본전산 이야기
카테고리 경제/경영
지은이 김성호 (쌤앤파커스, 2009년)
상세보기

불황기 10배 성장,
손대는 분야마다 세계 1위,
신화가 된 회사

어설픈 정신상태의 일류보다 하겠다는 삼류가 낫다.
많은 기업들이 사원들에게 거래처 응대하는 방법이나 상대에게 그럴듯하게 보이는 스킬을 가르치느라 시간을 허비한다. 하지만 그렇게 머리가 잔뜩 커져봐야 결국 자신의 알량한 생각으로 이건 안 되겠는데, 이건 어떤 책에서도 힘들다고 했고, 하는 식으로 지레 포기하는 나쁜 버릇만 들 뿐이다.


세상에 능력이 없는 사람은 없습니다. 또 유별나게 능력이 출증한 사람도 없습니다. 신이 아닌 이상 인간의 능력이란 다 거기서 거깁니다. 문제는 못할 것이라는 생각 관념을 버리는 것입니다. 우리는 무슨 수를 써서라도 해내기로 한 것은 결국 해냅니다. 그래서 강합니다.


비즈니스 정글에서 애초에 승패나 승률의 차이는 크지 않다. 하지만 처음의 아주 작은 차이를 만들어내고, 결국 점점 더 큰 갭을 만들어내는 것이 바로 문제 해결 습관이다. 그것은 천성도 아니고 특별한 능력도 아니다. 문제를 만날 때마다 무슨 수가 있어도 그것을 꼭 해결하고 마는 습관을 몸에 주입하면 된다.


된다고 생각해도 넘어야 할 산이 많은데, 안 된다고 말하는 구차한 변명 따위를 듣느라 시간 낭비 할 수는 없다는 것이다. 니가모리 사장은 끝까지 밤새워 방법을 찾아보는 사람들이 성공할 수 있도록 돕는 것이 일본 전산의 창립 취지라고 강조한다.


머리가 기발하게 좋진 않아도 일처리를 똑 부러지게 하는 사람은 따로 있네 밥 먹는 게 빠르고 용변 보는 게 빠르고 씻는 게 빠른 놈이야 무엇이든 할 수 있다는 정신상태만 본다.


어느 수준에 한 번 도달했다고 해서, 늘 그 수준을 유지할 수 있다는 생각은 망상이다. 현상 유지 이 생각을 품는 순간 내리막길이 시작된다.


신발을 정리하는 일을 맡았다면, 신발 정리를 세계에서 제일 잘할 수 있는 사람이 되어라. 그렇게 된다면 누구도 당신을 신발 정리만 하는 심부름군으로 놔두지 않을 것이다.


밑바닥 일을 제대로 할 수 있어야 모든 일을 잘할 수 있다는 것이다. 밑바닥 일을 제대로 경험하지 못하면, 나중에 관리자로 성장했을 때 직원들을 제대로 통솔하기 어렵고, 부하 직원들을 이해하기도 어렵다는 것이 이들의 지론이다.


우리 회사가 꼽는 좋은 인재란 명문대학을 졸업한 사람이나 성적이 우수한 사람, 혹은 일류 기업 경력자가 아닙니다. 마음속에 불씨를 가지고 있어서 언제든 그것을 점화할 수 있는 사람입니다. 그런 불씨를 가진 사람이라면 화장실 청소처럼 남들이 싫어하는 일도 서슴없이 할 수 있어야 합니다.


진정한 프로가 된다는 것은 남들에게는 보이지 않는 곳 가지 생각이 미치는 것이다. 똑똑한 것과는 다르다. 자신의 생각을 끊임없이 확장시키고, 문제가 생기면 책임지고 해결하려는 습관을 들인 사람만이 프로가 될 수 있다. 바로 이런 습관이 지금, 기업들의 승패를 좌우하고 있다.


나가모리 사장은 자신이 솔선해서 생각으로 일하는 시간을 투자하는 직원을 최고로 꼽는다. 일하는 자체에 에너지와 시간을 쏟는 것도 중요하다. 하지만 일을 쉬고 있을때나 무의식중에도 자신의 일에 대해 고민하는 사람, 풀리지 않은 문제에 대해 끝까지 골몰하는 사람은 반드시 답을 내오게 되어 있다.


이제는 큰 기업이 작은 기업을 잡아먹던 시대는 지났다. 빠른 기업이 느린 기업을 잡아먹는다는 것이 정설이 되었다. 변화의 속도는 점점 빨라지고, 조금이라도 그 템포를 따라가지 못하면 아무리 튼튼한 철옹성 같은 기업도 경쟁사에 잡아먹히는 것이 비즈니스 정글의 속성이다.


일본 전산이 가장 경계하는 것은 할 수 있는 일을 어중간한 상태에서 중간에 그만두는 패턴이다. 자신을 온전히 불태워 헌신하지 않고, 어떻게 하면 날로 먹을 방법은 없을까? 궁리하며 쉽게 얻으려 하는 것. 조금 더 시간과 노력을 투자하는 것이 힘드니까. 안 되는 이유를 찾아 열심히 짜 맞추어 둘러대는 것. 그리고 그런 패턴이 회사 내에서 쉽게 통용되는 문화가 바로 경계 대상 1호다.


일본전산은 처음부터 요구사항이 많고 까다로운 일에 관심을 가졌다. 직원들 사이에도 까다로운 일이란 풀어야 할 문제가 산적해 있는 오더지만, 그것만 해결하면 선두로 치고 올라갈 수 있다는 흔들리지 않는 공감대가 형성돼 있다. 참으로 엄청난 위력이다. 그런 모습을 보면, 고객은 감동하게 되어 있다. 문제가 많다고 다들 회피하는 일을 척척 해내는 상대를 싫어할 사람은 없다. 고객은 입에 발린 말이나 서비스 콜, 굽실대는 태도에 감동하는 것이 아니다. 바로 남들이 안 하는 일, 어려운 일을 척척 해내는 실행에 감동한다.


너보다 똑똑한 사람이 있느냐? 그럼 두배로 노력하면 된다. 똑똑하고 머리 좋은 사람이 오후 6시에 해결했다며 룰루랄라 퇴근했다면, 똑똑하지 못한 우리는 포기하지 않고 밤 11시까지 해서 해결하면 된다. 그럼 결과는 같아지는 것 아니냐?


대부분의 사람들은 수많은 이유 때문에 잘 팔 수 없다고 말한다. 그 어떤 일에서건, 약점만 생각한다면 아무것도 할 수 없다. 그럼에도 불구하고 어떻게 팔 것인가? 어떤 방법을 통해 지금 우리의 상품을 알릴 것인가를 고민하지 않으면 승리는 없다.


직장은 생산적이고도 창조적으로 문제를 해결해가는 곳이다. 그것도 기존과는 아주 다른 새로운 방법으로 문제를 해결해야 하고, 그 결과를 고객이 돈을 지불하고 사주어야 비로소 일이라는 의미가 성립된다. 생산재를 다루는 회사건 서비스를 다루는 회사건, 모두 똑같은 논리가 적용된다.


이상하게 변기를 자기 손으로 직접 청소해본 사람은 자연히 그 뒤로는 깨끗하게 사용해야겠다ㅏ. 그리고 다른 사람들도 깨끗하게 사용해줬으면, 하는 생각을 하게 된다. 뭔가 고장이 났을 때도 생각하는 범위와 행동하는 정도가 달라진다. 그전까지는 관리실에 연락을 하고 말거나 그다지 관심이 갖지 않았던 사람, 아니면 나하고는 관계없는 일이 라며 무신경했던 사람도 뭔가 조치를 취해야겠다는 생각을 하게 된다.


누군가 커피를 바닥에 엎지르면, 내가 뛰어가 물걸레를 가져옵니다. 그걸 닦으면서 다른 사람 손이 또 한 번 안 가도록 해야겠다는 것을 머릿속으로 다짐하게 되는 스스로를 발견했습니다. 빨리 완벽하게 다른 사람에게 피해가 가지 않도록 끝내기 위한 고민은 비단 청소뿐 아니라 다른 업무에도 미칩니다. 복사 하나를 하더라도 어떻게 하면 짧은 시간에 완벽하게 할 수 있을까를 생각하고 실행합니다. 그렇게 하게 되면 잡무도 제대로 된 일로 바뀔 수 있습니다. 아무리 작은 일이라 해도 다른 사람들이 감탄 할 정도로 멋지게 처리할 수 있는 방법을 생각하면서 실행에 옮기려 의식합니다.


말 그대로 학벌은 굶어 죽지 않을 확률을 조금 높이는 것에 불과하다. 비즈니스 정글에서는 학교 성적이나 학교 간판으로 먹고 살 수 없다. 좋은 학교 나왔다고, 성적이 좋다고 좋은 상품을 저절로 만들 수 있게 되는 것도 아니고, 경쟁에서 이길 만한 해법을 고안해낼 수 있는 것도 아니다. 중요한 것은 그 다음이다.


아끼는 직원일수록 호되게 나무란다.


실패한 사람에게 점수를 더 준다.


저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[Info] workflow < process < lifecycle < business process

Posted at 2010.01.19 15:35 // in Architecture // by MOOVA 무바㏇
IC롤 수행중 이해했던 비즈니스 프로세스관련 상관관계.


workflow < process < lifecycle < business process


business process

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

[Reference - J2EE Basic] Core J2EE Pattern

Posted at 2010.01.19 11:44 // in Architecture // by MOOVA 무바㏇
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
Click to pattern:

reference book :
 
J2EE 설계와 개발(expert one-on-one)
카테고리 컴퓨터/IT
지은이 로드 존슨 (정보문화사, 2004년)
상세보기

Business Delegate, Session Facade , Service Locator - EJB기반의 J2EE패턴이 상세하게 잘 나와 있는 책이다.


 
저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

SW 아키텍처 이론과 실체.

Posted at 2010.01.18 15:59 // in Architecture // by MOOVA 무바㏇
소프트웨어 아키텍처 이론과 실제
카테고리 컴퓨터/IT
지은이 렌 베스 (에이콘출판, 2007년)
상세보기

근래 필요에 의해서 다시 보게 되었다. 개인학습 + 실제프로젝트 팀단위 경험(AA) 과 실제 아키텍쳐 교육기관에서 하는 이론적인 사항.
장/단점이 있겠지만.. 장점의 내용을 필터링해서 재 소화하는 과정을 겪어야 한다.

이번 움직임은 지식의 편린을 정리하자는 목적이 강하다. 교육내용이 이론+경험+사례중심이다.

 이론 + 경험 + 사례 중심이다,


저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

라니와 함께 도서관에서 읽은 책과 선택한 책

Posted at 2010.01.18 01:26 // in Architecture // by MOOVA 무바㏇
라니. 고맙다.:)
 
Engineering Service Oriented Systems: A Model Driven Approach de Bill Karakostas et Yannis Zorgios (Relié


아키텍트 이야기
카테고리 컴퓨터/IT
지은이 야마모토 케이지 (인사이트, 2007년)
상세보기


SOA(서비스 지향 아키텍처)
카테고리 컴퓨터/IT
지은이 토마스 얼 (에이콘출판, 2006년)
상세보기


Rapid Web Applications with TurboGears: Using Python to Create Ajax-Powered Sites (Prentice Hall Open Source Software Development Series)
카테고리 과학/기술
지은이 (PrenticeHallPTR, 2006년)
상세보기


저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

Agile Project Management Software 투표 결과

Posted at 2010.01.14 13:47 // in Architecture // by MOOVA 무바㏇

AgileZone에 실린 기사입니다.
Agile Tool의 사용 빈도에 대한 투표 결과입니다.

http://agile.dzone.com/articles/agile-project-management


VersionOne, ScrumDesk,Agilo가 앞도하는 군요.

저작자 표시 비영리 변경 금지
신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

통합 LG 텔레콤 개편 축하 메세지!!!

Posted at 2010.01.14 02:32 // in Architecture // by MOOVA 무바㏇

 

2010:01:13 22:13:19

드디어 오픈했구나. ㅎㅎ
피를 부르는 프로젝트였다. 나가 떨어진 사람도 많았고..
마지막까지 있어 달라는 사람도 많았던 프로젝트였다.
그리고.
사람들의 상처와 희열이 담긴 프로젝트였다. 잘 쓰고 있나 모르겠네 ㅋ

신고
블로그코리아에 블UP하기

댓글을 남겨주세요.

티스토리 툴바