팀, 거버넌스, 가치

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

1팀: 심리적 안전과 인지 부하

D3의 소통 계획은 나쁜 소식을 1작업일 안에 알리라고 정했다. 이 규칙은 팀원이 PM에게 먼저 말할 때만 작동한다. 에드먼드슨(A. Edmondson)은 1999년 Administrative Science Quarterly 논문에서 팀 심리적 안전(team psychological safety)을 “팀이 대인 관계의 위험을 감수해도 안전하다는, 팀원들이 함께 가진 믿음”으로 정의했다. 제조 회사의 팀 51개를 조사해, 심리적 안전이 높은 팀일수록 질문하고 도움을 청하고 실수를 말하는 학습 행동이 많고, 그 행동이 팀 성과와 이어진다는 것을 보였다.

에드먼드슨은 심리적 안전을 팀 수준의 값으로 다뤘다. 그래서 잴 때도 팀 단위로 모은다. 회고에서 쓸 익명 설문 문항을 세 개 만들자. 에드먼드슨의 7문항 척도를 참고해 아래처럼 쓸 수 있다.

• 이 팀에서 실수를 하면 그것이 나에게 불리하게 쓰인다. (거꾸로 채점)
• 이 팀에서는 일정이 위험하다는 말을 먼저 꺼낼 수 있다.
• 도움을 청하면 팀원들이 귀찮아한다. (거꾸로 채점)

응답자가 다섯 명보다 적으면 결과를 공개하지 않는다. 개인을 알아볼 수 있기 때문이다. Launchpad(4명)는 Orbit과 합쳐 모으거나 설문 대신 회고의 질문으로 쓴다.

팀 토폴로지와 인지 부하

스켈턴(M. Skelton)과 파이스(M. Pais)는 Team Topologies(2019)에서 팀 유형 네 가지와 상호작용 방식 세 가지를 정리하고, 팀이 감당할 수 있는 인지 부하(cognitive load)에 맞춰 팀의 책임 범위를 정하자고 했다. 인지 부하는 일 자체의 어려움(내재적), 일과 무관한 절차와 도구의 부담(외재적), 새 지식을 익히는 부담(본유적)으로 나눈다. 외재적 부하를 줄이는 것이 플랫폼 팀과 지원 팀의 역할이다.

상호작용 방식은 협업(collaboration), 서비스로 제공(X-as-a-Service), 촉진(facilitating)이다. 아래 조직에서 팀 유형과 상호작용 방식을 정하자.

1. Launchpad 팀(4명): 사전신청 흐름 전체를 맡는다.
2. 알림 플랫폼 팀(3명): 사내 알림 발송 API를 운영한다. Launchpad의 LP-04가 이 API를 쓴다면 외부 업체 계정(R-02)이 필요 없다.
3. 개인정보 지원 담당(2명): 석 달 동안 각 팀에 개인정보 보관·삭제 방법을 가르치고 빠진다.
4. Orbit 팀(8명): 제품 하나를 맡고, 6월부터 리뷰 당번을 직접 돌린다. 당번 순서를 매주 손으로 정한다.

2용량 계획과 WIP 한도

용량 계획은 일할 수 있는 시간과 해야 할 일의 양을 맞춰 보는 일이다. Launchpad Sprint 2(10월 26일~11월 6일, 10작업일)로 계산해 보자. 하루 집중 시간은 6시간, 예상하지 못한 일에 용량의 20%를 남긴다고 하자.

LP-02와 LP-03의 남은 시간은 실습 14의 체크박스 비율로 어림했다(24 × 2/4 = 12, 32 × 3/4 = 24). 시간으로는 개발 56h가 86.4h 안에 들고, QA 16h도 30h 안에 든다. 그런데 D2의 일정 위험 분석은 마감 확률이 21.7%라고 했다. 원인은 LP-05가 LP-04를 기다리는 순서이고, 시간은 남는다. 시간 합계로 하는 용량 계획은 순서의 제약을 보지 못하므로 일정망 계산과 함께 쓴다.

진행 중 업무 한도

실습 15의 리틀의 법칙(평균 진행 중 업무 수 = 처리량 × 평균 리드 타임)을 Orbit의 6개월 기록으로 확인하자. 아래 명령은 업무마다 작업 시작과 마지막 업무 완료 시각을 찾고, 평일 18시마다 진행 중인 업무를 센다.

jq -R -s -r -L github-pm-starter-kit/lib '
include "workdays";
split("\n")[1:] | map(select(length > 0) | split(","))
| group_by(.[0])
| map({s: ([.[] | select(.[1] == "작업 시작") | .[2] | isoepoch] | min),
       e: ([.[] | select(.[1] == "업무 완료") | .[2] | isoepoch] | max)})
| map(select(.s != null and .e != null))
| ("2026-03-09" | epochday) as $a | ("2026-08-28" | epochday) as $b
| ([range($a; $b + 1) | select(isworkday) | . * 86400 + 9 * 3600] as $t
   | [$t[] as $x | [.[] | select(.s <= $x and .e > $x)] | length]) as $wip
| ([.[] | select(.e >= $a * 86400 and .e < ($b + 1) * 86400)] | length) as $done
| (map(.e - .s) | add / length / 86400) as $w
| ($done / (($b - $a + 1) / 7)) as $thr
| "끝난 업무 \(length)건, 작업 시작부터 완료까지 평균 \($w * 10 | round / 10)일",
  "처리량: \($done)건 ÷ \(($b - $a + 1) / 7 * 10 | round / 10)주 = 주 \($thr * 10 | round / 10)건",
  "리틀의 법칙: 주 \($thr * 10 | round / 10)건 × \($w * 10 | round / 10)일 ÷ 7일 = 진행 중 \($thr * $w / 7 * 10 | round / 10)건",
  "평일 18시에 센 진행 중 업무: 평균 \($wip | add / length * 10 | round / 10)건, 최소 \($wip | min)건, 최대 \($wip | max)건"
' github-pm-starter-kit/samples/orbit-event-log-clean.csv

끝난 업무 257건, 작업 시작부터 완료까지 평균 5.9일
처리량: 249건 ÷ 24.7주 = 주 10.1건
리틀의 법칙: 주 10.1건 × 5.9일 ÷ 7일 = 진행 중 8.5건
평일 18시에 센 진행 중 업무: 평균 8.8건, 최소 5건, 최대 13건

리틀의 법칙으로 계산한 8.5건과 평일마다 센 평균 8.8건이 가깝다. Orbit은 개발 6명과 QA 1명이므로 사람마다 1건을 조금 넘게 동시에 들고 있다. 진행 중 업무를 7건으로 제한하고 처리량이 주 10.1건으로 유지된다면 평균 리드 타임은 7 ÷ (10.1 ÷ 7) = 4.85일이 되어 5.9일보다 하루 정도 줄어든다. 처리량이 유지된다는 가정은 확인해야 할 가설이다. 한도를 둔 뒤 실습 29처럼 기간을 나눠 다시 잰다.

3거버넌스: PMO와 단계 관문

거버넌스는 누가 무엇을 결정하고 어떤 기준으로 감독하는지를 정한 틀이다. 프로젝트 관리 조직(PMO)은 통제의 정도에 따라 세 가지로 나눈다(PMBOK 6판의 구분).

쿠퍼(R. G. Cooper)는 1990년 Business Horizons에 단계 관문(Stage-Gate) 방식을 발표했다. 개발을 단계로 나누고 단계 사이의 관문에서 진행(go), 중단(kill), 보류(hold), 다시 하기(recycle)를 정한다. 관문 기준은 반드시 충족해야 하는 기준(must-meet, 예·아니오)과 점수로 판단하는 기준(should-meet)으로 나눈다. D1의 맞춤 원칙은 마일스톤 마감 3작업일 전에 스폰서가 진행 여부를 승인하는 관문을 두었다. M2 관문(11월 17일)의 기준을 앞 모듈의 결과로 쓰자.

4지연 비용과 WSJF

라이너트슨(D. G. Reinertsen)은 The Principles of Product Development Flow(2009)에서 일의 순서를 지연 비용(cost of delay)으로 정하자고 했다. 지연 비용은 그 일이 한 주 늦어질 때 잃는 가치다. 한 팀이 한 번에 하나씩 일한다면 지연 비용을 기간으로 나눈 값(Cost of Delay Divided by Duration, CD3)이 큰 순서가 전체 지연 비용을 가장 작게 만든다. SAFe는 같은 생각을 상대 척도로 바꾼 WSJF(Weighted Shortest Job First)를 쓴다. 지연 비용을 사용자·사업 가치, 시간 긴급성, 리스크 감소·기회 활성화의 세 점수의 합으로 매기고, 작업 크기 점수로 나눈다.

키트의 samples/d-portfolio.tsv는 다음 분기 후보 여섯 건이다. 세 점수와 크기는 1, 2, 3, 5, 8, 13, 20의 상대 척도이고, 주당 지연 비용(만원)과 기간(주)은 금액 추정이다. wsjf.sh로 두 방식의 순위와 순서별 총 지연 비용을 계산한다.

bash github-pm-starter-kit/wsjf.sh github-pm-starter-kit/samples/d-portfolio.tsv

WSJF와 CD3 모두 P-05가 1위지만 2위부터 갈린다. WSJF는 P-02(유입 경로 기록)를 2위에 두고, CD3는 4위에 둔다. P-02는 크기 점수가 2로 작아 WSJF가 커졌지만, 주당 지연 비용은 150만원으로 P-01(900만원)이나 P-03(1,200만원)보다 작다. 반대로 P-03(결제 기능)은 크기 점수 20 때문에 WSJF 5위지만 CD3로는 3위다. 총 지연 비용은 CD3 순서가 19,590만원으로 가장 작고, WSJF 순서는 그보다 2,670만원 크다. 이 차이는 상대 점수와 금액 추정의 비율이 서로 달라서 생긴다. P-02의 지연 비용 점수(16)는 P-01(24)의 3분의 2인데, 주당 지연 비용(150만원)은 P-01(900만원)의 6분의 1이다. 두 순서가 다르면 어느 추정이 틀렸는지 담당자와 확인한다.

마감이 있는 일

P-05(개인정보 보관 기간 자동 삭제)를 다시 추정했더니 1주 대신 3주가 걸린다고 하자. 입력 파일의 기간만 바꿔 다시 계산한다.

awk -F'\t' 'BEGIN { OFS = "\t" } $1 == "P-05" { $8 = 3 } { print }' github-pm-starter-kit/samples/d-portfolio.tsv > pm-lab/portfolio-b.tsv
bash github-pm-starter-kit/wsjf.sh pm-lab/portfolio-b.tsv

CD3로 P-05는 4위로 내려가고, CD3 순서(P-01 → P-03 → P-02 → P-05)에서 P-05는 13주차에 끝난다. 그런데 P-05는 규정 때문에 분기 시작 6주 안에 갖춰야 하는 일이라고 하자. 주당 지연 비용 400만원은 평균값일 뿐이고, 실제로는 6주가 지나면 과태료가 한꺼번에 생긴다. 시간 긴급성 점수 20이 이 사정을 담아 WSJF로는 1위다. 이런 일은 순서 계산에서 따로 떼어 마감 안에 끝나도록 먼저 자리를 잡고, 나머지를 CD3로 정한다. P-01(3주) 다음에 P-05(3주)를 두면 6주차에 끝난다.

for k in P-01 P-05 P-03 P-02 P-06 P-04; do awk -F'\t' -v k="$k" '$1 == k' pm-lab/portfolio-b.tsv; done > pm-lab/portfolio-c.tsv
bash github-pm-starter-kit/wsjf.sh pm-lab/portfolio-c.tsv | grep '입력 순서'

| 입력 순서 | P-01 → P-05 → P-03 → P-02 → P-06 → P-04 | 23,670 | +1,250 |

wsjf.sh는 입력 파일의 줄 순서로 “입력 순서” 줄을 계산하므로, 원하는 순서로 줄을 다시 쓴 파일을 넣으면 그 순서의 총 지연 비용이 나온다. 마감을 지키는 순서는 CD3 순서(22,420만원)보다 1,250만원 크지만 과태료를 피한다. 계산식: P-01 900 × 3 + P-05 400 × 6 + P-03 1,200 × 12 + P-02 150 × 13 + P-06 80 × 15 + P-04 60 × 17 = 2,700 + 2,400 + 14,400 + 1,950 + 1,200 + 1,020 = 23,670만원.

여러 저장소를 모은 조직 Project

후보가 여러 저장소의 이슈라면 조직 소유 Project 하나에 모으고 숫자 필드로 점수를 둔다. 필드 이름의 첫 글자만 소문자로 바뀐 것이 JSON 키다(gh 2.101.0 소스의 camelCase 함수). “Cost of delay”는 cost of delay, “Job size”는 job size가 된다.

gh project field-create "$ORG_PROJECT" --owner "$PM_ORG" --name "Cost of delay" --data-type NUMBER
gh project field-create "$ORG_PROJECT" --owner "$PM_ORG" --name "Job size" --data-type NUMBER
gh project item-list "$ORG_PROJECT" --owner "$PM_ORG" --limit 200 --format json \
  --jq '.items | map(select(.["cost of delay"] and .["job size"])
        | . + {wsjf: (.["cost of delay"] / .["job size"])})
        | sort_by(-.wsjf) | .[]
        | "\(.wsjf * 100 | round / 100)  \(.content.repository)  \(.content.title)"'

$PM_ORG와 $ORG_PROJECT는 조직 이름과 조직 Project 번호다. 조직 Project를 만들 권한이 없으면 사용자 Project로 같은 명령을 연습한다. 이 명령은 GitHub에서 읽기만 한다.

5OKR과 효익 실현

OKR(Objectives and Key Results)은 목표(O) 하나에 그 달성을 재는 핵심 결과(KR) 몇 개를 붙인다. 인텔의 그로브(A. Grove)가 쓰던 방식을 도어(J. Doerr)가 Measure What Matters(2018)로 알렸다. Launchpad의 다음 분기 OKR을 예로 들면 다음과 같다.

• O: 공개 런칭으로 정식 출시의 초대 대상을 확보한다.
• KR1: 12월 18일까지 사전신청 누적 1,000건.
• KR2: 신청 완료율을 베타 2주 값보다 5%p 높인다.
• KR3: 신청 관련 문의를 주 10건 이하로 유지한다.

OKR의 KR은 출시가 끝난 뒤에야 판정할 수 있다. 프로젝트가 산출물을 내고 닫힌 뒤에도 효익(benefit)을 확인할 책임자와 날짜가 있어야 하는 이유다. 효익 실현 관리(benefits realization management)는 산출물 → 역량 → 성과 → 효익을 잇는 지도를 만들고, 효익마다 지표, 기준값, 목표값, 측정 담당, 확인일을 정한다. PMI는 Benefits Realization Management: A Practice Guide(2019)로 이를 정리했다. 효익 책임자는 사업 쪽 사람이다. Launchpad에서는 마케팅 담당이 맡고 스폰서가 최종 승인한다. PM은 효익을 잴 수 있게 만드는 데까지 책임진다.

cp github-pm-starter-kit/templates/benefits-tracking.md pm-lab/benefits-m2.md

| ID | 지표 | 종류 | 운영적 정의 | 기준값(언제) | 목표값(언제까지) | 데이터 출처 | 측정 주기 | 측정 담당 |
| - | - | - | - | - | - | - | - | - |
| B-01 | 사전신청 수 | 후행 | 동의를 마치고 저장된 신청 건수. 같은 이메일은 1건 | 0건(11-20) | 누적 1,000건(12-18) | 신청 데이터 집계 | 매주 월 | 마케팅 |
| B-02 | 신청 완료율 | 선행 | 랜딩 방문자 중 신청 완료 화면에 도달한 비율 | 비공개 베타 2주(11-06~11-19)의 값 | 기준값보다 5%p 높게(12-18) | 웹 분석 도구 | 매주 월 | 마케팅 |
| B-03 | 신청 확인 시간 | 선행 | 신청 저장부터 운영자가 알림을 연 때까지의 중앙값 | 베타 2주의 값 | 4업무시간 이하(12-04) | 운영 알림 기록 | 2주마다 | 개발(dev-kim) |
| B-04 | 신청 관련 문의 | 후행 | 고객지원에 접수된 신청·초대 관련 문의 건수 | 베타 2주의 주 평균 | 주 10건 이하(12-18) | 고객지원 시스템 | 매주 월 | 고객지원 |

채운 예 전체(효익 지도, 부정적 효익, 확인 일정)는 samples/d-benefits-launchpad.md에 있다. B-02와 B-04의 기준값은 M2 전 비공개 베타 2주에 재야 하므로, 3단계 M2 관문의 점수 기준에 “기준값을 쟀다”를 넣었다. 기준값 없이 출시하면 효익을 판정할 수 없다.

효익 확인 이슈는 마일스톤을 닫을 때 만든다. 손으로 만들면 다음과 같다.

gh label create kind:benefit -R "$PM_REPO" --color 0E8A16 --description "출시 뒤 효익 확인"
gh issue create -R "$PM_REPO" --title "[효익 확인] M2 공개 런칭" --label kind:benefit \
  --body-file github-pm-starter-kit/samples/d-benefits-launchpad.md

키트의 templates/workflows/benefits-review.yml은 마일스톤이 닫히는 이벤트(milestone, closed)에 같은 이슈를 자동으로 만든다. 마일스톤 이름은 사용자가 입력한 값이므로 셸 명령에 바로 넣지 않고 환경 변수로 넘긴다.

on:
  milestone:
    types: [closed]
  workflow_dispatch:
    inputs:
      milestone:
        description: 마일스톤 이름
        required: true

permissions:
  contents: read
  issues: write

6가치 흐름과 지속가능성

가치 흐름(value stream)은 요청이 들어와 사용자에게 가치가 닿기까지의 모든 단계다. 가치 흐름에서 자주 보는 값이 흐름 효율(flow efficiency) = 실제로 일한 시간 ÷ 리드 타임이다. 실습 14의 기록으로 계산하면, 10월 21일까지 LP-03은 5작업일(40업무시간) 동안 진행 중이었고 Actual은 10시간이었다. 흐름 효율은 10 ÷ 40 = 25%다. 나머지 30시간에는 정책 결정을 기다린 시간(실습 8의 막힘)과 다른 일을 한 시간이 들어 있다. 처리 시간을 줄이려면 일하는 속도보다 기다리는 시간을 먼저 본다. 2단계(실습 25)의 병목 분석이 이 기다림을 단계별로 잰 것이다. Orbit의 3~5월 기록에서 업무 시간 합계는 백로그 대기 3,484h, 개발 3,147h, 첫 리뷰 대기 960h로, 시작을 기다린 시간이 개발한 시간보다 많았다.

D1에서 본 것처럼 PMBOK 8판은 지속가능성 통합을 원칙으로 두고(교육기관 자료 기준), PRINCE2 7판은 비즈니스 케이스에 지속가능성 목표를 넣는다. 지속가능성은 환경, 사회, 경제의 세 측면에서 프로젝트가 끝난 뒤까지 남는 영향을 본다. Launchpad에서는 다음과 같다.

7윤리: 측정 데이터를 개인 평가에 쓰지 않는 이유

PMI의 Code of Ethics and Professional Conduct는 책임(responsibility), 존중(respect), 공정(fairness), 정직(honesty)의 네 가치를 두고, 가치마다 지향 기준과 의무 기준을 적는다. 이 과정은 Level 1부터 측정 데이터를 개인 평가에 쓰지 않는다고 적어 왔다(실습 14의 Actual, 2단계의 리뷰어 익명화). 근거는 세 가지다.

1. 평가에 쓰이는 지표는 바뀐다. 굿하트(C. Goodhart, 1975)와 캠벨(D. T. Campbell, 1976)은 지표가 결정과 보상에 쓰일수록 그 지표가 재려던 것과 멀어진다고 지적했다. 개발자별 처리량으로 평가하면 업무를 잘게 쪼개고, Actual로 평가하면 Actual을 추정에 맞춰 적는다. 그때부터 실습 14의 CPI와 실습 15의 예측은 의미를 잃는다.
2. 결과는 시스템이 만든다. LP-05의 리드 타임은 QA 담당의 속도보다 LP-02~LP-04의 완료와 D-03 결정에 더 크게 달려 있다. 결정 대기 목록에서 D-01은 3작업일 늦어졌고, 그 지연은 개발자의 숫자에 나타난다. 개인의 숫자는 다른 사람과 결정의 영향을 함께 담는다.
3. 수집할 때 말한 목적과 다르게 쓰면 정직과 존중에 어긋난다. 팀에 “일정 예측에 쓴다”고 말하고 모은 기록을 평가에 쓰면, 정보의 쓰임을 정직하게 알리지 않은 것이고 팀원의 정보를 존중하지 않은 것이다.

세 상황에서 PM의 대응을 정하자.

1. 팀장이 “개발자별 처리량과 Actual 시간을 이번 분기 평가 자료로 달라”고 요청한다.
2. 스폰서가 다음 경영 회의 전에 상태 보고의 일정 영역을 적색에서 황색으로 바꿔 달라고 한다.
3. Orbit의 병목 분석(실습 25)에서 3~5월 첫 리뷰 123건 중 64건(52%)이 한 리뷰어에게 몰렸고, 그 리뷰어의 리뷰는 중앙값 11.7h를 기다렸다. 팀장이 그 사람이 누구인지 묻는다.

• 팀 심리적 안전의 정의와 팀 단위로 재야 하는 이유를 말할 수 있다.
• 네 팀의 팀 토폴로지 유형과 상호작용 방식을 정했다.
• Sprint 2 용량을 계산하고, 시간으로는 들어가도 일정이 위험한 이유를 설명할 수 있다.
• Orbit 기록으로 리틀의 법칙을 확인하고 WIP 한도의 효과를 계산했다.
• M2 관문의 반드시 충족 기준과 점수 기준을 썼다.
• wsjf.sh로 WSJF와 CD3 순서를 비교하고, 총 지연 비용의 차이를 읽었다.
• 마감이 있는 후보를 따로 배치한 순서의 총 지연 비용(23,670만원)을 확인했다.
• M2 효익 추적 계획에 효익 책임자, 기준값, 목표값, 확인일이 있다.
• 측정 데이터를 개인 평가에 쓰지 않는 이유 세 가지를 말할 수 있다.

마치며...

Sprint 2는 시간으로는 개발 56h가 86.4h 안에 들었지만 순서의 제약 때문에 위험했고, Orbit의 기록은 리틀의 법칙(계산 8.5건, 측정 8.8건)대로 움직였다. 다음 분기 후보 여섯 건은 CD3 순서가 총 지연 비용 19,590만원으로 가장 작았고, WSJF 순서는 2,670만원 더 컸다. P-05처럼 마감이 있는 일은 따로 자리를 잡은 뒤 나머지를 정했다. 출시 뒤의 효익은 사업 쪽 책임자와 확인일을 정한 계획과, 마일스톤을 닫을 때 만들어지는 효익 확인 이슈로 남긴다. 측정 데이터는 이 판단에만 쓰고 개인 평가에는 쓰지 않는다. 트랙 D의 네 모듈에서 만든 맞춤 원칙, 리스크 분석, 소통 계획과 결정 요청, 우선순위표와 효익 계획은 모두 Launchpad의 GitHub 기록을 근거로 한다.