'IT서평'에 해당되는 글 23건

  1. 2007.12.16 대화의 기술
  2. 2007.12.15 Spring프레임워크워크북
  3. 2007.12.13 SCJP가 필요하다고 느껴질때 [JAVA2SCJP]
  4. 2007.12.03 개발의 갈등을 풀어주는 책 [Effective Java]
  5. 2007.12.01 구체적인 행동강력이 담겨있는 빨간책!! [XP도입을 위한 실전 입문]
  6. 2007.11.28 ERP 매직카펫을 나르게하려면 메뉴얼봐야죠 [ERP 프로젝트]
  7. 2007.11.25 '프로젝트 자동화'에는 ant와 log4j는 얼마 안들어 있다. [ANT Log4J]
  8. 2007.11.24 중급 개발자가 고급 개발자로 가기 위한 서적!! [refactoring java] 2
  9. 2007.11.22 프로젝트 과정/결과는 유토피아를 향한다!! [소프트웨어 생존전략]
  10. 2007.11.21 리스크는 이익이 되어 돌아옵니다. [리스크 관리] 1



"오늘까지만 Sale 하는것 입니다. 내일부터는 20%할인도 적용받지 못하구요. 사은품도 받으실 수 없답니다. ^^"
"이제품은 이런 이런 기능이 좋구요. 2005년 한국소비자 대상을 받은 제품이랍니다."
"반듯한 바디에 다양한 기능은 사용하는 사람의 품격까지 높여준답니다."
상냥한 점원의 말과 내용은 내가 지금 이 물건을 사지 않으면 안될것 같은 충동을 일으킨다.
돈이야 카드로 긁으면 되고, 이미 집에 같은기능을 하는게 있지만 지금상황에 그런게 대수인가..
어떻하나 .. 질러야 하나??  
"손님~! 이제 3개 남았습니다 ^^"
"어떻게 카드로 하시겠나요 현금으로 하시겠나요?? ^^"


우리가 대화를 하다보면 반박할 타이밍을 놓쳐 자신의 의지와 생각을 전달하지 못하는 경우가 종종 있다.
그중에 하나가 위에서 예로 든것과 같이 백화점에서 전문가의 포장을 두르고 판단할 기회조차
주지않는 대화가 대표적이다.

대화의 기술은 이런 대화속에서 논리정연하고 상대방에게 불쾌감을 덜 주면서 자신의 의지를 효과적으로
전달할 수 있도록 하는 방법을 기술한 "말하는 방법" 의 책이다.
책은 2001년도에 만들어져 이미 5년이란 시간을 훌쩍 넘어버려 책이 돌아다닐까 의심도 되지만 책의 내용은
지금나의 상황에서도 적용이 가능한 내용을 담고 있다.

나만보면 괴롭히는 사람이 있는데 어떻게 대처할 것인가?
왜 나만 항상 손해보는 느낌이 드는것일까?
내가 그렇게 만만해 보이는것 일까?

책의 저자는 이런 모든 문제가 자신(여성)이 그 상황과 타이밍에 적절하게 대응하지 못하였기 때문이라고 한다.
이러한 문제를 해결하기 위해서 저자는 6단계의 말하는 방법에 대해 기술하고 있고
가상의 상황을 설정 6단계별로 대화를 해나가는 방법에 대해서 이야기를 해주고 있다.

대화의 기술 6단계
 1. 상대방의 대답을 도저히 받아들일 수 없을때 자신의 의견을 주장한다.
 2. 상황을 간단히 설명한다.
 3. 자신의 요구를 정당화 한다.
 4. 원하는것을 요구한다.
 5. 자신의 요구가 받아들여질 때 생길 긍정적인 결과를 말한다.
 6. 자신의 요구가 거불될 때 일어날 부정적인 결과를 말한다.

책에는 이러한 기술의 방법으로 풀어내는 대화를 랜트카상황, 우편물 상황, 여행자 수표 등등의 상황을 설정하고
올바른(?) 대화의 기술을 말해주고 있다.

사실 개인적으로는 위에 언급된 6단계 말하는 기술을 두번이상 볼 사람에게는 적용하지 않을것이다.
적용을 하게 된다면 물건을 구입할때나, 소비자로써 당연한 권리를 행사할 때와 같은 자리에서 하게 될것이다.
책은 이 외에도 더 다양한 대화의 기술을 말하고 있다.
하지만 모든 말이 그렇듯 너무 칼날같이 말하는 사람에게 친분이 쌓일리는 만무하다.
권장한다면 책에 언급된 대화의 기술은 내 상황을 곤란하게 하는 점원과 상담원에게만 하는게
좋은 방법으로 보인다.



"솔직히 물건살 준비가 되어있지 않아요"
"당신이 물건을 팔려는것이 나쁘다는게 아니에요"
"하지만 전 그 모델에 별로 관심이 없어요. 불필요한 기능이 많을 뿐더러 집에 있는데요^^"



Spring프레임워크워크북

최근 J2EE의 화두는 SOA(Service Orinted Architecture)이다. 이는 웹서비스를 근간으로
다양한 시스템간의 통합을 이루겠다는 전락인데 과연 기존에 각각의 프레임웍과 분산된 서비스를
어떻게 어떠한 방법으로 통합 할것인가?

Spring프레임워크워크북 (이하 Spring워크북) 은 이러한 화두를 Spring으로 통합을 모색할 수 있는
기술적인 방법과 충실한 예제코드로 가이드해주고 있다고 볼 수 있다.

Spring은 사실 맨땅에서 태어난것은 아니다.  저자가 책에서 밝힌것처럼 굳이 EJB가 필요로 하지 않는
환경에서 EJB가 가지고 있는 정형화된 비지니스계층을 제공하기 위해 태어났다고 봐야 할 것이다.
이러한 점에서 책은 첫장부터 마지막장까지 EJB와의 비교의 끈을 놓치치 않고 전개하고 있어
역시 "Struts프레임워크 워크북"의 저자다운 내공(?)을 보여주고있다.

그렇다고 반 EJB진영에서 Spring만을 옹호하지는 않았다. 때로는 EJB의 분산환경 지원의 장점을
Spring에도 분산환경을 지원하기 위한 저자의 의견도 피력되어있다 (437p)

책읽는 전략!!
본 책은 다양한 프레임웍이 등장하고 있어 소설같이 차근차근 읽으면 다 이해되는 수준은 아니다.
핵심키워드인 Spring을 면밀히 검토한 후 전체를 한번 물 흐르듯 관찰하고, Spring과 다른 프레임웍과의
Relation을 결정짓는 많은 xml에 대해 장고해야 한다.
가장 좋은것은 이 모든과정을 거친후 예제코드를 eclipse에서 실행시켜보는 바둑의기보의 면모를
가져야 할 것이다.
사실 Spring워크북을 읽는데 필요한 내공은 중급 이상에 해당한다.
쉽사리 코드와 문구들이 눈에 들어오지 않는다고 실망할 필요는 없다.
다만 Spring의 핵심에 해당하는 IoC(inversion Of Control)과 AOP(Aspret Orinted Programming)은
꼭! 확인하고 넘어가는게 좋을것 같다.

책을 이해하기 위해 필요한 사전 지식
[EJB에 대한 대략적 이해]
 생명주기를 비롯해 NonEJB 진영으로 LightWeight이 등장한 주요한 이유가 있기 때문이다.
[TDD 방식에 대한 개념적 지식]
Spring워크북 에는 Test-Driven Development에 충실하는 모습을 보이고 있다.
JUNIT 을 이용한 Test방식을 선택하고 있기 때문에 JUNIT에대해 알고 넘어가는것도 좋을것 같다.
[MOCK Object]
가상객체라 불리우는 MOCK Object가 UI 개발자를 위해 Spring워크북에서 도입되었다.
물론 MOCK 자체가 UI 개발자위한 용은 아니지만 책은 MOCK이 여러모로 유용하다는것을 보여주고
있는 알려주고 있는 셈이다.
[UML]
소스코드의 흐름을 한눈에 보기위해 모델링 언어로는 UML로 표현하고 있다.
전 소스코드에 모델링으로 선택되어있기 때문에 UML의 사전지식을 가지고 있다면 소스코드의 라인단위
트레이보다는 UML을 보는게 보다 효과적으로 보인다.

책을 열고 내려놓을 무렵 하루가 다 지나갔다.
저자의 깊이있는 내공이 같은 개발자로써 커다란 산이되어 다가 오는것을 느꼈다.
이제막 프레임웍을 기반으로 몇개의 Project를 해본 나로써는  개발이라는 full Process를 Spring을 통해
깊이 있고 통찰있는 시각으로 구성시키는 점에서 Spring워크북에 긍정적 평가를 내려본다.

끝으로 이책을 통해 열악한 개발자로 살아가는 많은 이들에게 저자가 말하는 거짓말이 현실이 되어 다가와 주었으면 좋겠다.
"내년이면 좀 더 좋아질 거야!" 저자서문에서..



지금은 개발자로써 일을 하고있다. 하지만 시간이 지나면 나의 케릭터도 변할것이다.
그렇다면 내가 개발자였다는 사실을 누가 증명 해줄것인가?

또한 나 혼자 "나! JAVA 잘해요. 난 프로그래머에요" 라고 외쳐보지만 객관적인 자료가 없는 상황에서는
유언비어이고 쌓여있는 경력에 대한 가치를 희석시키는 일 밖에 되지 않을것이다.

기회는 한방이였다. 돈 20만원이 정말 아까웠기에 한방에 성공으로 이끌어야 한다.
그래서 사전준비차원으로 "인정받는 IT 프로 JAVA 2 SCJP"을 보게 되었다.

주문한 책이 내손에 들어온게 올8월24일..
그러고 기획에 착수해서 결과를 얻기까지 3달즈음 걸린셈이다.
개발자치고는 좀 오래걸렸지만 지금 프로젝트를 뛰면서 일하면서 멀티로 했기때문에
이렇게나 시간이 걸린것같다.

서두가 너무 길었다. 책의 내용으로 들어가 보도록 하자.
책은 SCJP를 위한 수험서적이다기 보다는 JAVA에대한 전반적인 섬세함을 보여주고있는 서적이다.
SCJP TEST가 그렇지만 ++i 냐 i++ 이냐에 따른 차이가 매우 중요하다.
책은 이런것 하나 하나도 놓치지 않고 이야기 해주고 있다.

간혹 Typeing 해보고 싶은 소스코드도 눈에 띄지만 결과와 설명의 정확도가 매우 높아
직접 Typeing하지 않아도 될꺼라고 본다. (다른 서적에 경우 Typeing 하면 결과가 다른 경우가 눈에띔)

SCJP수검은 주요 테마별로 진행이 된다. 책역시 수검에 필요한 단위 항목별로 카테고리가
분리 되어있고 thread, 가비지 컬랙션, 오버라이딩, 오버로딩 ... 등등의 출재빈도와 난이도와
유형에 따라 적절하게 배합 된것을 보여주고 있다.

이정도만 보면 정말 이 책은 SCJP를 위해 좋은 수험서이다.
친절하게 문제 유형을 설명하고 , 문제의 딥이 이것! 인 이유를 설명해 주고 있으며 뽀너스 트랙으로
EJB, JAVA WEB서비스 까지 70여페이지를 할애하여 이야기 하고 있으니
SCJP뿐만아니라 JAVA 배우는 책으로는 얼마나 좋은가?

하지만 이 좋은 수험서를 참고서 수준으로 전략시키는 문제집이 있다는 사실을 잊지 말자.
시험의 Pass가 목적이라면 참고서뿐만 아니라 문제집도 봐야하기에 문제집 3인방!
우그필 덤프, chofort덤프, test King이 대표적인 3인방을 꼭! 필독하고 시험을 보길 권면한다.
문항수는 3개 파일 합해서 500여문항이 넘는다.

바로여기에서 수검자는 손쉬운 유혹에 빠진다.
"500문제만 다 풀어보면 시험 보겠네...."
SCJP너무 우습게 보지 않기 바랬으면 한다.  자만하다 떨어지는 날이면 20만원이 자신의 열정과 함께 날라간다는
사실을 잊지 말고 문제지는 문제지로써, 참고서는 참고서로써 모두 두루 섭렵하고 수검에 임해야 한다는 사실이다.

11월12일.. 토요일..
바쁜 일상속에 공릉에 있는 LG교육센터에가서 시험을 치루었다.
충분한 연마를 했다고 치루었는데 결과는 만족하지 못하는 점수의 pass 였다.

휴...
재법 차가워진 가을 바람이 수검의 긴장을 싸악 가시게 할 만큼 기분 좋게 불었지만
자칫 자만하고 비아냥거렸다가 떨어졌을때 시나리오를 생각해보니 아찔하게만 다가왔다.

이제 나의 현재를 인정해주는 point가 생겼다.
또 다른 point를 만들기 위해 또 노력 할테지만 본 책을 구입해서 SCJP를 볼 사람들에게 권고한다.
쉽게 보지말고 시간이 걸려도 찬찬히 오래 깊이있게 참고서와 문제지를 봤으면 좋겠다.
문제지에는 문과 답만 있다.
문제지가 놓치는 설명을 "인정받는 IT 프로 JAVA 2 SCJP" 가 해 줄 것이다.



아참! 중요한것을 말하지 않았다!

내년부터는 SCJP도 한글로 출제된다고 한다. 원하든 원치않든 영어시험은 올해로 끝일것으로 보인다.

이팩티브 자바는 원제목처럼 "유창하게 말하기"를 목적으로 하지 않는것 같다.
서평자의 경우 단순 말솜씨를 더욱 돋보이게 하기 위해 책을 보고 또봤다기 보다는
정말 내가 개발할때 궁해서 봤기 때문이다.
개발에 임하게 되면 의례 빠지는 갈등이 "과연 이렇게 만든 소스코드가 정상인가?" 하는 의문이다.
컴파일을 하고 구동을 시켜보면 결과는 원하는 데로 출력이 되지만 왼지모를 소스코드는
아무리 개선을 하고 연구를 해도 찜찜한것은 사실이다.
그래서 종종 openSource 코드들을 찬찬히 살펴보기도 하는데 그럴때면 서평자의 경우
심한 괴리감에 빠져들게 된다.
"내가 짠것도 java이고 이것도 java인데 왜 이리 쉽게 이해가 오지 않지?? ^^"
아마도 서평자가 아직 내공이 많이 않아서이기도 하고 openSource들은 그만큼 많은
단련의 과정을 거쳐서 된것일것이다.
본 서적은 이런 단련의 과정중에 중요한 몇가지를 왜 그렇게 구연해야하는지를
친절하게도 구체적인 소스코드를 가지고 사례를 들어주었다.
최초번역서를 보고 공부하게 된게 2003년이니 시간이 생각보다 꾀 많이 흐른것을 볼 수 있다.
다른 새로운책들로 책상이 많은 변화를 가져왔을법도 한데 아직 이책이 내 책상위를 떠나지 않는것은
내가 project를 하나씩 완료해 나갈때마다아직 내 머리가 project의 열기로 식기전에
내가 구연한 방법이 올바른지를 확인해 줄 수 있기 때문이다.

● 구독방법
빈맘으로 한번 읽는다.
  > 책의 구성은 단락 단락 되어있어  단락마다의 이슈제기와 문제 해결 방법등을 이야기 하고 있다.
  > 서평자의 경우 단락의 이슈가 처음 읽을때는 딴나라 이야기 였다. 공감가는게 10개도 안되었다.
     (당신도 그러하다면 나역시 정상인 이다.^^)
project완료후 다시 읽는다.
  > 책은 java의 여러 이슈를 다루고 있다.  하나의 project를 완료했고 거기서 발생한 자신만의 깊은
     상념의 시간이 필요할것이라고 본다.   바로 이때!! 이책을 봤으면 하는 바램이다.
     project에서 장고하지 않고 일정에 밀려 짧게 생각하고 넘어가벼렸던 메소들의 사용법을
     누군가 다시 집어주는것이다.
     음..
     물론 이단계에서 봐줄만한 책은 리펙토링도 있을것이다. 함께 복용하면 좋을것 같다 ^^

Project가 끝났다고 개발이 완료된것은 아니다.
이땅의 많은 개발자들은 Project완료후 또다른 Project를 대해야 하는 밴딩머신앞 기술자 일 수 있다.
밴딩머신을 떠나지 않는한 우린 지속적으로 Project를대하게 될것이고 비슷한 문제를 대하게 될것이다.
이제 그 비슷한 문제점을 습관이라고, 이전 Project에서 성공적으로 잘 돌아갔던 프로그램이라고
말하지 말고 개선의 여지를 찾아봤으면 좋겠다.
 책에 나온 57개의 항목이 모두 맘에 와닫으면 정말 대단하신 분이다. (박수^^)
 하지만 서평자 처럼 잘 몰라도 음냐.. 그냥 Project가 하나씩 완료될때마다 보고, 또한번 봤으면 하는책이다.

오늘도 진화를 거듭해하는 당신께 응원을 보낸다. 홧팅^^


Extreme Programming Installed XP도입을 위한 실전 입문
빨간책!
불온(火溫^^ [열정적])서적이면서 선동을 유도하며 구체적인 행동강력이 담겨있는 빨간책!!
Extreme Programming Installed (XPI) 는 구체적인 실행을 위한 가이드 라인이라 볼 수 있는
빨간책으로 처음 나에게 다가왔다.
 
세상에는 XP라는 이니셜을 달고있는 많은 이론들이 있지만 그중에 XPI는 XP의 무엇을 위해
태어나게 되었고 누구를 위해 이야기 하고 있으며 최종 종착지는 어디일까?
 
론 제프리즈는 XPI의 탄생을 떠벌이 기획자혹은 엔지니어들로 인해  왜곡된 XP를 바로 펴려고
자신이 경험한 프로젝트를 중심으로 본 서적의 이야기를 풀어나가고 있다.
XP는 보다 지능화되고 향상된 프로젝트를 만들어내고 개발자에게는 "배웠구나! 얻었구나!" 하는 보람을 주려고 탄생되었다고 생각한다.

하지만 몇몇 떠벌이들이 XP의 취지를 무시한체 XP를종이 몇장에 서술해 가며 되려 고객과 관리자, 개발자들을 고생시키고 있다.
바로 이 책은 C3 (크라이슬러 급여관리) Project를 배경으로 XP가 어떻게 전계되었는지를 이야기한다.
책에 등장하는 3명의 인물은 개발을 경험한 컨설턴트이다.
그들은 고객이 일의 진행사항을 보고 싶어하고 이런 저런 기능들이 추가되길 바라지만
돈주도 말못하는 애로사항을 이해 해주었고,  관리자가 관리는 하지만 별 성과없이 스트레스만 받는말못할 사정도 풀어주려고 하였고 , 개발자의 피패함을 방지하고 보람찬 일상이 되도록 배려해주고 있다.

이말을 다시 풀이하자면!!
진정 XP는 개발자에 국한된것도 아니고 관리자, 고객에게 국한되지 않는 IT전반에 걸쳐
Project라는 미명아래 움직이는 모든 사람을 위한 방법론 인것이다.
 
● 구독방법
본 서적은 다음과 같은 구독방법을 권고한다.
만일 이와같은 방법으로 구독한다면 당신의 회사는 변화하게 될것이다.
 
1. 최초 개발자가 먼저 읽는다.
   - 개발자가 먼저 읽고 각각의 중요한 부분에 연필로 믿줄을 긋고 자신의 의견을 달아놓는다.
   - 개발자는 이때 적당한 tool이 뭐가 있는지 함께 기술하는게 좋을것 같다.
 
2. 두번째로 관리자가 읽는다.
   - 개발자가 다 읽은 책을 관리자가 받아 개발자의 사상을 이해하며 자신이 보기에 중요한 부분을 믿줄 긋는다.
   - 관리자는 개발자의 생각을 읽으려고 노력을 한다면 이보다 더 좋은 효과는 없을것 같다.
 
3. 세번째로 고객(갑)이 읽는다.
   - 개발자와 관리자가 다본 책을 봄으로써 고객은 권한과 권리의 범위를 정확하게 이해한다.
   - 책임의 입장으로써 고객의 투정 한마디가 생각보다 얼마나 크게 작용하는지를 간접적으로 보게 되는것이고 이러함으로써 정말 프로젝트를 바라보는 시선을 갖춘다.

훌륭한 프로젝트는 개발자 한사람으로 만들어 지지 않는다.
고객, 관리, 개발자 모두 훌륭해 져아한다.

하지만 이런 방법론을 함께 공유하기란 쉽지 만은 않다.
그러기에 지각있는 분이 읽어 본 책이 무술교본에 나와있는 행동하나 하나임을 알고 따라하길 바랬
으면 좋겠다.
 
 
"XP실천사항들을 그 쓰인데로 완전히 마스터 했을때에 단순한 법칙을 넘어서 형을 깨트리고 자신만의 형을 창조하시게 될겁니다."
(책속에서...)


1999년에 들어 많은 재조업들이 IT시장의 활성화에 힘입어 ERP를 도입하게 된다.
그당시 기업환경은 단위항목에 전산화가 적용되이있는터라 진정한 통합을 위한 과정을 비롯
부서간 상호관계의 필요성이 대두된것이다.
이때즈음 ERP는 "매직카펫"과 같아서 ERP로 올라타기만 하면 어디든 자유로이 갈 수 있을것만 같았다.
 
2005년 그로부터 벌써 6년여가 흘렀다.
ERP초창기에 도입한 부서들은 정착화가 되어있지만 중반에서 말부에 ERP를 도입한 기업들은 많은 문제를 겪게 된다.
자사가 도입한 EPR는 "매직카펫"이 아니라 나르지 않는 엉성한 양탄자에 불과하다는 사실을 알게된다.
"ERP 제품은 경쟁사와 동일한데 카펫이 나르지 않는다니..."
"무엇이 문제인가? 무엇이 문제였을까?"
 
아마 이런이슈가 너무 많이 부각되어 이런책의 탄생이 필요하게 되었을지 모른다.
 
책은 ERP도입, 적용, 활용 등에 있어 각 부서마다의 역할과 CIO와 CEO 등과 같이
경영조직에 적극적인 대응을 요구하고 있다.
각부서는 통합을 위한 도메인 설정과 정확한 자기업무 진단의 과정을 거쳐야 한다.
하지만 이 과정에서 업무진단의 미숙과 Process로 뽑아낼 구분에 대한 모호성때문에 ERP도입이 어려워지게 된것이다.
이는 ERP실패의 원인이 되는것이다.
책은 실패 point를 짚어내고  성공적인 ERP로 가기위한 helper역할을 해주고있다.
하지만 안타깝게도 책의 저자가 일본인이라는 사실을 알아 두었으면 한다. (기업조직이 일본임)
(아무래도 기업의 특성이 일본이기에 우리나라같이 일본+미국의 혼용 기업구조에서는 무비판 도입 보다는 필~! 을 느껴야 할것입니다.)
 
책은 크게 2부분으로 나누고 있다.
ERP성공을 위한 필수조건 / ERP성공을 위한 부서마다 해야할일 (구매, 생산, 판매, 인사, 회개, 업무, 기술 ..)
 
제 1부
1부는 ERP 전반에 걸친 성공의 조건들과 공식에 대해 이야기 한다.
- 빅뱅도입과 점진적 도입
 전사적으로 한꺼번에 고생해서 빠르게 도입해서 비용감소를 최소화 시키는것을 "빅뱅도입"이라고 한다.
 하지만 "점진적도입"을 하게 되었을 경우 기존의 시스템과 병행운영을 통한 비용발생도 역시 위험이라고 말하고 있다.
 물론 경영조직의 선택이지만 이리가든 저리가든 수고는 반드시 따라야 한다는 점이다.
- ERP는 CEO, CIO가 직접 챙겨야 한다. (130p의 ERP 성공기업의 특징)
 CEO가 직접챙겼을때와 그렇지 않았을때의 차이가 너무 확연하게 나타난다.

제 2부
에 대항하는 부분은 부서마다 할일을 이야기 한다.
정말 지극히 업무적인 부분이기 때문에 업무에 대한 도메인 이해없는 서평자의 경우 몇번이고 되돌아 봤던것 같다.
 
책은 길을 보여주지는 못한다 하지만 길을 느끼게 해주고 내 가는 길이 맞는지 틀린지 판단하게 해준다.
이미 ERP를 활용하고 있는 기업이든 부서든 본 책을 통해서 자사의 ERP도입에 자사평가를 해보는것도 좋을것 같다.
개념으로만 존재하는 ERP를 의지만으로 도입해 어려움을 겪고 있다면
나르지 못하는 ERP 매직카펫을 수선해서 많은 기업들이 가고싶은 그곳을 향해 잘 날라다녔으면 좋겠다.


정말 오래간만에 서평을 쓰게 된다.
한동안 개발에만 열을 올렸더니 책을 볼 기회조차 허락되지 않았다.
지난 실용주의 서적에 대한 Junit에 관한 서평을 쓴 이후로 '실용주의'에 관한 관심이 쏠려
3번째 서적인  "프로젝트 자동화"에 대하여 이야기를 해보려고 한다.
제1편 CVS와 제2편 junit까지 정말 구독자의 기분은 상쾌하게 만들어줬던 실용주의 마지막 3번째는
과연 얼마나 기분좋게 할것인가 기대하는 맘으로 읽기 시작 했다.
결과부터 이야기 하자면 서평자는 주소를 잘못 잡고 있었다.
 
'프로젝트 자동화'가 말하는 것은 표지에 디자인 'ANT&log4j'에 대해서 크게 말하고 있지 않다.
만일 'ANT&log4j' 를 위해서 본 책을 기대에 부풀어 사보게 된다면 약간의 실망을 감내 해야 할 것 이다.
ANT는 깊이가 있어질려다 말았고 log4j는 후반부에 5페이지 정도 분량으로 밖에 소개되고 있지 않다.
정말 'ANT&log4j'에 관해서 알고 싶다면 본 책의 역자가 추천하는 서적
'Java Development With Ant (자바의 또 다른 멋진 도구 Ant 앤트 )'를 보았으면 한다.
 
서평자는 헛된 기대에 책을 보고 예상했던 내용이 크게 부각되지 않아 조금 당황스러 웠다.
이유는 책을 모두 다 보고 책 표지를 다시 보니 불연듯 책 타이틀을 보니 책은 정말 제목데로 만들어 졌다.
'프/로젝/트/자/동/화'
그렇다. '프로젝트 자동화'가 추구하는것은 프로젝트를 자동화하하기 위하여 필요한 ANT, CVS, log4j, ... 등등과 같은
프로젝트 자동화를 위해 사용될 수 있는 도구들을 적절하게 활용된 사례를 기술해 놓았다.
 
실질적인 프로젝트(DocumentManagement System)를 바탕으로 ANT와 CVS, 그리고 5페이지로 언급된
log4j를 사용하고 있는것이다.
 
책 제목은 책 내용을 완벽하게 커버하고 있다.
서평자처럼 "디자인된 표지에 속아 ant는 이정도 깊이인가? log4j는 겨우 5페이지라니.. " 하는 실망감을
가지지 않았으면 좋겠다.
 
자 이제 책 내용을 살펴보도록 한다.
 
● 빌드 (Build) & 릴리즈
책은 미국문화에 이해가 가장 쉽도록 ant를  설명하고 있다. '크루즈컨트롤러' 가 그 예인데 크루즈컨트롤어의 의미는
책 85p에 언급되어있지만 우리나라 문화라면... 아마 리니지 AutoMouse가 아닐까 하는 생각도 해본다. ^^
여하튼 ant의 주된 역할은 프로젝트 진행에 있어 그 어떤 작업환경에서든 동일한 결과를 도출해 낼 수 있도록 하는
"빌드(Build)"에 관점이 기울어져 있는것있다.
 
책이 DMS 기반으로 있기 때문에 ANT의 깊고도 복잡 다단한 부분까지는 접근하지 않고 있다.
아마 불필요하기 때문일것 같고 정말 실전에서 쓸수 있는 것만 '프로젝트 자동화'에 다룬것 이라고 볼 수 있다.
 
 
● 디플로이
디플로이 부분은 여태 내가 디플로이하는 방법보다 보다 효과적이고 강력한 디플로이 방법을 이야기 하고 있다.
단순 ANT로 소스코드를 운영에 반영하고 시스템을 한번 내렸다 올리는 손이 많이 가는 (하지만 내가 지금 그렇게 하고 있는..)
방법보다 더 아름다운 디플로이 방법을 이야기 하고 있다.
 
● 모니터링
서평자는 WEB개발자이기 떄문에 모니터링은 콘솔상에서 쌓여가는 로그파일을 보는게 모니터링 기법이라 생각했다.
하지만 '프로젝트 자동화'에서 말하는 모니터링은 이보다 보다 시각적이고 보다 직관적이다.
여기에 log4j는 모니터링의 한 부분으로써 소개가 되어지고 있다. (그러니 5페이지 될 수 밖에...)
 
 
ant나 log4j는 '프로젝트 자동화'의 한 부분이다.
오히려 본 책은 실용주의 서적 제1편이 말한 CVS의 재 언급이 "오호 이렇게 연결이 될 수 있겠구나" 하는 발상을 가져다 준다.
 
표지만 보고 헛된 기대는 하지 말자!
ANT와 log4j는 함량 미달이다. 하지만 '프로젝트 자동화'는 정말 프로젝트에서 필요한것만 담았다.
ant도 log4j도 cvs가 프로젝트에 어떻게 적용되고 어떻게 사용되는지  다양한 기법들을 담았기에
학문으로써가 아니라 /사/용/할/목/적/으/로  본 책을 접한다면
실용주의의 결정판! 그 '프로젝트 자동화' 가 실망스러움이 아닌 다양한 아이디어를 줄 것이다.
 
서평이 끝났다.
서평자가 보기에 이책이 프로젝트에 필요한 이유는 아래인것 같다..
 
----------------------------------------------------------------------------------------
코드가 길면 길수록 코드를 제대로된 상태로 유지하기 위하여 계속되는 통합의 작업이 더 절실하게 필요하다.
              '프로젝트 자동화 98p'
----------------------------------------------------------------------------------------


중급 개발자가 고급 개발자로 가기 위한 서적!!
 
refactoring java는 프로그램을 짜는 방법이 들어가 있다.
메소드를 선언하는 방법 sub메소드를 만들어 내는 방법, 그리고 그 sub메소드를 호출하고 관리하는 방법..
너무나 고맙게도 고급개발자 (마틴파울러)는 본 서적을 통해 고급! 바로 그들만의 리그에
중급 개발자들을 참여시키고자하는 다분한 의도를 가지고 있다.
 
refactoring java는 이미 많은 서평자들이 엇갈린 의견을 내 놓은것처럼
"해도 그만 안해도 그만" 에서 부터 "꼭 해야하는것!" 하는 다양한 의견을 나타내고 있다.
그도그럴것이 잘 구동되는 소스코드는 건드리지 않는다! 라는 전재 하에서 본 서적은 이야기를 시작 하고 있다.
 
그럼? 잘 구동되는 소스코드를 뭐할려고 건드리는가?
이문제에 답은 refactoring은 누구를 위한 것인가? 라는 질문이 더 잘 어울린다.
refactoring 은 관리자도 스폰서도 위한 작업이 아니다.
refactoring 은 순수 프로그래머들을 위한 작업이다.
 
프로그래머들은 많은 위험에 노출되어있다.
납기일 준수나,  촉박한 일정에 떨어지는 폭탄과도 같은 요구사항들 그리고 가장 기본으로 요구되는 안정된 운영!!
많은 사람들은 프로그래머를 마치 고장난 자판기마냥 동전 몇개만 넣으면 어러가지 음료수를
한꺼번에 쏟아내는줄만 아는데 안타깝게도 프로그래머들은 자판기가 아니라 사람이다.
 
자.. 훌륭한 사람이기에 쏟아질것 같은 요구사항에 미리 미리 대응해 보자.
잘 구동되는 소스코드도 정리해보도록 하고 확장에 용이하도록 분석과 분해를 해봤으면 좋겠다.
납기일이나 촉박한 일정이 다가올것을 염두하고 선수학습하는 맘으로 구조를 짜 맞춰 보자!!
바로 이런 일들을 진행할때 곁에두고 싶은 참고서가 있다면 서평자는 refactoring java를 추천하는 바 이다.
 
● 구독방법
1. 서문과 도입의 글을 필독한다!
    > 모든 refactoring 의 사상이 담겨져 있다.
    > refactoring을 운운하시는 분들은 모두 서문과 도입을 인용 하는것이니 개발자는 꼭! 봤으면 한다.
2. 첫장 부터 타이핑 해가며 한장 한장 따라 시도해본다.
3. 아주간혹 이해가 안간다 하더라도 그냥 .. 그냥 물흐르듯 보자.
 
자세는 키보드옆에 활짝 펴 두고 글도 보면서 차근차근 본다.
 > 정말 이때는 바둑의 기보를 보는 자세가 요구된다. 내가 앞에서 뭐 했는가를 잊어먹으면 곤란해진다.
 
● 책은 이것보다 훨씬 많은것을 동기유발 시킨다.
refactoring java는 UML기반으로 설명을 하고 있다.
서평자 역시 refactoring java를 보고 자주 등장하는 classDiagram 이나 화살표들이 너무 궁금해 RUP책을 보게 되었다.
궁금증이 해결된것은 아니지만 하나의 학습은 다른 학습을 유도하는 시너지 효과를 발휘하고 있다.
 
refactoring java는 코드네이밍 규칙을 이야기 하고 있다.
프로그램 만드는데 작명과 워드랩을 하는 수준은 깔끔과 명확성을 가지고 있다.
refactoring이 전부 내것이 되지 못하더라도 깔끔한 소스코드를 만드는 보너스 팩은 받아누릴 수 있을것이다.
 

사실 서평자는 2003년도 같은 회사 직원 한사람이 이 책을 틈나는 데로 탐독하는것을 봤다.
당시 그는 중급개발자였지만 지금은 고급개발자가 되어있고 지금도 멋진 개발자로써 훌륭히 자기일을 하고 있다.
초입에 들어설때도 그는 면티에 훌렁한 반바지를 입고 빡빡머리에 자유분방함을 가졌지만 소스코드는 그런 외모와는 상관없는
향기를 담고 있었고 알수없는 고수(?)의 흔적들을 볼 수 있었다.
그당시 그가 이 책을 그토록 보고 또보고 하는 이유를 몰랐다.
하지만 그 결과는 나타나고 있고 그 향기는 시간이 지남에 따라 더욱 진하게 퍼지고 있다.
꼭! 본 서적이 원인이였다고 볼 수는 없지만 그래도 그런 그의 향기가 가장 배어나오는게 본 서적이라 위의 예를 들어본다.


서평자는 전에 스티브맥코넬리의 서적을 모두 탐독코자 하였다.
이번에 평하고자 하는 서적은 "소프트웨어 생존전략!"
이름도 그럴듯한 Servival Guide 책이다.
 
2005년3월10일에 구입해서 보기 시작해서 오늘까지 봤으니 거의 2주정도 시간이 걸렸다.
소설책류의 2시간에 비하면 어마어마한 시간이 들어갔다.
서평자는 스티브맥코넬리의 깊은 사상을 이해하려하였고 그가 생존전략! 이라는 거창한 이름을
붇인 까닭을 알고 싶었다.
결과를 미리 말하자면 진정 맥코넬리는 프로젝트의 모든 구성원들이 만족하고 행복해하는
유토피아를 본 서적에서 기술해 놓았다.
 
- 스폰서에게는 프로그램이 완성되어져가는 과정을 보면서 자신의 의견을 적용 될 수 있도록 하였고
- 관리자에게는 잘짜여진 틀 안에서 스폰서와 개발자들사이의 훌륭한 PM 이 되도록 하였고
- 개발자에게는 프로젝트 완료후 기술의 스킬UP과 회사에 강한 소속감을 가질 수 있도록 하였다.
 
정말 놀라운 서적이 아닐 수 없다.
스티브맥코넬리는 3인칭 전지적 관찰자 시점에서 프로젝트에 관여된 3계층(스폰서, 관리자, 개발자) 모두 만족시켜주는 가이드를 제시한것이다.
 
하지만 본 서적이 그토록 유명하게된 까닭은 단지 3계층을 커버하는 수준이였다면 그만큼 유명해지지는 않았을 것이다.
서평자가 보기에 SPSG에 투입되고 연관되어있는 방법론과 서적은 실로 방대하다.

스폰서 / 관리자
 > ROI (투자수익률)
 > 피플웨어 (톰디마르고,  티모시 리스터)             
 > 리스크관리 (톰디마르고,  티모시 리스터)
 > Professional 소프트웨어개발 (스티브맥코넬리)

 
개발자
 > Extreme Programming Installed  (론 재프리즈)
 > Junit (데이브 토머스)
 > TDD (캔트백)
 > RUP (개발방법론: 로즈)

기타 등등..
이런류의 서적들을 모두 총 종합시킨 전과목 참고서 수준이다.
한장 한장 넘기면서 "이 주제는 어디서 본것 같은데..." 하는 느낌과 냄새(?)가 난다는 것이다.
피플웨어나 마일스톤의 경우는 (피플웨어,리스크관리)책 냄새가 나고
스모크테스트나 일별 test계획을 세워서 프로토타이핑을 만들어내는것은 (XPI, TDD, JUNIT..)책 냄새가 난다.
 
만일 위에 언급한 사항들을 모두 보신 분들 이라면 썩 이 책이 신선하게 다가오지는 않을것이다.
하지만 구술도 꽤어야 보배라고 모든 단위 항목 학문을 하나로 꾀어내는 능력은 정말 탁월하다고 칭찬할만 하다.
 
스티브 맥코넬리는 프로젝트 진행단계 단계마다 가장 적당한 방법론의 소개, 행동 방법 등을 기술하였고 프로젝트의 규모에 따라 예외사항까지 기술해 놓았다.
제목 그데로 Guide인 샘이다.
얼마나 가능할련지는 모르지만 가능하다면 내가 참여하는 모든 프로젝트에 본 가이드데로 시행하고 싶은 욕심이 생긴다.^^
 
자 책의 서평을 정리하는 뜻에서 중요한 한가지 힌트를 주고 가름하려고 한다.
스티브맥코넬리는 개발자나 관리자가 움직이는 작은 움직임도 돈으로 계산하도록 하고 있다.
Planning Checkpoint Review를 가장 주의깊게 봤으면 한다.
PCR은 책의 논제가 어디로 흩어지든 항상 중심으로 인도하는 몇개의 끈들중에 하나이다.
PCR은 프로젝트 비용의 10~20%를 확보할 수 있고 PCR은 아키텍쳐를 만들어 내는 중요한 레퍼런스이다.
PCR은 요구사항을 개발!! 하는 도구중에 하나이며    PCR은 완료보고서의 멋진 시작이다^^


리스크 관리를 사보게 되었다.
code Complete책을 보다가 그 방대한 두꺼움에 압박을 당해 가벼운책으로
진정된 마음을 달래보려 빈맘에 리스크 관리를 보게된것이다.
 
책을 접하게된계기는 "리스크관리"의 저자가 전 피플웨어 저자와 동일했기 때문이다.
본 서평자는 책을 마구잡이식 읽기보다는 저자가 생각과 사상을 이해하려고 하기때문에
주로 저자중심의 그룹별 책읽기를 선호한다.
 
"피플웨어"에서 보였던 톰 디마르고와 티모시 리스터는 전화기가 없는 사무실에 훌륭한 사무 환경을
제공함으로써 진정한 개발자와 관리자와의 순수작업공간을 제시함으로써 개발자들로 부터
큰 호응을 얻었다
실제로 복잡한 사무환경과 너저분한 책상에서 깔끔하고 아름다운 제품을 기대하긴 힘들것 같다
   (그래서 필자도 책상을 정리하고 일을 수행하려는 습관을 들이기 시작함^^)
 
다시 본 서적의 원론으로 다가가보자!!
"리스크관리"는 리스크란! 절대 사라질 수 없으며
우리가 원한다고 피할 수 있는 존재가 아니라는것을 인지시키며 시작한다.
직원이 회사를 그만둘 수 도 있고 , 계획이 변경될 수 도 있고, 자금이 딸려 조기 종료될 수 도 있는 다양한 리스크가 있다.
이런 리스크들은 피하는 존재가 아니라 관리의 대상 인것이다.
 
서적 초기에 DIA (Denver International Airport)의  ABHS 구연에 대한 예를 들어주고 있다.
소송관련 컨설턴트인 톰 디마르고와 티모시 리스터는 DIA의 ABHS 프로젝트에 대한 정확히 어디어디가
리스크였고 이 리스크에 대한 책임을 누가 져야하는지를 본서적에서 집어내고 있다.
 
● 사건의 내용
ABHS Project는 납기일을 준수하지 못하여 소송에 휘말리게 된다.
매일 리스크 비용이 발생하기에 Denver시는 해당 문제에 대한 비용청구를 하게 된다.
과연 누가 이 리스크 비용을 감당하게 될것인가??
 
2명의 저자는 ABHS Project 리스크해결을 위해 다양한 접글을 시도한다.
다른 공항의 개발사례도 분석했는지 유무도 파악하며
충분한 자금이 투입되었는지 여부도 확인 하고
일정에 대한 관리는 잘 이뤄졌는지
개발을 위한 요구사항 명세서 도 살펴보고
개발자가 과연 이것을 개발 할 수 있는 정도의 스킬을 가졌는지도 확인하게 된다.
 
자..
소송관련 컨설턴트의 입장에서 실패한 project에 과실 여부를 분석할때 과연 누가 가장 큰 잘못을 했고
누가 그 비용을 담당해야 옳을 것인가??  (이 답은 책에 나와있습니다. ^^ )
 
아직까지 필자가 경험한 project의 이런 리스크 비용은 고스라니 엔지니어 몫이 된다.
영업하시는 분들이 촉박하게 잡은 일정덕에 개발자들을 날을 새고 일을 하지만 납기일 준수는 하지 못하고
그 덕에 온갖 무시와 홀대를 받으며 겨우겨우 1~2달 말미를 받아 드라마같이 프로젝트를 종료한다.
 
2명의 필자는 이런 우리를 위해 리스크를 관리하는 산출근거와 방법들을 설명해 주고 있다.
리스크 산출은 domain에 밀접한 관련이 있긴 하지만 "리스톨로지"를 통하여 리스크를 관리하고자 하는
그들의 높은 의지를 옅볼 수 있다. (실제 적용유무는 글쎄... ^^)
 
이제 서평의 결말이다.
리스크관리가 이뤄지지 않는 조직에서 리스크를 이야기하는것은 선량한 한명의 가슴에 주홍글씨를 세겨넣는것과 같다.
그곳에선 그를 죄인 취급하고 프로젝트 방해꾼으로 총징한다.  (이런곳에서는 리스크를 말하지 말자!!)
 
하지만 정말 건설적인 프로젝트 완료와 성장지향을 원한다면 위험요소를 꼽아내는 그에말에 귀 기울여볼 필요가 있다.
그사람이 "리스크를 이익" 으로 환원시켜줄 연금술사가 될지도 모르니까 말이다.
1 2 3 

글 보관함

카운터

Total : / Today : / Yesterday :
get rsstistory!