---
title: "게임 일시정지는 어떻게 구현되나 — timescale 0 회피, 스크린샷 꼼수, 7단계 pause의 지옥"
published: 2026-04-16T14:05:10.000Z
canonical: https://jeff.news/article/1816
---
# 게임 일시정지는 어떻게 구현되나 — timescale 0 회피, 스크린샷 꼼수, 7단계 pause의 지옥

게임 개발자들이 pause 구현 경험을 공유했다. Unity의 timescale=0 특수 동작을 피하려 0.000000001배로 설정하거나, 스크린샷을 찍고 플레이어를 빈 방으로 순간이동시키는 등 꼼수가 만연했다. 콘솔 TRC 요구사항 때문에 pause가 7단계로 늘어나며 충돌하는 경우도 흔하다.

- Kotaku가 게임 개발자들에게 "게임 일시정지는 어떻게 구현하나요?" 물어봤더니, 답변이 **예상보다 훨씬 엉망진창** — 시간을 진짜로 거의 멈추거나, 몰래 스크린샷 찍고 방을 치우거나
- 핵심 발견: 현대 게임 엔진은 pause를 기본 지원하지만, 실제 현장에서는 **"healthy dose of hackyness"**(적당한 꼼수)가 항상 섞여 있음

### 타임스케일 0을 피하는 꼼수
- `Waves of Steel` 개발자 Chris Weisiger: 일시정지 시 게임 속도를 **0.000000001배**로 설정
  - 이유: Unity가 timescale=0일 때 특수 동작을 하는데, 이걸 피하고 싶었음
  - 계산해보면 실시간 3년에 게임 시간 1초 정도 흐름 — 사실상 정지
- Unreal 취미 개발자 Tommy Hanusa: `.000001`로 설정
  - 이유는 더 엉뚱 — pause 중에도 테스터가 카메라를 "말도 안 되는 속도(5000000)"로 날려서 버그 현장을 보여줄 수 있도록
- 많은 개발자는 그냥 timescale=0으로 맞추되, 메뉴 UI 같은 함수들이 이 설정을 무시하도록 처리

### Pause는 한 종류가 아니었다 — 7단계 pause의 지옥
- Frontier에서 Kinectimals(Xbox 360) 개발했던 Andrew Gillett 증언: 게임에 **pause 종류가 7단계쯤** 있었음
  - 일반 pause (start 버튼)
  - Kinect 카메라 연결 끊김 pause
  - Xbox 시스템 메뉴 pause
  - 컨트롤러 연결 끊김 pause
  - 인벤토리 열림 pause
  - QTE 중 pause 불가 예외
  - ...등등
- Dreamless의 회고: PS2/Xbox 시대에는 처음엔 일반 pause만 만들어놓고, **출시 직전 TRC(Technical Requirements Checklist) 읽다가 "컨트롤러 뽑으면 자동 pause" 요구사항 발견**
  - 급하게 별도 pause 추가 → 두 pause가 서로 충돌하면서 버그 쏟아짐
  - 콘솔 인증 요구사항이 개발 막판에 이런 일 자주 일으킴

### 최고의 꼼수 — 스크린샷으로 시간 얼리기
- DW O'Boyle: pause 시점에 **게임 화면 스크린샷 찍고**, 그걸 pause 메뉴 배경으로 깔고, 진짜 게임 오브젝트는 안 그림
  - 주목적은 메모리 절약
- Vlambeer·Minit·Disc Room 개발자 Jan Willem Nijman의 더 과격한 버전
  - UI 끈 스크린샷 찍기 → **플레이어를 완전히 빈 방으로 순간이동** 시키거나 모든 것 비활성화 → 스크린샷을 배경으로 깔기
  - 일시정지 해제하면 원래 방으로 다시 점프
  - 가끔 1프레임 지연이 생기는데, UI 비활성화 스크린샷 찍는 시간 때문
- "이거 좀 해키하지 않냐"는 반응에 Nijman 왈: "내가 작업한 모든 게임에 꼼수가 적당히 섞여 있어요"

### 모두가 처음엔 망쳤다
- 개발자 Caliban Darklock의 고백: 첫 pause 구현 때 **모든 게임 오브젝트가 매 프레임마다 "지금 pause 상태?"를 체크**하게 만듦
  - 전체 퍼포먼스가 뚝 떨어짐
  - 지금은 오브젝트를 계층 구조로 두고, **최상위 하나만** pause 여부를 체크
- Darklock 코멘트: "대부분의 개발자가 첫 pause 구현은 끔찍하고 지저분하게 하고, 그 뒤로 평생 제대로 합니다"

---

## 기술 맥락

pause 기능이 단순해 보이지만 실제론 **"모든 게임 상태를 동시에 멈추는 건 불가능하다"** 는 게 핵심이에요. 프레임마다 움직이는 수천 개 오브젝트, AI tick, 물리 엔진, 애니메이션, 사운드, UI 이벤트를 한꺼번에 얼리는 건 쉽지 않아요. 그래서 game engine의 timescale(Unity의 `Time.timeScale`, Unreal의 time dilation)을 0이나 거의 0으로 놓는 방식이 보편화됐어요. 이 값을 0으로 하면 엔진이 "정말로 정지"라고 판단해 특수 처리를 하는데, 이게 오히려 버그를 만들기도 해서 몇몇 개발자는 아주 작은 수(0.000000001)로 설정해 회피해요.

두 번째 포인트는 **"pause는 한 종류가 아니다"** 예요. 콘솔 플랫폼은 TRC라는 인증 요구사항을 통해 컨트롤러 연결 끊김·시스템 메뉴·카메라 분리 같은 상황에서 자동 pause를 요구해요. 이걸 지키지 않으면 인증이 안 나서 출시를 못 해요. 개발 막판에 이 리스트 보고 부랴부랴 별도 pause를 추가하다가 기존 pause와 상태 플래그가 엉키는 게 전형적인 실수 패턴이에요.

스크린샷 기법은 **"플레이어가 눈치채지 못하게 백스테이지에서 작업하기"** 에 대한 해킹이에요. pause 중에 적 위치를 초기화하거나 다음 방을 미리 로드하거나 UI를 재배치할 수 있는데, 게임 화면이 살아 있으면 이런 작업이 화면에 드러나거든요. 그래서 스크린샷을 배경으로 깔고 실제 오브젝트를 싹 치우면 그 틈에 뭐든 할 수 있어요. "hacky" 해 보이지만 퍼포먼스·메모리·유연성을 다 잡는 현실적 해법이에요.

## 핵심 포인트

- Unity timescale=0 특수 동작 회피 위해 0.000000001처럼 극단적으로 작은 값 사용
- Kinectimals 개발 시 pause가 7단계 — 카메라 분리·시스템 메뉴·컨트롤러 끊김별 별도 처리
- 콘솔 TRC 요구사항을 막판에 반영하다 pause 간 상태 충돌로 버그 속출
- Vlambeer 스타일 꼼수 — UI 끈 스크린샷 찍고 플레이어를 빈 방으로 텔레포트
- 첫 pause 구현 시 모든 오브젝트가 매 프레임 pause 체크 → 성능 저하 전형 실수

## 인사이트

겉보기엔 버튼 한 번이지만, 실제 현장에서는 엔진 특수 동작 회피·플랫폼 인증 요구사항·성능 최적화·메모리 절약이 뒤엉킨 복잡한 설계 문제. pause 구현만 보면 그 스튜디오의 엔지니어링 성숙도가 보인다는 말이 나올 만하다.