물리 엔진

물리 엔진 Physics Engine
분야	게임 개발 × 실시간 시뮬레이션 × 수치해석
핵심 구성	강체 동역학, 충돌 감지, 제약 해결기, 시간적분
대표 엔진	PhysX, Havok, Bullet, Box2D
시간 예산	16.6ms (60fps 기준)
제1원칙	맞는 것보다 그럴듯한 것

1. 개요[편집]

정확할 필요는 없다. 다만 16.6밀리초 안에 끝나야 하고, 폭발하지 말아야 한다.

물리 엔진(physics engine)은 게임을 비롯한 실시간·인터랙티브 응용에서 물체의 운동, 충돌, 접촉 같은 물리 현상을 근사적으로 시뮬레이션하는 소프트웨어다. 뉴턴 역학의 법칙을 수치적으로 적분해 매 프레임마다 물체의 위치와 속도를 갱신하며, 상자가 쌓이고 공이 튀고 캐릭터가 넘어지는 것을 “물리적으로 그럴듯하게” 만들어 준다. 여기서 방점은 그럴듯함에 찍혀 있다 — 전산유체역학이나 구조해석 같은 CAE 해석이 “맞는 답”을 추구한다면, 물리 엔진은 “관객을 속일 수 있는 답”을 정해진 시간 안에 뽑아내는 것이 목표다.¹

플레이어는 래그돌이 계단을 굴러 내려가는 장면을 보고 나비에-스토크스 방정식의 오차한계 따위를 검증하지 않는다. 그럴듯하게 굴러떨어지기만 하면 된다. 대신 굴러떨어지다 말고 화면 밖으로 로켓처럼 발사되면 곤란하다. 이 미묘한 균형 — 정확도는 포기하되 안정성과 시각적 개연성은 사수하는 것 — 이 물리 엔진 설계의 전부라 해도 과언이 아니다.

2. 구성 요소[편집]

물리 엔진은 대체로 네 개의 하위 시스템이 매 프레임 돌아가는 파이프라인으로 구성된다.

단계	하는 일	대표 기법
강체 동역학	힘·토크로 위치·자세 갱신	뉴턴-오일러 방정식
충돌 감지	겹친 물체 쌍과 접촉점 판정	broad/narrow phase
제약 해결기	침투 해소, 관절·접촉 구속	순차 임펄스, PGS
시간적분	다음 프레임 상태 전진	베를레 적분, 심플렉틱 오일러

2.1. 강체 동역학[편집]

대부분의 게임 물리는 물체를 변형하지 않는 강체(rigid body)로 취급한다. 물렁한 젤리나 펄럭이는 천은 별도의 특수 처리(연체·천 시뮬레이션)를 요구하며, 강체 가정은 자유도를 위치 3 + 자세 3으로 줄여 계산을 극적으로 싸게 만든다. 질량중심의 병진 운동은 $\mathbf{F} = m\mathbf{a}$, 회전 운동은 오일러 방정식으로 다룬다.

2.2. 제약 해결기[편집]

두 상자가 서로 파고들었을 때 이를 밀어내고, 경첩·관절이 분해되지 않게 붙들어 두는 것이 제약 해결기(constraint solver)의 몫이다. 현실의 강체는 절대 겹치지 않지만, 이산 시간 시뮬레이션에서는 매 프레임 물체가 살짝 겹친 상태로 발견되는 것이 정상이다. 해결기는 이 침투를 임펄스로 밀어내는데, 대개 정확히 푸는 대신 순차 임펄스(sequential impulse)나 PGS(Projected Gauss-Seidel)를 몇 번 반복(iteration)해 “충분히 그럴듯한” 근사에서 멈춘다. 반복 횟수를 늘리면 관절이 단단해지지만 그만큼 프레임 예산을 갉아먹는다.

3. 실시간이라는 족쇄[편집]

물리 엔진과 CAE 솔버를 가르는 결정적 차이는 시간 예산이다. 60fps 게임에서 한 프레임에 허용되는 시간은 약 16.6ms이며, 이 중 물리에 배정되는 몫은 렌더링·AI·오디오와 나눠 가진 뒤 남은 몇 밀리초에 불과하다. 반면 CFD 해석은 하룻밤을 꼬박 돌려도 아무도 뭐라 하지 않는다.

이 족쇄가 낳은 설계 원칙이 몇 가지 있다.

• 고정 timestep — 프레임 시간에 따라 적분 간격을 들쭉날쭉 바꾸면 시뮬레이션이 불안정해지고 재현성이 깨진다. 그래서 대부분의 엔진은 물리를 고정된 간격(예: 1/60초)으로 돌리고, 실제 프레임 시간과의 차이는 누적 후 여러 번 스텝을 밟거나(accumulator 패턴) 렌더링 단계에서 보간한다.²
• 안정성 우선 — 큰 timestep이나 빠른 물체에서 수치적으로 폭발하느니, 부정확하더라도 얌전히 감쇠하는 편이 낫다. 베를레 적분이나 심플렉틱 오일러가 정확도가 더 높은 고차 룽게-쿠타법보다 선호되는 이유가 여기 있다 — 장기 에너지 거동이 안정적이기 때문.
• 그럴듯함 우선 — 관통을 완벽히 막느니 살짝 겹쳤다가 부드럽게 밀어내는 편이 시각적으로 더 자연스럽다. 오차는 다음 프레임에 씻겨 나간다.

“게임 물리는 물리학이 아니라, 물리학인 척하는 예술이다.”

4. 결정론과 네트워크 동기화[편집]

멀티플레이어 게임에서 물리 엔진의 골칫거리는 결정론(determinism)이다. 같은 입력을 넣으면 어느 기기에서든 완전히 똑같은 결과가 나와야, 각 클라이언트가 물리를 각자 굴려도 세계가 어긋나지 않는다(lockstep 방식). 문제는 부동소수점 연산이 CPU 아키텍처·컴파일러·최적화 플래그에 따라 마지막 비트가 미묘하게 달라진다는 것.³ 이 티끌만 한 차이가 카오스적으로 증폭되어, 한쪽 화면에선 승리한 유닛이 다른 화면에선 폭사하는 참사로 번진다.

그래서 실무에서는 (1) 물리를 서버에서만 굴리고 결과를 뿌리거나, (2) 정수·고정소수점 연산으로 갈아엎어 결정론을 강제하거나, (3) 주기적으로 상태를 스냅샷 동기화(snapshot / state reconciliation)하는 타협을 쓴다. RTS는 lockstep, FPS는 서버 권위(server authoritative) 쪽으로 기우는 편.

5. 대표 엔진들[편집]

• PhysX — NVIDIA가 소유한 사실상의 업계 표준. Unreal Engine과 오랫동안 결합돼 있었고 GPU 가속을 지원한다.
• Havok — 콘솔 AAA 게임의 오랜 강자. 마이크로소프트가 인수했다.
• Bullet — 오픈소스의 대표주자. 게임뿐 아니라 로보틱스·영화 VFX·강화학습 시뮬레이션(PyBullet)에서도 널리 쓰인다.
• Box2D — 2D 물리의 교과서. 앵그리버드가 이걸로 새를 날렸다. 코드가 깔끔해 물리 엔진 공부의 입문서로도 통한다.

6. 해석 소프트웨어와의 철학 차이[편집]

물리 엔진을 구조해석이나 유한요소법 기반 CAE 솔버와 같은 선상에 놓으면 안 된다. 둘은 애초에 지향점이 다르다.

항목	물리 엔진	CAE 해석 (FEM/CFD)
목표	그럴듯함	정확성
시간 제약	실시간 (16.6ms)	오프라인 (시간~일)
적분기	저차·심플렉틱, 안정성 위주	고차·적응형, 정확도 위주
물체 모델	주로 강체	변형체·연속체
실패 모드	래그돌 폭발	발산·미수렴

한마디로, 전산유체역학 엔지니어가 밤새 격자 품질과 잔차 그래프에 시달릴 때, 게임 물리 프로그래머는 “왜 캐릭터가 바닥을 뚫고 지구 반대편으로 빠졌는가”를 디버깅한다. 같은 뉴턴 방정식에서 출발했지만 도착지는 정반대다.

7. 관련 문서[편집]

• 충돌 감지
• 베를레 적분
• 룽게-쿠타법
• 구조해석 · 유한요소법
• 전산유체역학
• SPH

8. Footnotes[편집]

1. 영화 VFX용 시뮬레이션은 중간 지대에 있다. 실시간은 아니지만 물리적 정확성보다 “감독이 원하는 그림”이 우선한다는 점에서 게임 물리와 철학을 공유한다. 즉 물속에서 폭발이 예쁘게 보이면 그게 정답이다. ↩

2. Glenn Fiedler의 유명한 글 “Fix Your Timestep!”(2004)이 이 패턴의 성경으로 통한다. 가변 timestep으로 물리를 굴리다 프레임 드랍 때 시뮬레이션이 터지는 것은 초보 물리 프로그래머의 통과의례다. ↩

3. 특히 x87 FPU의 80비트 확장 정밀도, SSE로의 전환, fma(fused multiply-add) 명령어의 유무가 결정론을 깨는 단골 원인이다. “우리 게임은 크로스플랫폼 결정론을 보장합니다”라는 문장은 엔진 프로그래머에게 협박에 가깝게 들린다. ↩