cd ~/gh-pm-lab source pm-lab/env.sh
1위험을 이슈로 기록
위험은 아직 일어나지 않았지만 일어나면 목표에 영향을 주는 일이다. 업무와 같은 저장소에 risk 라벨 이슈로 두면 담당자, 대응, 확인일이 업무와 같은 방식으로 관리된다. 확률(Probability)과 영향(Impact)은 1~5의 숫자 필드로 두고, 둘을 곱한 값을 위험 점수로 쓴다.
gh label create "risk" -R "$PM_REPO" --color D93F0B --description "목표를 위협하는 위험"
gh project field-create "$PM_PROJECT" --owner "$PM_OWNER" --name Probability --data-type NUMBER
gh project field-create "$PM_PROJECT" --owner "$PM_OWNER" --name Impact --data-type NUMBER
while IFS='|' read -r title p i response <&3; do
url=$(gh issue create -R "$PM_REPO" --title "$title" --label risk \
--body "대응: $response
담당: PM
다음 확인일: 2026-10-23")
gh project item-add "$PM_PROJECT" --owner "$PM_OWNER" --url "$url" >/dev/null
gh project item-edit "$PM_PROJECT" --owner "$PM_OWNER" --url "$url" --field Probability --value "$p" >/dev/null
gh project item-edit "$PM_PROJECT" --owner "$PM_OWNER" --url "$url" --field Impact --value "$i" >/dev/null
echo "$url"
done 3<<'EOF'
[R-01] 법무 검토로 재신청 정책이 다시 바뀐다|3|4|법무 확인 기한을 10월 23일로 정하고, 저장 로직의 재신청 처리를 설정값으로 분리한다
[R-02] 알림 발송 서비스의 계정 승인이 늦어진다|2|3|승인 전에는 메일 알림으로 대체하는 안을 LP-04 범위에 둔다
[R-03] QA 담당이 11월 첫 주에 다른 프로젝트에 배정된다|3|5|QA 항목표를 10월 28일까지 확정하고, 개발 담당 1명이 교차 검증을 맡는다
EOF
while ... done 3<<'EOF'는 아래 세 줄을 한 줄씩 읽어 같은 명령을 반복한다. |로 나뉜 네 칸이 제목, 확률, 영향, 대응이다.
2위험 점수 순 조회
gh project item-list "$PM_PROJECT" --owner "$PM_OWNER" --limit 100 \
--query 'label:risk is:open' --format json \
--jq '.items | map(. + {score: ((.probability // 0) * (.impact // 0))}) | sort_by(-.score) | .[]
| "\(.score) P\(.probability) × I\(.impact) \(.content.title)"'
15 P3 × I5 [R-03] QA 담당이 11월 첫 주에 다른 프로젝트에 배정된다 12 P3 × I4 [R-01] 법무 검토로 재신청 정책이 다시 바뀐다 6 P2 × I3 [R-02] 알림 발송 서비스의 계정 승인이 늦어진다
같은 결과를 확률 × 영향 표에 놓으면 다음과 같다. 오른쪽 위로 갈수록 점수가 높다.
| 영향 \ 확률 | 1 | 2 | 3 | 4 | 5 |
|---|---|---|---|---|---|
| 5 | 5 | 10 | R-03 | 20 | 25 |
| 4 | 4 | 8 | R-01 | 16 | 20 |
| 3 | 3 | R-02 | 9 | 12 | 15 |
| 2 | 2 | 4 | 6 | 8 | 10 |
| 1 | 1 | 2 | 3 | 4 | 5 |
R-03은 EVM과 확률 예측 어디에도 드러나지 않는다. 과거 처리량에는 QA 담당이 빠진 주가 없었기 때문이다. 이런 위험이 있으면 실습 15의 예측은 실제보다 낙관적이라는 점도 보고서에 함께 적는다.
3상태 판정 기준
녹색·황색·적색(RAG)은 지표를 결정과 연결하는 약속이다. 기준은 팀이 정하고, 보고서마다 같은 기준을 쓴다. 아래는 이 과정의 예시 기준이다.
| 영역 | 녹색 | 황색 | 적색 | 10월 21일 판정 |
|---|---|---|---|---|
| 일정 | SPI(t) 0.95 이상 | 0.85 이상 | 0.85 미만 또는 예상 완료가 마감 뒤 | 적색 SPI(t) 0.62, 11월 19일 |
| 공수 | CPI 0.95 이상 | 0.85 이상 | 0.85 미만 | 적색 CPI 0.76 |
| 범위 | 범위 변경이 모두 기록·결정됨 | 결정 대기 1건 이상 | 목표에 영향을 주는 변경이 미결정 | 녹색 LP-07은 M2로 결정 |
| 위험 | 점수 10 이상 없음 | 점수 10 이상 있음 | 점수 15 이상 있음 | 적색 R-03 점수 15 |
4상태 보고서 작성
키트의 templates/status-report.md를 복사해 실습 13~16의 결과로 채운다. 아래는 10월 21일 기준으로 채운 예다.
cp github-pm-starter-kit/templates/status-report.md pm-lab/status-2026-10-21.md
## 프로젝트 상태 보고: 기준일 2026-10-21 ### 요약 | 영역 | 상태 | 근거 | | - | - | - | | 일정 | 적색 | SPI(t) 0.62, EVM 예상 완료일 11-19, M1 마감 11-06 | | 공수 | 적색 | CPI 0.76, EAC 147h (BAC 112h) | | 범위 | 녹색 | 범위 변경 요청 1건(LP-07), M2로 배정 | | 위험 | 적색 | R-03 점수 15 (QA 담당 배정 변경) | 상태 기준(팀이 정한 값): 일정은 SPI(t) 0.95 이상 녹색, 0.85 이상 황색, 그 아래 적색. ### 일정 - EVM: SPI 0.51, SPI(t) 0.62. 끝낸 일의 양은 계획상 10-16에 끝났어야 할 양이다. 예상 완료일 11-19(목). - 확률 예측: 남은 5건, 50% 11-13, 85% 11-20. 11-06까지 끝낼 확률 46%. - 두 예측이 다른 이유: EVM은 LP-03이 막혔던 4일의 효율이 계속된다고 보고, 확률 예측은 지난 프로젝트의 처리량을 쓴다. R-03이 일어나면 두 예측 모두 낙관적이다. ### 주경로와 여유 - 주경로: LP-01 → LP-03 → LP-04 → LP-05 → LP-06 - 계획상 마감까지 여유 2작업일. 현재 지연 약 3작업일로 여유를 넘었다. ### 상위 위험 | 위험 | 확률 | 영향 | 점수 | 대응 | 담당 | | - | - | - | - | - | - | | R-03 QA 담당 배정 변경 | 3 | 5 | 15 | 항목표 10-28 확정, 교차 검증 | PM | | R-01 재신청 정책 재변경 | 3 | 4 | 12 | 법무 확인 기한 10-23 | PM | ### 결정 요청 - 결정할 것: M1(11-06)을 지키기 위한 조정 - 선택지 1: LP-04 알림을 M2로 미룬다. 남은 업무 4건, 주경로 4작업일 단축. - 선택지 2: 개발 1명을 Sprint 2 첫 주에 추가한다. 추가 공수 1명 × 5일 × 8h = 40h. - 선택지 3: M1을 11-13으로 1주 미룬다. 확률 예측상 50% 시점. - 결정 기한: 2026-10-23(금) 주간 회의
선택지마다 앞의 실습에서 계산한 숫자를 붙인다. 선택지 1의 “주경로 4작업일 단축”은 LP-04를 빼면 LP-05가 LP-03 완료 직후(10월 23일)에 시작해 전체 18작업일이 14작업일이 되는 계산이다. 선택지 1을 고르면 실습 15의 계산기에서 남은 업무를 4건으로 바꿔 확률이 어떻게 바뀌는지도 보고서에 덧붙인다.
5게시
상태 보고는 M1 전체를 묶은 상위 이슈(실습 13의 LP-EPIC)에 댓글로 올린다. 매주 같은 이슈에 쌓이므로 이전 주와 비교하기 쉽다.
gh issue comment "$PM_EPIC_URL" --body-file pm-lab/status-2026-10-21.md gh issue view "$PM_EPIC_URL" --comments --web
주간 운영 순서
1~3회차의 도구를 한 주의 순서로 놓으면 다음과 같다.
| 요일 | 할 일 | 도구 |
|---|---|---|
| 월 | 일정이 바뀌었으면 주경로를 다시 계산하고 Start date·Target date를 갱신 | cpm.sh |
| 수 | 주간 사전 리포트를 운영 이슈에 게시 | weekly-digest.sh |
| 목 | 주간 회의: 리포트와 상태 보고의 결정 요청만 다룬다 | 운영 이슈의 결정 기록 |
| 금 | Actual 입력 후 EVM, 흐름 지표, 확률 예측, 위험 갱신, 상태 보고 게시 | evm-report.sh, flow-metrics.sh, forecast.sh |
risk라벨 이슈 3개가 Project에 있고 Probability, Impact 값이 있다.- 위험 점수 순 조회 결과의 첫 줄이 R-03이다.
- 네 영역의 상태를 판정 기준에 따라 정했다.
- 결정 요청에 선택지 세 개와 각각의 숫자 근거를 적었다.
- 상위 이슈에 상태 보고 댓글이 있다.
막히면
| 증상 | 확인과 해결 |
|---|---|
| 점수가 모두 0 | Probability, Impact 값이 비어 있다. Project 표에서 확인하고 item-edit를 다시 실행한다. |
| 위험 이슈가 조회되지 않음 | Project에 추가하지 않았다. gh project item-add를 실행한다. |
PM_EPIC_URL이 비어 있음 | 실습 13에서 저장한 값이다. gh issue list -R "$PM_REPO" --label kind:epic으로 주소를 찾는다. |
마치며...
3회차에서 Launchpad의 GitHub 기록에 Estimate, Actual, Start date 세 필드를 더해 주경로, 획득가치, 흐름 지표, 완료 확률을 계산했고, 위험 등록부와 함께 결정 요청이 있는 상태 보고서로 정리했다. 1회차의 업무 구조와 2회차의 기록 습관이 있었기 때문에 각 계산이 명령 한 줄로 끝났다. 4회차에서는 같은 기록을 위키, 브랜치, 토론으로 넓히고, 이벤트 로그로 업무가 실제로 흐른 과정을 분석한다.