Extremely Agile/General2008.09.24 11:49

불확실성(Uncertainty) : 장래 일어날 수 있는 사상()에 관해서 인간이 가진 정보의 정확성에 대한 하나의 구분. (출처 : 네이버 백과사전)

네이버 백과사전에 나온 불확실성의 정의에 따르면, 의사결정자가 가지고 있는 정보의 정확성은 ㉠ 확실성, ㉡ 리스크(risk), ㉢ 불확실성, ㉣ 무지()의 4종류로 분류할 수 있다고 합니다. 관련 부분을 인용해보죠.

㉠의 확실성은 무엇이 일어날지 확정적으로 알고 있는 경우를 말한다. ㉡의 리스크는 무엇이 일어날지 확정적으로는 알 수 없으나, 일어날 수 있는 상태는 알고 있고, 또 그 확률분포()도 알고 있는 경우를 말한다. 이에 대하여 ㉢의 불확실성은 일어날 수 있는 상태는 알고 있으나, 그 확률분포를 알지 못하는 경우를 말한다. ㉣의 무지란 무엇이 일어날지, 어떠한 상태가 일어날지, 전혀 예견할 수 없는 경우를 말한다. 한편, 넓은 뜻의 불확실성이란 ㉡의 리스크와 ㉢의 불확실성의 양자를 가리킨다.

이런 개념을 최초로 정립한 사람들은 경제학자들입니다. 돈이 걸리면 어떻게든 위험성을 줄이는 것이 좋으니까, 당연하겠죠. 소프트웨어 프로젝트에도 돈이 걸려 있기 때문에, 무슨 방법을 쓰던 위험성을 줄이면 줄일수록 이득입니다.

하지만 '확실성'이 갖는 정의 - 무엇이 일어날 지 확정적으로 알고 있는 경우 - 에 비추어보면, 확실성이란 달성이 불가능한 꿈과 같습니다. 확실성을 성취하려면 타임머신을 발명하던가 해야 합니다. '아무 일도 하지 않으면 되지 않느냐?'고 물으실 분도 계실 것 같은데, 아무 일도 하지 않으면 그 순간부터 유보수익이 사라지고, 기회비용 문제가 발생하기 시작합니다.

하지만 '불확실성'에 대한 '확실한 사실'이 한가지 있긴 합니다. 우리가 알고자 하는 것이 미래의 특정 시점에 일어날 사건에 대한 불확실성의 정도라고  한다면, 이 불확실성은 그 시점에 가까이 가면 갈수록 감소하는 경향을 보인다는 것이죠. 가령 우리 아기가 몇개월때 첫 걸음마를 뗄 것인지를 알고 싶다고 해 봅시다. 그리고 18개월쯤에는 첫걸음마를 뗄 것으로 예상한다고 해 봅시다. 이 예상이 갖는 불확실성은 시간이 흘러 18개월 근처로 가면 갈수록 감소합니다. 17개월이 되었는데도 엎드려 고개를 드는 것이 고작이라고 한다면? 아마 18개월에 첫 걸음마를 떼기는 힘들어지겠죠. 예상이 맞건 틀리건, 불확실성은 이런 식으로 감소 추세를 보이기 시작합니다. (물론 아이가 예상하지 못한 병에 걸린다거나 하는 불행한 일이 생기면 불확실성이 급상승하는 일도 생길 수 있긴 하겠습니다.)

불확실성이 갖는 이러한 속성과, 확실성, 위험, 지식이 갖는 속성들을 종합해 보면, 우리는 분명해 보이는 몇 가지 결론에 이르게 됩니다.

1. 시간이 흐르면 불확실성은 차츰 감소한다.
2. 지식이 늘어나면 불확실성은 차츰 감소한다.

이 지식에는 '확률적 지식'도 포함됩니다. 시간이 흐르면 사람들은 '어떤 사실'의 '발생 가능성'에 대한 지식을 자연스럽게 취득하게 됩니다. 확률적 지식이 100% 정확하다고는 볼 수 없습니다만, 적어도 한 잣대는 되어줄 수 있기 때문에, 불확실성은 그에 따라 차츰 감소하게 됩니다.

이런 불확실성의 개념이 소프트웨어 개발 프로젝트 관리 방법론의 한 근간으로 등장한 것은 사실 오래된 일입니다. 1981년 베리 뵘은 이후 스티브 멕코넬이 '불확실성 원추(Cone of Uncertainty)'라고 부르게 되는 그래프를 하나 그렸는데, 이것이 시발이라고 봐도 무방할 것 같습니다. 이 그래프가 보여주는 것은 사실 위에 제시했던 두 가지 뻔한 결론에 다름 아닙니다. 하지만 전통적인 개발 방법론이 이 자명한 사실을 인정하게 되는 데는 약간의 시간이 필요했죠. 애자일 선언문이 발표된 것이 2001년도이니까, 그 사람들이 지금은 '애자일'이라고 불리는 방법론을 가다듬는 데 필요했을 10년 정도의 세월을 감안하면, 불확실성이 화두로 등장하는 데는 10년 정도의 시간이 필요했다고 봐도 될 것 같네요.

그럼  불확실성이 프로젝트 관리에 있어서 가장 중요한 문제중 하나로 등장한 이유는 뭘까요? 아마 다 아시겠지만, 그것은 초기 계획대로 굴러가는 프로젝트가 별로 없기 때문이며, 초기 설계대로 우아하게 마무리되는 프로그램이 별로 없기 때문이고, 그런 일이 빈번하게 생기면 프로젝트 팀원들의 '꼭지가 돌아버리기' 때문입니다. 그리고 그런 프로젝트는 고객에게 '최선의 가치를 전달'하기가 점점 더 어려워지죠. 전통적인 방법론들은 프로젝트 도중에도 불쑥 뿔쑥 등장하곤 하는 이런 '꼭지도는 일들'을 어떻게 처리해야 하는지에 대해서는 별 이야기가 없습니다.

이쯤에서 이미 식상해졌을 지도 모를 애자일 이야기를 조금만 더 하자면... 애자일 방법론은 사실 불확실성에 관한 방법론입니다. 흔한 오해중에 한가지는 '애자일 방법론은 고객 중심 방법론이다'라는 것인데, 사실 이 이야기는 반 정도는 맞고 반 정도는 틀립니다. 사용자를 무조건 만족시키는 것이 애자일 방법론의 목표는 아니기 때문이죠. 고객이 중요한 것은, 사용자가 프로젝트의 성패에 관련된 가장 중요한 이해 당사자 중 하나이기 때문입니다. 고객을 중요하게 생각하는 것은, 그들과 어떻게 의사소통하느냐에 따라 프로젝트의 불확실성 정도가 굉장히 많이 달라질 수 있기 때문입니다.

흔히 보는 장면
A : 이번 프로젝트의 요구사항 명세표를 분석해야 하는데요.
B : 누가 작성한 명세표죠?
C : 영업팀에서 작성한 겁니다.
D : 그거 영업 팀에서 분석해야 하는거 아닌가?
A : 이전 프로젝트 결과를 토대로 우리가 추가해줬음 하는 것도 있어서요.
B : 그런걸 요구사항이라고 부를 수 있나요?
A : 엇비슷한 프로젝트니까 일단은 그렇게 하고 프로젝트를 진행해달라는 게 '영업팀의' 요구사항이죠.
B : 왜?
C : 받아온 프로젝트 기간이 좀 빡빡해서요.
(2달 후)
A : 우리가 구현한 기능들 중 한 열개 항목 정도가 잘못되었다는 군요.
B : 누가 그래?
A : 고객이요.

보통 개발자들이 고객을 미워하는 이유는 개발자들이 보기에 고객이란 사람들이 '뭘 잘 모르는 사람들'처럼 보이기 때문도 있습니다만, 가장 큰 이유는 프로젝트 진행 중에 요구사항을 변경하는 사람들이 대부분 고객이기 때문입니다. 그런 일이 자주 생기면, 개발자들의 인생은 급속도로 피폐해집니다.

그런데 사실 그건 고객 잘못은 아니에요. 위의 '흔히 보는 장면' (진짜로 이런 일이 흔하면 큰일나겠습니다만 ㅋㅋ)에서도 느끼실 수 있겠지만, 애초에 프로젝트를 진행하는 팀이 고객과 의사소통을 할 기회가 없었다는 것이 가장 큰 문제죠. 자뻑용 프로젝트를 한다면야 모르곘지만, 개발팀을 고객과 떼놓고 프로젝트를 하면 득보다는 실이 더 많아질 수도 있습니다. 고객/사용자는 종종 시장 그 자체이며, 시장의 변화를 외면하면서 시장에 '최선의 가치를 전달할' 방법 같은 것은 없습니다. 시장의 변화라는 것은 곧 '불확실성'이기 때문에, 우리는 어떻게든 불확실성을 끌어안을 방법을 찾아내야 합니다.

애자일 방법론이 의사소통의 문제를 가끔 비 이성적으로 보일 때 까지 깊이 탐구하는 것은 아마 그래서 일 겁니다. 애자일 방법론은 구두로 나눈 대화와, 그 자리에서 합의된 사항을 '개발 계획서'보다 더 중시하는 경향이 있습니다. (이 점이 전통적인 방법론을 옹호하는 사람들의 심기를 굉장히 불편하게 만들곤 합니다만...) 이건 제 개인적인 경험입니다만, 지식을 늘리는 가장 간단한 방법른 사실 구글 검색도 아니고 독서도 아닙니다. '대화'죠. 대화가 확대할 수 있는 지식의 영역은 특별히 어딘가로 제한되지 않습니다. 하지만 프로젝트 진행에 있어 가장 도움되는 부분은 다음의 몇 가지 일 것 같군요. (무순)

1. 프로젝트 자체에 대한 지식
2. 팀원에 대한 지식
3. 고객/사용자에 대한 지식

앞서도 언급했었습니다만, 지식이 증가하면 불확실성은 감소합니다. 지식을 늘리는 방법으로 스파이크(spike) 같은 것도 있습니다만, 아무래도 고수와의 커피타임만큼 짧고 효율적이진 않습니다. 요구사항 변화에서 오는 야근을 줄이는 방법으로 '무조건적인 퇴근시간 준수'같은 것도 있겠습니다만, 아무래도 요구사항을 낸 이해 당사자와의 전화통화만큼 효과적이지는 못합니다.

의사소통을 자주 그리고 효율적으로 하게 되면 프로젝트 중반에 발생하는 이런 저런 일들에 보다 능동적으로 대처할 수 있게 됩니다. 그리고 팀이 지금 어디쯤 와 있는지 좀 더 분명히 알 수 있게 되고, 앞으로 발생할 지 모를 '꼭지도는' 일들이 팀의 항로를 어떻게 바꾸어 놓게 될지 좀 더 명료하게 알 수 있게 됩니다.

의사소통을 강조하는 것이 자기 파티션 안에 처박혀 있기를 좋아하는 개발자들의 습성과 배치되긴 합니다만, 그런 개발자의 모습은 개발이라는 것을 종종 예술(art)과 비슷한 것으로 묘사하는 너드(nerd) 문화의 클리셰일 가능성이 높습니다. 개발자들은 프로그래밍이 오타쿠들이 좋아하는 저패니메이션같은 것과는 질적으로 다르다는 사실을 깨달을 필요가 있어요. 개발은 현실이고, 현실은 가혹합니다. 개발자들이 의사소통을 무시하고 파티션 안에 처박혀 있으려는 습성은 어찌보면 개발자들이 처한 현실이 주는 문제를 계속해서 재생산하는 측면이 있습니다. 그냥 그 안에 처박혀서 '사용자들은 아무것도 몰라'라고 해서는 인간다운 생활을 영위할 수 없다는 것이 문제라는 거죠. 불확실성을 감소시키지 않으면, 야근 일수는 줄어들지 않는다, 뭐 그런 이야기죠.

하지만 굳이 불확실성 이야기의 외연을 개발자 각각의 삶으로 넓혀놓지 않더라도, 불확실성을 감소시키는 것은 중요합니다. 소프트웨어 프로젝트의 목표가 '고객에게 최선의 가치를 전달'하는 것이라고 보면, '최선의 가치'라는 것의 정의는 시간이 지나면 어떻게든 변화하게 될 처지이니 (시장 상황은 자고 일어나면 바뀌죠) 불확실성이라는 것이 존재한다는 사실을 인정하고 그것과 '화해할 수 있는' 전략을 수립하도록 애쓰는 것이 프로젝트를 관리하는 사람이 해야 하는 일이 아닐까요?


신고
Posted by 이병준

소중한 의견, 감사합니다. ^^