황상철님의 블로그, 실용주의 이야기에서 알게 된 책이다. 평소에 소프트웨어 공학에 관한 책을 그다지 관심을 갖지 않는다. 하지만 무슨 이유에서인지 이 책이 끌려서 구입했다.(지금 다시 제목과 황상철님의 블로그를 가서 원래 글을 봐도 무엇에 끌렸는지는 미스테리다.)

사실 여기서는 이 책 얘기 보다는 소프트웨어 공학.... 정확히는 관리와 개발 사이에 대한 말을 해볼까 한다.

책 이전에, 일단 나는 '소프트웨어 공학'을 매우매우 좋아하지 않는다.(싫어하는 것은 아닌듯 하다. 아마도.....) 학교 수업시간에 간단하게 해결할 수 있는 일을 매우매우 어렵게 해결하는 모습을 보고 완전히 질려버렸기 때문이다.

코딩을 해보고, 별도로 간간히 디자인 패턴을 공부하게 되면, 그냥 코딩 스타일대로, 코딩을 하다가 만들어지는 기법에 이미 누가 이름을 붙인 경우가 제법 있었다.(물론 차이점이나 개선점도 많았지만..) 코딩으로써 얻는 디자인 패턴(코딩 기법), 그리고 책을 보고 거창한 이름 안에서 주절 설명되어지는 디자인 패턴 간의 차이에 약간의 괴리감도 가지고 있다.

소프트웨어 공학, 내지는 소프트웨어 설계, 디자인 패턴, 패턴 설계....의 모든 것은 궁극적으로 코딩을 위한 것이다. 하지만 (학교에서의 경험으로) 코딩보다는 이러한 설계에 더 노력을 해야 하는 그 상황에 아주 끔찍하게 질려버렸다.(물론 학교에서는 특수성 안에서 생산성을 애당초 포기했겠지만, 그것을 감안해도 그러한 깐깐한 방법론 자체가 싫었다.)

사실상 프로그램이 커지다보면 이러한 취향은 고려대상이 아니라는 것을 잘 알고 있다. 그렇기 때문에, 디자인 패턴과 소프트웨어 공학의 공부는 그동안 항상 코딩 위주로 해왔던 설계를 더 발전 시키고, 궁극적으로는 그러한 설계에 많은 시간과 공을 들이지 않기 위해서, 나름대로 방어 수단으로 공부하는 것이다. 즉, 관리를 잘하기 위해서 공부하는 것이 아니라 코딩을 잘하기 위해서 공부하고 있다.

이 모든 것을 한줄로 짧게 말하면, '난 관리직을 끔찍히도 싫어한다.'

이제 책 얘기로 돌아가면, 이 책의 1장, '관리'에서 바로 내가 고민하는 부분을 저자도 고민했다는 것을 알 수 있었다. 저자는 관리가 성공의 길이라는 것을 알고 있었고, 그것을 피할 수는 없었다. 하지만 두가지 이유로 스스로가 기술자(엔지니어)로 남고자 하는 것을 깨달았다고 한다.(아래 두 문장은 책에서 그대로 옮겨 왔다.)


2번과 연결이 되는 저자가 쓴 책, The Power of Peonage(1979) 의 핵심은 관리자의 위치보다는 기술자의 위치가 자신이 하는 일을 능숙하게 할 수 있으면서도, 관리에 영향을 줄 수 있다는 것이다.

근본적인 물음은, 왜 이런 기술자 스타일의 저자가 관리에 관한 책을 썼느냐인데, 정작 중요하면서도 자주 잊어버리는 것은 관리 측면이기 때문이라는 것이다. 기술자의 위치는 자신의 일을 할 수 있으면서도 관리에 영향을 준다는 것이다.(이것이 The Power of Peonage 의 결론)

이러한 전제 조건 안에서, 저자는 소프트웨어 공학에 있어서 사람들이 자주 잊어 버리는 것들을 모아 책으로 엮은 것이다. 저자가 중요시한 주제는 '사람', '도구와 기술', '추정', '재사용', '복잡성'... 이 안에서 여러가지 소주제[2]를 두고 3~4페이지로 저자의 입장을 기술한다. 초반에는 유명한 말 중에 하나인 '최상의 프로그래머는 최악의 프로그래머 보다 28배 뛰어다' 라는 말 같은 것을 소주제로 삼기도 한다.

이번 포스팅이 책 외의 것들을 언급하면서 다소 복잡하게 되어버렸는다. 요약하자면, 이 책은 기본적으로 소주제를 통해 흔히 잊을 수 있는 몇몇 사실(혹은 오해, 혹은 논쟁의 여지가 남겨진 하나의 의견)들을 다시한번 생각해 볼 수 있는 계기를 줄 수 있는 책이다. 거기에 관리자 측면이 아닌 개발자 측면일 지라도 관리의 중요성을 느낀다면, 이 책이 좋은 선택일 것이다. 저자 스스로가 개발자 스타일이라는 것을 밝혔기 때문이기도 하다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.