대기열, 자원, 시뮬레이션

cd ~/gh-pm-lab

이 모듈의 시간은 모두 업무 시간(평일 09~18시)이고, 기간은 2단계와 같이 작업 시작 신호의 날짜로 나눈다(3~5월은 --to 2026-05-31, 6~9월은 --from 2026-06-01).

1대기열의 말

도착이 포아송 과정이고 처리 시간이 지수 분포이며 창구가 c개인 대기열을 M/M/c라고 적는다(켄들 표기). M/M/c에서 기다리는 시간은 얼랑 C 공식(Erlang, 1917)으로 계산한다. 이용률마다 대기 시간 Wq가 처리 시간 S의 몇 배인지 계산해 본다.

창구가 하나일 때 이용률이 0.5면 처리 시간만큼 기다리고, 0.9면 9배, 0.95면 19배를 기다린다. 대기는 1/(1 − ρ)에 비례하므로, 이용률이 같은 폭으로 올라도 이용률이 높을 때 대기가 훨씬 많이 는다. 같은 이용률에서 창구 둘이 줄 하나를 함께 받으면(풀링) 대기는 3분의 1에서 절반 사이로 준다. 리뷰어를 늘리는 정책이 효과가 있으려면 지금의 대기가 이 곡선 위에 있어야 한다. 곧 리뷰어가 바빠서 생긴 대기여야 한다.

2로그에서 대기열 재기

대기열 마이닝(queue mining)은 이벤트 로그에서 대기열의 도착, 대기, 처리를 재고 대기열 이론의 예측을 쓰는 방법이다. 센데로비치(A. Senderovich) 등은 2015년 Information Systems 논문에서 통신사와 금융 기관의 로그로, 사례가 들어올 때의 대기열 길이를 쓰는 예측이 대기열을 무시한 예측보다 대기 시간을 잘 맞힌다는 것을 보였다. queue-mining.py는 PR 첫 리뷰를 대기열로 보고 같은 양을 센다.

• 도착: 작업일 하루에 PR이 평균 1.78개 들어왔다. 하루 PR 수의 분산이 평균의 1.22배, 도착 간격의 변동계수가 1.24로, 포아송 도착(둘 다 1)에서 크게 벗어나지 않는다. 도착률은 업무 시간당 0.198개다.
• 리뷰어 1: 첫 리뷰의 52%를 맡았고 평균 12.1h를 기다리게 했다. 리틀의 법칙으로 L = 0.103 × 12.1 = 1.25, 곧 평균적으로 PR 1.25개가 이 사람의 첫 리뷰를 기다리고 있었다. 나머지 다섯 명은 0.05~0.08개다.
• 묶음 리뷰: 같은 리뷰어의 앞 리뷰와 30업무분 안에 있는 리뷰는 170건 중 9건(5%)이다. 하루 한두 번 몰아서 리뷰하는 습관(묶음 처리, batching)이 있다면 이 비율이 높게 나온다.

3리뷰어가 바빠서 생긴 대기인가

리뷰어 1의 대기를 M/M/1 대기열로 설명해 본다. 관측한 W = 12.1h와 λ = 0.103에서 처리 시간을 거꾸로 구하면 S = W / (1 + λW) = 5.4h, 이용률은 0.56이다. 이 가설이 맞다면 앞에 PR이 n건 기다릴 때 들어온 PR은 평균 (n + 1) × 5.4h를 기다려야 한다. 위 출력의 “대기열 길이와 대기” 표가 이 예측과 실제를 나란히 놓는다.

앞에 아무 PR도 없을 때 들어온 PR 14건도 평균 11.6h를 기다렸다. 줄이 없는데 기다렸다는 것은 대기가 리뷰를 시작하기까지의 지연에서 왔고 리뷰어의 처리 능력과는 거의 관계가 없다는 뜻이다. 나카툼바(J. Nakatumba)와 판 데르 알스트는 작업 부하가 처리 시간에 주는 영향을 로그와 회귀로 재는 방법을 제안했다(“Analyzing Resource Behavior Using Process Mining”, BPM 2009 워크숍). 같은 질문을 리뷰 대기에 던지면 Orbit의 답은 “부하와 거의 무관하다”다. 6~9월도 확인한다.

6~9월에는 가장 많이 맡은 사람의 몫이 23%로 줄었고 리뷰어별 대기 중앙값이 모두 1.6~1.8h다. 3~5월에 리뷰어 1을 뺀 다섯 명(2.0~3.4h)보다도 짧다. 이 차이는 아래에서 모델을 다른 기간으로 검증할 때 다시 쓴다.

4조직 마이닝과 결정 마이닝

대기의 원인이 배정 방식에 있다면, 누가 누구의 일을 받는지와 어떤 PR이 다른 갈래로 가는지를 먼저 본다.

판 데르 알스트, 레이예르스(H. A. Reijers), 송민석은 2005년 Computer Supported Cooperative Work 논문 “Discovering Social Networks from Event Logs”에서 로그의 수행자 정보로 사람 사이의 네트워크를 만드는 방법을 정리했다. 넘김(handover of work)은 사례 안에서 일이 한 사람에게서 다음 사람으로 넘어간 횟수, 함께 일함(working together)은 두 사람이 같은 사례에 나온 정도다. 활동이 비슷한 사람끼리 묶으면 역할이 나온다. org-mining.py는 PM4Py의 세 함수(discover_handover_of_work_network, discover_working_together_network, discover_organizational_roles)를 실행하고, PR 작성자와 첫 리뷰어의 짝을 센다. 이름은 역할 파일의 역할에 번호를 붙인 가명으로 바꿔 적는다.

• 넘김: 이어진 사건의 51%는 같은 사람이 이어서 했다. 다른 사람에게 넘어간 것 가운데 가장 많은 것은 PM 1에서 개발자로 가는 넘김이다. 업무 생성(PM) 다음의 작업 시작(개발), 막힘 해소(PM) 다음의 첫 커밋(개발)이 여기에 들어 있다.
• 역할 발견: 활동으로 묶은 역할 네 개가 나왔다. 역할 3(리뷰 승인, 변경 요청)에서 개발 1의 사건이 120건으로, 다음 사람(49건)의 두 배를 넘는다. 실습 25의 리뷰 집중도를 다른 방법으로 다시 찾은 것이다. 역할 1에 PM 1이 들어 있는 것은 product 업무의 PR을 PM이 직접 만들기 때문이다.
• 작성자 → 첫 리뷰어: 개발 1은 자기 PR을 제외한 모든 작성자에게서 가장 많은 첫 리뷰를 받았다. 리뷰어를 작성자가 고르면 특정 사람에게 몰린다는 것을 표로 보여 준다.

결정 마이닝(decision mining)은 프로세스 모델의 분기점에서 사례가 어느 갈래로 가는지를 사례의 속성으로 설명한다. 로지나트(A. Rozinat)와 판 데르 알스트는 2006년 BPM 학회의 “Decision Mining in ProM”에서 분기점마다 결정 나무를 학습해 갈래를 가르는 조건을 찾는 방법을 제안했다. 위 출력의 마지막 표는 “PR 생성 다음의 첫 리뷰가 변경 요청인가”라는 분기를 결정 기록, 막힘, 둘째 PR, 작업 시작 시기(6월 1일 전후), area로 설명한 깊이 2의 결정 나무다.

나무는 결정 기록으로 먼저 나누고, 결정 기록이 있는 PR을 다시 시기로 나눴다. 결정 기록이 있는 PR의 변경 요청 비율이 64%에서 28%로 떨어졌고, 결정 기록이 없는 PR은 시기로 나뉘지 않았다. C2의 선언적 제약 비교(response(결정 기록, 변경 요청) 78% → 32%)와 같은 방향이다. 결정 나무는 관계를 찾을 뿐 원인을 증명하지 않는다. 6월 1일에는 리뷰 당번과 완료 조건 갱신 규칙이 함께 시작되었으므로(실습 27), 이 차이를 어느 규칙의 효과로 볼지는 나무가 답하지 않는다.

5시뮬레이션 모델 만들기와 검증

로지나트, 만스(R. S. Mans), 송민석, 판 데르 알스트는 2009년 Information Systems 논문 “Discovering simulation models”에서 로그로 흐름, 자원, 시간, 데이터의 관점을 각각 발견해 시뮬레이션 모델 하나로 합치는 방법을 보였다. review-sim.py는 그 가운데 PR 첫 리뷰 부분만 이산 사건 시뮬레이션(discrete event simulation)으로 만든다. SimPy는 프로세스(PR 하나)와 자원(리뷰어 한 명)을 Python 함수와 객체로 적는 이산 사건 시뮬레이션 라이브러리다.

먼저 3~5월로 추정하고 3~5월의 도착을 그대로 흘려, 모델이 관측을 재현하는지 본다.

“작성자가 고름” 줄이 지금 방식의 재현이다. 첫 리뷰 대기 중앙값은 관측 6.8h에 대해 6.4h(반복 200회의 5~95% 범위 5.3~8.4h), 85%는 14.4h에 대해 14.2h, 가장 많이 맡은 사람의 몫은 52%에 대해 50%, 처리 시간 중앙값은 36.8h에 대해 37.9h(36.4~39.2h)다. 관측값이 모두 시뮬레이션의 범위 안에 있다. 대기열 점검의 기울기도 시뮬레이션 −0.0h, 관측 +0.3h로 둘 다 0에 가깝다. 같은 검증을 queue 모델로 한다.

queue 모델은 평균 대기를 관측에 맞췄는데도 중앙값이 4.1h(2.9~5.9h)로 관측 6.8h를 범위 밖에 둔다. 지수 분포의 처리 시간이 짧은 대기를 너무 많이 만들기 때문이다. 대기열 점검의 기울기도 +4.8h로 관측 +0.3h와 다르다. 두 모델 모두 평균은 맞출 수 있지만, 분포의 모양과 부하에 대한 반응으로 검증하면 queue 모델은 Orbit의 3~5월을 설명하지 못한다. 아래에서는 delay 모델을 쓴다.

6정책 비교와 실습 28의 어림

• 리뷰어를 늘려도 대기는 거의 줄지 않는다: 새 리뷰어도 다른 리뷰어와 같은 비율로만 고르면, 가장 많이 맡은 사람의 몫이 50%에서 45%로 줄 뿐이다. 대기가 처리 능력의 부족에서 오지 않았으므로 창구를 늘려도 M/M/c 표의 곡선을 따라 내려가지 않는다.
• 배정 방식을 바꾸는 정책이 효과가 크다: 고른 리뷰어에게 이미 1건이 기다리면 가장 덜 바쁜 사람에게 넘기는 대기 한도(WIP 한도)는 몫을 28%로, 리뷰 당번은 24%로 낮춘다. 대기가 긴 사람에게 가는 PR이 줄어 중앙값과 85%가 함께 준다.
• whatif.sh와 비교: 리뷰 당번의 처리 시간 33.4h는 어림 33.1h와 비슷하다. 시뮬레이션이 더해 주는 것은 두 가지다. 반복으로 얻은 범위(32.6~34.3h)와, 어림으로는 적을 수 없는 정책(리뷰어 추가, 대기 한도)의 비교다.

7다른 기간으로 검증하기

모델을 만든 기간으로만 검증하면 모델이 그 기간을 외웠는지 구분하지 못한다. 3~5월로 추정한 모델에 6~9월의 실제 PR 도착을 흘려 보내고, 리뷰 당번 줄을 6~9월의 관측과 비교한다.

리뷰 당번의 첫 리뷰 대기 중앙값은 3.3h(2.9~3.9h)로 예측했지만 실제는 1.8h였고, 처리 시간도 30.8h(29.9~31.7h) 예측에 실제 27.7h로, 둘 다 범위 밖이다. 모델이 놓친 것은 두 가지다.

1. 당번의 응답 속도: 모델은 사람마다 3~5월의 응답 지연이 그대로라고 가정했다. 그러나 queue-mining.py의 6~9월 표에서 리뷰어별 대기 중앙값은 1.6~1.8h로, 3~5월에 가장 빨랐던 사람들보다도 짧다. 당번이 된 날 리뷰를 먼저 처리하는 행동의 변화가 정책과 함께 생긴 것으로 보인다. 3~5월의 기록으로 추정한 모델에는 그 행동이 없다.
2. 리뷰 밖의 변화: 6월 이후에는 결정 기록이 있는 업무의 변경 요청이 줄었다(결정 마이닝, C2). 이 모델은 첫 리뷰 대기만 바꾸므로 그 효과는 처리 시간 예측에 들어가지 않는다.

같은 출력의 “작성자가 고름” 줄(34.4h)은 반대 방향의 물음에 답한다. 6~9월의 업무가 3~5월의 리뷰 방식으로 처리되었다면 처리 시간 중앙값이 34.4h였을 것이라는 어림이다. 모델 안에서 리뷰 당번이 줄인 몫은 6~9월 업무로 3.6h(34.4h → 30.8h), 3~5월 업무로 4.5h다. 실습 27이 다른 방법으로 얻은 4.1h와 비슷한 크기다.

8PR이 두 배로 늘면

팀이 커져 PR이 두 배가 되었을 때를 두 모델로 비교한다. --load 2는 실제 도착 대신 도착률을 두 배로 한 포아송 도착을 만든다.

delay 모델에서는 도착이 두 배여도 지금 방식 6.3h, 리뷰 당번 3.5h로 정책 비교의 값과 비슷하다. 리뷰 작업이 0.5시간뿐이라 리뷰어의 이용률이 여전히 낮기 때문이다. queue 모델에서는 지금 방식의 85%가 75.1h까지 늘어난다. 리뷰어 1의 이용률이 0.21 × 5.4 ≈ 1.1로 1을 넘어 관측 기간 내내 줄이 길어지는, M/M/c 표에서 이용률이 1에 다가갈 때의 모습이다. 같은 정책이라도 어느 모델이 맞느냐에 따라 “리뷰어 추가”의 가치가 달라진다. 지금의 Orbit 기록은 delay 모델을 지지하지만, 그 결론은 지금의 부하에서만 확인한 것이다. 부하가 늘 때 어느 쪽인지 가리려면 리뷰를 시작한 시각이 필요하다. GitHub에서는 리뷰 요청(review_requested) 사건의 시각과 리뷰어가 남긴 첫 댓글의 시각을 모으면, 요청부터 첫 반응까지와 첫 반응부터 리뷰 제출까지를 나눠 어림할 수 있다.

• M/M/c 표에서 이용률과 창구 수가 대기에 주는 영향을 설명할 수 있다.
• queue-mining.py로 도착률, 리뷰어별 L = λW, 묶음 리뷰 비율을 확인했다.
• 앞에 기다린 PR 수별 대기를 M/M/1 예측과 비교해, 리뷰 대기가 처리 능력보다 응답 지연에서 왔다는 근거를 적었다.
• 역할 발견과 작성자 → 첫 리뷰어 표에서 리뷰 집중을 확인하고, 결정 나무의 두 분기를 읽었다.
• delay 모델과 queue 모델을 3~5월로 검증하고, 정책 네 가지를 비교해 whatif.sh의 어림과 맞댔다.
• 6~9월 재생 결과가 범위 밖에 나온 이유 두 가지를 적었다.

마치며...

대기열 이론은 리뷰어가 바빠서 생긴 대기라면 창구를 늘리라고 말하지만, Orbit의 리뷰 대기는 줄의 길이와 거의 무관했다. 그래서 리뷰어 추가보다 배정 방식을 바꾸는 정책이 대기를 더 줄였고, 시뮬레이션은 이 판단에 범위를 붙이고 어림이 다루지 못하는 정책을 비교하게 해 주었다. 다른 기간으로 검증하자 모델은 리뷰 당번의 효과를 작게 예측했고, 그 차이에서 사람의 응답 속도가 정책과 함께 바뀐다는 가정이 빠졌음을 찾았다. 다음 모듈에서는 지금 열려 있는 업무가 늦어질지를 미리 예측하고, 그 예측을 경보로 운영할 때의 문제를 다룬다.