바쁘다는 핑계로 책을 안보다가 인사이트 책 소개에 넘어가 읽은 책입니다. (다년간 SI 프로젝트를 경험했다는 저자이력도 책을 들쳐보게 하기에는 충분했던거 같네요.^^)
한국 소프트웨어 개발 현장은 전쟁터니, 앞뒤 가리지 말고 살아 남으시라, 인사이트
책은 프롤로그와 사례연구로 시작합니다. 그런데 사례연구가 "덴버공항과 미국 항공 교통 통제시스템(AAS)"이어서 조금 실망했습니다. 국내 SI 프로젝트 사례가 나올거라 예상했거든요.

좀 더 책을 읽어봤습니다. 개념을 설명하는 부분에서 많은 인문학적 사유나 인용이 등장합니다. 메타포를 이용한 설명은 저도 좋아하는 편입니다만 해당 개념을 설명하는데 어떤 관련성이 있는건지 잘 이해가 안가서 다시 저자 이력을 봤습니다. "박사네" 솔직히 이쯤에서 책을 그만 읽을까도 고민했습니다. 개인적으로 코딩 한줄 못하는 아키텍트나 컨설턴트의 노가리가 아닌가 하는 생각이 들었거든요. 책 곳곳에 등장하는 저자 경험으로 비추어 보면 그건 아닌것으로 보여서 또 읽어봤습니다.

TDD에 대한 내용이 나옵니다. 조금 옮겨 봤습니다.
TDD로 여러 차례 개발을 진행해 봤다. 그때마다 느낀 것은 요구사항을 분석해야 한다는 무거운 짐으로부터 개발자들을 해방시킨다는 것이다. 개발자들은 단순히 사용자의 요구사항을 말로 듣고 그 순간부터 즉각 개발에 착수한다. 무엇을 개발할 것인가는 테스트 케이스로 간단하게 선언한다. 개발자가 선언한 테스트 케이스가 맞는 것인가는 2주일 후에 고객과 함께 작성한 프로그램을 검토함으로써 확인할 수 있다.
전 2가지 점을 이야기 하고 싶습니다. 첫째는 TDD에서 정의하는 Test Case가 요구사항을 대체할 수 있을정도로 크지 않습니다. TDD가 일정 수준의 디자인을 대체할 수 있지만 요구사항 자체를 TDD로 대체할 수 있을지는 의문입니다. 둘째로 고객이 TDD로 작성한 테스트 케이스가 맞는지 확인해 줄 수 없습니다. FitNesse와 같은 ATDD, BDD를 통해 유비쿼터스 언어로 Test Case를 작성하면 혹시 가능할 지 모르겠네요. SI 프로젝트 10년하면서 그런 고객은 본 적이 없습니다. 그런 고객이 있었다면 지금과 같은 SI 프로젝트 현실이 생겼을까요? 그러면 좋다는 의미로 이해하렵니다.

SI 프로젝트가 정치판이라는 의견에도 십분 공감합니다. 하지만 그렇다고 개발자도 꼭 정치적이 되어야 하는걸까요? 프로젝트에는 희생이 따른 다는 의견도 많이 보입니다. 맞는 말입니다만 그걸 피하기 위해서 정치적이 되어야 하는지는 잘 모르겠습니다. 저도 프로젝트에서 열심히 일하고 팀에서는 평가를 제대로 받지 못했던 적도 많았습니다. 오히려 고객이 걱정을 해준적도 있으니까요. 그런 경험을 통해서 저는 노력을 제대로 평가받는 방법을 배웠던것 같습니다. '포장술'이라고 하면 될까요.

'소프트웨어 개발은 프로세스라기보다 일종의 협동 작업이라고 봐야 한다.' 'WBS는 팀의 의욕을 떨어뜨린다. 작업 속도는 각 팀마다 고유한 것인데 WBS는 이것을 일정이라는 틀로 지시하려는 것이다.'
WBS에 대한 적절한 표현이라는 생각이 듭니다. 항상 WBS 작성에 대한 반박논리가 궁색했는데 좋은 무기를 얻은거 같아 기쁩니다.

'내가 하지 못할 일을 남에게 강요하지 말라' 지원 업무를 하면서 저자가 가졌던 원칙이라고 합니다. 100% 동감합니다. 저도 지원업무를 해봤고 지금도 하고 있습니다만 무슨 관리자인냥 행동하는 사람들을 많이 봤습니다. 꼴보기 싫습니다.

'소프트웨어의 품질관리에는 한계가 있으며 우리는 개발자를 신뢰하는 것 외에는 특별한 품질관리 방법이 없다.' 50% 공감합니다. 개발자마다 다를 수는 있다고 생각합니다. 스스로 품질관리를 할 수 있는 개발자라면 더 많은 자유를 주어야 하지만 능력이 안되는 개발자를 신뢰하는 것은 품질을 망칠수도 있습니다.

'긍정적인 사고방식이 우리의 적극적인 행동을 이끌어낼 것이라는 것은 분명해 보인다. 하지만 긍정적인 사고방식만으로는 일이 성공할 수 없다.' 저는 이 부분을 읽으면서 스크럼과 XP에 대해 생각했습니다. 스크럼을 도입하면 사람들이 긍정적으로 열심히 참여하게 만들지만 이것만으로는 부족합니다. 내가 맡은 업무가 실질적으로 개선되도록 해야 하는데 이때 XP의 실천법이 많은 도움이 됩니다.

맘에 드는 부분도 있고 수긍이 가지 않는 부분도 많았습니다. 저도 10년 넘게 일했던 분야고 저자가 경험한 분야를 대부분 겪어봐서 그런것 같습니다. 괜히 옛날 힘들었던 기억이 나서 두번 읽을거 같지는 않네요. ^^;

인간조직권력그리고어느SW엔지니어의변
카테고리 컴퓨터/IT > 컴퓨터공학 > 소프트웨어공학
지은이 이종국 (인사이트, 2011년)
상세보기


저작자 표시 비영리 변경 금지