01. 시뮬레이션 개요 — 왜, 언제 쓰나

새 공장의 장비를 한 대 더 들이면 처리량이 정말 늘어날까? 응급실 간호사를 두 명 더 배치하면 환자 대기시간은 얼마나 줄까? 새 교차로 신호 체계는 출퇴근 정체를 완화할까? 이런 질문들의 공통점은, 답을 알려면 시스템을 실제로 바꿔봐야 하는데 그러기엔 너무 비싸거나 위험하거나 아예 불가능하다는 것이다. 시뮬레이션은 바로 이 빈자리를 메운다. 컴퓨터 안에 시스템의 모형을 만들어 시간에 따라 돌려보고, 실제로 건드리기 전에 “만약 이렇게 하면?”을 안전하게 실험한다.

이 글은 시뮬레이션 시리즈의 출발점으로, 시뮬레이션이 무엇이고, 언제 쓰는 것이 맞고, 어떤 절차로 진행하는지를 큰 그림으로 잡는다. 개별 기법(난수·DES·통계 분석)은 이후 글들에서 하나씩 펼친다.

시뮬레이션이란 무엇인가

시뮬레이션(simulation)은 실제 시스템의 모델을 만들어, 그 모델을 시간에 따라 모방 실행함으로써 시스템의 거동을 관찰·분석하는 기법이다. 여기서 핵심 단어는 셋이다.

• 모델(model): 실제 시스템을 단순화한 표현. 현실의 모든 것을 담지 않고, 우리가 답하려는 질문에 필요한 부분만 추린다.
• 시간(time): 시스템이 시간에 따라 어떻게 전개되는지를 따라간다. 정적인 사진이 아니라 동영상에 가깝다.
• 모방 실행(execution): 모델을 실제로 “돌려서” 가상의 데이터를 만들어 낸다. 이 데이터를 분석해 결론을 얻는다.

흔한 오해 하나를 짚자. 시뮬레이션은 “정답”을 계산해 주는 도구가 아니다. 시뮬레이션을 한 번 돌려 나온 평균 대기시간 “12.3분”은 정답이 아니라 하나의 표본(sample)일 뿐이다. 무작위성이 들어간 모델은 돌릴 때마다 다른 숫자를 내놓는다. 그래서 시뮬레이션 결과는 늘 통계적으로 해석해야 하며, 이 점이 시리즈 후반부(output analysis)의 핵심 주제가 된다.

왜, 언제 시뮬레이션을 쓰나

시스템을 분석하는 방법이 시뮬레이션만 있는 것은 아니다. 가능하다면 해석적(analytical) 방법 — 즉 수식으로 닫힌 해(closed-form)를 구하는 것 — 이 거의 항상 더 낫다. 정확하고, 빠르고, 일반적인 통찰을 준다.

예를 들어 도착이 포아송 과정이고 서비스 시간이 지수분포인 단일 서버 대기열(M/M/1)에서는, 시스템 안에 머무는 평균 손님 수(대기 중 + 서비스 중)가

$$L=\frac{\rho }{1-\rho },\rho =\frac{\lambda }{\mu }$$

라는 깔끔한 공식으로 바로 나온다(여기서 $\lambda$는 도착률, $\mu$는 서비스율, $\rho$는 이용률). 이런 공식이 있으면 시뮬레이션은 필요 없다. 손으로 계산하면 끝이다.

문제는 현실이 이런 깔끔한 가정을 거의 따르지 않는다는 데 있다. 서비스 시간이 지수분포가 아니라 제멋대로이고, 손님에 우선순위가 있고, 서버가 가끔 고장 나고, 여러 단계가 서로 얽혀 있으면 — 닫힌 해는 곧 존재하지 않게 된다. 바로 이 지점에서 시뮬레이션이 등장한다. 수식으로 풀 수 없을 만큼 복잡한 시스템도, 규칙만 정확히 기술하면 컴퓨터가 끝까지 따라가 줄 수 있기 때문이다.

시뮬레이션이 특히 알맞은 상황을 정리하면 다음과 같다.

• 시스템이 너무 복잡해 해석적 해가 없을 때: 무작위성, 동적 상호작용, 비선형성이 얽혀 수식이 손을 들 때.
• 실제 실험이 위험·고비용·불가능할 때: 가동 중인 공장 라인을 멈춰 실험할 수는 없다. 대신 모델로 what-if를 돌린다.
• 시간 척도를 마음대로 조절하고 싶을 때: 수년치 운영을 몇 초로 압축하거나, 반대로 찰나의 현상을 느리게 펼쳐 관찰할 수 있다.
• 시스템을 짓기 전에 설계를 검증하고 싶을 때: 아직 존재하지 않는 공장·서비스도 모델로 미리 돌려볼 수 있다.

반대로, 시뮬레이션을 피해야 할 때도 분명히 있다.

• 닫힌 해나 간단한 계산으로 충분하다면 — 그것을 써라. 시뮬레이션은 과한 도구다.
• 모델·데이터 구축 비용이 그로부터 얻을 통찰보다 크다면.
• 모델을 검증(validation)할 현실 데이터가 전혀 없다면 — 그럴듯해 보이지만 틀린 모델은 잘못된 의사결정을 정당화하는 가장 위험한 도구가 된다.

시뮬레이션의 장단점

장점	단점
해석 불가능한 복잡한 시스템도 다룰 수 있다	결과가 통계적 추정치라, 신중한 분석이 필요하다
실제를 건드리지 않고 안전하게 실험한다	좋은 모델·데이터를 만드는 데 시간·비용이 든다
시간을 압축·확장해 관찰할 수 있다	검증을 게을리하면 “그럴듯하지만 틀린” 답을 준다
설계 단계에서 미리 평가할 수 있다	통찰이 닫힌 해만큼 일반적이지 않다(특정 시나리오의 수치)

요점은, 시뮬레이션은 만능이 아니라 트레이드오프라는 것이다. 표현력을 얻는 대신 통계적 분석과 검증의 부담을 진다. 이 부담을 제대로 다루는 법이 이 시리즈가 4부에서 집중적으로 다룰 내용이다.

시뮬레이션 연구의 절차

시뮬레이션은 “코드를 짜서 돌린다”가 전부가 아니다. 신뢰할 수 있는 결론을 얻으려면 다음과 같은 단계를 밟는다(Banks 등의 고전적 정리를 단순화한 것이다).

1. 문제 정의·목표 설정    무엇을 답하려 하는가? 성능 지표는?
        │
2. 모델 개념화           어떤 요소·규칙을 담고 무엇을 버릴까 (conceptual model)
        │
3. 데이터 수집           도착 간격·서비스 시간 등 입력 분포의 근거
        │
4. 모델 구현             개념 모델을 코드로 (DES 엔진/SimPy 등)
        │
5. Verification          코드가 개념 모델대로 동작하는가? (모델을 "맞게 만들었나")
        │
6. Validation            모델이 현실을 충분히 반영하는가? (맞는 모델을 만들었나)
        │
7. 실험 설계             어떤 시나리오를, 몇 번, 얼마나 길게 돌릴까
        │
8. 실행·분석             결과를 통계적으로 분석 (신뢰구간·비교)
        │
9. 문서화·의사결정        결론을 정리하고 실제 결정에 반영

이 흐름에서 특히 5번 verification과 6번 validation의 구분은 초보자가 가장 자주 놓치는 부분이다. 전자는 “내가 의도한 모델을 코드로 올바르게 옮겼는가”(building the model right)이고, 후자는 “그 모델이 애초에 현실을 제대로 본떴는가”(building the right model)이다. 코드가 버그 없이 완벽해도, 가정이 현실과 다르면 결과는 무의미하다. 이 둘은 별도의 글에서 깊이 다룬다.

또 하나, 위 절차의 3번(데이터)→6번(검증)→8번(분석)은 본질적으로 통계의 문제다. 그래서 이 시리즈는 시뮬레이션을 단순한 프로그래밍이 아니라 실험과학에 가까운 것으로 본다. 모수 추정과 가설검정 같은 통계 기초가 곳곳에서 다시 등장할 것이다.

정리

• 시뮬레이션은 시스템의 모델을 시간에 따라 모방 실행해 거동을 분석하는 기법이다. 결과는 정답이 아니라 통계적 표본이다.
• 닫힌 해가 있으면 그것을 쓰고, 복잡성·무작위성·상호작용 때문에 수식으로 풀 수 없거나 실제 실험이 위험·고비용일 때 시뮬레이션이 빛난다.
• 표현력을 얻는 대신 통계 분석과 검증의 부담을 진다. 이 부담을 다루는 방법론이 시뮬레이션을 신뢰할 수 있게 만든다.
• 제대로 된 시뮬레이션은 문제 정의 → 모델링 → 데이터 → verification → validation → 실험 → 분석의 절차를 따르는 실험과학이다.

다음 글에서는 시뮬레이션 모델을 어떻게 분류하는지, 그리고 DES·연속·Monte Carlo·agent-based 같은 주요 패러다임이 각각 무엇을 잘하는지 지도를 그린다.