불확실성과 리스크

cd ~/gh-pm-lab
source pm-lab/env.sh

1리스크, 이슈, 불확실성

세 말은 회의에서 섞여 쓰이지만 다루는 방법이 다르다.

국제 표준 ISO 31000:2018은 리스크를 “목표에 대한 불확실성의 영향(effect of uncertainty on objectives)”으로 정의한다. PMI의 The Standard for Risk Management in Portfolios, Programs, and Projects(2019)도 리스크에 위협(threat)과 기회(opportunity)를 모두 넣는다. 리스크 등록부에 나쁜 일만 적으면 일정을 줄일 기회를 찾지 않게 된다.

아래 여섯 문장을 셋 중 하나로 나누자. 리스크이면 위협인지 기회인지도 적는다.

1. LP-03 담당자가 다음 주 화·수요일 휴가를 신청했고 승인되었다.
2. 법무 검토 결과에 따라 재신청 정책이 바뀔 수 있다.
3. 알림 발송 서비스의 계정 승인이 아직 오지 않아 LP-04를 시작하지 못하고 있다.
4. 베타 신청이 하루 500건을 넘으면 사내 메일 서버의 발송 한도를 넘는다.
5. 사내 폼 라이브러리를 쓰면 LP-03이 2작업일 줄어들 수 있다.
6. LP-05 QA가 2작업일에서 7작업일 사이 얼마나 걸릴지 모른다.

2불확실성의 종류와 상황 판단

불확실성은 줄일 수 있는가에 따라 둘로 나눈다.

스노든(D. J. Snowden)과 분(M. E. Boone)은 2007년 Harvard Business Review에 상황을 원인과 결과의 관계로 나누는 틀인 커네빈(Cynefin)을 정리했다. 상황에 따라 맞는 대응 순서가 다르다.

아래 네 상황이 어느 영역인지 정하고, 그 영역에서 몬테카를로 일정 위험 분석이 쓸모 있는지 함께 판단하자.

1. 이메일 형식 검사 규칙을 구현한다.
2. 예상 신청 수에 맞춰 알림 발송 큐의 서버 구성을 정한다.
3. 베타 신청자가 어떤 안내 문구에 더 반응할지 정한다.
4. 공개 직후 신청 페이지 오류로 다른 신청자의 이메일이 화면에 보인다.

3리스크 관리 과정과 리스크 이슈

ISO 31000:2018의 리스크 관리 과정은 여섯 활동이다. 범위·맥락·기준 설정, 리스크 평가(식별, 분석, 평가), 리스크 처리, 모니터링과 검토, 기록과 보고, 그리고 이 모두에 걸친 소통과 협의다. 분석은 두 가지로 한다. 정성 분석은 확률과 영향을 1~5 척도로 매겨 순서를 정하고(실습 16의 위험 점수), 정량 분석은 확률과 영향을 숫자(금액, 작업일)로 놓고 계산한다(4·5단계).

리스크 서술은 원인, 사건, 영향의 세 부분으로 쓴다. “알림 서비스가 문제다”는 서술이 아니다. “알림 발송 서비스의 계정 심사가 3~5작업일 걸리기 때문에(원인) 승인이 LP-04 시작 전에 나지 않으면(사건) M1 완료가 최대 5작업일 늦어진다(영향)”가 서술이다. 원인이 있어야 대응을 고를 수 있고, 영향이 숫자여야 정량 분석에 쓸 수 있다.

키트의 리스크 양식은 이 서술 형식과 확률·영향 척도, 대응 전략, 발생 신호, 대응 기한을 칸으로 둔다. 실습 16에서 만든 risk 라벨은 다른 kind: 라벨과 맞춰 kind:risk로 바꾸고, Project에 대응 기한 필드를 더한다.

gh label edit risk -R "$PM_REPO" --name kind:risk
gh project field-create "$PM_PROJECT" --owner "$PM_OWNER" --name "Response due" --data-type DATE

cd launchpad-pm-lab
git switch main
git pull
mkdir -p .github/ISSUE_TEMPLATE
cp ../github-pm-starter-kit/templates/ISSUE_TEMPLATE/risk.yml .github/ISSUE_TEMPLATE/
git add .github/ISSUE_TEMPLATE/risk.yml
git commit -m "chore: 리스크 이슈 양식 추가"
git push
cd ..

라벨 이름을 바꾸면 이미 붙어 있던 R-01~R-03에도 새 이름이 보인다. 양식의 labels에 적은 라벨은 저장소에 그 라벨이 있을 때만 붙는다. 양식 파일은 기본 브랜치에 있어야 웹의 New issue 화면에 “리스크”가 나타난다.

# 저장소의 .github/ISSUE_TEMPLATE/risk.yml 로 복사하면 웹의 New issue 화면에 "리스크" 양식이 나타난다.
# 제출하면 항목마다 "### 항목 이름" 아래에 답이 적힌 본문이 만들어진다.
# kind:risk 라벨이 저장소에 먼저 있어야 붙는다: gh label create kind:risk --color D93F0B
# 확률과 영향의 숫자는 Project의 Probability, Impact 필드에도 같은 값으로 넣는다.
name: 리스크
description: 원인, 사건, 영향과 대응 계획이 있는 리스크(위협 또는 기회)
title: "[R-00] "
labels: ["kind:risk"]
body:
  - type: markdown
    attributes:
      value: 이미 일어난 문제는 이슈로 다룬다. 업무 이슈에 blocked 라벨과 원인을 남긴다.
  - type: dropdown
    id: direction
    attributes:
      label: 구분
      options:
        - 위협 (일어나면 목표에 나쁜 영향)
        - 기회 (일어나면 목표에 좋은 영향)
    validations:
      required: true
  - type: textarea
    id: statement
    attributes:
      label: 리스크 서술
      description: "원인, 사건, 영향의 세 부분으로 쓴다. 예: 알림 발송 서비스의 계정 승인이 3~5작업일 걸리기 때문에(원인) 승인이 LP-04 시작 전에 나지 않으면(사건) M1 완료가 최대 5작업일 늦어진다(영향)."
    validations:
      required: true
  - type: dropdown
    id: probability
    attributes:
      label: 확률
      description: 팀이 정한 척도로 고른다. 정량 분석에는 괄호 안의 대표값을 쓴다.
      options:
        - 1 (10% 미만, 대표값 5%)
        - 2 (10~30%, 대표값 20%)
        - 3 (30~50%, 대표값 40%)
        - 4 (50~70%, 대표값 60%)
        - 5 (70% 이상, 대표값 80%)
    validations:
      required: true

양식의 문법은 GitHub 문서 Syntax for issue forms와 form schema를 따른다. 맨 위 키는 name, description, body가 필수이고 title, labels는 선택이다. dropdown의 options는 서로 다른 문자열 목록이어야 한다. 전체 파일은 키트의 risk.yml에 있다.

4기대 금전 가치와 결정 나무

기대 금전 가치(Expected Monetary Value, EMV)는 결과마다 확률 × 금액을 더한 값이다. 대응 방법이 여러 개면 대응마다 EMV를 계산하고, 가장 큰 값(손실이면 가장 작은 손실)을 고른다. 결정 나무(decision tree)는 이 계산을 선택(네모)과 확률 사건(동그라미)의 가지로 그린 것이다.

R-02(알림 발송 서비스 계정 승인 지연)로 계산해 보자. 필요한 숫자는 네 가지다.

• 업체가 안내한 심사 기간은 3~5작업일이다. 회사가 같은 업체에 낸 지난 계정 신청 10건 중 3건이 5작업일을 넘겼다고 하자. 지연 확률은 0.3으로 잡는다.
• 승인이 늦으면 LP-04가 최대 5작업일 늦어진다. LP-04는 주경로에 있으므로 M1도 5작업일 늦어진다.
• M1이 1작업일 늦어질 때의 비용은 팀 4명 × 8시간 × 시간당 5만원(실습 14의 --rate 50000) = 160만원이다. 5작업일이면 800만원이다.
• 메일 알림 대체 경로를 미리 만드는 데 16시간, 80만원이 든다. LP-02 담당이 여유 5작업일 안에서 만들므로 주경로에 영향이 없다. 업체에 신속 심사를 요청하면 수수료 30만원이 들고 지연 확률이 0.1로 준다.

아래 표는 결정 나무의 가지를 한 줄씩 적은 것이다. 금액 단위는 만원이다.

EMV는 B(−80만원) > C(−110만원) > A(−240만원)이므로 B를 고른다. 같은 나무로 정보의 가치도 계산한다. 승인이 제때 날지 미리 안다면 제때일 때는 A(0원), 늦을 때는 B(−80만원)를 고르므로 EMV는 0.7 × 0 + 0.3 × (−80) = −24만원이다. 지금 최선인 −80만원과의 차이 56만원이 완전 정보의 기대 가치(EVPI)다. 업체에 심사 상태를 확인하는 데 56만원보다 적게 든다면 확인부터 하는 편이 낫다.

기회도 같은 식으로 계산한다. 사내 폼 라이브러리로 LP-03이 2작업일 줄어들 확률이 0.4이면, 주경로 단축 2 × 160 = 320만원의 기대값은 0.4 × 320 = 128만원이다. 6시간(30만원)짜리 기술 검토로 확률을 0.7로 올리면 −30 + 0.7 × 320 = 194만원이다. 194 − 128 = 66만원만큼 증대(enhance) 대응이 낫다.

5일정 위험 분석: 3점 추정과 몬테카를로

일정 위험 분석(Schedule Risk Analysis, SRA)은 업무 기간을 하나의 값 대신 분포로 놓고, 일정망을 수천 번 다시 계산해 완료일의 분포를 얻는다. 헐릿(D. Hulett)의 Practical Schedule Risk Analysis(2009)가 실무 절차를 정리한 책이다. 키트의 sra.sh는 이 계산을 한다. 업무마다 낙관·보통·비관 세 값을 받아 삼각분포에서 기간을 뽑고, cpm.sh와 같은 lib/cpm.jq로 가장 빠른 일정과 여유를 다시 계산하는 일을 시행마다 반복한다. 난수는 실습 15의 forecast.sh와 같은 생성기를 써서 같은 씨앗값이면 같은 결과가 나온다.

입력 파일은 schedule.tsv의 days를 세 열로 넓힌 것이다. 보통(likely) 값은 schedule.tsv와 같고, 선행 관계도 같다. LP-03의 4·6·11은 실습 13의 세 점 추정 예와 같은 값이다. LP-02의 비관 값 15는 브랜드 검수에서 두 번 반려되는 경우를 넣은 것이다.

# key	optimistic	likely	pessimistic	hours	predecessors
LP-01	2	3	6	12	-
LP-02	4	5	15	24	LP-01
LP-03	4	6	11	32	LP-01
LP-04	3	4	8	20	LP-03
LP-05	2	3	7	16	LP-02,LP-03,LP-04
LP-06	1	2	3	8	LP-05

먼저 보통 추정만으로 계산한 결정론적 일정을 다시 보고, 같은 네트워크로 1만 번 시행한다.

bash github-pm-starter-kit/cpm.sh github-pm-starter-kit/schedule.tsv --start 2026-10-12 --deadline 2026-11-06
bash github-pm-starter-kit/sra.sh github-pm-starter-kit/samples/d-schedule-3pt.tsv \
  --start 2026-10-12 --deadline 2026-11-06

sra.sh는 1만 회에 몇 초가 걸린다. 두 결과를 나란히 놓는다.

보통 추정으로 짠 일정이 실제로 그날 끝날 확률이 3.9%밖에 되지 않는 이유는 두 가지다.

1. 분포가 오른쪽으로 길다. 삼각분포의 평균은 (낙관 + 보통 + 비관) ÷ 3이다. 주경로 다섯 업무의 평균을 더하면 (2+3+6)/3 + (4+6+11)/3 + (3+4+8)/3 + (2+3+7)/3 + (1+2+3)/3 = 3.67 + 7 + 5 + 4 + 2 = 21.67작업일로, 보통 추정의 합 18작업일보다 3.67작업일 길다. 출력의 “평균 기간” 열이 이 값과 맞는다. 늦어질 수 있는 폭(비관 − 보통)이 앞당겨질 수 있는 폭(보통 − 낙관)보다 큰 업무가 많기 때문이다.
2. 경로가 합쳐지는 곳에서 늦은 쪽을 따른다. LP-05는 LP-02와 LP-04가 모두 끝나야 시작한다. 결정론적 계산에서 LP-02는 여유 5작업일로 주경로 밖이지만, 시행의 11.1%에서는 LP-02가 길게 걸려 주경로가 되었다. 헐릿은 이를 합류 편향(merge bias)이라고 부른다. 합류하는 경로가 많을수록 완료일은 결정론적 계산보다 늦어진다.

주경로 지수(criticality index)와 기간-완료일 상관은 다른 질문에 답한다. LP-01, LP-05, LP-06은 모든 경로에 있어 주경로 지수가 100%다. 그러나 기간-완료일 상관은 LP-03(0.58)이 LP-01(0.35)이나 LP-06(0.18)보다 크다. LP-03의 추정 범위(4~11)가 넓어 전체 기간의 변동을 더 많이 만든다는 뜻이다. 대응에 쓸 시간이 한정되어 있으면 상관이 큰 업무부터 범위를 좁힌다.

상관을 넣으면

위 결과는 업무 기간이 서로 독립이라고 본 것이다. 실제로는 같은 팀이 여러 업무를 하므로, 팀 전체가 예상보다 느리면 여러 업무가 함께 늦는다. 헐릿은 상관을 빼면 분포가 실제보다 좁게 나온다고 경고한다. --corr 0.5는 모든 업무 기간이 공통 요인 하나를 0.5만큼 나눠 갖게 한다.

bash github-pm-starter-kit/sra.sh github-pm-starter-kit/samples/d-schedule-3pt.tsv \
  --start 2026-10-12 --deadline 2026-11-06 --corr 0.5 | sed -n '8,31p'

## 완료일 분포

| 구분 | 작업일 | 완료일 |
| - | - | - |
| 결정론적(보통 추정) | 18 | 2026-11-04(수) |
| P50 | 22 | 2026-11-10(화) |
| P80 | 26 | 2026-11-16(월) |
| P90 | 28 | 2026-11-18(수) |

- 결정론적 완료일(2026-11-04(수))까지 끝낼 확률: 17.7%
- 마감일(2026-11-06(금))까지 끝낼 확률: 35.9%
- P80 기준 일정 예비: P80 − 결정론적 = 8 작업일

## 업무별 결과

| 업무 | 낙관 | 보통 | 비관 | 평균 기간 | 결정론적 여유 | 주경로 지수 | 기간-완료일 상관 |
| - | - | - | - | - | - | - | - |
| LP-01 | 2 | 3 | 6 | 3.7 | 0 | 100.0% | 0.73 |
| LP-02 | 4 | 5 | 15 | 8.0 | 5 | 4.2% | 0.65 |
| LP-03 | 4 | 6 | 11 | 7.0 | 0 | 96.1% | 0.82 |
| LP-04 | 3 | 4 | 8 | 5.0 | 0 | 96.1% | 0.77 |
| LP-05 | 2 | 3 | 7 | 4.0 | 0 | 100.0% | 0.77 |
| LP-06 | 1 | 2 | 3 | 2.0 | 0 | 100.0% | 0.69 |

P50은 22작업일로 같지만 P80은 24에서 26으로, P90은 25에서 28로 늦어졌다. 마감일까지 끝낼 확률은 21.7%에서 35.9%로 올랐다. 상관이 있으면 업무들이 함께 빨라지거나 함께 늦어지므로 분포의 양쪽 끝이 모두 넓어진다. 마감이 분포의 왼쪽(P50보다 앞)에 있으면 확률이 오르고, 예비를 정하는 P80·P90은 늦어진다. 같은 씨앗값을 썼으므로 두 실행의 차이는 상관 설정에서만 나온다. LP-02의 주경로 지수는 11.1%에서 4.2%로 내려갔다. LP-02가 길어지는 시행에서는 주경로 업무도 함께 길어지는 경우가 많아 LP-02가 주경로를 차지하는 일이 줄기 때문이다.

대응의 효과를 다시 계산하기

4단계에서 고른 대응 B(메일 대체 경로)를 하면 LP-04의 비관 값은 승인 지연분이 빠져 8에서 5가 된다. 입력 파일을 고쳐 다시 계산한다.

마감일까지 끝낼 확률이 21.7%에서 34.7%로, P80이 24작업일에서 23작업일로 바뀌었다. 대응 하나가 마감 확률을 13.0%p 올렸지만 여전히 절반에 못 미친다. 일정 위험 분석은 이렇게 대응 전과 후를 같은 씨앗값으로 비교할 때 쓴다.

6예비 일정과 크리티컬 체인 버퍼

예비(reserve)는 두 가지로 나눈다. 둘을 구분하지 않으면 PM이 쓸 수 있는 시간과 스폰서만 쓸 수 있는 시간이 섞인다.

Launchpad는 계산된 우발 예비 6작업일이 마감까지의 여유 2작업일보다 크다. PM이 혼자 메울 수 있는 차이가 아니므로 범위를 줄이거나, 마감을 P80 날짜(11월 12일)로 옮기거나, 사람을 더하는 것 중 하나를 스폰서가 정해야 한다. 이 차이가 계획 단계에서 숫자로 드러나는 것이 일정 위험 분석의 쓸모다.

리스크 등록부의 EMV를 더해 예비를 잡을 때는 겹침을 확인한다. LP-04의 비관 값 8에는 이미 R-02(승인 지연)가 들어 있으므로, 일정 위험 분석의 예비에 R-02의 EMV(0.3 × 5 = 1.5작업일)를 다시 더하면 같은 리스크를 두 번 센다.

크리티컬 체인 버퍼

골드랫(E. M. Goldratt)은 Critical Chain(1997)에서 업무마다 숨겨 둔 여유를 걷어 내 프로젝트 끝에 한 덩어리로 모으자고 했다. 업무 기간은 절반 확률로 끝나는 값으로 짧게 잡고, 주경로(자원 제약까지 넣은 크리티컬 체인) 끝에 프로젝트 버퍼를, 다른 경로가 합류하는 지점에 합류 버퍼(feeding buffer)를 둔다. 여기서는 보통 추정을 짧은 값으로, 비관 추정을 안전한 값으로 보고 계산한다.

체인 18작업일에 프로젝트 버퍼 8작업일을 더하면 26작업일, 11월 16일(월)이다. 일정 위험 분석의 P90(25작업일)과 하루 차이다. LP-02의 합류 버퍼 10작업일은 LP-02의 여유 5작업일보다 크다. LP-02를 LP-01 직후에 바로 시작하고 진행을 따로 지켜봐야 한다는 뜻이며, 일정 위험 분석에서 LP-02의 주경로 지수가 11.1%로 나온 것과 같은 결론이다.

버퍼 소진 차트

크리티컬 체인 방식은 업무별 목표일 대신 버퍼가 얼마나 줄었는지를 본다. 버퍼 소진 차트(fever chart)는 가로축에 체인 진척률, 세로축에 버퍼 소진률을 찍는다. 10월 21일에 LP-03 담당이 남은 기간을 4작업일로, 10월 28일에 LP-04 담당이 3작업일로 다시 추정했다고 하고 두 시점을 계산해 보자. 아직 시작하지 않은 업무는 보통 추정을 쓴다. 구간 경계는 팀이 정하며, 여기서는 소진률이 진척률 이하이면 녹색, 진척률 + 30%p 이하이면 황색, 그 위면 적색으로 둔다.

버퍼를 같은 3작업일 쓰고 있어도 체인이 더 진행된 10월 28일에는 녹색이다. 체인 앞부분에서 버퍼를 많이 쓰면 남은 체인에 쓸 버퍼가 적다는 것을 이 차트가 보여 준다.

7대응 전략과 리스크 소진

리스크 소진 차트(risk burndown)는 주마다 열린 리스크의 노출(확률 × 영향)을 더해 줄어드는지 본다. 키트의 samples/d-risk-weekly.tsv는 Launchpad 리스크 네 건의 값을 매주 월요일에 옮겨 적은 예다. 실제 팀에서는 Project 스냅숏(실습 18)이나 gh project item-list로 같은 값을 모은다.

awk -F'\t' '!/^#/ && $5 == "open" {
  if (!($1 in e)) w[++k] = $1
  e[$1] += $3 * $4; n[$1]++
}
END {
  for (i = 1; i <= k; i++) {
    bar = ""; for (j = 1; j <= e[w[i]] * 4 + 0.5; j++) bar = bar "#"
    printf "%s  열린 리스크 %d건  노출 %.1f 작업일  %s\n", w[i], n[w[i]], e[w[i]], bar
  }
}' github-pm-starter-kit/samples/d-risk-weekly.tsv

2026-10-12  열린 리스크 3건  노출 5.5 작업일  ######################
2026-10-19  열린 리스크 4건  노출 5.2 작업일  #####################
2026-10-26  열린 리스크 3건  노출 3.5 작업일  ##############
2026-11-02  열린 리스크 1건  노출 1.2 작업일  #####

노출은 5.5작업일에서 1.2작업일로 줄었지만 한 방향으로만 줄지는 않았다. 10월 19일에는 R-04(브랜드 검수 반려)가 새로 생겨 열린 리스크가 4건이 되었고, 10월 26일에는 R-03의 확률이 0.4에서 0.5로 올라 노출이 2.4에서 3.0작업일로 늘었다. 소진 차트는 총량과 함께 어느 리스크가 늘었는지를 같이 적어야 읽힌다. 상태 보고의 리스크 영역에는 다음처럼 적는다.

### 리스크
- 열린 리스크 3건, 노출 합계 3.5작업일 (지난주 5.2). R-01 종료(법무 확인 10-23).
- 늘어난 리스크: R-03 QA 배정 변경, 확률 0.4 → 0.5. 교차 검증 담당을 10-28까지 정한다.
- 일정 위험 분석(대응 B 반영): 11-06까지 끝낼 확률 34.7%, P80 11-11.
- 우발 예비: P80 − 결정론적 = 5작업일. 마감 여유 2작업일과의 차이 3작업일은 스폰서 결정 사항이다.

• 여섯 문장을 리스크, 이슈, 불확실성으로 나누고 이유를 말할 수 있다.
• 우연적·인식적 불확실성의 예를 Launchpad에서 하나씩 들 수 있다.
• 저장소에 kind:risk 라벨과 리스크 양식이 있고, Project에 Response due 필드가 있다.
• R-02 결정 나무의 세 EMV(−240, −80, −110만원)와 EVPI 56만원을 직접 계산했다.
• sra.sh를 실행해 P50·P80·P90, 마감 확률, 주경로 지수를 읽었다.
• 상관 0과 0.5의 결과가 왜 다른지 설명할 수 있다.
• 우발 예비와 관리 예비를 구분하고 Launchpad의 우발 예비를 숫자로 말할 수 있다.
• 리스크 소진 표에서 노출이 늘어난 주와 그 원인을 찾았다.

마치며...

리스크, 이슈, 불확실성을 나누고, R-02의 대응을 결정 나무로 골랐다(메일 대체 경로, EMV −80만원). 3점 추정으로 일정 위험 분석을 하니 결정론적 완료일 11월 4일에 끝날 확률은 3.9%, 마감 11월 6일까지는 21.7%, P80은 11월 12일이었다. 대응 B를 넣어도 마감 확률은 34.7%이고, 우발 예비 5~6작업일과 마감 여유 2작업일의 차이는 스폰서가 정할 문제로 남았다. D3에서는 이 결정을 누구에게 언제 어떤 형식으로 요청하고, 결정이 늦어지는 것을 어떻게 드러내는지 다룬다.