1Orbit 팀과 분석 의뢰
Orbit은 교육용으로 만든 가상 팀이다. 기록은 정해진 규칙과 난수로 만든 합성 데이터이며, 실제 팀의 기록이 아니다. 규칙은 공개하지 않으며, 2단계의 분석으로 찾아낸다.
| 항목 | 내용 |
|---|---|
| 사람 | PM 1명(pm-oh), 개발 6명(dev-a~dev-f), QA 1명(qa-jung) |
| 업무 | 매주 업무 이슈 10건을 만든다. 영역 라벨은 area:engineering, area:design, area:product, area:qa 네 가지다 |
| 일하는 방식 | 1단계와 같다. 업무 이슈마다 PR을 만들고, 리뷰 승인 뒤 병합하며, 닫는 키워드로 업무를 닫는다. QA 업무는 PR 없이 이슈의 테스트 항목표로 완료한다. 막히면 blocked 라벨을 붙이고, 작업 중에 정책이 바뀌면 PM이 결정 기록 댓글을 남긴다 |
| 기록 기간 | 업무 생성 2026-03-03 ~ 기록 추출 2026-09-04(금) 18:00 |
| 작업 시작 시각 | 평일 18시에 Project 스냅숏을 저장하고, In Progress로 처음 보인 스냅숏 시각을 작업 시작으로 쓴다 (실습 18, 20의 방식) |
5월 마지막 주 회고에서 “PR이 리뷰를 오래 기다린다”, “작업 중에 정책이 바뀐 업무가 QA에서 다시 열린다”는 의견이 나왔다. 팀은 6월 1일부터 두 가지 규칙을 함께 시작했다.
- 리뷰 당번: 평일마다 개발자 한 명이 돌아가며 그날 만든 PR의 첫 리뷰를 맡는다. 이전에는 PR 작성자가 리뷰어를 골랐다.
- 정책 변경 업무의 완료 조건 갱신: 결정 기록이 남은 업무는 그날 안에 완료 조건과 테스트 항목을 고친다.
분석 시점은 2026-09-07(월)이다. 팀장이 PM에게 다음 세 가지를 물었다. 2단계의 모든 실습은 이 질문에 답하기 위한 것이다.
| 번호 | 질문 | 답의 형태 |
|---|---|---|
| Q1 | 6월에 시작한 리뷰 당번은 효과가 있었는가 | 전후 비교 숫자와, 그 차이를 리뷰 당번 때문이라고 말할 수 있는 범위 |
| Q2 | 지금 업무가 가장 오래 기다리는 곳은 어디이고, 왜 기다리는가 | 단계별 대기 시간, 근거가 있는 원인 가설 |
| Q3 | 다음 분기에 무엇을 바꾸면 처리 시간이 얼마나 줄어드는가 | 개선안 2~3개, 개선안마다 어림 효과와 확인 방법 |
26개월 기록을 한 화면에 놓기
점 도표(dotted chart)는 사례(업무) 하나를 가로줄 하나로, 사건 하나를 점 하나로 찍는 그림이다. 분석 도구 대부분이 로그를 처음 열 때 보여 준다. 사례는 작업 시작 순서로 위에서 아래로 놓였다. 가로축을 “작업 시작부터 지난 날”로 바꾸면 모든 업무의 작업 시작이 한 세로선에 맞춰지고, 줄의 길이가 처리 시간이 된다.
그림에서 바로 읽히는 사실이 세 가지 있다.
- 토요일과 일요일의 세로 띠 안에는 점이 없다. Orbit 팀은 주말에 기록을 남기지 않는다. 그래서 2단계는 시간을 달력 시간과 업무 시간(평일 09~18시) 두 가지로 잰다.
- 점의 띠가 왼쪽 위에서 오른쪽 아래로 고르게 내려간다. 주마다 비슷한 수의 업무가 시작되었다는 뜻이다.
- “작업 시작부터 지난 날”로 바꾸고 “강조”를 “변경 요청 · 막힘 · 다시 열림”으로 고르면, 주황 점이 있는 줄이 대체로 길다. 이 관찰을 숫자로 확인하는 것이 2단계의 분석이다.
3분석 절차: PM²
프로세스 마이닝 프로젝트의 진행 순서로는 판 에크(M. L. van Eck) 등이 2015년 CAiSE 학회에서 발표한 PM²(Process Mining Project Methodology)를 쓴다. 여섯 단계이며, 4·5단계는 답이 나올 때까지 여러 번 오간다.
| PM² 단계 | 하는 일 | Orbit에서 | 실습 |
|---|---|---|---|
| 1 계획 (planning) | 질문, 범위, 사례의 정의를 정한다 | Q1~Q3, 사례 = 업무 이슈 하나 | 이 페이지 |
| 2 추출 (extraction) | 시스템의 기록을 이벤트 로그로 뽑는다 | event-log.sh 결과 (Orbit은 미리 만든 파일) | 22 |
| 3 데이터 처리 (data processing) | 품질을 점검하고, 고치고, 분석할 범위를 거른다 | log-check.sh, --clean | 22 |
| 4 마이닝과 분석 (mining & analysis) | 발견, 적합성 검사, 시간 분석 | process-map.sh, PM4Py, bottleneck.sh | 23~26 |
| 5 평가 (evaluation) | 결과를 해석하고 원인 가설을 세워 확인한다 | compare.sh, 인사이트 양식 | 27 |
| 6 개선과 지원 (process improvement & support) | 개선안을 정하고, 적용 뒤 효과를 잰다 | whatif.sh, 개선안 양식, 정기 분석 워크플로 | 28, 29 |
41단계의 기록 규칙이 활동이 된다
이벤트 로그의 활동 12종은 모두 1단계에서 만든 기록 규칙에서 나온다. 규칙이 지켜지지 않은 업무는 해당 활동이 로그에 빠진다.
| 활동 | GitHub 기록 | 1단계 규칙 |
|---|---|---|
| 업무 생성 | 업무 이슈의 생성 시각 | 업무는 kind:task 이슈로 만든다 (실습 3, 5) |
| 작업 시작 | Project 스냅숏에서 Status가 처음 In Progress인 날 | 시작하면 Status를 바꾼다 (실습 7), 스냅숏을 쌓는다 (실습 18) |
| 첫 커밋, PR 생성, 변경 요청, 리뷰 승인, PR 병합 | 업무를 닫는 PR의 커밋, 리뷰, 병합 | PR 본문에 닫는 키워드를 쓴다 (실습 9) |
| 막힘, 막힘 해소 | blocked 라벨을 붙인 시각과 뗀 시각 | 막히면 라벨과 이유를 남긴다 (실습 8) |
| 결정 기록 | “결정 기록” 양식의 이슈 댓글 | 회의 결정은 양식 댓글로 남긴다 (실습 10) |
| 업무 완료, 업무 닫힘, 다시 열림 | 이슈를 닫은 시각과 이유, 다시 연 시각 | 완료 조건을 확인하고 닫는다 (실습 12) |
5도구와 결과물
| 도구 | 실행 환경 | 쓰는 곳 |
|---|---|---|
키트 스크립트 (log-check.sh, process-map.sh, bottleneck.sh, compare.sh, whatif.sh) | bash와 jq. GitHub에 접속하지 않고 CSV만 읽는다 | 모든 실습. GitHub Actions에서도 같은 명령이 돈다 |
| PM4Py 2.7.23.8 | Python. 내 컴퓨터, 또는 교안의 웹 실습실(브라우저 안에서 도는 Python인 Pyodide) | 실습 24, 26, 27. 모델 발견, 정렬, 4-eyes 검사 |
| 교안의 화면 도구 | 브라우저 | 점 도표, 프로세스 지도, 단계별 대기 비교, 개선 효과 어림 |
| 결과물 | 파일 | 실습 |
|---|---|---|
| 정리한 이벤트 로그 | pm-lab/orbit-event-log-clean.csv | 22 |
| 프로세스 지도 보고 | pm-lab/orbit-process-map.md | 23 |
| 병목 분석 (기간별) | pm-lab/bottleneck-a.md, pm-lab/bottleneck-b.md | 25 |
| 팀 절차 규칙 | pm-lab/process-rules.tsv | 26 |
| 분석 보고서 | pm-lab/process-analysis-report.md (양식: templates/process-analysis-report.md) | 27~29 |
| 개선안 | 개선안 이슈 (양식: templates/improvement-proposal.md) | 28 |
| 정기 분석 워크플로 | .github/workflows/process-report.yml | 29 |
로그의 resource 열에는 아이디가 있다. 2단계의 분석 단위는 단계, 연결, 규칙이며, 사람별 숫자는 일이 한쪽에 몰려 줄이 생기는지를 볼 때만 쓴다. bottleneck.sh는 기본으로 아이디를 “리뷰어 1, 2, …”로 바꿔 출력한다. 팀에 분석 결과를 공유하기 전에 이 원칙을 먼저 알린다.
- Q1~Q3이 각각 어떤 형태의 답을 요구하는지 설명할 수 있다.
- 점 도표에서 주말 띠, 6월 1일 선, 길게 늘어진 줄을 찾았다.
- PM²의 여섯 단계가 실습 22~29의 어디에 해당하는지 확인했다.
- 활동 12종이 각각 어느 1단계 기록 규칙에서 나오는지 확인했다.
마치며...
2단계의 질문은 업무 하나가 아니라 업무 수백 건의 흐름에 관한 것이다. 같은 질문이라도 사례를 무엇으로 정하고 시간을 어떻게 재는지에 따라 답이 달라지므로, 분석은 계획에서 정한 정의를 끝까지 지킨다. 다음 실습에서는 Orbit 로그를 받아 사례, 활동, 시각의 정의를 확인하고 품질 문제를 찾아 고친다.