객체 중심 이벤트 데이터

cd ~/gh-pm-lab
python3 -c "import pm4py, simpy, sklearn; print(pm4py.__version__, simpy.__version__, sklearn.__version__)"

세 패키지가 없으면 트랙 C 안내의 설치 명령을 먼저 실행한다. 이 모듈의 ocel-export.py는 Python 표준 라이브러리만 쓰고, ocel-notebook.py는 PM4Py 2.7.23.8을 쓴다. PM4Py를 불러오면 표준 오류로 라이선스 안내문이 먼저 나온다. 아래 출력에서는 그 안내문을 뺐다.

1사례 하나로 줄일 때 생기는 일

업무마다 PR이 몇 개인지 센다.

PR이 하나인 업무가 221건, 둘인 업무가 13건이고, 나머지 23건은 PR이 없는 QA 업무다. OB-005는 3월 12일에 PR #1005로 끝났다가 3월 17일에 다시 열려 PR #2005로 다시 끝났다. 업무를 사례로 삼은 로그에서 OB-005의 사건 13개는 한 줄로 이어지고, “PR 생성”과 “리뷰 승인”이 두 번씩 나온다. 두 리뷰는 서로 다른 PR에 대한 것이고 리뷰어도 다르지만(dev-a, dev-b), 사례 하나 안에서는 같은 활동의 반복으로만 보인다.

판 데르 알스트(W. M. P. van der Aalst)는 2019년 논문 “Object-Centric Process Mining: Dealing with Divergence and Convergence in Event Data”(SEFM 2019)에서 사례 하나를 고를 때 생기는 문제를 두 가지로 정리했다.

사례를 PR로 바꾸면 발산은 줄지만, 업무에만 걸린 사건(업무 생성, 작업 시작, 막힘, 결정 기록, 다시 열림)이 빠진다. 사례를 무엇으로 정하든 한쪽의 정보가 빠지거나 복제된다. 객체 중심 이벤트 로그(object-centric event log)는 사례를 하나로 정하지 않고, 사건마다 관련된 객체를 모두 적는다.

2OCEL 2.0의 구성

OCEL 2.0(Object-Centric Event Log 2.0)은 RWTH 아헨 대학의 판 데르 알스트 연구실이 중심이 되어 2023년에 낸 교환 형식 명세다. 명세서와 예시 로그는 ocel-standard.org에 있고, 2024년에 베르티(A. Berti) 등이 같은 명세를 arXiv(2403.01975)에 올렸다. 1.0판에 없던 것은 세 가지다. 사건과 객체의 관계에 붙는 한정자(qualifier), 객체와 객체의 관계, 시간에 따라 바뀌는 객체 속성이다.

GitHub의 리뷰(review)도 아이디가 있는 객체이고, 리뷰 하나에 댓글 여러 개가 달린다. Orbit 로그는 리뷰 하나를 사건 하나로만 적었으므로 review 객체를 만들지 않았다. 리뷰 댓글까지 모으는 저장소라면 review를 객체 유형으로 두고 “리뷰 하나에 댓글 몇 개, 몇 번 오갔는가”를 객체 단위로 잴 수 있다.

3OCEL 2.0 파일 만들기

ocel-export.py는 키트 형식의 CSV(case_id,activity,timestamp,resource,ref,area)를 읽어 OCEL 2.0 파일을 쓴다. 객체와 관계는 다음 규칙으로 만든다.

• 사건마다 그 줄의 case_id를 task 객체로, ref가 있으면 그 PR을 pr 객체로, resource를 person 객체로 잇는다.
• person의 한정자는 활동으로 정한다. 업무 생성은 creator, PR 생성은 author, 변경 요청과 리뷰 승인은 reviewer, PR 병합은 merger다. 리뷰 사건은 PR 작성자에게도 pr author로 잇는다.
• 업무 완료가 같은 업무의 PR 병합 바로 뒤 60초 안에 기록되었으면 그 PR에도 closing pr로 잇는다. 닫는 키워드로 PR이 이슈를 닫으면 두 사건이 몇 초 간격으로 생기기 때문이다.

숫자를 검산한다. 사건-객체 관계 5,582개는 task 관계 1,975개(모든 사건), pr 관계 1,310개(PR 번호가 있는 사건 1,063개와 PR 병합에 이어진 업무 완료 247개), person 관계 1,975개, 리뷰 사건의 작성자 관계 322개를 더한 값이다. 객체-객체 관계 494개는 PR 247개마다 closes와 author가 하나씩이다. 속성 변화 1,106건 가운데 612건이 task의 state와 blocked, 494건이 pr의 state다.

e00005(OB-001의 리뷰 승인)는 객체 네 개에 걸린다. #2005 객체는 3월 18일에 OPEN, 3월 20일에 MERGED가 되었고 OB-005를 닫는다. 같은 파일이 키트의 samples/c-orbit-ocel.json으로 들어 있다.

출력 파일의 확장자를 .sqlite로 주면 OCEL 2.0의 관계형 형식으로 쓴다. 활동마다 표가 하나씩 생기고, 표 이름은 event_map_type 표가 활동 이름과 잇는다.

PM4Py의 관계형 스키마 점검(표의 존재, 기본 키, 외래 키 등 24개 조건)을 모두 통과했다. SQLite 파일은 SQL로 바로 질의할 수 있어 객체가 수십만 개인 로그에 맞고, JSON은 사람이 읽고 grep으로 찾기 쉽다.

bash github-pm-starter-kit/event-log.sh "$PM_REPO" --snapshots pm-lab/pm-data/snapshots > pm-lab/event-log.csv
python3 github-pm-starter-kit/ocel-export.py pm-lab/event-log.csv pm-lab/my-ocel.sqlite --roles github-pm-starter-kit/roles.tsv
python3 github-pm-starter-kit/ocel-notebook.py pm-lab/my-ocel.sqlite

gh pr list -R "$PM_REPO" --state merged --limit 200 --json number,closingIssuesReferences \
  --jq '.[] | select((.closingIssuesReferences | length) > 1) | "#\(.number): \([.closingIssuesReferences[].number] | join(", "))"'

4PM4Py로 읽고 평탄화하기

ocel-notebook.py는 # %% 줄로 셀이 나뉜 스크립트다(실습 24의 pm4py-notebook.py와 같은 방식). 셀 [1]~[6]을 한 번에 실행하고 결과를 보고 파일로 남긴다.

평탄화(flattening)는 객체 유형 하나를 골라, 그 유형의 객체 하나를 사례 하나로 삼은 일반 로그를 만드는 일이다(PM4Py ocel_flattening). 셀 [3]의 표를 읽는다.

5수렴과 발산을 숫자로

셀 [4]는 실제 분석에서 자주 만드는 로그 하나를 흉내 낸다. PR을 사례로 삼으면서 백로그 대기와 막힘도 함께 보려고, 그 PR이 닫는 업무의 사건을 모두 PR 사례에 붙인 로그다.

이 로그로 “PR 리드 타임”을 재면 다시 열린 업무의 둘째 PR이 실제보다 길게 나오고, 업무 생성은 PR이 있는 업무 234건보다 13번 많은 247번 나온다. OCEL에서는 업무 생성이 task 객체에만 걸리므로 PR 리드 타임은 pr 객체의 사건만으로, 백로그 대기는 task 객체의 사건만으로 잰다.

6객체 중심 직접 이어짐 그래프

객체 중심 직접 이어짐 그래프(object-centric directly-follows graph, OC-DFG)는 객체 유형마다 따로 직접 이어짐 관계를 구해 한 그림에 겹친다. 연결의 색이 객체 유형이고, 연결의 EC는 그 유형의 객체에서 두 사건이 이어진 횟수(event couples), 활동 상자의 E는 사건 수다. 셀 [5]가 task와 pr 두 유형으로 그래프를 구하고 pm-lab/ocel-fig/ocdfg.dot로 저장한다.

셀 [5]의 출력에서 두 유형을 비교한다.

• task에만 있는 연결 11개: 업무 생성, 작업 시작, 막힘, 막힘 해소, 결정 기록, 다시 열림 가운데 하나가 들어간 연결이다. 이 활동들은 PR 객체에 걸리지 않는다.
• “첫 커밋 → PR 생성”은 task 204회, pr 247회: 업무 43건에서 첫 커밋과 PR 생성 사이에 결정 기록이 있다. task의 흐름에서는 “첫 커밋 → 결정 기록 → PR 생성”으로 끊기고, 결정 기록이 걸리지 않는 pr의 흐름에서는 247개 PR 모두 첫 커밋 다음이 PR 생성이다. 같은 두 활동의 관계가 어느 객체 유형을 기준으로 보느냐에 따라 다르게 나온다.
• pr 흐름의 끝은 모두 업무 완료: closing pr 관계 덕분에 PR 247개가 모두 “PR 병합 → 업무 완료”로 끝난다. 이 관계가 없으면 pr의 흐름은 PR 병합에서 끝나고, PR이 업무를 닫았다는 사실은 로그에 남지 않는다.

셀 [6]은 객체 속성의 시간 변화를 쓴다. state가 두 번 이상 CLOSED가 된 업무는 13건으로 다시 열린 업무 수와 같다. 활동을 세지 않고 상태 변화만으로 같은 답을 얻는다.

7이벤트 추상화와 로그 결함

GitHub의 원래 기록은 활동 12종보다 훨씬 잘다. 이슈 타임라인에는 라벨 붙임(labeled), 담당자 지정(assigned), 리뷰 요청(review_requested), 리뷰(reviewed), 커밋(committed), 병합(merged), 닫힘(closed), 다시 열림(reopened), 다른 이슈에서의 언급(cross-referenced) 같은 사건이 쌓인다. 잘게 기록된 사건을 분석 질문에 맞는 활동으로 묶는 일을 이벤트 추상화(event abstraction)라고 한다. 키트의 event-log.sh는 이미 몇 가지 추상화를 했다.

수리아디(S. Suriadi) 등은 2017년 Information Systems 논문에서 실제 로그에 자주 나오는 결함을 패턴 11개로 정리했다. 그중 GitHub 기록에서 볼 수 있는 것을 Orbit과 키트에 대어 본다.

OCEL로 바꾸면 동음이의 이름 문제는 줄어든다. 둘째 “첫 커밋”은 #2005 객체에 걸리므로, pr 객체를 기준으로 보면 언제나 그 PR의 첫 커밋이다.

8사람 객체와 개인정보

person 객체를 두면 사람마다 평탄화한 로그(셀 [3]의 person 행)가 바로 나온다. 한 사람의 6개월 활동이 시각까지 한 줄로 이어진 기록이고, 개인을 평가하거나 감시하는 데 그대로 쓸 수 있는 형태다. 파일을 팀 밖으로 주기 전에 세 가지 중 하나를 고른다.

가명은 처음 나온 순서로 붙는다. 그런데 person-01은 role이 PM인 유일한 사람이고, QA도 한 명뿐이다. Orbit처럼 여덟 명인 팀에서는 역할 속성 하나와 활동 유형만으로 가명이 누구인지 알 수 있다. 개인정보 보호법 제2조 제1호의2는 가명처리를 “추가 정보가 없이는 특정 개인을 알아볼 수 없도록 처리하는 것”으로 정의한다. 작은 팀의 가명 파일은 이 조건을 만족하지 못할 수 있으므로, 외부에 줄 때는 사람 객체를 빼거나 집계만 준다. 대응표(pm-lab/person-map.tsv)는 저장소에 커밋하지 않는다.

• 수렴과 발산을 Orbit의 예(리뷰 사건 322건, PR이 둘인 업무 13건)로 설명할 수 있다.
• pm-lab/orbit-ocel.json과 pm-lab/orbit-ocel.sqlite를 만들고 관계형 스키마 점검을 통과했다.
• task, pr, person으로 평탄화한 로그의 행, 빠진 사건, 복제된 사건을 비교했다.
• “첫 커밋 → PR 생성”이 task와 pr에서 다르게 나오는 이유를 설명할 수 있다.
• 가명화한 파일이 작은 팀에서 다시 식별되는 이유와 대안을 적었다.

마치며...

사례 하나를 고르는 일은 분석 질문을 고르는 일이고, 고르지 않은 객체의 정보는 빠지거나 복제된다. OCEL 2.0은 사건마다 걸린 객체를 모두 적어 이 선택을 분석 단계로 미루고, 평탄화는 그 선택을 다시 하는 단계다. 이 모듈에서는 Orbit의 업무, PR, 사람을 객체로 나누어 같은 기록이 객체에 따라 다른 흐름과 숫자를 내는 것을 확인했다. 다음 모듈에서는 업무 로그 하나로 여러 발견 알고리즘과 선언적 제약을 비교하고, 6월 1일의 변화를 통계 검정으로 찾는다.