이 책은 "Code Complete"로 유명한 스티브 맥코넬이 지은 책이고 특정기술이 아닌 소프트웨어 개발에 대한 얘기를 한 책이다. 어떻게 보면 방법록적인 부분과도 관련이 있다고 해야할까.... 기술적인 것들도 중요하지만 나는 이런 부분도 관심이 많기 때문에 좀 편히 읽어보고자 집어 들었다.
스티브 맥코넬은 국내에서도 컴퓨터학과에 한 과목씩 있는 소프트웨어공학이라는 측면으로 개발이라는 업무에 접근하고 있다. 결론부터 말하면 단순히 컴퓨터학이 아니라 소프트웨어공학이라는 측면으로 접근해야 한다는 것이다. 건축,토목등에 공학사나 기술사들이 있는 것처럼 IT도 그런 체계적인 것이 있어야 하고 그것을 위해서 소프트웨어 공학이 필요하다고 얘기하고 있다.
현재의 대부분의 조직들은 소위 말하는 "일단 작성하고 고쳐보는 개발(code and fix development)" 즉 설계나 계획없이 일단 짜고보는 방법을 취하고 있고 이것은 장기적으로 보았을 때 훨씬 비효율적인 방법이고 이 방법을 취하는데 딱히 훈련이 필요하지 않기 때문에 취하지만 이런 시도는 비용과 일정을 늘리기만 한다.
일반적으로 개발은 프로세스 기반과 책임기반이 있는데 프로세스 기반은 잘 정의된 프로세스와 효율적인 시스템을 통해서 좋은 결과를 만들어 내는 것이고 책임기반은 한명의 실력있는 인재에게 프로젝트의 관리자를 맡기고 전권을 줌으로써 동기부여를 시켜서 프로젝트를 성공적으로 이끄는 것이다. 이 두가지는 좋은 방법이지만 많은 조직들은 프로세스 사칭조직의 형태를 띄어서 프로세스 형태를 그 본질보다 훨씬 중요하게 생각해서 오히려 개발자들이 일을 즐기지 못하게 만들거나 책임사칭 조직의 형태를 띄워서 책임조직의 동기부여에 따른 긴 근무시간을 혼동하여 개발자들에게 긴 근무시간을 강요하게 되어버린다.
이제 소프트웨어 개발이 공학이어야 하는 이유는 과학은 이론을 연구하는 것이고 공학은 과학의 이론을 현실에 적용하는 것을 연구하는 사람인데 우리 개발자들은 공학에 더 가깝다는 것이다. 그렇기 때문에 과학적인 접근만으로는 현실에서 한계가 생긴다는 것이다. 그래서 공학적인 접근이 필요하고 이 공학을 연구한 사람한테 자격증 혹은 면허를 줌으로써 점점 체계적인 시스템을 갖춰 나갈수 있다는 것이다.
내가 느끼기엔 위의 한 얘기가 결국 이 책에서 스티브 맥코넬이 얘기하고자 하는 바이고 개발자의 성향분석이나 여러가지 수치적 데이터, 여러가지 방법론등을 통해서 얘기하고자 하는 바를 뒷받침하고 있기는 한데 그런 부분에 대한 사전지식이 없어서인지 뒷받침자료로 제시하고 있는 그래프나 수치적 데이터가 오히려 말하고자 하는 논지를 산만하게 느껴지게 만드는것 같고 이론과 실무에 대해서 얘기하고자 한거지만 오히려 이책 자체가 실무와는 좀 동떨어진 이론적 얘기를 하는 것 같은 인상이다.
좋은 말이기는 한데 특별한 건 없다고 할까나?
어쨌든 이 책에서 인상깊었던 몇가지 글들
"같은 방식으로 일하기를 반복하면서, 다른 결과를 바랄 수는 없다."
우리는 능력이라는 것이 경험과 지식을 조합한 것이라는 걸 알게 되었다. 지식이 경험에서 우러나온 것이 아니라면 정말 최신의 지식을 소유한 것이라 말할 수 없고, 마찬가지로 최신 지식을 알고 있지 않다면, 좋은 경험을 쌓는 다는 것은 결국 불가능하다. 개인의 지식과 경험 레벨이 서로 일치하지 않는다면, 개인의 최종 능력은 일반적으로 경험과 지식 중 더 낮은 쪽에 가까워 진다.
더블어 IEEE에서 제정한 소프트웨어공학 윤리강령과 업무 규범이란 것도 있다는 걸 알았다. 취지는 참 좋은데 현실에선.. 흠...
Comments