표준과 방법론 맞춤

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

1표준, 지침, 방법론, 프레임워크

PM이 참고하는 문서는 성격이 다르다. 표준과 지침은 무엇을 관리해야 하는지 말하고 방법은 고르게 둔다. 방법론은 역할, 산출물, 절차를 정해 준다. 프레임워크는 최소한의 규칙만 정하고 나머지는 팀이 채운다.

PMBOK 가이드 7판과 8판

PRINCE2 7판

예외에 의한 관리는 단계마다 허용 범위(tolerance)를 정해 두고, 예측이 그 범위를 넘을 때만 윗선(프로젝트 보드)이 개입하는 방식이다. 4단계에서 Launchpad에 적용한다.

애자일과 흐름

• 스크럼 가이드(2020): 책임은 제품 책임자(Product Owner), 스크럼 마스터, 개발자다. 이벤트는 스프린트, 스프린트 계획, 일일 스크럼, 스프린트 리뷰, 스프린트 회고다. 산출물인 제품 백로그, 스프린트 백로그, 증분(Increment)에는 각각 제품 목표, 스프린트 목표, 완료 정의(Definition of Done)라는 약속이 붙는다. 가이드의 끝맺음은 스크럼의 일부만 쓰는 것은 가능하지만 그 결과는 스크럼이 아니라고 적는다.
• 칸반 가이드: 작업 흐름을 정의하고 보이게 하며, 진행 중 업무(WIP)를 통제하고, 흐름을 개선한다. 흐름 측정은 진행 중 업무 수, 처리량, 업무 나이(work item age), 사이클 타임 네 가지다. 실습 15에서 이 가운데 처리량과 진행 중 업무 수를 GitHub 기록으로 쟀다.
• SAFe 6.0: 여러 팀을 애자일 릴리스 트레인으로 묶고 8~12주의 계획 구간마다 함께 계획한다. 우선순위는 WSJF로 정한다. 6.0에서 Program Increment를 Planning Interval로 바꿔 불렀다.
• Disciplined Agile: 하나의 정답 대신 팀의 상황에 맞는 생애주기와 실무를 고르게 하는 선택지 모음이다.

2생애주기 고르기

고를 때 보는 요인은 요구사항의 안정성, 바꾸는 비용, 인도 방식(한 번에 내야 하는가), 규제와 계약, 팀의 경험과 위치, 이해관계자가 피드백을 줄 수 있는 빈도다. 아래 네 범위에 맞는 생애주기를 고르자.

1. 개인정보 동의 문구와 보관 정책. 법무 승인이 있어야 공개할 수 있고, 정해지면 잘 바뀌지 않는다.
2. 랜딩 페이지의 안내 문구와 화면. 마케팅과 베타 사용자의 반응을 보고 고친다.
3. 알림 발송 업체의 계정 신청과 계약. 업체의 심사 기간이 정해져 있다.
4. 다음 분기의 결제 기능. 금융 규제를 받고, 화면과 흐름은 아직 정해지지 않았다.

3같은 Launchpad, 세 가지 운영 방식

Launchpad를 PMBOK 기반 예측형, PRINCE2, 스크럼으로 각각 운영한다고 하고 비교표를 채운다. 마지막 열은 1단계에서 이미 쓰는 GitHub 기록이다. 모둠마다 표를 먼저 직접 채운 뒤 아래 예와 비교한다.

표를 채우면 GitHub 기록 열이 세 방식 모두에서 쓰인다는 점이 보인다. 마일스톤은 예측형의 일정 약속이자 PRINCE2의 단계 경계이고, Iteration 필드는 스크럼의 스프린트다. 기록 도구는 같고, 달라지는 것은 누가 언제 그 기록을 근거로 결정하는가다.

4같은 날 같은 지표, 세 가지 대응

세 방식의 차이는 문제가 생긴 날 가장 크게 드러난다. 실습 13과 14의 결과를 다시 계산한다. 키트의 예시 파일을 쓰므로 실습 저장소가 없어도 같은 결과가 나온다.

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/evm-report.sh github-pm-starter-kit/samples/evm-input.sample.json \
  --status-date 2026-10-21 | grep -E 'SPI|완료일'

| SPI 일정 성과 지수 | 0.51 | EV ÷ PV | 1보다 작으면 일정 지연 |
| SPI(t) | 0.62 | ES ÷ AT |
| 계획 완료일 | 2026-11-04(수) | 18 작업일 |
| 예상 완료일 | 2026-11-19(목) | 계획 작업일 ÷ SPI(t) = 29 작업일 |

계획 완료일은 11월 4일(18작업일), 10월 21일 기준 예상 완료일은 11월 19일(29작업일)이다. 차이는 29 − 18 = 11작업일이고, 마감(11월 6일, 20작업일)보다는 9작업일 늦다. 세 방식은 이 숫자에 다르게 반응한다.

예측형과 PRINCE2는 기준선이 있으므로 차이를 숫자로 말하고 승인 절차를 탄다. PRINCE2는 허용 범위를 넘는 순간 정기 보고를 기다리지 않는다. 스크럼에는 기준선이 없으므로 “9작업일 늦다”는 문장 대신 “남은 백로그로 보아 11월 6일에는 이 범위까지 낼 수 있다”는 문장이 나온다. 실습 16의 상태 보고는 예측형의 차이 분석과 스크럼의 범위 선택지를 함께 쓴 혼합형이었다.

5맞춤: 무엇을 줄이고 무엇을 더하는가

맞춤(tailoring)은 표준이나 방법론의 요소를 프로젝트에 맞게 가져오고, 줄이고, 더하고, 버리는 일이다. PMBOK 7판은 맞춤을 원칙 하나(상황에 맞춘 맞춤)와 별도 절로 다루고, PRINCE2는 “프로젝트에 맞춘 맞춤”을 원칙으로 둔다. 스크럼은 반대로 규칙을 바꿀 수 없다고 적는다. 그래서 스크럼 이벤트를 줄인 팀은 스크럼을 쓴다고 말하는 대신 스크럼에서 무엇을 가져왔는지 적는다.

맞춤과 생략은 이유가 적혀 있는가로 갈린다. 리스크 등록부를 “작은 프로젝트라서” 버렸다면 생략이고, “업무 6건, 외부 의존 1건이라 주간 회의의 막힘 점검으로 충분하며, 외부 의존이 2건 이상이 되면 다시 둔다”라고 적었다면 맞춤이다. 다시 검토할 조건을 함께 적어야 상황이 바뀌었을 때 맞춤을 고칠 수 있다.

6실습: 팀 맞춤 원칙 쓰기

키트의 양식을 복사해 Launchpad의 팀 맞춤 원칙을 쓴다. 요소별 결정 표의 각 줄에 가져옴, 줄임, 더함, 버림 중 하나와 이유를 적는다. 모둠마다 40분 동안 쓴 뒤 아래 예와 비교한다.

cp github-pm-starter-kit/templates/tailoring.md pm-lab/tailoring.md

다 쓰면 결정이나 이유가 빈 줄이 없는지 확인한다. 아래 명령은 “## 2” 절의 표에서 결정 열(다섯째 칸)이나 이유 열(여섯째 칸)이 빈 줄을 찾는다. 빈 양식에 실행하면 모든 줄이 걸린다.

awk -F'|' '/^## 2/ {s = 1; next} /^## / {s = 0}
  s && /^\|/ && $2 !~ /영역|^ *- *$/ {
    d = $5; r = $6; gsub(/ /, "", d); gsub(/ /, "", r)
    if (d == "" || r == "") { n++; t = $3; gsub(/^ +| +$/, "", t); print "비어 있음: " t }
  }
  END { print "결정이나 이유가 빈 줄: " n + 0 "개" }' github-pm-starter-kit/templates/tailoring.md | tail -n 3

비어 있음: 교훈 기록
비어 있음: 구매와 계약 관리
결정이나 이유가 빈 줄: 17개

채운 예시 파일에 같은 점검을 하고 결정별 개수도 센다. 실습에서는 파일 이름을 pm-lab/tailoring.md로 바꿔 실행한다.

awk -F'|' '/^## 2/ {s = 1; next} /^## / {s = 0}
  s && /^\|/ && $2 !~ /영역|^ *- *$/ {
    d = $5; r = $6; gsub(/ /, "", d); gsub(/ /, "", r)
    if (d == "" || r == "") { n++; t = $3; gsub(/^ +| +$/, "", t); print "비어 있음: " t }
    else c[d]++
  }
  END { print "결정이나 이유가 빈 줄: " n + 0 "개"
        printf "가져옴 %d, 줄임 %d, 더함 %d, 버림 %d\n", c["가져옴"], c["줄임"], c["더함"], c["버림"] }' github-pm-starter-kit/samples/d-tailoring-launchpad.md

결정이나 이유가 빈 줄: 0개
가져옴 8, 줄임 6, 더함 2, 버림 1

예시 파일의 앞부분과 요소별 결정 표는 다음과 같다. 전체는 키트의 samples/d-tailoring-launchpad.md에 있다.

# 팀 맞춤 원칙: Launchpad 사전신청

- 작성: 2026-10-09, PM(gildong) / 검토: 스폰서(사업본부장), dev-kim, qa-park
- 참고한 표준과 방법론: PMBOK 가이드 8판, PRINCE2 7판, 스크럼 가이드 2020, 칸반 가이드
- 생애주기: 혼합형
- 생애주기를 고른 이유: 출시일(M1 11-06, M2 11-20)은 마케팅 일정에 묶여 바꾸기 어렵고, 신청 화면과 정책은 베타 피드백으로 바뀐다. 마일스톤은 예측형으로, 그 안의 업무는 2주 반복으로 운영한다.

완성한 원칙은 실습 17의 위키에 페이지로 올린다. 파일 이름이 페이지 제목이 된다.

cp pm-lab/tailoring.md pm-lab/wiki/팀-맞춤-원칙.md
git -C pm-lab/wiki add 팀-맞춤-원칙.md
git -C pm-lab/wiki commit -m "팀 맞춤 원칙 추가"
git -C pm-lab/wiki push

위키를 쓸 수 없는 비공개 저장소라면 실습 9처럼 저장소의 docs/tailoring.md로 두고 PR로 올린다. 맞춤 원칙은 운영 규칙이므로 PR 리뷰를 거쳐 바꾸는 편이 이력을 남기기 쉽다.

7발표와 토론

모둠마다 결정 개수(가져옴, 줄임, 더함, 버림)와 가장 논쟁이 된 줄 하나를 5분 동안 발표한다. 이어서 아래 세 질문을 토론한다.

1. 일일 점검을 화·목 15분으로 줄인 Launchpad 팀은 “스크럼을 쓴다”고 말할 수 있는가.
2. PRINCE2의 예외 보고를 더하면 스크럼의 제품 책임자 역할과 부딪히는가.
3. Launchpad의 팀이 12명, 저장소가 3개로 늘면 어느 줄의 결정이 바뀌는가.

• PMBOK 7판과 8판의 원칙 수, 성과 영역 수의 차이를 말하고, 8판 구성의 출처가 무엇인지 말할 수 있다.
• PRINCE2 7판의 7원칙, 7실무, 7프로세스와 사람 요소를 구분할 수 있다.
• 네 범위의 생애주기를 고르고 Launchpad 전체가 혼합형인 이유를 설명할 수 있다.
• 세 방식의 비교표를 채우고 각 요소를 GitHub 기록과 짝지었다.
• 10월 21일의 지표(예상 완료일 11월 19일)에 세 방식이 각각 어떻게 반응하는지 설명할 수 있다.
• pm-lab/tailoring.md를 쓰고 점검 명령에서 “결정이나 이유가 빈 줄: 0개”를 확인했다.
• 맞춤 원칙을 위키나 저장소 docs/에 올렸다.

마치며...

PMBOK 7·8판, ISO 21502, PRINCE2 7판, 스크럼, 칸반, SAFe의 구성을 비교했고, 같은 10월 21일의 지표(계획 대비 11작업일 지연)에 예측형은 변경 요청, PRINCE2는 예외 보고, 스크럼은 백로그 재정렬로 반응한다는 것을 표로 정리했다. Launchpad의 맞춤 원칙은 17개 요소 중 8개를 가져오고 6개를 줄이고 2개를 더하고 1개를 버린 혼합형이며, 줄마다 이유와 GitHub 기록이 있다. D2에서는 이 원칙에 넣은 리스크 등록부와 정량 일정 위험 분석을 실제로 해서, 마감까지 남은 위험을 숫자로 말한다.