I will have a positive influence on the World - MJ KIM

본글은 딸기우유님의 자료를 퍼온 것입니다.

위험관리에 대한 고찰 (Advanced Risk Management)

http://yjhyjh.egloos.com/267034

프로젝트 매니저가 뛰어난 사람인지 아닌지를 알아볼 수 있는 방법에는 여러가지가 있을 것이다.
그중 하나가, 이 양반이 위험관리를 하는 사람인가를 살펴보는 것이다.
위험관리를 하고 있다면, PM내공이 상당함을 인정해도 된다고 본다.

위험관리가 무엇이고 왜 중요하고 하는 것은 회사생활 5년차 넘으면 알긴 알 것이다.
근데 정말 알까?
최근, 부장/차장 급들이 신경써서 만들었다는 RR모델(Risk/Return Model)을 보고 사람들이 위험에 대한 개념이 없는 경우가 제법 있다고 느꼈다. (지금 나는 이 바닥에서 20년 이상 묵은 사람들이 위험의 정의를 잘못내리고 있다는 건방진 말을 하고 있는 것이다.)
이에 대한 자세한 내용은 다음 포스트(http://yjhyjh.egloos.com/279741)에서 다루기로 하고, 먼저 실전에서 사용해야 하는 위험관리에 대해 쭉 한번 살펴보겠다.
(일부는 PMBOK의 내용보다 깊이가 있을 수도 있으므로, 다소 난해한 설명이 되더라도 너그러이 이해를 바라면서...)

< 위험의 정의 >
먼저 위험(Risk, 리스크)의 정의는 다음과 같다.

• 원치 않는 결과를 초래하게 될 발생 가능한 미래의 사건

이쯤에서 위험(Risk)와 이슈(Issue)의 차이점을 먼저 짚어보자.
이 둘의 정의를 정리하면 Figure 1과 같다.

< Figure 1 >

요컨대, Risk는 아직 발생하지 않은 확률적 사건이고, Issue는 발생해서 프로젝트의 발목을 잡고 있는 문제점이다.
결국, Risk가 발현하면 Issue가 된다고도 할 수 있다.
이것이 리스크관리와 이슈관리를 종종 혼동하는 이유이기도 하다.

< 위험관리의 정의 >
이러한 리스크(Risk)는 관리되어야 한다.
위험관리 또는 리스크관리에 대한 정의는 다음과 같다.

• Risk가 추상적인 상태에서, 문제로 되기 전(이슈화 되기 전)에 대응책을 생각해 내는 과정이다.
• A disciplined and systematic method of managing risk is necessary and feasible to control the quality, cost, and schedule of software products [CMU/SEI]

< 위험 발생 통제 : Trigger >
위험관리의 핵심은 아직 발생하지 않은 (확률적으로 발생 가능한) 위험을 어떻게 관리할 것이나의 것이다.
우리는 이를 위해 발생하기 전에 발생을 예고하는 조짐을 관찰하고 통제해야 한다.
위험이 발현될 것임을 알려주는 신호를 Risk 전이 경계지표(Trigger)라고 한다.
즉, Trigger는 Risk가 현실화되는 촉발점이다.
우리는 Risk 각각에 대해 한 개 이상의 Trigger를 설정하고, 항상 감시해야 한다.
구르는 공은 뛰어오는 아이보다 앞서 나타난다라는 격언을 떠올려보면, 무슨 말인지 쉽게 이해갈 것이다.


< 위험관리가 필요한 이유 >
프로젝트는 다음과 같은 특징을 가진다.

• 프로젝트에서 만드는 산출물 중에 변하지 않는 산출물은 없다.
• 프로젝트에서 존재하는 불확실성은 제거할 수 없다.
• 변경을 통제하는 것보다, 변경의 종류/규모/빈도를 예측하는 것이 더 효과적이다.
• 동일한 프로젝트는 없다.
• 정확한 일정계획 및 비용계획을 수립할 수 없다.
• 대부분의 프로젝트는 일정/원가/품질을 모두 만족시키기 어려운 조건으로 진행된다.

불확실성이 있는 곳에는 언제나 Risk가 있다.
이러한 Risk에 대해 “모르겠다”라는 대답을 하는 것보다는, 불확실성 정도를 이해하는 것이 문제에 대응할 수 있는 실마리를 제공한다.
프로젝트는 항상 불확실성에 시달리므로 위험관리가 꼭 필요하다.
위에 언급한 위험관리가 필요한 이유를 도식화 하면 Figure 2와 같다.

< Figure 2 >

< 위험관리 프로세스 >
PMBOK에서 제안하는 위험관리 표준 프로세스를 조금 수정하여 내가 사용하고 있는 프로세스는 Figure 3과 같다.

< Figure 3 >

• Risk Management Planning (위험 관리 계획 수립)
• Risk Identification (위험 인지/확인)
• Risk Analysis (위험 분석)
• Risk Response Planning (위험 완화전략 수립)
• Risk Monitoring & Control (위험 모니터링)

< 위험 정량분석 >
위험은 불확실성으로 인한 잠재적 문제점이다.
그러므로 위험은 확률모델로 정량화되게 된다.
기본적인 위험 분석에 사용될 수 있는 툴은 Risk Rating Matrix Analysis 이다.
이것은 마치 정량화 분석처럼 보이지만, 사실은 이를 흉내낸 정성적 분석이다. 물론, 이것은 정량화의 시작점이 되기 때문에 의미가 있다.
Risk Rating Matrix Analysis에서는 Figure 4와 같은 방식으로 발생가능성과 영향력을 평가해서 각 Risk의 우선순위를 결정한다.

< Figure 4 >

Risk Rating Matrix Analysis를 통해 위험의 발현으로 인한 영향력을 예상할 수 있으며, 각 위험의 우선순위를 파악할 수 있다.

하지만, 진정한 위험관리의 꽃은 리스크 다이어그램(Risk Diagram)이다.
리스크 다이어그램은 특정항목에 대해 불확실성을 확률기반 다이어그램으로 나타낸 것이다.
이것은 특정항목의 목표달성이 정확히 얼마나 불확실 할까를 통계적으로 파악하여 위험을 가늠하는 것이다.
Figure 5와 같은 모양으로 나타나는 리스크 다이어그램의 특징은 다음과 같다.

• 모든 확률의 합이 1이 되도록 수직축 값의 크기를 결정한다.
• 정규분포에서 고성과쪽으로 군집하는 모양을 보인다.
• Continuous Probability Distributions

< Figure 5 >

Figure 5는 일정에 대한 리스크 다이어그램이다.
이에 대한 해석을 짧게 정리하면 아래와 같다.

• 그래프의 X축은 날짜를 나타내며, 그래프의 면적은 해당날짜에 완료할 수 있을 확률이다.
• 여 기서 극소-확률 일자(Nano-Percent Date)는 곡선과 수평축이 만나는 지점의 확률이 0이 아닌 첫번째 날짜로써, 해당 날짜에 완료가능성이 발생하기 시작하는 지점이다. N지점에서는 아직 완료할 수 있을 가능성이 0%이다.
• N지점 보다 나중 일자가 되면 조금씩 완료가능성이 높아진다. 점선으로 표시된 지점의 날짜에 프로젝트가 완료될 확률은 약 30%쯤 된다.
• X축과 맞닿는 지점 이후로 완료일자를 잡으면, 과제가 제때 끝날 가능성은 100%에 육박한다. (물론, 이렇게 너그러운 완료일정을 주는 프로젝트는 전혀 없을 것이다.)
• 모든 일정 리스크는 다음과 같은 원인에 기인한다. : 실제 완료 일정 < 목표 일정 < N
  현실에서 대부분의 프로젝트는 N을 완료일자로 잡아서 일정준수에 실패한다.

이와 같은 리스크 다이어그램은 어떻게 그리는 것일까?
바로 몬테카를로 시뮬레이션을 이용해서 그린다. (이전포스트 "몬테카를로 시뮬레이션 (Monte-Carlo Simulation)" 참조)

리스크 다이어그램의 불확정구간의 크기는 조직의 개발 프로세스에 얼마나 많은 노이즈(noise)가 포함되는지에 따라 결정되는 것이다. (Worse case penalty, Most likely case penalty, Best case penalty로 산정하는 것도 한 방법이다.)
프로세스 노이즈는 과거의 Risk가 프로젝트에 미친 영향에 대한 정량화를 통해 나오는 결과다. 즉, 과거의 성과가 불확정구간의 크기를 결정하는 것이다.

리스크 다이어그램의 분석법 및 응용에 대해서는 더 많은 내용이 있다.
이것은 톰 디마르코와 티모시 리스터의 '소프트웨어 프로젝트에서의 리스크 관리'를 읽어서 습득할 것을 권한다.

어제의 문제는 오늘의 Risk이다.
프 로젝트의 문제는 반복해서 발생하는 경향이 있어서, 대여섯 개의 프로젝트만 분석해보면 어느정도 충분한 데이터를 얻을 수 있다. 우리는 지속적으로 축적된 프로젝트 Lessons Learned와 위험관리 노하우의 갱신을 통해서 Risk관리 수준을 높일 수 있다.

< 결언 >
위험은 불확실성으로 인한 잠재적 문제점이라는 점을 명심해야 한다.
그러므로, 위험을 말할때는 반드시 확률을 떠올릴 수 있어야한다.
그리고, 위험관리를 말할 때는 항상 리스크 다이어그램을 떠올려야 한다.
많은 사람들이 이슈(issue), 제약(constraint)과 위험(Risk)를 혼동하여, 위험관리를 제대로 못하곤 한다.
아직가지 위험관리를 한다고 말하면서 확률모델을 다루지 않았다면, 그대는 엉뚱한 것을 하느라고 위험관리를 못했다고 보면 된다. (무엇인가는 했을 것일테니까... 늘 그렇듯이...)
심지어 PMP 획득을 위해, 열심히 공부하는 PMBOK에서도 위험을 확률모델로 이해하려는 시도는 약한 것 같다.
위험관리에 대해서는 PMBOK만 보는 것으로는 부족하다. 좀 더 많은 위험관리 전문가의 서적을 읽어볼 것을 권한다.

프로젝트 관리에서 위험관리는 프로젝트의 불확실성 요소를 통제하려고 하는 확률모델적 접근임을 이 글을 읽는 독자라도 꼭 이해해 줬으면 한다.


<연관 포스트 소개>
다음 포스트에서는 Risk/Return Model (일명 R-R Chart)를 언급하면서 우리회사의 관리자들이 위험을 어떻게 잘못 이해하고 적용했는가를 설명하겠다.
또 다른 포스트에서는 크리티컬 패스(Criticla Path)와 위험관리(Risk Management)의 연관성을 설명한다.

http://yjhyjh.egloos.com/267034

본글은 딸기우유님의 블로그에서 퍼온 자료입니다.

몬테카를로 시뮬레이션 (Monte-Carlo Simulation)

http://yjhyjh.egloos.com/33072

연구(R&D) 기획일을 하다보면 불확정적인 정보들로 인해 결론내리기가 애매한 경우를 많이 당한다.
특히, 나를 포함한 공학도 출신들은 정확히 딱딱 떨어지는 계산결과에 쾌감마져 느끼는 사람들이 많다. 이런 사람들은 '이럴수도 있고, 저럴수도 있다'라는 식의 정보가 나오게 되면 결과를 내놓고도 결과가 흔들릴 수 있다는 생각에 잠이 잘 안오곤 한다.
기획은 planning이기 때문에 forecasting과 추론을 포함할 수 밖에 없다. 그리고 여기에 영향을 미치는 대부분의 요소들은 확률변수이다.
확률이 존재하는 의사결정이 필요한 상황에 내가 종종 들고 나오는 무기(tool)는 몬테카를로 시뮬레이션(Monte-Carlo Simulation)이다.

<몬테카를로 시뮬레이션의 개요>
변 수의 관계가 확실하여 예측치를 정확하게 찾을 수 있는 확정모형(deterministic model)과는 달리, 기획일의 많은 부분은 결과를 정확하게 예측할 수 없는 확률모형(stochastic model)이다. 일반적으로 확정모형에서는 분석적 해(analytical solution)을 찾는 것이 가능하다. 그러나 확률모형에서는 분석적인 방법으로 해를 찾는 것이 불가능 한 경우가 많다. 이 경우에는 수치적(numerical)으로 일련의 난수를 반복적으로 발생해서 시뮬레이션을 하면 답을 찾을 수 있는데 이것이 몬테카를로 시뮬레이션이다.

기본 사상은 각각의 단위 변수의 패턴을 알아내서, 의사결정을 위한 그 단위 변수의 조합의 패턴을 추정하는 것이다.
다시말해, 각각의 변수의 확률분포를 통합해서 목표로 하는 값의 확률분포를 알아내는 것이다.
Figure 1.을 보면 이게 무슨말인지 쉽게 이해할 것이다.

< Figure 1 >

그럼 단위 변수들의 확률모델은 어떻게 알아내느냐고? 그건 최소한 의사결정을 위한 목표값의 확룔모델을 알아내는 것보다는 몇갑절 쉽고 정확하다. 범위와 그 속성을 알면 누구나 동감할 만한 수준의 패턴을 찾아낼 수 있기 때문이다.

몬테카를로 시뮬레이션에 대한 비교적 이해하기 쉬운 글이 하나 있어서 추천한다. 아래를 클릭해서 읽어보면 도움이 될 것이다.
http://www.nemopartners.com/webzine/webzine0504_10.asp

이즈음에서 실제 적용사례를 하나 예로 들어보자.
일 단, 몬테카를로 시뮬레이션을 돌릴 툴이 필요하다. 각종 나이스한 통계툴들이 많이 판매되고 있지만, 이거 하겠다고 SW사달라고하면 사줄회사가 몇이나 될까? 대기업인 우리도 절대 사줄리 없다. 나중에 그 효용이 공유되고 아주 많은 경우에 통계기법이 활용되는 상황이 펼처지면 그때는 사줄 것이다. 그러므로 많은 분들은 엑셀을 써야만 하는 환경에 있으리라 믿어 의심치 않는다. (여기에 내가 그렇게 노래를 부르는 MS Excel의 power user가 되어야 하는 이유가 있다.)
엑셀을 이용하여 몬테카를로 시뮬레이션을 돌리는 것과 관련해서는 경문사의 '(엑셀/VBA를 이용한) 금융공학' 책을 읽어볼 것을 추천한다. 어느정도 수준급의 사용자는 굳이 이책을 읽지않고도 스스로 엑셀을 이용한 분석툴을 디자인 할 수 있겠지만 말이다.
이 예제에서는 모두 3가지 변수를 사용하여, 목표지수를 알아내려는 시도를 한다.
3 개의 변수(A, B, C)는 향후 몇년간 주어진 범위 내에서만 움직일 것이 확실하지만, 정확히 어떤값이 될지는 기업내외부 사정에 따라서 달라지므로 무어라 탁 꼬집어 말할 수 없는 상황이다. 다행히 A와 B의 트랜드는 파악이 되어서 어느정도 패턴을 유추할 수는 있는 상황이다. Metric C는 패턴이란게 절대 안보이고 범위안에서 제멋대로 나오므로 random변수를 사용할 수 밖에 없다.
3개의 변수에 대한 범위와 그 패턴정의는 Figure 2.와 같다.

< Figure 2 >

이러한 조건을 이용해서, 각 Metric의 난수생성을 해보자. (엑셀의 함수기능을 활용해야 하는데, 그것은 위에 추천한 책이나 엑셀의 도움말을 보고 공부하도록 한다. 여기서 엑셀 강좌까지 할 수는 없지 않은가?)
임 의로 각각 2천개씩 생성해서 돌리면 어느정도 답의 패턴이 보인다. 금융공학에서는 1백만번 이상이 되면 신뢰할만하다고 말을 하는데, 프로그래밍 하지않고 엑셀의 기능만 이용하면 이건 현실적으로 불가능하고 꼭 그렇게 안해도 2천번이면 충분히 결과가 나오더라.
Figure 3.은 2천개의 난수패턴에 결합모델을 이용한 엑셀파일의 일부이다. 오만가지 경우에 대한 목표지수가 나열된다. 몇개가? 2천번 돌렸으니 2천개가!

< Figure 3 >

Figure 3.을 보면 일단 무슨짓을 한것인지는 알 수 있을 것이다. 각 경우에 대한 목표값을 일일이 만들어보는 것이다. 사람이 할 짓이 아니므로, 컴퓨터가 필요한 것이 바로 몬테카를로 시뮬레이션이다.

Figure 4.은 각 Metric과 목표지수의 결과값을 오름차순으로 sorting해서 그 패턴을 분석해본 것이다. 과연, 확률모델상에서는 어떤일이 벌어진건지 설명해주기 위해서, 별도로 만들어 본 것이다. (목표지수도 sorting된 것이므로 Figure 3.에서처럼 Metric A, B, C의 연산으로 산정되는 테이블이 아님을 명심할 것)

< Figure 4 >

위의 Figure 4.를 보면 A와 B와 C의 패턴이 만나서, 목표값의 패턴이 되는 과정을 볼 수 있다. (사실 막대그래프인데 2천개를 정렬해서 세워놓으면 이런 차트가 나온다. 미적분의 원리 아닌가? ^^)
물 론 목표값자체도 확률모델로 나오므로, 1개의 정확한 해가 구해지는 것은 아니다. 하지만 적어도 의사결정에 사용될 결과값이 어떻게 움직일지가 예상될 수 있드며, 목표값이 어느 부분에 집중되어 있으므로 어디를 공략하는게 성공율이 높은지의 정보가 나온다.
충분히 값진 결과이다.


<몬테카를로 시뮬레이션 결과의 보고>
몬테카를로 시뮬레이션 결과는 어떻게 보고 되어야 할까?
난 편의상 복잡한 것을 싫어하는 상사에게는 가장 빈도높고 성공확률 높은 값(통상적으로 평균이 되는 경향이 있지만)을 찾아내서 그것을 알려주기도 한다. 하지만, 이것은 상황에 따라 그러는 것이고, 정공법은 아니다.
몬테카를로 시뮬레이션의 결과는 확률로 보고되는것이 정공법이다.
결과값은 각 구간별 빈도수를 체크하여 차트로 구성한다. 그러면 각 구간별로 발생할 수 있는 확률패턴이 나타나게 되는데 이것이 의사결정에 도움이 된다. (가장 대표적인게 표준정규분포표 아닌가?)

Figure 5.는 톰 디마르코와 티모시 리스터의 '소프트웨어 프로젝트에서의 리스크 관리'란 책에서 제공하는 Riskology라는 엑셀로 개발된 툴을 이용한 결과이다. (힌트를 주자면, 위에서 언급한 예제를 빈도수를 가지고 히스토그램을 만들어보면 아래와 똑같은 모양이 된다. 한번 해보기 바란다.)

< Figure 5 >

이것은 특정 프로젝트의 완료일자에 영향을 주는 다양한 요소를 고려해서 만들어진 완료일자 확률모델이다.
프로젝트는 상황이 충분히 좋으면 8월 11일에 종료될 수도 있고, 상황이 어려워지면 이듬해 12월까지 질질 끌려 지연될 수도 있다.
여 러분이 이 프로젝트를 맡았다면, 언제까지 과제를 종료시키겠다고 말할 것인가? 영업에선 8월 중에 종료할 수있다고(사실은 그럴 가능성이 있기는 하지만) 밀어붙이겠지만, 함부로 8월에 끝낼 수 있다고 장담할 수 있는 사람은 없을 것이다.
그러면, 어떻게 보고를 해야 할까? 내년 5월 완료? 7월 완료? 이쯤되면 그만두란 소리를 들을 법도 하다.
몬테카를로 시뮬레이션을 이해하는 사람간의 대화라면 아마 다음과 같을 것이다.
"이 프로젝트를 금년 10월까지 성공적으로 완료할 수 있는 확률은 15%남짓 합니다. 하지만 올해 12월까지 완료될 가능성은 30%는 되므로, 출시일정을 이에 맞추면 30%이상의 성공을 기대할 수 있을 것 같습니다."
이 대화가 이상해 보이는가?
난 이정도로 정량화된 사고와 대응을 할 수 있는 후배라면, 돈이 얼마나 들던 꼭 데려오고 싶을 것 같다.

참고로, Figure 5와 같은 모델을 리스크 다이어그램(Risk Diagram)이라고 한다.
이것은 정량적 위험관리의 강력한 툴로 사용된다.
몬테카를로 시뮬레이션이 적극적으로 활용되는 분야가 위험관리인데 이에 대해서는 위험관리에 대한 고찰 (Advanced Risk Management) 포스트를 참조하기 바란다.


<TIP>
몬테카를로 시뮬레이션은 무척 다양한 용도로 쓰인다.
(정량적 위험관리, 사업리스크 분석, 금융공학, 품질관리 등등)
확률이 존재하는 의사결정이 필요한 모든 부분에서 우선적으로 사용을 검토해보길 권한다.
최소한, 기존의 주먹구구 방식보다는 진일보시켰다는 평가를 받을 수 있을 것이다.