# 최적화의 정석: 롤러코스터 타이쿤 내부 들여다 보기 > Clean Markdown view of GeekNews topic #27778. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27778](https://news.hada.io/topic?id=27778) - GeekNews Markdown: [https://news.hada.io/topic/27778.md](https://news.hada.io/topic/27778.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-23T17:33:21+09:00 - Updated: 2026-03-23T17:33:21+09:00 - Original source: [larstofus.com](https://larstofus.com/2026/03/22/the-gold-standard-of-optimization-a-look-under-the-hood-of-rollercoaster-tycoon/) - Points: 27 - Comments: 2 ## Summary 1999년작 **RollerCoaster Tycoon**은 거의 전부 어셈블리어로 작성되어, 수천 명의 손님을 실시간으로 처리하면서도 안정적인 성능을 낸 **극단적 수동 최적화의 결정체**로 평가받습니다. 팬 프로젝트 OpenRCT2의 역공학 분석을 통해, 비트 시프트 연산·데이터 타입 세분화·경로 탐색 깊이 제한 등 **설계 단계에서 연산 자체를 줄이는 구조적 최적화**가 드러났습니다. 오늘날에도 이런 접근은 “코드를 빠르게 만드는 것”보다 “불필요한 계산을 설계에서 없애는 것”이 얼마나 강력한지 다시 상기시켜 줍니다. ## Topic Body - 1999년작 **RollerCoaster Tycoon**은 거의 전부 **어셈블리어로 작성된 시뮬레이션 게임**으로, 수천 명의 손님을 실시간으로 처리하면서도 안정적인 성능을 유지 - 개발자 **Chris Sawyer**는 고수준 언어 대신 저수준 제어를 택해, **CPU 연산 효율을 극대화한 마지막 세대의 어셈블리어 게임**을 완성 - 팬 프로젝트 **OpenRCT2**를 통해 원본의 **정밀한 최적화 패턴과 메모리 절약 기법**이 역공학적으로 분석됨 - 게임은 **비트 시프트 연산과 데이터 타입 세분화**를 활용해 연산 속도와 캐시 효율을 높였으며, **경로 탐색 깊이 제한**과 **충돌 연산 제거**로 대규모 시뮬레이션을 가능하게 함 - 이러한 구조는 **기술적 제약을 창의적으로 활용한 최적화의 전형**으로, 오늘날에도 설계 단계에서 불필요한 연산을 제거하는 접근의 중요성을 보여줌 --- ### RollerCoaster Tycoon의 최적화 구조 분석 - 1999년 출시된 **RollerCoaster Tycoon(RCT)** 은 거의 전부 **어셈블리어(Assembly)** 로 작성되어, 수천 명의 에이전트를 실시간으로 시뮬레이션하면서도 당시 하드웨어에서 안정적인 프레임을 유지한 게임으로 평가됨 - 독일 게임 팟캐스트 *Stay Forever* 에서 다룬 내용을 기반으로, **Chris Sawyer** 가 어떻게 극단적인 수준의 최적화를 달성했는지를 구체적으로 분석함 - 원본 소스코드는 공개되지 않았지만, 팬들이 제작한 **OpenRCT2** 프로젝트를 통해 코드 구조와 최적화 기법을 역공학적으로 확인할 수 있음 - ## 어셈블리어 기반의 성능 극대화 - RCT는 **C나 C++ 대신 어셈블리어**로 작성되어, 당시 다른 게임보다 훨씬 세밀한 성능 제어가 가능했음 - 예를 들어, *Doom* (1993)은 대부분 C로 작성되었으나, RCT는 거의 전부 어셈블리어로 구현됨 - 이 접근은 1990년대 후반에는 이미 드문 방식이었으며, RCT는 **마지막 대형 어셈블리어 게임** 중 하나로 평가됨 - 당시에는 컴파일러의 자동 최적화가 제한적이었기 때문에, 수동 최적화가 성능에 큰 차이를 만들었음 - ## OpenRCT2를 통한 코드 분석 - **OpenRCT2** 는 팬들이 원본 게임을 완전히 재구현한 오픈소스 프로젝트로, 원본 자산을 그대로 사용하면서도 **100% 호환성**을 유지함 - 초기 버전은 원본 코드와 거의 동일한 동작을 재현했으며, 이후 다양한 개선이 추가됨 - 이 프로젝트를 통해 원본 코드의 **세밀한 최적화 패턴**을 확인할 수 있었음 - ## 데이터 타입의 세분화 — 메모리 절약 - RCT는 **금액 데이터의 크기를 상황별로 다르게 저장**함 - 예: 전체 공원 가치는 4바이트 변수 사용, 상점 가격은 1바이트 변수 사용 - 이러한 세분화는 메모리 절약과 캐시 효율 향상을 위한 것으로, **현대 CPU에서는 성능 차이가 거의 없어** OpenRCT2에서는 단일 8바이트 변수로 통일됨 - ## 비트 시프트를 이용한 수학 연산 최적화 - 코드에는 `NewValue = OldValue >` 연산은 2의 거듭제곱으로 나누는 연산을 대체함 - 이러한 최적화는 **곱셈·나눗셈이 2의 거듭제곱일 때만 가능**하므로, 게임 내 수식 자체가 이 조건에 맞게 설계된 것으로 보임 - 즉, **게임 디자인 단계에서부터 CPU 연산 효율을 고려한 수학 구조**가 사용된 셈임 - ## 성능을 고려한 게임 디자인 - RCT는 Chris Sawyer가 **프로그래머이자 유일한 게임 디자이너**로 참여했기 때문에, 설계 단계에서부터 성능을 고려한 구조를 만들 수 있었음 - 대표적 사례는 **손님(Pathfinding) 시스템** - 대부분의 시뮬레이션 게임은 손님이 목적지를 정하고 경로를 탐색하지만, RCT에서는 손님이 **무작위로 걷다가** 우연히 놀이기구를 발견함 - 이 방식은 **대규모 경로 탐색 연산을 피하는 구조**로, 수천 명의 손님을 동시에 처리할 수 있게 함 - 경로 탐색이 필요한 경우(예: 정비공이 고장난 놀이기구로 이동)는 **탐색 깊이 제한**을 두어 프레임 드랍을 방지함 - 일반 손님은 5개의 교차로까지만 탐색, 정비공은 8개까지 탐색 - 지도를 구매한 손님은 탐색 한도가 7로 증가함 - 이러한 제한은 단순한 기술적 절충이 아니라, **게임플레이 요소로 자연스럽게 통합된 최적화 구조**임 - ## 군중 처리와 충돌 회피 생략 - RCT는 **손님 간 충돌이나 회피 연산을 완전히 제거**함 - 수천 명의 손님이 동일한 경로 타일을 공유할 수 있음 - 대신, 주변 인구 밀도를 추적하여 **혼잡도가 높으면 손님의 행복도가 감소**하도록 설계됨 - 플레이어는 여전히 혼잡을 관리해야 하지만, 계산량은 훨씬 적음 - 이 방식은 **복잡한 물리 연산을 제거하면서도 게임 경험을 유지**한 대표적 사례로 평가됨 - ## 현대 개발에 주는 시사점 - RCT의 최적화는 **기술적 제약을 창의적으로 활용한 사례**로 평가됨 - 오늘날에도 이러한 접근은 가능하지만, **프로그래머와 디자이너 간의 긴밀한 협업**이 필요함 - 때로는 기술적 문제를 해결하기보다, **문제 자체를 설계 단계에서 제거하는 접근**이 더 큰 성능 향상을 가져올 수 있음 ## Comments ### Comment 53700 - Author: cadenzah - Created: 2026-03-24T11:21:58+09:00 - Points: 2 롤코타 많이 사랑해주세요 ### Comment 53661 - Author: neo - Created: 2026-03-23T17:33:21+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47480886) - Warcraft 1, 2, StarCraft 모두 **2의 거듭제곱 단위 맵 크기**를 사용했음 덕분에 느린 386/486 CPU에서도 나눗셈·곱셈 대신 시프트 연산으로 속도를 확보할 수 있었음 맵 렌더링, 스프라이트, 폰트, 안개 효과 등은 수천 줄의 어셈블리로 처리했고, 나머지는 **C로 작성된 이식성 높은 코드**였음 Blackthorne의 경우 SNES, Genesis, DOS 버전이 각각 다른 어셈블리로 수작업 포팅되었고, PC 버전은 **VGA Mode X**를 위해 10만 줄의 렌더링 코드를 매크로로 생성했음 이런 경험 덕분에 Blizzard에서는 “어셈블리는 너무 많은 개발 시간을 잡아먹는다”는 교훈을 얻었음 Comanche: Maximum Overkill은 전부 어셈블리로 작성된 **보텍스 기반 헬기 시뮬레이터**였는데, 보호 모드로 포팅이 너무 힘들어 이후 버전부터 폴리곤 렌더링으로 전환했음 - Reddit 사용자가 StarCraft 골드 마스터 소스코드를 발견했지만, **Blizzard 굿즈**와 교환하며 반환한 게 아쉬움 EA는 [Command & Conquer 시리즈 소스코드](https://github.com/electronicarts)를 공개했는데, Tiberian Sun과 Red Alert 2는 빠져 있었음 StarCraft도 역사 보존 차원에서 공개되었으면 좋았을 것 같음 - 어릴 적 **Comanche와 Settlers 1**을 처음 봤을 때 DOS 텍스트 모드에서 그래픽이 나오는 게 마법 같았음 그때부터 게임에 완전히 빠져들었음 - 혹시 **Lost Vikings**에도 참여했다면, 어린 시절의 즐거움을 줘서 고맙다는 말을 전하고 싶음 혹시 **데모씬(demoscene)** 활동도 했는지 궁금함 - Blizzard에 있을 때 **소스코드 서버를 잃어버리고 백업도 없던 사건**이 있었는데, 그 시기에 있었는지 궁금함 나는 WC3 출시 즈음 컨설턴트로 잠시 있었음 - Maximum Overkill은 정말 **수백 시간**을 플레이할 만큼 놀라운 게임이었음 - 글에서 언급된 것처럼, **디자이너와 프로그래머가 동일인**일 때 훨씬 인상적인 결과물이 나오는 것 같음 대기업의 계층적 구조로도 결국은 인력으로 밀어붙이면 뭔가 나오긴 하지만, 진짜 창의적인 결과는 한 사람의 머리에서부터 완성되는 경우가 많음 **AI 개발 도구의 미래**도 이런 ‘1인 개발 시대’로 회귀할지도 모른다는 생각이 듦 - 게임 디자이너도 여전히 **수치적 특성**을 고려해야 함 좋은 디자이너일수록 연산 효율이나 정밀도 같은 요소가 게임 밸런스에 영향을 준다는 걸 알고 있음 요즘은 이런 걸 무시하는 개발자도 많지만, 그게 게임 품질 저하의 **숨은 원인**이 되기도 함 - 예전엔 나도 이런 미세 최적화가 중요하다고 생각했지만, **현대 CPU의 파이프라인 구조**를 공부하고 생각이 바뀌었음 지금은 덧셈 1사이클, 곱셈 3사이클, 나눗셈 12사이클 수준이고, 동시에 여러 연산을 병렬로 처리함 예전 펜티엄 시절엔 46사이클이 걸렸고 클럭도 100MHz였음 지금은 **메모리 레이아웃**이 훨씬 중요함 — 캐시 미스 한 번이면 100~1000사이클이 날아감 int[]로 연산하는 게 Monster[]보다 훨씬 빠름 - 나는 [csgrs CAD 커널](https://github.com/timschmidt/csgrs)을 개발 중인데, **숫자 계산은 아직도 풀리지 않은 문제**라고 느낌 속도, 정확도, 저장 크기, 복잡도 사이의 트레이드오프가 존재함 [Toward an API for the Real Numbers](https://dl.acm.org/doi/epdf/10.1145/3385412.3386037) 같은 논문은 이런 문제를 단계적으로 해결하려는 접근을 제시함 부동소수점 오차, 구간 산술, 심볼릭 연산 등 다양한 방법이 있지만, 결국 **트레이드오프를 이해하지 못하면 문제에 물림** - 상업 게임은 대량 생산되는 제품이므로, 디자이너가 기술적 제약을 이해하는 건 **산업 디자인 감각**으로서 큰 장점임 예를 들어 **Fumito Ueda**는 『Shadow of the Colossus』에서 기술적 실현 가능성을 세심히 고려했고, **Doom**도 창의성과 기술의 결합이었음 [관련 인터뷰](https://www.designroom.site/shadow-of-the-colossus-oral-hist...) 참고 - 게임 품질은 단순히 효율적인 런타임 성능이 아니라 **재미와 완성도**의 문제임 버그, 스토리 일관성, 몰입감이 더 중요함 물론 프레임 드랍이 심하면 품질 저하지만, 타깃 하드웨어에서 부드럽게 돌아간다면 개선은 다른 부분에 집중해야 함 - ARM Cortex-M4 기반 제품을 개발할 때 **커스텀 난수 생성기**를 만들었음 Thumb-2 명령어로 상수를 즉시 로드할 수 있게 조정해 메모리 스톨을 피했음 덕분에 빠르고 효율적으로 난수를 사용할 수 있었고, 테스트도 모두 통과했음 하지만 나중에 Cortex-M0로 바뀌면서 이 코드는 폐기되었음 - 기술적 제약을 **게임플레이 요소로 전환**하는 부분이 흥미로웠음 『젤다의 전설』의 [**Blood Moon** 시스템](https://www.polygon.com/legend-zelda-tears-kingdom/23834440/...)이 떠오름 - “/8 대신 >>3을 쓰면 나눗셈을 절약할 수 있다”는 설명은 **현대 컴파일러에서는 사실이 아님** 타입이 맞다면 컴파일러가 자동으로 시프트 연산으로 최적화함 - 단, **부호 있는 정수(signed)** 의 경우는 C 표준의 반올림 규칙을 맞추기 위해 추가 연산이 들어감 - “이진수에서 왼쪽 시프트는 두 배가 된다”는 설명을 보고 놀랐음 2026년에 이런 기본 개념이 새삼스러울 정도로 낯설게 느껴지는 게 신기함 - [xkcd 2501](https://xkcd.com/2501/)이 떠오름 - “컴파일러가 2의 거듭제곱 곱셈을 시프트로 바꾸지 않는다”는 말은 오래된 농담임 2000년대에도 이미 **컴파일러가 그런 코드를 보면 하품할 정도로 당연히 최적화함** - 재미있게 읽었음. RCT 관련해서는 아래 자료들도 추천함 - [Chris Sawyer 인터뷰 (2024)](https://news.ycombinator.com/item?id=46130335) - [MicroProse의 마지막 불꽃](https://news.ycombinator.com/item?id=44758842) - [RCT 25주년 인터뷰](https://news.ycombinator.com/item?id=39792034) - [“RollerCoaster Tycoon was the last of its kind” 영상](https://news.ycombinator.com/item?id=42346463) - [The Story of RollerCoaster Tycoon (YouTube)](https://www.youtube.com/watch?v=ts4BD8AqD9g) - 대형 스튜디오에서 **기술적 제약을 게임의 특징으로 승화**시키는 게 가능한지 궁금함 스토리텔링에서도 장애물이 이야기를 흥미롭게 만들듯, 1인 개발자는 기술적 한계를 **창의적 요소로 전환**할 수 있음 예를 들어 버그나 글리치를 미니게임으로 재해석하는 식의 접근이 떠오름 - RCT의 **경로 탐색(pathfinding)** 부분을 보며 [Marcel Vos의 유튜브 영상](https://youtu.be/twU1SsFP-bE)이 생각났음 그는 RCT의 내부 동작을 깊이 파헤치는 영상들을 많이 올림