일반서적 중에 자기계발서라는 것이 있다면, IT 서적 중에는 소프트웨어 개발방법론 서적이 있다고 생각한다.
흔히 IT 서적이라고 하면 구체적인 기술적인 내용을 담고 있는 반면에, 소프트웨어 개발 방법론 책은 거의 이론서적 중심이다(코드 한줄없는).
이러한 생각의 이유로는
자기계발서적을 읽고나면 느껴지는 모호함 같은 것들이다.
'좋은 얘기고 어느 정도 이해는 하겠는데, 그럼 나는 구체적으로 무얼해야 하지?'
약간의 허탈감도 든다. 읽을 때 만큼은 의욕이 넘치지만, 책을 덮고나서부터 갈수록 의욕이 떨어지고 마는 이런 것.
그래서 생긴 원칙한가지는 절대 자기계발서는 읽지 않겠다 는 거다.
소프트웨어 개발서적도 마찬가지 패턴이다. 읽을 때는 100% 완전 공감하면서도, 그후에 과연 지금의 프로젝트에 어떻게 적용시켜야 하는가? 현실과 이론의 괴리감을 느끼게 된다.
프로젝트 방법론 하면 가장 알고, 실제 현장에서 가장 많이 사용되는 것이 폭포수 개발 방법이다. 이 방법의 장단점들에 대해 잘 알고 있지만, 내가 경험한 거의 모든 프로젝트에서 이방법을 사용했다.
몇 년 전에서부터 소위 뜨고 있는 방식이 있다. 실용주의 프로그래머, 테스트 주도 개발로 잘 알려진 애자일 방식이다. 이로부터 이어져 내려오고 있는 린(lean) 방식이 벤처 창업으로까지 확장되었다.
책을 읽으면서, 낚였구나 라는 생각을 지울 수 없었는데, 이책에서 생각하는 독자와 내가 생각했던 책이 달랐던 것 같다. 결론적으로 말하자면, 지금 회사를 시작하려거나 앞으로 창업을 할 사람이 아니라면, 별로 도움이 안되는 책이다.
내가 원했던 책의 내용은 이런 것이었다.
개발자가 회사를 차리는 방법, 준비하면서 필요하고, 유의해야할 점들, 만들면서 생긴 에피소드, 공돌이도 사장이 될 수 있다 등등등.
저자가 실제 회사를 스타트업을 하면서 사용했던 린 방식을 예로 들며 설명하고 있는데, 별로 공감이 가지 않았다. 아마도 앞서 얘기했듯 책이 원하는 독자가 아니어서 일 것이다.
어쨌든 이 책을 계기로 생긴 새로운 원칙은 절대 소프트웨어 방법론 책은 읽지 않겠다. 필요하다면 지금껏 구입한 소프트웨어 방법론 책들 중 한권만으로도 충분하다 이다.