실습 29 개선 확인과 정기 분석 · PM을 위한 GitHub CLI

1개선 확인 계획은 적용 전에 정한다

적용한 뒤에 지표를 고르면 좋아진 숫자만 골라 보게 된다. 개선안 이슈에 아래 다섯 가지를 적용 전에 적는다.

항목	정하는 것	개선안 A (막힘 결정 기한)
적용일	규칙이 시작된 날. 결정 기록 댓글로 남긴다	2026-09-14(월)
겨냥한 지표	개선안이 직접 바꾸려는 숫자	막힘 대기 업무 시간 중앙값과 85%
결과 지표	팀이 결국 바라는 숫자	처리 시간 85% (업무 시간)
부작용 지표	개선 때문에 나빠질 수 있는 숫자	막힘이 있었던 사례 비율(라벨을 덜 붙이는지), 다시 열린 비율(결정을 서둘렀는지)
비교 방법과 시점	무엇과 비교하고 언제 판단하는가	작업 시작이 적용 전 8주(7-20 ~ 9-11)인 업무와 적용 후 8주(9-14 ~ 11-06)인 업무. 적용 후 기간 끝에 시작한 업무가 끝나도록 2주 남짓 더 기다린다(실습 22의 기간 끝 효과). 판단일 2026-11-23(월)

판단일에 실행할 명령은 다음과 같다. 적용 전 기간과 후 기간을 같은 길이로 맞추려면 실습 26의 awk로 로그를 먼저 자른다.

bash github-pm-starter-kit/compare.sh pm-lab/event-log-clean.csv --split 2026-09-14
bash github-pm-starter-kit/bottleneck.sh pm-lab/event-log-clean.csv --from 2026-09-14 --to 2026-11-06

한 번에 하나씩, 그리고 대조군

6월 1일처럼 두 규칙을 같은 날 시작하면 각각의 효과를 나눌 수 없다. 개선안 B는 A의 판단일 뒤에 시작한다. 개선과 무관한 묶음(QA 업무처럼 막힘 결정과 관계가 적은 업무)의 숫자를 함께 비교하면 기간 사이의 자연스러운 흔들림을 가늠할 수 있다.

2매주 자동으로 분석하기

1단계 실습 18에서 평일마다 Project 스냅숏을 pm-data 브랜치에 쌓는 워크플로를 만들었다. 같은 브랜치에 매주 월요일 아침 이벤트 로그와 보고서를 쌓는 워크플로를 더한다.

# 매주 월요일 아침 이벤트 로그를 다시 만들고 프로세스 보고서를 pm-data 브랜치에 남긴다 (2단계 실습 29).
#
# 설치:
#   1. 키트의 스크립트를 저장소의 .github/pm-kit/ 폴더에 복사해 PR로 올린다.
#      event-log.sh, log-check.sh, process-map.sh, bottleneck.sh, lib/, process-rules.tsv, roles.tsv
#   2. 이 파일을 .github/workflows/process-report.yml로 함께 올린다.
#   3. pm-data 브랜치와 snapshots 폴더가 있어야 한다 (1단계 실습 18).
# 같은 저장소의 이슈와 PR만 읽으므로 기본 토큰(GITHUB_TOKEN)으로 동작한다.
name: process-report

on:
  schedule:
    # 월요일 00:47 UTC = 09:47 한국 시각
    - cron: "47 0 * * 1"
  workflow_dispatch:

permissions:
  contents: write
  issues: read
  pull-requests: read

concurrency:
  group: process-report
  cancel-in-progress: false

jobs:
  report:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          path: main
      - uses: actions/checkout@v4
        with:
          ref: pm-data
          path: pm-data

      - name: 이벤트 로그와 보고서 만들기
        env:
          GH_TOKEN: ${{ github.token }}
        run: |
          d=$(TZ=Asia/Seoul date +%F)
          kit=main/.github/pm-kit
          mkdir -p pm-data/logs pm-data/reports
          bash "$kit/event-log.sh" "$GITHUB_REPOSITORY" --snapshots pm-data/snapshots > pm-data/logs/event-log.csv
          bash "$kit/log-check.sh" pm-data/logs/event-log.csv --clean > pm-data/logs/event-log-clean.csv
          {
            bash "$kit/log-check.sh" pm-data/logs/event-log.csv
            echo
            bash "$kit/process-map.sh" pm-data/logs/event-log-clean.csv --rules "$kit/process-rules.tsv"
            echo
            bash "$kit/bottleneck.sh" pm-data/logs/event-log-clean.csv --roles "$kit/roles.tsv"
          } > "pm-data/reports/$d.md"

      - name: pm-data 브랜치에 커밋
        working-directory: pm-data
        run: |
          git config user.name "github-actions[bot]"
          git config user.email "41898282+github-actions[bot]@users.noreply.github.com"
          git add logs reports
          if git diff --cached --quiet; then
            echo "바뀐 내용이 없다."
          else
            git commit -m "process report $(TZ=Asia/Seoul date +%F)"
            git push origin pm-data
          fi

실습 저장소에 설치한다. 스크립트를 저장소 안에 두는 이유는 워크플로가 실행될 때 키트가 있는 컴퓨터가 아니라 GitHub의 실행 환경에서 돌기 때문이다.

cd "$PM_REPO_NAME"
git switch main && git pull -q
git switch -c ci/process-report
mkdir -p .github/pm-kit .github/workflows
cp -R ../github-pm-starter-kit/{event-log.sh,log-check.sh,process-map.sh,bottleneck.sh,lib,roles.tsv} .github/pm-kit/
cp ../pm-lab/process-rules.tsv .github/pm-kit/
cp ../github-pm-starter-kit/templates/workflows/process-report.yml .github/workflows/
git add .github
git commit -m "ci: 주간 프로세스 보고 워크플로 추가"
git push -u origin ci/process-report
gh pr create --fill
cd ..

PR을 병합한 뒤 한 번 직접 실행해 확인한다.

gh workflow run process-report.yml -R "$PM_REPO"
gh run list -R "$PM_REPO" --workflow process-report.yml --limit 3
git -C pm-lab/pm-data pull
ls pm-lab/pm-data/reports

roles.tsv는 Orbit과 Launchpad의 아이디로 되어 있다. 실습 저장소의 아이디와 역할로 고친 뒤 올린다. 실습 저장소처럼 사례가 몇 건뿐이면 보고서의 숫자는 형식 확인용이다.

3보고서를 회의로 잇기

주간 보고서는 회의의 안건을 고르는 데 쓴다. 1단계의 주간 사전 리포트(실습 11)가 업무 하나하나의 상태를 다룬다면, 프로세스 보고서는 흐름 전체의 변화를 다룬다. 매주 다음 세 가지만 확인하고, 하나라도 해당하면 회의 안건으로 올린다.

확인	보고서 위치	안건으로 올리는 기준 (Orbit 예)
겨냥한 지표가 목표 안에 있는가	병목 분석의 단계별 대기 표	막힘 대기 중앙값이 4h를 넘는다
새 병목이 생겼는가	“업무 시간 합계가 큰 단계” 줄	백로그·개발이 아닌 단계가 상위 3개에 새로 들어왔다
로그 품질이 나빠졌는가	로그 점검의 “작업 시작이 없는 사례”, “빈 값”	지난주보다 늘었다. 스냅숏 워크플로가 멈췄거나 라벨 규칙이 지켜지지 않는다

4분석 보고서 완성

실습 27에서 복사한 pm-lab/process-analysis-report.md의 여덟 절을 채운다. 숫자는 모두 정리한 로그 기준이다. 아래는 Orbit 보고서의 앞부분과 끝부분 예시다.

# 개발 프로세스 분석 보고서: Orbit, 2026-03 ~ 2026-09

작성: pm-oh · 작성일: 2026-09-07 · 데이터: orbit-event-log-clean.csv, 사례 257건, 작업 시작 2026-03-03 ~ 2026-08-31

## 1. 질문
- Q1 6월에 시작한 리뷰 당번은 효과가 있었는가
- Q2 지금 업무가 가장 오래 기다리는 곳은 어디이고, 왜 기다리는가
- Q3 다음 분기에 무엇을 바꾸면 처리 시간이 얼마나 줄어드는가
- 질문: 팀장 / 결정: 팀장, PM

## 2. 데이터
| 항목 | 값 |
| - | - |
| 사례 정의 | 업무 이슈 하나 (kind:task) |
| 기간 | 작업 시작 기준 2026-03-03 ~ 2026-08-31, 6월 1일 전 126건, 후 131건 |
| 사례 · 사건 | 257건 · 1,975건 |
| 정리 | log-check.sh --clean: 작업 시작 31건 보정, 끝나지 않은 사례 3건 제외 |
| 한계 | 작업 시작은 하루 단위, 회의와 메신저의 결정은 결정 기록 댓글로 남긴 것만 있다, 기간 끝 2주는 짧은 업무만 남는다 |

(3~6절 생략)

## 7. 개선안
| 개선안 | 겨냥한 병목 | 어림 효과 (whatif.sh) | 비용 | 우선순위 |
| - | - | - | - | - |
| A. 막힘 결정 기한 | 막힘 대기 11.5h (85% 21.2h) | 85% 48.8h → 46.4h, 합계 170h | PM 하루 10분 | 1 |
| B. 착수 전 결정 확인 | 결정 기록 업무의 다시 열림 16% | 85% 48.8h → 46.3h 이하, 합계 162h 이하 | 작업 시작 지연 가능 | 2 (A 판단 뒤) |

## 8. 결정 요청과 확인 계획
- 결정 요청: 팀장, 9월 11일 주간 회의까지, 개선안 A의 적용 승인
- 확인: 적용일 2026-09-14, 적용 전후 8주, 막힘 대기 중앙값과 처리 시간 85%, 판단일 2026-11-23
- 정기 분석: 매주 월요일 process-report 워크플로, 안건 기준은 보고서 3단계 표

3~6절은 실습 23(발견), 25(병목), 26(적합성), 27(인사이트)의 결과를 옮긴다. 보고서는 실습 저장소의 위키나 docs/ 폴더에 올리고, 개선안 이슈에서 링크한다.

5발표 (15분)

한 사람(또는 한 조)이 5분 안에 다음 순서로 발표한다. 분석한 모든 숫자를 말하지 않는다. 결정할 사람이 결정에 필요한 숫자만 고른다.

질문 세 개와 데이터의 범위, 한계 (30초)
Q1의 답: 설명되는 부분과 구분할 수 없는 부분 (1분)
Q2의 답: 남은 병목과 근거 (1분)
Q3의 답: 개선안 두 개, 어림 효과, 우선순위 (1분 30초)
결정 요청과 확인 계획 (1분)

듣는 사람은 발표마다 질문 하나를 한다. 예: “어림 효과가 실제와 얼마나 다를 수 있는가”, “부작용 지표는 무엇인가”, “사례가 몇 건인가”.

막히면

증상	확인과 해결
워크플로가 `A branch or tag with the name 'pm-data' could not be found`로 실패한다	pm-data 브랜치가 없다. 1단계 실습 18을 먼저 한다
`Permission denied`로 push가 실패한다	워크플로 파일에 `permissions: contents: write`가 있는지 확인한다. 조직 저장소면 조직 정책이 워크플로의 쓰기 권한을 막는지 저장소 Settings → Actions → General에서 확인한다
보고서에 `오류: 조건에 맞는 사례가 없다`가 있다	끝난 업무가 아직 없다. 실습 저장소에서 업무를 하나 이상 닫은 뒤 다시 실행한다
예약 실행이 정해진 시각보다 늦다	GitHub Actions의 예약 실행은 부하에 따라 늦어질 수 있다. 정각을 피해 47분으로 정한 이유다

개선안 A의 확인 계획 다섯 항목을 개선안 이슈에 적었다.
process-report.yml을 실습 저장소에 설치하고 한 번 실행했다.
pm-data 브랜치의 reports/에 보고서가 생겼다.
주간 보고서에서 안건으로 올리는 기준 세 가지를 정했다.
분석 보고서 여덟 절을 채우고 5분 발표를 했다.

마치며...

2단계에서는 Orbit 팀의 6개월 기록으로 PM²의 여섯 단계를 한 번 돌았다. 로그를 정의하고 정리했고, 지도와 모델로 흐름을 그렸고, 업무 시간으로 병목을 재고, 규칙과 모델로 절차를 검사했고, 비교로 원인을 좁혀 인사이트로 적었고, 어림으로 개선안의 순서를 정하고 확인 계획을 세웠다. 분석의 재료는 1단계에서 만든 기록 규칙이며, 다음 분석 질문은 매주 만드는 보고서에서 고른다.