실시간 시뮬레이션

시뮬레이션 수치해석 소프트웨어 마지막 수정: 2026-08-15 04:36:09

1. 개요[편집]

실시간 시뮬레이션 Real-time Simulation
판정 기준	실시간 인자 RTF ≥ 1 이면서 매 스텝 데드라인 준수
등급	하드 / 펌 / 소프트 실시간
필수 조건	고정 스텝 · 유계 최악실행시간 · 오버런 검출
대표 응용	HIL, 모의비행장치, 게임 물리, 디지털 트윈
천적	가변 스텝 적분기 · 동적 메모리 · 강성
실패 신호	조용히 넘어간 데드라인 미스

맞는 답을 늦게 내는 것과 틀린 답을 내는 것은, 여기서는 같은 실패다.

실시간 시뮬레이션(real-time simulation)은 모의하는 물리 시간의 흐름을 실제 벽시계 시간의 흐름에 맞춰 진행시키는 시뮬레이션을 말한다. 오프라인 해석이 “몇 시간이 걸리든 정확한 답”을 목표로 한다면, 실시간 시뮬레이션은 “제시간 안에 나오는 충분히 정확한 답”을 목표로 한다. 사람이나 실물 하드웨어가 루프 안에 들어와 있어서, 결과가 늦으면 그 결과를 쓸 곳이 이미 사라져 버리기 때문이다.

정량 지표는 실시간 인자(real-time factor, RTF)다.

\mathrm{RTF} = \frac{\text{모의된 물리 시간}}{\text{소요된 벽시계 시간}}

$\mathrm{RTF} = 1$ 이면 정확히 실시간, $>1$ 이면 실시간보다 빠름(faster-than-real-time), $<1$ 이면 못 따라가는 상태다. 로보틱스 시뮬레이터들이 화면 구석에 이 숫자를 띄워 두는 이유가 있다. 다만 RTF는 평균 지표라 그것만으로는 부족하다. 평균 RTF가 1.5여도 어떤 스텝 하나가 데드라인을 넘겼다면 그 시뮬레이션은 실시간이 아니다. 실시간성은 속도가 아니라 예측 가능성의 문제다.

2. 하드·펌·소프트[편집]

데드라인을 놓쳤을 때 무슨 일이 벌어지는가로 등급이 갈린다.

등급	데드라인 미스의 결과	예
하드(hard)	시스템 실패. 한 번도 허용되지 않음	비행제어 컴퓨터, 인버터 전류 루프, HIL 랙
펌(firm)	그 결과는 버려지지만 시스템은 계속 감	모의비행장치의 한 프레임, 원격 계측
소프트(soft)	품질만 떨어짐	게임 물리, 시각화, 대화형 편집기

게임의 물리 엔진은 소프트 실시간이다. 한 프레임 늦으면 사용자가 “끊겼네”라고 느끼고 끝이다. 반면 전력전자 HIL은 하드 실시간이라, 스텝 하나를 놓치면 시험 결과 전체를 무효로 처리한다. 같은 “실시간”이라는 단어가 붙어 있지만 요구되는 엔지니어링 강도는 두 자릿수 차이가 난다. 문서를 읽을 때 이 등급을 먼저 확인하지 않으면 서로 다른 이야기를 하게 된다.

하드 실시간이 요구하는 것은 평균 성능이 아니라 최악실행시간(WCET)의 상한이다. 그래서 하드 쪽에서는 동적 메모리 할당, 가비지 컬렉션, 조건 분기가 많은 룩업 보간, 예측 불가능한 캐시 거동이 전부 제거 대상이 된다. 평균을 20% 개선하는 최적화보다 최악을 5% 줄이는 최적화가 값나가는 세계다.

3. 고정 스텝이 국룰인 이유[편집]

수치해석 교과서는 국소 오차를 보고 스텝을 조절하는 가변 스텝 적분기를 권한다. 실시간에서는 그게 그대로 금기가 된다. 스텝을 줄이는 순간 그 프레임의 계산량이 폭증하는데, 하필 그 순간은 물리가 험해진 순간(충돌, 스위칭, 급기동)이라 다른 부하도 같이 몰린다. 오차가 커질 때 시간도 같이 넘긴다는 최악의 상관관계다.

그래서 실시간 시뮬레이션은 예외 없이 고정 스텝을 쓴다. 그러면 렌더링·표시 주기와 물리 주기가 안 맞는 문제가 남는데, 표준 처방은 누산기(accumulator) 패턴이다.

accumulator += frameTime
while (accumulator >= dt) { step(dt); accumulator -= dt; }
alpha = accumulator / dt        // 표시용 보간 계수

물리는 항상 고정 $dt$ 로 밟고, 남은 자투리 시간은 표시 단계에서 두 상태를 $\alpha$ 로 보간해 메운다. 여기에 함정이 하나 있다. step(dt) 한 번이 실제로 $dt$ 보다 오래 걸리기 시작하면 누산기가 더 빨리 차오르고, 그러면 루프가 더 많이 돌고, 그러면 더 느려진다. 이 양의 되먹임이 죽음의 나선(spiral of death)이며, 처방은 한 프레임에 밟을 수 있는 스텝 수에 상한을 두고 초과분은 그냥 버리는 것이다.¹ 버린다는 것은 시뮬레이션 시간이 실제 시간보다 뒤처지는 것을 받아들인다는 뜻이고, 소프트 실시간에서만 허용되는 타협이다.

데드라인을 놓쳤을 때의 선택지는 결국 넷뿐이다 — 중단(하드), 결과 폐기(펌), 뒤처진 채로 계속(소프트), 모델을 깎아 다음 스텝을 싸게(적응적 성능저하). 절대 하면 안 되는 것은 아무 표시 없이 그냥 넘어가는 것이다. 오버런 카운터 없는 실시간 플랫폼은 실시간 플랫폼이 아니며, “결과가 이상한데요”의 상당 부분이 사실 안 본 오버런 로그다.

4. 강성과 적분기 선택[편집]

실시간의 진짜 적은 강성 방정식이다. 계 안에 아주 빠른 모드가 하나라도 있으면 명시적 적분기의 안정 스텝이 그 모드에 묶여 버린다. 고유값 $\lambda$ 의 실수부가 크게 음수면 전방 오일러의 안정 조건은 대략

h \lesssim \frac{2}{|\lambda_{\max}|}

이고, 관심 있는 동역학이 수 Hz여도 어딘가 숨어 있는 100 kHz 모드 하나가 스텝을 마이크로초로 끌어내린다. 오프라인이면 암시적 방법으로 넘어가면 그만인데, 실시간에서는 암시적 방법의 뉴턴 반복 횟수가 유계가 아니라는 것이 곧바로 문제가 된다. 수렴할 때까지 돌린다는 말은 WCET를 포기한다는 말과 같다.

실무의 우회로는 세 갈래다.

반복 횟수를 상수로 못 박는다. 뉴턴 2회, 그걸로 끝. 수렴을 포기하는 대신 시간을 산다. 남은 잔차는 모델링 오차로 간주하고 검증 단계에서 크기를 확인한다.
선형 부분을 정확히 미리 이산화한다. 계의 선형 시불변 부분은 영차 홀드 이산화로 $A_d = e^{AT}$ 를 오프라인에 한 번 계산해 두면, 런타임에는 행렬-벡터 곱 하나로 그 스텝 크기에서 절단오차가 없는 전진이 된다. 안정성 제약이 아예 사라지므로 빠른 모드가 몇 개 있든 상관없어진다. 행렬 지수함수를 시험 시작 전에 구워 두는 이 전략이 전력전자·회로 실시간 솔버의 뼈대다.
모델을 깎는다. 빠른 모드를 준정상 근사로 대수 구속으로 바꾸거나(미분대수방정식), 아예 축소차수모델로 자유도를 줄인다. 실시간화 노동의 대부분이 실은 이 작업이다.

여기에 회로·기계 공통의 트릭이 하나 더 있다. 행렬 구조를 스텝마다 바꾸지 않도록 모델을 설계하는 것. 상태에 따라 강성행렬이 바뀌면 매 스텝 재분해가 필요해 WCET가 망가지므로, 스위치를 미소 인덕턴스로 바꾸거나 접촉을 부드러운 벌칙항으로 바꿔 분해를 한 번만 하도록 만든다. 정확도를 팔아 예측 가능성을 사는 거래이며, 실시간 모델링의 정신 그 자체다.²

5. 결정론[편집]

실시간과 자주 혼동되지만 별개인 요구가 결정론이다. 같은 입력에 항상 같은 출력이 나오는 성질로, 실시간이면서 비결정적일 수도, 결정적이면서 느릴 수도 있다. 그런데 실무에서는 둘이 늘 같이 요구된다.

HIL·인증 시험 — 같은 시나리오를 다시 돌렸을 때 결과가 다르면 결함 재현이 불가능하고, 시험 증거로서의 가치가 사라진다.
네트워크 게임 — 각 클라이언트가 물리를 각자 굴리는 lockstep 구조에서는 마지막 비트까지 같아야 세계가 안 갈라진다.
디버깅 — 100번에 1번 나는 버그를 잡으려면 그 100번째를 재생할 수 있어야 한다.

결정론을 깨는 범인은 대개 부동소수점 자체가 아니라 순서다. 스레드 수에 따라 달라지는 리덕션 합산 순서, 해시 순회 순서, 컴파일러의 FMA 결합·재배열, 프레임 시간에 의존하는 스텝 크기. 그래서 결정론이 필요한 시스템은 스레드 분할을 고정하고, 리덕션을 결정론적 트리로 짜고, 무엇보다 스텝 크기를 실제 경과 시간에 의존시키지 않는다. 고정 스텝이 실시간뿐 아니라 결정론에도 전제조건인 이유다.

6. 어디에 쓰이나[편집]

하드웨어 인 더 루프 — 실물 제어기 하나만 남기고 플랜트를 실시간 솔버로 대체한다. 차량·항공은 1 ms, 전력전자는 마이크로초 이하 스텝을 요구한다. 실시간 시뮬레이션이 가장 엄격하게 요구되는 무대.
비행 시뮬레이터 — 조종사가 루프 안에 있으므로 지연이 곧 조종 특성의 왜곡이다. 전기체 모의비행장치 규격은 조종 입력부터 시각·운동 응답까지의 전달 지연에 100 ms 급 상한을 못박아 두고 있으며, 이 예산 안에 비행역학 적분·영상 생성·모션 플랫폼 구동이 전부 들어가야 한다.³
디지털 트윈 — 실물에서 올라오는 계측을 받아 모델을 같은 시간축으로 돌리며 상태를 추정하고 예측한다. 여기서는 칼만 필터류 추정기와 모델 예측 제어가 실시간 예산을 나눠 쓰는데, MPC는 매 스텝 최적화 문제를 풀어야 해서 “반복 횟수 상한” 문제를 정면으로 만난다.
게임·실시간 렌더링 — 가장 느슨한 소프트 실시간이지만 가장 많은 사람이 만난다. 16.6 ms 예산을 물리·AI·오디오·렌더가 나눠 쓰고, 부족하면 프레임 생성이나 축소차수모델에 해당하는 온갖 LOD로 메운다.
이산 사건 쪽 — 위의 예들은 전부 시간 구동(time-driven)이지만, 상태 변화가 드문드문 일어나는 계는 이벤트 구동 시뮬레이션으로 다음 사건 시각까지 시간을 건너뛰는 편이 훨씬 싸다. 실시간 제약과 결합하면 “다음 사건까지 남는 시간을 실제로 자면서 기다리는” 구조가 된다.

7. 현업에서의 현실[편집]

실시간화 작업의 90%는 알고리즘 최적화가 아니라 모델 깎기다. 오프라인 상세 모델을 그대로 올려서 실시간이 나오는 경우는 없다시피 하고, 어디를 깎아도 되는지를 아는 사람이 프로젝트의 병목이 된다.
“빠른 CPU를 사면 되지 않냐”는 질문에 대한 답은 대체로 아니오다. 하드 실시간에서 필요한 것은 처리량이 아니라 지터가 없는 것이라, 범용 OS 위의 빠른 CPU보다 실시간 운영체제 위의 느린 CPU가 낫다. 클럭보다 인터럽트 지연과 스케줄러가 중요하다.
스텝 주기, 통신 주기, 제어 주기가 서로 배수 관계가 아니면 비트(beat) 주파수가 생겨 원인 불명의 주기적 이상이 나타난다. 주기 설계는 성능 문제이기 전에 정수론 문제다.
실시간 시뮬레이션의 검증 및 확인은 오프라인 기준해와의 대조로 한다. 같은 모델을 가변 스텝·고정밀로 오프라인에서 돌린 결과를 참값 삼아, 실시간 버전이 얼마나 어긋나는지를 정량화하는 절차가 없으면 “실시간으로 틀린 답”을 얻게 된다. 이게 없는 실시간 모델은 그냥 빠르게 도는 애니메이션이다.

8. 관련 문서[편집]

게임 개발 쪽에서 이 패턴과 그 함정을 정식화해 널리 퍼뜨린 것은 Glenn Fiedler의 “Fix Your Timestep!”(2004)이다. 재미있는 것은 똑같은 구조가 HIL 랙에서도 이름만 “오버런 누적”으로 바뀌어 존재한다는 점. 다만 게임은 몇 프레임 버리고 넘어가고, HIL은 시험을 중단한다. 같은 병에 대한 처방의 차이가 곧 소프트와 하드의 차이다. ↩
오프라인 해석자와 실시간 엔지니어가 서로를 이해하지 못하는 지점이 정확히 여기다. 전자는 “왜 굳이 틀린 모델을 쓰냐”고 묻고, 후자는 “정확한 모델이 제시간에 안 나오면 그건 0점”이라고 답한다. 둘 다 맞는데 목적함수가 다르다. 그래서 실시간 모델에는 “이 근사가 어느 대역까지 유효한가”를 명시한 문서가 반드시 따라붙어야 하고, 그게 없으면 몇 년 뒤 아무도 그 모델을 못 믿게 된다. ↩
규격이 지연 상한을 못박는 이유는 조종사가 지연을 기체 특성으로 오학습하기 때문이다. 지연이 큰 장치에서 훈련한 조종사는 그 지연을 보상하는 조종 습관을 익히고, 실기에서는 그 습관이 그대로 과도 조작(PIO, 조종사 유발 진동)의 씨앗이 된다. 훈련 장비의 지연은 화질 문제가 아니라 안전 문제라는 뜻이다. ↩