이 책은 Yes24 / 컴퓨터와 인터넷 리뷰 클럽 서평 이벤트를 통해 받았다. 이 책을 받은 당일과 새벽에 이 책을 다 읽을 수 있었다. 흥미로운 주제와 내용을 돋보이게 하는 저자의 필력 때문이다. 이 책의 목적은 국내 IT 프로젝트가 가진 후진성의 원인을 미국과 비교 분석하고 해결책을 제시함으로써 글로벌 소프트웨어를 개발할 수 있도록 독려하는 데 있다. 책 전반부를 읽고 있을 때, 국내 프로젝트 진행이나 개발자들의 행태에 대한 저자의 날카로운 지적에 마음이 후련해지는 느낌을 받았다. 그러나 후반부로 읽어 갈수록 왠지 모르게 저자에 대한 거부감을 느끼게 되는 것은 개인만의 생각일까?

일단 저자가 지적한 대한민국의 IT 현실은 IT 바닥에서 몇 년만 있어도 동감할 수 있는 일반적인 현실일 것이다. 그러나 저자의 해결책은 추상적이고 이미 IT 관련 서적이나 매체를 통해 여러 저자가 언급한 일반적인 내용이다.

저자는 추상적인 해결책을 제시하면서 고기 잡는 법을 가르쳐 주면 싫어한다거나 원인 해결을 위해 컨설팅을 받으라는 식의 서술도 하고 있는데, 이런 서술은 부적절한 듯 하다. 저자가 제시한 해결책을 고기 잡는 법에 비유 하자면, "낚싯대를 가지고 바다에 가서 낚시를 하면 고기를 잡을 수 있다" 정도의 내용일 것이다. 바다에서 사용하는 낚싯대, 사용하는 미끼, 낚싯대를 던지는 방법, 찌를 확인하는 방법, 물고기가 잘 잡히는 곳, 날씨 변화를 읽는 법, 구체적인 낚시 방법 등을 제시해 주면 더 낚시를 잘 할 수 있을 것 같은데 저자의 생각은 다른 것 같다.

저자가 주장을 펼칠 때 사용하는 객관적인 근거가 부족하다. 저자의 주장에 대한 객관적 논거라고 할 수 있는 통계, 인용, 저자가 프로젝트 경험으로 수집한 자료 등이 거의 전무한 상태다. 아무리 저자가 유능하고 실력이 있더라도 자기 주장에 대한 객관적이고 과학적으로 정리되고 가공되지 않은 지식을 다룬 서적은 계몽서나 카네기 인생론 같은 자기 개발 도서라고 해야 할 것이다. 계몽서나 자기 개발 도서가 나쁘다는 게 아니라 책 성격과 안 맞다는 것이다. "~해야 한다","~는 잘못된 생각이다.","전혀 그렇지 않다" 식의 표현을 하려면, 그 만한 근거를 제시해야 했다. 너무 편하게 책을 쓴 느낌이다.

저자가 문제에 대한 프레임에도 문제가 있다. 예를 들어, 동료검토를 권장하는 원칙을 제시하면서도 뒷부분에 동료검토는 우리나라 정서에 맞지 않아 실패하는 경우가 많으니, 억지로 권하지는 말라고 한다. 맞는 말이긴 한데, 동료 검토를 싫어하는 것은 우리나라 개발자뿐 만이 아니다. 외국 개발자들도 동료검토를 통해 자신의 소스코드를 공개하는 것을 싫어한다고 한다. 이것은 외국 프로젝트 관련 서적에서도 자주 등장한다. 그래서 동료검토에 모멸감이나 수치심을 느끼지 않도록 주의하고 프로세스화해서 감정적인 요인을 제거해야 한다는 것이다. 또한 개발자 유형을 사이언티스트, 엔지니어, 테크니션으로 나눠 엔지니어만이 진정 개발에 필요한 사람으로 보고 나머지 유형은 프로젝트 진행에 방해가 되는 것처럼 표현한다. 임백준씨의 에세이 성격의 책인 [뉴욕이 프로그래머]를 보면, 다양한 유형의 개발자들이 존재하지만 서로 조화를 이루면서 프로젝트는 전반적으로 잘 운영된다. 인간 중심의 사고로 볼 때 세 유형은 서로 보완적인 관계로 볼 수 있다. 테일러 방법론에서 이상적으로 생각하는 동일한 기능을 수행하는 개발자를 원하지 않는다면 말이다. 그 외에도 문제라고 생각되는 프레임들이 많다. 건축가와 벽돌공 중 누가 더 가치가 있는가? 라든가. 스승과 제자의 일방적인 관계를 요구하는 [잔을 비워라]등 수 없이 많은 프레임의 고착화를 보인다.

마지막으로 애자일 방법론에 대한 가시 돋친 내용은 왜 넣었는지 모르겠다. 애자일 바로 알기라기 보단 애자일 방법론은 별 것 없다는 것을 강조하고 싶은 장으로 생각한다. 마틴 파울러가 최고책임 과학자로 있는 소트웍스의 경우 애자일 방법론으로 컨설팅을 수행한다. 소트웍스가 소규모 업체만 컨설팅할까? 그들이 애자일을 적용한 어느 정도 규모의 프로젝트들이 전부 실패할까? 프로세스가 모든 것을 해결하진 않는다. 평자는 애자일 방법론 예찬론자가 아니다.

마음에 들지 않는 부분들도 많지만, 이 책에서 다루는 내용들을 강령이나 원칙이라고 생각한다면 대부분의 내용은 받아 들일만 하다. 문제는 책을 읽고 사고(思考)할 수 있는 여유나 근거가 부족한데 있다. 책을 잘 읽지 않는 개발자들에게는 독(毒)이 될 수도 있을 것 같다. [대한민국 개발자 희망 보고서] 서평에서 한 권만 읽는다면 그 책을 권하고 싶다고 했다. 한 권만 읽을 것이라면 이 책은 읽지 말라고 하겠다. CTO에 대한 내용은 참신했으며, SRS 작성, 버전 및 이슈관리, 국제화/지역화에 대한 내용은 현재 트랜드로 보면 당연한 것으로 생각되지만 독자들이 판단하기 바란다.

최근에 실무적인 문제를 해결해야 하기 때문에 프로젝트나 소프트웨어 공학에 관한 책을 많이 읽지 못해 책에 대한 객관적 평가라고는 할 수 없다. 책을 읽으면서 느낀 점이나 생각을 주관적으로 작성했다. 사견으론 저자는 기술자 관점보다는 교수나 컨설턴트 입장에서 가르치려 한다는 느낌이다. 이 ~~책은 교재도 아니고 자기개발도서도 아니다.~~ 좀더 논리적인 근거로 설득 했더라면 좋았을 것을 너무 가르치려 한 것 같다. 평자가 잔을 비우기엔 너무 취했을 수도 있지만 말이다.

저녁부터 새벽까지 형광등 아래서 책을 봤더니 눈의 피로감이 상당했다. 이유는 모르지만, 무 광택 종이 재질을 사용하면 좋을 듯하다. 야간에 열심히 책을 읽는 개발자들도 고려해 주시길...

~~PS: 이 책을 보고 여러 분야의 책을 참고로 읽었다. 그러나 너무 글이 길어지는 것 같아 참고해서 인용하려던 부분들은 다 생략했다.~~