방법2026년 9월 9일 · 4 최소 읽기 시간(분)

업무 프로세스를 위한 사건 기반 시뮬레이션

간단히 말해

이벤트 기반 이산 시뮬레이션(DES)은 도착, 처리 시작, 처리 완료, 교대 전환 같은 사건들의 연속으로 프로세스를 묘사합니다: 시계는 고정된 시간 간격으로 흐르지 않고 항상 다음으로 예정된 사건으로 건너뜁니다. 따라서 모델의 하루는 밀리초 단위의 계산 시간만 소요합니다. 엔터티는 작업이며, 자원은 처리 능력이고, 둘이 맞지 않으면 대기열이 생깁니다. 업무 프로세스에서는 세 가지 결정이 중요합니다: 표준 가정으로서 지수분포된 도착 간격, 처리 시간에 대한 오른쪽 치우친 분포, 그리고 결과 구간이 안정적일 정도로 충분한 반복 횟수입니다.

Inhaltsverzeichnis

왜 “디스크리트(discrete)”이고 왜 “이벤트 지향적(event-driven)”인지

시뮬레이션에서 시간을 처리하는 방법에는 두 가지가 있습니다.

시간 간격 기반: 시계가 일정한 간격(매분, 매초)으로 흐르며 각 간격마다 무슨 일이 일어났는지 확인합니다. 프로그래밍은 쉽지만 실행에서 비효율적입니다. 승인 프로세스의 두 이벤트 사이에는 아무 일도 일어나지 않는 수시간이 있을 수 있는데도 계산은 계속됩니다.

이벤트 지향적: 시계는 다음으로 예정된 이벤트 시점으로 점프합니다. 이벤트들 사이에는 상태가 변하지 않으므로 계산할 필요가 없습니다.

이벤트 목록(시간순):
  09:14  도착 작업 #418
  09:22  처리 종료 #402 단계 "검사"
  09:40  교대 변경 승인
  ...
시계가 09:14로 점프해 처리하고 후속 이벤트를 계획한 다음 계속 점프합니다.

“디스크리트”란 상태가 연속적으로 변하지 않고 특정 시점에 급격히 변한다는 뜻입니다. 이는 업무 프로세스에 정확히 맞습니다. 신청서는 처리되었거나 그렇지 않으며, 반쯤 처리된 상태는 없습니다.

네 가지 구성 요소

구성 요소	귀하의 프로세스에서	하는 일
엔터티	청구서, 신청서, 티켓, 지원서	모델을 통과하며 속성을 가집니다
리소스	담당자, 승인 권한자, 검수 부서	용량이 있고, 사용 중이거나 비어 있음
대기열	우편함, 티켓 목록, 상기 재처리함	리소스가 사용 중일 때 저절로 생깁니다
이벤트	도착, 시작, 종료, 교대 변경	상태를 바꾸고 후속 이벤트를 계획합니다

가장 중요한 특징: 대기열은 모델링되는 것이 아니라 저절로 생깁니다. 처리 시간이 3일이라고 고정된 간격으로 입력하면 결과를 미리 가정한 것이지 계산한 것이 아닙니다. 그렇게 하면 용량이나 분산이 바뀔 때 이 시간이 어떻게 변하는지 보여줄 수 없습니다.

모델이 실패하는 세 가지 결정

1. 어떤 분포를 사용할까?

도착 간격에는 지수분포. 여러 공급업체의 청구서나 여러 사용자의 티켓처럼 작업들이 서로 독립적으로 도착할 때 표준 가정입니다. 우편함에서 관찰되는 행동을 정확히 만들어냅니다: 긴 평온한 구간 뒤에 세 건이 한꺼번에 오는 식입니다.

도착이 정기적이면 지수분포는 맞지 않습니다: 월말 수집 처리나 매일 8시에 이루어지는 인계처럼요. 그럴 때는 분포가 아니라 달력이 필요합니다.

처리 시간은 오른쪽 꼬리(비대칭). 로그정규나 감마분포를 사용합니다. 추정치만 있다면 최소값·가장 가능성 높은 값·최대값으로 삼각분포를 쓰세요. 이유는 처리시간이 명확한 하한을 가지며 긴 오른쪽 꼬리를 가지기 때문입니다. 정규분포는 음수를 만들고 극단값을 과소평가해 대기열을 제대로 재현하지 못합니다.

실무 규칙: 만약 ‘5에서 15분’만 알고 있다면 최빈값을 8로 한 삼각분포를 쓰세요. 로그정규와 감마 중 어느 쪽을 택하느냐는, 분산을 아예 고려하느냐보다 결과에 덜 영향을 줍니다.

2. 워밍업 기간

시뮬레이션은 빈 대기열에서 시작합니다. 이는 실제로는 존재하지 않는 상태입니다. 따라서 초기 며칠의 모델 결과는 체계적으로 과도하게 좋게 나옵니다.

처리 방법: 초기 며칠을 분석에서 제외(워밍업)하거나 현실적인 초기 재고로 시작하세요. 사용률이 85%보다 훨씬 낮은 프로세스는 며칠이면 충분하고, 경계에 가까우면 안정화에 몇 주가 걸릴 수 있습니다.

어떻게 알 수 있나: 첫 주 평균이 둘째 주보다 현저히 낮으면 워밍업이 충분하지 않은 것입니다.

3. 몇 번 실행할까?

단일 실행은 표본 크기 1입니다. 그것은 한 작업일에 대해 알려주는 정도밖에 안 됩니다. 난수를 새로 생성해 실행을 반복하고 결과 구간이 안정될 때까지 반복하세요.

실무 기준: 실행 횟수를 두 배로 늘려보세요. 그때 P50과 P90이 몇 퍼센트 이내로만 움직이면 충분합니다. 업무 프로세스의 경우 일반적으로 수백 회가 필요합니다.

정확한 횟수보다 중요한 것: 반드시 반복 실행을 하고 출력이 한 개의 수가 아닌 분포(구간)가 되도록 하는 것입니다. 단일 값을 출력하는 시뮬레이션은 이 방법의 목적을 충족하지 못합니다.

관점 비교

	프로세스 지향	이벤트 지향
설명하는 것	엔터티의 생활사	각 이벤트 유형에서 무슨 일이 일어나는지
예시	"청구서가 도착하고, 대기하고, 검토되고, 대기하고, 승인된다"	"도착 시: 대기열에 넣는다. 리소스가 비어 있으면: 다음 것을 뽑는다"
널리 쓰이는 곳	SimPy, Simul8, 대부분의 상용 도구들	오래된 라이브러리, 자체 구현들

업무 프로세스에는 프로세스 지향적 관점이 더 자연스럽습니다: 어떤 작업에 무슨 일이 일어나는지를 적는 것은 실무 부서가 자신의 흐름을 설명하는 방식과 정확히 일치합니다.

검증: 세 가지 검사

1. Little's Law. 재고 ÷ 처리율은 대략적으로 처리시간과 같아야 합니다. 모델과 현실 모두에서 이 검사는 분포에 대한 가정이 없어 가장 강력합니다.

2. 사용률을 수작업으로 확인. ρ = 수요 ÷ 용량을 각 단계별로 계산기로 확인하세요. 모델과 큰 차이가 나면 분기나 달력이 잘못된 것입니다.

3. 극단값 테스트. 한 단계의 용량을 두 배로 놓아보세요. 아무 변화가 없으면 그 단계는 결코 병목이 아니었습니다. 예상치 못했다면 모델이 귀하의 이해와 맞지 않는 것이며, 바로 그때 흥미로운 논의가 시작됩니다.

DES가 적합하지 않은 경우

참여자가 자체 결정을 내려 흐름을 바꾸는 경우(고객이 이탈하거나 담당자가 사례를 골라 처리함) → 에이전트 기반 시뮬레이션을 사용하세요.
수년 단위 재고와 피드백을 다루는 경우(인력 확충, 시장 역학) → 시스템 다이내믹스가 맞습니다.
대기열이 없을 정도로 용량이 충분한 경우 → 단순 합산이면 됩니다.
실제로 무슨 일이 일어났는지를 알고자 하는 경우 → Process Mining을 사용하세요. DES는 가정을 계산할 뿐 기록을 재현하지는 않습니다.

자주 묻는 질문

사건 기반 시뮬레이션과 에이전트 기반 시뮬레이션의 차이는 무엇입니까?

DES는 고정된 스테이션을 통해 흐르고 점유된 자원 앞에서 대기하는 프로세스를 모델링합니다. 로직은 프로세스에 있습니다. 에이전트 기반 시뮬레이션은 서로 상호작용하는 자체 규칙을 가진 참여자를 모델링합니다. 로직은 에이전트에 있습니다. 승인 프로세스에는 DES가 적절합니다; 참여자가 스스로 계속할지 어떻게 할지 결정할 때 ABS가 흥미로워집니다.

처리시간에 어떤 분포를 사용해야 합니까?

오른쪽으로 치우친 분포: 데이터가 있다면 로그정규나 감마, 추정한다면 최솟값·가장 가능성 높은 값·최댓값의 삼각분포를 사용하세요. 정규분포는 사용하지 마세요. 정규분포는 음수 지속시간을 만들고 대기열을 유발하는 긴 사례를 과소평가합니다. 오른쪽으로 치우친 후보들 중 선택하는 것보다 더 중요한 것은 분포에 변동이 반영되는 것입니다.

워밍업 기간은 얼마나 길어야 합니까?

재고와 대기시간이 더 이상 체계적으로 증가하지 않을 때까지 길어야 합니다. 가동률이 85%보다 훨씬 낮으면 며칠이면 충분하지만, 용량 한계에 가깝다면 대기열이 매우 천천히 안정화되기 때문에 몇 주가 걸릴 수 있습니다. 간단한 테스트: 첫 주 평균이 둘째 주 평균보다 현저히 낮으면 기간이 너무 짧았습니다.

왜 시계가 일정하게 흐르지 않고 건너뜁니까?

두 사건 사이에는 계산할 일이 없기 때문입니다. 승인 프로세스에서는 도착과 처리 시작 사이에 상태 변화가 없는 시간이 종종 몇 시간 동안 존재합니다. 사건 점프는 모델 연도를 몇 초 안에 계산 가능하게 합니다. 이것이 수백 번의 반복이 실용적인 이유입니다.

DES를 위해 프로그래밍 언어가 필요합니까?

아니요. SimPy와 같은 라이브러리는 코드가 필요하지만 상업용 도구와 경량 의사결정 도구는 그렇지 않습니다. 차이는 책임에 있습니다: 라이브러리를 쓰면 분포 선택, 워밍업 기간, 복제 수를 스스로 결정해야 합니다; 사용자 인터페이스가 있는 도구는 이러한 결정을 부분적으로 대신해 주지만 계산은 더 단순화합니다.

FlowVisual

자신의 프로세스로 직접 계산해 보세요

FlowVisual은 이 글의 수치를 귀하의 수량, 귀하의 용량, 귀하의 마진을 반영한 실행 가능한 모델로 만듭니다.

Mac App Store에서 받기 Microsoft Store에서 받기

Guide: seven steps to the number

계속 읽기