프로세스 마이닝 분석을 위한 로그 생성 가이드라인


얼마 전 새로 개발된 시스템에 사용자 패턴 분석을 위한 로그를 추가하기로 결정이 났습니다. 호기롭게 ‘좋아! 시스템 내 모든 이벤트에 로그를 추가하여 의미 있는 데이터와 분석 결과를 도출해보자!’라고 잔뜩 기합을 넣고 작업을 시작하려고 보니, 막상 어디서부터 어떻게 시작해야 할지 막막해졌습니다.
 
그러던 중 데이터 분석을 하는 직원들로부터 분석을 의뢰받은 데이터에 문제가 있는 경우가 많아서 분석을 하기가 어려울뿐더러, 이러한 경우 분석을 하더라도 의미 있는 결과를 추출하기 어렵다는 하소연을 들었습니다.
 
그렇다면 분석이 어려운 로그 데이터란 어떤 것일까요?
문제가 있는 로그 데이터에는 크게 4가지 유형이 있습니다.  

1. 손실 데이터 |missing data
  : 케이스 아이디, 이벤트 속성 등 분석에 있어 꼭 필요한 정보가 빠져있는 경우
2. 부정확한 데이터 |incorrect data
  : 기록 시스템의 문제 등의 이유로 잘못된 값이 로그 데이터에 기록된 경우
3. 정밀하지 않은 데이터 |imprecise data
  : 기록된 정보가 정밀하지 않아 분석 수행에 어려움을 주는 경우(예. 타임스탬프에 연도와 월까지만 기록된 경우)
4. 무관한 데이터 |irrelevant data
  : 데이터 필터링 및 가공 등의 과정에서 적절하지 않은 데이터가 포함된 경우

이에 올바른 로그 데이터를 만들기 위한 방법을 찾아보았습니다.
아래는 에인트호번 공과대학 Wil van der Aalst 교수의 로그 데이터를 위한 가이드라인입니다.

로그 데이터 생성을 위한 가이드라인

1. 참조자(reference), 속성 이름(attribute name), 이벤트(event)는 관련된 모든 사람들에게 동일한 의미를 가져야 합니다. 하나의 특정한 속성이 다른 이해관계에 있는 사람들 간에 서로 다른 의미로 해석돼서는 안됩니다.
 
2. 참조자(reference) 및 속성 이름(attribute name)를 관리하기 위한 체계적인 컬렉션이 있어야 합니다. 로그 기록은 특정 프로그래머가 조건에 따라 코드에 추가하는 것이 아닙니다. 새로운 이벤트와 참조자(reference), 속성 이름(attribute name)은 관련이 있다고 일치된 합의가 이루어 후에 추가되어야 합니다.
 
3. 참조자(reference)는 변경되지 않는 것이어야 합니다. 참조자(reference)는 문맥에 따라 변경되거나 기계의 언어 세팅을 바꾼다고 해서 달라져서는 안됩니다. 시간의 변화에 따라 달라져서도 안되며 안정적이어야 합니다.
 
4. 속성 이름(attribute name)은 가능한 정확해야 합니다. 때로는 데이터를 정확하게 생성할 수 없는 경우도 있는데, 이러한 경우에는 그러한 사항이 명확히 명시되어야 합니다.
 
5. 이벤트(event), 참조자(reference), 속성(attributes)이 확실하지 않은 경우, 그러한 불확실성이 분명히 명시되어야 합니다. 불확실하지 않은 자원임을 알고 있다면 우리는 교육을 통해 배운 추론을 통하여 분석할 수 있습니다.
 
6. 이벤트 데이터는 정렬되어야 하며, 타임스탬프에 의해 정렬이 되거나 리스트의 특정 조건에 따라 정렬될 수 있습니다.
 
7. 가능한 데이터는 트랜잭션 단위로 저장되어야 합니다. 단순히 종료 액티비티(activity)만 저장하는 것이 아니라 시작, 중단, 재개, 종료와 같은 흐름을 저장해야 합니다. 이로써 작업의 지속 시간을 계산할 수 있습니다.
 
8. 이벤트 데이터의 품질을 보장하기 위해서는 정기적이고 지속적으로 로그 데이터를 점검하고 체크해야 합니다. 단지 시스템 운영 초기에만 로그를 추가해 놓고 말 것이 아니라, 로그의 최신 여부를 주기적으로 확인해야 합니다.
 
9. 로그 기록은 시간 경과에 따라 변경되거나 특정 상황에 따라 달라져서는 안됩니다. 예를 들어 특정 시점에 로그 기록을 중단한다면, 우리는 해당 액티비티가 실행되었다가 중단되었다고 결론 내릴 것입니다. 하지만 이것은 로그가 기록되지 않아서 발생한 잘못된 결론입니다.
 
10. 데이터 분석 전에는 이벤트 집계를 하지 않는 것이 좋습니다. 집계는 분석 중에 이루어져야 하며, 이벤트 데이터는 가능한 처음 생성되었을 때의 상태로 두어야 합니다.
 
11. 이미 발생한 이벤트를 삭제하면 안 됩니다. 예를 들어 탈락한 학생 데이터를 삭제하는 경우 잘못된 분석 결과를 야기하게 됩니다.
 
12. 데이터에 기록된 개인 정보들에 대해서 프라이버시를 보장하되 상관관계가 제거되지 않도록 주의해야 합니다. 이를 위해서 데이터를 익명으로 만들되 연관 관계를 표현할 수 있는 해싱(hashing)을 사용할 수 있습니다.