Talk about Software with hani

프로젝트를 여러가지 관점에서 정의내릴 수 있지만, 일종의 게임으로 바라본다면, ‘프로젝트 발주사’와 ‘프로젝트 수행사’는 게임 속의 경쟁자로 생각할 수 있다. 물론 발주사와 수행사 사이에는 권력의 비대칭성이 존재하기 때문에, 프로젝트라는 게임은 공정하지 않다.

상세한 룰을 도입하지 않고, 일단 얼굴에 철판을 깔고 프로젝트를 게임이라고 우겨본다면가정한다면, 프로젝트는 ‘협조적 게임’일까? ‘비협조적 게임’일까? 프로젝트를 성공시키려면, 발주사와 수행사가 협력하는 게 좋은 결과가 나온다는 상식을 놓고 보면, 프로젝트는 ‘협조적 게임’이라고 생각할 수 있지만, 내 경험을 놓고 보면 (상당히 주관적이지만) 그렇게 간단하지 않다.

일단, 게임에 참여하는 경쟁자가 협조적인 관계에 있고 싶어도, 협조적인 관계를 구축하는데 가장 중요한 의사소통을 방해하는 요소가 존재한다. 바로 ‘요구사항이 불명확하다’는 정보의 불확실성이다. 별거 아닐 수 있지만, 이놈의 불확실성과 ‘고정금액 계약’방식이라는 룰이 결함되면서, 프로젝트는 판타스틱하고 드라마틱하게 ‘비협조적 게임’으로 밝혀진다.

‘고정금액 계약’방식, 즉 기간과 금액이 정해진 상태에서 무언가를 뽑아내고 무언가를 끝내야 한다는 현실 속에서, 무엇을 만들어야 할지 모른다는 불확실성 때문에, 각 경쟁자는 자신에게 가장 유리한 전략을 선택하게 된다.

조금 더 풀어 쓰자면, ‘발주사’는 무엇을 만들지도 모르지만, 주어진 기간 안에 ‘수행사’를 쪼아서푸쉬해서 최대한 많은 것을 만들게 하려는 막가파식 전략을 펼치고, ‘수행사’는 뭘 만드는지도 모르지만, 주어진 기간 안에 무언가를 최대한 적게 토해내기만들기 위해, 무조건 개발하기 난해하다는 BJR*전략을 구사한다.

‘발주사의 막가파식 전략’과 ‘수행사의 BJR전략’은 상대 경쟁자에게 모두 노출되었기에 그렇게 새로운 전략도 아니다. 상대방에게 노출된 전략이라는 것에 동의하지 못하겠다면, SI 프로젝트를 하다보면, 신규 기능을 개발해야 할 경우를 생각해 보자. 보통 구현은 못하지만 자바라는 게 무엇인지 아는 고객은 이렇게 말한다. ”그거 if하고 for하고 대충 써서… 이미지로 출력해서… 웹으로 띄우면 되잖아요.” 물론 큰 그림을 보자면 맞고 구현을 한다면 틀린 이야기일 수 있다. 이런 이야기를 하는 고객 앞에서, 개발자는 최대한 어렵다는 변명을 구구절절 늘어놓는다.

아무튼 고객이 어설픈 지식으로 개발자를 푸쉬하거나, 개발자가 갖은 엄살을 가져다 변명을 하는 것이나, 이런 전략은 길고 긴 IT역사를 통해서, 상대 경쟁자에게 노출되었다. 즉, 상대방이 무슨 생각을 하고, 그 생각에 따라서 나의 전략을 펼친다는 점에서 본다면, 일종의 내쉬의 평형이 떠오르는데, 결국 비협조적 게임 속에서 경쟁자들은 전체 관점에서 최악의 선택을 하고, 프로젝트는 죄수의 딜레마에 빠져 심해 속으로 가라 앉는다.

‘비협조적 게임’은 모두에게 불행을 주기에, 행복한 결말을 내려면, 프로젝트를 ‘협조적 게임’으로 바꿔야 한다. ‘협조적 게임’으로 바꾸는 것은, 우선 ‘요구사항이 불확실하다는 것을 사실’로 받아들여야 한다. 뭐, 이런 얘기는 초보 개발자도 다 아는 이야기지만, ‘비협조적 게임’이 팽배한 현실에서, 요구사항 정의서에 도장을 찍으려면, 발주사는 무언가를 잔뜩 개발시키려고 하고, 수행사는 요구사항 정의서에 적힌 것을 최대한 바꾸지 않으려 하니, ‘요구사항이 불확실하다는 것을 사실로써’ 인정하기란 참으로 어려운 일이다.

물론 현실에서, 수행사가 절대적으로 불리한 게임이지만, 이런 ‘비협조적 게임’ 상태에서 그 결과가 발주사에게도 좋은 것은 아니다. 그렇다면 여기서 협조적 게임으로 변환하면 되는데, 협조적 게임을 생각하다 보면, ‘애자일 선언’문이 떠오르는 것은 자연스러운 일이다.

그러나, ‘고정금액 계약’과 ‘비협조적 게임’이 상식으로 받아들이는 현실에서, ‘애자일 선언’을 순진하게 프로젝트에 적용하는 수행사 PM은, 팀원들을 사지로 몰아가는 최악수를 두는 것이다. 고로 이런 게임 관점에서, ‘애자일 프로젝트 관리’라는 것은 ‘협조적 게임’이 기본일 때 가능하다는 생각이다.

경쟁자 관점에서 최선의 선택을 하는 ‘비협조적 게임인 SI 프로젝트’에서 ‘애자일 프로젝트 관리’란 그리 쉬운 일이 아니다. 즉, ‘애자일 프로젝트를 관리’를 프로젝트에 도입하는 전체 최적화보다는 효율을 조금 높이는 미시 수준에서 ‘애자일 프랙티스’를 도입하는 편이 낫다.

* BJR = 배째라.

This entry was posted on Friday, May 9th, 2008 at 11:13 pm and is filed under software. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.