사용자 삽입 이미지
소프트웨어 개발팀은 몇 가지 부류의 사람들로 정의할 수 있습니다. 바로 고객, 자신, 자신의 동료 이렇게 말이죠. 이런 사람들과의 관계가 원만하다면 일은 훨씬 유연하게 돌아갈 것입니다. 하지만, 실상은 그렇지 않습니다. 아마도 다음과 같은 식이죠?

먼저 소프트웨어 개발팀에서 주로 이런 말들을 합니다. "우리 고객은 자기가 이렇게 하자고 했으면서, 이제 와서 딴 소리 해. 정말 일하기 힘들어!" 그리고 개발자들은 자신의 프로젝트 매니저에게는 이렇게 얘기를 잘 합니다. "B파트의 연계모듈이 완료되지 않아서 못했어요. 그건 제 잘못이 아니라구요. 그 사람 잘못이에요." 고객들은 또 자기들끼리 얘기합니다. "지금까지 개발된 내용 구경 좀 해도 되냐니까 보여주는데 며칠이나 걸려요. 그리고, 그것 때문에 일정이 지연되었다고 마감을 연기해 달라고 하는데, 이게 말이 되나요?"

너무 극단적인 프로젝트 팀이라고 생각할 수도 있겠지만, 사실 이런 식의 대화는 너무나 흔합니다.

"Head First Software Development : 더 쉽고 재미있게 소프트웨어를 개발하는 방법"은 이렇게 3가지 부류의 사람들의 관계를 어떻게 가져가는 것이 좋은지에 대해서 대부분 이야기하고 있습니다. 고객과는 어떻게 하는 것이 좋겠다. 동료들과는 어떻게 하는 것이 좋겠다. 자신에게는 어떻게 하는 것이 좋겠다. 이렇게 말이죠.

책에 나오는 대부분의 제목도 이런 식입니다.

  • 고객을 기쁘게 하라.
  • 고객이 원하는 것을 알아내야 합니다.
  • 성공을 위한 계획
  •  실제로 일을 시작해 봅시다.
  •  ….
  •  프로답게 버그 잡기

뭔가 이런 관계가 보이지 않나요?

우리가 흔히 하는 가위바위보 게임도 하나의 관계입니다. 만약 상대방이 항상 바위를 낸다면 내가 무엇을 내야 할지는 너무나 명확합니다. 하지만, 바보가 아닌 다음에야 항상 다른 무언가를 낼 겁니다. 바로 획일성이 아닌 다양성이란 점 때문입니다. 소프트웨어 개발도 마찬가지입니다. 상대방의 다양성을 받아 들여야만 보다 효율적인 프로젝트 진행이 될 것입니다. 이런 것들이 이어져서 결국은 프로세스화가 될 것입니다. 그래서 이 책의 마무리도 프로세스에 대한 이야기를 하고 있습니다.

이 책은 이런 주제로 어떻게 일해야 할 지 훌륭한 지침을 내리고 있습니다. 자신에게, 고객에게, 그리고 내 동료에게 어떻게 할지를 말이죠.

먼저 고객과의 관계는 어떻게 가져가는 것이 좋을까요? 이 책에 좋은 사례가 있습니다.

  •  만일 당신 고객이 행복하지 않다면 소프트웨어를 잘못 개발한 것입니다. (p.46)
  • 고객에게 더 많은 정보를 달라고 말하세요. (p.73)
  • 고객은 바로 지금 소프트웨어를 갖길 원합니다! (p.100)
  • 고객이 되어 봅시다. (p.119)
  •  피곤하게 하는 고객 다루기 (p.138)
  • 그리고 가장 중요하게도 고객이 행복해 하네요. (p.452) 등

이런 내용들은 고객을 보다 행복하게 해 줄 수 있는 방법들을 제시하고 있습니다. 특히 "지금 소프트웨어를 원한다"는 대목은 뭔가 우리를 힘들게 할 수 있는 항목이 아닌가 보이지만, 이 책에서는 어떻게 하는 것이 좋은지 잘 설명하고 있습니다.

이번에는 동료와의 관계를 봅시다.

  • 현황판에 태스크 붙이기 (p.158)
  • 스탠드업 미팅 (p.168,176……)
  • 그런데 혁도 같은 작업을 했습니다. (p.224)
  • 공통의 관습을 따를수록 다른 사람이 프로젝트를 더 쉽게 이해할 수…(p.274)
  • 팀원들이 실제로 느끼는 것이 중요합니다. (p.444) 등

위의 내용만 보아도 동료와는 서로 무슨 일을 하고 있는지 확인하고, 어떻게 커뮤니케이션을 해야 할 지가 잘 나와 있습니다. 특히 "혁도 같은 작업을.." 부분에서는 형상관리(여기서는 Subversion을 사용합니다.)를 해야 한다는 이야기가 나오기 시작하는데, 그 외에도 모든 사람의 작업을 통합하기 위해 Ant와 같은 빌드 도구, CruiseControl과 같은 통합 빌드 등에 대해서 왜 그리고 어떻게 사용해야 할지 잘 설명되어 있습니다..

마지막으로 나는 어떻게 해야 할까요? 이런 내용들이 있군요.

  • 프로그래머는 꿈결 같은 시간을 생각합니다. (p.130)
  • 개발자는 현실적인 시간을 생각하는 사람입니다. (p.131)
  • 개발자는 기억력 좋은 독자가 아닙니다. (p.260)
  • 개발자는 시스템을 속속들이 들여다봅니다. (p.278)
  • 아무도 믿지 마세요. (p.413) 등

사람들은 자신에 대해서 상당히 관대합니다. 하지만, 현실적으로 객관적인 내용을 잘못 볼 가능성은 자신으로부터 오는 경우가 많습니다. 여기 내용들은 자신을 부정적으로 보라는 것이 아닙니다. 자신을 객관화할 수 있는 환경 속으로 옮겨 보다 현실적인 사람이 될 수 있도록 합니다. 이는 누구에게도 믿음직한 팀원이 될 수 있다는 의미가 됩니다.

혹시 어떻게 일해야 할지 지금 어려움을 느끼고 있다면 이 책을 한 번 읽어보는 것이 정말 좋은 선택일 것 같습니다. 이렇게 소프트웨어 프로젝트에 참여하면서 어떻게 일해야 할 지를 알고 임하는 것은 상당한 차이가 있을 테니 말이죠.

끝으로 오랫동안 소프트웨어 개발을 하면서 우리가 하는 일을 형상화하면 좋겠다고 생각을 많이 했었는데, 이 책은 눈을 감아도 내가 할 일을 그림처럼 볼 수 있는 능력을 주는 것 같아 많은 도움이 되었던 것 같습니다.

by NHN 안성화 차장

책 이야기  |  2009/01/08 13:54   by 코핀
이 글의 트랙백 주소 :: http://blog.hanb.co.kr/trackback/106
.
"더 쉽고 재미있게 소프트웨어를 개발하는 방법"을 부제로 단 Head First Software Development를 monaca님의 애자일 3종 강탈 1탄 이벤트를 통해 읽게 되었습니다. 1장에서는 훌륭한 소프트웨어 개발에 앞서서 훌륭한 소프트웨어 개발의 정의를 짚고 갑니다. 요구사항을 주어진 시간과 비용으로 제공하는 것인데요. 그 비밀을 이터레이션이라고 소개하고 있습니다. 이터레이션을 통해 프로젝트의 방향이 고객이 원하는 목표와 맞는지 자주 점...
.
문제, 문제, 문제 대체 왜 기획자는 개발자가 필요로 하는 내용을 기획서에 담지 않는지, PM은 왜 툭하면 시연 등을 요청하여 개발 일정을 뒤틀어 놓는 것인지, 개발자는 함께 일정을 잡아놓....
2009/01/09 12:01 댓글에 댓글수정/삭제
꼭 소프트웨어 개발자들이 아니라도 읽어보고 싶어지는걸요. 세상사 같이 일하는게 참 중요한데 말이죠. 멋진 서평인걸요.^^
.
산토끼
2009/01/12 14:49 댓글에 댓글수정/삭제
재미있게 읽을 수 있는 Head First 시리즈 만큼이나 재밌는 서평이네요^ ^ 좋은 글 감사드립니다.
.
asran(アスラン)
2009/04/20 11:59 댓글에 댓글수정/삭제
수아기님, 산토끼님~ 재미있게 읽어주셨다니 다행이네요. 안 차장님께도 이 자리를 빌어 다시 한번 감사의 말씀을~^^
.
이상호
2009/01/14 18:03 댓글에 댓글수정/삭제
이 책 구입한다는게 요즘 주머니 사정이 좀..
asran(アスラン)
2009/04/20 11:59 수정/삭제
엇 오랜만이시네요~^^
왜 요즘은 세미나 안오셨어요. 눈 빠지게 기다렸답니다.(띠용~)ㅋㅋㅋ
좋은 책이니 주머니 사정 풀리시면 한권..ㅍ.ㅍb
.
moon
2009/01/16 13:54 댓글에 댓글수정/삭제
안성화 차장님!! 항상 행복하시길 진심으로 바랍니다.
.
안성화
2009/01/21 20:58 댓글에 댓글수정/삭제
다들 좋은 말들 많이 해 주셔서 감사합니다. ^^
이렇게 서평을 쓸 수 있는 기회를 주신 한빛미디어에 제가 감사를 드릴 따름입니다.
다들 건강하세요.
.
이름 ::   비밀번호 :: 홈페이지 :: 비밀글
등록