24. 하이브리드 시뮬레이션: DES × ABS × SD

입문 편에서 우리는 세 가지 시뮬레이션 패러다임을 하나씩 배웠다. System Dynamics(SD)는 위에서 내려다보며 총량과 피드백을, DES는 큐와 자원을 따라 흐르는 수동적 개체를, ABM은 국소 정보로 스스로 판단하는 능동적 개체를 다뤘다. 각 글은 “이 패러다임이 맞는 문제”를 골라서 보여 줬다. 그런데 현실의 문제는 그렇게 친절하지 않다. 하나의 시스템 안에 세 패러다임이 각각 잘 맞는 부분이 공존하는 경우가 흔하다. 이번 글은 23편에 이어, 이 불편한 현실에 대한 답인 하이브리드 시뮬레이션(hybrid simulation) — 여러 패러다임을 한 모델 안에서 결합하는 것 — 을 다룬다.

왜 섞는가: 시스템의 부분마다 다른 추상화가 필요하다

병원을 모델링한다고 하자.

환자 흐름 — 접수 → 진료 → 검사 → 처치 → 퇴원. 프로세스와 큐, 자원(의사·병상)이 핵심이다. 전형적인 DES 문제다.
개별 환자의 행동 — 대기가 길어지면 이탈하고, 증상에 따라 다른 병원으로 옮기고, 재방문을 결정한다. 개체가 국소 정보로 스스로 판단하는 agent 문제다.
지역 수요와 인력 정책 — 지역 인구 변화, 병원 평판, 인력 채용·이직의 느린 동역학. 총량과 피드백 루프, 즉 SD 문제다.

제조도 마찬가지다. lot의 공정 흐름은 DES, 반송 차량(AGV/OHT)과 작업자·유지보수 기사는 스스로 판단하는 agent, 수요 예측과 capacity 투자 계획은 SD의 영역이다.

이걸 한 패러다임으로 억지로 다 담으면 어느 한쪽 표현이 뒤틀린다. DES만 쓰면 환자의 이탈 판단을 “확률 분기”로 뭉개야 하고, SD만 쓰면 개별 lot의 대기시간 분포를 잃고 평균 총량만 남는다. ABM만 쓰면 굳이 능동적일 필요 없는 lot까지 agent로 만들어 모델이 비대해진다. 시스템의 서로 다른 부분이 서로 다른 추상화 수준을 요구한다면, 부분마다 맞는 패러다임을 쓰고 그것들을 잇는 것이 자연스러운 답이다. 실제로 이 접근은 OR(operations research) 분야에서 하나의 독립된 연구 흐름으로 자리 잡았다 (Brailsford et al., 2019).

대표 결합 패턴

DES + agent: 흐르는 entity와 판단하는 개체

가장 실무적인 패턴이다. 프로세스 흐름 속의 수동적 entity(lot, 환자, 주문)와, 그 사이를 오가는 능동적 agent(반송 차량, 작업자, 유지보수 기사)를 결합한다. entity는 DES 방식대로 정해진 공정 경로를 따라 흐르고, agent는 국소 정보로 스스로 판단한다 — 여러 반송 요청 중 어느 것을 받을지, 어떤 경로로 갈지, 어느 고장 장비부터 고칠지.

예를 들어 반도체 FAB에서 lot이 한 공정을 마치면 “다음 장비로 옮겨 달라”는 반송 요청 이벤트가 발생한다(DES). 이 요청을 어느 차량이 수락할지는 각 차량 agent가 자기 위치·적재 상태·주변 혼잡도를 보고 결정한다(ABM). 차량의 결정이 lot의 대기시간을 바꾸고, 그것이 다시 큐 길이와 다음 요청 패턴을 바꾼다. 이 패턴은 9부 FAB 응용 편에서 그대로 다시 등장할 것이다.

SD + DES: 거시 루프가 미시 프로세스의 parameter를 움직인다

거시 피드백 루프(수요, 평판, 투자)는 느리게 변하며 미시 프로세스(주문 처리)의 parameter를 천천히 바꾸고, 미시 프로세스의 결과(lead time, 서비스 수준)는 거시 루프로 되먹임된다.

작은 예를 수식으로 보자. 회사의 평판을 stock $R (t)$ 로 두고, DES가 산출하는 평균 lead time $L$ 이 목표 $L^{*}$ 에서 벗어나면 평판이 변한다고 하자.

\frac{d R}{d t} = α (L^{*} - L (t)), λ (t) = λ_{0} \cdot h (R (t))

첫 식은 SD 쪽 이야기다: lead time이 목표보다 짧으면( $L < L^{*}$ ) 평판이 쌓이고, 길면 깎인다 — $α$ 는 그 속도다. 둘째 식은 결합의 방향을 말한다: 평판 $R$ 이 증가 함수 $h$ 를 통해 주문 도착률 $λ (t)$ 를 끌어올리고, 이 $λ (t)$ 가 DES 모델의 도착 프로세스 parameter로 주입된다. 그러면 DES에서 주문이 늘어 큐가 길어지고 $L (t)$ 가 커지면, 다시 첫 식을 통해 평판이 깎여 수요가 진정된다 — 미시 큐잉과 거시 피드백이 하나의 균형 루프를 이룬다. 어느 한쪽만으로는 이 순환을 담을 수 없다.

SD + agent: 창발한 총량이 거시 모델과 만난다

개별 행동에서 창발한 거시 변수가 SD 총량 모델과 연결되는 패턴이다. 전염병이 좋은 예다. 특정 도시는 접촉 네트워크가 중요해서 사람 한 명 한 명을 agent로 시뮬레이션하고, 그 결과 집계된 감염자 수 $I (t)$ 가 국가 수준 SIR 모델의 stock에 연결된다. 반대 방향으로는, SD가 계산한 전국적 유행 수준이 각 agent의 행동 규칙(외출 자제 확률 등)에 영향을 준다.

계층 프레임: 전략 — 전술 — 운영

세 패턴을 하나의 그림으로 정리하면 의사결정 계층과 잘 맞는다.

계층	시간 스케일	질문	패러다임
전략 (strategic)	년	capacity를 얼마나 늘릴까	SD
전술 (tactical)	주·일	이 라인 구성으로 목표 산출이 나오나	DES
운영 (operational)	분·초	이 차량이 지금 어느 요청을 받을까	agent

위 계층이 아래 계층의 parameter(capacity, 정책)를 정하고, 아래 계층의 성과(lead time, 가동률)가 위로 집계되어 되먹임된다. 모든 하이브리드 모델이 이 틀에 들어맞는 건 아니지만, “우리 문제에서 어느 부분이 어느 패러다임인가”를 정리하는 출발점으로 유용하다.

기술적 난점: 결합부가 곧 문제다

패러다임을 섞는 순간, 각 패러다임 내부에서는 없던 문제들이 결합부에서 생긴다.

(a) 시간 진행의 결합

세 패러다임은 시계를 서로 다르게 굴린다. DES는 event-driven(다음 사건으로 점프), SD는 고정 스텝 수치 적분, ABM은 보통 고정 스텝이다. 이 서로 다른 클록을 맞물리는 표준적 방법은 이렇다: 현재 시각 $t_{k}$ 에서 DES의 다음 사건 시각이 $t_{k + 1}$ 이라면, 그 사이 구간 $[t_{k}, t_{k + 1}]$ 동안 연속 상태 $x (t)$ 를 수치 적분으로 전진시킨다.

\frac{d x}{d t} = f (x, t), t \in [t_{k}, t_{k + 1}]

즉 이산 세계가 “다음 사건까지”라는 구간을 정해 주면, 연속 세계는 그 구간을 잘게 쪼개 적분한다. 그런데 반대 방향의 문제가 있다. 연속 변수가 적분 도중 임계값을 넘는 순간 자체가 이산 사건이 되어야 하는 경우다 — 탱크 수위가 만수위에 닿으면 밸브를 닫아야 하고, 재고가 발주점 밑으로 내려가면 주문 이벤트를 내야 한다. 이를 state event(상태가 조건을 만족하는 순간 발생하는, 미리 스케줄되지 않은 사건)라 하며, 임계 조건을 $g (x) = 0$ 으로 쓰면 검출해야 할 시각은

t^{*} = min {t > t_{k} : g (x (t)) = 0}

이다. 이 식이 말하는 것: 다음 사건 시각은 더 이상 이벤트 목록만 봐서는 알 수 없고, 적분을 하면서 $g$ 의 부호가 바뀌는 순간을 찾아내야(zero-crossing detection) 한다. 고정 스텝으로 성큼 지나가면 임계 통과 순간을 놓치므로, 부호가 바뀐 스텝에서 이분법 등으로 $t^{*}$ 를 되짚어 찾고, 시뮬레이션 시계를 그 시각으로 되돌려 사건을 처리한다. 이산과 연속의 결합은 이렇게 시간 관리 자체를 어렵게 만든다.

(b) 상태 일관성

한 모듈이 다른 모듈의 상태를 언제 읽는가의 문제다. 예컨대 SD 모듈이 스텝 크기 $Δ t = 1 일$ 로 도는데 DES의 lead time을 읽어 간다면, 그 하루 사이 DES에서 벌어진 변화는 반영되지 않는다. 반대로 DES가 사건마다 SD의 stock을 읽으면, SD 입장에서는 적분 스텝 중간의 미완성 값을 읽힐 수 있다. 어느 시점의 값을 “공식 상태”로 삼을지, 갱신 순서를 어떻게 고정할지를 명시적으로 설계하지 않으면 — 같은 모델이라도 모듈 실행 순서에 따라 결과가 달라지는, 디버깅하기 고약한 비결정성이 생긴다.

(c) 인터페이스의 모호함

두 모듈 사이를 오가는 신호가 이벤트인가, 연속 신호인가부터가 모호하다. “수요”는 SD에서는 연속 flow지만 DES에서는 개별 주문 도착 사건이다. 연속 flow를 사건 열로 바꾸려면 rate를 도착 프로세스로 변환(예: rate $λ (t)$ 의 비정상(nonhomogeneous) Poisson 프로세스)해야 하고, 반대로 사건 열을 flow로 올리려면 어떤 구간으로 집계·평활할지 정해야 한다. 이 변환 규칙 하나하나가 모델링 결정이며, 잘못 정하면 결합부에서 정보가 왜곡된다.

이런 이산+연속 결합을 수학적으로 정식화하려는 틀이 19편에서 이름만 언급했던 DEV&DESS(Discrete Event & Differential Equation System Specification)다. DEVS의 이산 사건 구조에 미분방정식 상태와 state event 조건을 결합한 형식론으로, 위의 (a)~(c)를 모델 명세 수준에서 명확히 하려는 시도라고 이해하면 된다.

도구

상용 도구 중에서는 AnyLogic이 세 패러다임(SD·DES·ABM)을 한 모델 안에서 섞는 multimethod modeling을 전면에 내세운 도구로 알려져 있다. 프로세스 flowchart 위의 entity, statechart를 가진 agent, stock-flow 다이어그램을 같은 모델에서 연결할 수 있다.

오픈소스 진영에는 세 패러다임을 통합한 단일 표준 도구가 없어서, 보통 코드 수준에서 직접 결합한다. 전형적으로는 DES 라이브러리(SimPy)와 ABM 라이브러리(Mesa)를 한 Python 프로세스에서 함께 돌리고, SD 부분은 SciPy의 ODE solver나 간단한 오일러 적분으로 직접 구현한 뒤, 위에서 말한 시간 동기화와 인터페이스를 손수 짠다. 유연하지만 (a)~(c)의 난점을 전부 개발자가 책임져야 한다는 뜻이기도 하다.

경고: “섞을 수 있다”와 “섞어야 한다”는 다르다

하이브리드는 표현력을 얻는 대신 값을 치른다. 23편에서 본 보정·검증의 부담이 그대로 배가된다 — 패러다임마다 parameter와 가정이 따로 늘어나고, 각각을 뒷받침할 데이터도 따로 필요하다. 더 나쁜 것은 결합부 자체가 새로운 오류원이라는 점이다. 각 모듈이 단독으로는 검증을 통과해도, 시간 동기화나 인터페이스 변환이 잘못되면 결합 모델은 틀린다 — 그리고 이 오류는 어느 한 패러다임의 전문 지식만으로는 잡히지 않는다. 그러니 원칙은 단순하다. 답하려는 질문에 필요한 최소한의 결합만 한다. 큐의 거동만 궁금하면 DES 하나로 충분하고, 수요 피드백이 질문의 핵심일 때에만 SD를 붙인다.

정리

현실 시스템은 부분마다 다른 추상화를 요구한다 — 프로세스 흐름(DES), 능동적 개체(agent), 거시 피드백(SD)이 한 시스템 안에 공존한다.
대표 결합 패턴: DES + agent(흐르는 entity + 판단하는 차량·작업자), SD + DES(거시 루프가 미시 parameter를 움직이고 성과가 되먹임), SD + agent(창발한 총량이 거시 모델과 연결). 전략(SD)–전술(DES)–운영(agent) 계층 프레임으로 정리할 수 있다.
기술적 난점은 결합부에 있다: 시간 진행의 결합(event-driven vs 고정 스텝, state event 검출), 상태 일관성(읽는 시점), 인터페이스의 모호함(이벤트 vs 연속 신호). 이를 정식화하려는 틀이 DEV&DESS다.
하이브리드는 표현력의 대가로 보정·검증 부담과 결합부 오류원을 얻는다. 질문에 답하는 최소한의 결합만 하라.

8부 후반은 Digital Twin 심화로 넘어간다. 다음 글은 25편: Digital Twin 아키텍처와 표준이다.

참고문헌

S. C. Brailsford, T. Eldabi, M. Kunc, N. Mustafee, A. F. Osorio, “Hybrid simulation modelling in operational research: A state-of-the-art review”, European Journal of Operational Research 278(3), 2019, pp. 721–737. DOI

Roh's Warehouse

Explorer