1두 가지 방식
| 방식 | 절차를 적는 법 | 결과 | 도구 |
|---|---|---|---|
| 규칙 기반 (선언적, declarative) | “반드시 지킬 것”만 규칙으로 적는다. 2006년 페시치(M. Pesic)와 판 데르 알스트의 Declare 언어가 대표적이다 | 규칙마다 위반 사례 목록 | process-map.sh와 process-rules.tsv (실습 21) |
| 모델 기반 (정렬, alignment) | 절차 전체를 순서도(프로세스 트리, 페트리넷)로 그린다 | 사례마다 모델과 어긋난 위치와 종류 | PM4Py conformance_diagnostics_alignments |
규칙 기반은 규칙 하나하나를 팀이 합의하기 쉽고, 어느 규칙을 몇 건이 어겼는지 바로 읽힌다. 모델 기반은 “절차의 어디에서 어긋났는가”를 한 걸음 단위로 보여 주지만, 절차 전체를 모델로 그리는 데 합의가 필요하다.
2기본 규칙으로 검사
bash github-pm-starter-kit/process-map.sh pm-lab/orbit-event-log-clean.csv | sed -n '/## 적합성 검사/,$p'
257건 중 199건(77%)이 다섯 규칙을 모두 지켰다. 위반 세 종류를 하나씩 본다.
| 위반 | 건수 | 기록이 말하는 것 | 정할 것 |
|---|---|---|---|
| 업무를 닫기 전에 병합된 PR이 있다 | 23 | 모두 area:qa 업무다. QA 업무는 PR을 만들지 않고 이슈의 테스트 항목표로 완료한다(실습 23의 4위 변형) | 규칙을 고친다. QA 업무에는 이 규칙을 적용하지 않는다 |
| 완료한 업무를 다시 열지 않는다 | 13 | QA가 결함을 찾아 다시 열었다. 13건 중 8건에 결정 기록이 있다 | 일하는 방식을 고칠 대상이다. 원인을 먼저 좁힌다 |
| PR을 만든 다음 작업일까지 첫 리뷰가 있다 | 23 | 기간별로 나눠 본다 (4단계) | 기간별 결과를 보고 정한다 |
3규칙의 적용 범위 정하기
process-rules.tsv의 여섯째 열(scope)에 규칙을 적용할 사례를 적는다. area!=qa는 QA 업무를 빼고, area=engineering은 개발 업무에만 적용한다. 키트의 규칙 파일을 복사해 둘째 규칙에 범위를 더한다.
cp github-pm-starter-kit/process-rules.tsv pm-lab/process-rules.tsv # 편집기로 열어 둘째 규칙 줄 끝에 탭과 area!=qa 를 더한다
# process-map.sh 적합성 검사 규칙. 열 구분은 탭이다. 팀의 작업 합의에 맞게 고친다. # 유형 A B 기한(작업일) 설명 # absence A가 한 번도 없어야 한다 # response A가 나오면 그 뒤에 B가 나와야 한다 # precedence B가 나올 때마다 그 앞(직전 B 이후)에 A가 있어야 한다 # within A 다음의 첫 B가 A 다음 날부터 센 작업일 수 안에 나와야 한다. B는 |로 여러 개를 쓸 수 있다 # 여섯째 열(scope, 생략 가능)은 규칙을 적용할 사례다. 예: area!=qa (QA 업무 제외), area=engineering # type A B limit description scope precedence 리뷰 승인 PR 병합 - 병합 전에 승인 리뷰가 있다 precedence PR 병합 업무 완료 - 업무를 닫기 전에 병합된 PR이 있다 area!=qa response 막힘 막힘 해소 - 막힘은 해소로 이어진다 absence 다시 열림 - - 완료한 업무를 다시 열지 않는다 within PR 생성 리뷰 승인|변경 요청 1 PR을 만든 다음 작업일까지 첫 리뷰가 있다
bash github-pm-starter-kit/process-map.sh pm-lab/orbit-event-log-clean.csv --rules pm-lab/process-rules.tsv \ | sed -n '/## 적합성 검사/,$p'
모두 지킨 사례가 222건(86%)으로 늘었다. 아래 프로세스 지도에서 “QA 업무에는 병합 PR 규칙을 적용하지 않는다”를 켜고 끄면 같은 변화를 볼 수 있다.
4기간별로 나눠 검사하기
process-map.sh에는 기간을 거르는 옵션이 없다. 사례마다 작업 시작 신호(작업 시작, 첫 커밋, 막힘 중 가장 이른 시각)를 구하고, 그 날짜로 로그를 두 파일로 나눈다. awk가 같은 파일을 두 번 읽는다. 첫 번째에 사례별 시각을 모으고, 두 번째에 줄을 거른다.
“다음 작업일까지 첫 리뷰” 위반 23건은 모두 3~5월 업무였고, 6월 이후에는 한 건도 없다. 리뷰 당번이 지키려던 규칙이 기록에서도 지켜졌다. 6월 이후 위반은 다시 열림 6건만 남아 131건 중 125건이 모든 규칙을 지켰다. 기간을 나누는 이 방법은 다른 스크립트의 입력을 만들 때도 쓴다.
5PM4Py 정렬: 팀 절차 모델과 비교
팀이 회의에서 그린 절차를 프로세스 트리로 적는다. 업무를 만들고 시작한 뒤, 개발 업무는 첫 커밋, PR 생성, 변경 요청 반복(0번 이상), 리뷰 승인, PR 병합을 거치고, PR이 없는 업무는 그 갈래를 건너뛰고(tau), 업무 완료로 끝난다.
->( '업무 생성', '작업 시작',
X( ->( '첫 커밋', 'PR 생성', *( tau, '변경 요청' ), '리뷰 승인', 'PR 병합' ), tau ),
'업무 완료' )
정렬은 사례마다 로그의 사건열과 모델이 허용하는 실행 하나를 한 걸음씩 짝짓는다. 짝이 맞는 걸음(동기 이동, synchronous move), 로그에만 있는 걸음(로그 이동, log move), 모델에만 있는 걸음(모델 이동, model move)으로 나뉘며, 로그 이동과 모델 이동이 적을수록 적합하다. 아래 셀 [5]가 정렬을, 셀 [6]이 4-eyes 원칙과 재작업을 검사한다.
| 결과 | 값 | 읽는 법 |
|---|---|---|
| 팀 절차에 그대로 맞는 사례 | 182/257 (71%) | 규칙 기반(범위를 정한 규칙 222건)보다 적다. 모델에 없는 활동이 하나라도 있으면 맞지 않는 사례가 된다 |
| 로그 이동: 결정 기록 | 43 | 절차에 없는 활동이다. 개발 중 정책이 바뀌는 일은 절차 밖의 사건으로 기록된다 |
| 로그 이동: 막힘, 막힘 해소 | 36, 36 | 절차에 없는 활동이다. 막힘은 예외로 다루기로 했다면 맞는 판단이다 |
| 로그 이동: 다시 열림과 두 번째 PR 활동 | 각 13 | 다시 열린 업무의 두 번째 회차 전체가 절차 밖이다 |
| 모델 이동 | 없음 | 절차에 있는데 빠진 활동은 없다. PR 없는 업무도 tau 갈래로 설명된다 |
| PR 작성자가 직접 승인한 사례 (4-eyes) | 0 | GitHub는 PR 작성자의 승인 리뷰를 받지 않는다. 다른 시스템의 로그에서는 이 검사가 의미가 있다 |
정렬 결과는 “절차를 고칠 곳”을 알려 준다. 결정 기록 43건은 개발 도중에 생겼고, 같은 업무에서 변경 요청과 다시 열림이 자주 함께 나왔다(실습 25). 결정 기록을 절차에 넣을지, 결정이 개발 도중에 생기지 않게 할지는 원인을 확인한 뒤 정한다.
6위반을 다루는 순서
- 위반 사례 몇 건을 골라 이슈와 PR을 직접 연다. 기록이 잘못된 것인지(라벨을 늦게 붙임, 닫는 키워드 누락), 일이 실제로 그렇게 흘렀는지 먼저 구분한다.
- 일이 실제로 그렇게 흘렀다면 규칙과 일하는 방식 중 어느 쪽이 맞는지 팀과 정한다. Orbit의 QA 업무처럼 규칙이 업무 유형을 고려하지 않았으면 규칙을 고친다.
- 고친 규칙 파일은 저장소에 커밋해 이력을 남긴다. 규칙이 바뀐 날짜를 알아야 기간별 위반 수를 바르게 비교할 수 있다.
“위반 0건”을 목표로 정하면 위반이 생길 만한 기록(막힘 라벨, 다시 열기, 결정 기록 댓글)을 남기지 않는 쪽으로 행동이 바뀐다. 그러면 로그가 실제와 멀어져 적합성 검사 자체가 쓸모를 잃는다. 위반 건수는 원인을 찾을 사례 목록으로 쓴다.
막히면
| 증상 | 확인과 해결 |
|---|---|
| 범위를 더했는데 결과가 그대로다 | 열 구분이 탭이 아니라 공백이다. cat -et pm-lab/process-rules.tsv | grep 병합으로 보면 탭은 ^I로 보인다 |
| awk 결과 파일에 첫 줄만 있다 | 같은 파일 이름을 두 번 주었는지 확인한다. 첫 번째 읽기에서 사례별 시각을 모으고, 두 번째 읽기에서 거른다 |
| 셀 [5]가 오래 걸린다 | 정렬은 변형마다 모델과의 최적 짝을 찾는 계산이다. Orbit의 변형 20개는 브라우저에서 수 초가 걸리고, 변형이 수천 개인 로그는 내 컴퓨터에서 실행한다 |
- 기본 규칙으로 검사하고 위반 세 종류의 원인을 확인했다.
pm-lab/process-rules.tsv에 범위를 더해 QA 업무를 규칙에서 뺐다.- 로그를 작업 시작 날짜로 나누고, 첫 리뷰 규칙 위반이 3~5월에만 있었음을 확인했다.
- 정렬 결과에서 로그 이동이 많은 활동 세 가지를 찾았다.
- 위반마다 규칙을 고칠지 일하는 방식을 고칠지 판단을 적었다.
마치며...
적합성 검사의 결과는 위반 목록이지만, 쓸모는 그 목록을 규칙의 결함과 일의 결함으로 나누는 데 있다. Orbit에서 QA 업무의 위반은 규칙의 결함이었고, 첫 리뷰 규칙 위반은 6월 이후 사라졌으며, 결정 기록과 다시 열림은 절차 밖에서 반복되는 갈래로 남았다. 다음 실습에서는 묶음을 나눠 비교하며 이 갈래의 원인을 좁히고 인사이트로 적는다.