Process mining용 ETL 도구: 필요한 기능

process mining에 ETL이 필요할까요?

ETL 도구는 원천 시스템에서 데이터를 추출하고, 분석에 적합한 형태로 변환한 뒤 불러옵니다. 이 글에서는 process mining 프로젝트에 실제로 필요한 ETL 작업과 생략할 수 있는 작업을 살펴봅니다. 파이프라인 구매 가이드는 아닙니다. 한 시스템에서 기록을 내보낼 수 있고 파일에 케이스 ID, 활동, 타임스탬프가 있다면 첫 분석에서는 파이프라인을 건너뛰고 내보낸 데이터를 그대로 불러와도 됩니다.

필요한 작업은 프로세스와 관련 시스템, 분석 데이터를 얼마나 자주 갱신해야 하는지에 따라 달라집니다. 질문에 답할 수 있는 최소한의 데이터를 먼저 추출하고, 첫 분석에서 필요성이 확인되면 데이터 준비와 자동화를 추가하세요.

다음 세 가지 상황에서는 ETL 작업이 필요합니다.

• 프로세스가 여러 시스템에 걸쳐 있습니다. 한 케이스를 처음부터 끝까지 추적하려면 기록을 결합하고 식별자를 맞춰야 합니다.
• 원본 데이터를 그대로 읽을 수 없습니다. 분석에 사용하기 전에 활동 이름, 타임스탬프 또는 케이스 식별자를 표준화해야 합니다.
• 데이터를 반복해서 추출해야 합니다. 데이터가 매일 바뀌고 분석에도 이를 반영해야 한다면 수동 내보내기는 더 이상 실용적이지 않습니다.

이런 상황은 데이터를 준비해야 할 이유이지, 첫 질문에 답하기도 전에 파이프라인을 구축해야 할 이유는 아닙니다. 확보할 수 있는 데이터를 불러와 부족한 부분을 확인한 다음 결정하세요.

다음과 같은 경우에는 별도의 파이프라인을 생략할 수 있습니다.

• 프로세스 기록이 주로 한 시스템에 있습니다.
• 관련 기록을 내보낼 수 있습니다.
• 내보낸 파일에 케이스 ID, 활동, 타임스탬프가 있습니다.
• 파일이 작아 수동으로 준비할 수 있습니다.
• 데이터가 질문에 답할 수 있는지 아직 확인 중입니다.

스프레드시트에서 열 이름을 바꾸고, 명백한 불일치를 수정하고, 불필요한 필드를 제거해도 됩니다. 수동 준비를 계속해야 하는 것은 아닙니다. 분석의 효용이 확인되고 데이터를 자주 갱신해야 한다면 반복 작업을 자동화하세요.

추출 데이터에 포함해야 할 항목

process mining용 이벤트 로그에는 세 가지 필드와 이벤트당 한 행이 필요합니다.

비용, 사용자, 팀, 고객 세그먼트, CO2 배출량 등의 속성은 선택 사항입니다. 하지만 이런 속성이 있어야 단순한 프로세스 보기에서 분석으로 나아갈 수 있습니다. 보존하는 속성은 각각 필터, 구분 기준 또는 측정값으로 활용됩니다. 각 필드의 활용 방법은 데이터셋 속성 참고 자료에서 확인할 수 있습니다.

원천에 필드가 있어도 실제로 사용할 수 없는 경우가 있습니다. 시스템마다 케이스 ID가 다르면 이벤트를 연결할 수 없습니다. 활동 이름이 일관되지 않으면 실제로는 같은 단계가 세 가지로 나뉩니다. 타임스탬프가 텍스트로 저장되면 이벤트 순서가 틀릴 수 있습니다. 데이터를 매핑하기 전에 내보낸 파일을 살펴보고 필수 필드 세 가지를 먼저 확인하세요. 이벤트 로그에 필요한 항목은 process mining에 필요한 데이터에서 자세히 확인할 수 있습니다.

최소한의 이벤트 로그를 만드는 쿼리

원천에 활동별로 한 행씩 저장되어 있다면 SELECT 쿼리로 추출할 수 있습니다. 다음 예시는 케이스, 활동, 이벤트 시각이 포함된 process_events 테이블을 가정합니다.

SELECT
  case_id        AS case_id,
  activity_name  AS activity,
  event_time     AS timestamp
FROM process_events
WHERE case_id IS NOT NULL
  AND activity_name IS NOT NULL
  AND event_time IS NOT NULL
ORDER BY case_id, event_time;

이 쿼리는 세 필드에 이름을 붙이고, 사용할 수 없는 행을 제외한 뒤 케이스별로 이벤트를 정렬합니다. 원천에 맞게 테이블과 열 이름을 바꾸고, 데이터를 불러오기 전에 일부 케이스를 확인하세요. 각 케이스에 예상한 이벤트가 포함되어 있고, 실제 업무 담당자가 이해하는 순서로 정렬되어야 합니다.

어떤 변환 작업이 필요한가요?

분석 결과를 왜곡할 수 있는 부분을 바로잡는 것이 데이터 변환의 목적입니다. 대부분의 경우 다음 네 가지 작업이면 충분합니다.

1. 이벤트 형식 정리

   원천에서 프로세스 단계가 별도 열에 저장되어 있더라도, 활동이 발생할 때마다 케이스 ID와 타임스탬프를 포함해 한 행으로 정리합니다.

2. 타임스탬프를 사용할 수 있는 형태로 정리

   값이 실제 날짜와 시간인지, 현지 시간인지 UTC인지 확인합니다. 원천을 결합한다면 시간대를 맞추세요. 그렇지 않으면 이벤트 순서가 실제와 달라집니다.

3. 활동 이름 표준화

   실제 단계마다 하나의 이름을 사용하고, 언어와 표기를 통일합니다. 목록을 짧게 만들려고 비슷해 보이는 단계를 합치지 마세요.

4. 필요한 경우에만 원천 결합

   기록을 연결하는 키를 찾아 일치 여부를 확인합니다. 조인으로 이벤트가 중복되거나 케이스가 누락되면 프로세스 보기가 달라지므로, 조인 전후의 기록 수를 비교하세요.

내보낸 데이터에 이벤트별 한 행과 필드 세 가지가 이미 갖춰져 있다면 변환할 필요가 없습니다. 이는 지름길이 아니라 일반적인 경우입니다. process mining 이벤트 로그 만들기에서 Excel과 SQL 예시를 통해 같은 내용을 설명합니다.

이벤트 로그는 어디에 불러와야 할까요?

준비한 데이터를 분석할 플랫폼에 불러오세요. 처음 살펴볼 때는 파일 하나면 충분합니다. 데이터를 준비하고 불러온 뒤 프로세스 보기를 확인하고, 데이터가 뒷받침하는 내용을 파악한 다음 추출 범위를 조정하세요. process mining만을 위해 새로운 저장소 계층을 만들 필요는 없습니다. 팀에서 이미 데이터 웨어하우스나 데이터 레이크를 운영한다면 데이터는 그곳에 두고 해당 환경에서 생성한 데이터를 불러오세요.

자세한 내용은 지원 데이터 형식 페이지에서 확인할 수 있습니다. 수동 업로드를 원하지 않는 경우, 예약 작업을 통해 같은 형식의 데이터를 data API로 전송할 수도 있습니다.

불러온 데이터셋은 모델에 연결됩니다. 패널에서 해당 데이터셋의 케이스 수와 아직 매핑되지 않은 활동을 확인할 수 있습니다. Source: ProcessMind

어떤 방법을 선택하든 데이터는 분석이 이루어지는 곳에 불러와야 합니다. 아무도 확인하지 않는 폴더에 파일을 넣어 두는 것은 데이터 전략이 아닙니다. 데이터셋을 매핑하고 검토해야 합니다.

process mining에는 어떤 ETL 도구가 적합할까요?

모든 프로젝트에 맞는 ETL 도구 목록은 없습니다. 데이터가 저장된 위치, 팀에서 이미 사용하는 도구, 로그에 필요한 데이터 준비 수준을 기준으로 선택하세요. 작업 자체는 일반적인 데이터 엔지니어링이며, process mining에 필요한 조건은 결과에 케이스 ID, 활동, 타임스탬프가 포함되는 것입니다.

process mining 프로젝트에서 자주 언급되는 도구로는 데이터 추출과 SQL 변환을 위한 CData와 dbt, 데이터 웨어하우스용 BigQuery, Snowflake, Databricks, 시스템 간 데이터 이동이 주요 과제일 때 사용하는 Talend, Apache NiFi, Airbyte 등이 있습니다. 오픈 소스도 충분히 고려할 수 있으며, 보통 NiFi와 Airbyte부터 검토합니다. Evidant와 Konekti 등 일부 공급업체는 일반적인 시스템에 사용할 템플릿을 포함한 process mining용 ETL을 판매합니다.

위 도구는 예시일 뿐 추천이나 제휴를 의미하지 않습니다. 프로젝트가 끝난 뒤에도 팀에서 유지 관리할 수 있는 도구와 형식을 선택하고, 가능하면 변환 로직을 process mining 제품 외부에 두세요. 내장 ETL은 특히 신중하게 검토해야 합니다. 해당 플랫폼을 사용하는 동안에는 편리하지만, 준비한 데이터를 다른 분석이나 AI 프로젝트에서 재사용하기 어려워질 수 있습니다.

데이터를 불러온 뒤에는 어떻게 관리해야 할까요?

추출은 작업의 절반입니다. 이후 데이터셋을 어떻게 관리하느냐에 따라 한 분기가 지난 뒤에도 분석 결과를 신뢰할 수 있는지가 달라집니다.

• 내용을 알 수 있는 이름을 데이터셋에 지정합니다. Q1_2025_Sales_Data 또는 Customer_Support_Logs는 export_final_v3보다 낫습니다.
• 용도에 맞는 형식을 선택합니다. 수동으로 올리는 작은 파일에는 CSV나 Excel이면 충분합니다. 대용량 데이터셋이나 파이프라인에서 생성하는 데이터에는 Parquet 또는 ORC가 적합합니다.
• 매핑 전에 미리 봅니다. 구조와 열 유형, 일부 행을 확인하고 데이터셋 설정에서 케이스 ID, 활동, 타임스탬프를 지정했는지 확인합니다.
• 활동 매핑을 확인합니다. 자동 매핑으로 첫 작업을 진행한 뒤 매핑되지 않은 활동을 검토합니다. 발생했지만 데이터에 기록되지 않는 단계는 데이터 흐름으로 표시할 수 있습니다. 이렇게 하면 수치에 영향을 주지 않으면서 해당 단계를 보기에 표시할 수 있습니다.
• 다시 만들지 말고 갱신합니다. 정기적으로 내보내는 데이터라면 분석에 필요한 주기, 예를 들어 매일 또는 매주에 맞춰 새 파일로 데이터셋을 교체하고 기존 매핑을 유지합니다.
• 데이터에 포함되지 않은 내용을 기록합니다. 누락된 기간, 시스템, 단계는 분석 메모에 남겨야 합니다. 그래야 최종적으로 어떤 결론을 내릴 수 있는지 판단할 수 있습니다.
• 접근 권한을 관리하고, 사용이 끝난 데이터는 보관합니다. 데이터셋 접근 권한은 필요한 사용자에게만 부여하고, 프로젝트가 끝나 더 이상 사용하지 않는 데이터는 보관 처리합니다.

요약

ETL은 process mining 프로젝트의 목표가 아니라 수단입니다. 첫 분석을 늦추지 않도록 다음과 같이 진행하세요.

• 이번 주에 확보할 수 있는 데이터부터 시작합니다.
• 다른 항목을 제외하더라도 필수 필드 세 가지는 유지합니다.
• 먼저 내보낸 데이터를 불러오고, 분석을 통해 필요성이 확인되면 불러오기 작업을 자동화합니다.
• 팀에서 이미 유지 관리하는 도구와 형식을 사용합니다.

파이프라인이 너무 단순해서보다, 어떤 질문에 답해야 하는지 알기도 전에 파이프라인을 구축해서 프로젝트가 실패하는 경우가 더 많습니다.