Process mining 이벤트 로그 만들기: 구축 방법

process mining 이벤트 로그는 케이스 ID별로 묶은 타임스탬프 포함 액티비티를 하나의 표로 정리하는 데서 시작합니다. 이 안내서에서는 가상의 레스토랑 주문 프로세스를 예로 들어 시스템 데이터로 표를 만드는 방법을 설명합니다. Excel에서 몇 개 행을 직접 정리하는 방법과 UNION ALL를 사용해 액티비티를 하나로 합치는 SQL 쿼리를 모두 소개합니다. 작업하면서 완성된 예제 로그와 비교해 보세요.

process mining 이벤트 로그: 필요한 세 가지 열

이벤트 로그는 프로세스에서 발생한 일을 구조화해 기록한 데이터입니다. 각 행은 주문 접수나 결제 완료와 같은 이벤트 하나를 나타냅니다. 케이스 ID는 관련 이벤트를 연결하고 타임스탬프는 각 이벤트가 발생한 시점을 표시합니다. 이 두 정보와 액티비티를 활용하면 도구에서 케이스가 프로세스를 어떻게 거치는지 재구성할 수 있습니다.

액티비티는 유형이고 이벤트는 실제 발생 건입니다. 액티비티는 ‘주문 발송’과 같은 작업의 유형입니다. 이벤트는 그 작업이 실제로 발생한 한 건을 뜻합니다. 예를 들어 주문 12345가 1월 15일 오후 2시 30분에 발송된 경우입니다. 로그에는 이벤트가 기록되고, 각 이벤트에는 액티비티 이름이 포함됩니다. 두 용어를 같은 의미로 쓰기도 하지만 데이터 준비 단계에서는 구분이 중요합니다. 액티비티는 어떤 일이 있었는지를, 이벤트는 해당 케이스에서 그 일이 언제 발생했는지를 나타냅니다.

기본적인 process mining 이벤트 로그에는 다음 세 열이 필요합니다.

다음 단계로 넘어가기 전에 세 필드를 확인하세요.

이 세 필드가 기본이며, 하나라도 누락되거나 일관되지 않으면 프로세스 보기에 실제 업무 순서가 잘못 나타납니다. 나머지 필드는 선택 사항입니다. process mining 도구가 읽을 수 있는 이벤트 로그는 케이스와 이벤트를 담은 하나의 표이며, 비즈니스 프로세스 분석에 사용할 이벤트 로그의 필수 열은 언제나 같습니다. 지원 형식과 데이터 준비 단계는 process mining 데이터 문서에서 확인하세요.

예제로 살펴보기: 피자 팰리스 주문 시스템

단계를 구체적으로 설명하기 위해 피자 팰리스라는 가상의 레스토랑을 예로 들겠습니다. 고객은 온라인으로 주문하고, 직원은 음식을 준비하며, 배달 기사는 주문을 배달합니다. 이 예제에는 고객 데이터가 포함되어 있지 않습니다.

시스템에 다음과 같은 테이블이 저장되어 있다고 가정해 보겠습니다.

• orders: 주문 ID, 고객, 주문 시각
• order_items: 주문별 피자, 사이드 메뉴, 음료
• kitchen_queue: 주문이 주방에 들어오고 나간 시각
• delivery_assignments: 배달 기사 배정 및 배달 추적 정보
• payments: 결제 처리 기록

목표는 주문 접수부터 배달 완료까지 각 주문을 추적하는 이벤트 로그 하나를 만드는 것입니다. 주문 ID를 케이스 ID로 사용하고, 관련 타임스탬프와 액티비티를 각각 한 행으로 기록합니다. process mining 이벤트 로그 예시인 피자 팰리스 예제 로그를 다운로드하고, 열 구성을 직접 추출한 데이터와 비교해 보세요.

데이터를 추출하기 전에 포함할 액티비티를 정하세요. 피자 팰리스의 주문 처리 과정은 다음 여섯 단계로 구성됩니다.

1. 주문 접수: 고객이 주문을 제출합니다.
2. 결제 완료: 결제가 정상적으로 처리됩니다.
3. 주방 전달: 주문이 조리 대기열에 들어갑니다.
4. 조리 완료: 주방에서 주문 준비가 끝났다고 표시합니다.
5. 배달 기사 배정: 배달 기사가 지정됩니다.
6. 배달 완료: 주문이 고객에게 전달됩니다.

각 액티비티의 원본 테이블, 타임스탬프 필드, 케이스 ID 필드를 확인하세요. 케이스 ID가 이벤트를 올바른 주문에 연결하는지도 검증해야 합니다.

직접 기록된 이벤트와 추론한 이벤트를 구분하세요. 직접 기록된 이벤트는 원본 시스템에 명시적인 기록과 타임스탬프가 있습니다. 주문 접수는 orders 행의 타임스탬프에서, 결제 완료는 payments에서, 배달 완료는 delivery_assignments에서 가져옵니다. 타임스탬프가 분석하려는 이벤트의 발생 시점을 나타낸다면 일반적으로 간단히 추출할 수 있습니다.

추론한 이벤트는 자체 기록이 없으므로 다른 필드에서 발생 시점을 추정합니다. 배달 기사 배정은 배달 배정 정보가 생성된 시각만 기록되어 있을 수 있고, 조리 완료는 주방 대기열 상태가 ‘완료’로 바뀐 시점만 확인할 수 있습니다. 추론한 이벤트도 유용하지만, 어떤 방식으로 추정했는지 문서화하세요. 상태 변경 시각이나 기록 생성 시각이 액티비티 이름이 뜻하는 시점과 정확히 일치하지 않을 수 있습니다. 이벤트 타임스탬프로 사용하기 전에 원본 시스템을 잘 아는 사람에게 필드의 의미를 확인하세요.

이 매핑은 계획일 뿐, 모든 필드가 적합하다는 증거는 아닙니다. 타임스탬프가 채워져 있는지, 각 테이블을 주문 ID와 조인할 때 중복 행이 생기지 않는지 확인하세요.

케이스 및 이벤트 속성

속성을 추가하면 분석에 필요한 맥락을 확인할 수 있습니다. 케이스 ID, 타임스탬프, 액티비티 외의 열을 뜻하며, 의미가 명확하고 올바른 케이스나 이벤트에 연결할 수 있는 경우에만 추가하는 것이 좋습니다.

케이스 속성은 케이스 전체에 대한 정보이며, 일반적으로 해당 케이스의 이벤트마다 값이 같습니다. 고객 이름, 주문 총액, 배달 주소, 주문한 품목 수 등이 이에 해당합니다. 평면 이벤트 로그에서는 같은 케이스의 각 행에 값을 반복해 기록합니다. 그래야 나중에 케이스 수준의 정보를 기준으로 이벤트를 필터링하거나 비교할 수 있습니다.

이벤트 속성은 이벤트 하나에 대한 정보입니다. 배달 이벤트의 배달 기사, 결제 이벤트의 결제 수단, 주방 이벤트의 조리 구역이 그 예입니다. 이런 열은 모든 행에 적용되지 않으므로 해당하지 않는 행은 비워 두되, 모든 행의 구조가 같도록 열은 유지하세요.

완성된 이벤트 로그는 이벤트 하나를 한 행에 기록한 평면 테이블 하나로 구성해야 합니다. 다음은 피자 팰리스 로그 예시입니다.

같은 케이스에 속한 각 이벤트 행에 고객과 주문 금액이 반복됩니다. 이는 의도된 구성입니다. 이렇게 해야 process mining 도구가 읽을 수 있는 단순한 테이블 형식으로 로그를 유지할 수 있습니다.

방법 1: Excel에서 만들기

Excel은 소량의 데이터를 추출하거나 처음 연습할 때 적합합니다. 이벤트 유형별로 데이터를 내보내고 열 구성을 통일한 다음, 행을 하나의 시트에 합치세요. 아래 다섯 단계는 피자 팰리스 데이터 기준으로 약 1시간이 걸립니다.

1단계: 이벤트 유형별로 별도의 시트에 내보냅니다. 액티비티 유형마다 워크시트를 하나씩 만드세요. 예를 들면 다음과 같습니다.

시트 1: 주문 접수

시트 2: 결제 완료

같은 방법으로 주방 이벤트와 배달 이벤트 시트도 만드세요.

2단계: 열 구성을 통일합니다. 모든 시트에서 열 이름과 순서를 같게 하고, 해당하지 않는 속성은 빈 열로 추가하세요. 예를 들어 주문 접수 시트에도 전체 열을 넣을 수 있습니다.

값의 형식이 서로 호환되는지 확인하세요. 특히 타임스탬프가 날짜와 시간으로 저장되어 있는지, 타임스탬프처럼 보이는 텍스트로만 저장되어 있지는 않은지 확인해야 합니다.

3단계: 시트를 하나로 합칩니다. 새 시트의 이름을 이벤트 로그로 지정하고, 각 활동 시트의 이벤트 행을 복사해 한곳에 모읍니다. 머리글은 하나만 두고 행마다 이벤트 하나를 기록합니다.

4단계: 케이스와 타임스탬프를 기준으로 정렬합니다. 결합한 데이터를 Case ID 오름차순으로 정렬한 다음 Timestamp 오름차순으로 정렬합니다. 각 케이스의 이벤트 순서를 확인하기 쉽습니다. 정렬해도 부정확한 타임스탬프가 바로잡히지는 않으므로, 순서에 의존하기 전에 시간이 같거나 예상과 다른 이벤트가 있는지 확인합니다.

5단계: CSV로 내보냅니다. 결합한 시트를 도구에서 읽을 수 있는 process mining 이벤트 로그 CSV로 저장합니다. 내보낸 파일을 한 번 열어 헤더, 구분 기호, 날짜 형식, 빈 값이 예상대로 표시되는지 확인합니다.

Excel 사용 팁:

• VLOOKUP 또는 XLOOKUP을 사용해 주문 시트에서 고객 이름과 같은 케이스 속성을 가져옵니다.
• YYYY-MM-DD HH:MM:SS와 같이 날짜와 시간 형식을 일관되게 사용합니다.
• 내보내기 전에 중복 행이 있는지 확인합니다.
• 수정 내역을 추적할 수 있도록 원본 추출 데이터는 변경하지 않은 상태로 보관합니다.

방법 2: SQL로 만들기

데이터가 데이터베이스에 있거나 추출량이 많거나 다음 달에도 같은 추출 작업을 반복해야 한다면 SQL을 사용하는 편이 좋습니다. 일반적으로 각 활동별 SELECT을 만들고 UNION ALL로 쌓아 올립니다.

UNION ALL의 작동 방식 여러 SELECT 문이 반환한 행을 차례로 쌓습니다. 각 문은 열의 수와 순서가 같아야 하고, 데이터 유형이 서로 호환되어야 합니다. 또한 별칭을 일관되게 지정해 최종 열 이름을 명확히 해야 합니다.

쿼리 아래 예시는 가상의 Pizza Palace 테이블을 사용합니다. 적용하기 전에 실제 테이블 및 필드 이름, 타임스탬프의 의미, SQL 방언을 확인하세요.

-- Event Log Extraction for Pizza Palace
-- This query combines multiple event types into a single event log
-- Each SELECT block represents one activity type

-- Event 1: Order Placed
-- Source: orders table
-- This captures when customers submit their orders
SELECT 
    o.id AS case_id,                          -- The order ID is our case identifier
    o.created_at AS timestamp,                -- When the order was placed
    'Order Placed' AS activity,               -- The activity name (hardcoded)
    o.customer_name AS customer,              -- Case attribute: who ordered
    o.total_amount AS order_value,            -- Case attribute: order value
    NULL AS driver,                           -- Not applicable for this event
    NULL AS payment_method                    -- Not applicable for this event
FROM orders o
WHERE o.created_at >= '2025-01-01'            -- Filter to your desired date range

UNION ALL

-- Event 2: Payment Received
-- Source: payments table
-- This captures successful payment processing
SELECT 
    p.order_id AS case_id,
    p.payment_time AS timestamp,
    'Payment Received' AS activity,
    o.customer_name AS customer,              -- Join to get case attributes
    o.total_amount AS order_value,
    NULL AS driver,
    p.payment_method AS payment_method        -- Event-specific attribute
FROM payments p
JOIN orders o ON p.order_id = o.id            -- Join to get order details
WHERE p.payment_time >= '2025-01-01'
  AND p.status = 'successful'                 -- Only include successful payments

UNION ALL

-- Event 3: Order Sent to Kitchen
-- Source: kitchen_queue table
-- This captures when the kitchen starts working on the order
SELECT 
    k.order_id AS case_id,
    k.queue_entry_time AS timestamp,
    'Order Sent to Kitchen' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.queue_entry_time >= '2025-01-01'

UNION ALL

-- Event 4: Order Ready
-- Source: kitchen_queue table (different timestamp field)
-- This is an inferred event based on when the kitchen marked it complete
SELECT 
    k.order_id AS case_id,
    k.completed_time AS timestamp,            -- Different timestamp than entry
    'Order Ready' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    NULL AS driver,
    NULL AS payment_method
FROM kitchen_queue k
JOIN orders o ON k.order_id = o.id
WHERE k.completed_time >= '2025-01-01'
  AND k.completed_time IS NOT NULL            -- Only include completed orders

UNION ALL

-- Event 5: Assigned to Driver
-- Source: delivery_assignments table
-- This captures when a driver is assigned to deliver the order
SELECT 
    d.order_id AS case_id,
    d.assigned_at AS timestamp,
    'Assigned to Driver' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,                  -- Event-specific attribute
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.assigned_at >= '2025-01-01'

UNION ALL

-- Event 6: Delivery Completed
-- Source: delivery_assignments table (different timestamp field)
-- This captures when the order was delivered to the customer
SELECT 
    d.order_id AS case_id,
    d.delivered_at AS timestamp,
    'Delivery Completed' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_assignments d
JOIN orders o ON d.order_id = o.id
WHERE d.delivered_at >= '2025-01-01'
  AND d.delivered_at IS NOT NULL              -- Only include completed deliveries

-- Final ordering: by case, then by time
-- This makes the event log easy to read and follow
ORDER BY case_id, timestamp;

쿼리는 주문 ID를 케이스 ID로 사용하고 각 활동에 동일한 7개 열을 반환합니다. 속성이 적용되지 않는 경우에도 열 구조를 유지하기 위해 NULL 값을 사용합니다. 날짜 필터와 결제 완료 조건은 예시일 뿐입니다. 분석할 프로세스와 기간에 맞는 필터를 선택하세요.

쿼리 확장하기 활동을 추가하려면 다음과 같이 합니다.

1. SELECT 블록을 복사해 시작점으로 사용합니다.
2. 이벤트가 기록된 원본 테이블을 사용합니다.
3. 타임스탬프를 나타내는 필드를 선택합니다.
4. 다른 행과 일관된 활동 이름을 지정합니다.
5. 케이스 ID와 관련 속성을 포함합니다.
6. 분석 목적에 맞는 필터를 추가합니다.

예를 들어 시스템에 관련 테이블과 필드가 있다면 배송 시도 이벤트를 다음과 같이 추가할 수 있습니다.

UNION ALL

-- Event 7: Delivery Attempted
-- Add this to track failed delivery attempts
SELECT 
    d.order_id AS case_id,
    d.attempt_time AS timestamp,
    'Delivery Attempted' AS activity,
    o.customer_name AS customer,
    o.total_amount AS order_value,
    d.driver_name AS driver,
    NULL AS payment_method
FROM delivery_attempts d
JOIN orders o ON d.order_id = o.id
WHERE d.attempt_time >= '2025-01-01'

로그 분석 전 확인 사항

로그를 분석하기 전에 다음 항목을 확인합니다. 이 점검은 중복, 누락된 타임스탬프, 일관되지 않은 케이스 ID, 활동으로 잘못 해석된 상태 필드 등 process mining 결과를 오도할 수 있는 대표적인 이벤트 로그 문제를 다룹니다.

1. 필수 열부터 시작합니다. 이벤트나 속성을 더 추가하기 전에 케이스 ID, 타임스탬프, 활동으로 구성된 간단한 로그를 만듭니다.
2. 일관된 케이스 ID를 사용합니다. 같은 케이스의 모든 이벤트에 동일한 식별자를 사용해야 합니다. 프로세스 진행 중 값이 바뀌는 항목은 사용하지 않습니다.
3. 활동 이름을 일관되게 유지합니다. “주문 접수”처럼 하나의 이름을 정하고 “주문 생성”, “신규 주문”과 섞어 쓰지 않습니다.
4. 타임스탬프를 확인합니다. 이벤트가 발생한 시점을 나타내는지, 시간대가 일관적인지, 날짜와 시간 기준으로 정렬할 수 있는지 확인합니다.
5. 중복과 누락된 값을 검토합니다. 반복 이벤트와 케이스 ID, 타임스탬프 또는 활동이 누락된 행을 확인합니다.
6. 추출 과정을 문서화합니다. 소스 테이블, 필드, 필터, 추출 날짜, 전제 조건을 기록합니다. 이렇게 하면 로그를 더 쉽게 업데이트하고 문제를 해결할 수 있습니다.
7. 속성은 신중하게 추가합니다. 질문에 답하는 데 도움이 되는 필드를 포함하고, 조인으로 이벤트 행이 늘어나지 않는지 확인합니다.

중복 이벤트부터 누락된 케이스 ID까지 흔히 발생하는 데이터 문제 7가지는 이 페이지 마지막 FAQ에서 각각 해결 방법을 확인할 수 있습니다. 반복 추출 작업은 process mining을 위한 ETL에서 다룹니다.

데이터가 없을 때 해야 할 일

이벤트 로그를 준비하는 데 미리 구축된 커넥터가 꼭 필요한 것은 아닙니다. 먼저 시스템에서 어떤 데이터를 내보낼 수 있는지, 필수 필드 3개를 받을 수 있는지 확인합니다.

1. 분석할 프로세스와 추적할 케이스 ID를 정합니다.
2. 시스템에서 이벤트 이력, 감사 기록 또는 타임스탬프가 포함된 상태 변경 내역을 내보낼 수 있는지 확인합니다.
3. 데이터 템플릿을 사용해 사용 가능한 필드를 케이스 ID, 타임스탬프, 활동에 매핑합니다.
4. 바로 사용할 수 있는 이벤트 테이블을 내보낼 수 없다면 데이터 팀에 이벤트마다 한 행이 있는 데이터베이스 추출본이나 보고서를 요청합니다.

시스템에서 내보낸 데이터는 여러 테이블로 나뉘거나 같은 필드가 서로 다른 이름으로 표시될 수 있습니다. 각 필드의 의미를 보존하고 원본을 추적할 수 있다면 Excel이나 SQL에서 데이터를 결합하고 이름을 바꿀 수 있습니다. process mining 데이터 출처에서는 활용 가능한 원본 데이터가 있는 다른 위치를 살펴봅니다. 프로세스 개선 가이드에는 시스템별 데이터 템플릿이 포함되어 있어 1~3단계를 이미 수행한 상태로 시작할 수 있습니다.

형식을 비교할 다른 process mining 이벤트 로그 예시가 필요하다면 예제 로그 파일 및 템플릿 모음에서 바로 사용할 수 있는 스프레드시트를 확인하세요. 이벤트 로그 템플릿 페이지에는 필수 열과 선택 열이 정리되어 있습니다. 첫 번째 데이터 세트를 불러오는 방법은 첫 데이터 세트 불러오기를 참조하세요.

작성한 로그 불러오기

로그가 준비되면 파일을 불러와 필수 열 3개를 매핑합니다. ProcessMind는 Excel, CSV, 데이터베이스 추출 파일을 바로 읽을 수 있습니다.

1. 파일을 업로드하거나 데이터베이스 추출본을 선택합니다.
2. 케이스 ID, 타임스탬프, 활동 열을 매핑합니다.
3. 추가 속성을 검토합니다.
4. 프로세스 뷰를 생성하고 케이스와 이벤트 순서가 타당한지 확인합니다.

ProcessMind에서 데이터 세트 열을 활동, 케이스, 속성 역할에 매핑한 화면

프로세스 뷰를 통해 누락된 활동, 예상과 다른 순서, 추가 조사가 필요한 영역을 찾을 수 있습니다. 하지만 원본 데이터를 수정하거나 실제 업무 수행 방식을 바꾸지는 않습니다. 첫 결과에서 데이터 문제가 발견되면 추출 데이터를 수정한 뒤 다시 불러오세요. 첫 데이터 세트 불러오기에서 업로드와 매핑 방법을 자세히 설명합니다.

방금 작성한 로그 불러오기