실습 25 병목 찾기 · PM을 위한 GitHub CLI

1단계와 시간 재는 법

bottleneck.sh는 업무 하나의 흐름을 여덟 단계로 나눈다. 단계는 “바로 다음 사건”이 아니라 정해 둔 두 사건 사이의 구간이다.

단계	구간	성격
백로그 대기	업무 생성 → 작업 시작	계획상 기다린 시간. PM이 순서를 정한 결과다
개발	작업 시작 → 첫 PR 생성	일하는 시간. 막힘이 있으면 그 안에 겹친다
첫 리뷰 대기	PR 생성 → 같은 PR의 첫 리뷰(승인이나 변경 요청)	기다리는 시간
수정과 재리뷰	변경 요청 → 같은 PR의 다음 리뷰	고치는 시간과 다시 기다리는 시간
병합 대기	리뷰 승인 → 같은 PR의 병합	기다리는 시간
막힘	막힘 → 다음 막힘 해소	기다리는 시간
재작업	다시 열림 → 다음 업무 완료	다시 하는 일
PR 없는 업무	작업 시작 → 업무 완료	QA처럼 PR 없이 끝나는 업무의 처리 시간

시간은 두 가지로 잰다. 달력 시간은 밤과 주말을 포함하고, 업무 시간은 평일 09~18시와 겹치는 시간만 센다. 금요일 17:00에 만든 PR이 월요일 10:00에 첫 리뷰를 받았다면 달력 시간은 65시간(2.7일), 업무 시간은 금요일 1시간과 월요일 1시간을 더한 2시간이다. 공휴일은 계산에 넣지 않는다.

2리뷰 당번 전 기간 (3~5월)

작업 시작이 2026-05-31 이전인 업무만 고른다. --roles에는 아이디와 역할을 적은 키트의 roles.tsv를 준다.

bash github-pm-starter-kit/bottleneck.sh pm-lab/orbit-event-log-clean.csv --to 2026-05-31 \
  --roles github-pm-starter-kit/roles.tsv > pm-lab/bottleneck-a.md
cat pm-lab/bottleneck-a.md

보고서를 위에서부터 읽는다.

합계가 큰 단계: 백로그 대기 3,484h와 개발 3,147h가 가장 크다. 둘 다 계획과 작업 시간이라 줄일 대상으로 먼저 고르지 않는다. 그다음이 첫 리뷰 대기 960h다. PR 123건이 첫 리뷰를 평균 7.8업무시간 기다렸다.
중앙값과 85%: 첫 리뷰 대기의 중앙값은 6.8h, 85%는 14.4h다. PR의 15%는 하루 반 이상(업무 시간 기준) 첫 리뷰를 기다렸다.
요일별: 금요일에 만든 PR은 달력 시간 중앙값이 2.9일이지만 업무 시간은 6.9h로 다른 요일과 비슷하다. 금요일 PR이 늦게 리뷰되는 것이 아니라 주말이 끼었을 뿐이다.
리뷰 집중도: 첫 리뷰 123건 중 64건(52%)을 한 사람(리뷰어 1)이 맡았고, 그 사람의 리뷰는 중앙값 11.7h를 기다렸다. 나머지 다섯 명은 2~3.4h다.
재작업: 결정 기록이 있는 업무 18건 중 78%에 변경 요청이, 22%에 다시 열림이 있었다. 결정 기록이 없는 업무 98건은 23%와 3%다.
역할 사이의 넘김: PM에서 개발로 넘어가는 연결(140회)이 중앙값 15.5h로 가장 길다. 업무 생성(PM) → 작업 시작(개발)과 막힘 해소(PM) → 첫 커밋(개발)이 여기에 들어 있다. 개발에서 QA로 넘어가는 7회(업무 완료 → 다시 열림)는 20.5h다.

병목을 고르는 세 가지 기준

골드랫(E. Goldratt)의 제약 이론(Theory of Constraints, 1984)은 흐름 전체의 속도가 가장 느린 한 곳에서 정해진다고 본다. 그곳이 아닌 단계를 빠르게 해도 업무는 그 앞에서 다시 기다린다. 이벤트 로그에서는 세 가지를 함께 보고 병목을 고른다. (1) 기다린 시간의 합이 크다. (2) 85%가 중앙값보다 훨씬 커서 오래 기다리는 업무가 자주 나온다. (3) 기다림이 한 사람이나 한 역할에 몰려 줄이 생긴다. 3~5월의 첫 리뷰 대기는 세 가지를 모두 만족한다.

3리뷰 당번 뒤 기간 (6~9월)

bash github-pm-starter-kit/bottleneck.sh pm-lab/orbit-event-log-clean.csv --from 2026-06-01 \
  --roles github-pm-starter-kit/roles.tsv > pm-lab/bottleneck-b.md

같은 보고서의 리뷰 집중도 표다.

첫 리뷰 124건을 누가 맡았는지 센다. 사람을 평가하려는 표가 아니라, 리뷰가 한쪽에 몰려 줄이 생기는지 보는 표다.

| 리뷰어 | 첫 리뷰 수 | 비율 | 대기 업무 시간 중앙값 |
| - | - | - | - |
| 리뷰어 1 | 28 | 23% | 1.7h |
| 리뷰어 2 | 24 | 19% | 1.8h |
| 리뷰어 3 | 23 | 19% | 1.8h |
| 리뷰어 4 | 19 | 15% | 1.6h |
| 리뷰어 5 | 15 | 12% | 1.6h |
| 리뷰어 6 | 15 | 12% | 1.8h |

첫 리뷰 대기의 중앙값은 1.8h, 85%는 3.4h로 줄었고, 가장 많이 맡은 사람의 비율은 23%다. 두 기간을 단계마다 나란히 놓으면 아래와 같다. “값”을 바꿔 업무 시간 85%, 달력 시간, 합계로도 비교한다.

4지금 남은 병목

6~9월에서 계획과 작업 시간(백로그 대기, 개발)을 빼고 기다린 시간을 보면 다음과 같다.

단계	건수	업무 시간 중앙값	85%	합계	읽는 법
첫 리뷰 대기	124	1.8h	3.4h	249h	건수가 많아 합계는 크지만, 한 건의 대기는 짧고 고르다
막힘	18	11.5h	21.2h	242h	한 건의 대기가 가장 길다. 3~5월(10.5h)과 차이가 없다
수정과 재리뷰	28	8.8h	10.5h	230h	고치는 시간이 들어 있다. 건수는 47건에서 28건으로 줄었다
재작업	6	11.5h	15.2h	70h	건수가 적지만, 완료한 업무를 다시 하는 시간이다

막힘은 누가 풀었는가. 이벤트 로그의 막힘 해소 사건을 수행자별로 센다.

awk -F, 'NR > 1 && $2 == "막힘 해소" { n[$4]++ } END { for (k in n) print n[k], k }' pm-lab/orbit-event-log-clean.csv | sort -rn

32 pm-oh
4 qa-jung

막힘 36건 중 32건을 PM이 풀었다. QA 업무의 막힘 4건만 QA가 직접 풀었다. 막힘은 대부분 PM의 결정을 기다린 시간이며, 리뷰 당번은 이 대기를 바꾸지 않았다. Q2의 1차 답은 “한 건당 가장 오래 기다리는 곳은 PM의 결정을 기다리는 막힘이다”이다.

리뷰 집중도 표를 공유할 때

bottleneck.sh는 기본으로 아이디를 “리뷰어 1, 2, …”로 바꿔 쓴다. 3~5월의 리뷰어 1이 누구인지는 --show-names로 확인할 수 있지만, 공유하는 보고서에는 넣지 않는다. 그 사람에게 리뷰가 몰린 것은 PR 작성자들이 리뷰어를 고르는 방식의 결과이고, 고칠 대상도 그 방식이다.

막히면

증상	확인과 해결
`오류: 조건에 맞는 사례가 없다`	`--from`, `--to`는 작업 시작 날짜로 거른다. 날짜 형식이 `YYYY-MM-DD`인지, 로그의 기간 안인지 확인한다
역할 사이의 넘김 표가 없다	`--roles`를 주지 않았다. 역할 파일은 한 줄에 “아이디(탭)역할”이다. 공백으로 구분하면 읽지 못한다
넘김 표에 “기타”가 많다	역할 파일에 없는 아이디가 있다. `cut -d, -f4 pm-lab/orbit-event-log-clean.csv \| sort -u`로 아이디 목록을 보고 역할 파일에 더한다

여덟 단계 중 계획·작업 시간과 기다리는 시간을 구분했다.
금요일 PR의 달력 시간과 업무 시간이 다른 이유를 설명할 수 있다.
3~5월의 첫 리뷰 대기가 병목의 세 가지 기준을 만족하는지 확인했다.
단계별 대기 비교 화면에서 가장 많이 줄어든 단계와 그대로인 단계를 찾았다.
6~9월에 한 건당 가장 오래 기다린 단계와 그 대기를 푼 사람을 확인했다.

마치며...

5회차에서는 이벤트 로그를 점검해 정리하고, 업무가 지난 길을 지도와 변형과 모델로 그리고, 단계마다 기다린 업무 시간을 재서 병목을 찾았다. 3~5월의 병목은 한 사람에게 몰린 첫 리뷰 대기였고, 6~9월에는 그 대기가 줄어든 대신 PM의 결정을 기다리는 막힘이 한 건당 가장 긴 대기로 남았다. 다음 회차에서는 팀이 합의한 절차와 실제 기록을 비교하는 적합성 검사부터 시작한다.