|
주황색 속지를 넘기면 '왜 소프트웨어가 사용자들에게 거만하게 느껴질까' 라는 화두를 던지고 시작합니다. '거만함'은 소프트웨어의 '사용적 불편함'을 얘기하는 것이죠. 곳곳에 공감되는 글들이 보입니다. '업무용 프로그램에는 디자인은 대충해도 된다' 라는 고루한 경영진의 생각에 대한 반기를, 이 책에서도 동의해줍니다. 예쁠 수록 눈이 가고 흥미가 가죠. (공감가시는 남자분들!) UI, 조직, 칼퇴근, 보상, 자리배치, 단순함, 팀 빌딩, 인터뷰, 반복(애자일 방법론), 이직 등에 대한 재미있는 얘기가 담겨 있습니다.
그 중 저와는 약간 다른 견해를 보인 방법론에 대한 얘기에 덧붙혀 봅니다.
저자는 방법론의 문제에 대해 얘기합니다. 좀 삐딱하게 보면 '방법론의 무용론'으로도 비춰질 수 있겠는데요, 사람을 잘하게 움직이는 것은 '선언적 지식(declarative knowledge)' 가 아니라 '절차적지식(procedural knowledge)'라고 저자는 역설합니다. 단지 방법론 매뉴얼에 나온대로 따른다고 해서 동일한 품질의 소프트웨어가 나올 수 없다는 주장입니다. 박태환의 수영자세, 이승엽의 스윙 폼, 호날두의 프리킥 비법을 가르친다고 해서, 수강생들이 바로 그 선수의 레벨 처럼 되지 않는 다는 말이죠. 절차적 지식은 바로 '숙련과정'이 필요한 일이라는 것입니다.
맞습니다. 하지만 그래서 방법론인 것입니다. 방법론을 만든 사람, 공헌한 사람들에 입에서는 '이 방법론 대로 한다면 우수한 품질의 소프트웨어들을 그대로 척척 찍어낼 수 있습니다' 라고 소개하지 않았습니다. 오히려 그 방법론과 관련된 제품이나 서비스를 파는 '회사'에서 광고한 내용이 우리 머리속에 자리잡고 있는 것일 뿐이죠. 많은 개발자들도 방법론이 프로젝트의 성패를 가른다고 믿는 사람은 드물것입니다. (아! 물론 엄청난 물량의 의무스런 산출물들이 존재하는 방법론을 사용한 프로젝트라면 성패를 가른다고 생각하는 개발자들도 있겠군요! ㅋ)
하지만, 방법론이 그렇게 결함이 많은 것일까요? 박태환의 수영교실, 이승엽의 유소년 야구교실, 호날두의 일일 축구 강습이 쓸데 없는 일이겠습니까? 결국 거만한 소프트웨어를 만드는 것, 좋은 품질의 소프트웨어를 만드는 것도 '사람'입니다. 가이드라인(방법론)이 존재한다는 것. 그것때문에 발생할 가능성이 있는 '도덕적 헤이'가 일어난다고 보지 않습니다. 방법론에 나온 문서를 작성했다고 대충 처리한다면, 그러한 사람은 방법론이 없어도 그리 바람직하게 일을 할 사람이 아닙니다. 즉, 그 사람의 정신적 물리적 수준, 개발자의 '장인정신'의 여부에 따라 결정되어질 문제라는 것이죠.
이 책은 단순한 개발자의 삶을 탈피해서, 좀 더 상황을 넓게 보고 싶어하는 분들을 위해 시각을 넓이고 생각을 깊게 할 수 있도록 도와주는 좋은 책입니다.




최근 덧글