실습 27 인사이트 도출 · PM을 위한 GitHub CLI

cp github-pm-starter-kit/templates/process-analysis-report.md pm-lab/process-analysis-report.md

1비교의 세 축

옵션	나누는 기준	답하는 질문
`--split 날짜`	작업 시작이 그 날짜 전인가 후인가	바꾼 뒤에 무엇이 달라졌는가
`--by area`	area 열의 값	업무 종류마다 흐름이 다른가
`--has 활동`	그 활동이 있는 사례와 없는 사례	그 일이 있었던 업무는 무엇이 다른가

세 축 모두 같은 지표 10개를 계산한다. 처리 시간은 작업 시작 신호부터 마지막 업무 완료까지이며, 업무 시간과 달력 시간 두 가지로 적는다.

2Q1: 6월 1일 전후

bash github-pm-starter-kit/compare.sh pm-lab/orbit-event-log-clean.csv --split 2026-06-01

숫자는 모두 좋아졌다. 이 차이를 리뷰 당번의 효과라고 말하기 전에 세 가지를 확인한다.

확인할 것	방법	Orbit 결과
리뷰 당번이 바꾸려던 것이 바뀌었는가	첫 리뷰 대기, 리뷰 집중도, 첫 리뷰 규칙 위반	6.8h → 1.8h, 52% → 23%, 23건 → 0건 (실습 25, 26)
처리 시간 감소 중 얼마가 첫 리뷰 대기로 설명되는가	3~5월 업무의 첫 리뷰 대기가 6월 이후 수준(85%가 3.4h)이었다고 가정하고 다시 계산한다 `whatif.sh --to 2026-05-31 --review-cap 3.4`	36.8h → 32.7h. 감소 9.1h 중 4.1h다
업무 종류가 달라서 생긴 차이는 아닌가	기간별 파일(실습 26)마다 `--by area`	아래 표. PR이 있는 세 영역 모두 줄었다

영역	3~5월 사례	6~9월 사례	처리 시간 중앙값 3~5월	6~9월	첫 리뷰 대기 3~5월	6~9월
engineering	65	72	44.2h	37.8h	5.2h	2.2h
design	26	20	35.4h	23.6h	11.1h	1.3h
product	25	26	27h	19.6h	8.6h	1.4h
qa	10	13	14.8h	6.2h	-	-

QA 업무는 PR이 없어 리뷰 당번과 관계가 없는데도 처리 시간 중앙값이 14.8h에서 6.2h로 줄었다. 사례가 10건과 13건이면 중앙값이 우연만으로 이만큼 움직인다는 뜻이다. 개선과 무관한 묶음을 함께 비교하면 숫자의 흔들림 폭을 가늠할 수 있다. 이런 묶음을 대조군(negative control)이라고 한다.

Q1의 답은 다음과 같이 적는다. “리뷰 당번 뒤 첫 리뷰 대기는 중앙값 6.8h에서 1.8h로 줄었고, 한 사람에게 몰리던 첫 리뷰가 고르게 나뉘었으며, 다음 작업일까지 첫 리뷰 규칙 위반이 없어졌다. 처리 시간 중앙값 감소 9.1h 중 4.1h는 첫 리뷰 대기 감소로 설명된다. 나머지는 변경 요청 비율 감소(32% → 22%)와 관련이 있으나, 같은 날 시작한 완료 조건 갱신 규칙의 효과와 구분할 수 없다.”

3결정 기록이 있는 업무

bash github-pm-starter-kit/compare.sh pm-lab/orbit-event-log-clean.csv --has "결정 기록"

결정 기록이 있는 업무 43건은 처리 시간 중앙값이 11.2h 길고, 변경 요청 비율이 51%(없는 업무 21%), 다시 열린 비율이 19%(2%)다. 이 차이가 “결정 때문”인지 확인하려면 다른 설명을 하나씩 지운다.

다른 설명	확인	결과
결정 기록은 engineering 업무에 많고, engineering은 원래 오래 걸린다	engineering 업무만 남겨 비교한다 `awk -F, 'NR == 1 \|\| $6 == "engineering"' 로그 > pm-lab/orbit-eng.csv`	engineering 안에서도 처리 시간 +11.8h, 변경 요청 50% 대 23%, 다시 열림 27% 대 4%
한 기간에만 생긴 일이다	기간별 파일마다 `--has "결정 기록"`	두 기간 모두 다시 열림 비율이 높다(22% 대 3%, 16% 대 2%)
사례가 적어 우연히 생긴 차이다	두 비율의 차이를 피셔의 정확 검정(Fisher's exact test)으로 본다	6~9월 다시 열림 4/25 대 2/106은 p ≈ 0.012, 변경 요청 8/25 대 18/93은 p ≈ 0.18

python3 -c "from scipy.stats import fisher_exact; print(fisher_exact([[4, 21], [2, 104]])[1])"

6~9월에는 결정 기록이 있는 업무의 변경 요청 비율(32%)이 없는 업무(19%)와 우연으로 설명할 수 있는 정도까지 가까워졌다. 3~5월에는 78% 대 23%였다. 완료 조건 갱신 규칙이 리뷰 단계의 차이는 줄였지만, 다시 열림은 여전히 결정 기록이 있는 업무에 몰린다. 기록을 하나 더 보면, 결정 기록 43건은 모두 첫 커밋 뒤에 나왔다(실습 23 직접 이어짐 관계 “첫 커밋 → 결정 기록” 43회, 중앙값 16.9시간).

4영역별 차이

bash github-pm-starter-kit/compare.sh pm-lab/orbit-event-log-clean.csv --by area

engineering 업무가 가장 길고(41.1h), 막힘(18%)과 다시 열림(8%)도 가장 잦다. 첫 리뷰 대기는 영역마다 2.8~3.2h로 비슷하다. 개선안을 고를 때 engineering 업무에 효과가 큰 안이 전체 숫자를 가장 많이 움직인다. engineering이 사례의 53%이기 때문이다.

5PM4Py로 같은 비교

셀 [7]은 작업 시작 신호로 사례를 나누고, 기간마다 업무 시간 기준 직접 이어짐 그래프를 다시 계산한다. “PR 생성 → 리뷰 승인”처럼 연결 단위의 숫자라 compare.sh의 단계 단위 숫자와 정의가 다르다. 두 도구의 숫자가 같은 방향인지 확인한다.

6인사이트 다섯 줄

인사이트는 관찰, 근거, 영향, 가설, 확인 방법 다섯 줄로 적는다. 관찰과 가설을 한 문장에 섞지 않는 것이 이 양식의 목적이다. Orbit 분석의 인사이트 세 개를 보고서 6절에 적는다.

	인사이트 1: 리뷰 당번	인사이트 2: 막힘	인사이트 3: 결정 시점
관찰	6월 이후 첫 리뷰 대기 중앙값이 6.8h에서 1.8h로 줄었다	막힘 한 건의 대기가 중앙값 11.5h, 85% 21.2h로, 6월 이후 한 건당 가장 긴 대기다	결정 기록이 있는 업무는 다시 열린 비율이 16~22%로, 없는 업무(2~3%)보다 높다
근거	`compare.sh --split`, PR 123건/124건, 첫 리뷰 규칙 위반 23 → 0, 리뷰 집중 52% → 23%	`bottleneck.sh`, 막힘 18건(6~9월), 36건 중 32건을 PM이 해소	`compare.sh --has`, 두 기간과 engineering 안에서 같은 방향, 6~9월 p ≈ 0.012
영향	처리 시간 중앙값 감소 9.1h 중 4.1h	6~9월 막힘 대기 합계 242h. 막힌 업무는 18건이라 중앙값보다 처리 시간 85%를 늘린다	다시 열린 업무는 재작업 중앙값 11.5h, QA에서 발견될 때까지 2.7일 동안 완료로 보인다
가설	리뷰를 한 사람에게 몰리지 않게 나눠 대기 줄이 사라졌다	막힘은 PM의 결정을 기다리고, PM이 막힘 라벨을 확인하는 주기가 정해져 있지 않다	결정이 개발을 시작한 뒤에 나와, 이미 만든 결과물과 QA 기준이 어긋난다
확인 방법	4주마다 `compare.sh --split 2026-06-01`로 첫 리뷰 대기가 3.4h(85%) 안에 머무는지 본다	막힘 18건의 라벨 댓글에서 “무엇을 기다렸는가”를 분류하고, PM이 처음 반응한 시각을 기록한다	다시 열린 결정 기록 업무 8건의 결정 댓글과 QA 댓글을 읽어, 결정이 바꾼 항목과 결함이 같은지 확인한다

상관과 원인

비교가 보여 주는 것은 “함께 나타난다”까지다. 결정 기록과 다시 열림이 함께 나타나는 이유로는 결정이 늦게 나와서일 수도, 어려운 업무일수록 결정이 필요해서일 수도 있다. 영역을 같게 맞추고, 기간을 나누고, 사례 수를 함께 적는 것은 다른 설명을 하나씩 지우는 작업이다. 끝까지 남은 설명이 가설이 되고, 가설은 개선을 적용한 뒤의 숫자로 다시 확인한다.

막히면

증상	확인과 해결
`오류: 인자가 너무 많다: 기록`	활동 이름의 공백 때문이다. `--has "결정 기록"`처럼 큰따옴표로 감싼다
차이 열이 없다	묶음이 두 개일 때만 차이 열을 쓴다. `--by area`는 영역 수만큼 열이 생긴다
`ModuleNotFoundError: No module named 'scipy'`	`python3 -m pip install scipy`. 또는 웹 실습실의 셀 하나에 같은 코드를 넣어 실행한다

--split 결과를 읽고, 처리 시간 감소 중 첫 리뷰 대기로 설명되는 부분을 계산했다.
QA 업무를 대조군으로 써서 사례 수가 적을 때의 흔들림을 확인했다.
결정 기록과 다시 열림의 관계를 영역과 기간을 바꿔 다시 확인했다.
Q1의 답을 “설명되는 부분”과 “구분할 수 없는 부분”으로 나눠 적었다.
분석 보고서 6절에 인사이트 세 개를 다섯 줄 양식으로 적었다.

마치며...

인사이트는 숫자 하나가 아니라 관찰과 가설을 나눠 적은 문장이며, 비교 묶음을 바꿔도 같은 방향이 유지되는지 확인한 만큼 믿을 수 있다. Orbit에서는 리뷰 당번의 효과 중 첫 리뷰 대기로 설명되는 부분과 그렇지 않은 부분을 나눴고, 막힘과 결정 시점이 다음 개선 대상으로 남았다. 다음 실습에서는 이 두 대상에 대한 개선안을 만들고 효과를 어림한다.