한빛출판네트워크

개발자 필독서라 추천합니다. 절판된지 좀 됐는데.. 재판 했으면 하네요.

번역이 좀 미진하긴 하지만, 내용적으로 개발자, 설계자, PM 등 공감할 수 내용입니다.

이 책은 나온지 5년이 넘었지만, 여전히 훌륭한 내용을 담고 있습니다.

책에서는 여러 주의해야할 요소들과 빠른 개발을 위한 다양한 전략을 명쾌하게 설명하고 있는데, 그의 견해를 적절한 예제와 그림을 이용해서 알기 쉽게 전개해 나갑니다. 또한 각 챕터의 내용들이 서로 연관성이 있긴 하지만, 반드시 순차적으로 읽을 필요는 없는것 같고, 그때 그때 필요한 챕터 부터 읽어나가는 것도 괜찮은 것 같습니다.



다른 소프트웨어 공학 책들은 대부분 너무나 이론적이고 추상적이어서 실제 프로젝트에 적용하기 어려운점이 많았습니다만, 이 책은 보다 실제적입니다. 따라서 이 책을 읽고 실제 프로젝트에 적용해 본다면 훨씬 효과적으로 프로젝트를 진행해 나갈 수 있을것입니다.



특히 소프트웨어 개발을 위해 필요한 일정은 실제로 그것을 개발하기위해 요구되는 시간이기 때문에, 그 시간을 단축시키기 위해서는 다른 어떠한 손실을 감수해야 한다는 내용이 기억에 남는 부분입니다. 이러한 점들은 관리부서나 고객들도 알아야 할 부분인듯 합니다.

문득 이 상황에서.. 저는 열심히 일정을 초과한 시스템을 개발중에 있습니다.

개발능력이 낮고, 생산력이 많이 저하되고 있으며, 지금 저의 피부는 아주 건조합니다.

일정이 넘어선 이유는 무엇일까요?

그건 아마도 계속된 요구사항 추가, 그리고, 코딩 실력, 그리고 커뮤니케이션의 문제이다고 생각이 듭니다. 바로 RAPID하게 개발이 진행이 될 수 있도록 초반에 잘 잡고 가야되는데, 여전히 고객은 요구사항을 주고 있지요.



좋은 곳에서 많은 돈을 받으며, 나에게 적절히 맞는 일보다는 아무래도 치열하고, 상대적으로 적은 돈을 받으며, 나에게 챌린지(여태 해보지 못했던 일)한 일이 앞에 놓여 있지요.

그리고, 고객은 나에게 많은 걸 요구하고, 어서 빨리 프로토타입을 내어놓고, UI에 대해서 꼼꼼하게 보며, 자신에 맞는 방법을 선호하려고 합니다.



여러분은 어떤 방법을 취하시겠습니까?



능력있는 사람을 투입한다. 처음부터 다시 요구사항을 뽑아낸다. 도구를 잘 사용한다. ??

1시간동안 오락을 해서 동기를 부여한다. 적절하게 시간을 분배하고 스케쥴링해서 적절하게 시간에 맞춘다??

저 같으면, 이래이래해서, 일정을 조금 더 늦춘다는 현실적인 사람입니다..



머 방법은 많습니다. 저는 이 쾌속 개발 전략에 나오는 책은 바로 이런 문제점들을 잘 해결하려고 나온 책입니다. 소프트웨어공학 측면에서 최대한 효율적인 방법론을 제시하고 있습니다.

일정내에 끝내야 한다는 크리티컬한 부분은 이 책은 강조를 하고 있지요.



상황에 따라 맞는 부분도 있고, 안 맞는 부분도 있는 듯 싶습니다. 그래도 교과서는 늘 정석이어야 하기 때문에 이 책은 교과서적인 내용이고, 많이 도움이 되는 것 같습니다.



번역부분이 약간 정도 어색하긴 했지만, 역자들이 상당히 노력한 부분들이 보입니다.

(강컴에 올린 제 서평을 발췌하였습니다.)

조그만 규모의 개발 회사에서는 개발을 얼마나 체계적으로 하는가보다는 얼마나 빨리하는가에 더 역점을 두는 경우가 있다. 그래서, 개발 계획을 수립하는데 시간을 거의 투자하지 못하고 개발에 임하는 것이 사실이다. 하지만, 이렇게 하는 것이 꼭 개발 시간을 단축시키는 것은 아니다. 오히려 잘못된 개발로 나중에 더 많은 시간을 빼앗기게 될 수도 있기 때문이다.

이 책은 개발 프로젝트에 있어서 고려해야 하는 모든 부분에 대해 체계적으로 잘 정리되어 있는 책이다. 단, 번역이 다소 매끄럽지는 못한 부분이 좀 아쉽기는 하지만, 개발자라면 반드시 한번쯤 읽어보아야 할 책인 것 같다.

원서를 같이 구하게 되어 번역서를 주로 하고 이해가 잘 안되는 부분에서 원서를 참고하여 비교하며 읽고 있는 중입니다.



100페이지 정도 본 상태로 서평을 쓰는 것도 한심스러워 보이지만 번역서를 읽는 것을 포기하게 될 듯하여 서평을 적습니다.



원서의 내용은 구구절절 감동으로 와 닿습니다. 하지만 번역서는 그 감동의 반도 제대로 전하지 못합니다. 번역이 엉터리라서가 아니라 번역서라는 태생의 한계로 느껴집니다.



예를 들어 4장의 "감독"절을 보면 원서에서는 "Tracking"으로 되어 있습니다.

나름대로 부드러운 번역을 위해 "의역"을 해 놓은 것 같은데 문맥상으로 의미가 완전히 바뀌어 버렸습니다. "프로젝트의 진행상황 추적"을 뜻하는 "Tracking"이 어째서 "감독"이 되어야 할까요. 그래도 번역서만을 본다면 나름대로 의미가 통하는 느낌입니다. 그만큼 신경을 썼다는 얘기겠지요. 하지만 차라리 약간 어색한 느낌이 들어도 "추적"이나 "진행상황 추적" 등의 형태로 그 의미를 명확히 전달할 수 있도록 하는 쪽이 더 좋았지 않았나 싶습니다. 물론 장단점이 있겠지만 말입니다.



읽는 내내 이러한 것들을 많이 접하게 됩니다. 원서 자체가 워낙에 표현들이 절묘하기 때문에 그 세세한 의미를 멋드러지게 국어로 표현하기가 힘이 듭니다. 번역 오류로 등록해 보려고 나름대로 고심해 봤는데 잘 되지가 않더군요.



그래도 참 안타까운 것이 그러한 한계가 있는 중에서도 약간만 더 신경을 썼더라면 좋았을텐데 너무 의욕이 앞섰는지 아니면 오히려 의욕이 부족했는지 훌륭한 의역속에 녹아있는 무신경함이 읽는 내내 신경을 긁어 대는 것입니다. 나름대로의 흐름은 이어지지만 그 의미가 많이 와전되는 느낌일까요. 일종의 오역이랄 수도 있겠으나 의도된 번역인 것 같기도 합니다.



번역서만으로도 훌륭하고 번역도 상당히 잘 되어 있다고 생각되지만 역시 원서의 그 카타르시스를 느낄 정도의 놀라움은 많이 퇴색된 느낌입니다. 원서의 감동에 밀려 별 4개를 주면서 원서를 읽어 보기를 적극 권합니다.

소프트웨어 업계에 발을 디딘지 얼마 안된 나로서는 프로젝트를 진행하는 것이 긴장의 연속이다. 대수롭지 않게 여겼던 작은 실수가 큰 사건으로 되고나서야 탄식을 짓는 사람이 나 뿐만이 아니라고 생각한다. ^^



이 책의 내용은 선진화된 프로젝트 위험관리방법과 쾌속개발에 대한 가이드라인을 제시한다.

물론 한국 소프트웨어 업계, 특히 일정이 빡빡한 SI업계에서 일일 테스트와 빌드같은 개발법을 소화해 내기란 어렵겠지만. 선진화된 개발 프로세스를 한가지씩 적용해 가면서 느끼는 재미도 쏠쏠하다고 생각한다.



한번쯤 읽어보고, 상사나 동료들에게 권해 줄만한 책이라 생각한다.

책 뒤편에 인용되어 있는 아마존 고객의 서평이 뻥이 아니었음을 공감하게 되는 책이군요 ...^^



"프로젝트 데드라인 ..."이 책 부피도 그렇고 들고 다니면서 출.퇴근시 지하철에서 즐겁게 읽을 수 있는 책이라면 이 책은 부피도 그렇고 내용도 그렇고 그 아마존 고객의 얘기처럼 사무실과 집에 한 권씩 놓고 짬짬이 읽어도 좋을만한 책인 듯 싶습니다. ( "프로젝트 데드라인 ..."이 가볍다는 얘기는 물론 아닙니다. 말 그대로 책 부피만 그렇다는 얘기죠. )



1/3 쯤 읽은 듯 싶은데 매 장 내용이 가슴에 콕콕 박히는군요. 특히 "전형적인 실수"와 "위험관리"에 관한 장은 목록 정리해서 책상 앞에 붙여놔야 되겠다는 생각이 들 정도입니다.



그런데 읽다가 궁금한 부분이 있네요.



41p 의 "상승작용"이라는 항목에 보면 "재사용 가능한 컴포넌트를 관리하는 그룹을 둔다면, 그 그룹이 ... " 이라는 부분이 있던데 이러한 그룹을 조직 내에서 따로 운영하는 것을 아직 경험해보지 못해서 과연 이런 그룹이 어떤 식의 구성과 역할을 한다는 것인지 감이 잘 안오더군요.



게다가 좀 더 혼란스러운 것은 원서에는 "a reusable-components group can help to enforce ..." 이라고 되어 있던데 제 독해 실력으로는 이것이 "조직 내 특정 그룹"이라고 보기보다는 말 그대로 "SW적인 컴포넌트 그룹"이라고 여겨져서요.
제 한글 독해와 영문 독해 중 어느 쪽이 문제일런지요? 답변 꼭 부탁드립니다 ^^;

프로젝트 초기, 누구나 쾌속 개발을 꿈꾸지만 프로젝트 데드라인은 다가오고, 딜레이에 딜레이..

결국은 개발자는 말도 안되는 일정을 맞추기 위해서, 일정에 자기 몸을 끼워맞추는 일을 반복하고 말죠.

어떠한 책의 소개에서 이 책을 자기 회사의 팀장에게 선물해주고 싶다는 글을 읽은 적이 있는 것 같은데, 저는 동시에 투입되는 사이트의 클라이언트분들에게도 하나씩 선물하고 싶습니다.

"시스템이 빨리 개발되길 바란다면, 지킬 것은 지켜야 한다고..." 이 말과 함께...

책을 읽고 느낀 바가 몇가지 있다면, (이것만은 모든 사람들이 알았으면 합니다. 특히, 개발자가 슈퍼맨인 줄 알고 있는 클라이언트 분들..)

-불가능한 것은 어떻게 해도, 불가능한 것이다.

150키로까지 달릴 수 있는 차가 아무리 발버둥을 쳐도 200키로를 넘을 수 없듯이, 최소한 1년이 걸릴 프로젝트를 6개월만에 마친다는 것은 불가능하다.

-속도는 무언가를 희생함으로서 얻어질 수 있다.

짐을 잔득 실은 트럭이 130키로 이상 속력을 얻으려면, 짐을 덜어야만 하듯이, 프로젝트의 마감 속도를 빠르게 하고 싶다면, 기능 감소, 비용 추가 등 희생을 감수해야 한다.

스티브 맥코넬 씨의 책을 이제 Code Complete와 함께 두번째 읽는 책이지만, 읽을 때마다 대단함을 느끼게 합니다. 동시에 제 자신이 많이 부족하다는 것도 함께...

방대한 참고자료와 통계 자료로 집결된 이론들...



이쯤에서 제생각으로 마무리 짓는다면,

개인적인 생각이지만, 저자는 쾌속개발을 권장하고 있는 것 같지는 않습니다. 다만, 정확한 일정, 비용, 자원 측정, 프로젝트 분석 등을 통해서 얻어진 기본적인 자료를 토대로 불가능한 것, 가능한 것을 가려내고, 확실한 입장 표명으로 클라이언트에 의해 끌려다니며 정해진 일정에 휘둘리지 말 것을 당부하고 있는 듯 합니다.

그리고, 쾌속 개발은 밤샘 등의 몇몇 개발자의 공명심으로 얻어지는 밤샘등의 초과일정으로 얻어지는 것이 아니라

기능 감소, 비용 추가 등 무언가를 희생해야만 가능한 것이다라고 말하고 있습니다.

그러다면, 왜 쾌속 개발 전략이라 이름을 붙힌 것인가..

이런게 아닐까요...

"지켜야 할 것만 지킨다면, 최대한의 성과를 얻을 수 있을 것이다"



읽으면서 절로 고개를 숙이게 만드는 책이네요...