과정이 다루는 운영 흐름
한 업무는 아래 순서로 기록을 남긴다. 1회차는 1~3단계의 구조를, 2회차는 4~7단계의 운영을 만들고, 3회차는 이 기록으로 PM 방법론의 지표를 계산한다. 4회차는 같은 기록을 위키, 브랜치, 토론, 이벤트 로그로 넓혀 업무가 실제로 흐른 과정을 분석한다. 2단계(5·6회차)는 업무 수백 건의 이벤트 로그로 흐름 전체의 병목과 개선안을 다룬다.
- 출시 목표마일스톤 M1, M2
- 업무완료 조건이 있는 이슈
- Project 보기백로그, 스프린트, 로드맵
- 개발 결과PR, 리뷰, 커밋
- 사전 리포트회의 전날 조회 결과
- 회의 결정운영 이슈의 결정 기록
- 업무 갱신범위 변경, 이월, 종료
수료 후 할 수 있는 일
- 출시 목표를 마일스톤으로 정의하고, 수행 기간을 스프린트(Iteration)로 분리한다.
- 업무마다 담당자, 완료 조건, 우선순위, 출시 목표를 지정한다.
- 같은 이슈를 백로그 표, 스프린트 보드, 출시 로드맵에서 확인한다.
- PR과 커밋을 읽어 업무별 진행 상태, 리뷰 대기, 연결되지 않은 작업을 회의 전에 파악한다.
- 주간 사전 리포트를 만들어 회의 안건을 결정이 필요한 항목으로 좁힌다.
- 막힘과 의존성을 기록하고 회의의 결정 사항을 실행할 업무로 바꾼다.
- 스프린트 시작 범위와 종료 결과를 비교하고, 미완료 업무를 근거와 함께 이월한다.
- 업무 목록 파일과 스크립트로 다음 프로젝트의 초기 설정을 반복한다.
- 선행 관계로 주경로를 계산하고, 획득가치관리(EVM)로 일정·공수 지표와 예상 완료일을 구한다.
- 과거 처리량으로 완료 날짜의 확률을 계산하고, 위험 등록부와 함께 상태 보고서를 쓴다.
- 결정 기록과 상태 보고를 위키로 모으고, 기간 안의 토론과 리뷰를 한 문서로 정리한다.
- Project 스냅숏을 PM 데이터 브랜치에 쌓고, 선후행 관계마다 계획과 실제의 리드·래그를 잰다.
- GitHub 기록으로 이벤트 로그를 만들어 프로세스 지도, 변형, 대기 구간, 절차 위반을 찾는다.
2단계를 마치면 다음을 할 수 있다.
- 이벤트 로그의 사례, 활동, 시각을 정의하고, 품질 문제를 찾아 정리한 로그를 만든다.
- 점 도표, 프로세스 지도, 변형, PM4Py 모델로 업무가 실제로 흐른 길을 그리고, 적합도와 정밀도로 모델을 평가한다.
- 단계마다 업무 시간으로 대기를 재서 병목을 찾고, 규칙과 정렬로 합의한 절차와 실제를 비교한다.
- 기간, 영역, 활동 유무로 묶음을 나눠 비교하고, 관찰과 가설을 나눈 인사이트를 적는다.
- 개선안의 효과를 어림해 순서를 정하고, 적용 전에 확인 계획을 세우고, 분석을 매주 자동으로 돌린다.
기록이 지표가 되는 과정 미리 보기
아래는 3회차에서 다루는 화면이다. Launchpad Sprint 1의 열흘 동안 Project 보드의 카드가 움직이는 동안, 같은 기록으로 계산한 계획가치(PV), 획득가치(EV), 실제 투입(AC)이 함께 그려진다. 화면이 보이면 자동으로 재생된다.
과정 구성
각 회차는 180분이다. 오른쪽 숫자는 이 브라우저에 저장된 완료 확인 개수다.
수업 전
설치, 로그인, 권한, 작업 폴더를 준비한다. 수업 시작 전에 끝낸다.
- 30분수업 전 준비
1단계 · GitHub로 하는 프로젝트 관리
1회차 · 업무 구조 만들기
출시 목표, 분류 체계, 업무, Project, 스프린트 보기를 만든다.
- 0–15분도입 · 관리 구조 설계
- 15–35분실습 1 · 환경과 저장소
- 35–55분실습 2 · 마일스톤과 라벨
- 55–80분실습 3 · 업무 하나 작성하기
- 80–90분휴식
- 90–115분실습 4 · Project와 관리 필드
- 115–140분실습 5 · 백로그 일괄 등록
- 140–180분실습 6 · 스프린트와 보기, 1회차 점검
2회차 · 진행 읽기와 회의 운영
상태를 조회하고, PR과 커밋을 읽고, 사전 리포트와 회의 기록으로 스프린트를 운영한다.
- 0–35분실습 7 · 상태 변경과 PM 조회
- 35–55분실습 8 · 막힘과 의존성
- 55–85분실습 9 · PR과 커밋 읽기
- 85–95분휴식
- 95–115분실습 10 · 스프린트 운영 이슈
- 115–140분실습 11 · 주간 사전 리포트
- 140–165분실습 12 · 범위 변경과 종료
- 165–180분종합 실습
3회차 · PM 방법론 적용
WBS, 주경로, EVM, 흐름 지표, 몬테카를로 예측, 위험 등록부를 GitHub 데이터로 계산한다.
- 0–15분도입 · PM 방법론 지도
- 15–55분실습 13 · WBS와 주경로
- 55–105분실습 14 · 획득가치관리(EVM)
- 105–115분휴식
- 115–155분실습 15 · 흐름 지표와 확률 예측
- 155–180분실습 16 · 위험과 상태 보고
4회차 · 기록 확장과 프로세스 마이닝 입문
위키, 브랜치, 토론, Project 스냅숏으로 기록을 넓히고, 이벤트 로그로 리드·래그와 프로세스를 분석한다.
- 0–15분도입 · 기록을 넓히고 과정으로 읽기
- 15–45분실습 17 · 위키로 결정과 보고 모으기
- 45–80분실습 18 · 브랜치와 PM 데이터
- 80–105분실습 19 · 로그 읽기와 논의 정리
- 105–115분휴식
- 115–145분실습 20 · 마일스톤과 리드·래그
- 145–180분실습 21 · 프로세스 마이닝 첫걸음
2단계 · 프로세스 마이닝으로 개발 프로세스 개선
5회차 · 이벤트 로그와 병목
가상 팀 Orbit의 6개월 기록을 이벤트 로그로 정리하고, 흐름을 그리고, 단계별 대기로 병목을 찾는다.
- 0–20분도입 · 2단계 안내와 분석 계획
- 20–60분실습 22 · 이벤트 로그 설계와 품질 점검
- 60–100분실습 23 · 프로세스 발견: 지도와 변형
- 100–110분휴식
- 110–145분실습 24 · PM4Py로 모델 발견과 평가
- 145–180분실습 25 · 병목 찾기
6회차 · 인사이트와 개선
합의한 절차와 비교하고, 비교로 원인을 좁혀 인사이트를 적고, 개선안을 어림하고, 확인과 정기 분석을 설계한다.
- 0–40분실습 26 · 적합성 검사
- 40–80분실습 27 · 인사이트 도출
- 80–90분휴식
- 90–130분실습 28 · 개선안과 효과 어림
- 130–180분실습 29 · 개선 확인과 정기 분석, 발표
심화와 참고
수업 뒤 팀에 도입할 때 읽는다.
- 선택재사용과 팀 도입
- 선택확장성: 저장소와 팀이 늘어날 때
- 자료실습 키트
- 자료PM 질문별 명령
- 자료문제 해결
심화 과정: 트랙 A~D
Level 1(1·2단계)을 마친 뒤에는 화면 맨 위 메뉴에서 심화 트랙을 고른다. 트랙마다 모듈 4개이고, 모듈 하나가 180분 수업 한 번이다. 트랙은 서로 독립적이며, 각 트랙 안내 페이지에 필요한 Level 1 실습이 적혀 있다.
| 트랙 | 답하는 질문 | 모듈 |
|---|---|---|
| A · 측정과 판단 | 무엇을 재고, 숫자의 변동이 신호인지 어떻게 판단하고, 변경의 효과를 어떻게 판정하는가 | 측정 체계 설계, 통계적 공정 관리, 추정·예측·보정, 개선 효과 판정 |
| B · GitHub로 하는 통제 | 기준선, 승인, 접근, 추적성을 GitHub 설정으로 강제하고 증적을 보일 수 있는가 | 기준선과 변경 통제, 규칙 세트·승인·접근, 추적성과 감사 증적, 통제 점검 자동화 |
| C · 프로세스 마이닝 심화 | 객체 중심 로그, 시뮬레이션, 예측으로 흐름을 얼마나 더 정확히 설명하고 바꿀 수 있는가 | 객체 중심 이벤트 데이터, 발견과 적합성 심화, 대기열·자원·시뮬레이션, 예측 모니터링 |
| D · 프로젝트 관리 본류 | 표준, 불확실성, 이해관계자, 거버넌스를 도구와 무관하게 어떻게 다루는가 | 표준과 방법론 맞춤, 불확실성과 리스크, 이해관계자·소통·의사결정, 팀·거버넌스·가치 |
1단계 사례: Launchpad 사전신청
가상 서비스 Launchpad의 사전신청 기능을 만든다. 방문자는 랜딩 페이지에서 서비스 설명을 읽고 이메일로 신청하며, 운영자는 신청 결과를 알림으로 확인한다. 결제, 회원 로그인, 관리자 화면은 첫 베타 범위에서 제외한다.
| 구분 | 기간 또는 마감 | 목표 |
|---|---|---|
| M1 비공개 베타 | 2026-11-06(금) | 신청부터 운영 확인까지 검증 |
| M2 공개 런칭 | 2026-11-20(금) | 공개 안내와 운영 준비 완료 |
| Sprint 1 | 2026-10-12(월) ~ 10-23(금) | 정책, 화면, 신청의 최소 흐름 검증 |
| Sprint 2 | 2026-10-26(월) ~ 11-06(금) | 운영 알림, QA, 베타 준비 |
| Sprint 3 (4회차 시나리오) | 2026-11-09(월) ~ 11-20(금) | QA 마무리, 베타 초대, M2 준비 |
날짜는 교육용 예시다. 수업일에 맞춰 바꿔도 실습 절차는 같다. 실습에서는 모든 역할을 본인이 맡고 본인을 담당자로 지정한다.
2단계 사례: Orbit 팀의 6개월
2단계는 업무 6건으로는 답할 수 없는 흐름의 질문을 다루므로 사례가 많은 로그가 필요하다. 가상 팀 Orbit(PM 1명, 개발 6명, QA 1명)의 2026년 3~9월 기록(업무 260건, 사건 1,988건)을 키트의 합성 데이터로 제공한다. 이 팀은 6월 1일에 리뷰 당번과 정책 변경 업무의 완료 조건 갱신 규칙을 시작했고, 분석 시점(2026-09-07)에 팀장이 “리뷰 당번은 효과가 있었는가, 지금 어디서 기다리는가, 다음에 무엇을 바꿀 것인가”를 묻는다. 자세한 내용은 2단계 안내에 있다.
| 역할 | 팀 도입 시 맡는 일 |
|---|---|
| PM | 출시 목표, 우선순위, 범위 결정, 회의 기록 |
| 실행 담당자 | 진행 상태와 검증 근거 갱신, PR 작성 |
| 검수자 | 완료 조건 충족 여부 확인, PR 리뷰 |
교안 읽는 법
| 표시 | 뜻 |
|---|---|
| 터미널 | 그대로 입력하는 명령이다. 오른쪽 위 복사 버튼으로 복사한다. #으로 시작하는 줄은 설명이며 실행해도 아무 일도 하지 않는다. |
| 예상 출력 | 명령을 실행했을 때 보이는 화면의 예다. 로그인 이름, 번호, 날짜는 실습자마다 다르다. |
| 파일 | 파일에 저장되는 내용이다. |
| 완료 확인 | 다음 단계로 넘어가기 전에 확인할 항목이다. 체크 상태는 이 브라우저에만 저장된다. |
| 막히면 | 자주 나오는 오류와 해결 방법이다. 펼쳐서 읽는다. |
기준 버전과 범위
명령 예시는 GitHub.com과 gh 2.101.0의 도움말을 기준으로 작성했다. 아래 기능은 버전에 따라 동작 여부가 다르다. GitHub Enterprise Server(GHES)는 버전별로 지원 범위가 다르다.
| 기능 | 최소 gh 버전 | 사용하는 실습 |
|---|---|---|
Project 항목 조회 필터 item-list --query | 2.89.0에서 확인 | 실습 6, 7, 10, 12 |
이슈 의존성 issue edit --add-blocked-by, 상위 이슈 --parent, 유형 --type | 2.94.0 | 실습 8, 심화 |
필드 이름으로 Project 값 수정 item-edit --field --value --url | 2.97.0 | 실습 5, 7, 12 |
추가 열 표시 item-list --field | 2.101.0에서 확인 | 실습 6, 7 |
토론 명령 gh discussion (미리 보기 기능) | 2.101.0에서 확인 | 실습 19 |
2026-09-30에 나온 2.102.0은 보안 수정 4건을 포함한다. 수업 전 준비에서는 설치 가능한 최신 버전을 설치하고, 2.97.0 이상인지 확인한다.
이 교안은 기존 오프라인 교안(3시간, 실습 10개)을 두 단계 6회차 구성으로 넓히고, PR·커밋 읽기, 주간 사전 리포트, PM 방법론 적용, 기록 확장, 프로세스 마이닝으로 하는 개발 프로세스 분석과 개선 실습을 추가한 개정판이다.