Head First Software Development 책 서평

01 Apr 2009

문제, 문제, 문제

• 대체 왜 기획자는 개발자가 필요로 하는 내용을 기획서에 담지 않는지,
• PM은 왜 툭하면 시연 등을 요청하여 개발 일정을 뒤틀어 놓는 것인지,
• 개발자는 함께 일정을 잡아놓고선 만날 야근하고도 일정을 지키질 않는지,
• 다른 조직의 개발자는 이틀이면 된다는 일을 왜 우리 팀 개발자는 일주일짜리 일이라고 하는지,
• 왜 그리도 개발자는 하드디스크가 잘 고장나서 소스 파일을 날려먹는 일이 여느 사람보다 훨씬 많은 것인지,
• 기껏 다 만들었더니 왜 요구한대로 만들지 않았냐고 사장님이 버럭 화를 내시는 것인지,
• 우리는 우리대로 손해보고, 고객은 고객대로 사기 당한 것 같은 얼굴을 보이는 일은 왜 그리도 잦은지.

해결을 하는 것이 문제

프로젝트를 진행하면서 이러한 상황을 종종 볼 수 있다. 경력이 많은 사람일수록 설화인지 전설인지 구분하기 어려운 무용담, 아니 개발담을 많이 갖고 있다. 그리고, 이런 상황을 해결할 수 있는 방법은 경력자 수만큼, 혹은 서점에 있는 책 개수만큼 많다. 예를 들면, 개발자에게 필요한 내용이 기획서에 제대로 나와있지 않다면 화술이나 대인관계론을 공부하여 기획자를 효과있게 구박하거나 기획자에게 개발 공부를 시켜서 상황을 해소하는 식이다.

이런 방법들이 틀린 것은 아니다. 그러나, 여러 톱니바퀴가 맞물려 돌아가는 상황에서 어딘가 이빨이 맞물리지 않아서 문제가 발생했다면, 각 톱니바퀴를 절대 망가지지 않는 초합금으로 만들고 금테를 두르는 것만으로는 문제를 해결하기 어렵다. 톱니바퀴 자체가 아니라 톱니바퀴가 맞물려 돌아가는 전체 흐름, 즉 개발 공정을 봐야 한다.

훌륭한 소프트웨어 개발을 위한 방법을 쉽고 재미있게 배우자

Head First Software Development 는 개발 공정을 주제로 하는 방법론을 다루고 있다. 개발 공정 중 일부에 대해서, 혹은 방법론을 깊이 다루지 않는다. 소프트웨어 개발의 전체 흐름, 그리고 개발할 소프트웨어와 관계된 이해당사자에 대해 이야기를 하고 있으며, 이러한 내용을 가상으로 프로젝트를 시작하고 완료하는 공정에 비추어 친절하게 설명한다.

책 이름이 개발자를 위한 것 같지만, 실은 기획자나 프로젝트 관리자(PM)도 함께 봐야 할 책이다. 이들이 숙지해야 할 내용이 있기 때문에 그렇기도 하지만, 다정하고 친절하게 개발 공정을 설명하는 책이기에 그렇기도 하다. 마치 이야기 구성이 잘 짜여진 소설을 읽듯이 프로젝트 시작부터 완료까지 개발 공정 이야기를 편안하고 쉽게 읽을 수 있다.

내용 구성

책은 크게 계획, 업무 정의(사용자 스토리, 태스크), 이터레이션, 버전 관리, 테스트, 버그 관리에 대해 다루고 있다.

계획 과정에서 고객의 요구사항 파악 및 우선순위 도출을 하고, 사용자 스토리를 기반으로 업무(task)를 정의한다. 이 업무는 조직의 개발 속도 등을 감안하여 이터레이션(iteration)을 나누어 진행하며 마일스톤으로 향한다. 물론, 각 이터레이션에는 협업 환경에서 필수인 버전 관리 체계 따르기, 테스트 기반 개발(TDD : Test Driven Development), 그리고 버그 추적 및 관리를 하여 품질 관리 과정이 녹아 있다.

이 책은 이러한 각 과정을 12장(chapter)에 걸쳐 꼼꼼하고 친절하게 다루고 있다. 좀 더 자세히 말하자면, 책 구성과 내용이 주제보다는 독자에 기준을 두고 쓰여졌다는 생각이 들 정도이다. 이야기 전달력(스토리텔링)이 높다. 다른 기술서에선 한 두 단락으로 다룰 내용을 이 책은 내용 전달을 위해서 여러 쪽에 걸쳐 최대한 쉽게 풀어쓰고 각종 그림을 동원하기도 하고, 400장이 넘는 내용을 한 두 쪽짜리 연습문제로 내며(460쪽~463쪽) 깔끔하게 정리해서 책 이해를 돕는다.

이 정도면 불친절하고 꺼칠한 사수보다 Head First 책들이 더 낫다는 생각이 들지 않을까? :)

아쉬운 점

좋은 점이 참 많은 책이다. 하지만 아쉬운 점도 있다.

우선 책을 읽으면서 이러한 친절이 좀 과하다고 생각이 드는 점을 들 수 있다. 그림이나 사진 등으로 전달력을 높이는 건 좋은데, 오히려 시선을 흩뜨려서 집중을 해치는 경우도 간혹 있다. 나는 책에 줄을 긋거나 생각을 적으며 책을 읽는데, 이 책에 그러면 정돈되지 않아 산만해지는 꼴이 되어 버린다.

두 번째는 심심치 않은 오탈자이다. 다행히 뜻을 해치는 수준은 아니므로, 옥에 티가 뭍은 수준이라 할 수 있다.

서평을 마무리하며

앞서 말했듯이 난 이 책을 개발자 뿐만 아니라 기획자나 PM도 꼭 읽어야 한다고 생각한다. 책은 자바(Java)나 C#, C++ 같은 프로그래밍 언어를 알아야 한다고 하지만, 프로그래밍을 몰라도 충분히 소화할 수 있다. 그만큼 쉽게 이해하도록 쓰여져 있다.

설령 프로그래밍 언어를 몰라서 내용을 이해하기 어렵더라도 개발자에게 모르는 걸 물어보며 개발 공정을 이해하도록 노력해야 한다고 생각한다. 개발 공정이라면 마땅히 개발이 어떤 공정으로 흐르는지 알아야 하는데, 기획자나 PM은 “공정”에 자신만의 관점과 생각을 반영하여 개발 과정에서 소통 차질을 일으키곤 한다. 이런 문제는 개발 공정 중 “개발”에 지식을 쌓으면 어느 정도 해소되지만, “개발 공정”을 이해하여 개발과 공정 모두를 잡을 수도 있다. 물론, 프로그래밍이나 그래픽 디자인처럼 기획을 구현하는 “개발” 영역을 이해한다면 금상첨화이다.

이제 글을 열며 제기한 문제들을 해결하는 방법 하나를 꼽으며 글을 닫으려 한다. 이 책을 곁에 두고 읽으며 실천해보는 것이다. :)