---
title: "롤러코스터 타이쿤이 1999년 하드웨어로 수천 명 시뮬레이션 가능했던 이유 (진짜 레전드 최적화)"
published: 2026-03-24T09:03:00.000Z
canonical: https://jeff.news/article/130
---
# 롤러코스터 타이쿤이 1999년 하드웨어로 수천 명 시뮬레이션 가능했던 이유 (진짜 레전드 최적화)

롤러코스터 타이쿤(1999)은 Assembly로 거의 전부 작성된 게임인데, 어떻게 그 시대 하드웨어로 수천 명의 NPC를 끊김 없이 돌릴 수 있었을까? 개발자 Chris Sawyer가 프로그래머이자 게임 디자이너였기 때문에 가능했던 미친 최적화 기법들을 파헤쳐봄. 요즘 빌딩 게임들도 버벅이는 거 생각하면 ㄹㅇ 레전드 수준임.

- **Chris Sawyer**가 거의 혼자 **Assembly**로 작성 → 1999년 기준 이미 사장된 방식인데 혼자 끝까지 밀어붙임 ㄷㄷ
- 돈 값 저장 시 변수마다 **자료형 크기를 다르게 설정** (1바이트~4바이트), 현대 CPU에선 의미 없어서 OpenRCT2에선 전부 8바이트로 통일
- **비트 시프트(bit shifting)**로 곱셈/나눗셈 대체 → 게임 내 공식 자체를 2의 제곱수 기반으로 설계한 거 미쳤는데
- 손님 **길찾기(pathfinding) 알고리즘을 아예 안 씀** → 대신 손님이 무작위로 걷다가 우연히 탈거리 발견하는 구조로 설계
- 손님들끼리 **충돌 판정 없음** → 같은 타일에 수천 명 겹쳐도 되고, 대신 근처 인파 수치로 행복도에만 영향 줌

---

## 상세 내용

### Assembly로 쓴 마지막 대형 게임

**롤러코스터 타이쿤(RollerCoaster Tycoon, RCT)**은 개발자 **Chris Sawyer**가 거의 전부 **어셈블리(Assembly)**로 작성한 게임임. 당시엔 이미 Doom(1993)도 대부분 C로 작성했을 정도로 어셈블리 개발은 사실상 사장된 분위기였는데, 얘는 혼자 끝까지 어셈블리로 밀어붙임. RCT가 이 방식으로 개발된 마지막 대형 게임일 가능성이 높음.

어셈블리 사용의 성능 이점은 당시엔 상당했지만, 현재는 컴파일러 최적화가 워낙 좋아져서 예전만큼 큰 차이가 나진 않음.

### 소스 코드 없어도 OpenRCT2로 역공학 가능

RCT의 소스 코드는 공개된 적 없지만, 팬들이 만든 **오픈소스 재구현 프로젝트 OpenRCT2**가 수년간의 리버스 엔지니어링을 통해 원작을 100% 재현함. 덕분에 내부 코드 구조를 분석할 수 있었고, 이 글에서 소개하는 최적화 사례들도 여기서 확인 가능.

### 자료형도 절약: 상황별 바이트 수 다르게

**돈 값 저장 방식**이 인상적인데, 전체 공원 가치처럼 큰 수는 4바이트, 상점 아이템 가격처럼 작은 수는 **1바이트**만 사용함. 쓸 데 없이 큰 자료형 쓰지 않겠다는 거임. OpenRCT2에선 현대 CPU에서 성능 차이가 없다는 이유로 전부 8바이트로 통일했음.

### 비트 시프트로 곱셈/나눗셈 대체

`value << 2` 같은 **비트 시프트(bit shifting)** 연산을 곱셈/나눗셈 대신 씀.
- `x << 2` = `x * 4`
- `x >> 1` = `x / 2`

2진수 시스템에서 비트를 한 칸 왼쪽으로 밀면 값이 두 배가 되는 원리임. 10진수에서 숫자 뒤에 0 붙이면 10배 되는 것과 같은 원리.

더 놀라운 건 이게 **그냥 코드 트릭이 아니라 게임 설계 자체를 2의 제곱수 기반으로 맞췄다**는 점임. 게임 내 공식에서 9.5 대신 8을 쓰도록 디자인한 거임. 프로그래머가 게임 디자이너한테 "CPU가 좋아하는 숫자로 공식 바꿔주세요"라고 요청하는 건 보통 불가능한 일인데, RCT에선 Chris Sawyer가 둘 다였기 때문에 가능했음.

### 길찾기를 버린 길찾기 설계

일반적인 공원 게임이라면 손님이 타고 싶은 놀이기구를 정하고 → 경로를 계산해서 → 거기까지 이동하는 구조를 쓸 거임. 근데 이건 수천 명 NPC에게 동시에 **A\* 길찾기(pathfinding)**를 돌리는 거라 현대 컴퓨터도 벅찬 작업임.

**RCT의 손님들은 사실상 맹목적으로 랜덤하게 걸어다님.** 탈 거리를 목적지로 정하는 게 아니라, 걷다가 우연히 흥미로운 놀이기구를 발견하면 탑승하는 구조. 갈림길에서는 거의 랜덤으로 방향을 선택하고, 막힌 길만 피하는 아주 단순한 규칙만 사용함.

게임 내에서도 이 "한계"를 실제로 목격할 수 있음. 손님이 배고프다고 불평하면서도 음식 가판대를 찾아가는 게 아니라 그냥 계속 걷다가 우연히 지나치길 기다림 ㅋㅋ

전통적인 길찾기가 필요한 경우(정비사가 고장난 기구 찾아가거나, 손님이 출구 찾을 때)에는 별도로 사용하되, **탐색 깊이 제한**을 걸어둠:
- 일반 손님: 최대 **5개 교차점**까지만 탐색
- 지도를 구매한 손님: **7개**까지 탐색 (지도가 실제로 길찾기 성능을 올려주는 거임 ㄹㅇ)
- 정비사: 더 중요한 NPC라서 **8개**까지 탐색

탐색 한계에 부딪히면 손님이 "출구를 못 찾겠어요"라고 불평하는데, 이건 사실 **게임이 "성능을 위해 탐색을 포기했다"는 신호**임. 기술적 제약을 게임플레이 피드백으로 승화시킨 거 개인상받아야 함.

### 충돌 판정도 없앰, 대신 행복도로 우회

수천 명의 NPC가 서로 충돌 회피 연산을 한다? 그건 프레임레이트 킬러임. **RCT 손님들은 서로 충돌 판정 자체가 없음.** 같은 타일에 수천 명이 겹쳐도 게임은 멀쩡하게 돌아감.

대신 주변에 다른 손님이 너무 많으면 **행복도(happiness)가 떨어지고 불만이 쌓이는 방식**으로 혼잡도를 간접적으로 처리함. 플레이어 입장에선 여전히 공원 레이아웃을 잘 설계해야 하고, 연산 비용은 비교도 안 되게 낮아짐.

### 결론: 코더 = 게임 디자이너일 때만 가능한 최적화

RCT의 최적화 중 상당수는 **프로그래머와 게임 디자이너가 같은 사람**이었기 때문에 가능했음. 현대 게임 개발에선 이 두 역할이 완전히 분리되어 있어서 이런 식의 협업은 거의 불가능에 가까움. 다만 교훈은 여전히 유효함 — 더 많은 대화, 그리고 때로는 기술적 도전에 "안 돼"라고 말하는 용기.

## 핵심 포인트

- Assembly + 게임 디자이너 겸 프로그래머 = 전무후무한 최적화 조합
- 길찾기 알고리즘을 게임 설계 자체로 우회 (랜덤 워킹 방식)
- 충돌 판정 제거 후 행복도 시스템으로 혼잡도 간접 처리

## 인사이트

요즘 게임들이 빌딩 시뮬에서도 버벅이는 거 보면 RCT의 접근법은 진짜 다시 배울 필요 있음. 기술적 한계를 '극복'하는 게 아니라 '설계로 아예 피하는' 발상의 전환이 핵심인데, 이게 개발 역할 분리가 심화된 현대 스튜디오에서 얼마나 실현 가능할지가 관건임.