성악설에 입각한 방법론과 성선설에 입각한 방법론, 하지만 결론은 사람..

뭐 사실 나쁜 방법론과 좋은 방법론의 주제와는 전혀 무관(?) 할지도 모르지만 예전에 써야지 했다가 그냥  제목만 쓰고 묻혀버린 이야기가 생각나 트랙백과 함께 포스팅하게 되었습니다(지금 검색해보니 무려 2006년 11월에 제목을 만들었더군요.. ㅎㅎ 그건 지금 막 지웠습니다).

저는 세상의 방법론을 다음의 두 종류로 나눌 수 있지 않을까 했습니다(물론 둘의 중간자적인 입장을 취하는 것들도 있지만 그런것은 그냥 뮤턴트 X라고 하고 넘어가죠).

첫째로 성악설에 입각한 방법론입니다.
말 그대로 기본적으로 프로젝트를 수행하는 사람들은 원천적으로 악하기 때문에 그냥 두면 놀기나 하고 품질은 엉망이 되고 거짓말이나 하고 그래서 프로젝트는 산으로 가고 납기는 넘기기 일쑤고 맨날 야근이나 하면서 돈은 꼬박꼬박 받아가고 품질은 나쁘니 고객한테 불만도 쌓이고 등등.. 그렇기 때문에 우리는 프로젝트에 철저한 관리의 기술을 적용해야 한다. 물 샐틈 없이 잘 짜인 스케쥴과 품질을 위한 각종 문서, 진행을 위한 각종 표준을 미리 설정해 두고 이를 따르도록 한다. 모든 진행 상황(진척, 변경등)은 철저한 통제하에서 이루어져야 한다. 모든 것은 수치와 통계 문서로 귀결되도록 해야 한다. 모든 상황이 우리의 관리할 수 있는 범위내에 있어야 하기 때문이다.

두번째로는 성선설에 입각한 방법론입니다.
원래 사람들이란 자유롭게 협럭하면서 살게 하면 더 효율적으로 잘 일할 수 있는 존재이다. 그래서 그들에게는 최족 목표만 지정해 주고 방법은 알아서 최선의 것을 선택하도록 해준다. 따라서 우리는 프로젝트에 자율과 협력, 자유로운 의사소통을 할 수 있도록 도와주고 항상 현재 가장 필요한 최선의 것만을 추구하도록 한다. 미래에 있어야만 할 것 같은(있어야 하는 것이 아니라 할 것 같은) 것이나 그저 보여주기 위한 것들은 배제하도록 한다. 우리는 프로젝트 팀원이 자신의 최고 역량을 항상 다 할것이라 믿어 의심치 않는다.
(뭐 제가 성선설에 입각한 쪽으로 좀 기울어 져 있기 때문에 그쪽이 더 좋은 것처럼 쓰기는 했습니다만.. 경험상으로 봤을 때 성악설에 입각한 쪽도 전혀 일리가 없는 것은 아니라 생각됩니다.)

어찌되었건.. 사실 위의 분류는 그냥 제가 경험과 느낀바에 의해 쓴거고, 막말로 누가 처음부터 "너희들은 바보 천치 멍청이에 거짓부렁쟁이들이야. 그러니깐 내가 시키는 대로만 하고 절대 딴데는 보지도 마" 이러면서 방법론이란 것을 만들어 내겠습니까. 다들 이전의 아픈 기억들에 기반해 다음에는 좀 더 잘해보자라는 생각에 앞에 있었던 것들을 보완할 수 있는 장치들을 마련했겠죠. 개인적으로는 다들 "더 행복하게, 더 쉽게, 더 편하게, 더 빠르게"를 지향했을 것이라 생각하고 있습니다.

하지만 문제는 결국 사람에게서 나타나지 않았나합니다. 즉 받아들이는 사람의 오해와 무지, 그리고 쓰잘데기 없는 용기와 공명심등이 아주 잘 버무려져 흰색을 회색이나 검정색으로 바꾸어버린 것입니다. 꼭 water fall 방식이 원래 그것을 생각해낸 사람의 의도와는 전혀 다른 방법으로 근래에 해석되고 사용되고 있는 것 처럼 말입니다.

예를 들어 CMM 의 경우 어느정도 이상의 레벨에서는 반드시 요구사항의 변경을 추적할 수 있도록 해야한다고 되어있습니다. 당연히 취지는 좋습니다. 뭐가 어떻게 돌아가는지(갔는지)를 알 수 있다면 남들과 뭘 하려 해도 조금이나마 도움이 되지 않겠습니까? 그런데 이걸 받아들이는 사람들이 요구사항의 변경에 타이트한 관리가 필요하다고 생각해서, 이런 저런 문서뭉치와 복잡한 절차, 세세한 것까지 제한하는 제한사항등을 만들어내고 일반 서류로 하기 힘드니깐 이런 저런 배우기도 복잡한 툴들을 도입하고.. 결국 일선에서 그것을 받아들여햐 하는 사람들은 원래의 취지는 반의 반도 느끼지 못하고 그저 "책상머리에서..." 라던가 "실무도 모르는..." 등을 외치며 외면하게 된다는 것이죠.(XP 도입라는 글에서 CMM 관련 부분들을 읽어보시면 제 어줍잖은 글보다는 더 잘 이해되시리라 생각됩니다).

Aglie 류도 결국은 마찬가지라 생각됩니다. TDD, Refactoring, PairProgramming, CI 등등의 주옥같은 단어들이 최선의 가치를 만들어낼 수 있기에 선택한 최선의 툴이 아니라, 반드시 이견없이 모두 다 따라야만 하는 메뉴얼이나 규정 처럼 되어버리면, 그래서 왜그래야 하는지는 생각해볼 틈도 없이 시키는 대로만 해야 하는 것(혹은 해야된다고 강박관념에 시달리는)이 되어버리면 달라지는 것은 이전과 아무것도 없을것입니다.

결론은 사람 이군요. ㅎㅎㅎㅎ (쓰다보니 처음 의도와는 전혀 다른 결말을 맞게 되어서 글 제목도 수정하게 되었습니다)

덧글

  • 리브리스 2007/11/15 17:36 # 삭제 답글

    저는 아직 그런 프로세스를 경험해 보지는 못했어요. 단지 이론만 공부했을 뿐이죠. 기억나는건 하나도 없네요.ㅋ 하지만 이런저런 개발을 하고 부딪히면서 프로세스는 반드시 필요하다는 생각을 합니다. 성선설(?)이든 성악설(?)이든간에 말이죠. 최소한 두사람 페어가 아니라면 더더욱..
    진영님의 말씀처럼 프로세스이전에 사람이 우선되어서 충분히 이해하고 고려되야만 하는 것 같습니다.^^
  • 이정훈 2014/04/09 22:16 # 삭제 답글

    전 성무성선설에 가까운 편입니다. 태어날땐 백지상태란 말이죠
  • 전우식 2014/04/09 22:17 # 삭제

    그런것도!!!
댓글 입력 영역