요 근래에 회사에서 프로젝트 관련 서적을 몇 권 샀습니다. 그 동안 주먹구구 식으로 해오던 것을 좀 더 체계적으로 해보고 싶기도 하고, 좀 더 재미있고 효율적으로 해보고 싶기도 한 욕심에 몇 권 주문을 했습니다. 이 책은 그 중에 하나였습니다. 사실 주문할 때에는 그렇게 큰 기대는 하지 않고 샀습니다. 그런데 책장을 펼치고 몇 페이지를 읽는 순간 완전 월척을 낚은 느낌이더군요.
이렇게 감동의 도가니탕으로 몰아넣는 책을 얼마만에 읽었는지 기억도 나질 않습니다. 물론 요즘은 사실 책도 별로 읽지도 못했지만 어쨌든 근래에 읽은 컴퓨터 관련 책 중에는 단연 으뜸입니다. 저자의 글빨이 얼마나 좋은지 그닥 재밌을 법한 주제가 아님에도 페이지를 넘기면서 심심한줄 모르고 읽었습니다. 글쓴이가 개발자인줄 알았는데 역시나 아니더군요. ㅋㅋ~
주된 내용은 챈들러라는 프로젝트의 진행 과정을 외부인(이 책의 저자)이 밀착 취재해서 적은 내용입니다. 프로젝트가 어떻게 산으로 갈 수 있는가? 사람들은 어떤 곳에서 문제를 겪는가? 소프트웨어 개발 프로젝트는 어떤 요소 때문에 실패하는가? 등등의 내용을 담고 있습니다. 다큐같은 내용 중간 중간에 소프트웨어 공학에 관해서 몰랐던 역사적인 내용도 감초처럼 섞여 나와서 좋았습니다.
책에도 나오지만 프로그래머 내지는 소프트웨어 개발자를 교육할 때 그 역사에 대해서 공부하지 않는다는 사실에 새삼 놀랐습니다. 생각해 보면 어떠한 분야도 다들 자신의 분야의 역사는 배우기 마련인데, 제가 나온 대학교의 특징인지는 몰라도 소프트웨어의 역사 요론 주제로 수업을 하는 것을 본 적은 없었거든요. 다른 학교도 비슷한 것 같구요. 아마 이런 강좌가 개설된다면 아주 재밌을 법 한데 말이죠.
리스프와 객체지향 전문가이자 썬 사의 “뛰어난 공학자”인 리처드 가브리엘은 주장한다. “저는 프로그래머들도 시인, 예술가처럼 창의적인 활동을 하는 사람들을 양성하는 방식으로 양성해야 한다고 생각합니다. 사람들은 이게 엉뚱한 소리라고 말할지도 모릅니다. 하지만 시문학 석사학위를 받으려고 교육받을 때 사람들은 무엇을 하나요? 그들은 위대한 시들을 공부합니다. 소프트웨어 공학에서 그렇게 하나요? 아니요, 우리는 위대한 소프트웨어의 소스코드를 읽지 않습니다. 위대한 소프트웨어의 설계를 공부하지도 않죠. 그 디자인을 보지도 않고요. 위대한 소프트웨어 디자이너들의 인생을 공부 하지도 않습니다. 즉 우리는 우리가 만들려는 것의 기존 문헌들을 공부하지 않습니다.”
– 드리밍 인 코드 中
저명한 커누스 교수님 또한 소프트웨어 개발이 어렵다고 하니 정말 쉬운 일은 아닌 것 같긴 하죠. 이 전 내용에 나오는 빌 조이는 책 쓰는 일이 더 어렵다고 이야기 했는데요. 두 분야(책쓰기, 소프트웨어 개발하기)를 모두 깊이 있게 경험해보신 커누스 교수님 말에 좀 더 무게를 실어 주는게 당연하겠죠. 하지만 주관적으론 빌 조이의 말에 공감이 가긴 합니다. 저 또한 코딩보다 글쓰기가 훨씬 더 어렵게 느껴지거든요. 아마 대부분의 개발자가 그런 생각을 가지고 있을 것 같습니다. 그래서 문서화가 그리도 안되는 거겠죠.
제가 컴퓨터 조판 시스템 문제를 해결하기 위해서 수년의 시간을 쏟아부으면서 배운 것이 무엇이냐고요? 가장 중요한 교훈 중 하나는 아마도 “소프트웨어 개발은 어렵다”는 것입니다. 지금부터 저는 제가 만나게 되는 모든 성공적인 소프트웨어 도구들에 대해 훨씬 더 깊은 존경심을 갖게 될 것 같습니다. 지난 10년간 저는 텍과 메타폰트 개발이 제가 평생 해온 그 어떤 일(정리를 증명하는 일이나 책을 쓰는 일) 보다도 어려운 일이었다는 사실에 놀랐습니다. 좋은 소프트웨어를 만든다는 것은 다른 일ㅇ 비해 현저하게 높은 수준의 정확성을 요합니다. 그리고 다른 지적인 활동에 비해 더 오랜 시간의 집중을 요합니다.
– 커누스(Knuth) 교수의 말, 드리밍 인 코드 中
아래 내용을 읽다보면 소프트웨어 개발이란 작업을 교량을 건설하는 것처럼 한다는 것 자체가 어불성설인지도 모른다는 생각이 듭니다. 전 레오나르도가 관리자도 승격됐다는 부분에서 눈시울을 적셨습니다. 주위에도 이런 사례는 정말 많죠.
그들은 예술가들이 예술 작풍을 만드는 작업에 도움이 되도록 몇 가지 효율적인 도구를 마련해 주기로 결정했다. 그들은 전동 조각칼, 자동으로 물감 짜내는 기계 등을 발명했다… 결과는 여전히 만족스러운 수준에 이르지 못했다… 협회는 2주 동안 특정 그룹의 화가들이 하루에 평균 몇 번의 붓질을 하는지를 세어봤고, 이러한 기준을 나머지 화가들의 가치를 평가하는 데 적용 했다. 만약 어떤 화가가 하루에 20번 미만의 붓질을 했다면 그는 명백히 생산성이 낮은 화가였다. 안타깝게도 이러한 지식의 진전은 실제로 예술 작품을 제작하는 일에 별 영향을 미치지 못하는 듯 보였다. 마침내 그들은 근본적 어려움이 관리에 있다고 결론 내렸다. 재능있는 학생 중 한 명(레오나르도 다빈치란 이름의)이 곧바로 물감, 캔버스, 붓 등을 조직에 조달하는 일을 책임지는 관리자로 승격됐다.
– ‘예술 작품 공학’, 드리밍 인 코드 中
대부분의 소규모 벤처 회사들은 소프트웨어 개발 일정이 지연되는 이유를 빡빡한 일정, 부족한 자금, 부족한 인력에서 찾곤 합니다. 이 책에 등장하는 챈들러 팀은 사실 그 중 하나도 해당되지 않았죠. 일정도 널널했고 (물론 느끼기 나름인지도 모르겠습니다), 자금도 풍부했고, 인력 또한 충분했습니다. 하지만 그들의 계획보다도 소프트웨어는 더 느리게 릴리즈 되었죠. 반대의 경우도 물론 있습니다. 지금은 성공했지만, 초창기 차고에서 시작한 회사들 중에는 그 모든 힘든 상황에도 불구하고 믿기 힘들만큼 좋은 제품을 빠른 시간안에 릴리즈 했던 경우가 더러 있었으니까요.
어쨌든, 여러가지 의견이 분분한 아직은 걸음마 단계의 소프트웨어 분야이지만 한 가지는 확실합니다. 소프트웨어를 만드는 것이 생각하는 것처럼 쉽지 않다는 것 아닐까요?
P.S) 혹시 이런 비슷한 성격의 책 (소프트웨어 개발 프로젝트 이야기)을 좀 더 알고 계신 분은 제보 해 주세요. 의외로 이런 책을 찾으려고 하는데 눈에 띄지 않더군요.