← 목록으로
AI·데이터
#프로세스 마이닝#이벤트 로그#프로세스 발견#적합성 검사#XES#업무 프로세스 개선
최종 업데이트 · 2026-09-29

프로세스 마이닝(Process Mining) 기반 업무 프로세스 분석·개선

1. 개요

정의: 프로세스 마이닝은 정보시스템이 기록한 이벤트 로그에서 실제 업무 흐름을 발견하고, 기준 모델과의 차이를 검증하며, 시간·자원·데이터 관점에서 프로세스 모델을 개선하는 데이터 기반 분석 기법이다. [1][3]

조직의 업무는 ERP, CRM, 전자결재, 콜센터, 물류 시스템 등 여러 정보시스템을 통과한다. 각 시스템은 업무가 실행된 시점과 처리 결과를 기록하지만, 시스템별 로그만으로는 하나의 업무가 처음부터 끝까지 어떤 경로를 거쳤는지 파악하기 어렵다. 프로세스 마이닝은 서로 다른 이벤트를 업무 사례(case) 단위로 연결하여 실제 실행 경로를 재구성한다.

전통적인 업무 분석은 인터뷰와 워크숍으로 이상적인 절차를 그린 뒤 실제 운영과 비교한다. 이 방법은 현장 지식과 맥락을 얻기 좋지만, 기억 편향이나 표본 선택, 예외 경로 누락의 영향을 받는다. 반대로 프로세스 마이닝은 실행 로그에 근거해 빈번한 경로, 재작업, 병목, 승인 우회 등을 정량적으로 보여 준다.

다만 로그가 곧 현실 그 자체인 것은 아니다. 이벤트가 기록되지 않았거나 잘못된 사례 번호로 묶이거나 시각이 뒤섞이면, 정교한 알고리즘도 잘못된 프로세스를 만들 수 있다. 따라서 기술사는 분석 알고리즘뿐 아니라 업무 경계, 로그 품질, 개인정보, 모델 해석, 개선 통제까지 연결하여 설계해야 한다.

1.1 필요성과 적용 목표

첫째, 실제 업무 흐름과 문서상 표준 절차의 차이를 가시화한다. 예를 들어 구매 승인 규정은 2단계 승인이라고 정했지만, 로그에서 금액 기준에 따른 승인 생략이나 같은 단계의 반복이 관찰될 수 있다. 이 차이는 규정 위반인지, 합리적인 예외인지, 시스템 설계 결함인지 현업과 함께 판단해야 한다.

둘째, 리드타임과 병목 원인을 활동 단위로 분해한다. 전체 처리시간이 길다는 결과만으로는 어느 부서나 대기 구간을 개선해야 하는지 알 수 없다. 활동의 시작·종료 시각과 자원 정보를 연결하면 실제 작업시간과 대기시간, 재작업을 분리할 수 있다.

셋째, 규정 준수와 업무 위험을 지속적으로 점검한다. 감사 표본 몇 건만으로는 전체 업무의 경로 편차를 파악하기 어렵지만, 이벤트 로그는 전체 사례 또는 넓은 모집단을 분석할 수 있다. 단, 자동으로 발견된 편차를 곧바로 위법·부정으로 단정하지 말고 업무 조건과 로그 한계를 확인해야 한다.

2. 핵심 개념과 분석 관점

프로세스 마이닝의 출발점은 이벤트 로그다. [1][3] 로그는 프로세스 실행 사례들의 집합이며, 각 사례는 시간 순서가 있는 이벤트들의 묶음으로 표현된다. 분석 결과는 데이터가 기록된 방식과 사례 경계 정의에 직접 영향을 받는다.

flowchart LR
    B[업무 목표·규정] --> M[기준 프로세스 모델]
    S[ERP·CRM·업무시스템] --> E[이벤트 로그]
    E --> P[프로세스 마이닝]
    M --> P
    P --> D[실제 흐름·편차·병목]
    D --> A[현업 검증·원인 분석]
    A --> I[프로세스 개선·통제]
    I --> B

2.1 이벤트 로그의 구성

사례(case)는 주문 1건, 민원 1건, 보험 청구 1건처럼 하나의 업무 실행 단위를 뜻한다. 활동(activity)은 접수, 검토, 승인, 지급 등 업무에서 수행된 단계이며, 이벤트는 특정 사례에서 활동이 발생한 한 번의 기록이다. 동일 활동도 반복될 수 있으므로 활동명만으로는 발생 순서와 개별 실행을 구분하기 어렵다.

기본 로그에는 사례 식별자, 활동명, 시각이 필요하다. 여기에 자원(담당자·부서·시스템), 활동의 시작/완료 상태, 금액이나 고객 유형과 같은 사례 속성, 처리 결과를 더하면 분석 관점이 넓어진다. 기록 시각(timestamp)은 이벤트의 순서를 구성하므로 시간대, 시계 동기화, 이벤트 발생시각과 적재시각의 차이를 관리해야 한다.

요소 예시 분석상 의미
사례 식별자 주문번호 O-301 하나의 실행을 묶는 기준
활동 주문접수, 신용심사, 출고 프로세스의 단계
시각 2026-09-29 09:15 순서·대기·처리시간 계산
자원 담당자·팀·자동화 봇 업무 분담·부하 분석
속성 주문액, 채널, 위험등급 조건별 경로·성과 비교
결과 승인, 반려, 취소 업무 결과와 경로의 관계

로그를 단순한 표로 취급하지 않고, 각 사례의 이벤트 시퀀스로 정규화하는 과정이 중요하다. 같은 사건을 ERP와 결재 시스템이 각각 기록하면 이벤트 중복이나 서로 다른 명칭의 활동이 생길 수 있다. 식별자 매핑과 활동 분류체계가 불안정하면 사례가 분리되거나, 서로 다른 업무가 한 사례로 합쳐진다.

2.2 세 가지 기본 분석 유형

프로세스 마이닝은 일반적으로 프로세스 발견, 적합성 검사, 모델 개선의 세 유형으로 설명한다. [1][3] 각 유형은 이벤트 로그와 기준 모델을 사용하는 방식이 다르며 서로 대체재라기보다 연결된 분석 단계다.

유형 입력 핵심 질문 대표 산출물
프로세스 발견 이벤트 로그 실제 흐름은 어떠한가? As-is 프로세스 모델
적합성 검사 로그와 기준 모델 실행이 의도한 모델과 일치하는가? 편차·정합성 진단
모델 개선 로그와 기존 모델 시간·자원·데이터로 모델을 어떻게 개선하는가? 성능·조직·예측 정보가 보강된 모델

가. 프로세스 발견(Process Discovery)

프로세스 발견은 사전에 정한 프로세스 모델 없이 로그에서 실행 흐름을 추론한다. 결과 모델은 현재 조직이 실제로 수행하는 As-is를 설명하며, 알려지지 않았던 대체 경로와 반복 활동도 드러낼 수 있다. 이를 표준 프로세스라고 오해하지 않도록 발견 모델과 목표 To-be 모델을 명확히 구분한다.

예를 들어 환급 업무 로그에서 접수→검토→승인→지급뿐 아니라 검토→보완요청→재검토의 반복이 발견될 수 있다. 반복이 업무 복잡성에 따른 합리적 경로인지, 최초 안내 부족으로 생긴 재작업인지는 분석 결과만으로 알 수 없다. 따라서 프로세스 모델은 개선 대화를 시작하는 증거이지, 현업 판단을 대체하는 결론이 아니다.

나. 적합성 검사(Conformance Checking)

적합성 검사는 기준 모델과 실제 로그를 대조하여 행위가 모델에 부합하는 정도와 편차 위치를 진단한다. 정책 준수 여부를 볼 때는 모델이 규범적 기준인지, 단지 현황을 표현하는 설명 모델인지 먼저 정해야 한다. 설명 모델과 다른 실행은 모델이 현실을 놓쳤을 가능성이 있고, 규범 모델과 다른 실행은 승인 절차 누락이나 예외 통제 문제일 수 있다.

모든 편차가 곧 잘못은 아니다. 법령이나 위험정책에 근거한 필수 통제의 우회는 조사 대상이 될 수 있지만, 고객 보호를 위한 긴급 경로처럼 승인된 예외도 있을 수 있다. 편차에는 사례 속성, 권한, 업무 사유를 결합하고, 사람이 판단할 수 있도록 근거와 추적 기록을 남겨야 한다.

다. 모델 개선(Enhancement)

모델 개선은 기존 프로세스 모델에 로그에서 얻은 성능, 자원, 데이터 정보를 덧붙이거나 모델 자체를 보정한다. 활동별 처리시간과 대기시간을 색상으로 표시하면 병목을 빠르게 찾을 수 있고, 자원 정보를 추가하면 특정 팀에 집중된 대기를 살펴볼 수 있다. 모델과 로그가 잘 맞지 않는 경우에는 편차 진단을 토대로 모델의 누락된 조건이나 분기 규칙을 수정할 수 있다.

예측형 분석은 진행 중인 사례가 완료될 가능성이나 남은 시간을 추정할 수 있다. 그러나 과거 패턴이 정책 변경 이후에도 유지된다는 보장은 없으므로, 예측 결과를 자동 승인·거절의 단독 근거로 사용하지 않는다. 모델 개선은 분석 정확도만 높이는 활동이 아니라 사람이 개입할 시점과 업무 책임을 정하는 운영 설계까지 포함한다.

3. 처리 구조와 분석 방법

실무에서는 원천 로그를 바로 마이닝 도구에 넣기보다, 업무 정의와 데이터 파이프라인을 함께 설계한다. 업무의 시작·종료 조건과 사례 단위를 먼저 합의하고, 시스템별 이벤트를 공통 활동과 시각 기준으로 변환한다. 그다음 로그 품질을 검증하고 탐색·모델링·현업 검토를 반복한다.

flowchart TD
    G[목표·범위·사례 정의] --> X[시스템 이벤트 추출]
    X --> C[식별자 연결·활동 매핑]
    C --> Q[시간·중복·누락 품질검사]
    Q --> F[로그 필터링·익명화]
    F --> A[발견·적합성·성능 분석]
    A --> V[현업·감사 검증]
    V --> R{개선 승인}
    R -->|승인| D[업무·시스템 통제 개선]
    R -->|보완| C
    D --> O[지표 모니터링·재분석]

3.1 로그 추출과 전처리

첫 단계는 분석 목적에 맞는 사례 경계를 정하는 것이다. 주문 처리와 환불 처리를 하나의 사례로 볼지 별도 사례로 볼지에 따라 발견되는 경로와 리드타임이 달라진다. 고객·주문·배송처럼 하나의 이벤트가 여러 객체와 연결되는 상황에서는 단일 사례 키로 억지 변환하면 관계가 손실될 수 있다.

다음으로 시스템별 이벤트 코드를 공통 활동 사전으로 매핑한다. PAY_OK, PaymentSettled, 결제완료를 동일한 의미로 묶을 수 있지만, 완료·취소·실패 상태를 하나로 합치면 중요한 업무 차이가 사라진다. 매핑 규칙과 변경 이력을 관리하고, 이벤트 정의 변경 시 과거 데이터와 비교 가능한지 검증한다.

이벤트 시각은 발생 시간, 애플리케이션 기록 시간, 데이터 적재 시간을 구분한다. 시스템 간 시계 차이, 지연 적재, 역전된 타임스탬프는 잘못된 활동 순서나 음수 처리시간을 만들 수 있다. 이상 이벤트를 무조건 삭제하기보다는 보정·격리·제외 기준을 명시하고 결과에 영향을 기록한다.

3.2 로그 표준과 모델 표현

XES(eXtensible Event Stream)는 이벤트 로그와 이벤트 스트림의 상호운용을 위한 IEEE 표준이다. [2] IEEE 1849-2023은 로그·스트림과 확장 구조를 위한 문법 및 XML 스키마를 제공하며, 2016판을 대체하는 활성 표준으로 표시되어 있다. 표준 포맷을 쓰더라도 원천 활동의 업무 의미와 사례 연결 규칙까지 자동으로 통일되는 것은 아니므로 별도의 의미 매핑이 필요하다.

프로세스 모델은 분석 목표와 이해관계자에 맞게 선택한다. Petri Net은 동시성, 토큰 흐름, 교착·도달 가능성을 엄밀히 다루기 좋고, BPMN은 업무 담당자에게 역할·이벤트·게이트웨이를 설명하기 쉽다. 직접후행 그래프(DFG)는 활동 간 빈도와 성능을 빠르게 탐색할 수 있지만, 분기·반복의 의미를 엄밀하게 표현하기 어렵다.

모델 표현 강점 주의점·활용
Petri Net 동시성·실행 의미·적합성 분석 비전문가에게 복잡할 수 있음
BPMN 업무 역할·이벤트·분기 표현 마이닝 결과를 검토해 업무 의미를 보완
DFG 빈도·직접 선후관계를 빠르게 시각화 간결하지만 실제 제어 흐름을 과도하게 단순화할 수 있음
프로세스 트리 구조적 발견과 블록형 흐름 표현 다양한 비정형 행태가 많은 로그에서는 모델 복잡도 관리 필요

3.3 발견 알고리즘과 품질

α 알고리즘은 이벤트 로그에서 인과·동시성 관계를 찾아 Petri Net을 구성한 초기의 대표 기법이다. [3][5] 간단한 로그를 설명하는 데 유용하지만, 잡음·희귀 경로·짧은 루프에 취약할 수 있어 실제 업무 로그에 그대로 적용하기 어렵다. 알고리즘은 하나의 정답을 산출하는 것이 아니라, 로그와 가정에 따라 서로 다른 수준의 단순화와 설명력을 제공한다.

Heuristics Miner 계열은 빈도 정보를 이용해 드문 행동의 영향을 줄이며, Inductive Miner는 재귀적인 분할로 프로세스 트리를 발견할 수 있다. [5] 실무에서는 로그 필터링, 알고리즘 설정, 모델 시각화만으로 검증을 끝내지 말고 현업이 알고 있는 대표 사례와 편차를 대조한다. 모델을 지나치게 세밀하게 만들면 예외 하나하나를 모두 설명하느라 이해하기 어려워지고, 지나치게 단순하게 만들면 실제 위험 경로를 놓친다.

모델 품질은 적합도(Fitness), 정밀도(Precision), 일반화(Generalization), 단순성(Simplicity)을 함께 고려한다. [3][5] 적합도는 관측된 실행을 모델이 얼마나 재현하는지, 정밀도는 모델이 로그에 없는 행태까지 과도하게 허용하지 않는지를 본다. 한 지표를 높이기 위해 다른 품질을 희생할 수 있으므로, 업무 위험과 의사결정 목적에 맞는 균형을 설명해야 한다.

4. 성능 지표와 분석 결과 해석

프로세스 분석은 흐름의 모양뿐 아니라 시간·빈도·자원·결과를 함께 다룬다. 리드타임은 사례의 시작과 완료 사이의 경과 시간이고, 활동시간은 활동 자체의 수행 시간이며, 대기시간은 활동 사이의 지연을 나타낸다. 시스템이 기록한 완료 시각이 실제 작업 종료를 의미하지 않을 수 있으므로 지표 정의와 산식은 현업과 합의한다.

측정 관점 대표 측정값 활용 질문
흐름 경로 빈도, 변형 수, 재작업 횟수 어떤 경로가 표준이며 예외는 어디서 생기는가?
시간 사례 리드타임, 활동시간, 대기시간, 분위수 지연을 만드는 활동·대기 구간은 무엇인가?
자원 담당자별 건수, 핸드오프, 업무 집중도 업무가 특정 역할이나 팀에 과도하게 몰리는가?
규정 편차 사례, 미승인 우회, 필수 단계 누락 필수 통제가 실제 실행에 반영되는가?
결과 반려·취소·재작업률, 완료 결과 경로와 결과 사이에 어떤 관계가 있는가?

평균만 보면 소수의 매우 긴 사례가 가려질 수 있으므로 중앙값과 상위 분위수를 함께 본다. 활동 사이의 대기시간은 담당자 부재, 승인 정책, 시스템 큐, 외부 기관 의존 등 서로 다른 원인에서 생길 수 있다. 관찰된 상관관계를 인과관계로 오해하지 말고, 개선 실험이나 현업 조사로 원인을 검증한다.

5. 사례: 전자상거래 주문 승인

다음은 실제 기업의 실적을 주장하는 사례가 아니라, 분석 절차를 설명하기 위한 가상 시나리오다. 전자상거래 사업자가 주문 접수부터 출고까지의 리드타임을 줄이고, 고위험 주문의 승인 통제를 확인한다고 가정한다. 로그에는 주문번호, 접수·결제·위험심사·승인·출고 이벤트, 시각, 위험등급, 채널이 포함된다.

프로세스 발견 결과, 일반 주문은 접수→결제→출고로 진행되고 일부 고위험 주문은 수동 심사와 추가 승인 단계를 거친다고 확인한다. 적합성 검사는 승인 기준보다 낮은 권한의 사용자가 고위험 주문을 승인한 사례와, 외부 결제 지연 때문에 순서가 바뀐 사례를 분리한다. 성능 분석은 주문 접수부터 출고까지 전체 경과 시간뿐 아니라 심사 큐와 승인 대기 구간을 별도로 비교한다.

팀은 편차 사례를 즉시 제재하지 않고 주문 위험등급, 승인 권한, 시스템 예외, 기록 누락 여부를 조사한다. 확인된 원인이 승인 업무의 단순 인력 부족이라면 교대·배정 정책을 바꾸고, 규칙 해석의 혼선이라면 권한표와 시스템 검증을 개선한다. 개선 뒤에는 리드타임과 필수 승인 누락률을 함께 감시해 속도 향상이 통제 약화로 이어지지 않는지 확인한다.

이 사례의 핵심은 단일 최적화 지표를 추구하지 않는 것이다. 출고 시간을 줄이는 과정에서 사기 방지 절차를 생략하면 매출 손실과 고객 피해가 커질 수 있다. 따라서 비용·속도·고객 경험·규정 준수를 함께 평가하는 균형 지표가 필요하다.

6. 유사 기법과 비교

업무 인터뷰·BPMN 모델링은 이해관계자의 지식과 목표 절차를 명확히 하지만, 실제 빈도나 예외의 분포를 직접 보여 주지 못할 수 있다. 프로세스 마이닝은 로그 기반 현황을 정량적으로 드러내지만, 기록되지 않은 업무와 암묵지를 자동으로 복구하지 못한다. 따라서 인터뷰는 모델의 의미를 해석하고, 로그 분석은 실행 근거를 검증하는 상호보완 관계가 적절하다.

일반 데이터 마이닝은 분류·군집·회귀 등 데이터 패턴을 찾는 데 초점을 둔다. 프로세스 마이닝은 사례의 활동 순서와 흐름을 중심으로 분석하며, 데이터 마이닝·BPM·프로세스 모델링을 연결한다. BI 대시보드가 결과 지표를 집계하는 데 강점이 있다면, 프로세스 마이닝은 결과가 만들어진 실행 경로와 편차를 드러내는 데 초점을 둔다.

구분 업무 모델링·인터뷰 프로세스 마이닝 일반 데이터 마이닝·BI
주요 근거 전문가 지식·설계 기준 이벤트 로그·실제 실행 정형화 데이터·지표
시간 순서 모델에 따라 표현 사례별 이벤트 순서가 핵심 분석 목적에 따라 선택
강점 목표·책임·규칙을 명확히 함 실제 경로와 편차를 대규모로 확인 예측·집계·패턴 탐색
제약 기억 편향·예외 누락 로그 품질과 사례 연결에 의존 업무 흐름의 맥락이 약할 수 있음
보완 역할 To-be와 업무 의미 제시 As-is·적합성·성과 진단 결과 지표·위험 예측 지원

7. 심화: 로그 표준화와 데이터 거버넌스

IEEE 1849-2023 XES는 이벤트 로그와 스트림을 공통 구조로 표현하여 도구 간 상호운용을 지원한다. 표준 포맷은 데이터 교환의 기반이지, 시스템마다 다른 활동 이름·사례 정의·시간 기준을 자동으로 해결하는 만능 변환기는 아니다. 조직은 데이터 계약, 활동 사전, 사례 식별 규칙, 시각 기준, 품질 책임자를 함께 관리해야 한다.

프로세스 마이닝은 사용자·직원 행동을 상세히 분석할 수 있어 개인정보와 노동자 감시의 위험을 수반한다. 업무 개선 목적을 명확히 하고, 최소 필요 속성만 사용하며, 개인 식별을 가명처리하고, 목적 외 이용과 보존기간을 제한해야 한다. 자원별 성과 분석을 개인의 징계나 자동 인사평가에 바로 사용하는 것은 편향·맥락 누락·설명 불가능성을 일으킬 수 있다.

8. 고려사항 및 시사점

8.1 업무 경계와 사례 식별의 합의

분석 착수 전에 프로세스 시작·종료, 사례 단위, 재오픈, 취소, 분할·병합 기준을 업무 책임자와 합의한다. 사례 경계가 달라지면 경로 수와 리드타임이 달라지므로, 이를 메타데이터와 분석 버전에 기록한다.

8.2 이벤트 데이터 품질과 시간 정합성

필수 이벤트의 누락, 중복, 활동 코드 불일치, 시간대 오류가 모델과 지표를 어떻게 왜곡하는지 검증한다. 추출·변환 규칙, 품질 검사 결과, 제외 사례 목록을 보존하여 분석 결과의 재현성을 확보한다.

8.3 개인정보와 목적 제한

개인 식별 정보와 자유기술문은 원칙적으로 제거하거나 가명처리하고, 역할 기반 접근통제와 감사 로그를 적용한다. 수집 목적과 다른 인사평가·감시로 분석을 전용하지 않도록 법무·보안·노무·개인정보 담당자가 검토한다.

8.4 모델 복잡도와 설명 가능성

모델이 로그를 모두 설명하도록 복잡도를 높이면 현업이 이해할 수 없고, 단순화하면 희귀하지만 중요한 위험경로를 숨길 수 있다. 업무 위험도별 필터와 상세화 수준을 분리하고, 모델의 가정·제외 기준·품질 지표를 함께 공개한다.

8.5 개선의 효과와 부작용 측정

개선 전후 비교에서는 업무량·계절성·시스템 변경을 고려하고, 가능한 경우 단계적 적용이나 대조군을 이용한다. 리드타임과 비용만이 아니라 오류율·고객불만·규정 위반·직원 부담을 함께 측정해 지표 최적화의 부작용을 막는다.

8.6 지속 운영과 책임 체계

프로세스 정의가 바뀌면 활동 사전, 로그 매핑, 기준 모델, 규칙을 함께 갱신하는 변경관리가 필요하다. 업무 소유자, 데이터 엔지니어, 보안·감사 담당자, 프로세스 분석가의 책임을 정하고, 발견부터 승인된 개선과 재측정까지 닫힌 운영 루프를 유지한다.

참고자료

  1. IEEE Task Force on Process Mining, Process Mining Manifesto: https://www.tf-pm.org/resources/manifesto
  2. IEEE Standards Association, IEEE 1849-2023: Standard for eXtensible Event Stream (XES): https://standards.ieee.org/ieee/1849/10907/
  3. Wil M. P. van der Aalst, Process Mining, Communications of the ACM: https://cacm.acm.org/research/process-mining/
  4. Process Intelligence Solutions, PM4Py: https://processintelligence.solutions/pm4py/
  5. Leemans, Fahland, and van der Aalst, Scalable process discovery and conformance checking: https://link.springer.com/article/10.1007/s10270-016-0545-x

한 줄 요약: 프로세스 마이닝은 이벤트 로그로 실제 업무 흐름을 발견·검증·개선하되, 로그 품질·업무 맥락·개인정보·성과 통제를 함께 설계해야 한다.