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 이병준

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

Extremely Agile/General2007.11.12 01:44
'프로그래밍의 도' (Tao of Programming)라는 유명한 농담이 있습니다. 꽤 재미있는 농담입니다만, 저는 이 농담이 두 가지 측면에서 좋지 않다고 생각합니다. 프로그래머라는 사람들은 조직의 가치에 융화되기 어려운 사람들이라는 잘못된 생각을 전파시킬 수 있다는 점에서 그렇고, 이 농담에서 묘사하는 '도를 깨친 프로그래머'가 실제 프로그래머의 모습과 상당히 거리가 있기 때문에 더 그렇습니다.

제자(第子)가 스승에게 묻기를: "저 프로그래머는 설계(設計)도 않고, 문서(文書) 작성(作成)도 않으며 자기(自己) 프로그램을 테스트해 보지도 않습니다. 하지만 모두 그를 세계(世界)에서 가장 뛰어난 프로그래머라고 칭송(稱頌)합니다. 그 이유(理由)가 무엇입니까?"

가령, 위와 같은 문장이 그 예입니다. '테스트를 하지 않는 프로그래머'가 세계에서 가장 뛰어난 프로그래머라니요? 모든 좋은 프로그램들은 오히려 '뛰어난 테스트'로부터 만들어집니다. 테스트를 하지 않고서도 돌아갈 수 있는 프로그램을 만드는 프로그래머가 되고 싶은 마음은 이해하지만, 현실적으로는 불가능합니다.

도사(道士) 프로그래머 가라사대:
"프로그램을 테스트하고 있을 때는
설계(設計)를 변경(變更)하기엔 이미 늦은 다음이니라."

위의 문장은 부분적으로는 맞고, 부분적으로는 맞지 않습니다. 위의 명제가 맞으려면, 프로젝트가 거의 폭포수 형태로 진행되어야 하고, 설계는 프로젝트 초기에 모두 이루어져야 합니다. 하지만 프로젝트를 애자일 적으로 진행하는 경우에는 테스트를 통해 설계의 얼개가 드러나기도 합니다. 설계는 프로젝트 전반에 걸쳐 조금씩 진행되며, 결과적으로 테스트 시점에 떠안게 되는 오버헤드도 굉장히 낮아집니다. 그럼 저 명제를 제시한 '도사 프로그래머'는 정말로 도사일까요? (저는 아니라고 생각합니다.)

많은 해가 지나 관리자는 은퇴(隱退)하게 되었다. 은퇴식장에 가던 도중 그는 프로그래머가 터미날 앞에서 잠들어 있는 것을 보게 되었다. 그는 어제 밤을 새가며 프로그래밍을 했던 것이다.

위와 같은 문장은 프로그래머가 굉장히 무책임한 부류의 사람들이라는 인상을 줍니다만 (물론 원래 의도는 그렇지 않을 거라고 생각합니다만) 그것도 역시 사실이 아닙니다. 이렇게 사실이 아닌 문장이 농담을 빌어 나열된 것은, 아마도 다음과 같은 이유 때문일 겁니다. 역시 '프로그래밍의 도'에서 인용했습니다.

프로그래머는 왜 생산성(生産性)이 낮은가?
그들의 시간이 회의로 낭비(浪費)되기 때문이다.
프로그래머가 왜 툴툴거리는가?
관리자가 지나치게 참견하기 때문이다.
프로그래머가 왜 하나씩 회사를 떠나는가?
지쳤기 때문이다.
무능력(無能力)한 관리자 밑에서 일하는 프로그래머는 자신의 직업(職業)을 소중히 여기지 않는다.

위에 나열된 문제들은 계획(planning)을 프로젝트 전반기에 어떻게든 마무리하고 그렇게 해서 만들어진 프로젝트를 고수하려고만 하는 프로젝트 팀에서 빈번히 발견됩니다. 전반기의 회의 시간에 상당수의 프로그래머들은 졸거나 다른 일을 하고, 막상 개발에 들어가고 나면 관리자들이 요구사항을 지나치게 변경해 댄다고 툴툴거리게 됩니다. 그러다보면 정작 테스트는 프로젝트 막바지에 몰아서 하게 되고, 그 단계에 오류를 발견하게 된다고 하더라도 설계를 쉽게 변경할 수 없게 됩니다. 그러다보면 프로그래머들은 결국 지쳐서 하나둘씩 회사를 떠나게 되지요. 결국 관리자들은 '프로그래머들이란 책임감이라고는 눈꼽만치도 없는 인간들이야...'라는 식으로 생각하게 될 겁니다.

그러니, 위에서 언급한 '테스트를 하지 않는 프로그래머', 즉 도를 깨친 프로그래머는, 프로그래머가 당면한 여러가지 현실적 문제들을 논리적으로 거꾸로 뒤집어 만들어낸 캐릭터인 셈입니다. 현실과는 완전히 반대이며, 그렇기 때문에 또 정말로 바람직한 프로그래머의 상 과는 '현실적으로' 거리가 있는, 그런 캐릭터가 만들어진 것이죠.

그렇다면 저는 '프로그래밍의 도를 깨친 프로그래머는 애자일적인 프로그래머이다'라는 주장을 하고 싶은 걸까요? 사실 그건 아닙니다. '프로그래밍의 도'라는 이 농담이 폭포수적인 개발 관행의 부조리함에 대한 반감에서 나오긴 했습니다만, 그렇다고 애자일적인 프로그래밍을 하는 사람이 자동적으로 도를 깨친 프로그래머가 되는 건 아닙니다. 사실 '프로그래밍의 도'라는 이 농담에는 꽤 들어둘만한 구절도 몇 군데 있는데, 이런 구절들이 사실상 프로그래밍의 도란 무엇인가를 어느정도는 암시한다고 생각합니다. 결국 프로그래밍의 도라는 것은 특정한 방법론에 귀속되는 것은 아닌 셈이죠.

관리자는 보너스를 주려고 하였지만, 프로그래머는 거절(拒絶)하였다. 프로그래머 가로되. "나는 이 프로그램이 재미있다고 생각했기 때문에 작했을 뿐입니다. 따라서 나는 아무런 보상도 바라지 않습니다."
이 말을 들은 관리자가 말하기를, "이 프로그래머는, 비록 비천(卑賤)한 자리에 있으나, 종업원의 맡은 바 책무(責務)가 무엇인지 잘 알고 있다. 그를 보조 관리자로 승진시키도록 하자!"
그러나 이 말을 들은 프로그래머는 다시 한 번 거절하였다."나는 프로그램을 짤 수 있기 때문에 존재합니다. 만일 승진한다면 다른 사람의 시간을 갉아먹게 될 뿐입니다. 이제 가도 됩니까? 지금 짜고 있는 프로그램이 하나 있거든요."


이 글을 읽는 여러분은 프로그래밍의 도에 대해 어떤 생각을 가지고 계실지 궁금하군요.
 

신고
Posted by 이병준

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