핵심 인사이트 (3줄 요약)
- 본질: 모델 향상 (Model Enhancement)은 프로세스 마이닝 (Process Mining) 결과를 읽고 끝내는 것이 아니라, 실제 이벤트 로그를 근거로 현재 상태 (AS-IS) 프로세스를 목표 상태 (TO-BE) 프로세스로 재설계하는 개선 단계다.
- 가치: 병목, 재작업 루프, 규정 위반을 제거하면서도 "바꾸고 나면 더 좋아지는가"를 시뮬레이션으로 검증해, 개선 실패 비용을 줄인다.
- 판단 포인트: 현실을 모델에 반영하는 수리 (Repair)와, 모델 자체를 더 나은 구조로 바꾸는 확장 (Extension)을 구분하고, 국소 최적화가 아닌 전체 흐름 기준으로 판단해야 한다.
Ⅰ. 개요 및 필요성
모델 향상 (Model Enhancement)은 프로세스 발견 (Process Discovery)과 적합성 검사 (Conformance Checking) 이후에 수행하는 프로세스 개선 단계다. 발견이 "실제로 어떻게 일하는가"를 보여주고, 적합성 검사가 "어디서 표준과 어긋나는가"를 보여준다면, 모델 향상은 그 결과를 바탕으로 모델과 운영 방식을 함께 바꾸는 데 초점을 둔다. 즉 분석에서 실행으로 넘어가는 구간이다.
이 단계가 필요한 이유는 로그 분석만으로는 리드타임 (Lead Time)과 비용이 줄지 않기 때문이다. 예를 들어 승인 루프가 4번 반복된다는 사실을 알아도, 승인 권한 재설계나 자동화 투입이 없으면 병목은 그대로 남는다. 또한 현장에서는 표준 모델이 낡아 현실을 설명하지 못하는 경우도 많아, 모델을 고치지 않으면 이후 통제와 자동화 역시 잘못된 기준 위에서 돌아가게 된다.
- 📢 섹션 요약 비유: 건강검진에서 혈관이 막힌 사실을 알아낸 것만으로는 치료가 끝나지 않는다. 모델 향상은 검사 결과를 보고 식단을 바꾸고, 스텐트를 넣고, 다시 운동 계획까지 세우는 치료 단계와 같다.
Ⅱ. 아키텍처 및 핵심 원리
모델 향상은 보통 이벤트 로그, 기준 프로세스 모델, 성능 지표를 함께 입력으로 사용한다. 로그에서는 대기 시간, 반복 빈도, 우회 경로를 찾고, 기준 모델에서는 원래 의도한 통제 지점과 책임 분리를 확인한다. 이 둘을 비교해 개선 가설을 만든 뒤, 수정된 목표 상태 (TO-BE) 모델에 대해 처리시간, 자원 부하, 서비스 수준 협약 (SLA, Service Level Agreement), 핵심성과지표 (KPI, Key Performance Indicator) 충족 여부를 검증한다.
| 기법 | 핵심 질문 | 대표 산출물 | 주의점 |
|---|---|---|---|
| 수리 (Repair) | 현실과 모델 중 무엇이 어긋났는가? | 최신 AS-IS 모델 | 규정 위반을 정당화하지 않도록 구분 필요 |
| 확장 (Extension) | 어떤 제어/자동화를 추가할 것인가? | TO-BE 설계안 | 국소 병목 제거가 다른 병목을 만들 수 있음 |
| 시뮬레이션 (Simulation) | 바꾸면 어떤 수치가 달라지는가? | 예상 처리량·대기시간 | 입력 가정이 틀리면 결과도 왜곡됨 |
아래 그림은 모델 향상이 단순 편집이 아니라, 로그 기반 진단과 TO-BE 검증이 연결된 순환 구조임을 보여준다.
┌──────────────────────────────────────────────────────────────────┐
│ 모델 향상 흐름: 발견된 문제를 TO-BE와 검증으로 연결 │
├──────────────────────────────────────────────────────────────────┤
│ 이벤트 로그 ─┐ │
│ ├─▶ 병목·루프·편차 분석 ─▶ 개선 가설 ─▶ TO-BE 모델 │
│ 기준 모델 ──┘ │ │
│ ▼ │
│ 시뮬레이션·KPI 검증 │
│ │ │
│ ▼ │
│ 운영 반영 또는 재설계 반복 │
└──────────────────────────────────────────────────────────────────┘
실무에서는 세 가지 순서가 중요하다. 첫째, 병목이 발생한 활동 자체보다 그 앞뒤 대기열과 핸드오프 (Hand-off)를 본다. 둘째, 제거 가능한 단계와 반드시 남겨야 하는 통제 단계를 나눈다. 셋째, 자동화 후보는 처리시간뿐 아니라 오류율, 야간처리 필요성, 규정 준수 여부를 함께 평가한다.
- 📢 섹션 요약 비유: 낡은 도로를 고칠 때는 막힌 교차로 하나만 넓히는 것이 아니라, 어디서 차가 몰리고 어디서 신호가 꼬이는지 본 뒤 우회로와 신호체계를 함께 설계해야 한다. 그래야 공사 후에 다른 골목이 더 막히는 일을 막을 수 있다.
Ⅲ. 비교 및 연결
모델 향상은 앞선 두 기법과 역할이 다르다. 프로세스 발견은 현실 복원에 가깝고, 적합성 검사는 위반 탐지에 가깝고, 모델 향상은 설계 변경에 가깝다. 따라서 같은 로그를 쓰더라도 질문이 다르다. "무엇이 일어났는가"에서 "무엇을 바꿔야 하는가"로 질문이 이동하는 순간이 바로 모델 향상이다.
| 구분 | 프로세스 발견 | 적합성 검사 | 모델 향상 |
|---|---|---|---|
| 기준 | 이벤트 로그 중심 | 로그 vs 표준 모델 | 로그 + 모델 + 성능 목표 |
| 초점 | 실제 흐름 가시화 | 위반과 편차 측정 | 병목 제거와 TO-BE 설계 |
| 대표 질문 | 현실은 어떤가? | 표준과 얼마나 다른가? | 무엇을 어떻게 바꿀까? |
| 대표 산출물 | AS-IS 맵 | 적합도·편차 리포트 | TO-BE 모델·개선안 |
또한 모델 향상 내부에서도 수리와 확장을 분리해 봐야 한다. 수리는 메뉴얼이 현실을 따라가지 못할 때 유효하고, 확장은 현실 자체가 비효율적일 때 필요하다. 여기에 시뮬레이션을 붙이면 "모델 수정"이 단순 문서 갱신인지, 실제 성과를 바꾸는 구조 변경인지 구체적으로 검증할 수 있다. 이 점에서 모델 향상은 비즈니스 프로세스 관리 (BPM, Business Process Management), 로보틱 프로세스 자동화 (RPA, Robotic Process Automation), 하이퍼오토메이션 (Hyperautomation)과 직접 연결된다.
- 📢 섹션 요약 비유: 발견은 도시 지도를 새로 그리는 일이고, 적합성 검사는 불법 주정차를 잡아내는 일이며, 모델 향상은 차선을 다시 긋고 버스전용차로를 만드는 도시계획에 가깝다. 셋은 비슷해 보여도 쓰임새가 다르다.
Ⅳ. 실무 적용 및 기술사 판단
실무에서는 "현실을 따라갈 것인가, 현실을 바꿀 것인가"를 먼저 판단해야 한다. 로그에 자주 나타난다고 해서 그 경로를 바로 표준화하면, 오래된 예외 처리나 편법을 제도화할 수 있다. 반대로 규정을 지나치게 고수하면 현업이 실제로 왜 우회했는지 놓치게 된다. 따라서 규정상 필수 통제인지, 단순 관행인지 먼저 분리해야 한다.
적용 체크리스트
- 병목의 원인이 단계 자체인지, 인력·권한·시스템 응답시간인지 분리했는가?
- 제거하려는 단계가 감사, 보안, 법규 측면의 통제 지점은 아닌가?
- 시뮬레이션 입력값에 실제 처리량, 피크 시간, 예외 비율이 반영되었는가?
- 자동화 후보라면 API 연계, 로보틱 프로세스 자동화 (RPA), 조직 변경 중 무엇이 가장 유지보수성이 높은가?
안티패턴
- 승인 단계를 없애면서 책임 추적 경로까지 제거하는 설계
- 한 부서의 처리시간만 줄이고 후속 부서 적체를 키우는 국소 최적화
- 로그 품질이 낮은데도 시뮬레이션 숫자를 절대값처럼 신뢰하는 의사결정
기술사 답안에서는 "발견 → 편차 분석 → 수리/확장 → 시뮬레이션 검증 → TO-BE 정착"의 흐름을 기억하면 안정적이다. 특히 개선안 제시 시에는 비용 절감만이 아니라 통제 유지와 변화관리까지 함께 언급해야 설계 판단이 완성된다.
- 📢 섹션 요약 비유: 집을 리모델링할 때 벽 하나 허물면 넓어 보여도, 그 벽이 하중을 버티는 구조벽이면 건물이 위험해진다. 모델 향상도 빨라 보이는 해법보다, 남겨야 할 구조를 먼저 구분하는 리모델링 감각이 필요하다.
Ⅴ. 기대효과 및 결론
모델 향상이 잘 수행되면 리드타임 단축, 재작업 감소, 규정 준수 향상, 자동화 우선순위 명확화라는 네 가지 효과를 동시에 얻을 수 있다. 특히 프로세스 개선이 데이터 근거를 갖게 되므로, "느낌상 좋아 보이는 개선"이 아니라 수치 기반 의사결정이 가능해진다. 이는 경영진 승인과 현업 설득 모두에 유리하다.
다만 모든 프로세스가 시뮬레이션대로 움직이진 않는다. 로그 누락, 조직 저항, 예외 케이스 폭증, 시즌별 업무량 차이 같은 변수가 실제 효과를 깎을 수 있다. 따라서 모델 향상은 일회성 문서 작업이 아니라, 운영 반영 후 다시 측정하고 보정하는 반복 구조로 이해해야 한다.
결국 이 개념은 "프로세스를 그리는 기술"이 아니라 "프로세스를 바꾸되 검증까지 끝내는 기술"로 기억하는 것이 맞다. 발견과 감사의 결과를 성과로 바꾸는 마지막 연결 고리가 모델 향상이다.
- 📢 섹션 요약 비유: 좋은 코치는 경기 영상을 보고 문제를 설명하는 데서 멈추지 않는다. 전술을 다시 짜고, 연습 경기를 돌려 보고, 실제 경기에서 통할 때까지 수정한다. 모델 향상도 바로 그런 감독의 일이다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|---|
| 프로세스 발견 (Process Discovery) | 실제 로그로 AS-IS 프로세스를 복원하는 선행 단계 |
| 적합성 검사 (Conformance Checking) | 표준 대비 편차를 찾아 개선 대상을 명확히 함 |
| 시뮬레이션 (Simulation) | TO-BE 적용 전 처리량과 병목 이동을 예측함 |
| 로보틱 프로세스 자동화 (RPA, Robotic Process Automation) | 확장 단계에서 사람 작업을 자동화 모듈로 치환하는 수단 |
| 비즈니스 프로세스 관리 (BPM, Business Process Management) | 모델 향상 결과를 조직 프로세스로 정착시키는 운영 프레임워크 |
📈 관련 키워드 및 발전 흐름도
프로세스 발견 (Process Discovery)
│
▼
적합성 검사 (Conformance Checking)
│
▼
모델 향상 (Model Enhancement)
├─ 수리 (Repair)
├─ 확장 (Extension)
└─ 시뮬레이션 (Simulation)
│
▼
TO-BE 정착 · 자동화 · 지속 개선
이 흐름도는 "가시화 → 위반 분석 → 설계 변경 → 검증 → 정착"의 개선 폐루프를 보여준다.
👶 어린이를 위한 3줄 비유 설명
- 학교 운동장이 어디서 막히는지 보는 것은 문제를 찾는 단계예요.
- 모델 향상은 아이들이 덜 부딪히게 길을 다시 그리고, 필요한 곳에 신호등을 놓는 일이에요.
- 그리고 정말 잘 움직이는지 쉬는 시간 전에 미리 연습해 보는 것이 시뮬레이션이에요.