기업이 AI 에이전트를 도입할 때 가장 먼저 그리는 그림은 대개 단순합니다. 주문이 들어오면 정보를 확인하고, 승인받고, 출고를 지시하고, 고객에게 알림을 보내는 식입니다. 이 흐름만 보면 에이전트에게 시스템 접근 권한과 몇 가지 도구를 주면 곧바로 자동화할 수 있을 것처럼 보입니다.
하지만 실제 업무는 매뉴얼의 화살표대로 움직이지 않습니다. 긴급 주문은 메신저에서 먼저 승인되고, 재고가 부족하면 담당자가 엑셀로 우회하며, 특정 거래처는 예외 조건 때문에 세 번의 검토를 거칩니다. 시스템에는 완료로 기록됐지만 사람이 이메일로 다시 확인하는 작업도 있습니다. 표준 절차는 하나인데 현실에는 수십 개의 변형이 존재합니다.
이 상태에서 AI 에이전트를 바로 투입하면 비효율을 제거하는 것이 아니라 기존의 우회와 재작업을 더 빠르게 반복할 수 있습니다. 자동화 범위를 정하기 전에 먼저 물어야 할 질문은 “AI가 무엇을 할 수 있는가?”가 아닙니다. “업무가 실제로 어떻게 흘러가고 있는가?”입니다.
프로세스 마이닝(Process Mining)은 이 질문에 이벤트 데이터로 답하는 방법입니다. ERP, CRM, MES, WMS, 그룹웨어처럼 이미 업무를 처리하고 있는 시스템의 기록을 연결해 실제 경로를 복원하고, 병목·반복·규정 이탈·예외를 수치로 보여줍니다. 에이전트 도입을 기술 데모가 아니라 운영 개선 프로젝트로 만들려면 이 지도가 먼저 필요합니다.
프로세스 마이닝은 업무 인터뷰의 디지털 대체재가 아니다
프로세스 마이닝을 “로그로 그리는 업무 흐름도” 정도로 이해하면 활용 범위가 좁아집니다. 핵심은 예쁜 다이어그램이 아니라 실제 실행 기록과 기대 모델의 차이를 계산할 수 있다는 데 있습니다. 일반적으로 다음 세 가지 분석을 함께 사용합니다.
- 프로세스 발견(Process Discovery): 사전에 정답 흐름을 넣지 않고 이벤트 로그에서 실제 경로와 변형을 찾아냅니다.
- 적합성 검사(Conformance Checking): 승인 규칙이나 표준 프로세스와 실제 기록을 비교해 누락, 순서 위반, 우회 실행을 찾습니다.
- 프로세스 향상(Enhancement): 발견된 모델에 대기시간, 비용, 작업자, 오류율 등의 정보를 결합해 개선 지점을 찾습니다.
인터뷰는 여전히 필요합니다. 데이터만으로는 담당자가 왜 우회했는지, 어떤 규정이 현실과 맞지 않는지 알 수 없기 때문입니다. 다만 인터뷰는 기억과 역할에 따라 달라집니다. 프로세스 마이닝은 “원래 이렇게 한다”는 설명과 “실제로 이렇게 했다”는 기록을 나란히 놓아 대화를 구체적으로 만듭니다.
좋은 이벤트 로그를 만드는 최소 조건
전통적인 프로세스 마이닝에서 이벤트 한 건은 최소한 세 가지 정보를 가져야 합니다. 첫째는 같은 업무 건을 묶는 케이스 식별자, 둘째는 수행된 활동, 셋째는 활동이 발생한 시각입니다. 여기에 담당자, 조직, 금액, 설비, 채널, 결과 같은 속성을 붙이면 원인 분석이 가능해집니다.
| 필드 | 예시 | 분석에서 하는 역할 |
|---|---|---|
| 케이스 ID | 주문번호, 작업지시번호, 장애번호 | 한 업무의 시작부터 종료까지 연결 |
| 활동 | 주문 접수, 재고 확인, 승인, 출고 | 업무 단계와 경로 구성 |
| 타임스탬프 | 발생·시작·완료 시각 | 대기시간과 처리시간 계산 |
| 자원 | 담당자, 부서, 시스템, 설비 | 인수인계와 부하 분석 |
| 업무 속성 | 금액, 고객등급, 제품군, 긴급도 | 병목의 조건과 예외 원인 분석 |
현실에서는 이 정보가 한 테이블에 모여 있지 않습니다. 주문은 ERP, 고객 문의는 CRM, 생산 실적은 MES, 배송은 WMS나 운송 시스템, 승인은 그룹웨어에 남습니다. 동일한 고객과 주문을 시스템마다 다른 키로 표현하기도 합니다. 따라서 도구를 고르는 것보다 먼저 업무 객체의 식별 체계와 시간 의미를 합의해야 합니다.
타임스탬프도 주의해야 합니다. 생성 시각, 저장 시각, 실제 발생 시각이 다를 수 있고, 일괄 처리 때문에 수백 건이 같은 시각으로 기록되기도 합니다. 시간대가 섞이거나 완료 이벤트만 남으면 대기시간 계산이 왜곡됩니다. 로그가 있다고 해서 곧바로 사실이 되는 것은 아닙니다. 이벤트의 의미와 생성 조건을 데이터 계약으로 관리해야 합니다.
한 개의 케이스 ID로는 현실을 평평하게 만든다
주문 하나에 여러 품목이 있고, 품목별로 생산 작업과 배송 묶음이 갈라지는 상황을 생각해보겠습니다. 주문번호만 케이스로 잡으면 품목과 배송 이벤트가 뒤섞여 실제로 존재하지 않는 순서가 만들어질 수 있습니다. 반대로 품목번호만 선택하면 주문 단위 승인이나 고객 단위 조건이 사라집니다.
이 문제 때문에 최근에는 객체 중심 프로세스 마이닝(Object-Centric Process Mining)이 중요해지고 있습니다. 이벤트 하나를 주문, 품목, 패키지, 고객, 설비처럼 여러 업무 객체와 연결하는 방식입니다. OCEL 2.0은 이벤트와 객체, 객체 간 관계 및 시간에 따라 변하는 속성을 표현할 수 있는 교환 형식을 정의합니다. 복잡한 제조·물류·서비스 프로세스라면 처음부터 “케이스 하나를 무엇으로 볼 것인가”의 한계를 검토할 필요가 있습니다.
태스크 마이닝과 프로세스 마이닝은 보는 높이가 다르다
두 용어는 자주 섞이지만 관찰 대상이 다릅니다. 태스크 마이닝은 사용자의 화면 클릭, 입력, 복사·붙여넣기처럼 데스크톱에서 반복되는 세부 동작을 봅니다. 프로세스 마이닝은 시스템의 이벤트 로그를 이용해 주문이나 장애 처리처럼 여러 사람과 시스템을 거치는 종단 간 흐름을 봅니다.
예를 들어 프로세스 마이닝이 “견적 승인 후 주문 등록까지 평균 18시간이 걸린다”는 병목을 찾았다면, 태스크 마이닝은 그 구간에서 담당자가 세 시스템 사이에 같은 데이터를 반복 입력한다는 원인을 보여줄 수 있습니다. 전자는 어디를 개선할지, 후자는 구체적으로 어떤 동작을 자동화할지 찾는 데 강합니다.
AI 에이전트는 API 호출과 문서 이해, 예외 판단을 함께 수행할 수 있어 기존 RPA보다 넓은 구간을 다룰 수 있습니다. 그렇다고 전체 프로세스를 한 번에 맡겨야 한다는 뜻은 아닙니다. 종단 간 지도에서 가치가 크고 경계가 명확한 구간을 고른 뒤, 필요한 경우 태스크 수준까지 내려가 도구와 화면 동작을 설계하는 편이 안전합니다.
자동화 후보는 빈도가 아니라 가치·안정성·위험을 함께 봐야 한다
가장 자주 발생하는 업무가 항상 가장 좋은 자동화 후보는 아닙니다. 빈도는 높지만 예외가 너무 많거나, 오류 한 번의 손실이 크거나, 입력 데이터가 늦게 도착하면 에이전트 운영비가 오히려 커질 수 있습니다. 후보별로 다음 요소를 함께 점수화하는 것이 좋습니다.
- 경제적 가치: 대기시간 단축, 인력시간 절감, 매출 회수, 불량과 패널티 감소 효과
- 반복성과 규모: 발생 건수, 업무량의 변동, 계절성과 피크 부하
- 표준화 가능성: 상위 몇 개 경로가 전체 건수에서 차지하는 비율, 입력과 출력의 명확성
- 예외 밀도: 재작업, 취소, 반려, 사람 간 인수인계, 시스템 밖 처리의 비율
- 자동화 준비도: API와 권한, 데이터 품질, 테스트 환경, 결과 검증 가능성
- 위험도: 금전·법적 영향, 개인정보, 되돌리기 어려운 작업, 고객 접점 여부
실무에서는 우선순위 점수 = 기대가치 × 처리규모 × 자동화 가능성 × 신뢰도 − 위험비용처럼 단순한 공식을 만들어도 유용합니다. 중요한 것은 숫자의 절대적 정밀도가 아니라 모든 후보를 같은 기준으로 비교하고, 가정과 근거 이벤트를 추적할 수 있게 만드는 것입니다.
에이전트의 역할은 프로세스 전체가 아니라 통제 가능한 구간에서 시작한다
프로세스 지도를 얻었다면 가장 안정적인 정상 경로부터 에이전트에 맡깁니다. 예를 들어 주문 정보와 계약 조건을 비교하고, 누락 자료를 요청하며, 승인용 초안을 만드는 작업은 자동화하되 실제 금액 확정이나 출고 중지는 사람이 승인하게 할 수 있습니다.
운영 경계는 세 층으로 나누면 명확해집니다.
- 자동 실행 구간: 입력이 완전하고 정책이 명확하며 실패를 되돌릴 수 있는 작업
- 승인 후 실행 구간: 금액, 고객, 설비 상태 등 조건에 따라 사람이 최종 확인해야 하는 작업
- 사람 전담 구간: 새로운 예외, 규정 충돌, 낮은 신뢰도, 중대한 영향이 있는 작업
이 경계는 고정하지 않습니다. 에이전트가 남긴 실행 이벤트를 다시 프로세스 로그에 넣고, 자동화 전후의 처리시간과 예외율을 비교합니다. 충분한 기간 동안 안정성이 확인된 구간만 승인 단계를 줄입니다. 반대로 오류나 우회가 늘면 자동 실행 범위를 즉시 축소합니다.
프로세스 마이닝과 AI 에이전트를 잇는 운영 아키텍처
지속 가능한 구조는 일회성 분석 파일이 아니라 실행 시스템과 분석 시스템이 순환하는 형태입니다.
- ERP·CRM·MES·WMS·그룹웨어에서 이벤트를 변경 데이터 캡처, API 또는 배치로 수집합니다.
- 활동명과 상태값을 공통 의미로 매핑하고, 식별자와 시간대를 정규화합니다.
- 케이스 또는 여러 업무 객체를 연결해 프로세스 모델과 변형을 계산합니다.
- 병목, 적합성 위반, 재작업, 비용, 자동화 후보를 분석합니다.
- 정책 엔진이 자동 실행·승인·사람 처리 경계를 결정합니다.
- 에이전트 오케스트레이터가 최소 권한의 도구를 호출하고 모든 결정을 기록합니다.
- 실행 결과가 다시 이벤트 스트림으로 들어가 개선 효과와 새로운 변형을 측정합니다.
여기서 에이전트의 대화 로그만 저장하는 것으로는 부족합니다. 어떤 업무 객체에 대해 어떤 정책 버전과 모델 버전으로 판단했고, 무슨 도구를 호출했으며, 사람이 언제 개입했고, 실제 비즈니스 결과가 무엇이었는지를 하나의 추적 ID로 연결해야 합니다. 그래야 오류 재현과 ROI 측정이 가능합니다.
대시보드가 멋진데도 프로젝트가 실패하는 다섯 가지 이유
1. 질문 없이 가능한 데이터를 모두 가져온다
수천 개 테이블을 먼저 복제하면 분석 범위가 커지고 의미 정의가 늦어집니다. “주문 확정부터 출고까지 대기가 왜 길어지는가?”처럼 의사결정 가능한 질문과 시작·종료 이벤트를 먼저 정해야 합니다.
2. 활동 이름은 같지만 의미가 다르다
‘완료’가 실제 작업 종료인지, 시스템 저장인지, 월말 마감인지 시스템마다 다를 수 있습니다. 활동 사전에는 비즈니스 의미, 원천 필드, 생성 조건, 소유자, 변경 이력을 포함해야 합니다.
3. 시스템 밖 업무를 없는 것으로 본다
전화, 메신저, 종이 문서, 개인 엑셀에서 처리된 단계는 로그에 공백으로 남습니다. 짧은 현장 관찰과 인터뷰, 필요하면 제한된 태스크 마이닝으로 이 구간을 확인해야 합니다.
4. 평균만 보고 긴 꼬리를 놓친다
평균 처리시간이 좋아도 상위 5%의 장기 지연이 고객 불만과 비용을 만들 수 있습니다. 중앙값뿐 아니라 분위수, 변형별 분포, 재작업 횟수, 인수인계 수를 함께 봐야 합니다.
5. 발견에서 끝나고 실행 책임자가 없다
병목을 찾았지만 업무 규칙, 시스템, 조직 중 누가 무엇을 바꿀지 정하지 않으면 대시보드는 보고서로 끝납니다. 각 개선 항목에 프로세스 오너, 기준선, 목표값, 실행 기한과 재측정 주기를 지정해야 합니다.
작게 시작하는 8주 실행 순서
1~2주차에는 범위를 좁힙니다. 경제적 결과가 분명하고 시작과 종료가 정의되는 프로세스 하나를 선택합니다. 예를 들어 견적 요청부터 계약 승인, 주문 확정부터 출고, 설비 알람부터 정비 종료처럼 경계를 잡습니다.
3~4주차에는 최소 이벤트 로그를 만듭니다. 모든 데이터를 완벽하게 모으려 하지 말고 핵심 활동 10~20개, 최근 3~6개월, 주요 업무 속성부터 시작합니다. 표본 케이스를 원천 화면과 대조해 순서와 시간이 맞는지 검증합니다.
5주차에는 실제 경로와 기준선을 확정합니다. 상위 변형, 병목 대기시간, 재작업률, 적합성 위반, 인수인계 수를 계산합니다. 현업 워크숍에서 데이터가 보여준 우회 경로의 이유를 확인합니다.
6주차에는 자동화 후보를 평가합니다. 가치, 규모, 표준화, 예외, 준비도, 위험을 같은 기준으로 점수화합니다. 첫 후보는 빈도가 높고 되돌릴 수 있으며 결과를 자동 검증할 수 있는 구간이 좋습니다.
7주차에는 그림자 모드로 실행합니다. 에이전트가 실제 작업은 하지 않고 권고 결과만 냅니다. 담당자의 실제 판단과 비교해 정확도, 누락, 불필요한 개입, 처리시간을 측정합니다.
8주차에는 제한된 자동화를 시작합니다. 저위험 조건에서만 실행하고 나머지는 승인 큐로 보냅니다. 중단 스위치, 중복 실행 방지, 권한 만료, 감사 로그와 보상 절차를 함께 준비합니다.
ROI는 절감 시간만으로 계산하지 않는다
에이전트가 한 건당 5분을 줄였다는 수치만으로는 투자 효과를 판단하기 어렵습니다. 자동화 이후 예외 처리와 검토 부담이 늘 수 있기 때문입니다. 최소한 다음 지표를 전후 비교해야 합니다.
- 전체 리드타임과 실제 작업시간의 분리
- 첫 처리 성공률과 재작업률
- 변형 수와 상위 변형의 점유율
- 사람 간·시스템 간 인수인계 횟수
- 규정 이탈과 승인 누락 비율
- 자동 처리율, 승인 전환율, 사람 복귀율
- 건당 모델·도구·인프라 비용
- 오류 복구 비용과 고객·매출 영향
비용 절감 외에도 현금 회수 기간, 납기 준수율, 설비 가동률, 불량률처럼 회사의 결과 지표를 연결해야 합니다. 프로세스 마이닝의 장점은 자동화 구간만 떼어 보지 않고 앞뒤 단계까지 함께 볼 수 있다는 것입니다. 한 단계가 빨라졌지만 다음 승인 큐가 더 막혔다면 전체 성과는 좋아지지 않은 것입니다.
좋은 AI 자동화는 업무 지도를 계속 갱신한다
AI 에이전트는 기존 절차를 자동으로 실행하는 도구를 넘어, 문서를 읽고 예외를 분류하며 여러 시스템을 오갈 수 있습니다. 바로 그 능력 때문에 실제 프로세스를 모른 채 배치했을 때의 위험도 큽니다. 잘못된 경로를 빠르게 반복하고, 사람이 암묵적으로 막아주던 예외를 놓칠 수 있기 때문입니다.
프로세스 마이닝은 에이전트보다 먼저 한 번 수행하는 진단 작업이 아닙니다. 에이전트가 만든 새로운 이벤트를 다시 분석하고, 실제 결과에 따라 권한과 자동화 경계를 조정하는 운영 루프입니다. 발견하고, 비교하고, 제한적으로 실행하고, 다시 측정하는 순환이 있어야 자동화가 시간이 갈수록 안전하고 경제적으로 변합니다.
결국 경쟁력은 가장 많은 에이전트를 배치하는 데서 나오지 않습니다. 회사의 실제 업무가 어디에서 기다리고, 왜 되돌아가며, 어느 예외에서 사람의 판단이 필요한지를 데이터로 설명하고 그 근거에 맞춰 자동화하는 능력에서 나옵니다. AI 에이전트 프로젝트의 첫 화면은 챗봇이 아니라 실제 업무의 지도여야 합니다.
