“고정 시간 간격이면 다 해결된다?” 게임 루프 설계의 진짜 승부

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

캐릭터가 같은 속도로 달리는데 고주사율 모니터에서는 빨라지고, 프레임이 한 번 끊긴 뒤에는 물체가 벽을 뚫고 지나갑니다. 이런 현상을 렌더링 최적화 문제로만 보면 원인을 놓치기 쉽습니다. 실제 승부처는 게임 프로그래밍의 시간 처리 방식, 즉 고정 시간 간격과 가변 시간 간격 중 무엇을 어디에 적용했느냐에 있습니다.

두 방식 가운데 하나가 언제나 우월한 것은 아닙니다. 물리 시뮬레이션과 재현성이 중요하다면 고정 방식이 강하지만, 화면 반응성과 단순한 구조가 우선이라면 가변 방식도 충분히 실용적입니다. 중요한 것은 유명 엔진의 기본값을 따르는 일이 아니라, 게임의 규칙과 실패 비용을 기준으로 선택하는 것입니다.

고정 시간 간격 vs 가변 시간 간격, 무엇이 실제로 달라질까

고정 방식은 예측 가능성을 사고, 처리 지연을 감수합니다

고정 시간 간격(Fixed Timestep)은 시뮬레이션을 일정한 간격으로 갱신합니다. 예를 들어 60Hz라면 한 번의 업데이트가 약 16.67ms의 게임 시간을 담당합니다. 실제 화면이 초당 90번 그려지든 45번 그려지든 물리, 충돌, 이동 규칙은 동일한 간격으로 계산되므로 결과를 비교하고 재현하기가 쉽습니다.

이 방식은 충돌 판정, 차량 움직임, 격투 게임의 판정 프레임처럼 작은 시간 차이가 결과를 바꾸는 시스템에 특히 유리합니다. 동일한 입력을 동일한 틱에 넣으면 비슷한 결과를 얻을 가능성이 높아져 리플레이, 서버 검증, 테스트 자동화에도 도움이 됩니다. 다만 렌더링 프레임 사이에 시뮬레이션이 여러 번 실행될 수 있으므로 CPU 부하가 갑자기 커지는 상황을 대비해야 합니다.

• 장점: 물리 계산의 안정성이 높고 버그 재현이 쉬우며 틱 단위 설계가 명확합니다.
• 단점: 프레임이 늦어지면 한 화면 안에서 업데이트를 여러 번 수행해야 하며, 보간이 없으면 움직임이 끊겨 보일 수 있습니다.
• 잘 맞는 장르: 대전 액션, 레이싱, 정밀 플랫포머, RTS처럼 판정의 일관성이 중요한 게임입니다.
• 설계 포인트: 30Hz, 60Hz, 120Hz 중 높은 값을 무조건 고르지 말고 목표 기기에서 틱 한 번의 최대 비용을 측정해야 합니다.

가변 방식은 즉각적인 흐름을 얻지만 오차 관리가 필요합니다

가변 시간 간격(Variable Timestep)은 이전 프레임부터 현재 프레임까지 실제로 흐른 시간인 delta time을 사용합니다. 코드가 직관적이고 렌더링과 업데이트를 한 루프에서 처리하기 쉬워 프로토타입이나 물리 의존도가 낮은 게임에서 빠르게 적용할 수 있습니다. 카메라 연출, UI 애니메이션, 파티클 수명처럼 화면 시간에 맞춰 흘러야 하는 요소에도 자연스럽습니다.

문제는 프레임 시간이 크게 흔들릴 때 나타납니다. 16ms 동안의 이동을 한 번 계산하는 것과 8ms 이동을 두 번 계산하는 것은 복잡한 충돌이나 감쇠 연산에서 완전히 같은 결과를 보장하지 않습니다. 부동소수점 오차까지 누적되면 기기마다 결과가 달라질 수 있으므로 delta time에 상한을 두고, 프레임 독립적인 수식을 사용해야 합니다.

프레임률 독립이란 모든 코드에 delta time을 곱하는 것이 아닙니다. 시간에 비례해야 하는 값과 틱마다 한 번만 적용할 값을 먼저 구분하는 일이 출발점입니다.

한쪽만 고집하지 않는 하이브리드 게임 루프 설계

물리는 고정하고 화면은 보간하면 두 장점을 함께 얻습니다

실무에서 가장 균형이 좋은 방법은 시뮬레이션을 고정 틱으로 실행하고 렌더링은 가능한 속도로 그리는 구조입니다. 매 프레임 실제 경과 시간을 누산기에 더한 뒤, 누적 시간이 고정 간격보다 크면 시뮬레이션을 한 번씩 진행합니다. 업데이트가 끝나고 남은 시간을 고정 간격으로 나눈 비율을 이용해 이전 상태와 현재 상태 사이를 보간하면 화면도 부드러워집니다.

예를 들어 60Hz 시뮬레이션에서 누산기에 10ms가 남았다면 보간 계수는 약 0.6입니다. 렌더러는 물체의 이전 위치와 현재 위치 사이 60% 지점을 보여줄 수 있습니다. 이때 보간된 위치를 다시 물리 상태에 기록하면 안 됩니다. 시뮬레이션 원본과 화면 표현용 값을 분리해야 누적 오차와 떨림을 막을 수 있습니다.

1. 프레임 시작 시 고정밀 타이머로 실제 경과 시간을 구합니다.
2. 일시 정지 복귀나 디버거 중단에 대비해 프레임 시간의 상한을 100~250ms 범위에서 정합니다.
3. 누산기가 고정 간격 이상인 동안 입력을 소비하고 시뮬레이션을 갱신합니다.
4. 한 프레임에서 허용할 최대 업데이트 횟수를 정해 무한한 따라잡기를 차단합니다.
5. 남은 시간의 비율로 렌더링 상태만 보간하고, 확정된 게임 상태는 수정하지 않습니다.

입력, 네트워크, 애니메이션은 서로 다른 시계를 원합니다

키보드와 패드 입력은 렌더 프레임에서 자주 수집하되, 게임 규칙에는 어느 틱에서 적용됐는지 기록하는 편이 안전합니다. 반면 UI 전환과 메뉴 애니메이션은 게임이 일시 정지됐을 때도 움직여야 할 수 있으므로 시뮬레이션 시간이 아닌 실제 시간을 사용하는 것이 낫습니다. 네트워크는 서버 틱과 패킷 도착 시간이 따로 존재하므로 또 하나의 시간축으로 취급해야 합니다.

이런 구분은 코드가 복잡해 보이지만 책임을 명확하게 만듭니다. 게임 기획자의 역할에 관한 지식백과 설명처럼 게임 규칙과 사용자 경험은 여러 직군의 의사결정이 만나는 영역입니다. 프로그래머는 “시간 배율 0이면 무엇이 멈추고 무엇이 계속되는가”를 기획자와 먼저 합의해야 합니다.

• 시뮬레이션 시계: 이동, 충돌, 전투 판정처럼 게임 세계의 규칙을 담당합니다.
• 렌더링 시계: 카메라 보간, 시각 효과, 프레임 사이의 표현을 담당합니다.
• 실시간 시계: 로딩 표시, 연결 제한 시간, 운영 이벤트처럼 게임 배율과 무관한 기능에 씁니다.
• 네트워크 시계: 서버 틱 번호, 스냅샷 시점, 입력 순서를 맞추는 기준입니다.

시간 시스템의 API에는 단순한 deltaTime 하나만 두지 말고 fixedDelta, unscaledDelta, tickIndex처럼 의미가 드러나는 값을 제공하세요. 호출부에서 잘못된 시계를 선택하는 실수가 크게 줄어듭니다.

프레임 드롭에서 드러나는 세 가지 설계 실수

평균 FPS만 재면 시간 버그를 발견할 수 없습니다

첫 번째 실수는 평균 프레임률이 높다는 이유로 게임 루프가 안정적이라고 판단하는 것입니다. 평균 120FPS여도 자동 저장이나 셰이더 컴파일 순간에 180ms가 걸리면 가변 방식의 물체가 터널링을 일으킬 수 있습니다. 테스트에서는 평균값보다 프레임 시간의 상위 백분위, 최대 연속 지연, 한 프레임에 수행된 고정 업데이트 횟수를 함께 기록해야 합니다.

두 번째 실수는 느려진 시간을 모두 따라잡으려는 것입니다. 한 프레임이 늦어져 업데이트가 밀리고, 밀린 업데이트를 처리하느라 다음 프레임도 늦어지는 현상을 흔히 ‘죽음의 나선’이라고 부릅니다. 최대 4~8회처럼 틱 처리 한도를 두고, 초과 상황에서는 품질을 낮추거나 관측 가능한 경고를 남겨야 합니다. 국제 게임 개발 흐름과 기술 발표가 모이는 GDC의 배경과 성격을 살펴보면 게임 기술이 단순한 코드 기법을 넘어 측정과 공유의 문제라는 점도 이해하기 쉽습니다.

• 실수 1, delta time 무제한 사용: 창을 끌거나 절전 모드에서 돌아온 직후 수 초가 한 번에 적용됩니다. 상한을 정하고 복귀 이벤트에서 누산기를 초기화해야 합니다.
• 실수 2, 위치는 보간하면서 회전은 방치: 캐릭터 몸체는 부드럽지만 조준점이 떨립니다. 위치, 회전, 카메라 기준점에 일관된 보간 정책을 적용해야 합니다.
• 실수 3, 틱 속도를 상수로 흩뿌리기: 코드 곳곳의 0.016f가 서로 다른 의미로 사용됩니다. 시간 설정을 한곳에서 관리하고 단위가 초인지 밀리초인지 타입과 이름으로 드러내야 합니다.

의도적인 악조건이 두 방식의 약점을 빠르게 보여줍니다

개발용 빌드에는 50ms, 100ms, 200ms의 인위적 지연을 주기적으로 삽입하는 기능을 두는 것이 좋습니다. 여기에 렌더링 속도를 30FPS와 144FPS로 번갈아 제한하고, 동일한 입력 스크립트를 실행해 최종 위치와 충돌 횟수를 비교해 보세요. 고정 방식이라면 틱 수와 상태 해시가 예상대로 유지되는지, 가변 방식이라면 큰 delta에서도 속도와 감쇠가 폭주하지 않는지 확인할 수 있습니다.

모든 시스템을 고정 틱으로 옮기는 것도 흔한 과잉 대응입니다. 배경 장식, 메뉴 커서, 단순 페이드까지 물리 틱에 묶으면 높은 주사율에서 시각적 이점이 사라지고 일시 정지 처리도 까다로워집니다. 반대로 충돌과 전투 판정까지 가변 시간에 맡기면 테스트 기기에서는 멀쩡하던 버그가 저사양 환경에서만 나타날 수 있습니다. 게임 규칙은 고정 시간, 표현은 렌더링 시간, 현실의 제한은 비배율 시간이라는 기본선을 세운 뒤 예외를 문서화하는 편이 가장 관리하기 쉽습니다.

1. 30초 동안 같은 입력을 재생하고 틱별 위치, 속도, 상태 해시를 저장합니다.
2. 프레임 제한과 강제 지연 조건을 바꿔도 고정 틱 결과가 일치하는지 비교합니다.
3. 보간을 끈 화면과 켠 화면을 나란히 녹화해 떨림이 물리 문제인지 표현 문제인지 분리합니다.
4. 업데이트 한도 초과 횟수를 텔레메트리에 남겨 실제 사용자 환경의 위험 구간을 찾습니다.
5. 시간 배율 0, 0.5, 2.0에서 UI와 네트워크 제한 시간이 의도대로 작동하는지 검증합니다.