| 사실 이 책은 스티브 맥코넬이라는 분이 썼다는 점 하나로 선택했고 번역 또한 성심 성의 것 되어있어 읽는 재미를 배가시켜 줍니다. 저는 현재 수출용 휴대전화기 SW 개발을 담당하고 있습니다. 이제 5년차 직장인이지만 짧은 소견으로 늘 현재의 개발 process의 비효율과 복잡성과 무모성에 환멸(?)을 느끼고 있지만 모든 사람들이 같은 생각을 한다손 치더라도 조직이 비대해지면 실행에 옮기기 어렵고 효과 또한 장기전으로 돌입해야한다는 불안감에 어쩌면 모든 사람들이 모르고 못하는 것이 아니라 알지만 안 하는 것인지도 모르겠습니다. 일단 개발에 착수하고 문제점이 발생할 때마다 수정하는 방식이 우리 나라 기업에서만 자행되는 후진성이라고 생각했지만 미국 기업도 마찮가지라는 곳곳의 흔적을 접하고 나서 역시 쉽지 않은 일임에 틀림이 없다는 생각이 많이 듭니다. 학부 시절 소프트웨어 공학 과목의 중요성을 인지하지 못한채 수강하지 못한 것이 한이 됩니다. 현재 관련 과목을 수강하는 분들이 계시다면 꼭 수강하시길 바랍니다. 아무리 좋은 인력과 기술과 자본이 있다손 치더라도 잘 비비지 못하면 엉뚱한 맛을 내거나 먹지 못할 음식이 나오는 겁니다. 강력히 추천하는 책이며 우리 나라 모든 관련 산업이 한 단계 올라설 수있는 시금석이 되길 바라는 마음 간절합니다. 그리고 또 하나 개발자는 개발자의 역할 즉, R & D에서 D의 역할을 명쾌히 인식하길 바랍니다. |
| 언어 입문서 위주였던 개발서적 코너에서 SW공학서적으로는 처음으로 많은 사람들에게 관심을 끈 책인 것 같습니다. 일부 SI대기업을 제외하고는 SW공학의 불모지나 다름없는 우리나라에서 SW공학이 많은 사람의 관심을 끌기 시작한 것은 고무적인 일입니다. 저자는 이 책을 통해서 왜 SW개발에 공학적 접근이 필요한가에 대해서 역설하고 있습니다. 하지만 그것을 구체적으로 어떻게 해야하는지에 대해서는 이야기 하고 있지 않습니다. 이 책은 SW개발의 공학적 접근의 필요성(Why)에 대한 책이고 충분히 공감했다면 이제 구체적으로 어떻게(How) 해야할지 배워야 할 때입니다. 저자도 소개했듯이 '소프트웨어 프로젝트 생존 전략'은 이책을 제대로 보신 분이라면 꼭 읽어야 할 책입니다. 구체적은 SW 프로세스를 안내해주는 책입니다. 그러나 그것만으로 충분하지는 않을 것입니다. SW 프로세스(혹은 개발방법론)은 남이 가르쳐주는데로 따라한다고 모두에게 정답일 수 없습니다. SW 프로세스에 대한 저자의 관점은 많은 관점 중에 하나 일 것입니다. 많이들 알고계신 XP(eXtreme Programming)이나 RUP(Rational Unified Process) 그리고 CBD (Componet Base Development)는 SW 프로세스에 대해서 각각 다른 것에 중심을 둔 관점을 보여주고 있습니다. XP는 '초보자를 위한 eXtreme 프로그래밍', RUP는 'UML과 패턴의 적용' 이라는 책이 개인적으로 추천할만합니다. 진정 저자가 말한 '바보들의 황금'에 빠지 않으려면 모두 알고 그 조직과 환경에 가장 적합한 프로세스를 스스로 찾아내고 조직해야(tailoring) 합니다. 흔히들 SW개발(특히 SI는) 노가다라고 이야기합니다. 그것은 SW개발자의 스스로 자신의 가치를 비하하는 이야기가 아닌가 합니다. 그것이 노가다라면 노가다가 아닐 수 있도록 SW 프로세스를 개선해야하는 것도 SW개발자의 몪일 것입니다. 비로서 SW개발은 세상 어떤 일보다 창의로운 일이 될 것입니다. |
| Code Complete란 책으로 국내에서 유명한 스티브 맥코넬은 글을 잘 쓰기도 하고 많이 쓰는 것으로 유명한 사람중 한명입니다. 그는 자신이 느끼고 겪은 일들, 자신이 생각한 내용들을 책으로 써서 많은 사람들에게 도움을 주는데, 이 책은 그런 그의 작업 중 평소의 생각을 정리한 책이라 할 수 있습니다. 필드에서 일을 하고 프로젝트 등을 진행해 오면서 자신이 느꼈던 점들을 정리해서 발표한 내용이 이 책이 가지고 있는 특징이라 할 수 있습니다. 그렇기 때문에 저자가 살고 있는 미국이라는 지역에 토대를 두고 있는 이야기들이 대부분이라고 할 수 있습니다. 하지만, 소프트웨어 산업이라는 산업 구조상 범세계적일 수 밖에 없고 우리나라의 대학 제도나 그 밖에 많은 것들이 미국과 크게 다르지 않기 때문에 우리에게 역시 많은 도움이 될 수 있는 서적입니다. 이 책을 읽을 때는 크게 세가지 사항에 염두를 두고 읽는 것이 좋습니다. 저자가 말하고자 하는 것은 단순하게 막개발을 벗어나서 체계적인 개발을 하자는 식의 계몽구호 같은 것이 아닙니다. 저자는 소프트웨어 개발의 향상을 위해서 크게 세가지 것에 중점을 두고 이야기 하고 있습니다. 첫번째로 우리나라에는 거의 알려져 있지 않은 소프트웨어 엔지니어링이라는 개념에 대해서 사례를 들어가며 자세히 설명을 하고 있습니다. 더불어 소프트웨어 엔지니어링의 산출물들을 적용한 다양한 사례를 보이면서 그 효율성을 이야기하고 있습니다. 두번째는 공학적인 측면 그리고 전문적인 측면에서의 소프트웨어입니다. 이 부분에서 저자는 소프트웨어를 개발하는 사람을 다른 전문영역(건축사나 의사 등)에 비교하여 설명하고 있습니다. 그리고 전문적인 소프트웨어 개발을 위하여 인증제도와 윤리규칙의 중요성이 대해서 말하고 있습니다. 실제로 다른 전문영역에는 각각의 인증제도가 존재하고 있으며, 직업별 윤리조항이 존재합니다. 이런 부분은 직업의 전문성 강화에 도움을 줍니다. 저자는 소프트웨어 산업에도 믿을 수 있는 인증받은 개발자들이 참여할 수 있기를 바라고 있습니다. 이러한 부분은 미국에서도 소프트웨어공학 관련 인사들의 노력으로 소프트웨어 관련학과에 대한 공인인증이라던지 윤리규정 제정과 같은 작업들이 이루어지고 있습니다. 국내에도 최근들어 컴퓨터 관련학과들에 대한 인증작업이 추진되고 있습니다. 실용적이고 체계적인 인증기준들만 마련된다면 대학 졸업생의 수준이 전문적인 개발자로 활동할 수 있을 만큼이 될 수 있을것입니다. 세번째는 개인의 역량강화를 위한 개인과 조직의 노력입니다. 저자는 책에서 자신의 회사인 Construx의 PDL이란 제도를 통해서 이 부분을 말하고 있습니다. 저자는 회사에서 자체적으로 개발한 PDL이란 제도를 도입하여 사내 직원들의 소프트웨어 개발 역량을 점진적으로 향상시켜가고 있다고 말하고 있으며, 회사의 사례를 들어 말하고 있습니다. 리뷰에서 상세하게 말할 수는 없지만, 저자의 회사에서는 PDL을 통해 많은 성과를 거두었으며, 이는 CMM의 P-CMM과도 통한다고 볼 수 있을 것 같습니다. 첫번째 저자의 생각은 이미 잡지나 책 등 다양한 매체를 통해서 국내 소프트웨어 업계에 알려진 그리고 알려지고 있는 내용입니다. 이 책에서 우리가 주목하야 할 것은 두번째와 세번째 생각입니다. 전문적인 소프트웨어 개발자로서의 첫단계인 대학에서의 교육, 그리고 개인의 역량강화를 위한 노력과 조직의 조직원 역량강화를 위한 노력. 이러한 것들이 앞으로 필요하고 이러한 것들을 이루었을 때, 높은 역량을 가진 조직으로 그리고 높은 역량을 가진 개인으로 나갈 수 있다고 생각합니다. |
| 현재 소프트웨어 유지 보수 관련된 일을 하는 회사원입니다. 전산 학과를 나와 관련 업무를 하면서 시간에 쫒기어 또는 기존 습성 때문에 일단 프로그램 짠 후 디버깅하는 방법론에 젖어 있다 우연히 이 책을 접하게 되었습니다. 국내 뿐만 아니라 선진국도 우리와 비슷한 개발환경과 과실을 행하는 대목이 잼있었다면 저의 개발론( 일단 작성하고 고치는 )에 대한 저자의 따끔한 충고가 머릿속에 오랫동안 남아 있게 되었습니다. 은빛총알 개념에 대한 비판과 교육 문제, 자격증 문제 등 현 소프트웨어가 지니고 있는 크고 작은 이슈를 논리적이며 체계적으로 설명하였고, 그 해결책 역시 저자 나름의 논리로 이끌어 가는 대목엔 저도 모르게 맞장구를 치게 되더군요. 비록 많은 상황이 북미를 중심으로 기술하였지만, 한국의 많은 학생 및 현업에서 일하시는 분들이 꼭 읽어야 할 서적이라 생각합니다. 소프트웨어 공학에 대한 필요성을 절실히 일으켜 줄 것입니다. 끝으로 이렇게 좋은 책을 매끄럽게 번역해 주신 윤준호씨, 한지윤씨의 노력에 감사를 보냅니다. 별 5개 만땅 추천입니다. |
|
성공적인 소프트웨어 개발을 위한 방법론으로 시작하여 개인.조직의 프로정신, 소프트웨어 전문가의 사회적인 역활 직업윤리의식까지 체계적인 접근을 보여준다. 목표없이 그저 경제생활이나 먹고 살기위해 이 세계에 뛰어든 사람들은 뜨끔할 것이고 조직관리자는 최상의 조직을 갖추기 위해 무엇을 해야하는 지 해답을 얻을 수 있다.
Part 1에서는 전공과 상관없이 무수히 쏟아져나오는 소프트웨어 개발 인재들이 신대륙탐험이 끝나고 개척시대 골드러시가 끝난 상태에 놓여져 있다고 규정하면서 주어진 상황에 경험에 의존하기보다는 좀 더 나은 생산성과 미개척분야를 찾으려는 의지를 요구하고 있다. 단순히 최신 기술을 습득하고 언제나 책을 들고 사는 것도 중요하지만 노력하면 당신이 소프트웨어 업계의 이슈가 될만한 것에 참여하여 표준을 만들거나 발표를 하는 정도로 전문적이 되는 것도 중요하다고 말하고 있다.
Part 2는 개인의 프로정신으로 건축가와 목수에 비유하면서 계층화와 조직화, 팀 전문화를 꾀하고 있다. 또한 소프트웨어 개발자들의 MBTI결과를 소개하여 그들의 문화를 엿볼 수 있게 하였다. 이 장에서 "나만큼 프로그래밍에 흥미를 가진 사람을 찾을 수 없었다"는 저자의 말이 기억에 남는다. 그러나 이제는 그런 혼잣말은 통하지 않을 것 같다. www.computer.org 같은 전문가 모임에 참여하여 고민하고 토론하고 지식공유를 실천하는 여러 열린 프로그래머들과 함께하면 된다.
Part 3는 조직의 프로정신을 다룬다. 책 서문에 역자가 " 자신의 회사 사장님에게도 이 책을 슬그머니 선물한다면.."이라고 권하고 있다. 아마도 Part 3을 생각해서 하는 말인 듯하다. 소프트웨어 개발 개선사례를 제시하고 최상의 소프트웨어 개발과 투자대비 수익률을 높이는 기법들을 소개함으로써 조직발전을 위해 무엇이 필요한 지 체크해볼 수 있도록 구체적인 실행방법을 제시하고 있다.
저자의 회사인 Construx사의 전문성 개발 프로그램은 개인 뿐만 아니라 조직에서 적용가능한 방법들을 제시하고 있다. 아직 업무, 경력, 프로세스 기반이 잡혀있지 않는 신생회사에 있는 나로선 엄청난 충격이 아닐 수 없다. 과연 이런 전문성 개발 프로그램에 어느 정도 부합하는 기업이 우리나라에 얼마나 될까 의문이 든다. 그런 기업이 있다면 지금부터라도 철저히 준비하여 꼭 가야겠다는 생각이다. 그렇지 못하다면 현 회사에서 위의 프로그램들을 나름대로 실현해보고 싶은 정도로 솔깃한 내용들이다.
Part 4 업계의 프로정신
공학의 필요성, 예술, 성숙도를 열거하면서 소프트웨어 공학으로의 진보를 꾀하고 있다. 소프트웨어 업무 강령과 윤리 규범을 소개하면서 윤리적이고 전문적인 가이드라인을 제시하고 있다. 소프트웨어 엔지니어가 윤리적 판단이 필요한 상황에서 적절한 지침이 될만하다.
그래서 제시하는 것 중에 하나는 면허 또는 자격증이다. 의사, 변호사, 회계사 등이 면허가 있는 전문직으로 본다. 전문직은 한 사람의 실수로 인해 다른 사람이나 사회생활에 영향을 줄 수 있으므로 법적인 책임이 따르는 직업이다. 항공관제시스템이나 교통통제시스템 등 실생활과 밀접한 연관이 있는 프로그램들은 조금의 오차도 허용하지 않는 중요한 것들이다. 토목기사나 건축가 등이 책임을 감수하고 건물을 짓는 것처럼, 소프트웨어에도 룰이 정해지고, 면허를 주는 것이 엔지니어나 관리자, 고객, 공공 모두에게 유익한 것이라 말하고 있다.
개발자로서 내가 정진해야 하는 분야를 찾는 데 부단히 애쓰고 있는 나에게, 소프트웨어 개발자가 어떤 역할을 하고, 의의를 갖는 지에 대해 명확히 해주고 멋진 일이라는 자부심과 용기를 준 책이다. [인상깊은구절] 소프트웨어를 디자인할 때 저는 건축가입니다. 유저 인터페이스를 디자인할 때는 예술가이며, 구현할 때는 장인이 됩니다. 하지만 테스트를 할 때는 아마 쳐죽일 놈이 될 것입니다. |
| 맥코넬은 아직껏 날 실망시킨 적이 없다. 오히려 감동을 주어왔다. 이번도 역시 마찬가지다. 번역이 다소 이상한 곳들이 눈에 띄지만.. 나름대로 원문의 의미는 잘 전달하고 있지 않나 싶다. 이 책은 짧은 역사만큼이나 비성숙한 소프트웨어 개발 분야를 타 전문분야들의 성격과 역사 등에 비춰, '전문'이라는 단어에 걸맞는 소프트웨어 개발 방식의 발전 방향을 제시하고 있다. 말뿐인 이상향이 아닌, 상당히 구체적인 예시까지 제공하며, 또한 그의 회사에서 노력하고 있는 수년 간의 경험 사례와 노하우도 함께 풀어 놓는다. 이 책을 읽으면, 지금까지 내가 직접 또는 간접적으로 겪어왔던 소프트웨어 개발 조직들이 얼마나 막무가네였나를 다시금 깨다를 수 있다. 문제는 이런 글들을 소프트웨어 개발자들의 위에 군림하고 있는 구세대(어감이 이상할 수도 있지만) 사람들이 읽고 감흥해줘야 보다 빠른 성숙이 이루어질 수 있다는 것에 반해... 현실은 그렇지 못하다는 아쉬움이다. 어쩌면 이 책에서 제시하는 (또는 또 다른 어떤) 이상향의 실천은 우리 세대에 주어진 임무가 아닌가 싶다. 적어도 십수년의 세월은 더 흘러야할 것이지만.. 나도 조금이나마 그런 세상이 오는데 일조하고 있다고 생각에 조금은 뿌듯한 마음도 생긴다. 나는 이 책에서 제시한 다양한 모델들을 기반으로 내 개인적인 중장기 career path를 수립하고 있다. 그리고 나의 모델은 회사 동료들에게 공개될 것이고, 뜻을 같이하는 사람들의 조언을 모아 함께 다듬어.. 조직의 기본 skill up 가이드화 시키려 한다. |
|
이 책을 4년 전에 읽고 크게 공감하였다. 무엇보다 피라미드를 건설하는 이야기가 마음에 들었다. |
|
이 책은 MS의 빌 게이츠, Linux의 리누스 토발즈와 함께 소프트웨어 업계의 가장 영향력 있는 세인물 중의 한명으로 뽑힌 스티브 맥코넬의 최근 저서로 소프트웨어 업계의 현실과 '소프트웨어 공학 전문가'로 성장하기 위한 개인/조직/업계 차원의 방법론을 구체적인 가이드는 아니지만 에세이 형태로 기술한, 통찰력을 제공해주는 매우 유익한 양서라고 생각된다.
제 1부 '소프트웨어의 늪지대'에서는 소프트웨어 분야의 현실을 '공룡과의 승부', '바보들의 황금', '화물 숭배 소프트웨어 공학'의 은유적 메타포를 통해 예리하게 분석한다.
제 2부 '개인의 프로정신'에서는 프로그래머의 성격 특성을 분석해보고 의식 향상, 커뮤니티 참여, 전문화, 글쓰기 등을 실천할 것을 요구한다.
제 3부 '조직의 프로정신'에서는 소프트웨어 개발 기법을 개선하고 SW CMM과 Construx 전문성 개발 프로그램을 도입할 것을 주장한다. Construx 전문성 개발 프로그램은 스티브 맥코넬이 만든 소프트웨어 엔지니어를 위한 명확한 경력 경로(career path)와 전문성 개발 지원 프로그램으로 Construx 지식영역(CKA)과 4개의 능력 레벨을 조합하여 7단계의 전문성 개발 단계 레벨을 구분하여 각 단계별 필독서, 업무 경력, 교육, 업계 참여 등의 활동 타입별로 관리한다. 다소 개괄적으로 설명되어 있어 구체적으로 이해하기 곤란한 부분이 없진 않지만 이러한 프로그램이 외국에서는 활용되고 있다는 사실을 안 것만으로도 수확이라고 생각하며 추후에 이 부문을 좀 공부할 필요가 있을 거라는 생각이 들었다.
제 4부 '업계의 프로정신'에서는 소프트웨어 공학 전문가를 양성하기 위한 대학 교육 과정, 자격증, 면허제도, 기술사 육성, 소프트웨어 윤리강령 제정 등의 대안을 제시한다.
참고로 먼저 출간된 동 저자의 'Code Complete', 'Rapid Development', '소프트웨어 프로젝트 생존전략'은 이 책의 실용서로 이 책을 읽고 난 후에 접근하면 매우 유용할 것이다.
결론적으로 이 책은 소프트웨어 공학 전문가가 되기 위한 영감을 주기에는 충분하나 소프트웨어 공학 전문가의 정체성(Identity)과 요건에 대한 설명이 부족하고 또 전문가가 되기 위한 방법이 미국의 IT 현실 위주로 기술되어 있는 점이 다소 아쉬움으로 남는다. 그래서 다소 공감하기 어려운 부분이 몇가지 눈에 띈다. 그러나 이 점은 국내 IT 종사자들의 몫이다. 아니 그 역할을 미약하나마 내가 하리라는 결심이 들 정도로 이 책은 넋두리가 아닌 희망을 불러 일으키는 매력이 분명 있다. [인상깊은구절] - 바위를 움직이든 소프트웨어를 만들든 간에, 현명한 팀은 프로젝트 초기에 빠르고 효과적으로 일하기 위한 계획을 세우는 데 시간을 투자한다. - 현명한 팀은 지속적으로 더 효과적인 방법을 찾아낸다. - 전체 소프트웨어 개발팀 중 75%는 무작정 바위를 밀면서 프로젝트를 시작한다. 이것을 '일단 작성하고 고쳐보는 개발'(code and fix development)라 한다. - 소프트웨어 프로젝트 예산의 40%~80%가 초기 결함을 수정하는 데 쓰인다고 한다. - 프로젝트에 비용이나 일정을 품질과 맞바꾸려는 시도는 바보들의 황금일 뿐이다. - 어떠한 툴이나 방법론도(어떠한 '은빛총알'도) 다음 10년에 걸쳐 10배의 생산성을 향상시킬 수는 없다. - 이름에도 분명 소프트라는 단어가 들어 있는 데고 불구하고, 소프트웨어는 소프트하지 않다. 그리고 소프트웨어를 소프트하게 하기 위해서는 비용이 든다. - 개발 방식에는 '프로세스 기반 개발'과 '책임 기반 개발'의 두가지가 존재한다. '프로세스 기반 개발'은 잘 짜인 계획, 잘 정의된 프로세스 등 소프트웨어 공학 기법들을 적용해 프로젝트를 성공시키는 것이고 '책임 기반 개발'은 해당 분야의 최고 인재를 고용하여 프로젝트의 전권을 위임하고 자율적으로 프로젝트를 성공시키는 것이다. 문제는 이를 사칭하는 개발이 문제다. '프로세스 사칭 조직'은 소프트웨어 프로세스의 형태를 그 본질보다 더 중요하게 생각하는 '관료조직'이며 '책임사칭조직'은 결과(긴 근무시간)와 원인(높은 동기부여)를 혼동하는 '착취조직'이다. - 소프트웨어 개발이 어려운 이유는 코딩이나 테스팅 때문이 아니라 소프트웨어의 본질적 어려움인 복잡성, 일치성, 변화 가능성, 비가시성 때문이다. |
|
불과 2달전인가?.. 이와 비슷한... 컴퓨터는 과학인가? 공학인가? 라는 질문을 받은적이 있다.. 그때는 한번도 그런 생각을 해본적이 없어서.. 공학이 아닐까요? 라는 답을 했던 기억이 난다. 이와 비슷한 질문을 오늘 책을 읽으면서 또한번 접한다.. 소프트웨어는 과학 인가? 아님 공학인가?... 질문의 요지를 정확히 파악했는지는 모르겠지만... 소프트웨어는 공학이다 라는 논지로 이해했다. 그럼 과학과 공학의 차이는 뭘까?.. 이책에서는 아주 간단 명료하게 공감하는 이야기로 정의하고 있다... 과학의 목표는 어떤 문제 해결을 위한 그것에 있고... 공학은 그것을 사용하는 소비자와 관계해 있다라는것... 정확히는 기억안난다.. 책을 읽고도 -_- 2시간을 못가는구낭.... 여튼.... 과학자는 어떤 분야에 대해 그 분야만 알면 된다.. 반면 공학자는 어떤분야에 대해 그 분야뿐 아니라.. 조금이라도 연관되어 있는 모든 분야를 알아야한다고 이야기한다.. 동의하고 자시고가 아니라.. 이런 논리라면,.. 난 공학자이고,... 그리고 내 생각과 지극히 일치하고 있다. 그러고 보면,.. 얇은 지식이지만.. 난 참으로 욕심이 많아서.. 이거저거 참으로 많이 보아온거 같다.. 물론 그 양의 1/10도 난 아직 내것으로 만들고 있지 못하고 있음을 인정한다.. 중요한건 역시 대가가 쓴글은 다르긴 다르구나... 내가 그동안 느껴왔던 것들을 아주 간결하게 잘 정리해주고있다.. 정말 자신이 개발자이고, 과학자이고를 떠나서 컴퓨터와 관련된 프로젝트를 한번이라도 수행하거나 수행책임을 가지고 있다면,.. 꼭 읽어봤으면 한다. 그책은 바로.. 오늘 아침에 온,... "프로페셔널 소프트웨어 개발"!! |